Agent丨在 LLM 或 RAG 应用中，如何减少和规避幻觉问题？

type

Post

status

Published

date

Apr 21, 2026

slug

agent15

summary

一、先定义：LLM/RAG 中的“幻觉”到底是什么？

在工程里，不建议把所有错误都叫“幻觉”。更实用的分类是下面几种。

类型	典型现象	根因	主要治理手段
参数幻觉	模型凭训练记忆编造事实	未接入权威知识源	RAG、工具查询、拒答策略
检索幻觉	检索到的文档本身不相关，模型硬答	chunk、召回、重排质量差	hybrid search、rerank、metadata filter
归因幻觉	答案看似有引用，但引用不支持结论	citation 只是装饰	claim-level verification
上下文污染	历史对话、工具输出、用户注入污染推理	context 过长或混杂	compaction、memory 分层、输入隔离
工具幻觉	模型声称执行了某操作，但实际没执行	没有真实 tool observation	工具回执、状态机、审计日志
行动幻觉	Agent 错误调用工具或越权操作	权限和策略不清	allow/ask/deny、sandbox、人工确认
评测幻觉	LLM-as-judge 自己误判答案正确	评测器也会错	多指标、多 judge、人工抽检

所以，RAG 并不天然等于无幻觉。RAG 只是给模型提供外部证据，但是否检索对、是否使用对、是否引用对、是否验证过，才决定系统可靠性。

二、成熟 Agent 给我们的启发

1. Claude / Claude Code：证据、工具、权限、验证闭环

Claude 的“减少幻觉”建议非常适合迁移到 RAG：允许拒答、先提取原文证据、要求引用、每个 claim 找支撑 quote，找不到就撤回。(Claude Platform)

Claude Code 的设计也很值得参考。它不是让模型单纯“想”，而是让模型读项目文件、定位代码、展示改动、请求用户批准后再编辑；官方 quickstart 里也说明 Claude Code 会按需读取项目文件，修改文件前会请求权限，并且在修复 bug/实现功能时会定位相关代码、理解上下文、实现方案、在可用时运行测试。(Claude Code)

这给 RAG/LLM 应用的启发是：

不要让模型直接“生成最终事实”，而要让它经历：
查证据 → 生成草稿 → 拆 claim → 验证 claim → 再输出。

Claude Code 的权限系统也说明了另一个关键点：Agent 的可靠性不只是“答得对”，还包括“不能越权”。Claude Code 支持 allow、ask、deny 等细粒度权限规则，并区分只读、Bash、文件修改等工具类型；官方还建议权限和 sandbox 结合使用，形成 defense-in-depth。(Claude Code)

2. OpenCode：compaction / prune 是上下文治理，而不是简单省 token

OpenCode 文档中有一个很关键的配置：compaction。它支持自动压缩上下文、移除旧工具输出、预留压缩 token buffer。(OpenCode)

OpenCode 源码里的 compaction 模板也很有参考价值：它要求压缩后的摘要保留 Goal、Constraints & Preferences、Progress、Key Decisions、Next Steps、Critical Context、Relevant Files，并要求保留精确的文件路径、命令、错误字符串和标识符。(GitHub)

这说明成熟 Agent 不是把历史对话随便总结成一段自然语言，而是做“结构化上下文压缩”。

在 RAG/LLM 应用中，很多幻觉并不是模型笨，而是上下文里混入了太多过期、重复、矛盾、低价值信息。上下文治理至少要包括：

旧工具结果是否还需要？

历史对话里的结论是否已过期？

用户约束是否被完整保留？

检索文档是否和当前问题强相关？

摘要是否丢掉了关键实体、路径、数字、错误码？

3. OpenClaw：真实工具场景下，安全边界就是幻觉边界

OpenClaw 是一个可以接入 WhatsApp、Telegram、Slack、Discord 等真实消息通道的个人 AI assistant。它的官方安全文档强调：OpenClaw 的安全模型默认是单用户个人助手边界，不是多个互不信任用户共享同一个 agent/gateway 的敌对多租户边界。(GitHub)

