Agent 工程体系 · 第 65/98 篇。内容以 2026 年 9 月可验证的公开规范和稳定接口为基线；框架版本敏感能力会明确标注，不把实验行为写成通用保证。

多 Agent 辩论与 Critic：独立证据、聚合、成本和伪共识

多 Agent 系统经常被描述成“让多个 Agent 互相讨论，再由一个 Agent 总结”。这个描述容易让人误以为：只要增加参与者数量，答案就会更准确。

实际情况更复杂：

多个 Agent 可能只是同一个模型、同一份上下文、同一套检索结果的重复采样；
辩论可能暴露错误，也可能让错误观点变得更加自洽；
Critic 可能发现问题，也可能只是复述自己的偏好；
多数投票只有在一定独立性条件下才有统计意义；
更多调用通常意味着更高的 token 成本、更长的延迟和更多的故障路径；
“五个 Agent 都同意”不等于“结论有五份独立证据”。

因此，多 Agent 辩论与 Critic 的核心不是“增加发言者”，而是设计一套独立产生证据、结构化表达争议、按证据质量聚合、在有限成本内停止的可靠执行机制。

Anthropic 将 Agentic 系统区分为固定代码路径编排的 Workflow，以及由模型动态决定过程和工具使用的 Agent；同时建议只在简单方案不足以满足任务要求时增加复杂度，因为 Agent 系统通常以更高成本和延迟换取更强的任务处理能力。(anthropic.com) OpenAI 的 Agents SDK 文档也将 Agent 描述为能够规划、调用工具、协作使用专长并维护状态的应用，并把编排、状态、Guardrail、审批和追踪视为运行时的一部分。(developers.openai.com)

本文讨论的“辩论”不是开放式聊天，而是一种受约束的可靠性协议。

一、先区分几个容易混淆的概念

1. 多 Agent

多 Agent是指同一个任务由两个或更多具有相对独立职责、上下文或执行路径的 Agent 参与完成。

这里的“Agent”不一定意味着完全自治。一个 Agent 可以只是：

一个带有专门系统提示词的模型调用；
一个拥有不同工具权限的执行单元；
一个通过固定代码路径运行的专家角色；
一个能自主规划并调用工具的循环执行器。

因此，下面几种结构都可能被称为多 Agent：

用户
 ├── 研究 Agent
 ├── 安全审查 Agent
 └── 汇总 Agent

或者：

用户
  │
  ▼
协调 Agent
  ├── 动态拆分任务
  ├── 调用多个 Worker Agent
  └── 汇总结果

Anthropic 将“并行化”分为两类：一类是把任务拆成互相独立的子任务，另一类是对同一任务进行多次尝试并投票；而“Orchestrator-Workers”则由中心模型根据具体输入动态决定子任务。(anthropic.com)

但“多个调用”并不自动构成有价值的多 Agent 系统。若所有调用都满足：

相同模型
+ 相同系统提示
+ 相同用户输入
+ 相同检索文档
+ 相同工具结果
+ 相同错误假设

那么它们更接近于同一个推理过程的重复采样，而不是独立专家。

2. 辩论

多 Agent 辩论是指多个 Agent 针对同一个命题或候选方案，分别提出主张、证据和反驳，再由聚合器或裁决器决定输出。

辩论至少包含四种对象：

命题：需要判断真假的陈述；
主张：某个 Agent 对命题的判断；
证据：支撑或反驳主张的可检查材料；
裁决：根据规则和证据形成的最终状态。

例如，不应只要求 Agent 返回：

{
  "answer": "应该迁移到数据库 B"
}

而应要求返回：

{
  "claim": "应该迁移到数据库 B",
  "position": "支持",
  "confidence": 0.72,
  "evidence": [
    {
      "type": "benchmark",
      "content": "在 100 万行写入测试中，P95 延迟降低 18%",
      "source": "benchmark-run-2026-08-31",
      "independence_key": "execution:benchmark-v3"
    }
  ],
  "assumptions": [
    "写入模式与测试数据相似",
    "迁移期间允许双写"
  ],
  "counterarguments": [
    "团队对数据库 B 的运维经验较少"
  ],
  "abstain_if": [
    "没有双写一致性验证结果"
  ]
}

如果没有证据和假设，所谓“辩论”通常只是多个自然语言意见的排列。

3. Critic

Critic是针对某个候选输出、计划、代码变更或中间结论，寻找缺陷、遗漏、矛盾、不可验证假设和风险的评审组件。

Critic 的职责是：

输入候选结果
    +
输入评价标准
    +
输入可用证据
    ↓
输出问题、反例、缺失证据和修改建议

Critic 不一定直接给出最终答案。

例如，候选回答是：

“该接口可以安全地重试，因为请求是幂等的。”

Critic 不应只返回：

“我同意。”

而应检查：

