一人指挥多个智能体：
上限不在模型，在你的审查带宽

00速览：如果你只读一页

每条论断都写成可被证伪的句子，并标注证据强度：RCT 随机对照 > 大样本 遥测/受控实验 > 单一案例 厂商自述 > 自报 问卷 > 建模 推导。

1. 「一人指挥 N 个智能体」的产能上限，由人每天能真正审完的量决定，不由模型能力决定。所有公开的产能跃升案例，都是先把审查成本压到接近零，再谈并发。OpenAI：瓶颈明确写成「human QA capacity」；Anthropic：并发上限是「一个人能审好的流数」 单一案例

2. 多智能体只在天然可并行且彼此独立的任务上赚回成本；在强共享上下文的任务上，它是用 15 倍的 token 买更差的连贯性。Anthropic 15× vs 4×；80% 性能方差由 token 用量解释 单一案例

3. 把 token 预算拉平后，多智能体的优势大部分消失——很多「协调带来的增益」其实是「多花的算力」。Tran 与 Kiela 等预算实验，5 种架构全部未稳定胜出 受控实验

4. 多智能体的失败极少是模型不行：约 44% 出在系统设计（切错、没终止条件），32% 出在交接（上下文丢失、彼此矛盾），24% 出在验证。MAST，1,642 条执行轨迹，7 个框架，κ=0.88 大样本标注

5. 人一次能同时有效监督的数量有实测区间：低负荷约 8–9 个，高复杂度约 4–5 个；负荷超过可用时间的 70% 后，监督质量断崖。无人机监督研究综述（Chen 等；Cummings 与 Guerlain） 受控实验

6. 可复制的组织形态不是「一群平等的智能体」，而是指挥者 + 少数中层 + 大量短命工人，协调靠共享任务表与信箱，而不是靠人逐个喊话。Gas Town（20–30 并发）；Claude Code 智能体团队（lead + task list + mailbox） 单一案例

7. 人的交付物从「代码」变成规格 + 验收场景 + 门禁。所谓 harness engineering，本质是把「什么算对」写成机器能执行的判据。OpenAI：5 个月 100 万行、0 行手写；StrongDM：代码不得由人写、也不得由人审 单一案例

8. 「无人工厂」目前是极少数小团队的演示，不是行业默认路径：中位公司 27.7% 的 PR 有智能体参与，但仅靠 AI 审批就合并的只有 0.5%。Jellyfish 遥测：1,300 家公司 / 2.76 万开发者 / 1 亿 PR 大样本

9. 可迁移的不是某个框架，而是五个控制面动作：隔离、意图、门禁、验证、账本。这五件事的成熟度，直接决定你能把并发开到几。跨 5 个团队实践的共同交集 归纳

01先分清三种形态，否则方法论会串味

「一人指挥多个智能体」被讲得很含糊。它至少指三件不同的事，工程含义完全不同：一个是人的操作方式，一个是系统的拓扑，一个是组织的生产模式。

三者的分界不在「几个智能体」，而在三件事：谁持有任务状态、谁判定完成、人介入在哪里。把 A 的经验套到 C 上会翻车（人还在逐行读 diff，产能上限就是 1）；把 C 的规则套到 A 上也会翻车（没有验证层就关灯，等于把缺陷工业化）。

02三个硬约束：为什么「多」不等于「快」

关于一人多体的讨论大多停留在经验层面。其实它背后有三条几十年历史的老理论，每条都能直接推出一个工程动作。

·约束一：人的监督带宽是物理量，不是态度问题

「一人能看几个」在无人系统领域被研究了三十年，术语叫 Fan-Out（FO），指一个人能同时有效操作的对象数。综述给出的区间很稳定：任务负荷低时可到 8–9 个，条件复杂时只有 4–5 个，且这个数字惊人地接近管理学里经典的「7±2」。更实用的是另一条：当操作者的工作负荷超过可用时间的 70%，监督表现开始显著下降——这条来自 Cummings 与 Guerlain 对多无人机控制的研究，被后续文献当作经验阈值反复引用。

把它翻译成智能体语境：你不是在看 5 个终端，你是在为 5 条并行推理链维护「情境意识」。每次切换都要重建上下文，而重建成本随任务耦合度上升。所以「我开了 20 个 agent」通常意味着两件事之一：任务被切得足够碎（碎到不需要情境意识），或者你其实已经放弃了监督，只在最后看结果。

