第十章 多 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 复用。第二种是 Skillsystem prompt 和工具集合保持稳定需要某个角色能力时再加载对应的SKILL.md。这样静态前缀基本不变更利于缓存但 Skill 本质上只是行为指令并不能形成真正的权限隔离。工程上的选择原则很清楚角色差异主要来自知识、流程、写作风格时优先使用 Skill角色差异涉及工具权限、数据隔离、合规边界或必须强制禁止某类动作时使用独立 Agent 或transfer_to_agent并由 Harness 在代码层限制工具调用。实验 10-1 对比的正是这两条路径。系统提示词切换方案让 triage、research、coding、data_analysis、writing 等角色拥有不同工具和 PromptSkill 方案则保持固定 system prompt 和工具全集只在需要时加载角色规则。两种方式都能实现多角色协作但前者更强调硬隔离后者更强调稳定上下文与低切换成本。四、不共享上下文的多 Agent 协作不共享上下文才是更典型的独立多 Agent 架构。每个 Agent 都拥有自己的上下文、状态和执行轨迹其他 Agent 无法直接看到其内部过程。系统需要通过显式接口完成协作因此多 Agent 工程会自然分成两个层面共享文件、产物引用等构成数据平面消息、状态、终止和资源调度构成控制平面。这种模式与操作系统非常相似LLM 类似 CPUAgent 轨迹类似进程内存Agent Runtime 类似内核工具调用类似系统调用spawn_subagent类似创建进程cancel_subagent类似 killlist_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 来自不同团队甚至不同公司时内部消息总线和共享文件系统已经不够需要统一的跨组织协议。A2AAgent2Agent用于解决 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 ArenaVending-Bench Arena 把多个 Agent 放进同一市场每个 Agent 独立经营、定价、采购和竞争。与单 Agent 环境相比环境本身不再固定因为其他 Agent 也在根据局势调整策略因此问题从普通规划变成了动态博弈。这类环境可以用于测试长程决策、资源分配、竞争策略和协作行为同时也暴露了多 Agent 系统可能出现的价格战、隐式协调甚至不符合预期的合谋行为。6.5 Agent 经济Pinchwork 与 RentAHumanAgent 经济把任务分配从中心 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 为什么必要、它们引入了什么新信息以及性能提升是否值得额外成本。