幂等性由什么保证；
是否存在服务端已提交、客户端超时的情况；
重试键是否稳定；
请求是否包含时间戳或随机字段；
下游副作用是否也幂等；
是否有可执行测试或协议文档作为证据。

一个合格的 Critic 输出可以是：

{
  "verdict": "需要修改",
  "issues": [
    {
      "severity": "high",
      "type": "unsupported_assumption",
      "statement": "接口天然幂等",
      "reason": "未提供幂等键或服务端去重机制证据",
      "required_evidence": "接口协议或重试测试结果"
    }
  ],
  "blocking": true
}

Critic 的“发现问题能力”和“最终判定能力”是两个不同能力。让 Critic 直接输出唯一真相，会把“评审”与“裁决”混在一起。

4. 聚合

聚合是把多个 Agent 的主张、证据、置信度、冲突和验证结果转换为一个最终状态的过程。

聚合不是简单拼接，也不必然是多数投票。它可以输出：

接受某个候选；
拒绝所有候选；
请求补充证据；
进入第二轮评审；
升级人工；
暂停执行；
允许低风险继续，但禁止高风险动作。

可靠系统的聚合器应该支持“不确定”和“无法裁决”，而不是强迫所有输入变成一个答案。

二、多数投票为什么有时有效

多 Agent 投票的直觉来自一个简单模型。

设每个 Agent 独立判断一个二元问题：

单个 Agent 判断正确的概率为 $p$ ；
一共有 $n$ 个 Agent；
使用多数票；
$p > 0.5$ ；
各 Agent 的错误相互独立。

当 $n$ 为奇数时，多数票正确的概率为：

P_{\text{majority}} = \sum_{k=(n+1)/2}^{n} \binom{n}{k}p^k(1-p)^{n-k}

其中：

$k$ 表示判断正确的 Agent 数量；
$\binom{n}{k}$ 表示从 $n$ 个 Agent 中选出 $k$ 个的组合数；
$p^k$ 表示这 $k$ 个 Agent 正确；
$(1-p)^{n-k}$ 表示其余 Agent 错误。

假设 5 个 Agent 的独立正确率都是 $0.7$ ，多数票正确概率为：

\begin{aligned} P_{\text{majority}} &= \binom{5}{3}0.7^3 0.3^2 + \binom{5}{4}0.7^4 0.3 + 0.7^5 \\ &= 0.3087+0.36015+0.16807 \\ &= 0.83692 \end{aligned}

在这个理想模型中，单个 Agent 的正确率从 70% 提高到了约 83.7%。

问题在于，真实 Agent 往往不满足独立性。

三、“独立证据”比“不同角色”更重要

1. 角色不同不等于证据独立

下面这三个 Agent 具有不同角色：

架构师 Agent：评估系统设计
安全 Agent：评估安全风险
成本 Agent：评估成本

但如果它们都使用同一份错误的检索文档：

文档：错误地声称数据库 B 支持事务隔离级别 X

那么角色差异无法消除共同错误。

它们可能分别生成：

“从架构角度看可行”；
“从安全角度看没有明显问题”；
“从成本角度看迁移值得”。

表面上是三个独立结论，实际上三者都依赖同一个错误前提。

2. 证据独立需要拆成多个维度

工程上可以把证据的独立性近似拆成以下维度：

维度	例子	主要风险
数据源	官方文档、运行日志、代码、人工记录	同源错误
检索路径	不同关键词、不同索引、不同查询策略	查询偏差
模型	不同模型或不同提供方	共享训练偏差
提示词	不同审查标准和反例要求	指令同质化
上下文	是否看到其他 Agent 的输出	观点传染
执行环境	不同沙箱、不同测试数据	环境共同缺陷
时间	不同时间重新获取动态事实	过期信息
验证方式	语言判断、静态分析、运行测试	评审模式单一

这些维度并不需要全部变化。关键是识别当前任务最可能出现的共同失败原因，然后针对该原因建立独立路径。

例如：

事实核查最怕同一过时文档，因此应分离检索源和时间；
代码审查最怕共同漏看某种漏洞，因此应分离审查视角，并加入静态扫描和测试；
规划任务最怕所有 Agent 默认同一业务前提，因此应让至少一个 Agent 专门寻找需求歧义和反例；
数据库迁移最怕测试环境与生产环境不一致，因此增加真实数据抽样或影子流量验证，而不是继续增加语言模型数量。

3. 用相关性修正“投票收益”

可以用一个简化模型表达 Agent 错误之间的相关性。

设：

单个 Agent 错误率为 $e = 1-p$ ；
$q$ 表示发生共同模式错误的概率；
在共同模式错误发生时，所有 Agent 都受到同一个错误前提影响；
在其余 $1-q$ 的情况下，Agent 错误近似独立。

那么 5 个 Agent、单体正确率 $p=0.7$ 时：

P(\text{正确}) \approx (1-q)\times 0.83692 + q\times 0

当 $q=0.2$ 时：

P(\text{正确}) \approx 0.8\times 0.83692 = 0.669536

