Lecture 8 · 多智能体系统 · Multi-Agent Systems

对应 Maps to：Stanford CS329Z Engineering AI Agents（Fall 2026），Lecture 8 · Mon Oct 19 · Multi-Agent Systems。阅读材料：Wu et al., AutoGen: Enabling Next-Gen LLM Applications via Multi-Agent Conversation（COLM 2024）/ Cemri et al., Why Do Multi-Agent LLM Systems Fail?（2025）；Neubig, Don’t Sleep on Single-agent Systems；Liu et al., A Dynamic LLM-Powered Agent Network for Task-Oriented Agent Collaboration（DyLAN，COLM 2024）。 依据说明：写作时（2026-10-16）这一讲的 slides 还没有公布。本讲依据课表上的主题（单智能体 vs 多智能体、编排模式、交接与状态传递、委派与协作、协调的难题与错误传播、“不要小看单智能体”）和四篇阅读材料，并引用两篇被广泛讨论的工程博客：Anthropic 的 How we built our multi-agent research system 和 Cognition 的 Don’t Build Multi-Agents（凡是引用数字的都核对过原文）。等 slides 公布后，侧重点可能和这里不同。全部实验是本讲义自己设计的，不代表课堂上讲了什么。 配套代码 Code：code/lecture08/（只用 Python 标准库；5 个脚本 + 4 个模块 + 1 个可选脚本；不需要 API key；每个脚本不到 1 秒） 预计阅读时间：3 小时（含运行代码）

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

0.1 学习目标 Learning goals

学完这一讲你应该能够：

1. 用”模型、提示词、动作空间”三个组件说清楚什么算多智能体系统，列出人们造多智能体系统的理由。
2. 根据任务的结构判断该用一个智能体还是好几个：广度优先、可并行、超出单个上下文的任务适合拆；上下文高度共享、步骤之间强耦合的任务不适合拆。能复述 Neubig、Anthropic、Cognition 三方的论点，并解释它们为什么并不矛盾。
3. 比较几种编排拓扑（主智能体 + 工人、顺序交接、群聊、辩论）的通信成本和失败方式；用 AutoGen 的”可对话智能体 + 对话编程”描述一个系统，并给它设计终止条件。
4. 解释交接中的信息损失和”隐含的决定”冲突，知道结构化交接、共享完整轨迹各自的代价。
5. 说出多智能体辩论什么时候有用（错误独立、正确推理更有说服力）、什么时候有害（错误相关、从众）；理解 DyLAN 的动态组队。
6. 用 MAST 的 14 种失败模式给一条多智能体轨迹分类，并知道怎样可靠地标注（κ、LLM 评审）和怎样干预。

0.2 先修与本讲范围 Prerequisites & scope

0.3 本讲地图 Map

§0.6 开场：从"心智社会"到 LLM 智能体团队
§1  什么是多智能体系统：三个组件；人们为什么造它
§2  一个还是好几个：Neubig、Anthropic、Cognition 三方的论点；任务结构决定答案            ← 代码 01
§3  编排：主智能体 + 工人、AutoGen 的对话编程与群聊、其他拓扑、通信成本               ← 代码 02
§4  交接与状态传递：信息损失、结构化交接、共享轨迹、隐含的决定                       ← 代码 03
§5  协作：多智能体辩论、动态组队（DyLAN）                                          ← 代码 04
§6  为什么失败：MAST 的 14 种失败模式、标注与干预                                   ← 代码 05
§7  用真实模型试一试                                                              ← 代码 06（可选）
§8  一张决策清单
§9 小结   §10 常见误区   §11 练习   §12 延伸阅读   §13 下一讲预告

0.4 术语 Terms

0.5 本讲的代码

代码围绕”什么时候值得用多个智能体”这个工程问题，造了两类结构不同的任务（mas_lab.py）：广度研究——K 个互相独立的子问题，每个要检索 3 次、每次返回约 1,500 token 的文字；耦合构建——4 个部件，部件之间要在 5 个”隐含的决定”上保持一致。几种拓扑在两类任务上各跑 200 次。另有一个迷你 AutoGen（autogen_lite.py）、一个辩论与组队的模拟（debate_lab.py）、一个 MAST 失败分类的模拟（mast_lab.py）。

提醒：漏看、交接丢失、照着别人的决定做、被说服 / 从众的概率都是旋钮。机制性的部分是算出来的：上下文长度、token、延迟、交接后信息还在不在、部件的决定是否一致、群聊的读取成本；MAST 的失败比例取自论文。

0.6 开场：从”心智社会”到 LLM 智能体团队

第 1 讲 §2 讲过智能体的历史：1973 年的 actor 形式化把计算看成一群互发消息的独立实体；1980 年的 Contract Net 研究智能体之间怎样分配任务；Minsky 1986 年的《心智社会》设想智能本身就来自许多简单”智能体”的协作。LLM 让这个老想法突然变得容易实现：同一个模型，换一个系统提示就是一个新”角色”。于是有了 MetaGPT、ChatDev 这类”一家软件公司里有 CEO、CTO、程序员、测试员”的系统，有了 AutoGen 这样的通用框架，以及大量的论文和黑客松。

