Anthropic工程师Addy Osmani：用Coding Agent，工程师其实在当管理者

以前工程师一天的工作往往从打开 IDE、翻代码起步。现在，一些把 Coding Agent 用得很深的工程师，每天第一件事变成了查看几个 AI Agent 的进度：哪些活干完了、哪些测试没过、哪些 PR 等着审、哪些任务得重新派。

代码是 AI 写的，可工程师的活儿看上去并没轻松多少。11 月 8 日，Anthropic Claude Code 团队工程师 Addy Osmani 在 X 上发了一篇长文《Your Coding Agents Made You a Manager》（《你的编程智能体让你成为了一名管理者》），提出一个挺有意思的看法：工程师一旦频繁使用 Coding Agent，实际上就已经在做管理工作了。

挑任务、写指令、派活、盯进度、验收结果，最后拍板哪些代码能上线——这些事跟带一支工程团队像得出奇。问题也跟着来：一个 Agent 写出几百行代码，工程师压根没时间逐行看，怎么判断它靠不靠谱？同时跑五个 Agent，就真有五倍生产力？Agent 能自己定计划、执行任务、修错误了，工程师又该在哪几个环节插手？

Addy 的看法是，真正会用 Coding Agent 的工程师，未必是提示词工程玩得最溜的那批人，而是懂得让 Agent 自主干活、同时把验证机制搭起来的人。这对不少工程师来说有点讽刺：他们选个人贡献者（IC）这条路，本来图的就是专心搞技术，躲开整天开会、分派任务的管理者角色。结果 Coding Agent 又把他们拽回任务交接、工作监督和成果验收这些事上。

结合 Claude Code 的开发和使用经验，Addy 整理出一套管理 Coding Agent 的实操办法，涵盖任务分配、自动验证、人机协作、多 Agent 并行和最终决策。InfoQ 对原文做了编译整理。

让 Agent 自己证明工作完成了

不逐行看代码，怎么保证 Agent 一直产出高质量的东西？Addy 认为答案得从成熟工程团队的管理方式里找。老练的工程经理不会亲自去查每个人写的每一行代码，他们靠的是持续集成（CI）、自动化测试和代码审查这套质量保障。管 Coding Agent 也一样：工程师要搭一套让 Agent 自己验证结果的机制，而不是自己给所有任务当最终测试员。

第一步，是让 Agent 学会验证自己的活，别把所有检查都甩给工程师。Addy 在这条建议里给了一份 Claude Code 的最佳实践指南。他指出，没有验证机制，Agent 常常在任务“看起来完成”时就收手。所以开发者该把测试套件、构建检查、Linter 这些工具备好，让 Agent 自己发现错误、自己修。碰上 UI 任务，还可以让它打开浏览器看看实际效果。

验证机制也能嵌进日常工作流。比如在 CLAUDE.md 里记下测试命令，用 /goal 在每轮执行后核对目标有没有达成，通过 Stop Hook 拦住没过类型检查的任务不让它结束，或者用 /code-review 让独立的子 Agent 来审代码。这样工程师只用盯 Agent 自己验证不了的问题。

第二步，任务上下文要给清楚，但 Agent 自己能查到的信息不用重复。现在的 Coding Agent 已经能很快摸清代码结构、开发规范和测试配置。工程师更该交代的是仓库里没有的东西：这个任务为什么重要、有哪些约束、怎么算成功。打个比方，与其说“让仪表盘更快”，不如讲明白：把万人规模组织的 /team 仪表盘 p95 加载时间压到两秒以内，不许动数据库 Schema 和 API 响应结构，并用指定脚本验证优化效果。需求还没想清楚的，也可以先让 Agent 通过提问把规格说明理出来，再动手开发。

第三步，每次纠错都得攒下经验。同一个问题纠正过两次，就该把相关规则写进 CLAUDE.md，或者把重复的活封装成 Skill。Addy 建议重点记这几类：验证命令、容易看错的代码、仓库里没有的重要决策，以及反复冒出来的错误——别让每次会话都从零开始。不过这并不意味着 CLAUDE.md 里规则越多越好。Addy 此前专门谈过 Agent 指令文件怎么维护（https://addyosmani.com/blog/audit-your-agent-files/）：模型能力和项目环境都在变，过去管用的指令可能变得多余，开发者该定期清掉失效规则，免得攒下来的经验慢慢变成新的维护负担。