也就是说，加入五个 Agent 后，整体正确率可能只有约 67%，甚至低于单个 Agent 的 70%。

这个模型并不声称真实系统一定遵循这个精确公式，它的用途是说明一个因果关系：

只要共同模式错误足够多，增加 Agent 数量就会把同一个错误重复确认，而不是降低错误概率。

四、辩论的两种模式：先独立，后交叉

1. 同步独立提案

第一轮中，每个 Agent 只看到原始任务和自己的约束，不看到其他 Agent 的回答：

原始任务
  ├── Agent A：独立分析
  ├── Agent B：独立分析
  ├── Agent C：独立分析
  └── Agent D：寻找反例

这一轮的目标不是让 Agent 互相说服，而是获得尽可能不同的候选解释。

输出应当包含：

结论；
证据；
假设；
不确定性；
可能推翻结论的条件；
建议的验证动作。

这一阶段保留独立性，因此适合发现：

不同问题分解；
不同风险；
少数但关键的反例；
需求中的隐藏歧义。

2. 交叉批评

第二轮可以让 Critic 看到候选结果，但不应让它只做“哪个回答更像正确答案”的主观比较。

更好的输入形式是：

任务：
候选主张：
支持证据：
反对证据：
评价标准：
禁止接受的假设：
必须执行的验证：

Critic 应针对具体主张提出可检查的问题：

主张 P
  ├── 证据是否真的支持 P？
  ├── 是否混淆相关性与因果性？
  ├── 是否遗漏反例？
  ├── 证据是否重复计数？
  ├── 是否依赖未声明假设？
  └── 能否通过工具或规则验证？

这里的关键是：交叉批评会牺牲一部分独立性，换取更强的错误暴露能力。因此通常不应无限进行。

3. 聚合与裁决

在候选和 Critic 结果都产生后，由一个独立的聚合器进行裁决：

flowchart TD
    U[原始任务] --> A[独立分析 Agent]
    U --> B[独立分析 Agent]
    U --> C[反例 Agent]
    U --> D[证据检索 Agent]

    A --> N[证据规范化]
    B --> N
    C --> N
    D --> N

    N --> K[主张与证据图]
    K --> CR[Critic]
    CR --> V[规则/工具验证]
    V --> AD[聚合与裁决器]

    AD -->|证据充分| ACCEPT[接受]
    AD -->|发现阻断问题| REJECT[拒绝或返工]
    AD -->|证据不足| ESC[补充证据/升级人工]
    AD -->|超出边界| STOP[停止执行]

关键路径不是：

Agent A 说什么
Agent B 说什么
Agent C 说什么

而是：

哪些主张相互独立？
哪些证据真的支撑主张？
哪些问题已经被验证？
哪些冲突仍然存在？

OpenAI 的 Agent 编排文档将多 Agent 系统中的专业分工、交接、工具调用、状态和审批视为运行时设计问题，而不是单纯的提示词组合。(developers.openai.com)

五、证据不能只保存为自然语言段落

1. 从答案转向主张图

多个 Agent 的长文本难以比较，也容易重复计数。更适合的中间表示是“主张—证据图”。

Claim C1: 该迁移方案可在无停机条件下完成
 ├── Evidence E1: 双写测试成功
 ├── Evidence E2: 回放测试成功
 ├── Assumption A1: 生产流量峰值不超过测试峰值
 └── Counterexample X1: 回滚期间存在重复写入

Claim C2: 回滚不会造成数据丢失
 ├── Evidence E3: 事务日志可完整重放
 └── Missing M1: 尚未测试跨版本 schema 差异

图中的边必须标记关系：

supports：证据支持主张；
contradicts：证据反驳主张；
depends_on：主张依赖某个假设；
duplicates：两个证据来自同一底层来源；
verified_by：主张被可执行验证确认；
invalidated_by：主张被测试或规则推翻。

这样可以避免把以下三段文本误认为三份证据：

Agent A：官方文档说明支持该功能
Agent B：根据官方说明可以使用该功能
Agent C：该功能在文档中已经得到确认

它们可能只是同一个文档事实的三种复述。

2. 证据去重

每条证据应有一个稳定的来源标识，例如：

{
  "evidence_id": "doc:database-b:v4:transaction-isolation",
  "source_type": "official_documentation",
  "source_locator": "database-b/docs/isolation",
  "observed_at": "2026-08-31T10:00:00+08:00",
  "supports": ["claim:C1"],
  "independence_key": "source:database-b-official-doc"
}

independence_key 不等于 evidence_id。

例如：

E1：Agent A 引用官方文档第 3 节
E2：Agent B 引用官方文档第 3 节
E3：Agent C 根据 E1 改写结论

这三者的 independence_key 都应指向同一个底层来源。聚合器不能把它们算成三票。

六、聚合不能只看投票数量

1. 朴素多数投票的三个缺陷

缺陷一：不区分证据质量

