不想当管理者，就用不好 Coding Agent？Anthropic 工程师长文谈 Agent 管理实战
Addy 在梳理 Claude Code 的开发与使用经验后，给出一套颇具“管理味”的结论：工程师不必为了用好 Coding Agent 转去当管理者，但必须补上任务分配、过程监督、结果验收这套动作。过去不少人选择个人贡献者（IC）路线，就是为了少开会、少派活、专注技术；如今 Agent 接管大量执行环节，工程师反而重新面对“把活交出去、盯着它做完、判断做得对不对”的问题。
Addy把Coding Agent摆上管理岗的桌面
在 Addy 看来，真正擅长使用 Coding Agent 的工程师，未必是最会写提示词的人，而是能让 Agent 自主完成工作、同时建立有效验证机制的人。
- 当 Agent 能自己制定计划、执行任务、修复错误，工程师需要决定在哪些环节介入。
- 当 Agent 一次写出几百行代码，工程师很难逐行检查，必须判断交付结果是否可靠。
- 同时运行五个 Agent，并不自动等于五倍生产力，任务拆分、依赖处理和结果合并都会吞掉收益。
- 写代码越来越便宜后，工程师要回答的问题变成：任务是否值得做？结果是否可信？哪些修改该接受，哪些该拒绝？
Addy 的答案是否定的：工程师并不需要真的成为管理者。但他所说的管理能力，并非工程经理独有。优秀的 Staff Engineer 一直在做类似的事——明确需求与技术约束、编写设计文档、审查代码、帮助其他人更高效地完成工作。Coding Agent 只是让更多工程师以更低成本开始实践这些能力。
让Agent自己跑测试、开浏览器、交证据
如何在不逐行检查代码的情况下，确保 Agent 持续产出高质量工作？Addy 认为，答案可以从成熟工程团队的管理方式里找：经验丰富的工程经理不会亲自检查每个人写下的每一行代码，而是依靠持续集成、自动化测试和代码审查建立质量保障机制。
管理 Coding Agent 也是如此。工程师需要让 Agent 学会验证自己的工作，而不是自己成为所有任务的最终测试员。
- 提供测试套件、构建检查、Linter 等工具，让 Agent 自行发现并修复错误。
- 对 UI 任务，让 Agent 打开浏览器检查实际效果。
- 在
CLAUDE.md中记录测试命令，减少每轮重复交代。 - 使用
/goal在每轮执行后检查目标是否达成。 - 通过 Stop Hook 阻止未通过类型检查的任务结束。
- 使用
/code-review让独立的子 Agent 审查代码。
这套机制的核心，是把“看起来完成”变成“证明完成”。如果没有验证机制，Agent 往往会在任务表面完成时停下来；有了自动验证，工程师只需关注 Agent 无法自行判断的问题。
先搭模型、工具、循环，再谈五个窗口并行
Addy 强调，Agent 的核心结构并不复杂：模型、工具、循环，在一个环境中运作。三个关键组成部分分别是环境、工具集和系统提示。环境是 Agent 操作所在的系统；工具集是 Agent 采取行动和获取反馈的接口；系统提示则定义 Agent 的目标、约束和理想行为。
迭代时应优先构建和打磨这三个基本组件，因为这是投资回报率最高的部分。过早加入缓存轨迹、并行化工具调用、复杂界面等优化，反而会扼杀迭代速度。优化应该等到基本行为确定后再做。
Agent 也不是所有用例的默认升级方案。它成本高、延迟高，更适合扩展复杂且有价值的任务。对于可以清晰映射决策树的任务，显式构建工作流更具成本效益和可控性。Addy 给出的检查清单包括：
- 任务复杂度：Agent 擅长模糊问题空间；决策路径清晰时，工作流更合适。
- 任务价值：Agent 的探索性行为会消耗大量 token，任务价值必须能证明成本。
- 关键能力可行性：要确认 Agent 在编写、调试、错误恢复等关键环节没有严重瓶颈。
- 错误成本与发现难度：错误代价高且难以发现时，很难信任 Agent 自主行动，需要通过限制范围或人工干预缓解。
这也解释了为什么“同时开五个 Agent”不是起点。单 Agent 的基本组件、验证机制和介入边界没搭
