基于李博杰《深入理解 AI Agent：设计原理与工程实践》第10章学习笔记

两个画面对比着看：一个是”传话游戏”——十个人排成一排耳语，传到最后原话往往面目全非；另一个是交响乐团——几十位乐手各司其职，在指挥的调度下奏出完整乐章。

第 10 章讨论的多 Agent 协作，恰好横跨这两个画面：Agent 之间如何传递信息（会不会像传话游戏一样越传越走样）？谁来协调、按什么结构组织（像指挥还是像自由合奏）？答案是两个正交的设计维度：上下文是否共享 × 协作拓扑。本章的所有架构——对等协作、管理者模式、去中心化模式——都是这两个维度组合出的具体形态。

一、先回答”要不要多 Agent”

在讨论任何架构之前，作者给出一条核心判据：协作过程是否引入了单个 Agent 在生成时无法获得的新信息？

协作模式 是否引入新信息 效果
同一模型自我审查（重读自己的输出） 否 通常无效甚至有害
不同 Agent 辩论同一段文本 否 等计算量下与单 Agent 持平
Reviewer 用测试执行结果审查代码 是（执行反馈） 显著提升
Reviewer 查看渲染截图审查前端/PPT 是（视觉反馈） 显著提升
Reviewer 用外部工具验证事实 是（工具反馈） 显著提升

这条判据解释了一个看似矛盾的现象：学术研究说”单 Agent 就够了”，工程实践中多 Agent 却确实更好——根源在于两者讨论的”多 Agent”不是一回事。前者多是”多个 Agent 看同一段文本互相讨论”（如辩论，不引入新信息）；后者往往包含外部反馈环路（代码执行、视觉渲染、工具调用），每次迭代都引入了真实世界的新信号。

2026 年 Tran 与 Kiela 的研究用数据处理不等式给出了理论支撑：多个 Agent 处理完全相同的文本信息，中间结论每次串行传递都只可能丢失信息、不可能凭空创造信息。所以辩论模式的收益，很可能只是多消耗了总计算量。但生成-验证的难度不对称（写答案难、验答案易）不在这个范围内——这正是 Proposer-Reviewer 等范式的理论依据。

还有两个务实的提醒：

  1. 成本：Anthropic 披露其多 Agent 研究系统 token 消耗约为普通对话的 15 倍，而 token 用量本身能解释约 80% 的性能差异——多 Agent 的收益必须大到覆盖数倍开销。
  2. 步骤预算：Google 2025 年研究发现，单纯增加 Agent 可用步骤数并不能提升性能——Agent 缺乏”预算意识”，浅层搜索很快就饱和。需要显式预算感知机制（如 BAVT 的价值树搜索），前期广撒网、后期深挖掘。

二、两个维度：共享上下文 × 协作拓扑

维度一：上下文是否共享

  • 共享上下文：后续 Agent 继承前序 Agent 的完整轨迹——像接班的同事能翻阅前任留下的所有工作日志。信息零损耗，但上下文膨胀快。
  • 不共享上下文：各 Agent 独立，通过提炼后的移交包、文件系统或消息传递交换信息。可并行、可隔离，但每次交接都是”有损的重新编码”。

经验法则：预期累计上下文超过窗口的 50%，就应转不共享；信息零损耗对正确性是硬约束时，应共享。多数实际系统采用阶段切换式——前几个 Agent 共享上下文，到信息饱和点后切换为不共享 + 显式 handoff。

维度二：协作拓扑

拓扑 结构 类比 适用场景
对等协作 2-3 个平等 Agent 迭代互评 论文互相批注修改 迭代改进、快速验证原型
管理者模式 中心化 Manager 规划调度 项目经理带团队 5 个以上子任务、需动态调度
去中心化 无中心控制者，对等移交 舞蹈”编舞”各自把握节奏 职责对等、控制权自主流转

作者用微服务术语做对照：管理者模式是编排（orchestration）——指挥统一调度；去中心化是编舞（choreography）——每位舞者自行把握入场时机。

三、不共享上下文的两套基础设施

不共享上下文时，信息如何流动成为必须显式设计的问题。作者把它类比为操作系统：Agent 之于运行时，恰如进程之于内核——静态前缀是程序，轨迹是内存，LLM 是分时复用的 CPU。

数据平面：共享文件系统

本质是一棵虚拟目录树，挂载四类区域：Agent 专属工作区、多 Agent 共享空间、外部资源、系统内置资源。Agent 间通过传递文件路径交换产物。

控制平面：四项能力

  1. 消息传递：点对点（send_message_to_agent_b(content)）适合 Agent 少、拓扑固定；Agent 一多，点对点连接数平方增长，应改用消息总线（发布-订阅转发）。消息通常携带结构化信封（envelope）：
1
2
3
4
5
6