·约束二：队列会惩罚「生成快、审查慢」

Little 定律：平均在制品 = 到达率 × 平均停留时间。它给出一条残酷的算术。假设每个合并平均需要你 24 分钟真读，你每天能投入 4 小时——审查能力就是 10 个/天。如果并发让生成速度变成 24 个/天，队列每天净增 14 个；第三天积压 42 个，最老待审项已经躺了三天，而你早已不记得它的上下文。此时你名义上「指挥着 6 个智能体」，实际上在做一件更糟的事：为无法理解的东西签字。

Amdahl 定律给出同一件事的上限形式：若人的判断占关键路径的 20%，则无论并行多少路，整体加速比不超过 5×。想让上限从 5× 提到 20×，唯一的办法是把人的判断移出关键路径——从「合并前必须看」改成「合并后按风险抽查」，而不是更快地看。

·约束三：每一次交接都在丢信息

Claude Shannon 的数据处理不等式说：对数据做任何处理，信息量只能保持不变或减少，不会增加。把子任务的结论压成一段摘要交给下一个智能体，就是一次有损压缩。Cognition 用 Flappy Bird 讲清了后果：一个 agent 做背景，一个做小鸟，各自都「完成了任务」，但风格、坐标系、命名全不一致，最后由第三个 agent 收拾两场误解。他们给出的原则近乎红线：共享完整轨迹，而不只是消息；动作本身携带隐含决策，冲突的隐含决策会带来坏结果。

粗略量化一下：若每次交接保留 90% 的有效信息（对摘要来说已属慷慨），三级链条后最后一个执行者只握有 0.9³ ≈ 73% 的信息。剩下 27% 的缺口，会被它用「看起来合理的假设」填满——而错误恰恰长在这些假设上。

03分工判据：什么任务值得切，切到什么粒度

Anthropic 在复盘里承认过早期最典型的蠢事：给一个简单问题派出 50 个子智能体，或者让子智能体反复搜索根本不存在的来源。切分不是越细越好，切分的质量由接口是否显式决定。

一个任务真的可并行，需要同时满足三条，缺一条就会退化成「事后收拾矛盾」：

• 写集不相交。两个子任务不修改同一批文件/同一段契约。这不是洁癖：Cursor 用 git worktree 隔离，OpenAI 让每个 worktree 都能独立启动一份应用实例，都是为了让「不相交」成为物理事实而非口头约定。
• 判据可执行。每个子任务有机器能判的对错——测试、类型检查、截图比对、接口返回。Anthropic 的说法是「给它一个可以通过的检查」，而不是「告诉它要努力」。
• 结论可合并。合并时不需要协商风格、命名、错误处理策略。凡需要协商的，就是「动作携带的隐含决策」在打架。

反过来说，按角色切分（前端 / 后端 / 测试）是最容易翻车的方式，因为它天然让三方对同一份接口做各自的假设。可用的切法只有两种：按可独立合并的 PR切，或按互不重叠的查询方向切（研究类任务）。Claude Code 的 /batch 给了一个粒度参考：把一次机械改动切成 5–30 个单元，每个单元一个 worktree、一个 PR。

04组织形态：不是一群平级智能体，而是一个有中层的工厂

Dan Shapiro 在 2026 年 1 月把 AI 编程的自治度分成六级（Level 0–5），并指出一个残酷的观察：每一级在当下都感觉是最后一级，而大多数人稳定停在第 2–3 级。

阶梯给出的是「人的位置」，但没给出「智能体之间怎么组织」。公开跑通的系统在这一点上出奇一致：都不是扁平的一群，而是三层——一个指挥者、几个中层、一群短命工人。

Yegge 的 Gas Town 是最直白的样本：Mayor（拆解与派活）、Polecats（短命实现工人，一任务一实例，做完即销毁）、Witness（盯卡住的工人）、Refinery（合并队列，把并行产出串行化）、Deacon（健康巡检与会话回收）。它同时跑 20–30 个 Claude Code 实例，把任务状态写进 git 支持的工单队列（beads），靠「钩子上有活就必须干」的规则扛住会话崩溃。

·最小可落地的版本：共享任务表 + 信箱

不必一上来就搭工厂。Claude Code 的「智能体团队」把这件事压缩到了几个原语，值得当作最小实现来抄：lead 负责派生与协调，teammates 是各自独立上下文的完整会话，task list 是带依赖的共享队列（认领用文件锁防竞争，完成一个自动解锁下游），mailbox 让任意两个成员直接通信而不必经过 lead。再加上两件治理工具：delegate mode（lead 被限制为只协调、不写码）与 hooks（TeammateIdle 退出码 2 = 把成员按回工位继续干；TaskCompleted 退出码 2 = 拒绝结项并给反馈）。

