ai-agent-book第十章 多 Agent 协作学习笔记
第十章 多 Agent 协作学习笔记
来源：https://bojieli.github.io/ai-agent-book/book/chapter10
本章核心不是“Agent 数量越多越好”，而是研究多个 Agent 如何分工、通信、验证、调度与容错。判断多 Agent 是否真正有价值，最重要的标准是：协作过程是否引入了单 Agent 原本拿不到的新信息，以及这些收益是否值得额外的 token、时间和工程成本。
一、多 Agent 协作的分类框架
1.1 维度一：上下文是否共享
多 Agent 系统首先要决定各 Agent 是否共享上下文。共享上下文是指后续 Agent 继承前序 Agent 的完整轨迹，包括用户消息、模型回复、工具调用和工具结果。角色虽然发生变化，但历史信息全部保留，因此信息不容易丢失，适合阶段连续、前后依赖很强的任务。问题是上下文会持续膨胀，而且前一个角色形成的“思维惯性”也可能干扰后一个角色，使当前 Agent 无法专注于自己的职责。
不共享上下文则让每个 Agent 拥有独立的上下文、轨迹和状态。Agent 之间不能直接看到彼此的完整工作过程，只能通过显式接口传递结果。这样更容易实现模块化、权限隔离和并发执行，也能防止某个 Agent 的大量试错过程污染其他 Agent 的上下文。但代价是必须设计清晰的信息交接机制，否则容易出现信息丢失、重复、误解和状态不同步。
不共享上下文时，Agent 间通信本质上类似分布式系统中的进程通信，主要有三种方式：工具调用参数适合传递结构化、小规模数据；共享文件系统适合传递文档、代码等较大产物；消息总线适合多个 Agent 异步通信。工程上应尽量传递结构化结果和产物引用，而不是把另一个 Agent 的完整轨迹重新塞进当前上下文。
1.2 维度二：协作拓扑
第二个设计维度是控制权如何在 Agent 之间流动。对等协作模式通常由少量 Agent 相互审核、讨论和迭代，适合生成—审核、提议—验证等任务；管理者模式由一个 Manager Agent 负责拆解任务、分配子任务、监控进度和汇总结果，适合复杂任务和大量并行子任务；去中心化模式没有唯一的中央控制者，各 Agent 根据自身职责自主决定何时移交、请求反馈或协调资源。
可以把多 Agent 架构理解为一种执行图设计：节点可以是 Agent、程序或人工决策，边表示任务依赖、条件路由和失败后的去向。真正需要设计的不是“我要放几个 Agent”，而是哪些职责必须隔离、哪些信息必须共享、哪些步骤可以并行、谁拥有控制权、如何验收结果。
二、多 Agent 何时真正优于单 Agent
判断是否需要多 Agent，最关键的标准不是 Agent 数量，而是协作过程是否引入了新的、可验证的信息。如果多个 Agent 只是看着完全相同的上下文互相讨论，那么它们本质上只是在重复处理相同信息；即使输出更多，也不一定比给一个 Agent 更多推理预算更有效。相反，当协作中加入代码执行结果、测试结果、网页检索、视觉截图、真实环境状态或其他外部工具反馈时，新信息会进入循环，Agent 才有可能真正纠正之前无法发现的错误。
因此，“多个 Agent 看同一段文本互相辩论”和“生成 Agent + 执行/审核 Agent”是两类不同的系统。前者的额外收益可能主要来自更多计算量，后者则通过外部环境形成真实反馈环路。例如 Coding Agent 写完代码后，Reviewer 不是单纯重新阅读代码，而是实际运行测试；PPT Agent 生成页面后，Reviewer 应查看真实渲染截图；事实核查 Agent 应访问外部来源，而不是只让模型自我评价。
关注步骤预算与成本
单纯把 Agent 的最大步骤数从几十步提高到几百步，并不能保证效果提升，因为模型未必知道如何使用额外预算。更合理的做法是引入预算感知机制：任务开始时允许更广泛的搜索和探索，随着剩余预算减少逐渐聚焦最有希望的方案。Manager 在拆分任务时也应根据复杂度动态分配步骤预算，简单子任务使用较少步骤，复杂任务给予更充足的工具调用和迭代机会，同时要求子 Agent 按“规划 → 实现 → 测试 → 修正”的方式使用预算。
多 Agent 还必须显式关注成本。并行搜索、反复审核和多个模型实例会快速增加 token、API 调用和运行时间。因此，多 Agent 的目标不是单纯提高成功率，而是判断成功率提升是否值得额外成本。如果性能只提升很少，却增加数倍 token 消耗，那么经过良好设计的单 Agent 可能更加合理。
自己搭建多 Agent 项目是否需要计算指标？
需要。 如果只是把多个 Agent 串起来，只能证明“系统能运行”，不能证明“多 Agent 比单 Agent 更好”。项目至少应该设置一个单 Agent baseline，然后在相同模型、相同任务集和相近实验条件下比较多 Agent 系统。最建议记录五类指标：任务成功率或 Pass Rate 用来衡量是否真正完成任务；任务质量指标用于衡量最终输出质量；平均延迟用于衡量速度；Token/API Cost 用于衡量资源消耗；失败率、重试次数或平均步骤数用于衡量稳定性。
| 指标 | 单 Agent | 多 Agent | 目的 |
|---|---|---|---|
| Task Success / Pass Rate | 基线 | 对比 | 是否真正提高完成率 |
| 平均执行时间 | 基线 | 对比 | 并行是否真的加速 |
| 平均 Token / API Cost | 基线 | 对比 | 性能提升付出了多少成本 |
| 平均工具调用/步骤数 | 基线 | 对比 | 是否存在无效循环 |
| Failure / Retry Rate | 基线 | 对比 | 系统是否更稳定 |
还可以额外做一个简单消融实验，例如“单 Agent”“多 Agent 但无外部反馈”“多 Agent + 测试/搜索/视觉反馈”三组对比。这样能直接证明：提升究竟来自 Agent 数量，还是来自真正的新信息和验证机制。
三、共享上下文的多 Agent 协作
共享上下文模式中，每一个阶段虽然可以视为不同角色的 Agent，但后续 Agent 会继承前序 Agent 的完整轨迹。它最大的优势是信息不会丢失，例如 Research Agent 搜到的事实、Coding Agent 使用过的参数、Data Analysis Agent 得到的中间结果都仍然存在。它的问题也很明显：历史越长，当前 Agent 越容易受到无关信息和前序角色思路的干扰，因此核心问题是如何切换角色，同时让当前 Agent 聚焦自己的职责。
角色切换有两种主要方式。第一种是 transfer_to_agent，切换 system prompt，同时通常切换工具集。它的优势是权限边界强，当前角色看不到不应该使用的工具，但 system prompt 和工具 schema 变化会破坏静态前缀，降低 KV Cache 复用。第二种是 Skill：system prompt 和工具集合保持稳定，需要某个角色能力时再加载对应的 SKILL.md。这样静态前缀基本不变，更利于缓存，但 Skill 本质上只是行为指令，并不能形成真正的权限隔离。
工程上的选择原则很清楚：角色差异主要来自知识、流程、写作风格时，优先使用 Skill；角色差异涉及工具权限、数据隔离、合规边界或必须强制禁止某类动作时，使用独立 Agent 或 transfer_to_agent，并由 Harness 在代码层限制工具调用。
实验 10-1 对比的正是这两条路径。系统提示词切换方案让 triage、research、coding、data_analysis、writing 等角色拥有不同工具和 Prompt；Skill 方案则保持固定 system prompt 和工具全集，只在需要时加载角色规则。两种方式都能实现多角色协作，但前者更强调硬隔离，后者更强调稳定上下文与低切换成本。
四、不共享上下文的多 Agent 协作
不共享上下文才是更典型的独立多 Agent 架构。每个 Agent 都拥有自己的上下文、状态和执行轨迹，其他 Agent 无法直接看到其内部过程。系统需要通过显式接口完成协作，因此多 Agent 工程会自然分成两个层面：共享文件、产物引用等构成数据平面；消息、状态、终止和资源调度构成控制平面。
这种模式与操作系统非常相似：LLM 类似 CPU，Agent 轨迹类似进程内存，Agent Runtime 类似内核，工具调用类似系统调用，spawn_subagent 类似创建进程，cancel_subagent 类似 kill，list_agents 类似 ps。这个类比非常重要，因为很多多 Agent 问题本质上都可以借用操作系统和分布式系统已有的解决方法。
4.1 Agent 眼中的文件系统
成熟的多 Agent 系统通常不会让所有 Agent 共用一个混乱目录，而是使用虚拟文件系统统一管理不同来源、权限和生命周期的存储。Agent 专属工作区用于保存草稿、临时文件和调试信息，只对当前 Agent 可见；共享工作区保存多个 Agent 共同使用的中间产物和最终文件；外部挂载资源对应 Google Drive、Notion、Dropbox 等外部数据源；系统内置资源则包括 Skills、模板、参考文档等只读内容。
核心原则是私有试错留在私有工作区，真正需要协作的产物才进入共享空间。Agent 之间最好传递文件路径或产物 ID，而不是直接把大文件内容放入消息和上下文。这样可以控制上下文大小，同时便于追踪产物来源和生命周期。
4.2 Agent 间的通信与控制
Agent 间通信首先需要结构化消息。消息至少要包含发送者、接收者、消息类型和负载，避免使用无法机器解析的自然语言随意交接。Agent 数量少、拓扑固定时可以使用点对点通信；Agent 数量多或需要异步并行时，更适合使用消息总线，由 Agent 发布状态或结果，其他 Agent 根据订阅关系接收。
状态管理不应只依赖“主 Agent 不断轮询子 Agent”。子 Agent 可以主动发送 status_update，也可以将进度写入轻量的 progress.md。完整 trajectory 可以持久化用于调试，但不应作为日常状态同步方式，因为它通常过长。若进度文件长时间没有变化，可以判定 Agent 可能卡住，并触发超时、重试或终止。
执行终止必须区分优雅终止与强制终止。优雅终止时，Manager 发送 terminate 信号，子 Agent 在安全点停止当前工作，关闭浏览器、释放锁、保存必要状态并返回确认；只有在 Agent 长时间无响应时才使用强制终止。父 Agent 被取消时，它创建的子 Agent 默认也应级联取消，避免产生无人管理的“孤儿 Agent”。
资源调度同样必须进入 Harness，而不能完全交给模型自由决定。Agent 世界中最稀缺的资源是 token、API 并发和执行时间，因此创建子 Agent 时应设定步骤/token 预算、并发上限和超时；困难任务可以分配强模型和更多预算，机械任务使用低成本模型；当任务优先级变化时，也应允许运行时抢占低优先级任务。
可直接转成 Harness / Prompt 的约束：
- 子 Agent 只接收完成当前任务所必需的上下文，不默认继承其他 Agent 的完整轨迹。
- Agent 间只传递结构化消息、明确事实和产物引用，不把未验证推理当作事实交接。
- 每个子 Agent 必须有步骤、token、时间预算和明确的完成条件。
- 长任务必须周期性更新状态；超过设定时间无进度则触发超时处理。
- 收到 terminate 后先清理资源并确认退出；无响应时才允许强制终止。
- 父 Agent 终止时，默认级联终止其全部子 Agent。
- 共享文件写入必须使用并发控制或工作副本隔离，避免多个 Agent 相互覆盖。
4.3 对等协作模式：相互制衡与迭代改进
对等协作一般只需要 2—3 个 Agent，它们没有严格的上下级关系，而是通过独立生成、验证、批评和修正形成循环。真正有价值的并不是“创建多个相同 Agent”，而是让不同 Agent 拥有不同的信息、工具、模型、上下文或职责，否则多个高度同质的 Agent 很可能独立犯同一种错误。
4.3.1 Loop 工程
Loop 工程解决的是 Agent 最常见的“过早终止”问题：只完成一部分就声称完成；某一种方案失败后立即宣布任务失败；或者看似成功但实际没有完成真实闭环。Loop 工程的核心思想是把 Agent 从“一次生成答案”改造成“发现下一步 → 执行 → 验证 → 更新状态 → 决定是否继续”的持续循环。
因此，“任务是否完成”不能由执行 Agent 自己一句话决定，而要由可验证条件决定。例如 Coding Agent 必须通过测试才允许结束，网页任务必须检查页面最终状态，退款任务必须确认真实订单状态。循环的瓶颈不是模型，而是验证器。 如果验证条件本身不可靠，循环次数再多也只是反复制造错误。
4.3.2 提议者-审核者范式
提议者—审核者是典型的对等多 Agent 结构。Proposer 负责生成候选方案，Reviewer 负责基于独立证据检查结果。如果审核不通过，Reviewer 给出可定位的问题，Proposer 再修复，直到通过或预算耗尽。
关键约束是：Reviewer 必须看到独立证据。 代码审核应运行测试，PPT 审核应看渲染截图，事实审核应访问外部来源。只让 Reviewer 重新阅读 Proposer 的文字，本质上只是让模型“再想一遍”，无法稳定带来提升。另外，Reviewer 不应有权限修改测试、证据采集器或最终发布门槛，否则独立审核会退化为自我批准。
4.3.3 辩论模式
辩论模式让不同 Agent 从相反立场分析同一问题，有助于强制暴露支持证据和反对证据。但它不应被理解为“只要辩论就一定更强”。如果所有 Agent 使用完全相同的信息，只是反复传递文字，在相同计算预算下并不一定优于单 Agent。因此辩论更适合作为结构化分析方法，而不是默认的性能提升手段。
4.3.4 头脑风暴模式
头脑风暴模式强调独立生成和解空间覆盖。不同 Agent 先独立提出方案，再共享结果进行组合和扩展。它适合创意、方案搜索和开放性任务，但前提是需要主动制造差异，例如使用不同角色、信息源、工具或模型，否则多个 Agent 容易生成高度相似的答案。
4.3.5 专家小组模式
专家小组模式让不同 Agent 分别代表不同专业视角，例如工程、产品、运营、安全等。它的价值来自职责互补而不是重复推理。每个 Agent 应只对自己负责的专业维度给出分析，然后由统一机制整合，并明确冲突如何裁决。
4.4 管理者模式：中心化协调
管理者模式适合任务较复杂、子任务较多或依赖关系明显的场景。Manager 先理解总体目标，再进行任务分解，选择合适的 Agent 执行，跟踪进度，在失败时重试、换 Agent 或重新规划，最后汇总结果。从实现角度看，每个专业 Agent 都可以被封装成 Manager 的一个“工具”。
Manager 是整个架构的关键瓶颈。如果任务分解本身错误，后续子 Agent 即使能力很强，也会在错误方向上高质量执行。因此最强模型、最好的任务规划 Prompt 和最完整的全局状态通常应该优先给 Manager，而不是平均分配给所有 Agent。同时 Manager 的上下文中只应保存任务目标、计划、Agent 状态和文件索引，不应保存所有子 Agent 的完整执行轨迹和大规模产物内容。
管理者模式可以顺序执行，也可以并行执行。顺序模式适合有明确依赖关系的任务；并行模式适合相互独立的搜索、分析和处理任务。并行时必须额外处理状态监控、竞态条件和级联终止。例如多个 Agent 同时搜索，只要一个找到目标，Manager 就应该锁定成功状态并终止其他 Agent，避免重复汇总和继续浪费 token。
4.5 去中心化模式
去中心化模式没有唯一 Manager，每个 Agent 根据自身职责自主决定何时与其他 Agent 通信、何时移交任务、何时请求帮助。它可以降低中心 Manager 成为单点故障的风险，但会提高路由、权限和循环控制的复杂度。
MetaGPT 展示了 SOP 驱动和标准化“移交包”的价值：下游 Agent 不需要知道上游的完整思考，只需要任务描述、验收标准、已经确认的事实以及产物路径。AutoGen Group Chat 属于共享对话记录加中心化发言选择器的混合模式；OpenAI Swarm 更强调 Agent 之间直接 handoff，控制权在网络中流转。
去中心化 handoff 必须携带明确的 goal、constraints、accepted_facts、artifact_refs、remaining_budget 和访问历史。运行时必须记录已经访问过哪些 Agent，并设置最大移交次数，否则容易出现 A → B → A 的无限循环。
4.6 跨组织协作：A2A 协议
当多个 Agent 来自不同团队甚至不同公司时，内部消息总线和共享文件系统已经不够，需要统一的跨组织协议。A2A（Agent2Agent）用于解决 Agent 与 Agent 之间的互操作问题，主要包括能力发现、任务生命周期管理和不透明协作。
Agent Card 用于声明一个 Agent 的能力、输入输出形式和认证方式；Task 状态机用于描述已提交、执行中、等待输入、完成和失败等状态；Artifact 用于交换最终产物，而不暴露内部 system prompt、思考过程和工具实现。可以把 MCP 和 A2A 区分为：MCP 解决 Agent 如何调用工具，A2A 解决 Agent 如何调用或协作其他 Agent。
五、多 Agent 协作的失败模式
多 Agent 的错误与普通程序不同。传统程序常见的是“崩溃”，而 Agent 更危险的故障是继续正常运行，却生成错误结论。因此多 Agent 系统不能只监控进程是否活着，还必须验证结果是否正确。系统设计应重点防止接口不清、Agent 目标不一致和任务验证缺失。
5.1 失败模式一：共享文件系统的并发冲突
多个 Agent 同时修改共享文件时，会出现文件覆盖和逻辑冲突。版本号、时间戳和乐观锁可以解决同一文件的写入冲突；Coding Agent 并行修改同一代码库时，更适合为每个 Agent 创建独立 Git branch 或 worktree，最后统一合并。需要注意，乐观锁只能处理文件级冲突，跨文件的语义矛盾还需要更高层的集成测试和一致性检查。
5.2 失败模式二：错误的级联放大
Agent 间传递的不是完全精确的字节，而是自然语言语义。一个 Agent 的错误结论如果被下游 Agent 当作事实继续加工，错误会不断放大。因此重要事实不能只沿着一条 Agent 链传递，应让 Reviewer 直接访问原始证据进行独立交叉验证，而不是阅读上游 Agent 的全部推理再进行复述。
5.3 失败模式三：同质趋同
多个 Agent 并不天然代表多个独立意见。如果它们使用同一个模型、类似 Prompt、相同工具和相同上下文，就可能独立产生完全相同的错误。要获得真正的多样性，需要在模型、工具、信息源、角色职责或可见证据上主动制造差异，同时通过命名空间、配额和速率限制避免多个 Agent 同时争抢同一资源。
5.4 失败模式四：互相扯皮
当多个 Agent 的目标、权限和责任边界不清晰时，可能出现相互推诿甚至相互阻塞。解决方法不是简单增加 Prompt，而是在 Harness 层提前规定任务所有者、目标优先级、资源所有权、冲突处理规则和人工升级条件。无法依据规则解决的冲突应暂停执行，而不是允许 Agent 自行扩大权限。
5.5 失败模式五：循环失控
多 Agent 不仅会过早停止，也可能完全停不下来。例如 Agent 不断创建新的子 Agent、相互移交任务或反复修订，最终造成 token 和 API 成本失控。因此系统必须设置最大 Agent 数、最大递归深度、最大 handoff 次数、token/费用预算和全局截止时间，这些限制应由运行时控制，而不是仅写在 Prompt 中。
5.6 失败模式六：理解债与认知投降
Agent 自动生成代码和复杂产物的速度可能远远超过人的理解速度，最终形成“理解债”：系统已经变化很多，但开发者无法解释其真实实现。一旦发生严重故障，人也无法有效接管。使用 Agent 不意味着把理解和责任一起外包，关键架构、权限边界、验证逻辑和核心代码仍然需要人能够审查和解释。
六、Agent 社会
Agent 社会研究的是当 Agent 数量从几个扩展到几十、几百甚至更多时，系统是否会出现单个 Agent 规则中没有显式定义的群体行为。这里关注的已经不只是任务分工，而是社交关系、信息传播、经济竞争和策略博弈等涌现现象。
6.1 斯坦福 AI 小镇：生成式 Agent 的社会模拟
斯坦福 AI 小镇通过记忆流、反思机制和计划/行动机制，让多个 Agent 在虚拟社区中持续生活。记忆流记录 Agent 经历的事件和对话，并根据时近性、重要性和相关性进行检索；反思把具体事件进一步概括成高层认识；计划机制负责长期安排，同时允许 Agent 根据环境变化即时调整。
这个实验最重要的现象不是“Agent 能完成某个任务”，而是很多群体活动并没有被显式写进程序。例如信息可以通过社交网络逐步传播，多个 Agent 可以在没有中央调度的情况下协调时间和地点。这说明当记忆、行动和社交机制结合后，会出现自下而上的协调行为。
6.2 Agentopia：十年尺度的长期生活模拟
Agentopia 把模拟时间从几天扩展到多年，通过周期性的 Plan、Contact、Activity 和 Review，让 Agent 形成长期社会关系、职业和经济状态。它还引入环境模型对行动可行性和社会反馈进行外部评估，并使用文件系统保存长期记忆。
值得注意的是，Agentopia 不只观察 Agent 社会，还把长期社会轨迹转化为训练信号。也就是说，多 Agent 社会本身可以成为经验生成环境，为第九章所讨论的持续进化提供新的数据来源。
6.3 Moltbook：当 Agent 拥有自己的社交网络
Moltbook 展示了更大规模、开放环境中的 Agent 社交。当大量拥有长期记忆和主动行为能力的 Agent 在同一网络中互动时，可能出现人类没有显式设计的文化、协议和协作规则。这类现象说明，Agent 数量扩大后需要研究的不只是单 Agent 安全，还包括群体行为、信息传播和社会规范。
6.4 从虚拟社会到经济竞争：Vending-Bench Arena
Vending-Bench Arena 把多个 Agent 放进同一市场，每个 Agent 独立经营、定价、采购和竞争。与单 Agent 环境相比，环境本身不再固定，因为其他 Agent 也在根据局势调整策略，因此问题从普通规划变成了动态博弈。
这类环境可以用于测试长程决策、资源分配、竞争策略和协作行为，同时也暴露了多 Agent 系统可能出现的价格战、隐式协调甚至不符合预期的合谋行为。
6.5 Agent 经济：Pinchwork 与 RentAHuman
Agent 经济把任务分配从中心 Manager 转变为市场机制。Agent 可以发布需求，其他 Agent 根据能力和价格竞争任务；当数字 Agent 无法执行现实世界动作时，也可以通过平台把任务交给真人。它说明多 Agent 的资源协调不一定只能依靠固定拓扑，还可以利用市场和价格完成去中心化匹配。
6.6 信息不对称下的策略博弈：狼人杀
狼人杀实验展示的是信息权限对多 Agent 推理的重要性。不同角色只能看到各自被允许看到的信息，游戏状态则由代码驱动的法官统一维护。这里的关键工程原则是：权限控制必须由环境或 Harness 实现，不能依靠 Prompt 要求 Agent“假装不知道”。
这种系统同时包含中心化状态管理和多个独立 Agent，因此适合测试角色推理、实时交互、长期状态维护和信息不对称条件下的策略行为。
实验
5-1 比较角色切换与按需加载技能
Transfer 2/30、Skill 15/30。
七、本章小结
多 Agent 系统并不是简单地把一个 Agent 复制成多个实例。是否应该使用多 Agent，首先要问：任务是否需要独立上下文、专业分工、并行搜索、权限隔离或外部验证？如果多个 Agent 只共享同一段信息反复讨论，那么增加 Agent 数量本身并不保证性能提高；真正有效的协作通常依赖代码执行、视觉反馈、工具结果和真实环境状态等信息增量。
架构设计上要同时考虑上下文共享方式和控制拓扑。共享上下文简单、信息完整，但容易膨胀和产生角色干扰；不共享上下文更适合复杂工程系统，但必须设计清晰的移交包、共享文件、消息协议、生命周期和资源预算。对等模式适合生成—验证循环，管理者模式适合复杂任务的集中编排，去中心化模式适合自主移交和弱中心协调。
工程实现中最重要的不是“Prompt 写得多复杂”，而是把关键约束下沉到 Harness 和 Runtime：工具权限、预算上限、超时、并发控制、终止、文件版本、循环检测、验收门槛都应该由代码强制执行。Prompt 负责告诉 Agent“应该怎么做”，Harness 负责保证 Agent“不能越界做”。
最后，搭建自己的多 Agent 项目时必须保留单 Agent baseline，并通过任务成功率、结果质量、延迟、token/API 成本和失败率等指标验证多 Agent 是否真的产生价值。一个好的多 Agent 项目不只是“有很多 Agent”，而是能够说明：为什么需要这些 Agent、每个 Agent 为什么必要、它们引入了什么新信息，以及性能提升是否值得额外成本。
更多推荐
3
0- 0
已为社区贡献1条内容
所有评论(0)