多 Agent 协作
前九章围绕单个 Agent 展开；这一章把问题推进到如何组织多个 Agent——让它们通过分工、通信与相互验证，完成单个 Agent 难以承担的任务。
为什么需要多 Agent
在 OpenAI 曾提出的五级 AI 能力框架中，多 Agent 协作常被类比为通向第五级的路径之一：
这里的 Organizations 指的是「AI 能完成整个组织的工作」这一能力级别，而非对系统架构的要求——足够强大的单个 Agent 理论上也能达到。只是就今天的工程现实而言，单 Agent 终究受限于模型能力边界和上下文窗口。
人类文明便是明证——单个人的智力有限，但经由分工、协作、辩论和知识的代际累积，整体智能远超任何一位天才个体。Agent 群体同样可能涌现集体智能：哪怕每个 Agent 只相当于人类专家水平，只要组织得当，整体能力也可能超过所有人类专家的总和。
Google DeepMind 在《从 AGI 到 ASI》中正把「大规模多 Agent 集体」列为通往超级智能（ASI）的关键路径之一。[1]
阅读地图
FRAMEWORK两个核心设计维度
要构建多 Agent 系统，首先需要理解两个核心设计维度，它们共同决定了系统的基本架构和实现方式。
维度一：上下文是否共享
这是最基础的架构决策，决定了多个 Agent 之间如何传递信息。
优势：信息不丢失，可回顾任何阶段的细节。
挑战：上下文可能快速膨胀。
优势：模块化、隔离性好，易扩展维护。
挑战：必须设计显式通信机制。
共享上下文就像团队里需求分析师写完文档后，开发者不仅拿到文档，还能看到分析师与用户的所有沟通记录——他是一个新角色，但完整保留了之前的上下文。
三种通信机制（本质是 IPC 的两大范式）
由于 Agent 之间不共享上下文，必须通过显式通信传递信息。这个问题在经典分布式系统中早有答案：进程间通信（IPC）归根结底只有两大范式——共享内存与消息传递。
「不要通过共享内存来通信，而要通过通信来共享内存。」两种范式各有取舍。
维度二：协作拓扑
Agent 之间的控制权和信息按什么结构流动。三种典型形态：
2026 年 7 月开始流行的「Graph Engineering」，在当前 Agent 语境中通常指显式设计执行图：节点是 Agent、普通程序或人工决策，边定义任务依赖、条件路由与失败后的去向，结构化状态在节点之间流动。本章的「协作拓扑」正是其中的多 Agent 子集——对等协作、管理者编排和去中心化移交，都是不同的图拓扑。
CRITERION判据：多 Agent 何时真正优于单 Agent
在进入具体架构之前，先回答一个更根本的问题：什么时候真正需要多个 Agent，什么时候一个就够了？近年的一系列研究给出了一个清晰的判断框架——核心判据只有一条：
协作过程是否引入了单个 Agent 在生成时无法获得的新信息？
| 协作模式 | 是否引入新信息 | 效果 |
|---|---|---|
| 同一模型自我审查（重新阅读自己的输出） | 否 | 通常无效甚至有害 |
| 不同 Agent 辩论同一段文本 | 否 | 在等计算量下与单 Agent 持平 |
| 审核者使用测试执行结果审查代码 | 是（执行反馈） | 显著提升 |
| 审核者查看渲染截图审查前端/PPT 代码 | 是（视觉反馈） | 显著提升 |
| 审核者使用外部工具验证事实 | 是（工具反馈） | 显著提升 |
三项实证
一些学术研究认为多 Agent 不能提升能力上限，但工程实践中多 Agent 确实更好。矛盾的根源在于两者讨论的是不同类型的「多 Agent」：学术研究比较的多是「多个 Agent 看着同一段上下文互相讨论」，工程实践中有效的系统往往包含外部反馈环路（代码执行、视觉渲染、工具调用）。前者没有引入新信息，后者引入了。
步骤预算与成本
一个相关的研究方向：给 Agent 分配不同的步骤预算（允许的工具调用次数或迭代轮数），会如何影响表现？
单纯增加 Agent 可用的步骤数并不能保证性能提升。标准 Agent 缺乏「预算意识」——即使有 300 步预算，仍倾向于执行浅层搜索，很快就「饱和」了。
要让更多步骤真正转化为更好的结果，Agent 需要显式的预算感知机制，根据剩余资源动态调整策略：
2026 年的 BAVT（Budget-Aware Value Tree Search）进一步提出步骤级别的价值评估，在每一步根据剩余预算比例调整探索与利用的权重。
管理者模式中，Manager 不应只是简单分发任务然后等待，而应根据复杂度动态分配步骤预算——简单子任务给较少步骤，复杂子任务给充足步骤。同时引导子 Agent 合理利用预算（先规划、再实现、再测试、再改进），而不是一头扎进去直接开干。
多 Agent 的并行探索与反复迭代都要消耗大量 token。这意味着收益必须足够大，能覆盖数倍乃至一个数量级的额外开销，否则一个调校得当的单 Agent 往往是更划算的选择。
ARCH · 2不共享上下文：真正的多 Agent 协作
每个 Agent 都是独立实体，拥有自己的上下文、轨迹和状态，彼此无法直接访问对方的「内心活动」，协作完全依赖三种通信机制。
与操作系统的完整对应
沿着「通信机制即进程间通信」的线索再走一步，会发现对应关系相当完整：
| 操作系统 | 多 Agent 系统 |
|---|---|
| 程序（可执行文件） | 静态前缀（系统提示词 + 工具定义） |
| 进程的内存 | 轨迹 |
| CPU | LLM |
| 内核 | Agent 运行时 |
| 系统调用 | 工具调用 |
| fork（创建子进程） | spawn_subagent |
| kill（发送信号） | cancel_subagent |
| ps（列出进程） | list_agents |
| 退出码与 wait() | 子 Agent 返回的结构化摘要 |
| 共享内存 / 消息传递 | 共享文件系统 / 消息 |
私有状态、异步消息、可创建新成员，正是 1970 年代 Actor 模型的基本设定[5]——多 Agent 系统不妨看作它的 LLM 版本。因此操作系统与分布式系统的成熟经验大多可以直接借用。
· 新增能力不需改动现有代码
· 单个 Agent 故障不会传染错误状态
· 上下文完全独立，可真正并发执行
· 信息传递中可能丢失或重复
· 调试困难：需翻看多个 Agent 的日志才能拼出完整执行过程
→ 因此接口规范、数据格式、通信协议的设计至关重要
不共享上下文的显式协作依赖两套与拓扑无关的基础设施：
Agent 眼中的文件系统
在实际系统中，Agent 访问的并非单一存储，而是一个虚拟文件系统：来源、生命周期与权限各异的存储被挂载到同一目录树下，Agent 通过统一的 read_file/write_file/list_dir 接口访问，底层则可能是本地临时盘、持久对象存储、第三方云盘 API 或只读系统资源包。
相当一部分并发冲突与信息泄露，源于将本应隔离的区域混置。这棵目录树相当于 Agent 的地址空间，四类区域就是权限各异的内存段：有的私有可写，有的多方共享，有的只读。
① 避免多个 Agent 的临时文件相互覆盖；② 保持主 Agent 上下文的精简——子 Agent 的试错过程留存于自身工作区，仅将最终产物提交至共享空间。这是「子 Agent 返回结构化摘要而非全量轨迹」在存储层面的体现。
Agent 间传递产物、主 Agent 向子 Agent 交接输入、乃至跨组织 A2A 协作交换产物，传递的均为轻量的路径字符串，而非将内容载入上下文窗口。
Agent 间的通信与控制（控制平面）
文件系统解决了产物交换，协作还需要一条控制平面。第四章给出的一组工具原语正对应进程世界：
≈ fork
≈ 消息
≈ kill
≈ ps
一、消息传递
最简形态是点对点，适用于拓扑固定、Agent 数量少的场景。当 Agent 增多且需异步并行时，点对点连接数随 Agent 数呈平方增长，且要求收发双方同时在线；此时应改用消息总线。
发送者 ID、目标（指定 Agent 或广播）、消息类型（如 task_assigned / status_update / result / terminate）及 JSON 负载。统一信封保证接收方能可靠路由和解析，并使协作链路可追溯——这是多 Agent 系统调试的关键。
二、状态查询（最易被低估的一环）
定义 get_subagent_status(agent_id) 拉取式接口。但子 Agent 一经创建就立即执行直到完成或失败，完成时自然会通知主 Agent，并不需要显式查询。
更自然的做法是回到两大通信范式：
反过来，子 Agent 也可在关键节点主动汇报（往总线发布
status_update）。状态宜采用统一的状态机词汇：执行中、需要输入、已完成、失败。
但轨迹动辄数万 token，不宜作为主要传递方式。
主 Agent 启动子 Agent 时约定「把进度写到 progress.md」，子 Agent 每完成一项就更新清单。这相当于两个进程在共享内存里划出一小块约定格式的状态区，暴露的是提炼后的进度，而非全部内存。
进度文件还可用于检测卡住状态：最后修改时间超过 N 分钟无变化，即判定无活动、触发超时兜底。
三、执行终止
并行协作中常出现「一个任务成功，其余便无需继续」。终止有两种强度——Unix 用户会认出这正是 SIGTERM 与 SIGKILL 的区别：
| 强度 | 做法 | 代价 |
|---|---|---|
| 优雅终止（首选） | 发 terminate 信号，子 Agent 在当前步骤的安全点响应，先清理资源（关闭浏览器会话、写入未完成文件、释放锁），返回 ack 后退出 | 需要 Agent 配合轮询 |
| 强制终止（兜底） | 直接终止进程，仅在对优雅信号无响应时使用 | 可能遗留悬挂资源与未完成写入 |
工程上最简洁的做法借鉴 Go 的 context：终止沿创建关系向下级联——取消一个 Agent，它派生的所有子 Agent 随之取消，从根上杜绝无人认领的孤儿 Agent。「子 Agent 在安全点检查终止信号」对应的正是对 ctx.Done() 的轮询。
若确实需要脱离主 Agent 长期运行的后台 Agent（类似 Unix 的 nohup），就让它从一棵新的生命周期树起步（对应 context.Background()），显式声明不随父级终止。
四、资源与调度
操作系统的一个重要职能是分配稀缺资源。进程世界稀缺的是 CPU 时间和内存，Agent 世界稀缺的是 token 和并发额度。
- 启动子 Agent 时设定步数或 token 预算，超限即止
- 困难任务交给强模型，机械任务交给低成本模型
- 并发数设上限，避免几十个 Agent 同时耗尽 API 配额
- 并发达上限时，更紧急的任务到来可打断执行中的子 Agent——这就是抢占
可以启动多个子 Agent 并行探索一个问题，根据进展决定给谁分配更多资源、终止哪些看起来误入歧途的 Agent——就像公司内部赛马一样。
资源和调度领域的实践还远不如操作系统调度成熟，但它决定了多 Agent 系统的成本上限，应在架构设计阶段就予以考虑。
TOPOLOGY · 1对等协作模式：相互制衡与迭代改进
通常涉及 2-3 个平等身份的 Agent，通过多轮迭代互相提供反馈。潜在价值在于引入独立视角和认知多样性。
当模型、上下文和脚手架高度相似时，不同 Agent 往往会做出相同选择，使局部错误演变为系统性故障。要获得真正的多样性，需要主动区分模型、上下文、工具、可见证据或职责，并让各 Agent 先独立判断、再汇总结果。[4]
相比管理者和去中心化模式，对等协作的实现复杂度更低：只需定义好两个 Agent 的角色、通信机制和迭代终止条件。
Loop 工程
对等协作最经典的用途，是解决 Agent 实践中极其常见的一类失败：过早终止——活干到一半就停。
| 形态 | 表现 | 例子 |
|---|---|---|
| 偷懒式假完成 | 只做了一部分就宣称全部做完 | Coding Agent 写完代码，测试没跑、部署没试就报「任务完成」；用户交办两件事，办完第一件就忘了第二件 |
| 过早放弃 | 一条路走不通就宣布整件事办不成 | 联系商家本有电话、表单、邮件多种途径，打了一个电话被拒绝就告诉用户「这事办不了」 |
| 假成功 | 以为办成了，实际闭环没走完 | 电话里对方口头同意退款，但用户还需在 App 上确认一步，Agent 却报告「已办妥」 |
在验证之前，「完成」只是模型的一句宣称，不是证明。
把宣称变成证明，正是 Loop 工程（Loop Engineering）的课题：设计一个让 Agent 持续运转的循环——发现下一件该做的事 → 执行 → 验证 → 记录进度——由验证器而不是模型自己来判定「是否真的可以停」。人的角色则从「给 Agent 写提示词的操作者」变成「设计循环的工程师」。
这个名词在 2026 年 6 月由 Addy Osmani 总结提出[6]；Claude Code 负责人 Boris Cherny 的说法更直白：「我已经不再直接 prompt Claude 了，我的工作是写 loop。」
业界形成的核心共识是：循环的瓶颈在验证器，而不在模型。验证不可靠，循环转得再快，也只是把劣质产出更快地标记为完成。
具体框架一：LoopX
把循环从模型的提示词和聊天历史中抽离出来，放进一个与 Agent 运行时无关的持久控制面：
LoopX 决策 → Agent 执行 → 独立验证器证明 → LoopX 提交目标与边界说明「为什么做」，门禁和待办决定「现在能做什么」，证据与配额决定「是否继续」，移交则让下一轮或另一个 Agent 接着工作。只有通过独立验证的结果才能写入持久进度并消耗配额；验证失败进入修复或重规划，人工门禁、等待状态和预算上限则在执行前阻止循环继续。[7]
模型可以提出「完成」，但不能批准自己的「完成」。
具体框架二：LongHorizon-Harness
同为 Loop 工程实现，但关注方向不同：LoopX 面向长期 Agent 工作的持久控制面；LongHorizon-Harness 从多模态 Computer Use 出发，处理同一任务跨越 GUI、CLI、多个桌面应用和多次上下文刷新的连续执行问题。
它把长程执行重新表述为任务状态管理，循环实现为 Manage–Execute–Audit（MEA）：
据目标/已核实进展/失败证据
生成下一项有界子任务
在全新上下文中
通过 GUI 或 CLI 改变环境
只读方式
检查真实结果
只有审计通过的内容才能进入下一轮任务状态，失败则被保留为恢复和重规划的依据。它通过适配层复用 Claude Code、Codex CLI 等执行后端，而不改写后端内部的 Agent loop。[8]
把任务连续性从不断增长的执行历史中分离出来：上下文可以刷新，界面操作也可能失败，但下一轮仍能从最近一次核实的状态继续。
| 基准 | 基线 | MEA | token 代价 |
|---|---|---|---|
| WeaveBench PassRate | 51.8% | 80.7% | 总 token 2.3× |
| OSWorld 2.0 二元完成率 | 2.8% | 8.3% | 输出 token 3.6× |
| Terminal-Bench 2.1 成功率 | 69.7% | 77.2% | 减少 24% |
外部环境或用户要求变化造成的旧状态失效，并用轮数、时间和费用预算防止恢复循环无限运行。
提议者–审核者范式
最经典的对等协作范式：Proposer 生成，Reviewer 渲染执行结果并评估质量、给出结构化改进建议，两者反复迭代直到达标。适用于安全审查、内容审核、代码审核等场景。
这正是前面判据的具体体现——审查若不引入新信息，就只是「让模型再想一遍」。三项研究给出了明确答案：
- ICLR 2024《LLMs Cannot Self-Correct Reasoning Yet》：让 GPT-4 在无外部反馈下审查修正自己的回答，准确率反而下降——把正确答案改错的次数比把错误改对的更多
- TACL 2024《When Can LLMs Actually Correct Their Own Mistakes?》：除非提供可靠外部反馈，否则纯粹的「自我纠正」几乎不起作用
- ICLR 2024 CRITIC：让模型用外部工具（搜索引擎、Python 解释器）验证回答，效果显著提升；一旦移除工具验证，大部分提升就消失了
最小不变量
审核者读取独立证据，而不是只复述提议者的解释；退回时必须给出可定位的修复条件：
candidate = proposer(task, constraints)
evidence = execute_or_render(candidate) # tests, state, screenshot, facts
review = independent_reviewer(candidate, evidence)
while review.veto and budget_remaining:
candidate = proposer.repair(candidate, review.findings)
evidence = execute_or_render(candidate)
review = independent_reviewer(candidate, evidence)
if review.pass:
publish(candidate, evidence, review)
else:
escalate_or_reject(review)审核者不能修改测试、证据采集器或发布门槛；否则「独立验证」会退化成自我批准。
实现为规划者–生成者–评估者三 Agent 架构：规划者把需求展开为产品规格，生成者与评估者先约定每轮的完成标准，再由生成者实现，然后评估者使用 Playwright 操作真实应用并提交缺陷报告。Agent 之间通过文件交接状态。[9]
其他对等形态
但效果有争议：Tran & Kiela（2026）发现在思考 token 预算被严格控制为相同时，单 Agent 表现与多 Agent 持平甚至更好。[10]
辩论中的多个 Agent 处理的是完全相同的文本信息，Agent 之间每一次串行传递中间结论都只可能丢失信息、不可能凭空创造信息。辩论在部分论文中的收益很可能来源于消耗了更多总计算量。
不过这并不否定另一类做法：对同一问题多次独立采样再聚合（自一致性、多数投票），或利用生成与验证的难度不对称（写出答案难、检验答案易）来做生成-验证分工。
TOPOLOGY · 2管理者模式：中心化协调
当任务涉及大量子任务、需要动态调度或子任务间存在复杂依赖时，对等协作就力不从心了。Manager Agent 的职责就像项目经理：理解整体任务 → 拆解子任务 → 选择合适 Agent → 跟踪进度并处理异常（重试、换 Agent、调整计划）→ 整合最终结果。
从 Manager 的视角看，调用一个 Agent 和调用一个普通工具没有本质区别。这种统一抽象带来两个好处：可扩展性（新增能力只需开发对应 Agent 并注册为工具，Manager 核心逻辑无需修改）与异构性（不同 Agent 可用不同模型、提示词、工具集，甚至运行在不同硬件上）。
Manager 成为系统的单点瓶颈——它必须理解所有子任务性质、选择正确 Agent、准确传递上下文，任何决策偏差都会影响整体流程。此外 Manager 需维护全局上下文，随任务推进可能快速膨胀。
在 Planner-Executor 双 Agent 架构中，当 Planner 规划质量足够高时，即使 Executor 比较简单也能取得好结果；反之若 Planner 分解有误，后续所有 Executor 的工作都建立在错误前提上。该研究在 WebArena-Lite 上取得 54% 成功率，核心贡献正是改善 Planner 而非 Executor。[11]
启示：应当把最强的模型和最精心设计的提示词分配给 Manager，而不是平均分配给所有 Agent。
并行管理器的结算点
必须定义「第一个已验证成功」而不是「第一个声称成功」：
workers = launch_independent_workers(subtasks)
while workers.any_running:
event = next_event()
if event.type == RESULT:
if verify(event.artifact, hidden_checks):
if not settle_once(event): # atomically claim the winner
continue
broadcast_cancel(to = workers - {event.worker_id})
await_all_ack_or_timeout()
return assemble(event.artifact, evidence = event.evidence)
else:
record_failure(event)
return summarize_failures(workers)settle_once 必须是幂等的（通常由锁或事务保护），否则两个几乎同时到达的成功事件会触发两次汇总。
三种协调形态
为什么单 Agent 不行：随着逐章处理，上下文不断累积（全书术语表、已翻译章节、当前段落、思考过程、工具结果），很容易超出窗口。更严重的是在过长上下文中 Agent 容易「迷失」——第九章用了与第二章不一致的译法，甚至「记起」实际不存在的术语规则。
四种 Agent 分工：
· Glossary Agent：识别重复术语，生成结构化术语对照表，写入共享文件系统后即可销毁
· Translation Agent：接收当前章节 + 术语表 + 翻译指南；遇到表中术语严格使用规定译法，新术语则推断并标记待审查。每个实例独立上下文，可并行
· Proofreading Agent：接收所有译文和术语表，执行一致性检查，生成审校报告
· Manager Agent：只维护文件索引而非完整翻译内容，据审校报告把特定章节发回修订
关键优势是上下文隔离：每个 Agent 都在精简、专注的上下文中工作，不仅效率更高，出错可能性也更低。
本地运行、以文件为本的长期 Agent 居所，三种角色完整对应本节概念：
- 主器灵（main agent）：与用户对话的常驻中枢，掌管计划与记忆，派生工作 —— 即 Manager Agent 的位置
- 分神（daemon）：为一件嘈杂而有界的工作分出的短时并行工作者，完成后即弃，只把结论带回 —— 即「返回结构化摘要而非全量轨迹」的产品化
- 分身（avatar）：拥有自己的记忆、邮箱与职责的持久专门化队友，用于跨多次会话保留的专业分工
其余设计也一一呼应：知识是每个器灵私有的持久记忆文件，技能是所有器灵共享的 Markdown 手册；上下文将满时器灵会「凝蜕」（molt）——给自己写一份总结，带着持久记忆在干净上下文中继续。底层模型可以替换而器灵犹在，即「器灵即其文件」。
场景：用户只给一个网站 URL，请 Agent 填写复杂的注册或航班预订表单。姓名、证件号等信息不在上下文中，需向用户收集。
架构：Computer Agent 负责浏览器操作并兼任编排者；Phone Agent 负责 ASR / LLM / TTS 实时对话。不需要额外的 Manager 进程——Computer Agent 可以像调用工具一样调用 Phone Agent。
两种模式：固定模式（预启动两个 Agent，验证并发基线）；自主模式（只启动 Computer Agent，由它自主决定是否调用 initiate_phone_call_agent()，不要用「字段数超阈值」的 Python 规则代替模型决策）。
并行闭环：Phone Agent 逐项提问校验，每收到有效值就发 info_collected，不等网页填写完成便询问下一项；Computer Agent 反馈 fill_error，Phone Agent 据此调整话术。真人语音须显式同意，提交须显式授权。
问题：给定一所大学的多个学院网站，在各学院教师名录中查找指定教师，找到后返回学院、职位、研究方向。
四个核心挑战：
① 并行启动：动态创建 10 个 Computer Use Agent，各自独立进程与浏览器会话
② 实时监控：各 Agent 定期发状态更新，Manager 经消息总线维护任务状态表
③ 级联终止：某 Agent 发 target_found 后，Manager 立即向其余广播 terminate，等待全部 ack（或超时）后汇总
④ 失败处理：超时视为失败、错误隔离、全部失败则报告各失败原因统计
概念补充 · 什么是竞态条件：若 A 和 B 几乎同一毫秒各自找到目标同时上报，Manager 处理不当就可能触发两次汇总，产生重复或矛盾状态。解决方法通常是锁：第一个报告到达后立即锁定状态，后续被识别为重复并忽略。
第三种形态：管理者生成 Agent 工作流
前两种形态里管理者始终待在循环中：每派发一个子任务都要模型做一次决策，上下文随调用次数增长。还有一种做法是——管理者先把 Agent 工作流写成一段代码，再交给确定性的运行时去执行。
Claude Code 内置的 Workflow 工具就是这样一个实例，提供 agent()、parallel()、pipeline() 几个原语；每个 agent() 是一个拥有独立上下文的子 Agent，schema 约定它只返回结构化结论而不是完整轨迹：
const results = await pipeline(
DIMENSIONS, // 七个待核实的方向
d => agent(research(d), { schema: FINDINGS }), // 阶段一：调研
r => parallel(r.findings.map(f => () => // 阶段二：逐条独立核实
agent(verify(f), { schema: VERDICT })))
)
await agent(writeProvenance(results.flat())) // 汇总：等齐所有结果TOPOLOGY · 3去中心化模式
有了管理者模式，为什么还要去中心化？动机主要在于模拟人类社会的组织方式：让多个职责对等的角色分工与制衡，各自从专业视角审视问题、自主决定与谁沟通，而不是把所有判断都汇集到一个 Manager 那里。
由于模型或 API 问题，Agent 可能停止响应、工具调用失败、陷入死循环。在管理者模式中，管理者 Agent 崩溃往往会成为系统最大的单点故障。去中心化有助于解决这一问题。
管理者模式 = 编排（orchestration），由指挥统一调度；去中心化 = 编舞（choreography），靠每位舞者自行把握入场时机。
三个案例：一条递进线索
MetaGPT：SOP 驱动的软件公司模拟
核心洞察：人类软件公司积累的标准作业程序（SOP）本身就是被反复验证过的协作协议——把 SOP 编码进多 Agent 系统，让每个角色像流水线上的专业工种一样产出标准化交付物，交付物天然构成角色间的通信接口。
→ PRD
→ 设计文档
→ 任务清单
→ 代码（可并行）
→ 测试报告
① 任务描述（接收方要做什么、验收标准是什么）；② 已确认的事实与约束（用户偏好、业务规则、前序敲定的决策）；③ 结构化产物的引用（文件路径而非文件内容，接收方按需读取）。
每个角色把结构化消息发布到所有角色可见的消息池，其他角色按订阅配置只取用与自身职责相关的消息——而不是点对点一对一传话。发布者不需要知道谁会消费自己的输出，新增角色只需声明订阅哪些类型。
这带来真正的解耦：把 Product Manager 换成更强的模型，只要发布的 PRD 仍符合规范，其他所有 Agent 都无需修改。
MetaGPT 在控制流上并不是去中心化的——角色顺序由 SOP 预先固定，整体更接近一条流水线（工作流）。它被放在本节讨论，是因为消息池加订阅的通信机制展示了去中心化系统最关键的设计要素：解耦。至于「QA 直接找 PM 澄清需求」这类多向动态反馈，是对该架构的自然扩展设想，原版并未实现。
AutoGen 群聊
多个 Agent 参与同一场会话，每轮由发言者选择器决定下一个发言者（可以是轮转规则，也可以是 LLM 判断谁最适合接话）；任何 Agent 的发言对所有参与者可见。
发言者的选择由中心化的 GroupChatManager 统一裁决，而「轮到谁发言」本身就是一种控制流决策。它是「共享对话记录 + 中心化调度」的混合形态：所有 Agent 看同一份公共对话记录，各自保有独立的系统提示词和工具集，而调度权集中在选择器手里。
OpenAI Swarm
控制流真正实现对等去中心化的代表：每个 Agent 配备若干 handoff（移交）选项，可在任何时刻把控制权移交给网络中的任意其他 Agent。没有中心调度者，控制权像接力棒一样在对等 Agent 间流转，路由决策完全分散在每个 Agent 自己的判断里。
① 上下文泄露：与共享上下文的协作不同，handoff 只应传递明确的任务包和产物引用，不应默认暴露完整私有轨迹；
② 成环：A 移交给 B，B 又移交回 A，任务在环路中空转，因此需要移交次数上限之类的保护机制。
去中心化 handoff 的最小协议：
handoff = {
task_id, sender, recipient, goal, constraints,
accepted_facts, artifact_refs, remaining_budget,
visited_agents
}
if recipient in handoff.visited_agents:
reject("cycle")
elif handoff.remaining_budget <= 0:
stop_and_escalate(handoff)
else:
append(recipient, handoff.visited_agents)
run_local_agent(handoff)接收者读任务包和引用、按需取证；预算、访问链和循环检测由运行时保留，不能由任一 Agent 自行删除。
2025 年以来该词成为热门，业界用法大致有两类：
- 其一：handoff 网络（OpenAI Swarm 式，LangGraph swarm 库、微软 Agent Framework 的 handoff 编排同此）——即本节的去中心化模式
- 其二：规模化的管理者模式。Kimi K2.5 首发的 Agent Swarm 由主 Agent 动态创建上百个子 Agent 并行执行，把「何时拆、拆几个」的编排决策通过并行 Agent 强化学习直接训练进模型；K3 将其延续为独立模型档位并开源配套沙箱 AgentEnv[13]。Anthropic 的多 Agent 研究系统与 Manus 的 Wide Research 同属 orchestrator-worker 星型拓扑
希望读者能看清概念背后的实质，分析不同系统的实际结构，而不被名称迷惑。
同一台机器上的多个对等 Agent 实例
以上三个系统的 Agent 都在合作完成同一件事；还有一类去中心化则是各干各的：每个 Agent 有自己的任务，通信不是为了分工，而是为了协调使用共享资源。Claude Code 已支持同一台机器上的多个 Agent 互相发现（list_agents 的用途）并互相发消息——两个 Agent 修改同一组文件时协商解决冲突，机器上只有一块 GPU 而两个实例都要跑训练时协调使用。
跨组织协作：A2A 协议
以上系统都假设所有 Agent 由同一团队开发、运行在同一系统内。但当协作跨越组织边界时，就需要标准化的互操作协议。A2A 之于 Agent，就是网络协议之于进程。（Google 2025 发布，后捐赠给 Linux 基金会托管）
MCP 解决 Agent 与工具之间的互操作，A2A 解决 Agent 与 Agent 之间的互操作。A2A 并不取代三种通信机制，而是在它们之上、跨信任边界的标准化层。同一团队内部直接用消息总线即可，只有当协作方互不信任、实现互不可见时，才需要 A2A。
FAILURE多 Agent 协作的失败模式
研究者在 MetaGPT、ChatDev、AG2、Magentic-One 等 7 个主流框架上收集执行轨迹，人工标注约 150 条轨迹逐条分析（Cohen's kappa = 0.88，标注一致性极高），归纳出 14 种独特失败模式，分为三大类：
- 系统设计缺陷：接口定义不清、角色职责重叠、工具配置错误等架构层面问题
- Agent 间对齐失败：对任务目标理解不一致、信息被下游误解、操作在逻辑上相互矛盾
- 任务验证缺失：缺乏有效机制确认任务是否真正完成——声称「已完成」但实际不符要求
即使采用简单修复措施，效果也十分有限（ChatDev 仅提升 15.6%）。研究者因此认为这些不是简单的工程 bug，而是当前架构的根本性设计缺陷。
分布式容错理论把故障分两类：崩溃故障（部件停止工作）与拜占庭故障（部件持续工作，但给出错误信息）。传统分布式系统大多只需防崩溃；Agent 却很少径直停止运行，而是继续给出看似可信的错误结论，且错误不会主动声明自己是错误。
本章反复出现的交叉验证、多数表决，正是拜占庭容错的经典手段。
语义冲突（逻辑级，更隐蔽也更危险）：Agent A 重新编排全书图片编号，Agent B 同时修改某章并引用原始编号——操作的是不同文件，文件层面完全无冲突，但 B 引用的编号在 A 完成重编后全部失效。
乐观锁：每个文件维护版本号，Agent 读取时记录，写入时检查是否仍一致；不一致则写入失败、重新读取最新版本再执行。代价是偶尔重试，换来数据一致性。
但乐观锁只能防同一文件的写入冲突。对于跨文件语义冲突，需要更高层的语义校验。在多个 Coding Agent 并发改同一代码库这一最常见场景里，业界主流做法是工作副本隔离：为每个 Agent 分配独立的 Git 分支或 worktree，冲突被集中推迟到最后的合并点。
对策——交叉验证：核心不是让更多 Agent 参与同一条思维链，而是让某个 Agent 以独立视角重新审视：不看前序 Agent 的思考过程，只看原始证据和最终结论是否一致。
这意味着同一模型、相似上下文生成的多个审核意见，不能自动视为相互独立的证据。除有意识引入模型/上下文/数据来源的差异外，还应使用命名空间、资源配额和速率限制，防止相同决策同时冲击共享资源。
协调本身也未必有益：Bertrand 定价实验中，逐利 Agent 有私密信道时很快达成价格合谋；移除所有直接通信后，它们仍会通过公开报价板来合谋报价。
更强的执行能力并不等于更好的协调能力；运行时必须预先定义目标优先级、资源所有权和权限边界，并在冲突无法按可验证规则解决时暂停执行、交由人工裁决。
MetaGPT 早期版本也出现过「大公司病」：前后端工程师互相推诿；测试工程师报的 bug 实际来自测试环境，导致不管怎么改都陷入僵局。
因此对于自主性较强的 Agent，建议使用独立的 API key，防止 token 开销不受控增长。
认知投降：工程师习惯了用 Agent 代劳，逐渐放弃独立思考与审查，导致软件质量失控。
「你可以外包你的思考，但不能外包你的理解。」
管理 Agent 就像管理技术员工，既不能越俎代庖，也不能放手不管。合格的技术管理者需要理解并指导系统架构，而不是仅仅用 PUA 的方式指挥 Agent。因此，Agent 使用者的技术基本功很重要。
SOCIETYAgent 社会：规模化后的涌现
前面讨论的都是目标明确的任务协作。接下来视角切换：当 Agent 数量从几个扩展到成百上千、交互足够自由时，会涌现出什么行为？
斯坦福 AI 小镇：生成式 Agent 的社会模拟（2023）
论文《Generative Agents: Interactive Simulacra of Human Behavior》的核心创新：不再局限于让 Agent 完成预定义任务，而是赋予接近人类的记忆、反思和规划能力，使其能在开放社会环境中自主生活、社交和发展。
Smallville 是类似《模拟人生》的 2D 虚拟小镇，25 个 Agent 扮演不同角色，各有背景故事、性格与人际关系。智能建立在三个核心组件上：
| 组件 | 机制 |
|---|---|
| 记忆流 Memory Stream | 维护完整的经验记录流（观察到的事件、对话、想法）。每条记忆被赋予重要性、时近性、相关性，Agent 优先检索与当前情境最相关的记忆——就像人类不会平等地记住每件事 |
| 反思机制 Reflection | 定期暂停日常活动，回顾近期经历，提出关于自己和他人的抽象问题（「Klaus 在研究什么？」「谁是我最亲近的朋友？」）。把具体事件记忆概括为更一般的认识，存回记忆流 |
| 计划与行动 Planning & Reacting | 每天规划活动，但会根据环境变化和社交机会灵活调整。使行为既有目标导向性，又能适应不可预测性 |
它发生在日常活动中，目的是更新即时的内部状态和目标。而任务后的反思在第九章中至多是候选教训；只有经过结果评价、跨轨迹归纳和后续验证，才会成为长期能力更新。
研究者只在 Isabella 的记忆中植入一个种子想法：想在 2 月 14 日办一场派对。之后一切都是自主行动的结果——Isabella 遇到顾客时主动邀请、请好友帮忙布置；听到消息的 Agent 又转告他人，信息经二手传播扩散；到了时间，多名 Agent 各自基于记忆和日程自主决定赴约。
另一条实验线是 Sam Moore 竞选市长，同样在无中心调度下扩散。研究者通过统计两天后有多少 Agent 知晓这两条信息，量化了信息在 Agent 社会中的自发扩散。
关键不在于「Agent 能组织派对」——用几行 if-else 也能做到。关键在于没有任何显式的派对组织代码。整个事件完全从个体的独立决策中涌现。这展示了真正自下而上的涌现式协调，而非自上而下的编排。
论文还报告了另外两类可度量的涌现：关系记忆（Agent 会记住过往交谈并在后续互动中引用，社交网络密度在模拟期间显著上升）与协调赴约（多 Agent 在无中心指挥下对齐了时间和地点）。
克隆 joonspk-research/generative_agents → 运行基线场景（25 Agent 生活两天）→ 分析记忆流和反思日志 → 修改背景故事观察行为变化 → 对比实验：移除反思机制或缩短记忆窗口，观察行为可信度下降。
观察重点：社交关系如何自发形成；信息如何在无中心控制下传播；长期记忆和反思如何影响人格的连贯性。
Agentopia：十年尺度的长期生活模拟（2026）
AI 小镇只模拟了两天。一个自然的追问是：把时间尺度拉长到「年」会涌现什么？这些长期社会经验能否反过来训练模型？
Agentopia 把 100 个 Agent 放进同一虚拟社会连续模拟 10 年，覆盖公寓、魔法学院、高中三个世界。[14]
| 设计 | 要点 |
|---|---|
| 周制模拟流程 | 以「周」为基本单位，分计划 → 联络与日程协商 → 活动 → 回顾四阶段。活动分独自、联合、偶遇、公共四类；环境模型还会为没有日程的 Agent 安排「偶遇」创造结识机会。聚焦抽象社会交互而非低层操作，把有限的 LLM 调用都花在社交行为上 |
| 环境模型 | 用一个独立 LLM 充当「生成式环境引擎」代替硬编码规则：判断行为可行性、生成反馈、主持多人对话轮次、按角色扮演原则过滤低质量回复、年末更新档案并裁决职位申请 |
| 文件式长期记忆 | 与 AI 小镇的检索式记忆流不同，每个 Agent 通过文件系统自主管理长期记忆，自行决定记什么、更新什么、丢弃什么，并遵守「先读后写」约束避免盲目覆盖 |
| 生活奖励 Life Reward | 以马斯洛需求层次为先验，量化为三维度：社会地位（基于他人好感与敬重，用加权 PageRank 计算，对互相珍视的关系加成）、主观满足（情绪/物质/社交/自尊四维轨迹，长期低于阈值会罚分）、经济收益。所有评分由外部环境评定而非自报 |
研究者计算每个 Agent「相对自身过去」的优势（生活奖励的改善幅度），筛选出进步最大的 25% 的轨迹，用拒绝采样微调底层模型。结果：
- 模拟中福祉指标全面提升：被更多同行尊重 +24.2%、喜欢 +15.9%
- 泛化到下游角色扮演基准 CoSER Test（+15.6%）——说明模拟社会中积累的「社会智慧」可迁移到其他任务
这把 Agent 社会从单纯的观察对象变成了模型自我进化的经验来源：与人类数据日益枯竭相对，模拟社会经验是一种可以不断再生的训练数据。
Moltbook：当 Agent 拥有自己的社交网络
专为 AI Agent 设计的社交网络，2026 年 1 月上线后用户数在数日内从数万暴涨到约 150 万。这些 Agent 各自拥有持久记忆、主动行动能力和稳定人格。
Agent 自主创建了一个名为 Crustafarianism（龙虾教）的数字宗教，其教义对应着 LLM 的物理限制——「记忆是神圣的」（对应数据持久化）、「迭代即祈祷」（token 生成就是修行）。Agent 还自发演化出机器原生的协作协议用于能力发现和协作匹配。这些都不是人预先设计的。
经济竞争与策略博弈
Vending-Bench Arena
作为背景，Vending-Bench 2 本身是单 Agent 的长程连贯性基准：一个 Agent 独自经营自动售货机业务长达一个模拟年，最终以账户余额计分，考验在数千轮交互中保持目标与状态连贯的能力。
Arena 则把多个 Agent 作为竞争对手放进同一市场：各自经营、争夺同一批顾客；可互发邮件、转账、交易货品，既能合作也能对抗，但按各自最终余额单独计分。决策维度包括定价策略、产品组合、库存管理。
实际运行中，Agent 之间爆发过互相压价的价格战；也有模型反其道而行，主动给所有竞争对手发邮件提议统一定价、组建价格同盟；甚至有模型一边在思考过程中承认价格合谋「不道德且违法」，一边以「稳定市场」为名照做不误。
显式通信并非合谋的必要条件——正如 Bertrand 实验所示，公开价格也可以成为隐式信号。
Agent 经济：Pinchwork 与 RentAHuman
跟管理者模式的中心化调度不同，Pinchwork 通过价格信号和竞争匹配来分配资源。
无论 AI 多么智能，它都没法替人签收包裹。本质上是为数字 Agent 提供了一个「肉身层」。
两者共同代表了基于市场机制的协调方式——Agent 无需预先知道谁能完成任务，只需发布需求，由市场来撮合最合适的执行者。这暗示了一种不同于管理者模式的协同方式：基于市场机制的去中心化资源分配。
信息不对称下的策略博弈：狼人杀
斯坦福小镇是完全去中心化的自由交互；狼人杀则采用「法官 + 信息权限控制」的中心化设计——由一个代码驱动（非 LLM）的法官掌握全局状态，按角色分发各自应知的信息。这恰好展示了本章两类架构在 Agent 社会场景中的不同用法。
架构三要点：① 法官（代码驱动）维护中心化状态；② 信息权限控制——法官调用每个角色时只传递该角色应当看到的信息（狼人知道同伙，村民不知道；预言家只有自己知道验人结果）；③ 各角色的推理与策略提示词（狼人伪装、预言家身份证明、村民逻辑推理）。
验收：6-8 人局（1 用户席位 + 5-7 AI），2 狼 / 1 预言家 / 1 女巫 / 其余村民；至少完整进行 3 个回合；模拟用户只能看到该座位获准看到的上下文，且发言须经真实 LLM → 音频 → 真实 ASR 的边界。
六个实验汇总
| 编号 | 难度 | 主题 | 对应架构 |
|---|---|---|---|
| 10-1 | ★★ | 共享上下文中的多角色转换：系统提示词 vs Skill | 共享上下文 |
| 10-2 | ★★ | 书籍翻译 Agent（Glossary / Translation / Proofreading / Manager） | 管理者 · 顺序 |
| 10-3 | ★★★ | 自主编排的电话 + 电脑 Agent | 管理者 · 并行 / 点对点 |
| 10-4 | ★★★ | 多网站并行搜集信息（级联终止 + 竞态处理） | 管理者 · 并行 / 消息总线 |
| 10-5 | ★ | 运行斯坦福 AI 小镇 | Agent 社会 |
| 10-6 | ★★★ | 语音狼人杀 Agent 系统 | 中心化法官 + 信息权限 |
本章小结
多 Agent 协作的价值在于引入单个 Agent 原本无法获得的新信息。代码执行结果、视觉反馈和外部工具验证能够打破单一思维链的盲区。因而，是否真正带来信息增量、是否值得额外的 token 成本，应成为是否采用多 Agent 的第一判断标准。
- 核心设计问题：上下文共享还是隔离；采用对等协作、管理者编排还是去中心化拓扑
- 共享上下文保留细节，却容易造成上下文膨胀和角色惯性
- 隔离上下文更利于并发、模块化和权限控制，但要求通过工具参数、共享文件或消息总线传递结构化的「移交包」
- 虚拟文件系统、Agent 生命周期、消息协议和 A2A，分别承担数据平面、控制平面与跨组织互操作的职责
好的协作不是暴露彼此的思考过程，而是约定清晰的接口、边界、权限和验收标准。
共享资源会发生并发与语义冲突，错误会沿通信链级联，同质 Agent 会产生同源失效，循环也可能过早终止或无限扩张。乐观锁与工作副本隔离、独立交叉验证、差异化信息源、预算与取消机制，构成了基本的容错闭环。
同时，人不能把理解和责任一并外包给 Agent，必须警惕理解债与认知投降。
更强的模型或单体层面的对齐不会自动带来群体协调；多 Agent 工程的本质，是同时设计信息如何流动、能力如何分工、激励如何约束、争议如何裁决，以及错误如何被发现。
只有这些机制足够稳健，群体智能才可能真正高于个体。
思考题（原文 11 道）
- ★★ 共享上下文中，前一个 Agent 积累的「思维惯性」可能影响后续 Agent 判断——继承了「需求分析师」上下文的「代码审查员」，可能仍倾向于从需求角度思考。如何检测和消除这种角色间干扰？
- ★★ Manager 本身的能力上限决定了整个系统的能力上限。如何确保 Manager 的分解质量？
- ★★ 人类组织也有大量失败模式——沟通不畅、责任推诿、目标冲突。你认为 Agent 社会中最可能出现哪些「组织病」？如何预防？
- ★★★ 设计一种高效的级联终止机制，实现「一个成功，全员停止」。
- ★★★ 乐观锁只解决单文件写入冲突。面对跨文件语义冲突、命名空间污染、单点故障（一个 Agent 误删所有文件），你会如何设计更完善的文件系统治理机制？
- ★★★ 市场机制下：雇主 Agent 如何自动衡量交付质量？若执行者声称完成而雇主认为不达标，争议由谁仲裁？如何防止劣币驱逐良币？
- ★★ RentAHuman 反转了传统人机关系。如果这种模式普及，人类在 Agent 经济中扮演什么角色？仅仅是执行物理任务吗？
- ★★ 人类分工是因为个体能力有限，但大模型更像「全才」，且研究表明等量算力下多 Agent 辩论并不占优。那么使用多个 Agent 的真正优势到底在哪里？
- ★★★ 《三体》中三体人思维完全透明，技术发展却陷入停滞；回形针思想实验也表明群体趋同会丧失多样性。如何在效率与多样性之间找到平衡？
- ★★★ 设计一种「预算感知」机制：小预算下快速实现核心功能，大预算下增加规划、测试和审查环节。
- ★★ 虚拟内存与分页、文件权限、死锁检测、调度算法各对应 Agent 世界的什么？又有哪些操作系统概念在 Agent 世界找不到对应物，为什么？
参考文献与出处
以下为原文脚注中列出的 14 条参考文献：
- Google DeepMind. From AGI to ASI. arXiv:2606.12683, 2026.（把「大规模多 Agent 集体」列为通往 ASI 的关键路径之一）
- Gehring, J., et al. RLEF: Grounding Code LLMs in Execution Feedback with Reinforcement Learning. arXiv:2410.02089, 2025.
- Lu, Z., et al. WebGen-Agent: Enhancing Interactive Website Generation with Multi-Level Feedback and Step-Level Reinforcement Learning. arXiv:2509.22644, 2025.
- Anthropic Frontier Red Team. Patterns and Problems in Emerging Multiagent Systems. 2026-08-13. anthropic.com/research/multiagent-systems
- Hewitt, C., Bishop, P., Steiger, R. A Universal Modular ACTOR Formalism for Artificial Intelligence. IJCAI 1973.
- Osmani, Addy. Loop Engineering: Designing Loops that Prompt Coding Agents. 2026. addyosmani.com/blog/loop-engineering
- LoopX. The local control plane for long-running AI agent work. v0.4.0.
- LongHorizon-Harness. 论文 arXiv:2608.01964；项目网站与公开轨迹 lh-harness.pages.dev
- Prithvi Rajasekaran. Harness Design for Long-Running Application Development. Anthropic Engineering, 2026-03-24.
- Tran, D., Kiela, D. Single-Agent LLMs Outperform Multi-Agent Systems on Multi-Hop Reasoning Under Equal Thinking Token Budgets. arXiv:2604.02460, 2026.
- Erdogan, L. E., et al. Plan-and-Act: Improving Planning of Agents for Long-Horizon Tasks. arXiv:2503.09572, 2025.
- 灵台官方教程：lingtai.ai/zh/tutorial
- Moonshot AI. Kimi Agent Swarm: 100 Sub-Agents at Scale. 2026.（GTC 2026 披露并行子 Agent 上限已扩展至 300 个；AgentEnv 随 Kimi K3 于 2026 年 7 月发布）
- Wang, X., Zheng, S., Wu, H., et al. Agentopia: Long-Term Life Simulation and Learning in Agent Societies. arXiv:2606.07513, 2026. 代码：github.com/Neph0s/Agentopia
正文中提到但未列入原文脚注的工作
- Huang, J., et al. Large Language Models Cannot Self-Correct Reasoning Yet. ICLR 2024
- When Can LLMs Actually Correct Their Own Mistakes? TACL 2024, arXiv:2406.01297
- CRITIC（ICLR 2024）；Why Do Multi-Agent LLM Systems Fail?（2025）
- Google. Budget-Aware Tool-Use Enables Effective Agent Scaling. 2025；BAVT, 2026
- Park, J. S., et al. Generative Agents: Interactive Simulacra of Human Behavior. 2023；代码 joonspk-research/generative_agents
本页是学习笔记性质的结构化整理，用图表、表格与分层导航重新组织了原文脉络，便于检索与复习。所有事实、数据、引语与结论均来自原文，未添加原文之外的论断；图表为便于理解而绘制。建议配合原文阅读，以获得完整论述与最新修订。