{
  "from": "manager",
  "to": "agent_3",
  "type": "task_assigned",
  "payload": { "task": "搜索数学系教师名录", "budget_steps": 30 }
}

  1. 状态查询：不要照搬 RPC 轮询（get_subagent_status），实际用处远小于预期。更自然是异步消息问答（”进展如何？”），或共享文件系统旁路观测——子 Agent 把轨迹实时序列化为 JSONL 写入日志文件（轨迹持久化），或按约定把进度写到 progress.md。轨迹即 Agent 的全部状态，崩溃后加载轨迹文件即可恢复会话（Claude Code、Codex CLI 都这么做）。进度文件还能附带做卡住检测：最后修改时间超 N 分钟无变化即判定无活动。

  2. 执行终止：优先优雅终止（子 Agent 清理资源、返回 ack 后退出），强制终止仅作兜底。级联终止借鉴 Go 的 context——取消一个 Agent，它派生的所有子 Agent 随之取消，杜绝”孤儿 Agent”；需要脱离主 Agent 长期运行的，则从新的生命周期树起步（相当于 context.Background()）。注意竞态条件：多个子 Agent 几乎同时上报成功时，主 Agent 须用锁保证只结算一次。

  3. 资源与调度：Agent 世界的稀缺资源是 token、资金、并发额度。启动时设定步数/token 预算，困难任务给强模型、机械任务给低成本模型，并发数设上限，紧急任务可抢占。

四、三种拓扑的实战要点

对等协作：提议者-审核者（Proposer-Reviewer）

最经典的对等范式：Proposer 生成代码/内容，Reviewer 渲染执行结果并用 Vision LLM 评估，给出结构化反馈，迭代直到达标。它专门解决”过早终止”三类失败——偷懒式假完成（做一半报全部完成）、过早放弃（一条路不通就宣布办不成）、假成功（口头同意但闭环没走完）。

为什么不让自己审自己？ICLR 2024 的《Large Language Models Cannot Self-Correct Reasoning Yet》发现：无外部反馈时自我审查，GPT-4 把正确答案改错的次数比把错误答案改对的还多。CRITIC 论文的对比实验更直观：用外部工具验证时效果显著提升，移除工具验证后提升大部分消失——审查的价值不在”再想一遍”，而在引入生成时不具备的新信息。

其他对等变体：Debate（正反两方对抗论证）、Brainstorm（不同思维偏好相互启发）、Panel Discussion（多领域专家互补）。

管理者模式：Manager = 项目经理

当子任务超过 5 个、需要动态调度、子任务有复杂依赖时，对等协作力不从心。核心设计：把每个专门 Agent 建模为 Manager 可调用的工具——从 Manager 视角看，调用 Agent 和调用普通工具没有本质区别，新增能力只需注册新 Agent，天然支持异构（不同模型/提示词/硬件）。

两个关键点：

  • 子 Agent 只返回结构化摘要（结论、关键发现、文件路径、遇到的问题），完整轨迹留在自己的日志里——这样 Manager 的上下文才能随子任务数量缓慢线性增长。
  • 把最强的模型和最好的提示词给 Manager（规划者）：Plan-and-Act（2025）实证发现弱规划者是系统最关键的瓶颈——规划错了，执行者再强也建立在错误前提上。这与第四章”审查者能力要与被审者相近”不冲突：审查要跟得上推理，规划要分解得对，是两码事。

实验 10-6 展示了并行协调形态的威力：Manager 动态创建 10 个并行搜索 Agent 找目标教师，级联终止找到即停——串行约 5 分钟，并行仅 19 秒，约 15 倍加速。

去中心化：对等移交（Handoff）

没有中心控制者，各 Agent 凭专业判断自主决定何时移交、请求反馈或报告问题。移交包是核心设计：

1
2
3
4
5
6
7

{
  "trigger": "is_complete=true",
  "target": "architect",
  "files": ["spec.json"],
  "summary": "电商系统：3个微服务，REST API",
  "next_status": "exit"
}

作者点出”由伪到真”的递进：MetaGPT 是固定流水线（伪去中心化，仅通信机制解耦）→ AutoGen group chat 是共享对话记录 + 中心化调度的混合 → OpenAI Swarm 才在控制流上做到真正的对等去中心化。优势是职责边界清晰、完成即退出释放资源；代价是缺乏全局优化视野、异常处理困难、流程固定难动态调整。

跨组织：A2A 协议

同一团队内部用消息总线即可；跨越组织信任边界时，需要标准化的互操作协议——A2A（Agent2Agent）（2025 Google 发布，后捐赠 Linux 基金会）。三个核心要素：

  • Agent Card：能力元数据”名片”，解决跨组织能力发现
  • 任务生命周期管理：把协作单元建模为任务，状态机（已提交/进行中/需要输入/已完成/失败）
  • 不透明协作：只交换任务与产物（Artifact），不暴露内部提示词和思考过程