这对 Agent 幻觉治理很重要。因为一旦 Agent 能访问文件、浏览器、消息、日历、shell，幻觉就不只是“答错”，而可能变成“错误行动”。OpenClaw 文档建议从最小访问开始，再逐步扩大权限，并通过 openclaw security audit 检查 DM 策略、工具权限、文件权限、网络暴露、插件等风险。(OpenClaw)

OpenClaw 还区分“谁能触发 agent”和“哪些上下文会注入模型输入”，例如 contextVisibility 可以控制引用回复、线程历史等补充上下文是否按 allowlist 过滤。(OpenClaw)

这给 RAG/LLM 系统的启发是：

幻觉治理不仅是生成层问题，还是输入边界、工具边界、身份边界和上下文可见性问题。

三、整体架构：生产级防幻觉 RAG 应该长什么样？

这个架构的关键不是“检索 + 生成”四个字，而是中间的几个闸门：

证据足够性闸门：没有足够证据就不进入生成。

生成约束闸门：只允许使用检索上下文回答。

claim 验证闸门：逐条验证答案里的事实断言。

最终输出闸门：无证据 claim 删除，不确定信息降级。

观测回流闸门：把失败样本进入评测集。

四、第一层治理：检索阶段减少“错误证据”

RAG 幻觉很多时候不是生成器的问题，而是检索器把模型带偏了。

1. 不要只用向量检索

向量检索擅长语义相似，但在数字、专有名词、版本号、错误码、API 名称上容易失真。生产系统建议使用：

检索方式	适合场景
BM25	精确关键词、错误码、函数名、法律条款
Vector Search	语义相近问题、自然语言问答
Metadata Filter	时间、租户、权限、文档类型过滤
Reranker	细粒度判断 chunk 是否真能回答问题
Parent-child Chunk	小 chunk 召回，大 parent 提供上下文

LangSmith 的 RAG 评测教程把典型 RAG 应用拆成 indexing、retrieval、generation 三步，并强调要评估 answer relevance、answer accuracy、retrieval quality。(LangChain 文档)

2. 检索结果必须做“可回答性判断”

不要把 top-k 全塞给模型。应该先判断：这些 evidence 是否足够回答问题。

这个函数的思想是：检索不到，不要硬答；检索弱相关，也不要硬答。

五、第二层治理：生成阶段强制“基于证据回答”

很多 RAG 系统的 prompt 是这样的：

根据以下上下文回答用户问题。

这太弱了。更可靠的模板应该明确：

你只能使用 <evidence> 中的信息。
如果证据不足，请回答“根据当前资料无法确定”。
每个事实性结论必须引用 evidence id。
不要使用模型自身记忆补充事实。
不要把推测写成事实。
如果多个证据冲突，请说明冲突，而不是自行合并。

可以把 prompt 设计成结构化输入：

Anthropic 的提示工程文档也强调：复杂研究任务要定义成功标准，并鼓励跨来源验证；对 agentic search 场景，清晰的成功标准和 source verification 很关键。(Claude Platform)

六、第三层治理：答案生成后做 claim-level verification

只要求模型带引用还不够。模型可能给出“看起来像引用”的幻觉。更稳的方式是：

先生成答案。

从答案中抽取事实 claim。

对每个 claim 找 evidence。

判断 evidence 是否 entail claim。

不支持的 claim 删除或降级。

可以实现一个简化版 verifier：

NVIDIA NeMo Guardrails 的 fact-checking rail 也是类似思想：针对 RAG 问答，用 $relevant_chunks 作为 evidence，检查回答是否 grounded in provided evidence；如果 fact-checking 分数低于阈值，可以拒绝回复。(NVIDIA Docs)

七、第四层治理：让 Agent 通过工具“观察事实”，而不是凭空声称

Agent 类应用中，最危险的幻觉是：

“我已经帮你创建了文件 / 发了邮件 / 修复了 bug / 跑过测试。”

但其实它没有执行，或者执行失败了。

