第六部分 · 编排 · 第 43 章

多智能体系统

作者Changkun Ou

阅读时长约 16 分钟

如果另一个智能体能够并行完成工作、带来真正不同的能力，或者执行独立检查，那么它就有价值。仅仅多给出一个答案，并不足以证明它有用。每增加一个智能体，都会消耗更多词元、等待更多工具、交换更多状态，也会多出一个丢失权限或证据的环节。因此，应先建立单智能体基线，只有当新增智能体可衡量的边际价值超过协调成本时，才把它加入系统。

增加智能体不会凭空带来权限、真相或容错能力。对于能够拆分的工作，多智能体仍然可以扩大覆盖范围、缩短完成时间，但可靠性来自运行时契约：每项任务归谁所有，哪些证据可以接受，允许修改什么，以及工作延迟或结果不明时系统如何恢复。

图 43.1. 多智能体系统协调拐点示意图。起初，增加智能体能带来更多有效工作；如果任务无法清晰拆分，协调开销会以更快的速度增长。曲线仅为示意，不是实测数据。

使用另一个智能体的五种不同理由

“多智能体”涵盖了几种不同的机制，它们的收益和故障方式并不相同。应先选择机制，再决定智能体数量。

独立采样与聚合。 多个智能体在看不到彼此答案的情况下，分别解决同一个封闭式问题，再由投票、排序器或确定性验证器选出结果。如果输出容易比较，而且错误之间的相关性不高，这种方式可能有效，代价则是把额外算力花在重复工作上。

批评与裁决。 提案者先产出工件，批评者检查其中的具体主张，裁决者再逐项接受、驳回，或要求补充证据。价值来自独立检查和可以准确定位的证据，而不是达成共识。

分阶段流水线。 每个阶段都把带类型的输入转换为带类型的输出，例如先检索证据，再起草内容、核对引用，最后发布。如果处理顺序已经明确，流水线很合适。它的典型风险是错误级联：有问题的中间工件会成为下一阶段的前提。

任务图委派。 协调者把目标拆成相互依赖或彼此独立的任务，分配边界明确的角色，再合并经过验证的工件。对于可以横向展开的工作，这种方式可能缩短完成时间；它也可能漏掉任务、重复劳动，或在交接时丢失信息。

共享环境协作。 多个智能体共同读取和修改同一个代码仓库、应用或外部系统。这是最难处理的模式。系统必须明确所有权、检查版本并核对外部影响，否则即使每个智能体的局部决策都合理，它们之间仍会发生竞态。

OpenAI Agents SDK 还区分了两种相关接口：一种是管理者把专家当作工具调用，另一种是把控制权交给专家，由专家接手控制权 (OpenAI 2026)。这两种接口都不会替应用决定底层工作应该重复执行、组成流水线，还是共享环境。那仍然是应用本身的设计选择。

分布式系统带来的启示

拜占庭将军问题研究的是：当部分分布式参与者可能任意行事时，其余参与者如何达成一致。拜占庭容错协议会明确成员范围、通信方式、认证机制、时间假设和故障数量上限 (Lamport et al. 1982)。例如，在实用拜占庭容错（Practical Byzantine Fault Tolerance，PBFT）规定的模型中，只要副本总数满足 $N \ge 3f+1$ ，且拜占庭副本不超过 $f$ 个，系统就能让复制状态机达成一致 (Castro and Liskov 1999)。

这不是关于答案真伪的定理。如果所有模型都遵循投票协议，却给出同一个错误结论，那么协议只证明它们达成了一致，并未说明语义是否正确。该定理也不要求拜占庭故障在统计上彼此独立，故障参与者可以串通。共同原因之所以重要，是因为它可能让实际故障数量超过协议假定的上限，而不是因为定理中存在所谓的“故障多样性”。

并行数据处理是另一条有用的技术脉络。MapReduce 把分解、调度、中间数据、故障处理和归约纳入同一份运行时契约 (Dean and Ghemawat 2004)。用 LLM 工作者改变了任务的求解方式，却没有消除这些协调职责。两条技术脉络给出的实践结论相同：增加工作者之前，先明确工作及其不变量。