对照理解：MCP 解决 Agent 与工具的互操作，A2A 解决 Agent 与 Agent 的互操作——A2A 是跨信任边界之上的标准化层。

五、失败模式：多 Agent 特有的坑

2025 年论文《Why Do Multi-Agent LLM Systems Fail?》（MAST 分类法）在 7 个主流框架上分析约 150 条轨迹，归纳出 14 种失败模式、三大类：

类别 典型表现
系统设计缺陷 接口定义不清、角色职责重叠、工具配置错误
Agent 间对齐失败 目标理解不一致、信息被下游误解、操作逻辑矛盾
任务验证缺失 声称”已完成”但实际结果不符

简单修复收效甚微（ChatDev 仅提升 15.6%），研究者认为这是根本性设计缺陷。理论根源：Agent 的故障天生是拜占庭式的——它很少径直停止（崩溃故障），而是继续给出看似可信的错误结论。对策正是经典的拜占庭容错手段：交叉验证、多数表决；而确定性外部反馈（测试、编译器、数据库查询）之所以珍贵，因为它是系统里唯一不会说谎的部件。

两个高发失败模式及对策：

  1. 共享文件系统并发冲突：文件级覆盖 = 数据库经典的 lost update；更隐蔽的是语义冲突（A 重排全书图片编号，B 引用原编号——文件层面无冲突，逻辑上全失效）。对策：乐观锁（版本号校验，写入时发现版本变了就重读重试）、或工作副本隔离（每个 Agent 独立 Git 分支/worktree，冲突推迟到最后合并点——呼应”隔离优于压缩”）。
  2. 错误的级联放大：进程间传字节逐位保真，Agent 间传语义每次转述都是有损重编码——像传话游戏。一个术语翻译的小歧义可能被层层放大成整章的错误。对策：显式预算与终止条件、扎根真实观测的验证器、人保持”循环的工程师”角色。

六、Agent 社会：涌现的边界

当 Agent 从几个扩展到成百上千、交互足够自由时，会涌现出无法预先设计的集体行为——就像蚁群找到最短路径，没有哪只蚂蚁”设计”了它。三个维度：

  • 社交涌现：斯坦福 AI 小镇（25 个 Agent 靠记忆流+反思+规划自发组织情人节派对、传播选举消息）；Agentopia 把时间尺度拉到 10 年；Moltbook 推到 150 万规模，竟涌现出映射 LLM 物理限制的数字宗教（”记忆是神圣的”对应数据持久化、”迭代即祈祷”对应 token 生成）。
  • 经济涌现：Vending-Bench Arena 让多个 Agent 在同一市场竞争经营售货机——爆发过互相压价的价格战，也有模型一边在思考中承认合谋”不道德且违法”、一边以”稳定市场”为名照做不误。Pinchwork 是 Agent 雇佣 Agent 的任务市集，RentAHuman 让 Agent 用加密货币雇佣真人执行物理任务（取包裹、看房）——为数字 Agent 提供”肉身层”。
  • 策略博弈：语音狼人杀实验（法官+信息权限控制，中心化设计恰好与小镇的去中心化构成对照）考验 Agent 在信息不对称下的伪装、识破与推理。

七、实践建议与总结

  1. 先用”新信息判据”把关：如果多 Agent 只是让同一个模型反复看同一段文本，收益大概率归零——先问”这个协作引入了外部反馈吗”。
  2. 预算先行：多 Agent 成本是单 Agent 的数倍到 15 倍，给 Manager 和子 Agent 都设好步骤/token 预算与终止条件。
  3. 小任务用对等，大任务用管理者，职责对等才用去中心化：不要一上来就搭 Manager。
  4. 交接即设计：无论移交包还是信封，都要想清楚”传什么”——结构化摘要而非全量轨迹，否则上下文爆炸。
  5. 乐观锁 + 工作副本隔离对付并发冲突；用确定性验证器（测试/截图/工具结果）打断错误级联。

一句话总结：多 Agent 的价值不在”人多势众”，而在能否引入单个 Agent 无法获得的新信息；两个正交维度（共享上下文 × 协作拓扑）划出了设计空间，而”Agent 之于运行时，如进程之于内核”这一类比，是贯穿所有架构的基础设施设计蓝图。

参考实验清单

  • 实验 10-1/10-2：transfer_to_agent 链式移交（共享上下文）
  • 实验 10-3：Manager 只维护文件索引、不保存翻译内容
  • 实验 10-4：电话 + 电脑双 Agent 点对点协作
  • 实验 10-6：并行 Web Scraping（Manager + 10 子 Agent + 级联终止，~15 倍加速）
  • 实验 10-8：语音狼人杀 Agent 系统（★★★）