一个有运行测试支持的“支持”与一个没有证据的“支持”，不应具有相同权重。

缺陷二：不区分主张重要性

对于代码变更：

“变量命名不一致”可以是低严重性问题；
“存在未授权写操作”可能是阻断问题。

不能让十个低严重性意见抵消一个已经验证的高严重性风险。

缺陷三：不处理未决状态

当三个 Agent 支持、两个 Agent 反对时，系统可能输出“支持”。但如果反对意见指出一个尚未验证的灾难性故障路径，正确状态应是：

无法接受，等待阻断问题验证

2. 一个可解释的评分模型

可以给每个主张定义支持分和反对分：

S(C) = \sum_{e \in E^+(C)} w_{\text{quality}}(e) \cdot w_{\text{independence}}(e) \cdot w_{\text{verification}}(e) - \sum_{e \in E^-(C)} w_{\text{quality}}(e) \cdot w_{\text{independence}}(e) \cdot w_{\text{verification}}(e)

其中：

$E^+(C)$ 是支持主张 $C$ 的证据集合；
$E^-(C)$ 是反对主张 $C$ 的证据集合；
$w_{\text{quality}}$ 表示证据质量；
$w_{\text{independence}}$ 表示证据相对于其他证据的独立程度；
$w_{\text{verification}}$ 表示证据是否经过可执行验证。

例如，可按以下原则赋值：

运行测试通过             verification = 1.0
静态规则检查通过           verification = 0.8
官方文档直接支持           verification = 0.7
Agent 的解释性判断         verification = 0.3
未提供来源的主观置信度     verification = 0.1

这些不是通用规范值，而是一个可调的工程模型。真正的权重应通过离线评测校准，而不是凭直觉固定。

3. 阻断问题应具有优先级

最终状态不应只由总分决定。可以定义阻断条件：

若存在 severity = critical 且状态 = 未解决：
    结果 = blocked

否则若通过规则验证且支持分超过阈值：
    结果 = accepted

否则若存在冲突且证据不足：
    结果 = needs_evidence

否则：
    结果 = abstain

例如：

{
  "claim": "可以自动删除旧数据",
  "support_score": 8.4,
  "critical_issues": [
    {
      "type": "irreversible_side_effect",
      "status": "unverified"
    }
  ],
  "decision": "blocked"
}

即使支持分很高，只要涉及不可逆副作用且没有审批或恢复证明，也不应自动执行。

七、Critic 的真正目标：发现可验证的问题

1. Critic 不应评审“感觉”

低质量 Critic 的常见输出是：

“整体看起来不错”；
“建议进一步完善”；
“逻辑基本合理”；
“可以考虑更多边界情况”。

这些话没有定义：

哪个主张有问题；
问题为什么成立；
什么证据可以确认；
修复后如何判断问题消失。

高质量 Critic 应把自然语言意见转换为问题记录：

{
  "issue_id": "I-17",
  "target": "retry_policy",
  "type": "missing_idempotency_boundary",
  "severity": "high",
  "observation": "客户端超时后会重试写请求",
  "reasoning": "服务端可能已经提交成功，但响应未到达客户端",
  "required_check": "使用相同 idempotency_key 重放两次并验证副作用次数",
  "pass_condition": "副作用最多产生一次",
  "fail_condition": "重复创建或重复扣款"
}

这个结构使 Critic 的输出可以进入后续验证，而不是停留在评论区。

2. Critic 应该专门寻找“推理跳跃”

常见的推理跳跃包括：

从相关性跳到因果性

版本升级后错误率下降
因此错误率下降是升级导致的

中间缺少：

其他变量是否同时变化；
是否存在流量结构变化；
是否有对照组；
是否只是均值回归。

从局部测试跳到全局安全

三个测试用例通过
因此代码没有安全问题

测试只能证明覆盖到的行为，不会自动证明未覆盖路径安全。

从工具成功跳到任务成功

API 返回 200
因此业务操作成功

还需要确认：

返回体中的业务状态；
异步任务是否完成；
下游是否最终一致；
是否产生重复副作用。

从多数同意跳到事实成立

四个 Agent 都认为配置正确
因此配置正确

如果四个 Agent 都读取了相同的错误配置，投票只是在测量共识，不是在验证事实。

3. Critic 和 Verifier 不是同一个东西

可以按输出性质区分：

组件	主要问题	输出
Critic	“哪里可能有问题？”	缺陷、反例、缺失证据
Verifier	“这个条件是否成立？”	通过、失败、不可执行
规则检查器	“是否违反明确规则？”	规则命中或未命中
Judge	“候选结果是否达到标准？”	分数、等级、裁决
人工评审	“是否符合业务和责任边界？”	批准、拒绝、修改意见

例如：

Critic：重试可能造成重复扣款
Verifier：在相同请求键下执行两次，副作用次数为 2
规则检查器：支付写操作必须携带幂等键——失败
Judge：候选方案不满足安全门槛
人工评审：禁止自动上线

