Lecture 14 · 多智能体系统的架构——角色、通信拓扑、编排与自动设计 · Architectures of Multi-Agent Systems

对应 Maps to：CS486 课程描述的 “multi-agent collaboration”。第 12、13 讲的智能体是”对等”的：每个人回答同一个问题。这一讲研究分工：谁做什么、谁和谁说话、信息怎样传递、架构能不能自动设计。 依据说明：CS486 没有公开的日程或讲义。本讲依据角色化多智能体框架（CAMEL、MetaGPT、ChatDev、AutoGen）、工业界的工程报告（Anthropic 2025 年 6 月的多智能体研究系统、Cognition 2025 年 6 月的 Don’t Build Multi-Agents 及其 2026 年 4 月的后续）、受控的架构比较（Kim et al.，Towards a Science of Scaling Agent Systems，2025 年 12 月初版、2026 年 4 月第 3 版）、通信拓扑的研究（GPTSwarm、AgentPrune、MacNet）和自动设计（ADAS、AFlow、MaAS），以及第 10 讲介绍过的 MACI。§2–§6 的实验是本讲义自己设计的模拟，数字全部来自配套代码的实际输出。 配套代码 Code：code/lecture14/（只用标准库；每个脚本几秒钟） 预计阅读时间：3 小时（含运行代码）

0. 本讲导航 · How to read this lecture

0.1 学习目标 Learning goals

学完这一讲，你应该能够：

1. 说出几种基本的多智能体架构——单智能体、编排者–工人（中心化）、去中心化（群聊）、流水线、独立并行——以及角色化框架（MetaGPT、ChatDev、AutoGen）各自做了什么设计选择。
2. 解释上下文为什么是多智能体架构的核心资源：分工的收益（上下文隔离、并行）和代价（交接丢细节、隐含决策冲突、协调开销）都来自它。
3. 判断一个任务适不适合拆：可分解的并行任务、有隐含决策的任务、顺序任务各自需要什么样的架构；理解 Anthropic 和 Cognition 看似相反的结论为什么都对。
4. 解释错误放大、能力饱和（Kim et al.）的机制，并知道比较多智能体和单智能体时，单智能体也应该拿到同样的验证、重试和上下文管理。
5. 描述通信拓扑的优化和自动设计（GPTSwarm、AgentPrune、ADAS、AFlow、MaAS），并说出在小开发集上搜索架构的统计陷阱。

0.2 先修与本讲范围 Prerequisites & scope

0.3 本讲地图 Map

§1  从对等到分工：五种基本架构
§2  角色与流程：CAMEL、MetaGPT、ChatDev、AutoGen
§3  上下文是核心资源：隔离的收益、隐含决策的代价                       ← 代码 01
§4  交接与顺序任务：传话游戏                                          ← 代码 01
§5  验证、错误放大、能力饱和、计算量匹配                             ← 代码 02
§6  通信拓扑与自动设计：GPTSwarm、AgentPrune、MacNet、ADAS、AFlow、MaAS ← 代码 03
§7  MACI 的架构选择
§8  一张设计检查表
§9  现状与开放问题
§10–14  小结、常见误区、练习、延伸阅读、下一讲预告

1. 从对等到分工 · From peers to division of labor

第 12 讲的投票和第 13 讲的辩论里，每个智能体做同样的事。真实的多智能体系统大多是分工的。Kim et al.（2025）为受控比较总结了五种典型架构，本讲沿用它们（加上流水线）：

选架构，本质上是在回答三个问题：谁看到什么（上下文怎样分配），信息怎样传递（交接的形式和损失），谁来把关（验证放在哪里）。这一讲的实验把这三个问题分开来看。

2. 角色与流程 · Roles and procedures

2.1 角色扮演：CAMEL

CAMEL（Li et al.，NeurIPS 2023）让两个智能体扮演”用户”和”助手”，通过起始提示（inception prompting）设定角色和任务，然后让它们自主地对话、一步步完成任务。它的一个主要发现是角色对话里的典型失败：角色互换（助手开始给用户下指令）、重复的空洞回答、无限循环的对话——这些都是第 15 讲 MAST 失败分类里”系统设计问题”的早期例子。

2.2 标准作业流程：MetaGPT 与 ChatDev

