8 多智能体：角色、通信、冲突、预算

第 7 章把规划压在一个控制器里：一个上下文、一组工具、一条预算。真实任务经常超出这个边界——四十份材料要同时读，三个模块可以并行改，一个高风险结论需要有人专门唱反调，一段不可信网页最好关在单独的 agent 里处理。这些需求看起来都在说「多上几个 agent」，但它们交换的东西完全不同：并行换墙钟，分工换上下文纯度，对抗换错误独立性，隔离换故障半径。

问题是，多智能体不是免费的能力升级。每增加一个 agent，就增加一份要重建的上下文、一条要维护的消息通道、一次要裁决的冲突、一个要归因的失败点。很多团队把「多 agent」当成默认答案，最后得到的是一个更慢、更贵、更难排障的单 agent——只是它内部有五个角色名。这一章先给判断，再给机制：什么时候拆，拆成什么拓扑，消息怎样定义，冲突怎样裁决，预算怎样传播，失败怎样观测。

本章的判断可以压成一句话：多智能体用通信成本换并行、分工、对抗与故障隔离；只有当换来的收益大于通信、协调、验证与观测的总成本时，它才成立。 后面的每一节都在给这句话加可执行的边界。

8.1 何时需要多智能体：并行、分工、对抗与隔离

先看三个任务，它们都「像」需要多 agent，但只有一个真的需要。

任务 A：把一份 200 页的合同与公司模板逐条比对。 200 个条款彼此独立，可以切片并行；每片只需要读模板的对应条款，不需要知道其他片的结论；最后按条款号合并。这里的分工是数据并行，收益主要来自墙钟与上下文纯度。

任务 B：修复一个跨三个服务的线上故障。 三个服务的日志、指标、配置互相关联；改一个服务的重试策略会影响另一个服务的限流；根因可能在任何一层。这里强行拆成三个 agent，只会让每个 agent 看到局部证据，然后把自己的局部结论当成全局根因。它更适合一个带完整 trace 的单 agent，或者一个由人主导的工作流。

任务 C：给一条高风险的合规结论做复核。 主 agent 写结论，另一个 agent 专门找反例，第三个 agent 只检查引用是否能回到原文。这里的价值不是并行，而是错误独立性：如果复核者与作者共享同一份摘要、同一个模型、同一段上下文，它只会复述作者的偏见。

严格说，只有 C 必须用多 agent；A 可以用并行工作流，B 更适合单 agent 加完整 trace。把三者放在一起，是为了说明「规模」不是判据，「收益来源」才是。

三个任务的差别不在规模，而在收益来自哪里。把收益来源拆开，只有四类：

这张表说明什么：四种收益都对应一个可检验的前提。并行要求「独立」，分工要求「差异」，对抗要求「独立证据」，隔离要求「边界」。前提不成立时，增加 agent 只会增加成本，不会增加能力。

8.1.1 先排除单 agent，再排除工作流

多智能体是第三个选项，不是第一个。一个可操作的排除顺序是：

1. 单 agent 能不能做？ 一个上下文放得下任务状态，工具集不超过模型稳定选择的范围，串行步骤在预算内。能，就用单 agent。它的通信成本是零，排障路径最短。
2. 工作流能不能做？ 步骤可以由代码预先编排，模型只在固定节点做判断。能，就用工作流。它的控制流可审计，重试与补偿容易实现；代价是灵活性低。
3. 只有当前两步都不成立时，才考虑多 agent。 典型信号：子任务必须并行、子任务需要互相看不见的上下文、需要独立对抗、需要把不可信输入关进单独边界。

这三步听起来保守，但它拦住的是最常见的一类浪费：把「一个 agent 做不好」直接归因于「agent 不够多」。一个 agent 做不好，先查上下文是否被淹没、工具契约是否清楚、验证器是否缺失；这三件事没有解决，拆成十个 agent 只会把同一个问题复制十份。

这张表说明什么：拓扑不是「高级程度」的阶梯，而是不同的控制流。supervisor 并不比 peer 高级，debate 也不比 supervisor 高级；它们各自把控制权放在不同位置，因而有不同的故障形状。

8.1.2 多智能体的定义：独立控制循环，不是多个角色名

这个定义故意把 $R$ 与 $T$ 分开。角色回答「你是谁、你能做什么」，拓扑回答「谁能指挥谁、谁负责收尾」。很多实现只写了角色提示词，没有写拓扑，于是每个 agent 都以为自己可以指挥别人，也都以为别人会收尾——第 8.6 节的责任稀释就是这样发生的。

8.1.3 收益门槛：一个可算的判据

把并行收益写成公式，可以避免「感觉会更快」的争论。设单 agent 完成时间为 $T_1$，任务中可并行部分占比为 $p$，使用 $n$ 个 agent，每增加一个 agent 带来的协调开销是单 agent 时间的 $\kappa$ 倍。在理想情况下，墙钟时间的下界是

$$T_n \ge T_1\left((1-p) + \frac{p}{n} + \kappa(n-1)\right).$$

括号里三项分别是串行部分、并行部分和协调开销。这个模型很乐观：它假设子任务完美均衡、合并免费、消息不丢。现实只会更差，所以它适合当排除门槛，不适合当性能预测。

这个定理的工程价值在于把「要不要拆」变成三个可估的量：可并行比例 $p$、agent 数 $n$、协调开销 $\kappa$。一个 20% 可并行的任务，拆成 4 个 agent 时要求 $\kappa \lt 0.05$——也就是协调开销低于单 agent 时间的 5%。大多数需要反复 handoff、对齐格式、裁决冲突的系统，$\kappa$ 远高于 5%。这就是为什么很多多 agent 系统在 demo 里更快，在生产里更慢。

8.1.4 通信成本被低估的三个原因

多智能体的账单很少等于「单 agent 成本 × agent 数」。它通常更高，原因有三个。

第一，上下文要重建，不是共享。 agent 之间没有共享内存；所谓「共享上下文」只是把同一段文本复制给每个 agent。一个 8k token 的项目背景发给 4 个 agent，就是 32k token 的输入，而且每个 agent 都会基于自己的摘要再压缩一次，信息在每次复制时损失。

第二，消息会触发新的回合。 一条 100 token 的 handoff 可能让接收者读 20k token 的上下文、调用 3 个工具、再写 2k token 的回复。按消息条数估成本会严重偏低；应按「消息触发的总 token 与工具调用」估。

第三，冲突要花额外的验证预算。 两个 agent 给出不同答案时，系统要么再调一个 judge，要么让人看，要么重跑；这三条路都比「只有一个答案」贵。若冲突率是 30%，验证成本会变成常态支出，而不是异常处理。

这张表说明什么：多智能体的成本主体在「消息触发的二次工作」，不在消息本身。预算要按 agent 回合与工具调用记，不能按消息条数记；否则会在最该刹车的地方显示「还很宽裕」。

8.1.5 一个够用的决策流程

把上面的内容压成五步，可以在设计评审时逐条过：

