幻觉在Multi-Agent中的传播与抑制：错误如何被放大，以及如何切断

单 Agent 的幻觉是噪声，Multi-Agent 中的幻觉是雪崩。

一、为什么这个问题值得单独讨论

如果你只用一个 LLM 做问答，幻觉的边界是清晰的：模型说错了，用户发现了，纠正即可。但当你把多个 Agent 串联、并联、甚至递归调用时，幻觉的行为模式发生了质变——它不再是一个点错误，而是一种可以在系统中自我强化、级联扩散的系统性风险。

想象一个典型的 Multi-Agent 工作流：

用户Query → 规划Agent → 检索Agent → 总结Agent → 审核Agent → 输出

如果检索 Agent 在第 3 步产生了一个"看似合理但完全虚构"的中间结论，后续的总结 Agent 会把它当作事实基础进行推理，审核 Agent 可能因为上下文过长或依赖关系隐蔽而漏检。最终，一个最初的小幻觉，经过多轮 Agent 的"确认"和"加工"，变成了系统输出的"共识性错误"。

这不是假设。在实际的 RAG 流水线、代码生成协作、多轮研究助手等场景中，我们都观察到了这种现象。本文将系统分析幻觉在 Multi-Agent 架构中的传播机制，并给出可落地的抑制策略。

二、幻觉传播路径分析：错误是怎么被放大的

2.1 传播的三条典型路径

路径一：链式累积（Chain Amplification）

在串行流水线中，每个 Agent 的输出是下一个 Agent 的输入。如果上游 Agent 产生了幻觉，下游 Agent 缺乏独立的真相校验能力，只能基于"被污染"的上下文继续推理。

关键洞察： LLM 对上下文的置信度是"均匀分布"的——它不会自动区分"用户原始输入"和"上游 Agent 的推测"。这意味着一个虚构的事实和一条真实的信息，在模型眼中权重是相近的。

Agent A: "根据我的分析，X公司的营收在2024年增长了300%"  [幻觉]
Agent B: "既然X公司营收增长300%，那么其市场份额必然大幅提升..." [基于幻觉推理]
Agent C: "综合以上分析，X公司是行业领导者..." [幻觉被包装成结论]

路径二：回声放大（Echo Chamber）

在并行或讨论式 Multi-Agent 架构中（如 AutoGen、CrewAI 的讨论模式），多个 Agent 可能基于相同的错误前提相互"印证"。

当一个 Agent 提出一个错误观点，其他 Agent 在没有外部事实校验的情况下，往往会倾向于附和或基于该观点进行扩展，而不是质疑。这种现象类似于社交网络中的信息茧房——错误信息在封闭系统内不断回响，最终被所有参与者当作共识接受。

路径三：递归污染（Recursive Contamination）

在需要多轮迭代或自我改进的系统中（如 Agent 调用工具、获取结果、再调用工具），幻觉可能通过工具参数或中间状态递归传播。

例如：

• Agent 生成一个错误的 API 调用参数
• 工具返回错误结果（或空结果）
• Agent 对错误结果进行"合理解释"，产生二次幻觉
• 这个二次幻觉进入下一轮推理...

2.2 为什么 Multi-Agent 比单 Agent 更容易放大幻觉？

核心矛盾： Multi-Agent 的设计初衷是通过分工和协作提升系统能力，但副作用是每个 Agent 都成了潜在的幻觉放大器，而系统整体缺乏对"信息质量"的统一管控。

三、事实校验 Agent 的设计：给系统装上"免疫系统"

抑制幻觉的第一道防线，是在架构层面引入专门负责事实校验的 Agent。但"加一个校验步骤"不等于解决问题——校验 Agent 本身也可能产生幻觉，或者因为设计不当而成为瓶颈。

3.1 校验 Agent 的三种架构模式

模式 A：串联守门员（Gatekeeper）

在每个关键节点后插入校验 Agent，对上游输出进行事实核查。

[Agent] → [校验Agent] → [通过/驳回/修正] → [下一Agent]

适用场景： 流水线式架构，每个阶段产出明确的中间结果。

设计要点：

• 校验 Agent 的 Prompt 必须与上游 Agent 隔离，只能看到需要校验的内容，不能看到上游的完整推理过程（避免被说服）
• 输出格式严格限定为：{"verdict": "PASS|FAIL|UNCERTAIN", "issues": [...], "confidence": 0.0-1.0}
• 对 UNCERTAIN 的情况，必须触发外部检索或人工介入，不能默认通过