MetaGPT（Hong et al.，ICLR 2024）把人类软件团队的标准作业流程（SOP）编码进提示：产品经理 → 架构师 → 项目经理 → 工程师 → QA 工程师，像流水线一样依次产出需求文档、系统设计、任务列表、代码、测试。两个关键的设计选择：

• 结构化的产物：每个角色输出的是格式固定的文档（需求文档、设计图、接口定义），而不是自由的聊天。他们的论点是：天真地把 LLM 串起来，会产生”级联的幻觉”——一个角色的错误被下一个角色当作事实继续发挥；结构化的产物让中间结果可以被检查。
• 共享的消息池：智能体把结构化消息发布到一个共享的池子里，按自己的角色订阅相关的消息，而不是一对一地传话。

MetaGPT 在 HumanEval 和 MBPP 上报告了 85.9% 和 87.7% 的 pass@1。

ChatDev（Qian et al.，ACL 2024）用”聊天链”（chat chain）把软件开发拆成设计、编码、测试等阶段，每个阶段由一对角色对话完成；“交流式去幻觉”（communicative dehallucination）让助手在不确定时先向对方要更具体的信息，而不是自己编。

从本讲的角度看，这两个框架做的是同一件事：控制交接的质量——用结构化的产物减少交接时的信息损失和”传话游戏”（§4）。

2.3 对话编程：AutoGen

AutoGen（Wu et al. 2023）提供”可对话的智能体”（conversable agents）——可以是 LLM、工具、人类或它们的组合——和”对话编程”：用智能体之间的对话模式（两人对话、群聊、嵌套对话）来写多智能体应用。它是一个框架，不规定架构；同一个框架里可以搭出中心化、去中心化或流水线的系统。这也意味着，框架本身不会告诉你哪种架构适合你的任务。

3. 上下文是核心资源 · Context is the key resource

3.1 两份看似相反的工程报告

2025 年 6 月，两份工程报告几乎同时发表：

• Anthropic，How we built our multi-agent research system：一个主导智能体（Claude Opus 4）规划研究、并行地派出多个子智能体（Claude Sonnet 4）各自搜索，再汇总。在内部的研究评测上，它比单智能体的 Claude Opus 4 高 90.2%。他们的分析：在 BrowseComp 上，token 用量单独解释了 80% 的性能差异（加上工具调用次数和模型选择，三个因素解释 95%）；多智能体系统用的 token 约是普通对话的 15 倍（单智能体约 4 倍）；并行化让复杂查询的研究时间最多缩短 90%。他们也明确说：需要所有智能体共享同一个上下文的领域，以及大多数编程任务（可以真正并行的部分比研究少），目前不适合多智能体。他们建议子智能体把结果存进外部系统、只把轻量的引用交回编排者，以避免多阶段处理中的信息丢失。
• Cognition（Walden Yan），Don’t Build Multi-Agents：两条”上下文工程”原则——共享上下文（子智能体应该看到完整的上下文，而不只是一个摘要：只传摘要像传话游戏）和行动携带隐含决策（并行的子智能体看不到彼此，会做出互相矛盾的决策：一个做出了某种风格的背景，另一个做出了不搭的角色，拼起来不能用）。所以他们反对”并行写手”式的架构，推荐单线程的、上下文连续的智能体。2026 年 4 月的后续文章说这些观察对并行写手仍然成立，但他们找到了一类有效的模式：几个智能体贡献智能，而写操作保持单线程。

两份报告并不矛盾：研究任务（广泛地搜索、彼此独立的子问题）适合拆；写代码、写一个连贯的产品（到处都是隐含决策）不适合并行地写。架构要和任务结构匹配——这也是 Kim et al. 受控比较的结论（§5）。

3.2 模拟世界

代码使用一个可以精确控制的模拟（mas_lab.py）：

• 任务：n 个子任务；“并行”（彼此独立，最后汇总）或”顺序”（第 i 步要用到前面所有步骤的结果）；可以有 D 个隐含决策（每个子任务都要用到，所有子任务的选择必须一致）。
• 上下文腐烂：一次调用做对一个子任务的概率 $\sigma(\text{skill} - \text{difficulty} - \text{rot} \times \text{上下文长度})$——上下文里堆的材料越多越容易出错（“迷失在中间”、上下文腐烂这类现象的抽象）。
• 交接：摘要以一定概率丢失关键细节；也可以传原始材料（不丢细节，但接收方的上下文变长）。
• 隐含决策：互相看不到的智能体各自做决策，以概率 prior 选”默认选项”（模型共同的偏好），否则随机。
• 成本：调用次数、token（每次调用读入的上下文之和）、延迟（关键路径上的调用轮数）。