最后一条，Agent 能力越强，工程师反倒越该少插手。这话听着有点反直觉，Addy 借了英特尔前 CEO Andy Grove 的管理理念，认为监督的松紧应当跟执行者在这件具体任务上的能力对上。已经能自主完成的活，指令、规则和过程干预塞得太多，未必提质量，反而可能压住 Agent 的发挥。在 Claude Code 里，提示词、CLAUDE.md 和 Skills 主要用来指导模型，Hooks、Deny Rules 之类则可以用来强制执行要求。所以只有“禁止修改生成代码”“必须运行指定检查”这种不能让步的要求，才值得强制约束；一般偏好，尽量交给 Agent 自己判断。

模型能力往上走，以前反复念叨的“think harder”“don't be lazy”这类习惯也可能没必要了。在 Addy 看来，规则和干预越加越多，没准只是把人类管理里的“微观管理”搬到了 Agent 身上。

可以委派任务，但不能委派判断

等 Agent 已经能独立把活干完，工程师还得拿主意：什么时候介入、怎么纠偏、哪些决定必须自己扛。

Addy 给出一条关键原则：任务可以交出去，判断不能交出去。工程师得在动手前帮 Agent 把方向定清楚，在关键节点上及时拉回来，最终交付的结果也要自己担着。

先有方案，再让 Agent 动笔写代码。Addy 的做法是：复杂任务先开 Claude Code 的 Plan Mode，跟 Agent 来回讨论方案，把里面没验证过的假设挑出来，然后才进入开发。任务更大一些的，还可以再起一个会话，让另一个 Agent 站在资深工程师的角度审这份方案。问题在设计阶段暴露，代价通常比代码写完再返工要低。

拆任务这件事同样能交给 Agent。Claude Code 的 /batch 会把一次大型代码修改切成 5 至 30 个相对独立的任务，执行计划确认之后，各任务在独立的 Git Worktree 里并行跑，再按运行环境和任务结果创建 PR。

不过任务边界还得工程师自己看：不同 Agent 的活不能撞车，共享接口要提前定下来。要不然，五个 Agent 一起开工，产出未必是五倍，合并冲突倒可能多出一堆。

另一条是尽早纠偏，别一遍遍追加指令。需要人盯的任务，Addy 建议在 Agent 启动不久就去看它往哪个方向走。一旦发现它对任务的理解明显跑偏，越早纠正越好，免得错误路径一直烧时间和 Token。

连续纠正两次还不见效，就该清掉会话，把失败的经验带上重写提示词。接着纠下去，模型只会反复处理更多失败记录，上下文越背越重。

Claude Code 的 /rewind 能把代码和对话退回到较早的状态，试不同方案的成本因此低了不少。有保留价值的经验，复盘之后写进 CLAUDE.md。

说到底，任务可以委派，关键判断还是人的事。Addy 讲了自己的一次经历：他让 Agent 去研究产品与竞品的功能差距，再写代码提 PR。研究结论看着合理，测试也全过了，他差点就提交，最后发现这些功能对用户价值有限，反倒把产品搞复杂了。

用 Coding Agent 时很容易陷进这种错觉：眼前是一份 600 行的代码修改，变量命名合理，测试全部通过，甚至另一个 Agent 已经把代码审过一遍，工程师就觉得可以放心合并。

可代码跑得通，不等于这项修改就该存在。它可能带来不必要的复杂性，可能解决的是一个并不重要的问题，也可能让团队长期背上额外的维护成本。这些毛病，自动化测试未必查得出来。

Addy 的看法是，代码风格调整、常规 Bug 修复、单元测试这类活可以交给 Agent；产品取舍、安全边界、合规要求和最终上线决策，仍然归人。工程师不必盯着 Agent 的每一步操作，但必须把约束讲清楚、留下验证证据，并决定哪些修改要走人工审批。他还建议每次代码变更尽量做小，因为代码审查的基本单位，应该是人真正能看懂的单位。

同时管理五个 Agent，不等于获得五倍生产力

Agent 能长时间自主运行，甚至把任务再分给别的 Agent，工程师的工作重心也就跟着变了。

在 Addy 看来，这有点像管着多个团队的上层管理者：不再盯着每个人具体做什么，而是靠目标、约束和检查机制把事情推完。

第一步，是给无人值守的 Agent 设计一套完整的运行机制。现在 Agent 已经能定时跑，或者在 CI 检查失败、新 PR 创建时自动启动。但在放它独立干活之前，工程师要回答五个问题：什么情况下算任务完成？Agent 怎么自己验证结果？它有哪些操作权限？执行轮数或费用上限设没设？最终成果谁来审批？