可是 Graham Neubig（OpenHands 的作者之一）写了一篇题为《不要小看单智能体系统》的博客，Cognition 写了一篇题为《不要造多智能体》的博客，而 Anthropic 又写了一篇《我们怎样造出多智能体研究系统》。这一讲的核心任务是把这三种声音放在一起：它们说的是不同结构的任务。

1. 什么是多智能体系统 · What is a multi-agent system

1.1 三个组件

Neubig 的博客给了一个清楚的定义：一个 LLM 智能体由三部分组成——底层的 LLM、提示词（系统提示加上环境信息）、动作空间（它能用的工具）。多智能体系统里，至少有一个组件在智能体之间不同。

例子：CodeR（一个解 GitHub issue 的多智能体框架）有 5 个智能体，用的是同一个底层模型，但提示词和动作空间各不相同——管理者（写计划）、复现者（复现问题）、故障定位者（找出有问题的文件）、编辑者（改代码）、验证者（输出”问题解决了吗：是 / 否”）。

1.2 人们为什么造多智能体系统

• 专门化：每个智能体的提示词和工具只管一件事，更聚焦（第 6 讲 §2.2 的路由）。
• 并行：互相独立的子任务同时做，延迟降下来（第 6 讲 §2.3）。
• 上下文隔离：每个子智能体只看自己需要的东西，主智能体只看结果（第 6 讲 §4.2）。
• 不同的委托人 / 私有信息：买方的智能体和卖方的智能体在谈判，各自有不能告诉对方的底线——这类场景天然需要多个智能体（Neubig 也承认这是例外）。
• 模块化：每个智能体可以单独开发、测试、替换。

前三条是”性能”上的理由，后两条是”结构”上的理由。下一节看前三条什么时候成立。

2. 一个还是好几个 · Single-agent or multi-agent?

2.1 Neubig：不要小看单智能体

博客列了多智能体系统的三个问题：

• 结构僵硬：固定的角色在任务不合适时就会坏掉——比如验证者需要定位问题，却没有定位工具。
• 上下文丢失：在智能体之间传摘要，会丢掉下游有用的信息（§4）。
• 难维护：每个智能体可能有自己的代码和提示词，复杂度成倍增加。

（博客把这些问题比作一个管理不善的人类团队。）然后提出走向”一个强大的单智能体”的路线：

• 单一的 LLM：Claude、GPT-4o、Llama 3.1、Qwen-2.5 这样的通用模型覆盖了大部分能力，缺的能力可以继续训练补上；
• 单一的动作空间：给通用的工具（写代码、运行代码、浏览网页），需要时把工具箱合并——这覆盖了多智能体系统做的大部分事；
• 单一的提示：要么把所有提示词拼在一起（OpenHands 当时的做法，靠长上下文模型，成本可以用前缀缓存降下来，但多余的上下文会分散注意力），要么按需检索相关的提示（第 6 讲的渐进披露）。

博客认为”最好的提示方式”仍是开放的研究问题，但相信它能解决；例外是一个智能体掌握私有信息、或者不同的智能体代表不同的人时。

2.2 Anthropic：广度优先的研究任务值得拆

Anthropic 的多智能体研究系统：一个主智能体（Claude Opus 4）分析问题、制定策略，并行地派出几个子智能体（Claude Sonnet 4）各自探索不同的方向，最后汇总。博客报告：

• 在内部的研究评估上，这个多智能体系统比单智能体的 Claude Opus 4 高 90.2%；
• 在 BrowseComp 上，三个因素解释了 95% 的成绩差异，其中 token 用量一项就解释了约 80%（另两个是工具调用次数和模型选择）——多智能体系统有效，很大程度上是因为它花了更多 token 去解决问题；
• 代价：智能体通常用聊天的约 4 倍 token，多智能体系统约 15 倍——任务的价值必须撑得起这个开销；
• 适合：广度优先、要同时追好几个独立方向的问题；高度可并行、信息超出单个上下文窗口、要用很多复杂工具的高价值任务；
• 不适合：所有智能体必须共享同一份上下文的任务、智能体之间依赖很多的任务——大多数编程任务（可并行的部分比研究少）；以及实时的协调和委派（LLM 智能体还做不好）。

博客还总结了几条提示词原则，其中和多智能体最相关的：教主智能体怎样委派（给每个子智能体一个目标、输出格式、工具指引、清楚的任务边界，免得重复劳动）；按问题的复杂度决定投入（简单的事实查找 1 个子智能体、复杂研究 10 个以上）；并行（主智能体同时派 3–5 个子智能体、子智能体同时用 3 个以上工具，复杂问题的研究时间最多缩短 90%）。

2.3 Cognition：不要造多智能体

Cognition（Devin 的开发者）的两条原则：

1. 共享上下文：子智能体需要的不只是任务描述，而是前面的智能体的完整轨迹，不只是零散的消息；
2. 动作里藏着隐含的决定：“互相冲突的决定带来坏结果。”