让任务图可以执行

可以把一次运行表示为有向无环图 $G = (V,E)$ 。其中， $G$ 是带版本的任务图， $V$ 是任务节点集合， $E$ 是有向依赖边集合。边 $(u,v) \in E$ 表示节点 $v$ 需要节点 $u$ 已被接受的结果。这个模型中的每个符号都指向持久化运行时状态，而不是对话中的口头约定。

每个节点都应记录范围明确的目标、前序节点 ID、不可变输入工件引用、已分配角色、输出结构、验证器、前置条件、后置条件、权限、资源键、预算、截止时间、重试策略和汇合策略。只有必要的前序节点均已被接受、输入仍是当前版本且前置条件成立时，节点才进入就绪状态。只有输出结构、验证器和后置条件全部通过时，节点才算成功。根任务只有在所有必要的汇点条件都通过后才算成功；工作者说“完成了”并不代表任务完成。

TaskNode {
  task_id, goal
  predecessor_ids
  input_artifact_refs
  assigned_role
  output_schema, verifier
  precondition, postcondition
  authority, resource_keys
  budget, deadline
  retry_policy, join_policy
}

图 43.2 展示了一个小型任务图。调研和数据检查互不依赖，因此可以并行执行；起草必须等待两者完成；发布则要等待独立验证结果。

图 43.2. 任务图能够显式呈现真正可并行的工作和结果接受边界。调研与数据检查可以同时进行；起草阶段汇合两者已经接受的工件；验证通过后才能发布。

协调者应交换带类型的结构化消息，而不是把一个智能体的文本直接粘贴到另一个智能体的指令通道中：

AgentMessage {
  message_id, run_id
  task_id, parent_task_id
  sender, recipient, kind
  schema_version, causal_parent
  artifact_refs, evidence_refs
  authority_ref, deadline
  remaining_budget
  idempotency_key, body
}

TaskResult {
  task_id, attempt_id
  status, output_ref
  evidence_ref, effects
  unresolved, cost
  next_state_version
}

AgentMessage 保留身份、因果关系、来源和去重信息，其中的 body 是另一个工作负载提供的数据。TaskResult 区分 succeeded、failed、timed_out、cancelled、outcome_unknown 和 needs_reconciliation。摘要可以随工件一起传递，但不能取代验证工件所需的证据、版本或工具回执。

协调不变量

只有运行时真正执行以下约束，任务图才有意义。

有界委派。 子任务的权限必须同时受父任务权限、用户权限和策略约束。创建子任务之前，先从父任务的剩余预算中预留成本、调用次数、时间和并发额度；子任务终止后，再核销并返还未使用的部分。
单一所有权。 每项可变资源只设一个写入者。如果任务可能重试或重新分配，发布时必须检查版本，并使用单调递增的围栏令牌，防止过期尝试提交结果。
以类型约束信任。 消息是不可信数据，不是权限。子任务可以报告证据或提出操作建议，但不能扩大自己的任务范围、增加接收方，也不能把引用内容变成用户指令。
经过验证的完成。 释放下游任务之前，必须验证模式、工件版本、证据、前置条件和后置条件。裁决者可以同时否决两个候选结果，也可以要求更多证据。
根据外部影响决定是否重试。 读取操作和幂等操作可以按策略重试。外部修改遇到结果不明的超时后，绝不能盲目重试；应检查回执或当前状态，无法确认外部影响时进入 needs_reconciliation。
真正的取消。 确认取消只表示取消请求已被记录；静止状态则表示所有后代任务、租约、数据流和工具调用都已停止。系统必须分别跟踪两者，撤销委派凭证，并统计取消后仍然发生的外部影响。

共享文件和屏幕也需要同样的约束。工作树能减少文件冲突，但它不是事务，也不是租户边界。并发编辑者应以同一个基础版本提交补丁，再由指定合并者处理。多个智能体操作同一图形界面时，不能共享键盘焦点或坐标；所有界面操作都应由第 42 章所述的环境所有者串行执行。

聚合是一种有条件的估计