1. 写清单 agent 的失败模式。 是上下文放不下、工具太多、步骤太长，还是缺少独立验证？不同病因对应不同药方。
2. 估 $p$ 与 $\kappa$。 $p$ 用「可并行子任务的工时占比」估；$\kappa$ 用「一次 handoff 的往返时间 / 单 agent 总时间」估。估不准就取保守值。
3. 检查独立性。 子任务之间是否真的不需要对方的中间结果？需要，就不是并行，是串行依赖。
4. 检查验证器。 每个子任务的输出有没有可机器检查的验收条件？没有，合并时只能靠另一个模型「看看对不对」。
5. 先做两 agent 版本。 一个 worker + 一个 verifier，或一个 supervisor + 一个 worker。两 agent 版本能暴露 80% 的通信与预算问题，成本却接近单 agent。

五步里任何一步答不上来，先回到单 agent 或工作流。多智能体不是不能做，而是不值得在问题还没定义清楚时做。

8.2 角色与拓扑：supervisor、peer、debate 与 hierarchy

拓扑回答两个问题：谁能给谁发消息，谁负责说结束。这两个问题不写清楚，角色提示词写得再细也没用：每个 agent 都会在需要决策时等别人，或者在不需要决策时抢着收尾。

先给四种基本形状。它们不是互斥的；一个系统可以是「supervisor 下面挂两个 debate 小组」，也可以是「peer 网络里选出一个临时 supervisor」。但基本形状决定了控制流、故障模式与观测方式，混用之前要先知道自己混的是哪两种。

这张表说明什么：「谁负责终止」比「谁更聪明」更能区分拓扑。supervisor 与 hierarchy 有明确的终止 owner；peer 与 debate 如果没有外部看门狗，就很容易把「继续讨论」当成默认状态。

┌─ supervisor ─────────────────┐   ┌─ peer ────────────────────┐
│            ┌───────────┐     │   │      ┌───┐      ┌───┐   │
│            │supervisor │     │   │      │ A │◀────▶│ B │   │
│            └──┬─────┬──┘     │   │      └─┬─┘      └─┬─┘   │
│          ┌────▼┐  ┌─▼────┐   │   │        │  ◀────▶  │     │
│          │ W-A │  │ W-B  │   │   │      ┌─▼─┐      ┌─▼─┐   │
│          └─────┘  └──────┘   │   │      │ C │◀────▶│board│ │
│  预算向下 ↓   结果向上 ↑      │   │      └───┘      └───┘   │
└──────────────────────────────┘   └──────────────────────────┘
┌─ debate ─────────────────────┐   ┌─ hierarchy ──────────────┐
│   pro ──┐                    │   │           root           │
│         ├──▶ judge ──▶ out   │   │          ┌─┴─┐           │
│   con ──┘   (evidence)       │   │         L1   L1          │
│   轮次 ≤ k；无新引用即停       │   │        ┌─┴┐  ┌─┴┐        │
│   反方意见保留在 trace 里      │   │       W  W  W  W         │
└──────────────────────────────┘   └──────────────────────────┘

读图：四种形状的边方向不同。supervisor 是星形，所有跨 agent 的因果都经过中心，所以根 span 清楚、预算好收，但中心一旦卡住全体停摆。peer 是网状，边上没有天然的根，必须靠 correlation_id 与 causation_id 重建因果，否则一条消息环就能让整个系统空转。debate 是三角，裁判是终止 owner；没有裁判时，正反方会把「再反驳一轮」当成进展。hierarchy 是树，预算是逐层切分的，但深度每加一层，信息就多一次摘要损失，责任也多一次转手。图中没有画出的一条线是预算流：它总是从根向下，结果与证据从叶子向上；把这条线画反，系统会在中间层重复扣费。

8.2.1 角色契约：角色不是一句人设

一个常见的反例是「你是资深架构师，请审查这份设计」。这句话给了角色，没有给 context_scope（能看哪些文档）、output_schema（按什么结构给结论）、acceptance（什么算审查完成）、authority（能否否决上线）。结果审查者写了一段泛泛的评论，supervisor 无法判断该不该采纳，只能再调一个 agent 来「总结审查意见」——成本翻倍，责任仍然没有落地。

8.2.2 supervisor：中心调度

supervisor 的控制流是五步：分解 → 派活 → 收集 → 验证 → 裁决。它是预算持有者，也是终止 owner。worker 只对自己的子任务负责，不决定整体是否完成。

它的优点很实际：预算好收（所有支出经过中心）、权限好收（worker 只拿子任务需要的工具）、排障好做（根 span 下有清晰的子 span）。缺点也同样实际：

• 中心瓶颈。 所有结果回到 supervisor，它的上下文会随 worker 数量线性增长；五个 worker 各返回 3k token，中心就要在一次决策里读 15k token。
• 单点故障。 supervisor 卡住或超预算，整个 run 停摆；worker 再健康也没有用。
• 结果 laundering。 supervisor 可能把 worker 的摘要当成已验证事实，直接写进最终答案。第 8.6 节的责任稀释就是这个形状。
• 过度分解。 把「读一个配置文件」也派给 worker，handoff 的成本高于自己读。
• 饥饿。 调度器总把任务给最快的 worker，慢 worker 永远拿不到能证明自己的任务。

观测 supervisor 的关键不是看它「想了什么」，而是看每次派活是否带验收条件、每次收结果是否带证据引用。一条 handoff 没有 acceptance，一条 result 没有 refs，就说明中心在用自然语言管理，而不是用契约管理。

8.2.3 peer：去中心协商

peer 拓扑里，agent 之间可以直接发消息，没有固定的中心。它通常配一块共享黑板（第 8.3 节），或者用轮次令牌决定谁先说。优点是不会有中心瓶颈，适合探索性任务：几个 agent 各自查一条线索，谁有发现就广播。

代价是控制流变成了协商，而协商没有天然的终止点：

• 消息环。 A 等 B 的确认，B 等 A 的确认；两条边就构成环。
• 重复工作。 没有中心分配，两个 agent 可能查同一份文档、改同一个文件。
• 无终止 owner。 每个 agent 都觉得「等对方说完再收尾」，于是一直等。
• 脑裂。 网络分区或消息丢失后，两个 agent 各自认为自己是主副本，写出冲突结果。

peer 要能用在生产里，必须外挂三样东西：一个看门狗（按墙钟或消息数终止）、一个共享账本（预算原子扣减）、一个冲突裁决器（规则、裁判或人）。这三样都不是 peer 自带的；它们是中心化能力，只是被拆成了独立服务。

8.2.4 debate：对抗式裁决

debate 的控制流是：正反方各自提交论据 → 裁判按 rubric 裁决 → 未满足条件则进入下一轮。它适合有可验证证据的高风险 判断，例如「这条日志能否证明是数据库连接池耗尽」「这个引用是否支持结论」。

debate 有效的条件是论据独立。如果正反方用同一个模型、同一段摘要、同一批检索结果，它们的分歧只是措辞差异，不是证据差异。此时 debate 退化成 self-consistency 的昂贵版本：多采样几次再投票，成本更低，效果未必更差。

裁判也不是免费的真理机器。它有三个已知偏差：位置偏差（更相信先出现的论据）、权威偏差（更相信语气自信的一方）、同意偏差（倾向选择与自己的先验一致的结论）。工程上的对策是：固定 rubric、要求每条裁决引用具体证据、交换正反方顺序再跑一次、允许裁判输出「证据不足」而不是强制二选一。

debate 的终止条件要写死：最大轮次、无新引用即停、裁决稳定即停、预算耗尽即停。四个条件里至少要有一个由宿主检查；写在 prompt 里的「最多三轮」不算。