例子：做一个 Flappy Bird 的克隆，拆成两个子任务——“带绿色水管和碰撞箱的滚动背景”和”一只可以上下移动的鸟”。第一个子智能体误解了任务，做了一个《超级马里奥》风格的背景；第二个做的鸟看起来、动起来都不像 Flappy Bird。最后的智能体要把两个不兼容的结果拼起来。把原始任务也一起交给子智能体并不能完全解决问题，因为多轮对话和工具调用会改变对任务的理解；就算共享了上下文，两个子智能体仍可能各自做出冲突的风格选择。

推荐的架构：单线程、线性的智能体——上下文连续，两条原则都满足；任务太大、超出上下文时，加一个专门的上下文压缩模型，把历史压成关键的细节、事件和决定（这很难做好，可能需要微调一个小模型）。

2.4 它们并不矛盾：任务结构决定答案

三篇文章说的是不同结构的任务。代码 01 把同样的几种拓扑放在两类任务上：

广度研究（8 个独立子问题 × 3 次检索）：

耦合构建（4 个部件 × 5 个隐含的决定）：

读法：

• 广度任务上，拆分赢了。单智能体要把 24 段检索结果都留在上下文里，越往后越容易漏看；并行子智能体各自只看自己那 3 段（峰值 5.3K），成功率翻倍，延迟降到 1/6。让子智能体”先宽后窄”、多搜一倍，成功率 79%，token 是不宽的 3.1 倍——用更多 token 换更好的结果，这正是 Anthropic 观察到的”token 用量解释 80% 的差异”。
• 耦合任务上，拆分输了。并行子智能体各自做隐含的决定，几乎从不一致（0%）；主智能体事先把想得到的决定写进说明也只到 8%——它想不到所有的。单智能体 75.5%；子智能体顺序做、共享完整轨迹 66.5%，但那就失去了并行，token 还更多。这正是 Cognition 的 Flappy Bird。
• 顺序交接最差（11.5%）：每交接一次就重新总结一遍之前的发现，早先的事实一路被稀释——Neubig 说的”上下文丢失”。群聊每一轮每个人都要读整个记录，token 最多，还会被”选错发言者""没人说终止”拖长。
• 规模：子问题从 2 个涨到 16 个，单智能体从 88% 掉到 0%，并行子智能体从 84% 到 30%。K = 2 时单智能体不输（88% vs 84%），而且更简单。问题越宽，拆分越值得。

关于 token 有一个值得注意的细节：在我们的模型里，“单智能体全部保留”反而比子智能体用的 token 多（504K vs 99K），因为它每一步都重发越来越长的历史。真实系统里单智能体会用缓存和上下文管理（第 6 讲 §4），子智能体则往往搜得更多，所以 Anthropic 观察到的是多智能体用得更多。结论不变：多智能体系统的价值和代价都在于它让更多的计算并行地投入到问题上。

3. 编排 · Orchestration

决定”拆”之后，下一个问题是谁和谁说话、谁决定下一步。

3.1 主智能体 + 工人

第 6 讲 §2.4 的 orchestrator–workers 就是最常见的多智能体结构：主智能体拆任务、分派、汇总，子智能体之间不直接说话（星形拓扑）。Anthropic 的研究系统就是这样，几条工程经验值得记住：

• 委派要写清楚。早期版本里，主智能体只给一句简短的说明（“研究半导体短缺”），子智能体经常误解任务、重复彼此的搜索，或者一个查 2021 年的汽车芯片危机、另外两个都去查 2025 年的供应链。每个子智能体需要：目标、输出格式、可以用哪些工具和来源、清楚的任务边界。
• 按复杂度投入：简单的事实查找 1 个子智能体、3–10 次工具调用；直接比较 2–4 个子智能体、各 10–15 次；复杂研究 10 个以上，分工明确。
• 让子智能体直接写文件：子智能体把产出写到文件系统，只把一个轻量的引用交给主智能体，避免结果经过主智能体时被一遍遍转述（“传话游戏”，§4 量化它）。
• 主智能体也会失败：派出 50 个子智能体去查一个简单问题、没完没了地找不存在的来源、子智能体之间互相打扰……这些都是早期版本真实出现过的。

3.2 AutoGen：用”对话”来编排

AutoGen（Wu et al.）把多智能体系统统一成两个概念：

• 可对话的智能体（conversable agent）：能收发消息的实体，背后可以是 LLM、人、工具执行器，或它们的组合。两个内置的例子：AssistantAgent（LLM，写代码、给建议）和 UserProxyAgent（代表人，可以向人要输入，也可以自动执行收到的代码并回报结果）。每个智能体收到消息后用自动回复机制产生下一条消息——不需要一个外部的控制器一步步调度。
• 对话编程（conversation programming）：一个多智能体应用 = 计算（每个智能体收到消息后做什么）+ 控制流（谁在什么时候说话）。控制流既可以用自然语言写在提示词里，也可以用代码写（注册回复函数、终止条件）。

群聊（GroupChat）是 AutoGen 处理两个以上智能体的方式：所有消息进同一个对话记录，一个 GroupChatManager 每一轮做三件事——选下一个发言者（轮流 / 由 LLM 根据记录挑 / 人工选）、让它发言、把它的消息广播给所有人；直到有人发出终止信号（比如消息里带 TERMINATE）或轮数用完。