Critic 提出风险，Verifier 提供事实，规则检查器确认硬约束，Judge 根据 Rubric 评估，人工负责无法编码的责任和业务判断。

八、完整算例：审查一个数据库迁移方案

假设任务是：

将订单库从数据库 A 迁移到数据库 B，要求业务尽量不停机，迁移失败时可以回滚。

1. 第一轮独立分析

四个 Agent 分别运行：

A：设计迁移流程
B：寻找数据一致性风险
C：评估回滚路径
D：专门寻找“无法满足不停机”的反例

得到以下主张：

C1：可以通过双写实现不停机迁移
C2：双写期间需要处理部分成功和重复写入
C3：回滚不等于恢复到迁移前状态
C4：如果旧库和新库 schema 不兼容，则双写方案不能直接成立

注意，C1 是正向方案，C2～C4 是约束和反例。它们不能简单作为互相竞争的“答案”，而应进入同一个主张图。

2. Critic 发现缺失条件

Critic 审查 C1：

C1：可以通过双写实现不停机迁移

发现三个问题：

未说明双写失败时的补偿机制；
未说明读流量何时切换；
未证明新旧库之间的顺序一致性。

Critic 不应直接把 C1 改成“错误”，因为双写可能仍是可行方案。更准确的结论是：

C1：条件成立，但当前证据不足

3. Verifier 执行测试

系统启动可执行验证：

测试 T1：同一订单写入两个库，检查最终字段一致
测试 T2：只让新库写入失败，检查补偿队列
测试 T3：客户端重试同一写请求，检查是否重复创建
测试 T4：切换读流量后，检查旧库延迟写入是否污染新库

假设结果为：

T1：通过
T2：失败，补偿队列未配置告警
T3：通过
T4：失败，旧库延迟事件会覆盖新库字段

此时即使多数 Agent 支持双写，聚合器仍应输出：

decision = blocked
reasons = [
  "补偿失败没有可观测性",
  "延迟事件可能导致新库数据回退"
]

这就是“证据优先于共识”。

九、伪共识是如何产生的

1. 上下文污染

错误流程：

Agent A 先回答
Agent B 读取 A 的回答并评论
Agent C 读取 A、B 的回答并总结
Judge 读取全部文本并投票

后续 Agent 并没有独立作答，而是在同一个叙事框架中继续推理。

如果 A 的第一句话是：

“问题的根因显然是缓存失效。”

那么 B 可能围绕缓存解释异常，C 又根据 A、B 的共同方向继续补充。最终形成的不是独立验证，而是先入为主的逐层合理化。

更可靠的流程是：

第一轮：所有 Agent 隔离
第二轮：只暴露结构化主张和证据
第三轮：针对冲突执行验证

2. 提示词同质化

下面三个提示词看起来不同：

你是一名架构师，请分析方案。
你是一名安全专家，请分析方案。
你是一名运维专家，请分析方案。

但如果它们都要求：

请给出全面、合理、可执行的建议，并保持积极和建设性。

且都看到同一份背景材料，那么它们可能共享：

相同的默认前提；
相同的输出结构；
相同的风险容忍度；
相同的语言模型偏差。

真正的独立性应体现在任务约束上，例如：

安全 Agent：
只能寻找导致拒绝或暂停的风险，不得为了完整性提出正向建议。

反例 Agent：
必须构造至少三个使候选方案失败的输入或环境条件。

Verifier：
不得根据自然语言解释判定通过，只能依据工具结果或明确规则。

证据 Agent：
每个事实必须附来源标识，无法提供来源时必须标记 unknown。

不同角色的价值来自不同的错误搜索空间，而不仅是名字不同。

3. 置信度的一致性错觉

语言模型的 confidence: 0.9 通常不是经过校准的概率。两个 Agent 都输出 0.9，不代表两个概率可以直接相乘，也不代表它们各自有 90% 的真实正确率。

置信度至少需要回答：

这个数是主观确信度还是经过校准的概率；
它是否基于同一份证据；
Agent 是否知道自己的未知；
在历史评测中，输出 0.8 的样本有多少真正正确；
不同任务类型是否需要不同校准曲线。

因此，聚合器不应直接计算：

0.8 + 0.7 + 0.9

然后把结果解释成“高可信”。更合理的做法是把置信度作为辅助特征，把可验证证据、独立性和阻断问题放在前面。

十、成本：每增加一个 Agent，都增加新的预算项

1. 基本成本模型

设：

$N$ ：参与的 Agent 数量；
$R$ ：辩论轮数；
$I_i$ ：第 $i$ 个调用的输入 token 数；
$O_i$ ：第 $i$ 个调用的输出 token 数；
$P_{\text{in}}$ ：输入 token 单价；
$P_{\text{out}}$ ：输出 token 单价；
$C_{\text{tool}}$ ：工具调用、检索和执行环境成本。