Claude Code 的模式值得学习：它会读取项目文件、展示修改、请求批准、再进行编辑；文件修改前会要求用户确认。(Claude Code)

工程上应该把 Agent 操作设计成状态机：

示例代码：

这类设计的关键是：

最终回答必须来自 tool observation，而不是来自模型想象。

八、第五层治理：权限系统减少“行动型幻觉”

LLM 应用如果只是聊天，幻觉主要影响答案质量。Agent 一旦能调用工具，幻觉会变成真实副作用。

Claude Code 支持 fine-grained permissions，允许团队定义 agent 能使用哪些工具、访问哪些文件或域名，并支持 allow、ask、deny 规则。(Claude Code)

OpenCode 也支持权限配置，例如可以要求 edit 和 bash 工具必须经过用户批准。(OpenCode)

OpenClaw 的安全文档则更适合真实助手场景。它建议从最小访问开始，并特别关注谁能触发 bot、bot 能在哪里行动、bot 能接触什么。它还给出了 hardened baseline，例如本地 loopback、token auth、DM 隔离、禁用 runtime/fs/automation 工具、exec 总是询问等策略。(OpenClaw)

一个 RAG/Agent 系统可以抽象出这样的权限矩阵：

操作	默认策略	原因
读取公开知识库	allow	低风险
读取用户私有文档	ask / policy check	涉及隐私和租户隔离
写数据库	ask + transaction preview	有副作用
执行 shell	deny / sandbox ask	高风险
发邮件/消息	ask + 内容预览	不可轻易撤回
删除文件	deny by default	高破坏性
调用外部 API	allowlist	防止数据外泄

核心原则：

工具权限越大，模型自由度越小。
模型越不确定，系统越应该拒绝行动。

九、第六层治理：上下文压缩与记忆，防止上下文污染

长上下文不是越长越好。Anthropic 的 context engineering 文章提到，长时段 agent 会遇到 context pollution，常用技术包括 compaction、structured note-taking 和 multi-agent architectures；Claude Code 的 compaction 会保留架构决策、未解决 bug、实现细节，同时丢弃冗余工具输出或消息。(anthropic.com)

OpenCode 的 compaction 配置也有类似思想：自动压缩、prune 旧工具输出、预留 compaction buffer。(OpenCode)

可以借鉴 OpenCode 的结构化压缩方式：

这里最重要的是四个“必须保留”：

用户约束。

已确认事实。

关键决策。

精确实体：文件路径、函数名、错误码、日期、金额、版本号。

最容易造成幻觉的是“模糊摘要”：

错误示例：
之前修过登录问题，下一步继续完善。

正确示例：
已修改 src/auth/login.ts 的 validatePassword()，解决空密码返回 500 的问题；测试 auth/login.spec.ts::empty_password 仍失败，错误为 Expected 400, received 422；下一步需统一 API error code。

十、第七层治理：多 Agent 验证，而不是单 Agent 自说自话

Claude Code 的 Code Review 功能是一个很好的参考：官方文档说明它会用多个 specialized agents 并行分析 PR 和周边代码，再通过 verification step 检查候选问题，以过滤 false positives，然后去重、按严重程度排序并发布评论。(Claude Code)

RAG 应用也可以借鉴这个模式：

可以设计四个角色：

Agent	职责
Retriever	只负责找证据，不负责生成
Writer	只根据证据生成草稿
Evidence Verifier	逐 claim 判断证据是否支持
Policy Verifier	判断是否越权、是否需要拒答
Final Gate	删除无证据内容，输出最终答案

注意，不一定真的要启动多个模型实例。也可以用一个模型分阶段完成。但在工程逻辑上，职责必须分离。

十一、RAG 防幻觉主流程代码示例

下面是一个简化但接近生产结构的 RAG pipeline。

这个 pipeline 的核心不是某个模型能力，而是“每一步都有失败路径”。

没有证据时拒答，证据弱时降级，claim 不支持时重写，工具失败时不假装成功。

十二、评测：没有评测，防幻觉策略很快退化

RAG 防幻觉不能只靠主观感觉，需要持续评测。