这个模拟把真实系统简化到只剩这几个机制，所以它的作用是分离机制，而不是预测真实系统的数字。

3.3 可分解的任务：拆开的收益来自上下文隔离

代码 01 演示 1，并行、没有耦合的任务（每格：成功率 / 平均 token）：

几个要点：

• 子任务越多，拆开越值：n = 2 时单智能体和编排者–工人差不多；n = 16 时 0% vs 29%。在这个模型里原因只有一个：单智能体的上下文堆满了前面子任务的材料，工人的上下文是干净的。
• 单智能体自己压缩上下文就拿回了一部分（n = 8：29% → 45%）。这是 Cognition 的方向：上下文工程比智能体的个数更重要。
• 协调本身有代价：在这种完全独立的任务上，没有验证的编排者–工人反而不如独立的智能体（52% vs 64%）——编排多了摘要交接（可能丢细节）和汇总（可能出错），而它的好处（共享决策、验证）用不上。
• 群聊和单智能体一样会腐烂，token 却多得多：每个人都读每一条消息。
• 成本：在这个模型里，编排者–工人比单智能体更省 token，因为单智能体每次调用都要重读越来越长的上下文。真实的多智能体系统通常更贵（Anthropic：约 15 倍于普通对话），因为它们做了更多的工作（更广的搜索）；而提示缓存让”重读”在金钱上便宜，在注意力上并不便宜。比较成本时要说清楚用的是哪种口径。

3.4 隐含决策：拆分之前先把决策定下来

代码 01 演示 2：n = 8 的并行任务，每个子任务都要用到 2 个隐含决策（每个 4 个选项）：

各自做决策的工人几乎全部失败——8 个人在 2 个决策上都碰巧一致的概率很小。编排者把决策写进任务说明，就恢复到 49.3%（没有决策时是 51.7%）。这就是 Cognition 的”行动携带隐含决策”，以及它的工程解法：先把决策定下来、写下来，再并行。第 10 讲 MACI 的元规划器构建依赖图、把约束写进每个智能体的任务，是同一个思路。

一个有意思的细节：模型有很强的共同偏好时（prior = 0.99），独立的选择常常碰巧一致（独立智能体 55.8%）。第 12 讲里有害的”相关性”在这里成了帮手——多个相似的模型会做出相似的默认选择。但这不能指望：一旦任务需要非默认的选择，矛盾就回来了。

3.5 上下文腐烂有多严重，决定了拆分值不值

代码 01 演示 4（并行任务，n = 8）：

没有上下文腐烂时，单智能体最好之一，编排只剩代价。模型处理长上下文的能力越强，拆分越不值——这是一个会随模型进步而变化的工程判断，不是一条定律。

4. 交接与顺序任务：传话游戏 · Handoffs and sequential tasks

顺序任务的每一步都要用到前面的结果。代码 01 演示 3：

• 流水线的传话游戏：每一条早期的结果要被后面每一站重新转述一次，丢失的概率不断累积（n = 16：0.6%）。传原始材料的流水线不丢细节，但上下文一样变长，结果和单智能体完全相同——它就是一个被切成几段的单智能体。MetaGPT 的结构化产物，本质上是想让每一站的”转述”更可靠。
• 独立的智能体拿不到前一步的结果，完全失败。
• 编排者–工人仍然好于单智能体——这和我编写前的预想相反。编排者手里每一步的结果只被摘要一次、交给工人的上下文很短，和”单智能体 + 压缩上下文”是同一个道理。只有当状态很难被摘要时（丢失概率从 3% 提高到 15%），才反过来：编排者 16.7%、单智能体 29.1%。

Kim et al. 在顺序规划（PlanCraft）上看到所有多智能体变体都变差（−39% 到 −70%）。在这个模型里，要复现它，需要”状态难以摘要”这个条件；他们还固定了总的计算预算，多智能体的协调开销挤占了推理本身。哪个条件成立，取决于具体的任务。

5. 验证、错误放大、能力饱和 · Verification, error amplification, saturation

5.1 受控的比较