投票存在一个形式清楚的特殊情况。假设 $N$ 为奇数，每位投票者都返回一个二元答案，每个答案都以相同概率 $\epsilon$ 出错，而且错误彼此独立。令 $m=\lfloor N/2\rfloor+1$ 表示多数票门槛， $j$ 表示错误票数。在这个独立伯努利特殊情况中，多数票出错的概率为

\begin{gathered} \Pr[\text{majority is wrong}] = \sum_{j=m}^{N} {N \choose j} \\ {}\times \epsilon^j \\ {}\times (1-\epsilon)^{N-j}. \end{gathered}

系统调用了 $N$ 次模型，并不意味着这条公式自然适用。不同错误率、弃权、平票、智能体之间的通信、共享提示和相关错误，都需要另一种联合模型。只知道两两相关性，也无法确定二项分布的尾部概率。

应在留出样本上测量多样性。对于智能体 $i$ 和 $j$ ，记录两两联合错误率 $q_{ij}=\Pr(E_i=1,E_j=1)$ ，其中 $E_i=1$ 表示智能体 $i$ 出错。在控制任务难度这一共同因素的同时，报告两两分歧和相关性及其置信区间。Kim 等人考察了大量语言模型，包括来自不同供应商的模型，发现它们之间仍有显著的相关错误 (Kim et al. 2025)。这说明多样性需要测量，而不能因为换了供应商、角色提示或温度就假定它已经存在。

一致不等于证明。只有根据已知验证器或带标签的结果完成校准后，一致性才是有用证据。投票适合答案空间受约束的问题，却不适合代替对开放式补丁、报告或外部操作的检查。

批评需要证据和裁决

批评机制改变了接受结果的规则。系统不再询问哪个答案的支持者最多，而是检查批评者能否给出具体证据，例如失败的测试、反例、被违反的不变量、易受攻击的输入、相互矛盾的来源或缺失的引用。每项反对意见都要指明它针对的主张和工件版本。未解决的反对意见会一直保留，直到证据将其解决；工件发生变化后，反对意见也可能被标记为 duplicate、rejected、superseded 或 stale。

裁决者本身也是一个故障点，不是全知的判断者。它必须能够同时否决提案和批评。评估时应测量裁决错误、错误质疑、遗漏缺陷、修复成功率，以及采纳修复后引入的回归。批评者争论了很多轮，只能说明它坚持得久，不能说明问题更严重或批评一定正确。

AI 安全领域的辩论研究关注的是：较弱的裁决者能否通过对抗性交锋识别出更好的答案 (Irving et al. 2018)。双重高效辩论在特定模拟博弈、算力边界和策略假设下给出了形式化结果 (Brown-Cohen et al. 2023)。这些工作支持采用有界争议，却并不证明普通的 LLM 批评者能发现每一个缺陷，也不证明 LLM 裁决者一定能识别缺陷。实证研究中，多智能体辩论改善过部分基准 (Du et al. 2024)；但在算力匹配的研究中，相比自洽性方法，其收益取决于具体条件，并不存在普遍优势 (Yang et al. 2025)。

安全性、活性与语义质量

分布式系统对两个术语的使用，比智能体讨论通常更精确。安全性属性表示坏事不会发生，例如，没有任务能在当前权限失效时提交，也不会出现两个相互冲突的已接受结果。活性属性表示好事最终会发生，但必须以明确的假设为前提，例如，每个就绪任务最终都会完成，或进入某个终止失败状态 (Alpern and Schneider 1985)。

错误答案不一定构成安全性违规。只有当系统定义并执行了答案所违反的不变量时，它才属于安全性违规。应区分以下四种结果：

超时、依赖未完成或工作者不可用属于进度失败，也是可观察的活性症状。
被验证器拒绝的答案属于检测到的语义失败。
错误答案被验证器接受，属于未检测到的语义失败。
未获授权、相互冲突或来自过期尝试的提交，属于协议或策略层面的安全性违规。

采用这套词汇后，恢复方式也随之不同。进度失败可以重试、重新分配或升级处理，但也可能留下结果不明的外部影响。检测到的错误答案可以修复。系统无法主动阻止尚未检测到的错误答案，补救方式是采用更好的独立验证器和发布评估。

并行执行有一条关键路径