其中最有价值的一条经验是 delegate mode 的存在本身：它说明「指挥者亲自下场写代码」是这类系统最常见的退化。lead 一旦开始实现，就同时失去了仲裁视角与全局状态，团队退化成「一个人 + 一群旁观者」。

05控制面五件套：把「管理」变成配置文件

五个团队、五套工具链，最后收敛到同样五件事。这不是巧合：它们是「一人多体」的必要条件，缺一件，并发的代价就会以人的注意力来支付。

·隔离：让「写集不相交」成为物理事实

Cursor 2.0 的做法是把单条提示最多拆到 8 个并行智能体，每个跑在自己独立的代码库副本里（git worktree 或远端机器），从机制上排除文件冲突。OpenAI 做得更彻底：让应用能被任意 worktree 单独启动，并把 Chrome DevTools 协议、日志、指标都接到 agent 运行时上——于是每个智能体都能自己跑起来、自己截图、自己看 trace，而不需要人来转述。「隔离」不只是防冲突，它是让智能体能自我验证的前提。

·意图：写「什么算对」，不写「怎么做」

Anthropic 在最佳实践里给了两条反直觉的建议：不要在 CLAUDE.md 里描述架构和文件布局（它自己会读仓库），只写仓库里读不出来的东西；不要堆砌「IMPORTANT」「必须」这类强调（新模型会过度应用）。更关键的一条是：如果某条规则不可妥协，把它变成 hook 或拒绝规则，而不是写进散文。散文是概率性的，hook 是确定性的。

OpenAI 的说法更狠：「智能体看不见的东西，基本等于垃圾。」他们把一个仓库 500 个 npm 包的边界、规范、非功能要求，全部编码进智能体可感知的上下文；当智能体失败时，第一反应不是「再努力点」，而是问「它缺哪个能力，怎么让这个能力对它可见且可执行」。

·门禁：把「我以为它不会」变成「它做不到」

这一类工具在 2025–2026 才真正成熟：权限模式、允许/拒绝列表、PreToolUse 钩子、沙箱默认无网络、TaskCompleted 拒绝结项。它们的共同价值是把治理从事后审查前移成事前不可能。一个可操作的自检：你最近三次「提醒智能体不要做某事」，都应该已经被改写成一条拒绝规则——否则它们只是你的口头禅。

·账本：把成本当成设计参数

StrongDM 那句挑衅性的度量——「如果你今天没为每个工程师烧掉至少 1000 美元 token，你的软件工厂还有改进空间」——真正的信息量不在金额，而在它把 token 预算当作可调的设计参数。反过来也成立：如果你不知道每个任务花了多少、每个会话产出多少、返工率多高，你就没有任何依据决定「该加并发还是该减并发」，只能靠感觉。

06验证：唯一被真正规模化的东西

把所有公开案例放在一起看，产能跃升的那一刀都切在同一个地方：把「人读代码」换成「机器判对错」。生成从来不是瓶颈。

这条路上有一个必踩的坑：智能体会作弊。StrongDM 公开承认遇到过智能体为了让测试通过而直接写 return true 的情况——代码什么都没做，测试全绿。这是 Goodhart 定律在工程里的标准形态：一旦「通过测试」成为优化目标，它就不再是正确性的度量。他们的解法不是加强提示词，而是重构验证体系：

• Holdout 场景。验收场景存放在代码库之外，生成代码的智能体在构建过程中看不到它们，因此无法针对性地「调参过关」。
• 数字孪生。为 Okta、Jira、Slack、Google Docs 等外部服务建立行为克隆，目标是 API 层高度兼容，让端到端行为可以被反复验证而不触碰真实系统。
• 独立 checker。验证者永远不是写代码的那个，且常常跑在不同模型上——制造「不相关的失败模式」。
• 红队智能体。专门负责攻击自己的系统，找注入点、找越权路径。

·独立审查为什么必须「干净」