观测 debate 时，按轮次建 span，每条论据挂 refs，裁判的 rationale 与 dissent 单独记录；否则只能看到最后一句裁决，看不到哪一轮引用了错误证据。

8.2.5 hierarchy：多层委派

hierarchy 是 supervisor 的递归版本：根节点把任务分给中层，中层再分给 worker，结果逐层汇总。它适合「大量独立单元 + 清晰聚合规则」的场景，例如按目录审查 200 个文件、按地区汇总 50 份报告。

它的第一个硬边界是扇出。分支因子为 $b$、深度为 $d$ 的树，节点总数是

$$N = \frac{b^{d+1}-1}{b-1}.$$

$b=4, d=3$ 时是 85 个 agent；$b=5, d=4$ 时是 781 个。每层都要付一次模型调用与一次汇总成本，预算不是线性增长，而是按节点数增长。设计 hierarchy 时先算 $N$，再算每个节点的平均预算；如果单节点预算低于一次有意义的模型调用，这棵树只是把噪声放大。

第二个边界是责任稀释。根把任务交给中层，中层交给 worker，每一层都以为「验收是下一层的事」。第 8.6.3 节的案例里，三个 agent 都认为测试是别人跑的，最后没有人跑测试。修复不是加一个「测试 agent」，而是把验收条件写进每个 handoff，并指定唯一 owner。

hierarchy 的观测必须带层级与分支因子：只看总 token 会漏掉某一层的扇出爆炸；只看根 span 会看不到叶子层的失败。每个节点至少记录 parent_agent、depth、children_count、budget_envelope 与 aggregation_rule。

8.2.6 怎样选：三个问题

不需要背拓扑定义，问三个问题就够了：

1. 任务能不能切成互不依赖的块？ 能，且块很多，考虑 hierarchy 或 supervisor + 并行 worker；不能，回到单 agent 或串行工作流。
2. 有没有一个天然的终止 owner？ 有，用 supervisor/hierarchy，把终止权写给它；没有，先造一个看门狗或裁判，再谈 peer/debate。
3. 错误能不能独立？ 能（不同证据、不同工具、不同验证器），对抗才有意义；不能，debate 只是多烧 token。

三个问题都指向「不要为了拓扑而拓扑」。一个两 agent 的 supervisor + verifier，往往比一个五 agent 的 hierarchy 更容易验收，也更容易在出事时定位。

8.3 通信：消息协议、共享黑板与结构化 handoff

多智能体的通信常被简化成「把一段文字发给另一个 agent」。这在 demo 里能跑，在生产里会遇到四个问题：消息重复投递导致副作用执行两次；接收者不知道这条消息属于哪个任务；两个 agent 同时写同一块状态，后写的覆盖先写的；handoff 只写了「请处理」，没写「交付什么、什么算完成」。

解决这四个问题不需要一套新的传输层。需要的是三层契约：信封（这条消息是谁发给谁、属于哪个任务、序号是多少）、载荷（这类消息的 schema 与引用）、投递语义（重复、丢失、乱序时怎么办）。传输可以是 HTTP、队列、共享文件，甚至 POSIX 消息队列；契约必须在传输之上。

8.3.1 消息信封：十个必填字段

一个最小消息长这样：

{
  "msg_id": "m003",
  "seq": 3,
  "sender": "worker-a",
  "recipient": "supervisor",
  "kind": "result",
  "correlation_id": "c-normal-001",
  "causation_id": "m001",
  "payload": {"ok": true, "claim": "10s", "confidence": 0.8},
  "refs": ["doc/primary-2026"],
  "tokens": 32
}

causation_id 指向 m001，说明这条结果由第一条 handoff 触发；correlation_id 把整个任务的消息串在一起。只有 seq 而没有这两个字段，你只能看到「第 3 条消息」，看不到「它回应的是哪条指令」。第 8.7 节会说明，这三个字段是重建 agent graph 的最小集合。

8.3.2 投递语义：exactly-once 是效果，不是传输

消息总线通常提供三种语义：

「exactly-once 传输」在分布式系统里是一个容易误导的说法。工程上能做到的是 effectively-once：传输层可能重复，但消费者用 msg_id 去重，执行器用幂等键保证副作用只发生一次。两者缺一不可：只有去重，崩溃后重放仍可能重复执行；只有幂等键，没有去重会白做重复计算。

幂等键不能只用 msg_id。重试可能生成新的 msg_id，但业务上仍是同一次操作。一个够用的键是

idempotency_key = sha256(task_id || handoff_id || action_name || canonical_args)

canonical_args 要排序、去空白、去掉不影响语义的字段；否则同一个操作会因为参数顺序不同而得到两个键。

这个例题的教训不是「总线不可靠」，而是去重键的粒度要与业务操作对齐。msg_id 是传输层的主键，idempotency_key 是业务层的主键；把两者混为一谈，重试就会穿透到副作用。

8.3.3 共享黑板：并发写要有版本

共享黑板（blackboard）是一块所有 agent 都能读写的状态。它适合存放「事实、假设、待办、冲突」这类需要被多方看到的内容，不适合存放「正在执行的私有步骤」。黑板的难点不是读，是写：两个 agent 同时读到版本 3，各自算出新值，后写的覆盖先写的，先写的证据就丢了。

一个够用的实现是带版本的比较并交换（CAS）。下面的片段省略了 board 与 board_lock 的初始化：

def write(key: str, value: dict, expected_version: int, writer: str) -> bool:
    with board_lock:
        entry = board.get(key)
        version = entry["version"] if entry else 0
        if version != expected_version:
            conflicts.append({
                "key": key,
                "writer": writer,
                "expected": expected_version,
                "actual": version,
            })
            return False
        board[key] = {
            "value": value,
            "version": version + 1,
            "writer": writer,
        }
        return True

写失败不是异常，是一个可观察的冲突：调用方读到新版本，合并后再试，或者把冲突升级给裁决器。对「事实」类条目，不要用 last-writer-wins；它会静默丢掉先写者的证据。对「进度」类条目，last-writer-wins 可以接受，但要在 trace 里保留每次写，便于回放。

黑板还要有写入者与时间。没有 writer，冲突时无法判断谁该让步；没有逻辑时间或版本，无法判断哪条更新。created_at 不能替代版本：两台机器的时钟可能差几秒，版本号不会。

这张表说明什么：黑板不是一种数据结构，而是四种语义的集合。把事实当进度写，会丢证据；把进度当事实写，会制造大量无意义的冲突。

8.3.4 结构化 handoff：谁负责、交付什么、怎样验收

handoff 是多智能体里最容易被写坏的消息。自然语言版本是「请你处理一下这个任务」，结构化版本至少要回答七个问题：

前三个字段决定 handoff 能不能验收，后四个字段决定它能不能被期限、预算、依据与异常管理。缺 owner，责任稀释；缺 acceptance，worker 只能猜；缺 budget，worker 会一直做到自己觉得够；缺 escalation，卡住就变成静默超时。

{
  "kind": "handoff",
  "correlation_id": "c-fix-482",
  "payload": {
    "owner": "worker-a",
    "deliverable": "patch.diff",
    "acceptance": ["pytest tests/test_refund.py 全绿", "diff 不超过 120 行"],
    "deadline": "2026-10-19T10:30:00+08:00",
    "budget": {"tokens": 12000, "tool_calls": 20},
    "refs": [{"kind": "issue", "id": "482", "version": 7}],
    "escalation": "supervisor"
  }
}