总成本可近似为：

C_{\text{total}} = \sum_{i=1}^{M} \left( I_iP_{\text{in}}+O_iP_{\text{out}} \right) + C_{\text{tool}}

其中 $M$ 是实际调用次数，不一定等于 $N\times R$ ，因为系统可能提前停止或按风险动态扩展。

若每轮有 $N$ 个 Agent，运行 $R$ 轮，则最粗略的调用数为：

M \approx N\times R + M_{\text{critic}} + M_{\text{judge}} + M_{\text{verifier}}

这说明一个常见误区：

只计算“专家 Agent”的调用数量，会低估 Critic、Judge、Verifier、重试和工具调用的成本。

2. 延迟模型

如果第一轮 Agent 并发运行，第一轮延迟接近：

L_{\text{parallel}} \approx \max(L_1,L_2,\ldots,L_N)

如果串行运行，则接近：

L_{\text{serial}} \approx \sum_{i=1}^{N}L_i

因此，独立分析通常适合并发；但交叉辩论、工具验证和人工审批具有依赖关系，不能简单全部并发。

一个实际流程可能是：

阶段 1：4 个独立 Agent 并发
阶段 2：证据规范化
阶段 3：1 个 Critic
阶段 4：只对高风险问题并发执行验证
阶段 5：Judge 或人工审批

Anthropic 将并行化描述为同时运行多个 LLM 调用并以程序方式聚合，指出它既可以拆分独立子任务，也可以对同一任务进行多次尝试。(anthropic.com)

3. 边际收益递减

假设第一轮使用 3 个 Agent 已经发现了主要风险，增加第 4、5 个 Agent 可能只产生重复意见。

可以定义一个近似的边际收益：

\Delta Q_k = Q(k)-Q(k-1)

其中 $Q(k)$ 是使用 $k$ 个 Agent 后的任务质量。

当：

\frac{\Delta Q_k}{\Delta C_k} < \lambda

时，表示新增 Agent 带来的质量收益低于单位成本阈值 $\lambda$ ，应停止扩展。

这不是要求在线系统精确计算一个理论质量函数，而是要求通过离线评测观察：

新增 Agent 发现了多少新问题；
新问题中有多少是真实问题；
是否引入新的错误；
是否改善了关键指标，而不仅是文本更长；
额外成本是否值得。

十一、停止边界：没有停止条件的辩论会变成循环自洽

Agent 系统必须明确什么时候停止。Anthropic 特别指出，自治 Agent 会带来更高成本和错误累积风险，应设置最大迭代次数等停止条件，并通过环境中的真实反馈评估进展。(anthropic.com)

可以定义四类停止状态：

accepted      已满足接受条件
rejected      已满足拒绝条件
needs_evidence 证据不足，需要补充验证
escalated     超出 Agent 权限，需要人工判断

不要把以下状态误认为成功：

Agent 之间达成一致
回复文本变得更流畅
Critic 没有继续提出新问题
模型输出了高置信度

1. 一个可操作的停止策略

from dataclasses import dataclass, field
from typing import Literal

Decision = Literal[
    "accepted",
    "rejected",
    "needs_evidence",
    "escalated",
]

@dataclass
class Issue:
    severity: Literal["low", "medium", "high", "critical"]
    resolved: bool
    description: str

@dataclass
class ReviewState:
    support_score: float
    oppose_score: float
    issues: list[Issue] = field(default_factory=list)
    new_evidence_count: int = 0
    round_no: int = 0
    max_rounds: int = 2
    side_effect_risk: Literal["low", "medium", "high"] = "low"

def decide(state: ReviewState) -> Decision:
    critical_open = any(
        issue.severity == "critical" and not issue.resolved
        for issue in state.issues
    )

    high_open = any(
        issue.severity == "high" and not issue.resolved
        for issue in state.issues
    )

    if critical_open:
        return "escalated"

    if state.side_effect_risk == "high" and high_open:
        return "escalated"

    if state.round_no >= state.max_rounds:
        return "accepted" if (
            state.support_score > state.oppose_score
            and not high_open
        ) else "needs_evidence"

    if state.new_evidence_count == 0 and high_open:
        return "needs_evidence"

    if state.support_score - state.oppose_score >= 3.0 and not high_open:
        return "accepted"

    if state.oppose_score - state.support_score >= 3.0:
        return "rejected"

    return "needs_evidence"


state = ReviewState(
    support_score=7.2,
    oppose_score=5.1,
    issues=[
        Issue(
            severity="high",
            resolved=False,
            description="回滚后的重复写入尚未验证",
        )
    ],
    new_evidence_count=0,
    round_no=1,
    max_rounds=2,
    side_effect_risk="high",
)

print(decide(state))

预期输出：

escalated

为什么不是 accepted？

因为这个例子同时满足：

支持分高于反对分；
仍存在未解决的高严重性问题；
任务有高副作用风险。

这体现了一个重要原则：