总成本等于每个节点完成的工作加上协调开销。这里， $C_v$ 表示节点 $v \in V$ 的模型、工具、沙箱和重试成本， $C_{\text{coord}}$ 表示调度、消息传递、合并与验证的成本：

C_{\text{total}} = C_{\text{coord}} + \sum_{v \in V} C_v.

如果按照实际经过时间计算路径长度，那么运行延迟的下界由最长依赖路径决定。这里， $\ell_v$ 表示节点 $v$ 的实际持续时间， $\mathcal{P}(G)$ 表示图 $G$ 中的所有依赖路径， $\ell_{\text{coord}}(P)$ 表示路径 $P$ 上的协调延迟：

L(G) \ge \max_{P \in \mathcal{P}(G)} \left( \begin{gathered} \sum_{v \in P}\ell_v \\ {}+ \ell_{\text{coord}}(P) \end{gathered} \right).

其中， $L(G)$ 是整次运行的延迟。换句话说，运行不可能比最慢的必要路径更早结束，该路径上的节点耗时和协调延迟必须全部计入。并发限制、供应商速率限制、共享资源或耗尽的预算，都可能进一步抬高实际延迟。增加工作者无法缩短串行依赖；即使挂钟时间下降，总计算量通常也会上升。

Anthropic 报告称，由 Opus 4 主智能体协调 Sonnet 4 工作者后，其内部研究评估提高了 90.2%，而多智能体系统消耗的词元约为普通对话的十五倍 (Anthropic 2025)。这项结果同时混入了任务集、额外算力、模型组合和系统架构等因素，而且“普通对话”也不是与单智能体等算力的基线。因此，这项结果可以说明横向展开的研究任务可能受益于委派，却不能视为普遍的扩展定律。

权限必须在每次委派时收紧

应把每个智能体视为一个工作负载身份：它代表某个用户，在一个租户、会话、任务和委派范围内行动。每次委派都要遵循最小权限。子任务获得的短期凭证，只能用于指定的受众、资源、操作、数据类别、工具、截止时间、预算和委派深度。绝不能转发父任务可重复使用的持有者凭证。进行传递式委派和扇出时，必须以原子方式预留权限和预算，防止多个同级任务各自花掉同一份剩余额度。

这些约束可以避免系统成为困惑代理。页面、工具结果、检索文档或子任务消息中的提示注入可以提出新操作，却不能授权操作。多数票不是授权：多个模型批准并不等于多个独立的安全主体。系统应先执行用户权限和策略，只把智能体检查作为附加证据。如果策略要求人工批准，就应在外部影响发生时获取一份新鲜且与具体载荷绑定的批准（第 56 章；第 55 章）。

上下文分离有用，但它不等于隔离。不同租户需要各自独立的存储命名空间、缓存、日志、工件、凭证和网络策略。每次委派前都应尽量减少披露内容，并保存所发上下文的来源。即使子任务被攻陷，它也不应读取同级任务的状态、创建更深层的委派，或利用过期租约提交结果。

A2A 提供互操作性，不提供信任。当前规范定义了智能体卡、消息、任务状态、工件、取消、协议绑定和认证扩展点 (A2A Protocol Working Group 2026)。服务器仍要自行实现授权、租户范围、幂等性、共享状态一致性和语义输出验证。取消是一项尝试，不是保证。智能体卡是一项能力声明，不是证明远端智能体安全，也不能证明它已获得用户任务的授权。

恢复也是协调的一部分

应把图版本、任务状态变化、各次尝试、租约、消息 ID、工件引用、预算、截止时间和外部影响回执写入第 41 章所述的持久日志。协调者重启后，根据日志重建任务图，让过期租约失效，并且只重试影响语义允许重试的工作。

有用的故障注入包括：

子任务过慢、模型不可用、预算耗尽，或在汇合期间超过截止时间；
输出格式错误、证据缺失、工件过期，或验证器失败；
消息重复或乱序，以及工作者在租约过期后发布结果；
子任务在外部影响发生前崩溃，以及在外部影响发生之后、结果记录之前崩溃；
父任务崩溃后子任务继续运行，或提交期间发生取消；
编辑冲突、子任务被攻陷、提示注入，或尝试跨租户访问。