Kim et al.（Towards a Science of Scaling Agent Systems，Google Research / MIT / Google DeepMind）在第 3 版里用 260 个配置做了受控的比较：6 个智能体基准（BrowseComp-Plus、Finance-Agent、PlanCraft 等）、5 种架构、3 个模型家族，统一了工具、提示和计算预算。主要发现：

• 任务结构决定成败：相对于单智能体的变化从可分解的金融分析 +80.8% 到顺序规划 −70.0%。
• 错误放大：没有中心验证的独立架构把轨迹层面的错误放大 17.2 倍；中心编排把它控制在 4.4 倍——编排者是一个”验证瓶颈”。
• 能力饱和：单智能体的基线超过一定水平（约 45%）后，协调的收益递减甚至为负。
• 工具多的任务承受更大的多智能体开销。
• 他们的预测模型交叉验证 $R^2$ = 0.373（用任务相关的能力指标时 0.413），能为 87% 的留出配置选出最好的架构。

5.2 实验：错误放大取决于有没有人把关

代码 02 演示 1，在混合的任务上（一半并行、一半顺序，三分之一有隐含决策）：

（错误放大 = 任务失败率 ÷ 子任务单次出错率。）子任务的单次出错率差不多，任务层面的放大倍数却差很多：没有人把关的独立智能体 14.3×，验证 + 共享决策的编排者–工人 4.7×，方向和 Kim et al. 的 17.2× vs 4.4× 一致。中心节点的价值是当”验证瓶颈”：在错误传播之前把它挡住。

5.3 实验：能力饱和

代码 02 演示 2（并行任务，n = 6），模型能力提高时，多智能体相对于单智能体的变化：

协调的损失（摘要丢细节、汇总出错）是一个不随能力下降的固定成本；它要弥补的问题（长上下文里出错）随能力提高而变小。所以模型越强，编排越不划算，最后变成负的——和 Kim et al. 的”基线超过约 45% 后收益递减”方向一致；在这个模型里拐点的位置取决于协调损失有多大。完全独立的智能体在这种没有耦合的任务上一直更好（它没有协调损失），但在混合的任务上它最差（§5.2）。

5.4 计算量匹配：验证不是多智能体独有的

代码 02 演示 3（n = 8）：

给单智能体同样的验证和重试、再加上上下文压缩，它和编排者–工人只差 2.4 个点（顺序任务 1.4 个点）；多智能体剩下的主要优势是并行任务的延迟（4 轮 vs 17 轮）。这是第 12 讲 §7 的计算量匹配原则在架构上的版本：比较多智能体系统和单智能体时，单智能体也应该拿到同样的验证、重试和上下文管理——否则比的是”有没有验证”，而不是”有几个智能体”。

5.5 交接的质量决定了编排的上限

代码 02 演示 4（并行任务，n = 8）：摘要从不丢细节时，编排者–工人（验证）88.1%；丢失率 10% 时 38.3%，20% 时 14.7%——低于单智能体的 27.6%。改传原始材料不受丢失影响（78.4%），代价是编排者汇总时的上下文变长：摘要不丢细节时它反而更差（78.4% vs 88.1%）。Anthropic 建议子智能体把结果存进外部系统、只交回引用，本质上同时降低了丢失和汇总时的上下文长度。

6. 通信拓扑与自动设计 · Topology and automatic design

6.1 拓扑：谁和谁说话

• GPTSwarm（Zhuge et al.，ICML 2024）把 LLM 智能体描述成计算图：节点是处理数据或调用 LLM 的操作，边是信息流；图可以递归地组合成更大的图（智能体之间的层级协作）。它有两种自动优化：优化节点的提示（节点优化）和改变图的连接（边优化）。
• AgentPrune（Zhang et al.，ICLR 2025）指出多智能体管线里的通信冗余：很多消息对结果没有贡献，却消耗大量 token。它在时空消息传递图上一次性剪枝，在 6 个基准上用 5.6 美元的成本达到 43.7 美元的最好拓扑的水平，嵌入现有框架能减少 28.1%–72.8% 的 token，还能抵御两类智能体层面的对抗攻击。
• MacNet（Qian et al.，ICLR 2025）用有向无环图组织智能体，支持一千多个智能体的协作；它报告不规则的拓扑好于规则的拓扑，以及一个”协作扩展律”：性能随智能体数量呈 logistic 增长。

