不想当管理者，就用不好 Coding Agent？Anthropic 工程师长文谈 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。 如果连续两次纠正仍然失败，不如清除会话，结合失败经验重新编