Ragas 提供了面向 RAG pipeline 各组件的指标，包括 Faithfulness、Answer Relevancy、Context Recall、Context Precision、Context Utilization、Noise Sensitivity 等。(Ragas)

LangSmith 的 RAG 评测教程也建议建立测试数据集、运行 RAG 应用、再用 answer relevance、answer accuracy、retrieval quality 等维度评估。(LangChain 文档)

一个实用指标体系如下：

指标	问题	目标
Context Precision	检索回来的内容有多少真的有用？	减少噪声
Context Recall	标准答案需要的证据是否召回？	防止漏检
Faithfulness	答案是否忠实于证据？	防止编造
Answer Relevance	是否回答了用户问题？	防止答非所问
Citation Accuracy	引用是否真的支持句子？	防止假引用
Abstention Accuracy	该拒答时是否拒答？	防止硬答
Tool Success Truthfulness	声称执行的操作是否真的成功？	防止工具幻觉

评测代码可以这样组织：

更重要的是构造“容易幻觉”的测试集：

知识库没有答案的问题。

多个文档互相冲突的问题。

旧版本文档和新版本文档同时存在的问题。

问题里带错误前提。

需要精确数字、日期、金额的问题。

引用文档只支持部分结论的问题。

prompt injection 混在文档里的问题。

工具调用失败但模型可能想继续编的问题。

十三、生产级防幻觉 Checklist

检索层

是否支持 hybrid search，而不是只用 vector？

是否有 metadata filter，例如租户、权限、时间、文档类型？

是否有 reranker？

是否有最小相关性阈值？

是否支持“检索不到就拒答”？

是否记录每次回答用到的 evidence？

生成层

prompt 是否明确“只能使用 evidence”？

是否允许回答“不知道”？

是否禁止用常识补全缺失信息？

是否要求每个事实性结论带引用？

是否对时间敏感问题要求最新证据？

验证层

是否做 claim extraction？

是否逐 claim 验证 evidence support？

是否删除 unsupported claim？

是否能发现 evidence conflict？

是否对高风险回答启用二次验证？

Agent 工具层

工具调用是否有 observation？

工具失败时是否禁止声称成功？

写操作是否需要确认？

shell、文件、网络、数据库是否有 allow/ask/deny？

是否有 sandbox？

是否有审计日志？

上下文层

是否定期 compaction？

compaction 是否结构化？

是否保留用户约束、关键决策、精确实体？

是否清理过期工具输出？

是否隔离不同用户、不同租户、不同会话的 memory？

评测层

是否有 hallucination benchmark？

是否单独评估 retrieval 和 generation？

是否评估拒答能力？

是否把线上失败样本回流到测试集？

是否监控 citation accuracy？

十四、一个推荐的最终落地架构

这套架构的本质是：

模型负责语言和推理，系统负责证据、边界、验证和回滚。

十五、总结

在 LLM 或 RAG 应用中减少幻觉，不能只做 prompt engineering。真正有效的是系统工程。

可以把成熟 Agent 的经验总结成六条：

Claude 式证据约束：允许不知道、要求引用、每个结论找支撑，找不到就撤回。(Claude Platform)

Claude Code 式工具闭环：读文件、改文件、跑测试、请求权限，用真实 observation 约束回答。(Claude Code)

OpenCode 式上下文治理：自动 compaction、prune 工具输出、结构化保留目标、约束、决策、关键上下文。(OpenCode)

OpenClaw 式边界意识：真实工具场景中必须明确谁能触发、能看什么上下文、能调用什么工具、是否需要审计和沙箱。(OpenClaw)

NeMo Guardrails 式事实核验：把回答和 evidence 做 entailment 检查，低分就拒答或阻断。(NVIDIA Docs)

Ragas / LangSmith 式持续评测：分别评估检索质量、答案相关性、忠实度、召回率、拒答能力。(Ragas)

最终，一句话概括：

防幻觉不是让模型“永远正确”，而是让系统在证据不足、上下文污染、工具失败、权限不明时，有能力停下来、说不知道、请求确认或拒绝行动。