代码 02 的演示 1 是两个智能体的对话：助手写代码，用户代理在第 6 讲的白名单解释器里真的执行并回报：

[user_proxy] What is the mean of 3, 1, 4, 1, 5, 9, 2, 6? Use Python.
[assistant]  nums = [3, 1, 4, 1, 5, 9, 2, 6]
             print(sum(nums) / len(num))
[user_proxy] exitcode: 1
             Error: line 2: NameError: name 'num' is not defined
[assistant]  （改正后再发一版）
[user_proxy] exitcode: 0
             Output: 3.875
[assistant]  The mean is 3.875. TERMINATE

这正是第 6 讲的 CodeAct 循环；AutoGen 的贡献是把它表达成对话，于是同样的结构可以把用户代理换成真人（人在回路），或者加入更多参与者。

演示 2 是一个四人群聊（计划 / 编码 / 审查 / 测试），200 个任务，30% 的第一版代码有 bug：

• 选人：按对话记录选”该谁说”比轮流省轮数；选人一出错（该程序员改代码时却让计划者发言），轮数和读取量都涨，有些任务在 16 轮内没修完。
• 终止：没有终止条件时，测试已经通过了，大家还在说话，直到轮数用完——这就是 §6 MAST 里的”不知道终止条件”（占轨迹的 12.4%）。设计一个群聊时，终止条件和选人策略是你必须亲手写的两件事。

3.3 其他拓扑与通信成本

通信成本由拓扑决定（代码 02 演示 3：每人每轮说一条 100 token 的消息，共 4 轮）：

星形和链是线性的（每条消息只被一个人读）；群聊里第 i 条消息之前的所有消息都要被下一个发言者读一遍，总读取量是 100 × n(n−1)/2（n = 消息总数），平方增长。这是群聊只适合少数几个参与者的根本原因。

4. 交接与状态传递 · Handoffs and state

一次交接传递两样东西：控制权（接下来谁行动）和状态（目前知道什么、决定了什么）。控制权容易，状态难。

4.1 信息在交接中丢失

代码 03 的演示 1：第 1 个智能体发现了 10 个事实，之后每交接一次，接手的智能体就重新转述一次。三种格式：

（模拟：自由文本每跳保留每个事实的概率 0.90、悄悄改错 0.02；结构化 0.99、0.002；完整轨迹每段约 1,800 token，窗口 12,000，超出后从最早的那段截掉。）

• 自由文本像传话游戏：8 跳后只剩 3.6 个，而且下游不知道少了什么。
• 结构化交接（必填字段、事实逐条列出）8 跳后还剩 9.1 个：schema 让”丢了什么”变得可见（字段是空的），也让转述者没法随手改写。第 2 讲的结构化输出、第 5 讲 DSPy 的签名，用在智能体之间的交接上正合适。
• 完整轨迹（Cognition 的第一条原则）一个都不丢——直到超出窗口：6 跳时最早那段开始被截掉，8 跳时整段被截掉；而且每一跳读的 token 越来越多。共享完整上下文是对的，但它和”用多个智能体来分担上下文”这件事本身是矛盾的。

一个容易忽略的细节：完整轨迹被截掉时，丢的恰恰是最早的、往往最重要的发现（任务的原始要求、第一个智能体找到的关键事实）。第 6 讲 §4 的上下文管理（压缩、卸载到文件、观察遮蔽）在多智能体系统里同样需要。

4.2 隐含的决定

代码 03 的演示 2：P 个部件、D 个隐含的决定，每个决定有 3 种同样合理的选法。并行的子智能体各自做决定；“顺序、共享完整轨迹”的子智能体能看到前面所有人的决定（照着做的概率 0.98）。

公式：每个决定要所有部件碰巧选得一样，概率是 (1/3)^(P−1)；D 个决定都一致是 (1/3)^((P−1)·D)；再乘上每个部件本身做对的概率 0.96^P。模拟和公式吻合（差异是 300 次的抽样误差）。

直觉：隐含的决定的数量远比你以为的多——一个函数叫什么名字、坐标原点在左上还是左下、错误用异常还是返回值、配色、日期格式……每一个都”无所谓选哪个，但必须一致”。并行的智能体看不到彼此，只能碰运气；部件和决定一多，运气就不够了。顺序做、共享轨迹挽回了大部分，但那就失去了并行，而且部件越多、轨迹越长，全部一致的概率也会下降（P = 8、D = 5 时只有 45%）。

4.3 工程上怎么做交接

• 能不交接就不交接：强耦合的工作（同一个代码库的修改、同一篇文章）交给一个智能体按顺序做——Cognition 的”单线程、线性的智能体”。
• 先定合同，再并行：确实要并行时，先由一个智能体写下接口、命名、格式等决定（一份 spec 文件），所有子智能体都读它；代码 01 里主智能体”事先写下想得到的决定”只到 8%，因为它想不到所有的——所以合同要尽量完整，并在汇总时检查一致性。
• 结构化交接：用 schema 规定交接里必须有什么——任务目标、约束、已经做的决定、没解决的问题、产出的位置（文件路径而不是全文）。
• 产出写进文件，交接里只放引用：避免结果被反复转述（Anthropic 的做法）。
• 把子智能体用成”只读的工具”：让子智能体去做探索、检索、阅读这类不做决定的工作，只交回压缩后的发现，决定留给主智能体。这是第 6 讲”上下文隔离”的正确用法，也是 Claude Code 子智能体的典型用途。

