一、核心结论

Agent 的出错/幻觉，不是单点问题，而是「模型原生不确定性 + RAG检索误差 + Prompt约束不足 + 工具链不可验证」的叠加效应。

结合我项目落地经验，按优先级排序，幻觉的主要诱因的是：

1. 高概率：Prompt 缺少强约束，允许模型在“无证据、不确定”时硬答（核心可控）；
2. 次高：RAG 召回质量问题（切分不合理、过滤不到位、上下文拼接杂乱），给模型喂了无关“脏数据”，导致误导性幻觉；
3. 长期因素：模型本身能力边界（尤其本地小模型），属于原生短板，但占比最低。

核心优化思路（不换模型）：把“模型自由生成”，改成“检索/工具可验证 + 受控生成”，用工程手段兜底，减少模型主观臆测空间。

二、工程层面（不换模型）：系统性降低幻觉

方案1：Prompt 强约束（最立竿见影，零成本落地）

给 Prompt 增加防幻觉硬指令，强制模型：

• 仅基于提供的 RAG 上下文（question_answer_context）和工具返回结果作答，严禁杜撰数据、接口、业务规则；
• 若上下文不足、无相关证据，必须直接回复“缺少证据，需补充信息”，拒绝“硬答”；
• 输出格式化要求：必须引用 RAG 文档关键句或工具返回片段，标注来源，确保每一个结论都有依据。✅ 好处：立刻降低“张口就来”的幻觉，代价可控（轻微增加拒答率，对企业系统更安全）。

方案2：RAG 全链路降噪（根治“误导性幻觉”）

针对项目当前 RAG 直接拼接文档的问题，做4点优化（不换模型、不重构）：

• 限制 TopK 数量 + 文本截断：避免过多无关文档污染 Prompt，控制上下文长度；
• 增加相似度阈值过滤：低于阈值的检索结果直接丢弃，不注入大模型；
• 结构化注入上下文：给每段文档添加来源、标题标签，提升模型引用一致性，减少语义割裂；
• 优化检索策略：对用户问题做 query rewrite（改写），多轮检索提升召回准确率（适配你项目的 TokenTextSplitter，无需替换切分方式）。

方案3：工具可验证（用客观事实替代模型臆测）

幻觉的核心是“模型猜事实”，工程上把关键事实交给工具验证，不让模型主观判断：

• 需要业务状态、数据查询，直接调用 MCP 工具或查询 DB/接口，取返回结果作为依据；
• 需要文件、文档信息，走受控文件服务，不允许模型凭空编造；
• 总结阶段强制约束：最终答案只能基于工具返回或 RAG 证据生成，无依据不输出。

方案4：双阶段自检（Self-check，高风险场景必做）

不增加额外技术成本，仅通过多一轮 LLM 调用实现：

1. 第一阶段：生成初始答案；
2. 第二阶段：触发自检 Prompt，让模型自查“结论是否有证据支撑、是否与上下文冲突、是否存在编造内容”；
3. 若发现问题，自动重写修正；若无法修正，直接拒答。✅ 适合面试场景：体现“闭环思维”，大厂高风险场景（如故障分析、决策类任务）常用。

方案5：结构化输出 + 代码校验（解决“格式/参数幻觉”）

针对 Agent 流程执行场景，强制输出结构化格式（如 JSON），并在代码层做确定性校验：

• 定义固定字段、字段类型和范围，不通过校验则触发模型修正（repair loop）；
• 适配我项目的多步执行链路，减少“格式错乱、参数乱填”的幻觉，确保 Agent 执行可控。

总结

Agent 的幻觉不是纯模型问题，更多是工程上“缺证据仍允许输出”的可控问题。我会先用可观测手段定位：查看 RAG 命中文档相关性、答案是否引用上下文，再通过 RAG on/off 对比，区分是 RAG、Prompt 还是模型问题。

不换模型的话，我会按优先级做工程优化：第一，Prompt 强约束，只能基于检索和工具证据作答，不足则拒答；第二，RAG 侧做降噪，通过阈值过滤、结构化注入避免噪声；第三，把关键事实交给工具验证，再加上双阶段自检，最后用结构化校验兜底。结合我项目已有的 RAG 和工具基础，轻量升级就能显著降低幻觉率，兼顾效率和安全性。