Anthropic工程师谈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 又把他们推回到任务交接、工作监督和成果验收面前。

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

让 Agent 自己证明活干完了

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

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

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

第二步，任务上下文要给清楚，但 Agent 自己能查到的信息不必重复。现在的 Coding Agent 理解代码结构、开发规范、测试配置都很快。工程师更该交代的是仓库里没有的东西：这个任务为什么重要、有哪些约束、怎么算成功。

比方说，与其说“让仪表盘更快”，不如写明：把万人规模组织的仪表盘 p95 加载时间压到两秒以内，数据库 Schema 和 API 响应结构都不动，并且用指定脚本验证优化效果。需求还没想清楚的，也可以先让 Agent 提问，把规格说明整理出来再动手开发。/team

第三步，每次纠错都要留下经验。同一个问题纠正过两次，就该把相关规则写进，或者把重复的活封装成 Skill。Addy 建议重点记这几类：验证命令、容易被误解的代码、仓库里没有的重要决策、反复冒出来的错误。别让每次会话都从零开始。CLAUDE.md

不过 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 一起跑，如果等来的只是团队里积压更多待审 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 的价值用足，或许得先学会管它们。