总分用于排序，阻断条件用于安全边界。

如果把 side_effect_risk 改为 low，则结果可能变成 needs_evidence，因为系统仍然缺少关键验证。若高严重性问题被解决，且支持分领先超过阈值，才可能进入 accepted。

十二、故障路径比正常路径更能说明系统是否可靠

1. 某个 Agent 超时

正确处理不是把超时当成反对票，也不是无限重试。

应区分：

timeout         调用没有返回
invalid_output  返回无法解析
tool_error      工具执行失败
unsupported     Agent 明确表示无法判断
negative        Agent 提供了反对证据

只有 negative 才是实质性反对意见。其余状态是证据缺失或执行失败。

2. 某个 Agent 返回格式错误

如果输出契约要求结构化 JSON，则解析失败应进入：

invalid_output

系统可以：

记录原始输出；
进行一次格式修复或重试；
超过重试次数后标记该 Agent 不可用；
不把它计入支持或反对票；
根据任务风险决定是否继续。

如果格式错误的 Agent 恰好是唯一的安全审查者，则即使其他 Agent 都成功，也不能假设安全审查已经完成。

3. Critic 与主 Agent 使用相同错误证据

这是共同模式错误，不是“Critic 漏检”这么简单。

诊断时需要检查：

主 Agent 的证据集合
Critic 的证据集合
两者的 independence_key
检索时间
工具调用参数
系统提示版本

如果两者完全共享上下文和检索结果，Critic 的“同意”不应视为新的独立支持证据。

4. Agent 之间无限反驳

常见循环如下：

A：方案可行
B：存在风险
A：风险可以处理
B：处理方式未证明
A：可以进一步测试
B：测试本身还需要验证

这类循环没有产生新证据，只是在重复改变措辞。

系统应检测：

新增主张数量；
新增证据数量；
未解决问题集合是否变化；
连续两轮是否只复述已有内容；
成本和延迟是否达到上限。

若连续两轮没有新增独立证据，应停止辩论，进入：

needs_evidence

而不是继续要求 Agent“更深入地思考”。

十三、不同任务需要不同的聚合协议

1. 事实问答

适合：

独立检索
→ 来源去重
→ 主张抽取
→ 引用一致性检查
→ 冲突来源处理

核心不是投票，而是确认每个事实是否有来源、来源是否支持原句、来源是否过期。

2. 代码生成

适合：

多个实现候选
→ 编译
→ 单元测试
→ 属性测试
→ 静态分析
→ 安全 Critic
→ 人工审查高风险变更

对于代码，运行结果通常比语言模型投票更有价值。Anthropic 也指出，代码任务的优势之一是可以通过自动化测试验证功能，但自动化测试不能代替对整体系统要求的人工审查。(anthropic.com)

3. 规划与方案评审

适合：

独立方案
→ 约束检查
→ 反例构造
→ 风险排序
→ 成本与收益比较
→ 选择或升级人工

规划任务通常没有一个简单的“真值函数”，因此必须明确 Rubric：

正确性：是否满足业务约束
完整性：是否覆盖关键路径
可执行性：是否具备所需资源
可回滚性：失败时是否能恢复
成本：是否符合预算
风险：是否存在不可接受副作用

4. 高风险动作

涉及以下操作时，不能让多数投票直接授权：

删除数据；
转账或扣款；
发布配置；
修改权限；
发送对外通知；
部署生产代码；
执行不可逆迁移。

可以允许 Agent 负责：

准备计划
收集证据
生成变更
运行模拟
形成审批材料

但最终执行应由：

明确的规则门；
工具级权限；
人工审批；
可回滚机制；

共同约束。

OpenAI 的 Agent 文档将 Guardrail、审批和可恢复的运行状态作为 Agent 工作流的一部分，而不是把安全性完全寄托于模型自我约束。(developers.openai.com)

十四、生产实现的最小状态模型

一个可观测的多 Agent 运行至少应保存以下状态：

Run
 ├── run_id
 ├── task
 ├── policy_version
 ├── budget
 ├── deadline
 ├── current_phase
 ├── final_decision
 └── evidence_graph

AgentAttempt
 ├── agent_id
 ├── role
 ├── model
 ├── prompt_version
 ├── input_hash
 ├── output
 ├── status
 ├── latency
 ├── token_usage
 └── error

Claim
 ├── claim_id
 ├── text
 ├── position
 ├── assumptions
 └── status

Evidence
 ├── evidence_id
 ├── source
 ├── independence_key
 ├── observed_at
 ├── supports
 └── contradicts

Issue
 ├── issue_id
 ├── severity
 ├── required_check
 ├── verification_result
 └── resolved

OpenAI 将 Agent Run、工具调用、Agent 切换、Guardrail、审批和追踪作为 SDK 运行时的重要表面；无论使用具体 SDK 还是自建编排器，生产系统都需要保留类似的运行状态和追踪信息。(developers.openai.com)

