Anthropic Claude Code 团队工程师 Addy Osmani 近日发文指出：深度使用 Coding Agent 的工程师，日常已在做任务分配、进度跟进与成果验收——本质上是在管理 Agent。真正拉开差距的，不是提示词技巧，而是能否让 Agent 自证完成、把产品与上线判断留在人手里。
背景：写代码变便宜，工作却更像管理
11 月 8 日，Addy 在 X 上发布长文《Your Coding Agents Made You a Manager》。他观察到：工程师一天可能从查看多个 Agent 的进度开始——哪些完成、哪些测试失败、哪些 PR 待审、哪些要重派。代码多半是 AI 写的，但人的负荷并未消失，只是从敲键转向编排与验收。
这与个人贡献者（IC）原本想躲开的「开会、派活、盯结果」高度相似。本站此前对 Claude Code 桌面版负责人 Felix 的访谈也指向同一方向：先把目标定到「不合理」，再逼模型当真交付——目标与验收，比堆提示词更关键。
让 Agent 自己证明做完了
成熟团队靠 CI、测试与审查管质量，而不是经理逐行读代码。管理 Coding Agent 同理：
– 自验证优先：提供测试套件、构建、Linter；UI 任务可让 Agent 开浏览器自检。在 CLAUDE.md 写清测试命令，用 `/goal`、Stop Hook、独立 `/code-review` 子 Agent，把「看起来完成」卡在真正完成之前。 – 只补仓库外信息：说明为何重要、约束是什么、如何算成功；少重复模型能自己读到的结构。 – 纠错沉淀：同一问题纠两次以上，写入 CLAUDE.md 或封装为 Skill；并定期清理失效规则，避免指令文件变成新负担。 – 能力上来就少微观管理：不可妥协的用 Hooks / Deny Rules 强制；一般偏好留给 Agent。不断加「think harder」类规则，往往只是把微观管理搬到 Agent 上。
可委派任务，不可委派判断
复杂任务先走 Plan Mode，必要时用第二个会话审查计划；`/batch` 可拆成 5–30 个独立任务并行，但人要卡边界，避免接口冲突。方向偏了尽早纠偏，连续两次仍失败就清会话重写提示，比在烂上下文里追加指令更省 Token。
Addy 的关键案例：Agent 研究竞品差距并交出约 600 行、测试全绿的 PR，他差点合并——却发现对用户价值有限、徒增复杂度。能跑通 ≠ 值得上线。 风格与常规修复可交给 Agent；产品取舍、安全合规、最终上线必须由人拍板。审查单位也应缩到人能真正理解的规模。
多 Agent 并行还会碰到「编排税」：他常同时开四五个后台 Agent，注意力很快成为瓶颈。扩展的应是自动验证与通知，而不是人工盯进度的人数。指标也别只看生成行数或 PR 数，应看交付周期、返工与回滚——否则生产力只是从编码挪到了审查队列。这与本站介绍的 SwarmEvolve 多 Agent 进化搜索 同一提醒：规模 alone 不够，协作与验收机制才决定有效产出。
管理 Agent ≠ 管理人
Agent 试错成本低，可多版本并行对比；但跨会话经验依赖可保存的笔记与团队知识库，不能替代人的长期判断。模型也更易「顺着做」，配合「认知让渡」风险，应主动让 Agent 反驳你的结论。初级工程师的基本功机会，以及团队信任，仍不可被 Agent 编排挤掉。
Addy 的结论并不是「人人去做工程经理」，而是：Staff 级工程师本就在做约束、设计与验收；Coding Agent 只是把这类能力推到更多人面前。想榨干 Coding Agent，先学会管理它们——不必换岗位。
常见问题
Q：同时开很多 Coding Agent 就能线性提速吗？ A：不一定。并行省的是机器时间，人的协调、审查与上下文切换会形成「编排税」，容易把瓶颈挪到 PR 排队。
Q：测试全绿是不是就可以合并？ A：不够。自动化验证管的是正确性，产品是否值得做、安全与合规边界，仍须人工判断。
Q：CLAUDE.md 是不是规则越多越好？ A：不是。应沉淀可复用的验证命令与易错点，并定期清理失效指令，避免微观管理拖累 Agent。
相关文章