Addy 建议新的自动化流程先小范围试跑。比如批量改文件，先让 Agent 处理三个文件，看效果、调指令，再动剩下的。新搭的工作流也一样，先观察最初几次执行，再逐步放开无人值守。

还有一点：扩大 Agent 的使用规模，不等于不停加 Agent 数量。Agent 的执行时间可以并行，人的注意力却很难无限扩展。每多一个 Agent，工程师就可能多出任务协调、结果审查、异常处理和上下文切换的成本。

Addy 把这部分额外负担叫作“编排税”（Orchestration Tax）。他自己平时同时跑四五个后台 Agent 和几个本地会话，即便这个规模，有时也已经顾不过来。

换句话说，能启动多少个 Agent，和能有效管住多少个 Agent，是两码事。如果每个 Agent 都要人不断看进度、答问题、审代码，并行数量一多，工程师自己很可能就成了整条工作流的新瓶颈。

所以真正要扩的是验证能力，不是人工监督。靠自动检查、目标验证、独立审查，再加上集中查看后台任务、接收通知，工程师能少做反复检查，把注意力省给重要决策。

与此同时，衡量 Agent 的价值不能只看它写了多少代码。Addy 建议盯 PR 完成周期、新员工熟悉项目所需的时间，以及代码回滚和返工的频率。如果统计合并了多少 PR，也该同时统计其中多少需要返工或回滚，别光追产出数量。

Agent 生成代码的成本一低，几乎每个看着可行的想法都能很快变成 PR，可这些代码照样要审查、要安全检查、要长期维护。写代码越来越便宜，并不意味着软件开发的整体成本会同比例下降。

所以扩大 Agent 的使用规模，最终不能只用代码量或 PR 数量来衡量。更该看的是：一项需求从提出到交付要多久，Agent 生成的修改里有多少要返工或回滚，以及工程师的重复劳动是不是真的少了。

如果同时跑更多 Agent，只是让团队多出一堆等着审查的 PR，那所谓生产力提升，很可能只是把活从编码阶段挪到了审查阶段。

管理 Agent，跟管人不是一回事

不过 Addy 也提醒，别把 Coding Agent 真当成一名工程师。一个人能同时带五个 Agent，不等于他有带五名工程师的本事。真正的团队管理要处理激励、化解冲突、规划职业发展，还得靠长时间建立信任，这些都没法直接搬到 Agent 身上。

头一个区别在于，Agent 试错和返工的成本低得多。技术方案有争议时，工程师可以让 Agent 各做两三个版本，再拿实际效果比一比，不用像带人类团队那样掂量时间和协调上的开销。

第二个区别是，Agent 没有人类工程师那种持续积累的实践经验，跨会话的经验全靠能存下来、能调出来的信息。举个例子，Claude Code 的 Auto Memory 只把笔记存在本地，不会自动同步到团队其他成员的会话里。这些记录也顶不上工程师长年攒下的经验与判断，重要的经验还是得整理成团队共享的知识。

第三个区别是，Agent 在某些场景下可能过于积极、过于自信。让一名优秀工程师去做明显错误的事，对方也许会出言反对；可比起有经验的人类工程师，Coding Agent 在一些场景里更倾向于顺着用户的要求走，哪怕任务的前提本身就值得怀疑。Addy 引用了沃顿商学院关于“认知让渡”（Cognitive Surrender）的研究：人们可能接受 AI 给出的错误答案，甚至因此更确信自己的判断。他建议让 Agent 主动反驳自己的结论，以降低过度信任的风险。

还有一点，人类团队成员技能和经验各不相同，而跑同一模型的 Agent 往往优势相似、弱点也相似，这些特点还会随模型更新而变。

当 Agent 接下大量入门级开发任务，管理者还得有意识地为初级工程师留出实践机会，别让他们断了练基本功的路子。工程师也不该因为整天管 Agent，就忽略了跟同事沟通、建立团队信任。

那么，工程师真的非得当管理者吗？Addy 的答案是否定的。他说的管理能力，其实并非工程经理专属。优秀的 Staff Engineer 一直在做类似的事：明确需求与技术约束、写设计文档、审查代码，帮别人更高效地完成工作。Coding Agent 让更多工程师开始练这些能力，试错和调整的成本也更低。

写代码越来越便宜，工程师要回答的问题也跟着变了：这个任务值不值得做？Agent 交付的结果靠不靠得住？哪些修改该接受，哪些该拒绝？你不必真的去当一名管理者。但想把 Coding Agent 的价值用足，或许得先学会管好它们。