Addy Osmani谈Coding Agent管理：工程师如何变成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 里，提示词、以及 Skills 管的是给模型指方向，Hooks、Deny Rules 这类东西才用来强制执行。所以真正值得上强制手段的，只有“生成代码不许改”“指定检查必须跑”这种没得商量的要求；一般性的偏好，尽量留给 Agent 自己拿主意。CLAUDE.md

模型能力在涨，过去翻来覆去叮嘱的“think harder”“don't be lazy”，以后未必还用得上。Addy 的看法是，规则越加越多、干预越来越密，说白了就是把人类管理里那套“微观管理”原样搬到了 Agent 身上。

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

Agent 能独立把活干完之后，工程师还得想清楚：什么时候插手、怎么纠偏、哪些决定必须自己扛。Addy 为此提了一条原则——任务可以委派，判断不能委派。落到操作上，就是执行前帮 Agent 把方向定清楚，关键节点及时拉回来，最后交付的结果由自己负责。

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

Claude Code 的能把一次大型代码修改切成 5 至 30 个相对独立的任务，执行计划确认之后，用独立的 Git Worktree 并行跑，再按运行环境和任务结果提 PR。/batch

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

第二步是早点纠偏，别一遍遍追加指令。需要人盯的任务，Addy 建议在 Agent 刚启动那阵就去看看方向对不对；一旦发现它对任务的理解明显跑偏，越早掰回来越好，免得错误路径一直烧时间和 Token。要是连着纠两次还是不行，干脆清掉会话，把失败的经验带上重写提示词——接着纠下去，模型只会反复消化更多失败记录，上下文越背越重。

Claude Code 的还能把代码和对话退回较早的状态，试不同方案的成本因此低了不少。有保留价值的经验，复盘之后写进就行。/rewindCLAUDE.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 的答案是否定的。

其实 Addy 说的管理能力，并不是工程经理才有。优秀的 Staff Engineer 一直在干类似的事：明确需求和技术约束、写设计文档、审查代码，帮别人更高效地完成工作。Coding Agent 让更多工程师开始练这些能力，而且试错和调整的成本更低。

写代码越来越便宜，工程师要回答的问题也跟着变了：这个任务值不值得做？Agent 交付的结果靠不靠谱？哪些修改该接受，哪些该拒绝？

你不必真的去当一名管理者。但想把 Coding Agent 的价值用足，或许得先学会管它们。