5. 协作：辩论与动态组队 · Collaboration: debate and dynamic teams

前面几节的多个智能体分工做不同的子任务。另一类用法是让多个智能体做同一件事，再用它们的分歧来提高质量。

5.1 多智能体辩论

Du et al.（2023）的做法：几个模型实例各自作答 → 每个实例读到其他实例的答案和理由，修改自己的答案 → 重复几轮 → 取多数。论文在算术、GSM8K、国际象棋走法、传记的事实性等任务上报告了提升，智能体越多、轮数越多越好。直觉来自”三个臭皮匠”：一个错误的推理被另一个实例指出来，比自己发现更容易（第 6 讲 §3.2 讲过，没有外部反馈的自我纠错常常无效；辩论是一种来自”别人”的反馈）。

但辩论的调用量是”实例数 × (轮数 + 1)“，而第 6 讲 §2.3 的投票（各自作答、直接取多数）只要”实例数”。公平的比较应该在同样的调用预算下做。代码 04 的演示 1（同一个”通才”模型的多个实例，600 道 4 选 1 题；能力、诱人选项、被说服的概率是旋钮）：

• 大部分增益来自多个实例本身（投票）：5 票投票就从 59% 到 73%。
• 5 个辩论 2 轮（15 次调用）和 5 票投票（5 次调用）几乎一样；同样花 15 次调用，15 票投票是 77.0%，比辩论还高一点；5 个辩论 3 轮（20 次调用）77.5%，和 15 票投票在置信区间之内。3 个辩论 1 轮和 2 轮的差别也在置信区间之内。
• 后续不少研究也发现，在同样的计算预算下，多智能体辩论常常并不比多数投票（self-consistency）好多少（例如 Smit et al., 2024）。先试投票；辩论要和同预算的投票比。

5.2 辩论什么时候有用、什么时候有害

辩论能起作用（演示 2 里错误各不相同时，5 个辩论 2 轮比 5 票投票高出 7 个点），靠的是一个假设：正确的推理比错误的推理更有说服力——在代码里，“多数是对的、我是错的”时被说服的概率（0.55）大于”多数是错的、我是对的”时从众的概率（0.30）。代码 04 的演示 2 改变两个条件：

• 错误相关：同一个模型的多个实例往往犯同一个错（同样的训练数据、同样的”直觉陷阱”）。错误各不相同时，错误的答案分散在几个选项上，正确答案容易成为多数；错误都集中在一个诱人选项上时，它可能和正确答案打平甚至胜出，投票和辩论都在”互相确认错误”。所以多个实例最好真的不同：不同的模型、不同的提示、不同的工具或信息来源。
• 从众：从众概率和”被正确的多数说服”一样大时，辩论比 5 票投票还差（69.5% vs 73.3%）；更大时（0.75）只剩 63.8%。LLM 的谄媚（sycophancy，倾向于同意对方）会直接伤害辩论——一个本来对的智能体被两个错的说服了。真实模型上这件事发生得多不多，§7 的脚本可以测。

5.3 动态组队：DyLAN

如果有一池子不同的智能体（不同的角色提示、甚至不同的模型），每个任务该选哪几个？DyLAN（Liu et al., COLM 2024）的两个想法：

1. 团队优化：在少量样本上让所有候选一起协作，用一个无监督的智能体重要性分数（Agent Importance Score）给每个智能体打分——论文里，智能体在每一步给前一步的回答打分，分数沿着协作网络反向传播，算出每个智能体对最终答案的贡献——然后为这一类任务选出最重要的几个。打分不需要标准答案。
2. 动态协作：任务执行时，智能体分成若干”时间步”，每一步可以根据前面的回答选择下一步让谁参与；一旦多数（超过 2/3）达成一致就提前停止——借用了拜占庭共识的思路。

代码 04 的演示 3 用一个简化的分数（不看答案；一个智能体的答案和最终共识一致的次数，越早一致权重越高——“早早给出、最后被大家采纳”说明它有贡献）。7 个候选：数学家、程序员、律师、医生、历史学家、通才、一个弱的；5 个领域，每个领域用 60 道题打分，其余题测试：

• 不看答案的分数大体上把每个领域的专家排在了前面（数学领域：数学家第一；代码领域：程序员第一），但不完美——代码领域挑进了历史学家，法律、医学、历史三个领域排第一的都是通才而不是对应的专家。60 道题、无监督的分数有噪声。
• 挑对人比人多更重要：挑出来的 3 个胜过全部 7 个（后者调用多一倍多）。随机 3 个甚至比单个通才还差——弱的成员不只是浪费调用，还会把多数拉向错误。
• 提前停止把调用从 9.0 降到 3.4，准确率少了 5 个点：有些”早早一致”的答案其实是错的（又是错误相关）。省多少调用、丢多少准确率，是要在你的任务上测的权衡。

