多 Agent 对抗：用"竞争假设"提升 AI 可靠性

一个 AI 说"没问题"，你信不信？两个 AI 互相说对方有问题，你就知道真相了。

单 Agent 的天花板

当你用一个 AI Agent 分析代码变更时，它通常会给你一个看起来很有道理的结论。

但你怎么知道它是不是遗漏了其他风险？

单 Agent 的本质问题是锚定效应——LLM 一旦形成了初始判断，后续的推理都会围绕这个判断展开。它不会主动去挑战自己的结论。

"竞争假设"模式

让多个 Agent 实例各自独立调查，然后互相质疑对方的结论。

┌───────────────┐
│   Team Lead   │
│  (分配假设)    │
└───┬───┬───┬───┘
    │   │   │
┌───┴─┐ │ ┌─┴───┐
▼     ▼ ▼ ▼     ▼
Agent Agent Agent
  A     B   C
   \\   |   /
    \\  |  /
     ▼ ▼ ▼
┌───────────────┐
│   Team Lead   │
│  (合并 + 裁决) │
└───────────────┘

步骤 1：假设分配

Team Lead 把一个问题拆成多个互斥的假设方向，分配给不同的 Agent 实例。

例如，面对一个线上事故：

• Agent A：假设这是数据一致性问题——从数据库日志和数据流向出发调查
• Agent B：假设这是环境/配置问题——从部署配置和基础设施出发调查
• Agent C：假设这是代码逻辑错误——从 Git blame 和代码变更出发调查

步骤 2：独立调查

三个 Agent 各自独立工作，互不干扰。每个 Agent 有自己的上下文窗口，避免"污染"。

步骤 3：交叉质疑

Agent 之间不是简单地汇报结果，而是阅读彼此的结论并提出质疑。

步骤 4：Team Lead 合并裁决

Team Lead 收集所有调查结果和交叉质疑，产出最终结论。

为什么这比"让一个 Agent 分析三遍"好？

1. 上下文隔离防止锚定

同一个 Agent 先从角度 A 分析，再从角度 B 分析时，角度 B 已经被角度 A 影响了。多 Agent 方案中，每个 Agent 有独立的上下文窗口，真正独立。

2. 对抗产生信息增益

交叉质疑产出的是反驳关系图——"A 认为 X，B 用 Y 证据反驳了 X"。这种结构化的对抗过程让你能看到哪些结论是脆弱的。

实际效果：AI 找 AI 的 bug

核心原因不是 QA Agent 更聪明，而是视角不同：

• 开发 AI："这个实现正确吗？"
• QA Agent："这个变更引入了什么风险？"

多视角 AI 交叉审查 > 单视角 AI 深度分析。

什么时候该用、什么时候不该用

竞争假设模式的代价是单 Agent 的 3-5 倍 token 消耗。

实施的关键细节

1. 生成指令必须包含"质疑"动作

你必须显式要求 Agent 互相挑战，而不是只汇报结果。

2. 用文件而非消息传递大块内容

每个 Agent 把结果写到独立的文件中，Team Lead 读取所有文件后做合并。

3. 假设必须互斥

假设之间应该是正交的——从不同的维度、不同的数据源出发。

4. Team Lead 必须看到"推理过程"而非仅"结论"

每个 Agent 应该提交"证据链"而非"结论"。

更广泛的思考

"竞争假设"模式来自情报分析领域的 ACH（Analysis of Competing Hypotheses） 方法，由 CIA 分析师 Richards Heuer 在 1970 年代提出。

可靠性不来自更强的单点，而来自多视角的交叉验证。

这是"AI Agent 工程化实践"系列的第四篇。最后一篇将讨论 AI 与人类的分工模型。