代码 01 的群聊（人人看到一切）是 AgentPrune 所说的冗余的极端：n = 8 时 token 是单智能体的近 7 倍，正确率没有任何提高。

6.2 自动设计

• ADAS（Hu et al.，ICLR 2025，Automated Design of Agentic Systems）：一个”元智能体”用代码写出新的智能体设计（因为代码是图灵完备的，原则上能表示任何提示、工具使用、工作流），在验证集上打分，存进一个不断增长的档案，再基于档案写下一个。它发现的智能体在 DROP 阅读理解上把 F1 提高 13.6 分、在 MGSM 数学上提高 14.4 个百分点，并且报告发现的设计能跨领域、跨模型迁移。验证集通常 128 道题（GPQA 32 道），测试集 800 道。
• AFlow（Zhang et al.，ICLR 2025）把工作流优化写成在代码表示的工作流上的搜索，用蒙特卡洛树搜索修改代码、积累经验；在 6 个数据集上比最好的基线平均高 5.7%，让小模型在某些任务上以 GPT-4o 4.55% 的美元成本超过 GPT-4o。数据按 1:4 分成验证集和测试集，再从验证集里挑出”分数方差大”的题。
• MaAS（Zhang et al.，ICML 2025）不找一个”万能”的系统，而是优化一个智能体超网络——架构的概率分布——按每个查询采样合适的架构；只需要现有系统 6%–45% 的推理成本，性能高 0.54%–16.89%。

6.3 实验：在小开发集上搜索架构

代码 03 用 mas_lab 的 28 种设计做一个”自动设计”的实验。因为是模拟，每种设计的真实成功率可以在 12000 个留出任务上精确估计（演示 1：最好的”编排者–工人，写明决策，传原始材料，验证 + 重试 2 次”83.9%，最简单的单智能体 53.0%、第 20 名，最差的独立智能体 25.7%）。然后模拟搜索：在 N 道题的开发集上试 K 种设计、选开发集分数最高的，重复 400 次（演示 2）：

小开发集上的搜索带着赢家的诅咒：32 道题、试遍 28 种设计时，选中设计的开发集分数平均比真实高 4.6 个点；试的设计越多，乐观偏差越大（32 道题：K = 4 时 +2.6，K = 28 时 +4.6）。这正是第 2 讲的”在测试集上反复调参”；ADAS、AFlow 都在留出的测试集上报告，这是必须的。

这里的搜索其实比真实的情况容易：每个任务用固定的随机数，所有设计面对同样的”运气”（第 2 讲的公共随机数），嵌套的设计（“重试 2 次”和”重试 1 次”）的差别几乎总是同号。练习 4 让每种设计用各自独立的随机数（像 LLM 每次调用都重新采样），在同一批重新抽取的开发集上比较，结果明显变差：128 道题、试遍 28 种设计时，选中真正最好的设计的概率从 78% 降到 46%，乐观偏差从 1.25 个点升到 4.18 个点。

另外三个结果都和我编写前的预想不一样：

• 按任务类型分别选设计没有收益（演示 3）：一刀切 83.9%，按类型分别选 83.7%。这个设计空间里有一个在三类任务上都接近最好的设计；分开选以后每一类的开发集只有 83–260 道题，噪声反而更大。按查询选择架构（MaAS）要有收益，需要不同类型的任务真的偏好不同的设计、而且每一类都有足够的数据。
• 成本让”最好”变成一条前沿（演示 4）：从”独立的智能体”（25.7%，11 token）到最准的设计（83.9%，38 token）共 7 种设计在帕累托前沿上；“单智能体加验证”（61 token）不在前沿上。报告”最好的设计”时应该同时报告成本。
• 设计在更强的模型上迁移得很好（演示 5）：skill 3.5 上的前三名在 skill 5.5 上仍是前三名，28 种设计的排名相关系数 0.85，和 ADAS 报告的迁移一致。但多智能体的优势缩小了：最好的设计比单智能体高 30.9 个点 → 6.2 个点，单智能体从第 20 名升到第 10 名。排名能迁移，不代表收益能迁移。

7. MACI 的架构选择 · MACI’s architectural choices

第 10 讲介绍过 Chang 的 MACI（多智能体协作智能）：元规划器识别角色和约束、构建依赖图；规划和验证分开；每个智能体只保留完成任务所需的最小上下文；运行时监控器处理变化。用这一讲的语言看：

