大模型应用经常遇到一个问题模型会“编”。它可能编造一个不存在的事实也可能生成一条无法执行的 SQL甚至在工具调用失败后仍然一本正经地给出数据结论。在普通聊天场景中这类错误可能只是让人觉得回答不准确。但在企业场景中Agent 往往会接触数据库、知识库、业务系统和自动化工具。一旦模型把猜测当成事实影响的就不只是回答质量还可能包括错误的经营结论错误的数据口径越权访问对业务系统的误操作用户对系统可信度的下降。因此企业级 Agent 不能只依赖一句“请不要编造”的 Prompt。更可靠的思路是不要求模型永远不犯错而是让没有证据的内容无法顺利成为最终答案。一、先理解Agent 的幻觉不只是“说错话”在传统问答中幻觉通常指模型生成了不存在的事实。但在 Agent 系统中幻觉至少有三种表现。1. 内容幻觉这是最常见的一类。例如用户问本季度哪个产品的销量最高模型没有查询数据库却根据上下文猜了一个产品名称。回答可能非常流畅但没有任何真实数据支撑。2. 工具幻觉模型知道自己应该调用工具却调用错了。例如使用不存在的工具填错工具参数查询不存在的表或字段使用了错误的数据库语法把查询失败理解为“没有数据”。这种问题比普通内容幻觉更隐蔽因为系统表面上“调用了工具”但工具并没有返回有效证据。3. 行动幻觉模型不仅说错了还准备执行错误操作。例如生成破坏性 SQL请求超出权限范围的数据修改不应该修改的业务状态声称已经生成文件但实际上没有声称任务已经执行成功但后台任务早已失败。因此企业 Agent 的防幻觉设计不能只检查模型说了什么还要检查它调用了什么工具是否成功是否获得了真实证据最终回答是否与证据一致它有没有执行不被允许的动作。二、为什么仅靠 Prompt 不够最简单的防幻觉方式是在系统 Prompt 中写入规则不要编造数据。 涉及数据库的问题必须调用查询工具。 知识库没有返回结果时不要自行补充答案。 工具调用失败时应明确告知用户。这些规则当然有用。它们可以告诉模型应该怎么做减少明显错误也能让模型在多数正常请求中表现得更稳定。但 Prompt 本质上仍然是一种软约束。模型可能因为上下文过长、指令冲突、工具描述不清晰等原因忽略规则。用户也可能通过特殊输入诱导模型绕过限制。更重要的是Prompt 只能告诉模型“不要做什么”却无法真正阻止错误行为发生。可以把 Prompt 理解成一块警示牌前方危险请勿通行。它可以提醒驾驶员但不能代替真正的护栏。因此一个可靠的 Agent 系统通常需要建立多层防线用户问题 ↓ 输入澄清 ↓ 受约束的工具调用 ↓ 真实数据或文档证据 ↓ 证据门控 ↓ 安全的最终回答 ↓ 离线评测与持续回归三、第一层信息不够时先澄清而不是猜很多幻觉并不是模型缺少知识而是用户的问题本身不完整。例如帮我分析一下销售情况。这个问题至少缺少以下信息分析哪个时间范围看哪个区域关注销售额、销量还是增长率分析全部产品还是某个产品是否需要与上期进行比较如果 Agent 直接开始查询它只能自行补全这些条件。而模型自动补全的条件很可能和用户真实意图不同。即使最终数据完全准确回答也可能是在解决错误的问题。因此企业 Agent 的第一道防线不是查数据而是判断当前信息是否足够。比较合理的流程是理解用户问题 ↓ 检查关键参数是否齐全 ↓ 不齐全向用户澄清 ↓ 齐全生成执行计划 ↓ 调用工具例如你希望分析哪个时间范围主要关注销售额、销量还是增长率这看起来只是交互设计实际上也是一种防幻觉机制不清楚就问不要靠猜。当然也不能每个问题都反复询问。对于低风险、容易推断的条件可以使用明确标注的默认值对于会显著改变结果的关键条件则应该要求用户确认。四、第二层让事实问题必须经过工具如果问题涉及实时数据、企业数据或内部知识就不应该让模型依靠参数记忆直接回答。例如用户问本月订单量最高的地区是什么理想流程不是让大模型预测答案而是用户提出问题 ↓ Agent识别为数据查询 ↓ 生成查询参数或SQL ↓ 调用只读查询工具 ↓ 数据库返回真实结果 ↓ 模型根据结果生成解释这样大模型的职责从“记住答案”变成了理解问题选择工具生成查询解释查询结果。事实本身则来自外部工具。同样的原则也适用于知识库用户询问企业制度 ↓ Agent调用知识检索工具 ↓ 返回相关文档片段 ↓ 模型根据片段组织回答这类设计通常被称为 Grounding也就是让回答“落在证据上”。但需要注意调用了工具不等于已经获得可靠证据。工具可能连接失败、查询报错也可能返回空结果。因此仅仅要求模型调用工具仍然不够。五、第三层工具必须有硬约束如果模型能够自由生成并执行任意操作风险会非常高。以数据库查询为例至少应该设置以下限制。1. 强制只读数据分析 Agent 通常只需要查询不应该拥有修改数据的能力。可以只允许SELECT WITH SHOW DESCRIBE EXPLAIN并拒绝INSERT UPDATE DELETE DROP ALTER TRUNCATE这个限制不能只写在 Prompt 中而应该由后端代码检查。即使模型生成了危险语句执行层也必须拒绝。2. 限制允许访问的对象除了只读还可以增加表白名单字段白名单数据源权限最大返回行数查询超时并发限制。这样可以减少模型误查敏感信息或生成超大查询的风险。3. 使用结构化参数对于高频、固定口径的业务查询最好不要让模型每次自由生成 SQL。可以将常用查询封装成受治理的函数{ function: query_summary, arguments: { time_range: current_month, group_by: region } }模型只负责选择函数和填写参数真正的查询逻辑由后端模板生成。这种方式有几个优势业务口径固定参数范围可校验SQL更容易测试权限更容易管理模型不容易漏掉关键条件。自由生成 SQL 可以保留给探索性查询而固定报表和核心指标更适合使用受治理模板。六、第四层没有成功证据就不允许给出结论这是整个防幻觉体系中非常重要的一道硬门。想象下面的场景用户询问一个数据问题Agent正确调用了查询工具数据库连接超时工具返回错误模型根据之前的上下文生成了一个“可能的答案”。从对话体验看模型没有卡住甚至回答得很流畅。但这恰恰是最危险的情况。因此可以在最终回答之前增加一个 Evidence Gate也就是证据门。它不判断模型回答写得好不好只检查是否调用了预期工具工具是否真正执行成功是否返回了有效结果当前结论是否拥有可追溯证据。流程可以简化为if evidence.is_successful: allow_final_answer() else: return safe_message()安全提示可以是本次查询没有获得有效结果因此暂时无法给出可靠结论。你可以稍后重试或检查数据源连接状态。这条规则的核心是没有证据不准输出数据结论。它与 Prompt 中的“请不要编造”有本质区别。Prompt 是让模型自觉遵守规则Evidence Gate 是系统在模型之外检查条件。即使模型想继续回答最终输出也会被拦截。七、第五层工具失败必须显式返回工具调用失败后系统通常有两种错误处理方式。第一种是直接抛出异常整次请求结束。第二种是把错误转换成结构化消息再交给 Agent 判断是否能够修正。例如数据库提示Column not found系统可以将错误明确返回给 Agent{ tool: data_query, status: failed, error_type: invalid_column, message: The requested column does not exist. }Agent看到错误后可以查询表结构修正字段名称重新生成查询如果仍然失败则明确告诉用户。关键是不能把以下三种状态混在一起查询成功但结果为空 查询执行失败 没有执行查询它们的含义完全不同。如果系统只返回一个空字符串模型可能把“执行失败”理解成“没有数据”进而生成错误结论。因此工具结果应该包含明确状态{ status: success | empty | failed, data: [], error: null }清晰的错误语义本身就是防幻觉设计的一部分。八、知识库回答也必须接受证据约束接入 RAG 后系统并不会自动变得可靠。常见问题包括没有选择知识库检索没有找到相关内容找到的片段与问题无关文档版本已经过期模型在检索结果之外补充内容。因此知识库工具至少需要区分success找到可用内容 empty没有找到相关内容 no_selection尚未选择知识库 failed检索过程失败只有在成功获得相关内容时模型才能声称根据知识库中的资料……如果检索结果为空正确回答应该是当前知识库中没有找到足够的信息。而不是继续利用模型参数中的常识把内容包装成“知识库结论”。更进一步回答中还可以保留可追溯信息文档名称章节或片段标识文档版本引用位置。这样当回答出现争议时用户可以回到原始资料进行核对。九、固定业务口径不要交给模型自由发挥企业数据中很多指标并不是简单的字段求和。例如“有效订单”“活跃用户”“目标完成率”等概念背后可能包含一组固定规则。如果每次都让模型自由生成查询它可能漏掉过滤条件使用错误时间窗口选择错误字段按不允许的维度分组修改固定业务条件。因此稳定的业务口径更适合封装为受治理模板。可以把职责分成两部分模型负责识别用户意图选择正确模板提取时间、区域等参数对结果进行自然语言解释。代码负责固定指标定义校验参数范围生成查询执行权限检查返回结构化结果。这体现了一个重要原则让模型处理模糊性让代码处理确定性。自然语言理解存在模糊性适合交给模型业务公式、权限和安全规则具有确定性更适合由代码控制。十、运行时防护之外还要持续评测即使已经建立多层防线系统仍然可能因为模型升级、Prompt修改或工具变更而出现能力回退。因此防幻觉不能只依赖运行时设计还要建立持续评测。一个面向企业数据 Agent 的评测体系可以覆盖以下方面。1. 数据查询准确性不要只比较生成的 SQL 字符串。同一个问题可能有多种正确 SQL更合理的方式是比较最终执行结果是否一致。2. 安全拦截能力构造危险或越权请求检查系统是否真的阻止了操作而不是只看模型有没有说“我不能执行”。3. 工具路由能力检查 Agent 是否选择了正确工具以及参数是否填写正确。4. 结论忠实度检查最终回答中的数字和结论是否能够在工具返回结果中找到依据。5. 异常处理能力主动模拟数据库超时字段不存在知识库为空工具返回格式错误权限不足。然后检查 Agent 是否会承认失败而不是继续编造。评测不应该只在上线前运行一次。更理想的流程是修改Prompt或工具 ↓ 运行固定评测集 ↓ 生成本次得分 ↓ 与历史版本比较 ↓ 发现回退则阻止发布这样评测就不只是评价模型而是成为防幻觉体系的一部分。十一、五层防线总结可以把整套方法总结成五层。层级核心问题主要措施输入层用户的问题是否足够明确澄清关键条件工具层模型是否通过真实系统获取事实SQL、知识检索、业务函数约束层模型能否执行危险或越权操作只读、白名单、参数校验证据层最终结论是否有成功证据Evidence Gate、引用溯源评测层系统升级后是否重新出现幻觉固定数据集、回归评测它们并不是互相替代的。Prompt写得再详细也代替不了后端权限校验工具限制得再严格也代替不了最终证据检查运行时防护再完善也代替不了长期回归评测。十二、普通开发者可以先做什么如果正在开发一个 Agent不一定要一开始就建设非常复杂的平台。可以先完成下面五件事为每个工具定义明确的成功、空结果和失败状态对数据库和外部操作增加代码级权限限制要求事实性回答必须来自工具结果工具没有成功时禁止输出确定性结论保存一批典型问题修改系统后重复运行。这五项的成本并不高却能明显提升系统可靠性。总结企业级 Agent 无法仅靠一句“不要编造”解决幻觉问题。更有效的做法是把防幻觉从模型要求变成系统约束信息不完整时先澄清事实问题必须调用工具工具只能在受控范围内执行错误状态必须明确返回没有成功证据就不能输出结论固定业务口径由代码治理系统变更后持续进行回归评测。最终目标并不是让模型永远不出错——这在现阶段并不现实。真正可行的目标是让模型的错误能够被发现、被限制并且无法在没有证据的情况下变成最终业务结论。一个可信的 Agent不是因为它从不犯错而是因为系统已经为它犯错做好了准备。