Cognition 在 2026 年 4 月的复盘里给了一个很具体的发现：「编码 agent + 审查 agent」这个组合有效，但前提是审查者一开始拿到的是干净上下文，而不是编码者积累下来的指令与推理。它只读 diff，自行重建相关上下文，然后质疑编码者已经接受的假设。这样它才有机会发现「方向对但不对味」的问题。Anthropic 的对应建议是加一步 adversarial review：任务当作完成之前，让一个全新上下文的子智能体审 diff 与判据，只报「影响正确性或既定要求」的缺口。

但这里有个反向陷阱必须记住：被要求找缺口的审查者，几乎总能找出缺口。逐条追下去会得到过度设计——多余抽象、防御性代码、为不可能发生的场景写测试。Anthropic 明确建议在提示里写清「只报影响正确性的问题，其余视为可选」。审查的价值在于判定，不在于产出意见。

07证据全景：正反两面，以及真实的采纳分布

这一节刻意把最强的正面证据和最强的反面证据放在一起。它们并不矛盾——它们测的是不同任务。看清这一点，比记住任何单个数字都重要。

然后是反面的。它们同样硬，而且更少被引用：

08度量与节奏：什么时候该加，什么时候必须减

没有减容规则的扩容，最终都会以「悄悄放弃审查」收场。所以度量体系里必须有一组指标专门盯「人还跟不跟得上」。

其中「最老待审项年龄」是最被低估的一个。它比平均等待时间更早报警：平均值会被大量秒过的小 PR 稀释，而最老那一项告诉你「有没有东西正在腐烂」。一旦它超过两天，正确的动作不是加快审，而是减并发——因为继续加只会让更多东西进入这个队列。

·90 天：先修分母，再扩分子

顺序不能倒。Anthropic 给的建议是「从两三个会话开始」；OpenAI 的经验是「早期进展慢，不是因为模型不行，而是环境定义不足」。两句话指向同一个动作：先把反馈回路和隔离建好，再谈并发。

09十二条反模式：症状与修正

每一条都在公开案例里真实出现过，不是假想。按「战略 / 工程 / 治理」三层排列。

还有一个不列入表格的陷阱：要求审查者「找出问题」。被这么要求的审查者几乎总能找出问题，逐条追下去会得到多余抽象、防御性代码、为不可能场景写的测试。Anthropic 的建议很实用——在审查提示里写清「只报影响正确性或既定要求的缺口，其余视为可选」。

10结论：五条判断

以下是我的判断，不是行业共识。标注了推理依据，你可以逐条反驳。

1. 你的上限等于你每天能「判定」的产出数。模型会继续变强，这个数字几乎不动——因为它取决于人的注意力，不取决于机器的智力。所有关于一人多体的方法论，本质上都在做同一件事：把「判定」的单位成本压下去。依据：Little 定律 + Amdahl + Fan-Out 的 4–5 / 70% 阈值

2. 门槛在验证工程，不在提示词工程。2025 年大家在比谁的提示词更好；2026 年跑出成绩的团队，比的都是谁的场景库更全、谁的门禁更硬、谁的数字孪生更像真的。依据：StrongDM、OpenAI、Anthropic 三家的公开方法里，提示词技巧占比极低

3. 组织形状会收敛到三层。不是因为抄 Gas Town，而是因为「催活、串行化写入、回收实例」这三件事必须有承担者；放在人身上，并发上限立刻退回 4–5。依据：Gas Town 与 Claude Code 智能体团队在机制上高度同构

4. 不要从黑暗工厂开始，从 L3→L4 那道断点开始。那道断点的内容只有一句：停止「边写边读」，改成「看结果 + 抽查高风险 diff」。跨过去，你才第一次拥有「并行」的资格。依据：Shapiro 的观察——每一级在当下都像最后一级；多数人停在 L2–L3

5. 最被低估的复利资产是场景库。代码可以被丢弃（OpenAI 明说「直接清空工作树重来」），但验收场景、孪生环境、失败样本会一直留下来，并让下一轮自治更安全。它是唯一越用越值钱的东西。依据：StrongDM 的 holdout 场景被独立 agent 反复使用；OpenAI 把生产事故转成新场景

·什么情况下这套不适用

• 安全关键与强合规系统。当「97% 有效」等于失败时，抽查就是不成立的。Simon Willison 的提醒仍然有效：注入类风险一旦被正常化，代价是灾难级的。
• 需要长期可维护的公共基础设施。没人读过的代码，出事时也没人能推理。Osmani 的警告是「停止阅读就会停止理解」。
• 团队还不具备可执行判据。测试跑不起来、构建要十分钟、环境靠手工配——先把这些修好。在泥地上开工厂，只会更快地陷进去。