• 依赖图 + 把约束写进每个智能体的任务 = §3.4 的”先把决策定下来、写下来”：它解决隐含决策的冲突。
• 规划与验证分开、独立的验证智能体 = §5.2 的验证瓶颈：它压低错误放大。
• 最小上下文 = §3.3 的上下文隔离：它避免上下文腐烂。但第 10 讲的实验也提醒了代价：拆分改变了下游智能体看到的输入分布（10 人日程上 33%，让下游在上游真实的输出上训练后 92%）——交接的产物要和接收方的能力匹配。
• 运行时监控：第 10 讲的重规划。

MACI 的论文用案例研究支持这些选择；这一讲的模拟说明了每个选择分别针对哪个机制、在什么条件下值得。

8. 一张设计检查表 · A design checklist

1. 任务结构：子任务能不能真正独立？有没有贯穿全局的隐含决策？是顺序的吗？（并行、独立 → 适合拆；隐含决策 → 先定决策；顺序 → 慎拆。）
2. 上下文：单智能体的上下文会长到什么程度？模型在这个长度上的表现退化多少？先试试单智能体 + 上下文压缩。
3. 交接：交接的产物是结构化的吗？会丢什么？能不能把产物存进外部、只传引用？
4. 验证：谁来把关？验证放在错误传播之前了吗？
5. 成本：调用次数、token、延迟分别是多少？和”同样验证、同样上下文管理的单智能体”比，收益还剩多少？
6. 评测：在留出的测试集上报告；比较多种设计时开发集要足够大，最好用公共随机数（同样的种子、温度 0 或配对的采样）。
7. 模型变强之后：重新评估——多智能体的优势可能缩小。

9. 现状与开放问题 · State of the field

• 工业界的经验（Anthropic、Cognition）和受控比较（Kim et al.）在一点上一致：架构要和任务结构匹配。广泛的、可分解的搜索适合编排者–工人；到处是隐含决策的创作和编程适合单线程的写操作；顺序规划很难拆。
• 多智能体的收益很大一部分可以解释为上下文管理和验证——单智能体也能拿到其中的一部分。剩下的明确优势是并行带来的延迟。
• 自动设计（ADAS、AFlow、MaAS）在基准上有可观的提升，但它们面对的是小验证集上的多重比较问题；迁移和收益的稳定性需要更多独立的复现。

研究问题：

1. 能不能在动手之前预测一个任务适合哪种架构？Kim et al. 的预测模型 $R^2$ 约 0.4；哪些可以提前测量的任务特征（可分解性、隐含决策的数量、状态的可摘要性）最有预测力？
2. 怎样自动地发现和传递隐含决策？编排者怎样知道哪些决策需要写进说明？
3. 交接的”可摘要性”能不能度量？结构化产物（MetaGPT）在多大程度上降低了丢失？
4. 随着模型的长上下文能力提高，多智能体的优势会怎样变化？哪些优势（并行、验证、专门化）不依赖于上下文腐烂？
5. 自动设计的统计学：在多大的验证集上、搜索多少轮，选出的设计才可信？能不能把配对比较、序贯检验用到搜索里？

10. 小结 · Summary

1. 五种基本架构：单智能体、独立、中心化（编排者–工人）、去中心化（群聊）、混合；以及流水线。选架构是在回答：谁看到什么、信息怎样传递、谁来把关。
2. MetaGPT、ChatDev 用标准作业流程和结构化的产物控制交接的质量；AutoGen 是框架，不规定架构。
3. 上下文是核心资源：可分解的任务越大，拆开越值（n = 16：单智能体 0%、编排者–工人 29%）；收益来自上下文隔离，单智能体压缩上下文能拿回一部分。
4. 隐含决策让并行的工人互相矛盾（几乎全部失败）；把决策写进说明就恢复（49.3%）——Anthropic 与 Cognition 的结论都对，对应不同的任务结构。
5. 顺序任务里流水线有传话游戏；编排者–工人在”状态可以摘要”时仍然好于单智能体，状态难以摘要时反过来。
6. 错误放大取决于有没有人把关（独立 14.3×、验证 + 共享决策的编排 4.7×）；模型越强，协调的固定损失越不划算（能力饱和）；给单智能体同样的验证和上下文管理后，多智能体主要剩下延迟的优势。
7. 自动设计：小开发集上的搜索有赢家的诅咒（32 道题 +4.6 个点），独立的随机数让它更严重；按类型选设计、迁移、成本都要量出来——排名能迁移，不代表收益能迁移。