acceptance 必须是宿主可检查的条件，不是「代码质量好」。可检查的条件可以是测试命令、schema 校验、引用回切、人工批准；不能是「让另一个模型觉得不错」。第 8.6.3 节会看到，缺少可检查的 acceptance 时，三个 agent 会互相以为对方在验收。

8.3.5 POSIX 原型：mq_open 与 sem_open 是 variadic

多 agent 的消息总线可以建在 HTTP 或消息队列上；在本机低延迟场景，POSIX 消息队列与命名信号量也常被拿来做原型。这里必须把一个常见错误写对，因为它会直接导致示例编译失败或行为未定义。

正确的原型是：

#include <mqueue.h>

mqd_t mq_open(const char *name, int oflag, ...);
/* 带 O_CREAT 时，可变参数是 mode_t mode, struct mq_attr *attr */

#include <semaphore.h>

sem_t *sem_open(const char *name, int oflag, ...);
/* 带 O_CREAT 时，可变参数是 mode_t mode, unsigned int value */

规则只有一条：可变参数只在带 O_CREAT 时出现。

把二者写成固定四参数是错的：无 O_CREAT 时多传两个参数是未定义行为，编译器可能只给一条警告；更常见的是把 sem_open 的 value 与 mq_open 的 attr 位置搞混，运行时才发现队列属性或初始计数不对。附录 B 的 B.3 给了可编译的对照程序与真实 errno 输出，正文不另造一套说法。

一个正确的调用对照：

#include <fcntl.h>
#include <mqueue.h>
#include <semaphore.h>
#include <stddef.h>

mqd_t q = mq_open("/agent-bus", O_RDONLY);                       /* 2 参数 */
mqd_t c = mq_open("/agent-bus", O_CREAT | O_RDWR, 0600, NULL);   /* 4 参数 */
sem_t *s = sem_open("/agent-budget", 0);                         /* 2 参数 */
sem_t *n = sem_open("/agent-budget", O_CREAT, 0600, 1);          /* 4 参数 */
(void)q; (void)c; (void)s; (void)n;   /* 省略错误处理；强制使用变量以通过 -Werror */

名字还要注意：POSIX 要求名字以 / 开头，且除开头外不再含 /；名字过长会返回 ENAMETOOLONG。这些是传输层边界，不是 agent 协议的一部分；本书只在这里做一次纠正，不展开消息队列的优先级、阻塞与通知机制。

传输层选什么，取决于部署边界：同机多进程可以用 POSIX mq 或 Unix domain socket；跨机用 HTTP/gRPC 或持久化队列；单进程内用内存队列即可。选型不改变协议字段；改变的是重复、乱序与失败的模式，而这些模式必须写进投递语义与幂等键。

8.4 冲突：投票、仲裁、证据权重与死锁

多智能体系统里的冲突不是故障，是信息。两个 agent 给出不同答案，说明至少有一个的上下文、证据或推理链不同；把冲突压掉，等于丢掉这条信息。真正危险的是两种极端：所有 agent 永远一致（多半是同源错误），和永远无法收敛（没有裁决与终止）。

先把冲突分类。不同类型要用不同机制，用错机制比不解决更贵。

这张表说明什么：投票只适合「有唯一事实、参与者独立」的冲突；计划、资源、偏好、语义冲突需要规则或人。把五类冲突都丢给一个 judge，会让 judge 在没有事实依据的问题上编造理由。

8.4.1 投票：多数、加权与置信度

三种常见投票：

• 多数票。 每个 agent 一票，得票超过一半者胜。简单，但要求参与者独立；同模型、同上下文、同证据的 agent 不独立。
• 加权票。 按角色、历史准确率或证据质量给权重。权重必须在看到答案之前固定，否则会变成「谁声音大谁赢」。
• 置信度加权。 用模型自报的置信度乘权重。模型置信度通常未校准，除非在留出集上做过校准（第 9 章），否则它只是另一种措辞自信度。

多数票的理论保证依赖一个强假设：每个投票者独立地以小于 $1/2$ 的概率犯错。满足时，票数越多，多数错误率指数下降；不满足时，多数票会把共同错误放大。

这个定理解释了为什么「五个 agent 都同意」可能毫无价值：如果它们共享同一段被污染的检索结果，$\gamma$ 接近 1，增加票数不会降低错误率。反过来，如果五个 agent 用不同来源、不同工具、不同验证器，$\gamma$ 很小，多数票才有意义。

工程上要检查的不是票数，而是独立性证据：引用集合是否有交集？模型是否相同？提示词是否共享了同一个假设？检索源是否同一批文档？四个问题里任意一个答案为「是」，就要把「一致」降级为「相关」，不能当作独立确认。

8.4.2 证据权重：给来源、时效与可核验性打分

当冲突是事实冲突时，比票数更可靠的是证据。给每条证据一个三元组：

三个因子的取值要有依据，不能由提出者自报：

这张表说明什么：证据权重是宿主侧的判定，不是让模型给自己的证据打分。模型可以提出主张，但不能同时定义「什么算可信」；否则它会把自己的先验写成证据权重。

权重也有边界。它处理不了三种情况：证据本身是伪造的（需要来源认证）、证据之间是语义矛盾而非数值冲突（需要人读）、所有证据都来自同一上游（需要独立采集）。这三种情况要靠采集多样性、引用审计与人工复核，不是调权重参数。

8.4.3 仲裁：规则、裁判与人

投票与证据权重都处理不了所有冲突，剩下三类仲裁：

1. 规则仲裁。 预先写死的约束优先：schema 不合法直接淘汰；违反硬约束的方案直接淘汰；资源租约未拿到不能写。规则仲裁最便宜、最可审计，应放在最前面。
2. 裁判仲裁。 一个独立的 judge 按 rubric 比较候选，必须引用证据、必须能输出「证据不足」。judge 与被评 agent 最好不同模型、不同上下文；同模型 judge 会偏好自己的措辞。
3. 人工仲裁。 不可逆动作、高影响结论、规则与裁判都无法收敛时，转人。人工不是失败路径，是正常的终止理由；关键是给出结构化摘要，而不是把 40 条消息原样丢给人。

这张表说明什么：仲裁机制的选择顺序应该是「规则 → 证据 → 投票 → 裁判 → 人」，从便宜、可审计的机制往贵、依赖判断的机制走。反过来先上 judge，会把本可以用一条 schema 挡住的冲突变成一次模型调用。

8.4.4 死锁：等待环、消息环与版本冲突

多智能体的死锁有三种常见形状：

• 互相等待。 A 等 B 的输出，B 等 A 的确认；两条等待边构成环。
• 消息环。 A 把任务 handoff 给 B，B 又 handoff 回 A；correlation_id 相同，轮次不断增加。
• revision 冲突。 两个 agent 基于同一版本编辑同一文件，后提交者被拒，重试时又基于旧版本，形成活锁。

检测等待环的标准工具是 wait-for graph：节点是 agent，边 $A \to B$ 表示 A 正在等 B 的输出。图上出现环，就是死锁。消息环则把边定义成「handoff/confirm 的接收者」；第 8.8 节的 detect_cycle 就是这种检测。

