--- title: 260307-你的 AI Coding Agents 需要一个管理者 description: 在不久的将来，高杠杆开发者会更像异步优先的管理者，负责并行编排多位 AI Coding Agents。那些让人成为优秀技术负责人或管理者的能力，也会直接转化为新的 AI 协作能力。 author: Addy Osmani source: https://addyosmani.com/blog/coding-agents-manager/ date: '2026-03-07' category: 04-engineering-practices tags: - AI编码 - 代理编排 - 工程管理 - 开发效率 - 异步协作 --- # 你的 AI Coding Agents 需要一个管理者 **作者：Addy Osmani** **原文：[查看原文](https://addyosmani.com/blog/coding-agents-manager/)** **那些让人成为优秀技术负责人或管理者的能力，正在直接转化为新的 AI 协作能力。** 一旦你开始并行运行多个 Coding Agents，你做的就不再只是“补上下文、改提示词”，而是在做更明确的编排工作：讲清目标、拆分任务、建立验证循环，并处理异步沟通。随着[编排](https://addyosmani.com/blog/future-agentic-coding/)成为主流，工作的形态也在改变。 在不久的将来，我认为最高杠杆的开发者会更像**异步优先的管理者**，手里同时跑着一小队并行的 AI Coding Agents。它们已经可以在后台、隔离环境里完成有意义的工作，再把结果作为可审查的产物交回来——通常就是一个 PR。我们当然仍然需要质量把关，但真正的瓶颈已经转向“这件事值不值得做”以及“我能不能高效地编排多个智能体同时推进”。 我们正在看到预示这一未来的[工作流](https://code.claude.com/docs/en/common-workflows)。Claude Code 创建者 Boris Cherny 最近的一个[帖子](https://twitter-thread.com/t/2007179832300581177)走红了，因为它让这种转变感觉具体：他在终端标签页中本地运行五个 Claude Code 会话，在浏览器中再运行五到十个，甚至从手机上启动会话以便稍后查看。这就是编排。 与此同时，也有一些工程师从更审慎的角度记录这种并行代理工作流。Simon Willison 的[观点](https://simonwillison.net/2025/Oct/5/parallel-coding-agents/)我很认同：真正的瓶颈不是生成代码，而是审查代码。他仍然认为并行启动任务很有价值，但前提是你得诚实面对自己的注意力极限，并挑选那些不会把自己拖进认知过载的任务。我自己的体验也类似：价值是真实的，但前提是你把它当作管理问题，而不是魔法。 这就是思维方式的转变：你不再与单个代理配对。你在运行一个小团队。 这就是为什么使某人成为优秀技术负责人、工程经理或工程领导者的技能突然直接转化为"擅长 AI 编码"。因为大规模的 AI 编码不再是一个提示问题，而是变成了一个管理问题。 ## 新工作流的心智模型 我认为有两种模式并行运行。 第一种是**本地、高接触的会话，你保持人在回路中**。这些用于架构决策、棘手的重构、产品细微差别、模糊的需求，以及任何品味和判断占主导地位的事情。你与代理配对，实时纠正方向，并做出需要代理没有的上下文的决策。 第二种是**异步运行的云或后台会话**。这些用于专注、有界的任务：直接的功能、具有清晰模式的迁移、测试生成、文档更新、依赖项升级、小错误修复和有针对性的重构。你启动它们，切换到其他事情，然后回来审查输出。 这种划分清晰地映射到现代工具的演变方式。云代理（想想 GitHub Copilot Agent、Claude Web、Codex、Jules 等）被明确定位为可并行化、沙盒化的任务，可以编写代码、运行命令并提出更改以供审查。 GitHub 的 Copilot Coding Agent 也是类似定位——一个异步后台智能体，会先打开草稿 PR，在后台推进任务，完成后再请求审查，你可以在 PR 中继续评论并让它迭代。平台也在朝着“多智能体任务控制台”的方向演进，而不再只是一个单点助手。GitHub 甚至预览了 “Agent HQ”，作为协调多家第三方 Coding Agents 的统一控制平面，包括在同一任务上并行运行它们并比较输出。 所以问题变得不再是"哪个模型写出最好的代码？"而是"我能像运行一个高绩效团队一样运行这个吗？" 这就是管理技能出现的地方。 ## 为什么管理技能让你成为更好的 AI 编码者 _我已经深入写过[有效的管理技能](https://leanpub.com/effective-software-engineering-management)_ 当你管理人类时，你会艰难地学到输出质量是在上游塑造的。模糊性、模糊的所有权、缺失的完成定义和缺乏反馈循环会造成混乱。当你的"团队"是一组快速的非人类代理时，情况也是如此——甚至可能更是如此。 Anthropic 的 Claude Code 最佳实践指南明确指出：前期的具体性实质上提高了成功率并减少了方向纠正。这是管理语言，即使它是为工具编写的。 以下是最直接转移的四项技能。 ### 清晰的任务范围界定：写一份简报，而不是一种感觉 如果模糊性会扼杀代理的有效性，那么你的工作就是将想法形状的思想转化为能够在实施中存活的简报。这正是优秀管理者所做的：将意图转化为可执行的东西。 一份实用的代理简报涵盖：结果（完成时应该是什么样子）、上下文（这在代码库中的位置以及存在哪些模式）、约束（性能、安全性、API 形状、依赖规则、样式约定）、非目标（我们明确不做什么）、验收标准（具体检查，如测试通过或端点以某种方式行为）、集成说明（哪些文件是禁区以及接缝应该在哪里），以及验证计划（我们如何知道它有效）。 这是获得干净 PR 和获得你无法信任的千行混乱之间的区别。 两种策略使这变得更容易。首先，将代理指向现有模式——Anthropic 的指南明确建议提及你希望代理遵循或更新的文件，这样它就锚定在真实的约定上，而不是发明自己的。 其次，把持久规则放在智能体总能找到的地方。现在比较常见的做法，是通过 `AGENTS.md` 明确测试要求、lint 规则、依赖策略和文档约定，让执行预期保持一致。 ### 委派：决定完全交出什么与什么需要你的判断 代理的一个令人惊讶的陷阱是过度委派实际上是人类工作的部分：产品意图、API 设计权衡、架构边界和长期维护决策。 OpenAI 的"AI 原生工程团队"指南将其框架为跨软件开发生命周期的三部分划分：委派、审查、拥有。即使在他们乐观的观点中，工程师也保留最终决策和签署的所有权，特别是对于模糊的问题。 这清晰地映射到编排上。有些工作你可以完全委派——具有清晰规范的机械实施、样板重构、具有强审查的测试生成、文档更新和低风险的维护杂务。其他工作你委派但通过检查点保持在循环中——任何涉及共享接口的事情、任何可能造成合并冲突的事情、任何具有棘手产品边缘情况的事情、任何涉及数据迁移的事情。还有一些工作你根本不委派，或者只委派以探索选项——系统架构和新抽象、需要品味的跨领域重构、产品决策和"我们应该构建这个吗？"的决策，以及安全关键或隐私敏感的设计决策。 这与在团队中分配工作是同样的能力：你不断决定谁拥有什么、多少自主权是安全的，以及在工作固化之前你想要在哪里设置检查点。 ### 验证循环有助于及早发现问题 当你管理人时，你会了解到失去时间的最快方法是太晚审查低质量的工作。你想要早期反馈循环和质量门。代理也是一样的——除了它们可以高速生成低质量的工作。 验证循环是解锁，最好的工具制造商正在将它们融入他们的指导中。Anthropic 的[最佳实践](https://www.anthropic.com/engineering/claude-code-best-practices)明确建议运行多个 Claude 实例，其中一个编写代码，另一个通过审查和测试进行验证，将其视为具有关注点分离的两人工作流。OpenAI 的 Codex 定位也明确关于工具使用：运行命令、运行测试、迭代到通过状态，然后提出 PR。 实践中的验证循环是什么样子：要求代理运行测试套件（或范围子集）并在其最终消息中包含输出。要求 lint 和类型检查通过受影响的区域。要求代理为行为更改添加或修改测试。要求在最后提供结构化的"PR 包"——更改摘要、为什么采用这种方法、涉及的文件、测试计划加结果，以及风险或后续行动。 如果你想更进一步，使用双代理模式：代理 A 实施，代理 B 审查正确性、样式、边缘情况和遗漏的测试，然后代理 A（或新的代理 C）应用审查反馈并重新运行验证。这不是理论上的——Anthropic 实际上建议将其作为工作流升级。 这也是管理本能重要的地方：你不仅仅是检查代码是否编译。你在检查它是否符合约定、是否可维护，以及是否符合意图。 ### 异步签到：像对待下属一样对待代理 如果你同时运行十个并行会话，就不可能靠逐个滚动日志去理解发生了什么。你需要的是轻量、稳定、可复用的状态汇报机制——这本质上就是一套面向智能体的异步管理手册。 设置签到节奏："如果你在 15 分钟内没有取得重大进展，停止并报告阻碍。"以可预测的格式要求状态：什么改变了？接下来是什么？风险或阻碍是什么？你需要我做什么？ 这听起来很小，但这是你如何在不持续保姆的情况下防止并行工作脱轨的方法。如果你想要一个具体的类比，管理代理看起来很像管理跨时区的分布式团队。你预先加载清晰度，你依赖书面更新，你为决策和解除阻碍保留实时注意力。 ## 困难的部分是真实的（它们是管理问题） ### 合并冲突快速倍增 并行代理接触相邻代码就像让五个工程师在同一个文件中没有协调。这不是工具故障；这是边界故障。修复方法正是你在人类团队中会做的：创建有意的任务边界、隔离工作并定义接口。 实际上，这通常意味着在隔离的工作目录或分支中运行代理。[Git worktrees](https://git-scm.com/docs/git-worktree) 是这里的一个干净模式——它们让你从同一个仓库一次检出多个分支，每个分支在自己的目录中。Claude Code 的文档明确建议使用 git worktrees 进行并行会话，这样实例就不会相互干扰，Anthropic 的最佳实践给出了使用 worktrees 加上"每个 worktree 一个终端标签页"作为操作模式的逐步说明。即使你使用云代理，你也想要相同的原则：单独的分支、小的 PR 和模块的清晰所有权。 我最喜欢的边界规则，借鉴自团队协调：一个代理拥有一个 PR，没有来自多个代理的大型 PR。如果两个代理可能接触相同的文件，重新设计任务划分。共享接口在第一个 PR（人类主导）中处理，然后代理在该接缝之上构建。 ### 品味和"我们应该构建这个吗？"成为真正的瓶颈 当构建变得便宜时，你开始构建一切。这感觉很有成效，直到你的产品变成一个功能的杂物抽屉。 这是转变中没有得到足够关注的部分：AI 不会消除对判断的需求；它提高了判断的价值。"我们应该吗？"开始比"我们能吗？"更重要。 这是伪装的管理技能：优先级排序、说不、定义成功、运行小实验和快速杀死坏主意。 如果你想将其操作化，从管理中借用两个概念。首先，WIP 限制：限制你一次允许多少活跃的代理流，这样你就不会淹没在审查中（Willison 指出的同样瓶颈）。其次，终止标准：在你开始构建之前定义什么会导致你停止追求一个功能。 ## 我喜欢什么（以及为什么这值得努力） "随时随地"的委派效果是真实的。当后台代理可以针对仓库工作并返回可审查的更改时，你从"稍后提交问题"转变为"现在开始构建想法"。 我目前的设置运行四到五个后台代理处理低到中等复杂度的工作，而我在本地保持人在回路中进行架构和细致的产品工作，跨越另外三到五个会话。从移动设备委派工作的能力改变了我的创意循环：从想法到实施草稿到审查到迭代。 当你有质量标准和流程时，这是非常令人满意的，因为你的创意循环收紧了。但只有当你把编排当作管理而不是魔法时，它才会保持令人满意。你必须对自己的多任务和上下文切换带宽保持现实。不是每个人都需要一次运行十到十五个代理。Boris 的工作流作为一个极端很有用，它展示了什么是可能的，而不是作为一个要求。 ## 编排的简单操作系统 如果你想要一个可重复的循环来练习： 像管理者一样规划——用结果、约束和验收标准写简报。像编排者一样执行——把任务分配给边界清晰的并行智能体。异步监控——通过轻量状态同步快速解除阻碍，避免并行工作失控。积极验证——跑测试、过 lint、整理结构化 PR 包，并在有价值时增加第二个智能体做复审。谨慎集成——按深思熟虑的顺序合并，并留意边界冲突。最后做复盘——更新你的 [AGENTS.md](https://developers.openai.com/codex/guides/agents-md/) 和检查清单，让下一轮运行从更好的约束条件出发。 对我们大多数人来说，最佳点看起来更接近少数后台代理做低到中等复杂度的工作，而你在架构和产品细微差别上保持人在回路中，对你能容忍多少上下文切换保持现实。 这就是编排。快速擅长它的方法是学习使某人在领导工程师方面有效的相同技能：清晰度、委派、反馈循环和异步沟通。 --- _我很高兴分享我已经与 O'Reilly 发布了一本新的 [AI 辅助工程书籍](https://beyond.addy.ie/)。如果感兴趣，书籍网站上有一些免费提示。_