11. 常见误区 · Common pitfalls

1. “多智能体比单智能体强。” 取决于任务结构和对照组：在顺序任务、有隐含决策的任务上可能更差；和同样验证、同样上下文管理的单智能体比，收益可能很小。
2. “把任务拆给几个并行的智能体，速度和质量都会提高。” 如果子任务之间有隐含决策，拼起来可能不能用。
3. “交接时传一个摘要就够了。” 摘要会丢细节，而且在流水线里一路累积。
4. “让所有智能体看到所有消息，信息最充分。” 上下文腐烂一样发生，token 成倍增加。
5. “编排者–工人的收益来自’多个智能体’。” 在很多情况下，它来自上下文隔离和验证——单智能体也可以有。
6. “在验证集上搜索出来的最好设计，就是最好的设计。” 验证集小、试的设计多时，优势大部分是噪声；在留出集上报告。
7. “在一个模型上最好的架构，换了模型还是最好的。” 排名可能迁移，收益常常缩小；模型变强后要重新评估。

12. 练习 · Exercises

练习 1（算一算）。并行任务 n 个子任务，每个工人做对的概率 p，摘要交接不丢细节的概率 $1-\ell$，汇总做对的概率 m；单智能体第 i 个子任务做对的概率 $p_i$ 随 i 下降。(a) 写出编排者–工人（不验证）的成功率。(b) n = 8、p = 0.95、ℓ = 0.03、m = 0.97 时是多少？(c) 加上验证（发现率 0.8）和一次重试，每个子任务的成功率变成多少？

参考答案：(a) $p^n (1-\ell)^n m$。(b) $0.95^8 \times 0.97^8 \times 0.97 = 0.663 \times 0.784 \times 0.97 \approx 0.504$——和代码 01 演示 1 的 52% 接近（模拟里每个子任务的难度不同、工人的上下文也有一点腐烂）。(c) 一次就对：0.95；第一次错（0.05）、被发现（0.8）、重做对了（0.95）：$0.05 \times 0.8 \times 0.95 = 0.038$；合计 0.988。八个子任务：$0.988^8 \approx 0.91$，再乘交接和汇总：$0.91 \times 0.784 \times 0.97 \approx 0.69$（演示 1 的 69%）。注意交接丢失（0.784）现在是最大的损失来源——验证只管子任务，不管交接。

练习 2（隐含决策）。8 个互相看不到的工人，每个决策有 4 个选项，各自以概率 0.5 选默认选项、否则在另外 3 个里均匀选。(a) 8 个人在一个决策上全部一致的概率是多少？(b) 2 个决策都一致呢？(c) 和代码 01 演示 2 的 0.0% 对照。

参考答案：(a) 全选默认：$0.5^8 = 0.0039$；全选同一个非默认选项：$3 \times (0.5/3)^8 \approx 1.8 \times 10^{-6}$；合计约 0.0039。(b) $0.0039^2 \approx 1.5 \times 10^{-5}$。(c) 再乘上子任务全对的概率（约一半），一致而且全对的概率是十万分之一的量级——3000 个任务里一个都没有，所以是 0.0%。

练习 3（什么时候拆）。用代码 01 的模拟（或练习 1 的公式），对一个 n = 6 的并行任务，找出单智能体和编排者–工人（不验证）打平时的上下文腐烂率 rot（其他参数用默认值）。这个”打平点”随 n 怎样变化？

参考答案要点：演示 4 的表（n = 8）显示 rot = 0 时单智能体 75.3%、编排者–工人 58.2%，rot = 0.1 时 59.6% vs 55.7%，rot = 0.25 时 28.5% vs 52.0%——n = 8 的打平点在 0.1 和 0.25 之间、靠近 0.1。n 越大，单智能体的上下文越长，腐烂的总影响越大，打平点越小；n 越小，单智能体的上下文本来就短，打平点越大（甚至在合理的 rot 范围内永远不值得拆）。可以把 01_topologies.py 演示 4 的 n 改成 4、6、12 验证这个趋势。