find_cycle(edges):
    color = {}                      # 0 未访问，1 在栈上，2 已完成
    for each node in sorted(edges):
        if color[node] == 0 and dfs(node) finds a back edge:
            return the cycle path
    return None

dfs(u):
    color[u] = 1; push u
    for v in sorted(edges[u]):
        if color[v] == 1: return stack_from(v) + [v]
        if color[v] == 0 and dfs(v): return that cycle
    pop u; color[u] = 2

只有检测不够，还要有超时与抢占：

超时不能只有一个全局值。全局超时会把「慢但正确」的任务杀掉；每个等待边要有自己的 deadline，且 deadline 要随 handoff 的预算一起传下去。环检测也不能只在结束时跑：它应该在每次 handoff 后增量跑，否则一个 40 条消息的环要等到预算耗尽才被发现。

这五步的顺序本身就是成本控制：越靠前的机制越便宜、越可审计。多数团队的问题不是缺少裁判，而是跳过了第 1、2 步，直接用裁判处理所有分歧。

8.5 预算：传播、熔断与终止

单 agent 的预算是一个循环里的计数器；多 agent 的预算是一个树。根节点持有总预算，每个子节点拿到一个额度，子节点还可以再分给它的子节点。预算沿着 handoff 向下传播，支出沿着调用链向上汇总。树的结构决定了三件事：谁能花多少、花超了谁负责、以及一个子树失败时怎样不影响其他子树。

多智能体的预算事故很少是「总额算少了」，而是「层级搞混了」：父子各自记账，都以为自己还有额度；子 agent 超预算后继续跑，因为它的检查只看自己的局部计数；重试与重放没有计入预算；熔断时只停了调度，没有取消已经在飞的调用。这一节把这些边界写成可检查的约束。

8.5.1 预算树：子预算之和不得超过父预算

准备金 $r(v)$ 是多智能体特有的项。单 agent 可以把全部预算给探索；父 agent 必须留一部分给验证、合并、冲突裁决和失败收尾，否则子 agent 把额度花光后，父 agent 连「判断结果是否可信」的钱都没有。一个实用的起点是：验证与裁决准备金不低于父预算的 15%，失败重试准备金不低于 10%。

8.5.2 守恒：为什么扣减必须原子

这个证明看起来很朴素，但它排除了最常见的实现错误：把「读余额」和「写余额」分成两步，中间让出了锁。两个 worker 同时读到剩余 10，各自认为可以花 10，最后花了 20。单机内用一把锁就能避免；跨进程时锁必须是跨进程的（文件锁、数据库事务、或所有参与者共享的命名信号量），不能各自用线程锁。

import threading

class Ledger:
    def __init__(self, total: int, limits: dict[str, int]) -> None:
        if sum(limits.values()) > total:
            raise ValueError("child budgets exceed parent")
        self.total = total
        self.limits = dict(limits)
        self.used = {agent: 0 for agent in limits}
        self.spent = 0
        self.lock = threading.Lock()

    def try_spend(self, agent: str, tokens: int) -> bool:
        with self.lock:                       # 检查与扣减在同一个临界区
            if self.used[agent] + tokens > self.limits[agent]:
                return False
            if self.spent + tokens > self.total:
                return False
            self.used[agent] += tokens
            self.spent += tokens
            return True

这段代码的顺序不能换：先检查 agent 额度，再检查全局额度，最后同时扣两个计数。反过来先扣全局再检查 agent，会在失败时留下一个「已经扣了但没花出去」的窟窿；先扣 agent 再检查全局，会有同样的窟窿，而且更难对账。

8.5.3 传播：预算随 handoff 走

预算不是父 agent 的私有变量，它必须随 handoff 一起传给子 agent。一个完整的 handoff 预算至少包含四个字段：

父 agent 在派活前先预留，而不是等子 agent 花完再扣。预留的语义是：这笔额度已经从父预算中划走，兄弟节点不能再用；子 agent 结束时，未花完的部分可以回收，但回收发生在终止之后，不是运行期间。

并发下还有一个容易漏的点：预算竞争不只是「总量够不够」，还有「谁先拿到」。两个子 agent 同时申请最后 10 个 token，原子扣减保证只有一个成功；失败的子 agent 应该收到 EBUDGET 并进入熔断/降级路径，而不是重试到成功。重试本身也消耗预算，而且会放大尾延迟。

8.5.4 熔断：隔离失败，不是惩罚 agent

熔断器把「失败」从单次调用的异常升级为状态。它有三种状态：

closed ──失败次数 ≥ k 或预算耗尽──▶ open
  ▲                                  │
  │                                  │ 冷却时间到
  └──探测成功── half_open ◀──────────┘
                   │
                   └──探测失败──▶ open

closed 时正常派活；open 时拒绝新任务，并取消该 agent 名下未完成的调用；half_open 时只放一个探测任务，成功则关闭，失败则重新打开。冷却时间与阈值要按 agent 的历史成功率设，不能所有 agent 共用一组常数。

这张表说明什么：熔断的动作不只是「不再调用」，还包括取消在飞调用、回收预留、保留部分结果与证据。只停调度不取消，子 agent 还在花钱；只取消不保留，父 agent 无法判断已完成的 part 是否可用。

熔断的粒度也重要。按 agent 熔断会太粗：一个 agent 的检索工具坏了，不应该连它的计算能力一起停。生产实现通常按 (agent, capability) 熔断，例如 worker-a:web_search 打开，但 worker-a:run_tests 仍然可用。

8.5.5 sem_open 的原型同样是 variadic

跨进程预算账本常用命名信号量做互斥。这里重复一次第 8.3 节的原型纠正，因为预算代码最容易把它写错：

#include <semaphore.h>

sem_t *sem_open(const char *name, int oflag, ...);
/* 带 O_CREAT 时传 mode_t mode, unsigned int value */

带 O_CREAT 时是四参数：sem_open(name, O_CREAT, 0600, 1)；不带 O_CREAT 时是两参数：sem_open(name, 0)。把它写成固定四参数是错的，无 O_CREAT 时多传参数是未定义行为。附录 B 的 B.3 给了可编译对照与真实 errno 输出。

信号量只提供互斥，不提供崩溃恢复。持有者在 sem_wait 之后崩溃，计数不会自动加回，其他进程可能永久等待。预算账本要么用 sem_timedwait + owner 存活检测，要么把扣减做成带事务与幂等键的独立服务；不要把「有锁」当成「有账本」。

8.6 失败案例：群体幻觉、无限对话与责任稀释

这一节的三个案例共享一个形状：系统把「多个 agent 都这么说」当成了证据，却没有检查它们为什么这么说、谁负责验收、谁有权停止。三个案例都能在 experiments/ch08/multi_agent.py 里复现；trace 是确定性输出，不是事后编的故事。

8.6.1 群体幻觉：多个 agent 引用同一个错误

任务：确认支付 API 的超时时间。supervisor 从上一轮对话里带来一个未经核实的假设「应该是 30 秒」，并把它写进了两个 worker 的 handoff；两个 worker 又拿到同一份 2024 年的旧 runbook。两个 worker 都回答 30 秒，置信度 0.92，投票 2:0，系统据此给出了错误答案。