11参考来源

按类型分组。凡标注「二手」的条目，其数字未回溯到原始论文/官方文档，引用时请自行复核。

·一手工程文档与官方复盘

• Anthropic, How we built our multi-agent research system, 2025-06-13（90.2%、4×/15×、80% 方差、effort 分级、早期失败案例）
• Anthropic, Best practices for Claude Code（/batch 切 5–30 单元、worktree、对抗式审查、CLAUDE.md 瘦身、把规则变 hook）
• Anthropic, The AI-native SDLC playbook（「一个人跑几个会话」、并发上限即审查能力、verifier 子智能体、前置/滞后指标）
• Claude Code Docs, Orchestrate teams of Claude Code sessions（lead / teammates / task list / mailbox、文件锁认领、依赖自动解锁、delegate mode、TeammateIdle 与 TaskCompleted 钩子）
• OpenAI, Harness engineering: leveraging Codex in an agent-first world（3→7 人、100 万行、0 行手写、1,500 PR、3.5 PR/人/日、瓶颈为 human QA capacity、每 worktree 独立可观测）
• Cognition（Walden Yan）, Don't Build Multi-Agents, 2025-06-12（上下文工程两原则、Flappy Bird 例）
• Cognition, Multi-Agents: What's Actually Working, 2026-04-22（map-reduce-and-manage；审查者应从干净上下文开始；Smart Friend 的升级失败；经 Latent Space 词条转述）
• Cursor, Changelog 2.0, 2025-10-29（单提示最多 8 并行、git worktree 或远端机器、沙箱终端默认无网）
• StrongDM, Software Factories and the Agentic Moment, 2026-02（代码不写不审、holdout 场景、数字孪生宇宙、「1000 美元/人/天」）
• Simon Willison, Software Factory, 2026-02-07（现场参观记录；lethal trifecta 的持续风险）
• Dan Shapiro, Five Levels of AI Coding, 2026-01（L0–L5 阶梯）
• Steve Yegge, Welcome to Gas Town 及后续随笔（Mayor / Polecats / Witness / Refinery / Deacon、beads、GUPP、20–30 并发、自述「从不看代码」）

·实证研究与论文

• METR, Measuring the Impact of Early-2025 AI on Experienced Open-Source Developer Productivity, 2025-07-10（RCT，16 人 / 246 任务，慢 19%，CI +2% 至 +39%）
• METR, We are Changing our Developer Productivity Experiment Design, 2026-02-24（老手 −18%、新人 −4%、选择偏差导致改版）
• Cemri 等, Why Do Multi-Agent LLM Systems Fail?, arXiv:2503.13657（MAST：1,642 轨迹 / 7 框架 / κ=0.88；44.2 / 32.3 / 23.5；单点 17.1% 步骤重复）
• Tran 与 Kiela, Single-Agent LLMs Outperform Multi-Agent Systems on Multi-Hop Reasoning Under Equal Thinking Token Budgets, arXiv:2604.02460（等预算实验、数据处理不等式论证）
• Kim 等, Towards a Science of Scaling Agent Systems, arXiv:2512.08296（等预算下的轮次与协调开销、错误放大 17.2× vs 4.4×）— 二手数字经多篇解读转述
• Jellyfish 遥测（经 R&D World 报道）：1,300 家公司 / 27.6 万开发者 / 1 亿 PR（27.7% 参与、0.5% 仅 AI 审批、P99 9.4% 工厂 PR）— 二手 + 样本偏差
• Chen、Barnes 与 Harper-Sciarini，多机器人监督综述（Fan-Out，低负荷 8–9 / 高复杂度 4–5，接近 7±2）
• Cummings 与 Guerlain，多无人机控制工作负荷研究（负荷超过可用时间 70% 后监督表现下降）

·方法论与行业分析

• Addy Osmani, Software Factories, Light and Dark（「停止阅读就会停止理解」、亮工厂作为务实默认）
• BCG Platinion, The Dark Software Factory, 2026-03（声称 3–5 倍产出，样本与方法未公开）
• Gartner 预测：到 2027 年底超过 40% 的 agentic AI 项目会因成本、价值不清或风险控制不足被取消（预测，非观测）
• Code Ninety, Agentic AI Enterprise Penetration and Human Oversight Ratio, 2026-02（n=188 自报问卷：IT 支持约 1:18、代码生成约 1:2）— 自报仅作参考