练习 4（公共随机数）。代码 03 的搜索里，每个任务用固定的随机数，所有设计面对同样的运气。如果每种设计用各自独立的随机数（像 LLM 每次调用都重新采样），搜索会变差多少？先预测，再检验。

参考答案（草稿目录里实际运行，同样的 28 种设计和任务池，每种组合 400 次）：开发集 128 道题、试遍 28 种设计时，公共随机数下遗憾 1.04 个点、乐观偏差 1.25 个点、选中真正最好的设计 78%；各自独立的随机数下遗憾 2.18、乐观偏差 4.18、选中 46%。512 道题时：公共随机数 0.00 / 0.05 / 100%，独立随机数 0.45 / 0.99 / 78%。公共随机数把”设计之间的差别”和”题目之间、采样之间的噪声”分开了——在真实的 LLM 实验里，对应的做法是所有设计用同样的题目、同样的种子（或温度 0），并用配对检验比较。

练习 5（设计实验）。你的团队想把一个单智能体的代码助手改成”规划者 + 三个并行的程序员 + 一个审查者”。设计一个实验来决定是否值得，列出你要测量的东西和需要的对照。

参考答案要点：(1) 任务结构的测量：在一批真实任务里，有多少可以拆成真正独立的修改？共享的接口、风格、假设（隐含决策）有多少？(2) 对照：单智能体；单智能体 + 上下文压缩；单智能体 + 同样的审查（验证）和重试；规划者 + 程序员（不审查）；完整系统；“规划者把接口和约定写进任务说明”的版本。(3) 指标：通过测试的比例（pass@1 和 pass^k，第 11 讲）、合并冲突和风格不一致的比例、token、墙钟时间。(4) 方法：同样的任务、同样的种子、配对比较；超参数在开发集上定，在留出的任务上报告。(5) 预期：如果大部分任务是”改一个地方”，并行的程序员没有用武之地；如果任务需要跨文件的一致决策，必须先由规划者定下来。

13. 延伸阅读 · Further reading

角色与框架

• G. Li et al. CAMEL: Communicative Agents for “Mind” Exploration of Large Language Model Society. NeurIPS 2023.
• S. Hong et al. MetaGPT: Meta Programming for a Multi-Agent Collaborative Framework. ICLR 2024.
• C. Qian et al. ChatDev: Communicative Agents for Software Development. ACL 2024.
• Q. Wu et al. AutoGen: Enabling Next-Gen LLM Applications via Multi-Agent Conversation. 2023.

工程经验与受控比较

• Anthropic. How we built our multi-agent research system. 2025 年 6 月.
• W. Yan（Cognition）. Don’t Build Multi-Agents. 2025 年 6 月；Multi-Agents: What’s Actually Working. 2026 年 4 月.
• Y. Kim et al. Towards a Science of Scaling Agent Systems. 2025（第 3 版 2026 年 4 月）.

拓扑与自动设计

• M. Zhuge et al. GPTSwarm: Language Agents as Optimizable Graphs. ICML 2024.
• G. Zhang et al. Cut the Crap: An Economical Communication Pipeline for LLM-based Multi-Agent Systems（AgentPrune）. ICLR 2025.
• C. Qian et al. Scaling Large-Language-Model-based Multi-Agent Collaboration（MacNet）. ICLR 2025.
• S. Hu, C. Lu & J. Clune. Automated Design of Agentic Systems（ADAS）. ICLR 2025.
• J. Zhang et al. AFlow: Automating Agentic Workflow Generation. ICLR 2025.
• G. Zhang et al. Multi-agent Architecture Search via Agentic Supernet（MaAS）. ICML 2025.

14. 下一讲预告 · Next lecture

第 15 讲：多智能体为什么失败——失败分类、从众、成本与公平的评测。 这三讲反复看到多智能体系统的失败机制：相关错误（第 12 讲）、从众和鞅（第 13 讲）、传话游戏、隐含决策冲突、错误放大（这一讲）。下一讲把它们放进一个系统的框架：Cemri et al. 分析了 7 个流行框架的执行轨迹，建立了 MAST 失败分类（14 种失败模式、3 大类）；怎样从一条长长的执行轨迹里找出”哪个智能体在哪一步导致了失败”；从众和谄媚怎样在智能体之间级联；以及怎样公平地评测一个多智能体系统——标注者之间的一致性、LLM 当标注者的偏差、成本，以及和计算量匹配的单智能体的比较。