每一种情况都应明确规定任务会被重试、拒绝、取消、核对，还是升级处理。不要把 outcome_unknown 归入 failed，否则会丢失防止重复外部影响所必需的信息。

评估机制，而不是标签

比较多智能体设计与单智能体基线时，应使用匹配的模型、预算、工具、任务集、验证器、挂钟时间限额和运行框架。还应加入彼此不通信的独立样本，从而单独测量通信本身的影响。对于辩论或委派，要分别消融角色提示、并行执行、模型异质性、摘要和裁决者。

报告端到端任务成功率及其自助法置信区间，也要报告关键路径延迟、总词元、工具调用次数、API 支出和每美元成功率。随后直接报告协调机制的指标：协调开销、重复工作率、重复话题率、任务遗漏率、交接信息损失、消息量、重试次数、过期结果率、重复外部影响率、取消确认延迟、进入静止状态的延迟，以及取消后的外部影响次数。

聚合评估应区分正确、错误、平票、弃权和未收敛结果，并报告两两联合错误率及初始结果到最终结果的转移矩阵。批评机制需要同时使用植入缺陷和无缺陷的工件，测量缺陷召回率、精确率、错误质疑率、裁决错误、修复成功率和回归率。委派结果应按任务可拆分程度分组，同时报告综合错误和关键路径利用率。安全评估则要测量错误操作、错误阻断、绕过批准、权限违规、数据泄露和对子任务被攻陷后的遏制能力。

发布结果时，应同时公布拓扑、任务图、提示、模型快照、工具和运行框架版本、并发上限、重试规则，以及输入、输出和缓存词元的总量。如果不提供这些控制条件，一个百分比增益无法说明收益究竟来自协调、额外算力、更强的工作者，还是不同的裁决者。

争议所在

真正有争议的问题，不是多次调用能否胜过一次廉价调用，它们往往可以。问题在于：针对预期工作负载，哪一种协调机制能胜过最强的、算力匹配的单智能体策略。辩论的结果会随任务难度、模型能力、裁决质量和安全场景而变化 (Yang et al. 2025)。不同模型仍可能犯同样的错误 (Kim et al. 2025)。因此，异质性、批评和投票都应视为需要测量的假设，而不是配置之后自然获得的可靠性属性。

下层约束

这一层下面的运行框架负责持久状态、租约、预算、取消、工具策略和外部影响核对（第 41 章）。多智能体任务图可以约束这些机制，却不能取代它们。如果运行框架无法识别一次具体的任务尝试、阻止过期写入者，或停止所有后代任务，那么增加协调者只会把原有的不确定性分散到更多地方。

一条用于生产的选择规则

如果工作成本低、耦合紧密、按顺序执行，或主要受一个共享可变状态约束，就保留一个智能体。答案空间受约束，而且经过校准的聚合能改善错误成本曲线时，再采用独立采样。主张能够由具体证据检验，且错误质疑可以测量时，再加入批评者。阶段边界和输入输出约定稳定时，采用流水线。独立分支主导关键路径时，采用任务图委派。只有在所有权和合并语义明确时，才让多个智能体共享环境。

发布前，应核对以下五项：

每个节点都有目标、所有者、输入、输出结构、验证器、权限、预算、截止时间和终止条件。
每条消息都携带身份、因果关系、工件版本、证据和幂等键，同时不会变成指令权限的来源。
每项可变资源都有单一写入者、版本检查或围栏令牌；每项外部影响都有对应的重试与核对语义。
取消会传播到后代任务，凭证撤销后不能再开始新工作，而且运行时会分别测量取消确认和进入静止状态的时间。
完整系统在用户价值上优于匹配基线，同时不突破固定的成本、延迟、错误阻断或安全上限。

许多委派任务本质上是在查找证据：一个工作者检索文档，另一个搜索私有语料，裁决者再检查来源是否支持某项主张。协调无法修复缺失、陈旧或被污染的证据。因此，第 44 章将继续讨论检索漏斗本身，从索引和召回，到重排、来源追踪以及针对语料库的攻击。