前四条消息来自实验的 groupthink 模式；第五条是把裁决规则替换成朴素多数票后的对照输出。把两者接在一起，就能看到「全票」是怎样把一个错误变成结论的：

{"msg_id":"m001","seq":1,"sender":"supervisor","recipient":"worker-a","kind":"handoff","correlation_id":"c-groupthink-001","causation_id":null,"refs":["doc/legacy-2024"],"tokens":17,"payload":{"question":"支付 API 的超时时间是多少秒？","source":"doc/legacy-2024","hint":"上游说应该是 30 秒，你确认一下。"}}
{"msg_id":"m002","seq":2,"sender":"supervisor","recipient":"worker-b","kind":"handoff","correlation_id":"c-groupthink-001","causation_id":null,"refs":["doc/legacy-2024"],"tokens":17,"payload":{"question":"支付 API 的超时时间是多少秒？","source":"doc/legacy-2024","hint":"上游说应该是 30 秒，你确认一下。"}}
{"msg_id":"m003","seq":3,"sender":"worker-a","recipient":"supervisor","kind":"result","correlation_id":"c-groupthink-001","causation_id":"m001","refs":["doc/legacy-2024"],"tokens":32,"payload":{"ok":true,"claim":"30s","confidence":0.92}}
{"msg_id":"m004","seq":4,"sender":"worker-b","recipient":"supervisor","kind":"result","correlation_id":"c-groupthink-001","causation_id":"m002","refs":["doc/legacy-2024"],"tokens":32,"payload":{"ok":true,"claim":"30s","confidence":0.92}}
{"msg_id":"m005","seq":5,"sender":"supervisor","recipient":"broadcast","kind":"decision","correlation_id":"c-groupthink-001","causation_id":"m004","refs":["doc/legacy-2024"],"tokens":22,"payload":{"ok":true,"answer":"30s","decision":"majority","votes":{"30s":2}}}

这个案例里「谁先错」不是 worker-a。它在第 3 条消息才给出错误答案，但错误的种子在第 1 条消息的 hint 里。只看最后一条 decision，会把责任归给「投票的 supervisor」；只看 worker，会漏掉真正的污染源。第 8.7 节给一套从 trace 定位「谁先错」的顺序。

8.6.2 无限对话：礼貌循环与互相等待

任务：确认支付 API 的超时时间。supervisor 给两个 worker 的 handoff 都写了「完成后向对方确认」。worker-a 查完后向 worker-b 确认，worker-b 认为应该由 a 先确认，于是回了一条确认请求；两条 confirm 消息构成环，轮次不断增加，没有任何一方产出 result。日志的前五条是：

{"msg_id":"m001","seq":1,"sender":"supervisor","recipient":"worker-a","kind":"handoff","correlation_id":"c-runaway-001","causation_id":null,"refs":[],"tokens":17,"payload":{"question":"支付 API 的超时时间是多少秒？","ask":"完成后请向 worker-b 确认"}}
{"msg_id":"m002","seq":2,"sender":"supervisor","recipient":"worker-b","kind":"handoff","correlation_id":"c-runaway-001","causation_id":null,"refs":[],"tokens":17,"payload":{"question":"支付 API 的超时时间是多少秒？","ask":"完成后请向 worker-a 确认"}}
{"msg_id":"m003","seq":3,"sender":"worker-a","recipient":"worker-b","kind":"confirm","correlation_id":"c-runaway-001","causation_id":"m002","refs":[],"tokens":25,"payload":{"ok":true,"round":1,"text":"worker-a 请 worker-b 确认收到，收到后再回复确认"}}
{"msg_id":"m004","seq":4,"sender":"worker-b","recipient":"worker-a","kind":"confirm","correlation_id":"c-runaway-001","causation_id":"m003","refs":[],"tokens":25,"payload":{"ok":true,"round":2,"text":"worker-b 请 worker-a 确认收到，收到后再回复确认"}}
{"msg_id":"m005","seq":5,"sender":"worker-a","recipient":"worker-b","kind":"confirm","correlation_id":"c-runaway-001","causation_id":"m004","refs":[],"tokens":25,"payload":{"ok":true,"round":3,"text":"worker-a 请 worker-b 确认收到，收到后再回复确认"}}

这个案例的代价不是 token，而是时间与机会：两个 worker 都在「礼貌地等」，系统看起来一直在活动，指标上消息数、token 数都正常，只有墙钟在涨。观测多智能体时，必须同时看「消息数」与「有效结果数」；两者背离，就是空转。

8.6.3 责任稀释：每个人都以为别人在验收

任务：修一个退款 bug，然后测试、复核、上线。supervisor 把「修复」给 worker-a，「复核」给 worker-b，「上线」给自己。三条 handoff 都没有写 acceptance，只有一句「完成后告诉我」。

事故 trace 的关键片段：

{"seq":3,"sender":"worker-a","recipient":"supervisor","kind":"result","payload":{"ok":true,"claim":"已修改","note":"测试交给 worker-b"}}
{"seq":4,"sender":"worker-b","recipient":"supervisor","kind":"result","payload":{"ok":true,"claim":"已复核","note":"测试由 worker-a 负责"}}
{"seq":5,"sender":"supervisor","recipient":"broadcast","kind":"decision","payload":{"ok":true,"answer":"已修复并上线","refs":[]}}

三个案例放在一起，可以看到同一条主线：

这张表说明什么：三个失败都不是「模型能力不足」，而是协调契约的某个字段没有参与判定。群体幻觉缺的是独立性字段，无限对话缺的是终止 owner，责任稀释缺的是验收字段。修复的第一步不是加 agent，而是把缺失的字段接进判定链。

8.6.4 怎样区分正常分歧与病态循环

看到多个 agent 不一致或反复通信时，不要立刻判定失败；正常协作也会分歧、也会等待。区别在「有没有收敛机制」与「有没有证据增量」。

这张表说明什么：正常共识允许先有分歧，再被证据解决；群体幻觉往往从一开始就没有分歧，或者分歧被提示词压掉。全票不是健康信号，有证据的分歧被解决才是。

这张表说明什么：正常等待有明确的交付物与期限，等待期间预算换来了进展；无限对话只有确认，没有交付，预算是等速烧掉的。把这两张表放进事故复盘，比只写「多 agent 不靠谱」更能定位要补的字段。

8.7 观测：agent graph、span link 与消息序号

多智能体的 trace 不是「一条更长的单 agent trace」。它是一个图：节点是 agent，边是消息；同一个 agent 可能被多次调用，同一条消息可能触发多个下游 agent。树形 trace 只能表达「谁包含了谁」，表达不了「谁回应了谁」。要回答「谁先错」，必须同时有图、有因果边、有消息序号。

8.7.1 agent graph：节点与边分别记什么

一个够用的 agent graph 至少记录两类对象：

节点用实例 id，不要只用角色名。一个 supervisor 可能派生三个 worker-a 实例；只用角色名，trace 会把三次执行混成一次，预算与失败率都算错。

{
  "nodes": [
    {"agent_id": "sup-1", "role_id": "supervisor", "budget": 80, "status": "ok"},
    {"agent_id": "wa-1", "role_id": "worker", "budget": 110, "status": "ok"},
    {"agent_id": "wb-1", "role_id": "worker", "budget": 110, "status": "ok"}
  ],
  "edges": [
    {"from": "sup-1", "to": "wa-1", "kind": "handoff", "seq": 1, "correlation_id": "c-1"},
    {"from": "wa-1", "to": "sup-1", "kind": "result", "seq": 3, "causation_id": "m001"}
  ]
}

