编译｜林绮蓓
编辑｜蔡芳芳
以前，工程师的一天可能从打开 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 的答案是否定的。
实际上，Addy 所说的管理能力，并非工程经理独有。优秀的 Staff Engineer 一直在做类似的事情：明确需求与技术约束、编写设计文档、审查代码，并帮助其他人更高效地完成工作。Coding Agent 让更多工程师开始实践这些能力，而且能够以更低的成本试错和调整。
当写代码越来越便宜，工程师需要回答的问题也在发生变化：任务是否值得做？Agent 交付的结果是否可靠？哪些修改应该被接受，哪些又应该被拒绝？
你不必真的成为一名管理者。但如果想充分发挥 Coding Agent 的价值，或许就需要先学会管理它们。