6. 为什么失败：MAST · Why do multi-agent systems fail?

6.1 分类是怎样来的

Cemri et al. 问了一个直接的问题：多智能体系统的热情很高，可在常用基准上，相比单智能体的提升往往很小——它们到底是怎样失败的？做法是扎根理论（grounded theory）：先在 5 个框架的 150 条轨迹上由专家反复讨论、归纳出失败模式，三位标注者在最后一轮的一致性 Cohen’s κ = 0.88；再用一个验证过的 LLM 评审（o1，和人类的一致率 0.94、κ = 0.77）把标注扩展到 7 个框架（ChatDev、MetaGPT、HyperAgent、AppWorld、AG2、Magentic-One、OpenManus）的 1,642 条轨迹。结果是 MAST：14 种失败模式、3 大类。

三大类：FC1 系统设计问题（约 44%：任务和角色说明、对话管理、终止条件）、FC2 智能体之间的错位（约 32%：沟通、协调、理解彼此）、FC3 任务验证（约 23.5%：没验证、验证错、过早结束）。（三类的合计是把各模式的比例加起来得到的。）

几点直觉：

• 最常见的不是”模型不够聪明”：步骤重复、推理与行动不一致、不知道何时停、不按说明做——很多是系统设计让模型没法做对。论文把这比作组织设计：一群能干的人组成的团队，如果分工、沟通和检查机制设计得不好，照样会失败。
• FC2 正是 §4 的交接问题：隐瞒信息、无视别人的输入、不问澄清——信息没有在智能体之间正确地流动。
• FC3 说明”验证者”角色不够：很多系统有一个”测试者”或”审查者”，但它只检查代码能不能编译，不检查是否满足任务的真正要求。

6.2 在一个模拟系统上复现

代码 05 按论文的比例生成 1,000 条 ChatDev 式的轨迹（CEO → CTO → 程序员 → 审查者 → 测试者；每种失败让任务失败的概率是旋钮）：

• 每条轨迹平均带 1.54 种失败模式，19% 的轨迹没有任何失败模式；任务成功率 41.3%。
• 按失败模式的个数分组：0 种 90%、1 种 51%、2 种 21%、3 种以上 9%——失败会叠加（第 1 讲 §6.1 的错误累积）。

6.3 怎样可靠地标注

一个分类法只有在不同的人能一致地使用时才有用。Cohen’s κ 衡量两个标注者的一致性，扣除了”碰巧一致”的部分：

κ = (p_o − p_e) / (1 − p_e)

p_o 是实际一致的比例，p_e 是两人各自按自己的标注比例随机打标签时预期的一致比例。失败模式大多是”没有”，两个人都说”没有”很容易碰巧一致，所以只看一致率会高估，κ 更严格。

（在 14 × 1,000 个”有没有这种失败”的判断上，对照模拟的真实标签；标注者的准确率是旋钮。）LLM 评审既漏标也错标，但它便宜、能扩展到几千条轨迹——论文的做法是先在人工标注的子集上验证它和人类的一致性，再用它扩展（第 13 讲会细讲 LLM 评审的校准）。

6.4 干预

论文在 ChatDev 上试了两种干预：把角色说明写清楚（例如明确 CEO 有最终决定权），以及加一个高层的任务目标验证步骤（不只是检查代码能否编译，而是检查是否满足原始任务）。论文报告：前者让任务成功率提高 9.4%，后者在 ProgramDev 上提高 15.6%。代码 05 的演示 4：

（干预作用在哪些失败模式上、作用多大是旋钮，方向和论文一致。）角色说明主要减少 FC2，验证步骤主要减少 FC3，两者互补。但即使都加，成功率也只有 63%——论文的结论是：这些失败需要更根本的系统设计（更好的协调协议、可验证的中间产物、终止条件），而不只是改提示词。

7. 用真实模型试一试 · Try it on a real model

06_real_llm.py（可选，需要 pip install anthropic 和 ANTHROPIC_API_KEY，56 次调用）在 8 道容易掉进”直觉陷阱”的题上（球拍和球、5 台机器 5 分钟、睡莲覆盖湖面……标准答案写在脚本里）比较：

1. 单个实例答一遍；
2. 3 个实例各自作答，多数决（投票）；
3. 3 个实例读到彼此的答案和理由后再答一轮，多数决（辩论 1 轮）；

并统计”本来答对、辩论后改错”的次数——这就是 §5.2 的从众。

python3 06_real_llm.py

不联网检查脚本本身：python3 06_real_llm.py --toy（用随机的玩具智能体，结果没有意义）。

读结果时想一想：

• claude-opus-5-5 不接受 temperature 参数，3 个”独立”实例的第 0 轮答案可能几乎一样——这就是 §5.2 的错误相关：如果第 0 轮就全对或全错，投票和辩论都不会改变什么。
• 强模型在这些经典陷阱题上可能全对；想看到差别，可以换更难的题（例如第 3 讲的多跳问题、你自己领域里的题），或者给 3 个实例不同的系统提示（“你是一个谨慎的数学家” / “你是一个怀疑论者”），让它们真的不同。
• 编写时没有用真实 API 跑过这个脚本，所以这里不报告数字；请以你自己的运行结果为准。