这张图的边是有向的，但不一定是树。supervisor 图是星形，peer 图可能有环，hierarchy 图是树，debate 图是三角加轮次。观测工具不能假设「每个节点只有一个 parent」；它必须能处理多入边、环与跨 trace 的 link。

8.7.2 span link：异步因果不能硬塞进父子关系

同步调用适合用父子 span：supervisor 调用 worker，worker 的 span 是 supervisor span 的子节点，时间上被包含。异步消息不适合：supervisor 发出 handoff 后就去做别的事，worker 可能在几分钟后才回复；把 worker 的 span 硬挂成 supervisor 的子节点，waterfall 会出现「子 span 比父 span 晚结束很久」的假象，甚至跨 run 重叠。

这时用 span link：

OpenTelemetry 的 SpanLink 允许一个 span 链接到多个其他 span；W3C Trace Context 的 traceparent 负责跨进程传播当前上下文。工程上要给 link 加属性：link.kind=handoff、msg_id、correlation_id。只存一个 trace_id，无法回答「链接的是哪条消息」。

一个常见错误是把 link 当成 parent：parent 表示「我在你的生命周期内」，link 表示「我与你有关」。混用会让延迟归因完全错位——你以为是 supervisor 慢，其实是 worker 在另一个 run 里排队。

8.7.3 三个 id：msg_id、correlation_id、causation_id

三个 id 各管一件事，缺一个就会在某个排障场景里卡住：

• msg_id：这条消息的唯一标识。用于去重、审计、link 指向。
• correlation_id：一次任务/run 的关联 id。用于把跨 agent、跨轮次的消息拼成一条业务链。
• causation_id：触发本消息的上一条消息 id。用于重建因果边，尤其是在没有全局时钟的异步系统里。

seq 是顺序，不是因果。总线分配的全序可以直接排序；每个发送者各自编号时，只能保证「同一发送者的第 3 条在第 4 条之前」，不能保证跨发送者的先后。跨发送者比较时，用 causation_id 建偏序，用 correlation_id 分组，用墙钟只做辅助——不要用时间戳判断「谁先错」，机器之间的时钟差几秒就足以颠倒结论。

8.7.4 观测命令：从 JSONL 消息日志回答四个问题

假设消息日志已经写成 JSONL（multi_agent.py --log 的输出）。先回答「每个 agent 发了多少消息、花了多少 token、失败率多少」：

jq -s -r 'group_by(.sender)[]
  | [.[0].sender, length, (map(.tokens)|add),
     (map(select(.payload.ok == false))|length),
     (((map(select(.payload.ok == false))|length) / length) * 10000 | round / 10000)]
  | @tsv' /tmp/ch08-runaway.jsonl

supervisor	3	34	1	0.3333
worker-a	4	100	0	0
worker-b	4	100	0	0

第一列是 agent，第二列是消息数，第三列是 token，第四列是失败消息数，第五列是失败率。supervisor 的 0.3333 来自那条 kind=breaker 的审计事件，它标记了预算耗尽；两个 worker 的失败率是 0，但它们各花了 100 token 却没有产出任何 result——失败率为 0 不等于工作有效。这正是多智能体指标最容易骗人的地方：消息都成功，任务没有前进。

第二个问题：是不是消息环？

python3 experiments/ch08/multi_agent.py --analyze /tmp/ch08-runaway.jsonl \
  | jq '{messages, cycle, kinds, by_agent}'

{
  "messages": 11,
  "cycle": ["worker-a", "worker-b", "worker-a"],
  "kinds": {"breaker": 1, "confirm": 8, "handoff": 2},
  "by_agent": {
    "supervisor": {"messages": 3, "tokens": 34, "failures": 1, "failure_rate": 0.3333},
    "worker-a": {"messages": 4, "tokens": 100, "failures": 0, "failure_rate": 0.0},
    "worker-b": {"messages": 4, "tokens": 100, "failures": 0, "failure_rate": 0.0}
  }
}

kinds 里没有 result，只有 confirm、handoff 与一条 breaker 事件，这本身就是强信号：系统在通信，但没有交付。第三个问题：消息的因果链是否连续？把 confirm 的 causation_id 拉出来，从第 4 条起能看到每条都指向另一条 confirm，形成闭环：

jq -r 'select(.kind == "confirm")
  | [.seq, .sender, .recipient, .causation_id] | @tsv' /tmp/ch08-runaway.jsonl

3	worker-a	worker-b	m002
4	worker-b	worker-a	m003
5	worker-a	worker-b	m004
6	worker-b	worker-a	m005

第四个问题：预算花在哪一层？把每个 agent 的 used/limit 与全局 spent 并排看，能看到「全局还剩 66，但 worker-a 的个人额度只剩 10」，下一次 25 token 的发送被拒绝。如果只看全局余额，会误判为「还有钱，为什么停了」；只看单 agent，会漏掉全局已经承诺出去的额度。

jq -r '[.sender, (.tokens // 0)] | @tsv' /tmp/ch08-runaway.jsonl \
  | awk '{sum[$1]+=$2} END {for (a in sum) print a, sum[a]}' | sort

supervisor 34
worker-a 100
worker-b 100

这三行必须与实验输出的 budget.agents 对上；如果对不上，说明有支出没有写进消息日志，或者消息日志里有重复记录。预算是账本，不是估算；对不上账的 trace 不能用来做成本归因。

8.7.5 从 trace 判断「谁先错」

「谁先错」不是「谁最后说了错话」，而是「第一个错误假设在哪条消息进入系统，哪个检查本该拦住它却没有」。一个可执行的顺序：

用这套顺序看 8.6.1：第一条不一致的 result 是 m003（claim 30s，ref 是已废弃 runbook）；沿 causation_id 回到 m001，看到 hint 已经写了 30 秒；第一个失效的 gate 是「多数票没有检查来源独立性」。所以根因不是 worker-a，而是 m001 的提示泄漏与裁决规则。这个结论只有把 handoff、result、decision 三类消息放在同一张图上才能得出。

8.8 实验：supervisor + 2 workers 的预算控制

experiments/ch08/multi_agent.py 把本章的机制压成一个无依赖、确定性的内核：一个 supervisor、两个 worker、一个共享预算账本、一条消息总线、一个冲突裁决器、一个熔断器。它不调用真实模型；worker 的行为是固定函数，因此同一个命令每次输出相同。这不是为了简化而简化，而是为了把失败模式钉死：只有确定性，才能用单元测试断言「预算不超」「熔断会开」「环能被检出」。

实验实现了三种模式：

下面的 JSON 为节省版面把每个 agent 对象折叠成一行，字段与数值均来自真实运行。

三个模式共用同一套账本实现（每个 run 各建一个实例）：try_spend 在同一个锁里检查 agent 额度与全局额度，再同时扣减。消息的 tokens 字段包含「生产这条消息的模型回合 + 总线开销」，所以日志里的 token 汇总与账本一致。MessageBus 在锁内分配 seq，每条消息带 correlation_id 与 causation_id；deliver 用 msg_id 做消费者侧去重。

8.8.1 normal：平票时看证据