十五、如何诊断“看起来很可靠但实际不可靠”

可以建立以下诊断指标。

1. 独立证据率

R_{\text{independent}} = \frac{\text{具有不同 independence\_key 的有效证据数}} {\text{全部有效证据数}}

如果 8 个 Agent 最终只产生 2 个独立来源，系统的“8 票”应被降权解释。

2. Critic 命中率

R_{\text{critic-hit}} = \frac{\text{Critic 发现且验证为真实的问题数}} {\text{Critic 报告的问题总数}}

命中率太低，说明 Critic 可能过度挑剔或标准不清；命中率很高但发现率很低，则可能 Critic 过于保守。

3. 共识错误率

R_{\text{consensus-error}} = \frac{\text{多数 Agent 一致但最终被验证为错误的任务数}} {\text{产生多数共识的任务数}}

这个指标直接衡量“多数一致”是否被误当成可靠性。

4. 新证据率

R_{\text{novel-evidence}} = \frac{\text{某轮新增且去重后的证据数}} {\text{该轮全部证据数}}

如果连续几轮新证据率接近 0，辩论就已经退化为文本重写。

5. 校准误差

将 Agent 的置信度分桶，例如：

0.6～0.7
0.7～0.8
0.8～0.9
0.9～1.0

对每个桶比较：

平均置信度
实际正确率

如果 Agent 平均置信度为 0.9，但实际正确率只有 0.65，那么这个置信度不能直接用于决策阈值。

十六、几条需要明确拒绝的误解

误解一：Agent 越多越可靠

错误。只有当新增 Agent 带来新的错误搜索路径或独立证据时，数量才有价值。

误解二：不同人格就是独立性

错误。人格变化不等于数据源、上下文、工具和错误模式变化。

误解三：Critic 说“没有问题”就是验证通过

错误。Critic 的未发现只能说明它没有报告问题，不能证明命题成立。

误解四：高置信度可以替代证据

错误。未经校准的置信度通常只能表达模型状态，不能表达真实概率。

误解五：更多辩论轮次一定更好

错误。轮次增加会造成观点传染、成本上升和错误自洽。没有新增证据时，继续辩论通常没有收益。

误解六：Judge 可以解决所有冲突

错误。Judge 只能依据输入证据和评价标准作出判断。如果证据本身相关、过期或错误，Judge 可能只是更有条理地放大错误。

十七、一个可靠的最小协议

对于一般的多 Agent 评审任务，可以从以下协议开始：

阶段 0：定义命题、成功条件、阻断条件和预算

阶段 1：独立生成
- Agent 互相不可见
- 每个结论必须带证据、假设和反例
- 至少一个角色专门寻找失败条件

阶段 2：证据规范化
- 抽取主张
- 合并重复证据
- 标记 independence_key
- 区分事实、推断和意见

阶段 3：Critic
- 逐条检查主张
- 只报告可定位、可验证的问题
- 给出验证动作和通过条件

阶段 4：Verifier
- 优先执行规则、测试、查询、模拟和工具检查
- 失败、超时和无法执行必须区分

阶段 5：聚合
- 支持与反对证据加权
- 关键问题具有阻断权
- 支持 abstain、needs_evidence 和 escalated

阶段 6：停止
- 达到接受或拒绝门槛
- 无新增证据
- 超过轮次、预算或时间
- 触发高风险人工审批

这套协议不要求所有任务都使用五个 Agent，也不要求一定进行辩论。对于很多问题，一个带检索、结构化输出和规则检查的单 Agent Workflow 可能已经足够。Anthropic 明确建议从最简单的方案开始，在评测证明有收益后再增加 Agentic 复杂度。(anthropic.com)

结语：可靠性来自独立性和可验证性，不来自热闹的讨论

多 Agent 辩论真正解决的问题，不是“让更多模型发表意见”，而是把单一路径中的不确定性拆开：

用独立路径发现不同候选和反例；
用证据标识避免重复计票；
用 Critic 暴露推理跳跃和缺失条件；
用 Verifier、规则和工具把意见转成事实；
用聚合器处理冲突、不确定和阻断问题；
用预算、轮次和停止边界控制成本与错误累积；
用人工审批接管不可编码或不可逆的责任。

如果多个 Agent 共享同一错误来源，它们的一致是伪共识；如果 Critic 只复述偏好，它的反馈不是验证；如果聚合器只看票数，它会把相关错误包装成统计可信度。

真正值得信任的输出应当能够回答：

结论是什么？
依据哪些独立证据？
哪些证据只是重复来源？
有哪些未解决的反例？
哪些条件已经被工具验证？
如果判断错误，系统会在哪里停止？

当系统无法回答这些问题时，增加 Agent 数量通常只会增加文本、成本和错误的自信程度。

系列导航与关联阅读

官方资料

本文依据 Agent、模型、协议与框架官方资料重新梳理；正文、示例与生产清单由 WR BLOG 编写。