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