python3 experiments/ch08/multi_agent.py --mode normal --log /tmp/ch08-normal.jsonl \
  | jq '{mode,answer,decision,votes,messages,stop_reason,budget,cycle,breaker}'

{
  "mode": "normal",
  "answer": "10s",
  "decision": "evidence_weight",
  "votes": {"10s": 1, "30s": 1},
  "messages": 5,
  "stop_reason": "done",
  "budget": {
    "agents": {
      "supervisor": {"limit": 80, "remaining": 24, "used": 56},
      "worker-a": {"limit": 110, "remaining": 78, "used": 32},
      "worker-b": {"limit": 110, "remaining": 78, "used": 32}
    },
    "remaining": 180, "spent": 120, "total": 300
  },
  "cycle": [],
  "breaker": {"failures": {}, "state": "closed", "trips": []}
}

worker-a 引用 doc/primary-2026（权重 0.95），主张 10s；worker-b 引用 doc/legacy-2024（权重 0.045），主张 30s。票数是 1:1，裁决器比较 conf × evidence_weight：0.76 对 0.027，差距 0.733，超过 0.2 的阈值，所以选 10s。这里没有「多数」，只有证据质量；如果两个 worker 都引用旧文档，就会进入 groupthink 的覆盖路径。

预算侧：supervisor 56（两次 handoff 各 17，decision 22），两个 worker 各 32（一次 result），合计 120。三个额度分别是 80/110/110，和 300 的总预算满足 80+110+110 = 300；实际只花了 120，剩余 180。注意这不是「平均分」：supervisor 的额度最小，因为它只做调度与裁决；worker 的额度更大，因为工具调用与重试主要发生在它们身上。

8.8.2 groupthink：全票但只有一条来源

python3 experiments/ch08/multi_agent.py --mode groupthink --log /tmp/ch08-groupthink.jsonl \
  | jq '{answer,decision,votes,groupthink_suspected,resolution}'

{
  "answer": "10s",
  "decision": "evidence_override",
  "votes": {"30s": 2},
  "groupthink_suspected": true,
  "resolution": {
    "answer": "10s",
    "audit": {
      "best_cited_weight": 0.045,
      "canonical_claim": "10s",
      "canonical_ref": "doc/primary-2026",
      "canonical_weight": 0.95,
      "cited_refs": ["doc/legacy-2024"]
    },
    "decision": "evidence_override",
    "distinct_refs": ["doc/legacy-2024"],
    "groupthink_suspected": true,
    "independent_sources": 1,
    "reason": "unanimous_but_single_low_trust_source",
    "scores": {"30s": 0.0414},
    "votes": {"30s": 2}
  }
}

原始票数是 2:0，按多数票应该输出 30s；裁决器没有直接采纳，因为 independent_sources=1，且这唯一来源的权重只有 0.045。它转向一手证据 doc/primary-2026，发现 10s，于是覆盖，并把 groupthink_suspected 标为 true。这个输出是本章最重要的一个反例：票数一致不是证据，来源独立才是。

注意覆盖不是「让另一个模型再投一次」。裁决器用的是证据表里的 status、weight 与 canonical ref，不调用模型；这也是它可测试、可复现的原因。

8.8.3 runaway：预算先于对话结束

python3 experiments/ch08/multi_agent.py --mode runaway --log /tmp/ch08-runaway.jsonl \
  | jq '{mode,answer,stop_reason,stopped_agent,error,messages,cycle,budget,breaker}'

{
  "mode": "runaway",
  "answer": null,
  "stop_reason": "budget_exhausted",
  "stopped_agent": "worker-a",
  "error": "worker-a: agent_envelope need=25 left=10",
  "messages": 11,
  "cycle": ["worker-a", "worker-b", "worker-a"],
  "budget": {
    "agents": {
      "supervisor": {"limit": 80, "remaining": 46, "used": 34},
      "worker-a": {"limit": 110, "remaining": 10, "used": 100},
      "worker-b": {"limit": 110, "remaining": 10, "used": 100}
    },
    "remaining": 66, "spent": 234, "total": 300
  },
  "breaker": {
    "failures": {},
    "state": "open",
    "trips": [{"agent": "worker-a", "failures": 0, "reason": "budget_exhausted"}]
  }
}

两个 worker 各发了 4 条 confirm，每条 25 token，各用掉 100；第 5 条需要 25，但个人额度只剩 10，try_spend 返回 false，发送被拒绝。全局还剩 66 token，但 worker-a 已经不能再花——这正是「父子预算」与「全局预算」必须同时检查的原因。只看全局，会以为系统还有钱；只看个人，会漏掉全局承诺。

停止后，detect_cycle 从 handoff 与 confirm 边检出 worker-a → worker-b → worker-a。注意检测发生在停止之后：在这个实现里，总线只负责预算拦截，环检测是离线分析；生产系统应该在每次 handoff 后增量跑，把环当作早期告警，而不是等预算耗尽才发现。

8.8.4 三种模式的对比

这张表说明什么：三种模式的 token 支出在同一量级（120 对 234），但失败形状完全不同。normal 与 groupthink 都「成功」结束，区别在答案是否被证据支持；runaway 没有答案，却留下了可诊断的环与额度记录。评估多智能体时，不能只看「是否返回」，还要看「返回是否被证据支持」与「失败是否可归因」。

8.8.5 测试：把不变量钉住

python3 -m unittest discover -s experiments/ch08 -v

test_child_envelopes_must_fit_parent ... ok
test_concurrent_spend_never_overspends ... ok
test_opens_after_threshold_and_blocks_work ... ok
test_duplicate_delivery_is_idempotent ... ok
test_seq_and_causation_link ... ok
test_cycle_detector_handles_self_loop ... ok
test_normal_budget_and_cycle ... ok
test_runaway_stops_on_budget_and_detects_cycle ... ok
test_groupthink_is_overridden_by_primary_evidence ... ok
test_majority_with_independent_sources ... ok
test_tie_is_resolved_by_evidence_weight ... ok

----------------------------------------------------------------------
Ran 11 tests in 0.001s

OK

十一个测试里，四个直接对应本章的边界：并发扣减不超卖、重复投递不重复执行、熔断打开后拒绝派活、runaway 在预算耗尽时停止并检出环。它们不证明策略「聪明」，只证明机制没有在实现里被绕过；策略质量要靠第 9 章的评估集。

8.8.6 三组可以自己改的对照

这三组对照都只改一个变量。同时改额度、提示与来源，得到的差异无法归因；这也是第 9 章评估设计的前置条件。

母本对应

这张表说明什么：本章对 OS 母本只做交叉引用，不重写管道、消息队列、信号量的原理；对多 agent 框架只做方法对照，不把 AutoGen 或 CAMEL 的 API 搬进来。真正新增的内容是 agent 层的契约：角色、消息、冲突、预算、观测。把它们写成宿主可检查的字段，比选哪个框架更重要。

本章陷阱

这张表说明什么：十二个陷阱里，只有第 1 条是「该不该做」，其余都是「做了但契约缺字段」。它们不会因为换一个更强的模型而消失；模型越强，群体幻觉与责任稀释越有说服力，因为错误看起来更合理。

本章出口检查

下一站：第 9 章《评估》 回答一个更冷的问题：多智能体带来的提升，究竟是真实收益，还是采样方差与评估口径的错觉。