第 7 章 · 多智能体编排

多智能体（multi-agent）是 Agent 工程中最容易被过度使用的技术。本章的目标是让你能判断什么时候不该用，以及在确有必要时怎么把通信、终止、恢复做对。

7.1 什么时候用、什么时候不用

先看账。Anthropic 在其多智能体研究系统（multi-agent research system）中给出的工程经验值：

多智能体系统的 token 消耗约为普通聊天的 15 倍，而单 agent 循环约为聊天的 4 倍。

多智能体的成本结构：多个并行 worker 各自带完整上下文反复调用模型，外加 orchestrator 的调度与汇总开销。收益结构：并行探索节省墙钟时间、上下文隔离让每个 worker 保持专注、异构能力（不同模型/不同工具集）可以组合。

决策标准：

• 用多智能体：子问题天然独立可并行（研究 N 个主题、审查 N 个文件）、单个上下文装不下全部过程、任务价值高到覆盖 15× 成本；
• 不用：任务本身线性依赖（B 必须等 A 的结果）——排队执行的多智能体只是加了通信开销的单 agent；任务简单到一个好循环能解决——别为了架构图好看上多智能体；
• 先用单 agent + 子智能体（subagent）：orchestrator 派生一次性子循环做脏活、只回传结论，是多智能体的"轻量版"。90% 想上多智能体的场景，这个形态就够。

7.2 拓扑谱系

Orchestrator-Worker（主从）

一个编排者拆解任务 → 分派给 worker → 汇总。

            ┌──> Worker A（查文献）
Orchestrator┼──> Worker B（查数据）
            └──> Worker C（查案例）
      └── 汇总 → 最终报告

两条铁律（Anthropic 的实战教训）：

1. orchestrator 的任务描述质量 = 系统上限。worker 看不到全局上下文，orchestrator 的分派词就是 worker 的全部信息——分派词必须包含：目标、约束、输出格式、完成标准。把 orchestrator 的分派 prompt 当作产品最核心的资产来打磨；
2. worker 返回结论，不返回过程。orchestrator 只需要"三个候选方案的对比表"，不需要 worker 每一步读了什么。

流水线（pipeline）

固定阶段串联（提取 → 分析 → 生成 → 审查），每阶段一个专职 Agent。本质是 workflow（第 2 章的定义）+ 每阶段内部有自主性。适合阶段稳定的生产任务。

辩论 / 评审（debate / review）

多个 Agent 独立产出答案，再互相批判或由裁判裁决。成本近线性翻倍，收益必须用评测证明（第 9 章）——文献结论不一，多数场景"单 agent + reflection"性价比更高。真正的适用点是决策风险极高、且不同 Agent 的独立性有意义（多样性）的场景。

市场制 / 任务板（market / labor market）

非对称拓扑：没有固定分派，任务作为"工单"发布在任务板上，Agent 自行认领。

任务板（事实源：账本数据库）
  open → claimed → running → waiting_review → succeeded / failed

成员 A：board_list_tasks → board_claim_task（CAS）→ 执行 → board_submit_result
评审者：board_review_task → 通过则声誉入账（append-only ledger）

关键机制与它们的"为什么"：

• CAS 认领：UPDATE ... WHERE status='open' 只有一个成员成功——多成员抢单的竞态在数据层解决；
• 租约（lease）与过期回收：认领时带租约，worker 崩溃后租约过期任务自动回到 open——崩溃恢复不需要任何协调者；
• 审核环节：交付先进入 waiting_review，通过才算完成——质量闸门内建在工作流里；
• 声誉账本（reputation ledger）：审核通过才记分，append-only 且每任务每成员幂等——可审计、可重放，且注意只做"展示与门槛"语义（谁分高谁优先认领），一旦变成可流通的"货币"就会催生刷分博弈。

市场制的适用场景：开放式任务流（任务到达不可预测）、成员能力异构（不同 Agent 各有所长）、任务与成员都在动态变化。它的复杂度显著高于主从制——通信拓扑是自治的，调试难度上了一个量级，没有异构与开放性诉求就不要用。

7.3 通信与状态：架构的黄金分层

多智能体系统最大的工程陷阱是把通信建立在易失通道上。黄金分层：

事实源（PostgreSQL）：消息、任务、状态、结果——落库，可恢复，归属可证明
    ↑ 写入
通知层（Redis Pub/Sub / 队列）：只发"有新消息了"的唤醒信号，不带业务语义

为什么：Pub/Sub 消息即发即失——worker 掉线期间的消息会丢；而"任务是否完成""结果是什么"是必须可恢复的业务状态。落库 + 通知的分层让崩溃恢复 = 重放未完成任务，不需要任何额外的可靠传输机制。同时，归属与授权判断只看数据库（谁的任务、谁的结果），Redis 里的任何东西都不作为权限依据。

通信内容的纪律：消息里传引用（任务 ID、结果 URL），大内容放对象存储——消息总线不是文件传输通道。

7.4 终止与裁决

多智能体最难的问题之一：系统什么时候算完成？ 固定分派的主从制由 orchestrator 判断（worker 全部返回）；市场制需要一个**裁决者（adjudicator）**规则：

• 板上无 open 任务且无在途任务（无 claimed/running）→ 当班完成；
• waiting_review 不阻塞裁决（评审是异步的质量环节，评审积压不该卡死系统）；
• 显式终止信号（用户叫停、投票终止）优先级最高。

一个常见错误是把"所有 worker 空闲"当完成条件——worker 可能刚崩了还没被租约回收，空闲≠完成。以任务账本的状态为准，不以成员的忙碌状态为准。

7.5 失败模式清单

失败模式	现象	对策
编排者死循环分派	同一任务反复拆解重派	orchestrator 侧预算 + 已派任务去重（7.4 账本）
worker 声称完成但没做	汇总时发现结果为空	完成标准写进分派词 + 交付物校验（文件存在/格式正确）
消息洪泛	全员广播刷屏，上下文爆炸	定向通信（点对点/组内），广播要节制
雪崩重试	上游错误触发全员重试风暴	指数退避 + 抖动 + 全局重试预算（第 1 章 1.5 的推广）
声誉刷分	成员互刷评分抬高认领优先级	评分只来自审核通过、append-only、异常模式监控
上下文感染	一个 worker 的错误结论被其他成员引用放大	worker 结论标注来源与置信度；评审环节独立上下文

实现作业

1. 轻量版：给第 2 章的 Agent 加"派生子任务"能力（一个 spawn_subagent(task_prompt) 工具，子 Agent 用裁剪的工具集跑完返回结论），用"调研 A/B/C 三个主题并汇总"验证并行与上下文隔离；
2. 任务板版：用 SQLite 实现任务板（账本表 + CAS 认领 SQL + 租约过期回收的后台任务），三个并发 worker 进程抢单，人为 kill 一个，验证租约回收；
3. 给两版各做一次 token 计量对比单 agent 直做——亲身体验 15× 从哪里来、哪些是值得的成本。

深入材料

• Anthropic, How we built our multi-agent research system（2025，15×/4× 经验值与 orchestrator 教训的出处）
• AutoGen（arXiv 2308.08155，对话式多智能体框架的代表）、LangGraph 多智能体文档（图式编排的代表）
• CAMEL（arXiv 2303.17760，角色扮演式协作的早期系统）