模式 B：并行陪审团（Jury）

多个独立的校验 Agent 同时审查同一输出，通过投票或共识机制决定结果。

          ┌→ [校验Agent A]
[Agent] → ┼→ [校验Agent B] → [聚合器] → 最终判定
          └→ [校验Agent C]

优势： 降低单个校验 Agent 的偏见和幻觉风险。

关键参数：

• 各校验 Agent 应使用不同的模型或不同的 Prompt 策略，避免"同构错误"
• 聚合策略推荐保守原则：只要有一个 Agent 标记为 FAIL，就触发复核

模式 C：对抗式红队（Red Team）

专门设置一个"挑错 Agent"，其唯一目标就是找出其他 Agent 输出中的事实错误和逻辑漏洞。

[Agent输出] → [红队Agent: 找出所有错误] → [原Agent辩护/修正] → [仲裁Agent]

优势： 模拟对抗环境，迫使原 Agent 提高输出质量。

注意事项： 红队 Agent 需要明确的"攻击面"定义，否则可能陷入无意义的挑刺，影响效率。

3.2 校验 Agent 的 Prompt 工程

一个高效的事实校验 Prompt 应该包含以下要素：

你是一名严格的事实核查员。你的任务是审查以下陈述的事实准确性。

## 审查原则
1. 任何无法通过可靠来源验证的陈述，都应标记为"未验证"
2. 不要基于常识推断——只判断是否有明确证据支持
3. 对数字、日期、人名、机构名等实体信息保持最高敏感度
4. 区分"事实陈述"和"观点/推测"，只核查事实陈述

## 输出格式
对于每个待核查的陈述，输出：
- 陈述原文
- 判定：VERIFIED / UNVERIFIED / CONTRADICTED
- 依据：（如果有外部检索结果，引用来源；如果没有，明确说明"无独立验证来源"）
- 置信度：0-1

## 特别注意
- 如果陈述包含多个子主张，必须逐一核查
- 不要因为你"觉得合理"就标记为 VERIFIED
- 对模糊表述（如"据报道"、"有人认为"）保持警惕，追溯原始出处

四、置信度传播算法：让系统"知道"自己不确定

事实校验是离散的（通过/不通过），但真实世界的信息往往是连续的——有些陈述部分正确，有些高度不确定。因此，我们需要在 Multi-Agent 系统中引入置信度传播机制。

4.1 为什么需要置信度传播？

在传统系统中，信息以文本形式在 Agent 间传递，所有内容都被赋予相同的"可信度权重"。这导致：

• 一个高置信度的事实和一个低置信度的推测，在下游 Agent 眼中没有区别
• 系统无法量化"整体输出的可靠程度"
• 无法基于置信度动态调整策略（如低置信度时增加校验、触发检索或降级输出）

4.2 置信度传播的核心设计

4.2.1 每个 Agent 输出附带置信度元数据

每个 Agent 的输出不应只是文本，而应是一个结构化对象：

{
  "content": "X公司在2024年Q3的营收为5.2亿美元",
  "confidence": {
    "overall": 0.75,
    "breakdown": {
      "entity_resolution": 0.9,
      "temporal_accuracy": 0.8,
      "numerical_precision": 0.6
    }
  },
  "evidence": [
    {"source": "X公司Q3财报", "type": "primary", "relevance": 1.0},
    {"source": "行业分析报告", "type": "secondary", "relevance": 0.5}
  ],
  "uncertainty_flags": ["数值为推算值，非官方披露"]
}

4.2.2 置信度聚合规则

当多个 Agent 的输出被组合时，需要定义置信度如何传播：

串行传播（Sequential）：

C_final = C_1 × C_2 × ... × C_n

即最终置信度是各阶段置信度的乘积。这反映了链式系统中错误的累积效应——只要有一个环节的置信度低，整体置信度就会显著下降。

并行融合（Parallel Fusion）：

对于多个 Agent 对同一问题的独立回答，使用加权融合：

C_fused = Σ(w_i × C_i) / Σ(w_i)

其中权重 w_i 可以基于 Agent 的历史准确率、专业领域匹配度等动态调整。

共识增强（Consensus Boosting）：

当多个独立 Agent 给出一致结论时，适当提升置信度（但不能超过上限）：

C_consensus = min(C_base + α × agreement_ratio, C_max)