8. 一张决策清单 · A decision checklist

在动手造多智能体系统之前，依次问：

1. 单智能体加好的工具和上下文管理够不够？ 先做一个强的单智能体基线（第 6 讲的 ReAct + 上下文管理）。Neubig 的提醒：多智能体系统的很多”优势”可以由一个通用工具箱和按需检索的提示词得到。
2. 任务是广度优先、可并行的吗？ 子任务互相独立、各自需要读大量信息（检索、阅读、调研）→ 主智能体 + 并行子智能体值得考虑（§2.4 广度研究）。
3. 子任务之间有多少隐含的决定？ 共享一个代码库、一份文档、一种风格 → 一个智能体按顺序做（§4.2）；一定要并行，先写完整的合同。
4. 任务的价值撑得起 token 吗？ 多智能体系统约是聊天的 15 倍 token（Anthropic），是单智能体的数倍。
5. 有没有天然的多方：不同的委托人、私有信息、不同的权限 → 多智能体是结构上的需要，不是性能上的选择。
6. 如果造了：交接用 schema；产出写进文件、交接里放引用；明确终止条件和选人策略；有一个检查任务目标（而不只是”能不能运行”）的验证步骤；记录完整轨迹，用 MAST 给失败分类（第 12–13 讲的评估方法）。
7. 想用多个实例提高质量：先试投票；辩论要和同预算的投票比；让实例真的不同（不同模型 / 提示 / 信息），警惕从众。

9. 小结 · Summary

1. 定义：多智能体系统里，至少有一个组件（模型、提示词、动作空间）在智能体之间不同。人们造它是为了专门化、并行、上下文隔离、模块化，以及不同委托人 / 私有信息这种结构上的需要。
2. 一个还是好几个，看任务结构：广度优先、子任务独立、信息超出单个上下文 → 主智能体 + 并行子智能体胜出（代码 01：26.5% → 59.5%，搜得更宽 79.0%），代价是更多 token；子任务之间共享大量隐含的决定 → 拆开几乎必然冲突（并行 0%），单智能体（75.5%）或共享完整轨迹（66.5%）更好。Neubig、Anthropic、Cognition 说的是不同结构的任务。
3. 编排：星形（主 + 工人）、链（顺序交接）、群聊、辩论、共享状态。AutoGen 用可对话的智能体和对话编程统一了它们；群聊里选人策略和终止条件必须亲手设计；通信成本星形和链是线性的、群聊是平方的。
4. 交接：自由文本像传话游戏（8 跳剩 3.6 / 10），结构化交接让丢失可见（9.1 / 10），完整轨迹不丢但受窗口限制、而且和”分担上下文”矛盾。隐含的决定在并行时一致的概率是 (1/3)^((P−1)·D)，几乎为零。
5. 协作：大部分增益来自多个实例本身（投票）；辩论要和同预算的投票比；错误相关、从众都会让辩论失效；挑对成员（DyLAN 的无监督重要性分数）比人多更重要；提前停止省调用、但会丢一点准确率。
6. 失败：MAST 的 14 种失败模式里，系统设计问题约占 44%、智能体之间的错位 32%、任务验证 23.5%；失败会叠加；标注要先验证一致性（κ）；写清楚角色、加任务目标验证有帮助，但不够——需要更根本的系统设计。

10. 常见误区 · Common pitfalls

• “多个智能体总比一个强。” 取决于任务结构：在耦合构建任务上，并行子智能体是 0%（代码 01）。先做一个强的单智能体基线。
• “多智能体系统更省 token，因为每个智能体的上下文都短。” 在真实系统里通常相反（Anthropic：约是聊天的 15 倍）；它的价值在于把更多的计算并行地投入问题，而不是省钱。
• “给子智能体一句话的任务就够了。” 不清楚的委派会让子智能体误解任务、重复劳动（Anthropic 的半导体例子）；要写目标、输出格式、工具、边界。
• “把原始任务也传给子智能体，冲突就解决了。” 隐含的决定在执行过程中才做出，原始任务里没有（Cognition 的 Flappy Bird）。
• “交接时写一段摘要就行。” 每转述一次就丢一点，而且下游不知道丢了什么；用 schema、把产出写进文件。
• “共享完整轨迹，就不会丢信息。” 直到超出上下文窗口——而且最先被截掉的是最早、往往最重要的那段。
• “群聊让大家自由讨论最灵活。” 读取成本平方增长；没有终止条件就停不下来；选错人就白费一轮。
• “辩论比投票好。” 要在同样的调用预算下比；同一个模型的实例错误高度相关、会从众，辩论可能还不如投票。
• “团队越大越好。” 弱的成员会把多数拉向错误（全部 7 个 66.0% < 挑出来的 3 个 77.7%）。
• “多智能体系统失败，是因为模型不够聪明。” MAST 里最常见的是系统设计问题——步骤重复、不知道何时停、不按说明做；换更强的模型不一定能修好。

11. 练习 · Exercises