其中 α 是增强系数，agreement_ratio 是共识比例。注意：共识不等于正确，因此 C_max 应设定一个严格上限（如 0.95），避免群体幻觉。

4.3 基于置信度的动态决策

置信度传播的真正价值在于驱动系统行为：

这种机制让系统从"尽力而为"转变为"有自知之明"——知道什么时候该说"我不知道"。

五、多源交叉验证：打破信息茧房

即使有了置信度传播和事实校验 Agent，如果所有校验都依赖同一信息源或同一类模型，系统仍可能陷入系统性盲区。多源交叉验证是打破这一困境的关键。

5.1 交叉验证的维度

维度一：信息源交叉

不依赖单一检索结果或单一数据库。对于关键事实，应从多个独立来源获取信息并进行比对：

来源A: "X公司2024年营收10亿"  [来自财报]
来源B: "X公司2024年收入约10亿"  [来自新闻报道]
来源C: "X公司2024年营收9.8亿"  [来自第三方分析]

如果多个独立来源一致，置信度提升；如果冲突，触发深度调查。

维度二：模型交叉

使用不同架构、不同训练数据的模型对同一问题进行独立回答，比对结果：

GPT-4: "答案是A"
Claude: "答案是A"
Llama: "答案是B"

分歧本身就有信息价值——它提示这个问题可能存在歧义或知识边界。

维度三：工具交叉

对于可验证的事实（如数学计算、代码执行、数据库查询），优先使用确定性工具而非 LLM 推理：

LLM: "计算 2345 × 6789 = ?"
→ 不直接生成答案
→ 调用 Python 工具执行
→ 返回确定结果

黄金法则： 能用工具验证的，绝不依赖模型记忆；能查数据库的，绝不依赖模型推断。

5.2 冲突解决机制

当多源验证出现冲突时，系统需要明确的仲裁策略：

1. 优先级规则： 一手来源 > 二手来源，确定性工具 > 模型推理，近期数据 > 历史数据
2. 分歧标记： 如果冲突无法解决，在最终输出中明确呈现分歧，而不是强行选择一个
3. 降级策略： 高冲突场景下，主动降低输出置信度，或转为人工处理

六、实战建议：从理论到落地

6.1 渐进式实施路线图

阶段一：可见性（Visibility）

• 为每个 Agent 的输出添加结构化元数据（置信度、来源、不确定性标记）
• 建立幻觉事件的日志和追踪机制
• 目标：先"看见"问题，再解决问题

阶段二：防御（Defense）

• 在关键节点引入事实校验 Agent
• 实施串行置信度传播（乘法规则）
• 对低置信度输出触发自动检索或人工复核

阶段三：韧性（Resilience）

• 部署多源交叉验证
• 引入对抗式红队机制
• 建立基于历史数据的 Agent 准确率画像，动态调整权重

6.2 关键指标

建议监控以下指标来评估幻觉抑制效果：

6.3 一个最小可落地的设计模式

如果你今天就要改造现有的 Multi-Agent 系统，以下是优先级最高的三件事：

1. 给每个 Agent 的输出加"健康标签"：至少包含一个 confidence_score 和一个 uncertainty_note
2. 在最终输出前加一个"守门员"：一个独立的校验 Agent，只审查最终输出，不看中间过程
3. 对数字、日期、人名等实体强制走工具验证：接入搜索引擎、数据库或计算器，不要让 LLM "自由发挥"

七、结语：可靠性是 Multi-Agent 的生死线

Multi-Agent 架构的潜力是巨大的——分工协作、并行处理、复杂推理，这些能力单 Agent 难以企及。但与此同时，每一个新增的 Agent 都是一个新的幻觉风险点，每一次信息传递都是一次潜在的污染机会。

如果我们不在架构层面系统性解决幻觉传播问题，Multi-Agent 系统就会像一个没有免疫力的生物体——每一个细胞（Agent）都在努力工作，但整个 organism 却可能因为一个微小的感染（幻觉）而崩溃。

抑制幻觉不是加一个校验步骤那么简单。它需要的是：结构化的置信度传播、多层次的验证机制、对抗性的测试文化，以及最重要的——让系统学会说"我不确定"的谦逊。

在 AI 应用越来越深入关键业务场景的今天，可靠性不再是加分项，而是生死线。希望本文的分析和策略，能为你的 Multi-Agent 系统筑起一道坚实的防线。