练习 1（一个还是好几个）：下面每个任务，你会用单智能体还是多智能体？为什么？(a) 调研 20 篇论文并写一份综述；(b) 把一个函数在整个代码库里改名并更新所有调用；(c) 代表买方和代表卖方的智能体谈价格；(d) 让 5 个智能体并行写一部小说的 5 章；(e) 客服系统按问题类型把对话交给退款 / 技术 / 账户三个专门的智能体。

练习 2（通信成本）：6 个智能体，每人每轮说一条 100 token 的消息，共 3 轮。用代码 02 演示 3 的计数方式，分别算星形、链、全连接（群聊）的总读取 token。

练习 3（隐含的决定）：3 个部件、2 个隐含的决定，每个决定有 3 种同样合理的选法，每个部件本身做对的概率 0.96。(a) 并行、各做各的时，全部一致且都做对的概率？(b) 如果每个决定只有 2 种选法呢？(c) 如果主智能体事先把每个决定写进说明的概率是 0.6（写进去就一定一致），(a) 变成多少？

练习 4（传话游戏）：自由文本交接每跳保留每个事实的概率 0.90、改错的概率 0.02（代码 03）。(a) 推出 h 跳后一个事实完好的概率，并验证 8 跳时约剩 3.6 / 10。(b) 几跳之后剩不到一半？(c) 结构化交接（0.99、0.002）8 跳剩多少？

练习 5（完整轨迹的窗口）：每个智能体的轨迹约 1,800 token，窗口 12,000 token，超出时从最早的开始截。(a) 第几跳开始截到第 1 个智能体的轨迹？第几跳时它被整段截掉？(b) 提出一种既保留早期关键发现、又不让上下文无限增长的交接方式。

练习 6（Cohen’s κ）：两个标注者在 100 个”有没有这种失败”的判断上：都说有 10 个，A 有 B 没有 5 个，A 没有 B 有 5 个，都说没有 80 个。(a) 一致率和 κ 各是多少？(b) 一个永远说”没有”的标注者和 A 的一致率、κ 是多少？说明为什么要用 κ。

练习 7（公平地比较辩论）：你的预算是每题 15 次调用。(a) 代码 04 里，同预算的两种做法各是多少？(b) 除了”同预算”，还应该控制什么才能说”辩论有用”？(c) 怎样让多个实例的错误不那么相关？

练习 8（用 MAST 分类）：给下面每段轨迹片段归一个最贴切的失败模式：(a) 测试者运行代码没有报错，就宣布”任务完成”，但游戏规则和需求不符；(b) 程序员连续 5 次提交几乎一样的修改；(c) 智能体写道”我先读取配置文件再调用 API”，接着直接调用了 API；(d) 需求里没说要支持哪种棋盘大小，CTO 自己定了 8 × 8 而没有问；(e) 测试通过后，几个智能体又互相感谢、总结了 6 轮。

练习 9（写一条委派说明）：你的主智能体要派一个子智能体”调研 2026 年 HBM 内存的供应情况”。按 §3.1 的要求写出这条委派说明，并说明每一部分防止了什么问题。

练习 10（开放题：设计一个公平的实验）：你的团队想证明”我们的多智能体研究助手比单智能体好”。设计一个公平的实验：基线是什么、控制哪些变量、看哪些指标，怎样知道增益来自”多智能体”而不只是”多花了 token”？

12. 延伸阅读 · Further reading

本讲的阅读材料

• Q. Wu et al., AutoGen: Enabling Next-Gen LLM Applications via Multi-Agent Conversation, COLM 2024.
• M. Cemri et al., Why Do Multi-Agent LLM Systems Fail?, 2025（MAST 分类与数据集）。
• G. Neubig, Don’t Sleep on Single-agent Systems, All Hands AI 博客, 2025.
• Z. Liu et al., A Dynamic LLM-Powered Agent Network for Task-Oriented Agent Collaboration（DyLAN），COLM 2024.

工程博客

• Anthropic, How we built our multi-agent research system, 2025.
• Cognition, Don’t Build Multi-Agents, 2025.

辩论与协作

• Y. Du et al., Improving Factuality and Reasoning in Language Models through Multiagent Debate, ICML 2024.
• A. Smit et al., Should we be going MAD? A Look at Multi-Agent Debate Strategies for LLMs, ICML 2024.

角色扮演式的多智能体框架

• 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.

历史

• M. Minsky, The Society of Mind, 1986；R. G. Smith, The Contract Net Protocol, 1980（第 1 讲 §2）。

13. 下一讲预告 · Next lecture

第 9 讲 优化：提示词、权重与推理算力（10/21）。这一讲的干预——把角色说明写清楚、加一个验证步骤——都是人手改提示词和结构；第 5 讲的 BootstrapFewShot 已经让我们看到”自动挑示例”能做什么。下一讲把”优化一个智能体系统”系统地讲一遍：提示词优化（MIPROv2、GEPA 的反思式进化）、什么时候该改权重（微调与提示词优化怎样配合，Soylu et al.）、以及把算力花在推理时（Snell et al. 的测试时算力扩展：best-of-N、验证器、按难度分配预算）。配套代码会在模拟 LLM 上比较几种提示词搜索方法，并做测试时算力的计算最优分配。