AI 幻觉早已不是模型演示时的娱乐效果。当它出现在对话机器人、AI 客服、代码辅助工具、RAG 知识库问答和 Agent 自动执行链路里，一次看似合理的错误输出，可能直接变成错误决策、错误调用甚至安全事件。更值得警惕的趋势是：攻击者不再只依赖传统 prompt 注入去“撬开”系统，而是借助模型对虚构内容的高置信输出，把幻觉内容当作攻击载体。对于 AI 应用开发者和安全工程师来说，问题已经从“模型会不会编”升级为“模型编了之后系统会不会照做、怎么拦截、怎么兜底”。下面从幻觉的产生机制讲起，再分别在输入侧、输出侧、Agent 执行链三个位置给出防护思路，最后给出可量化的评测、排查和回归方法。
1. 先理解 AI 幻觉：为什么模型会一本正经地胡说八道
1.1 幻觉的通俗含义与技术定义
通俗地说，AI 幻觉就是模型生成了流畅、自信、但事实不成立的内容。它不是在说“我不知道”，而是在用和真实事实几乎相同的语气，给出一个不存在的数据、不存在的引用、不存在的函数参数或不存在的操作结果。
技术定义上，可以把幻觉理解为“生成内容与已知事实、用户提供证据或真实世界状态不一致”。在学术讨论中还会进一步区分“事实性幻觉”和“忠实性幻觉”：前者指模型输出与客观事实不符，后者指模型输出与用户给定的上下文或任务意图不符。对工程团队来说，这两类问题都需要处理，但处理方式不同。
事实性幻觉常见于通用问答、法律、医疗、金融等依赖外部事实的场景；忠实性幻觉常见于 RAG 知识库问答、文档摘要和 Agent 工具调用场景。做防护设计时，应把这两类分开评估，因为前者的兜底手段往往是外部知识校验，后者的兜底手段往往是上下文约束和执行前验证。
1.2 从生成机制看幻觉产生的四个常见原因
从大模型的工作机制看，幻觉很难被单一原因解释清楚，常见原因可以归纳为四类。
第一，训练目标侧重流畅性而非事实性。语言模型在预训练阶段学习的是词与词之间的条件概率分布，目标是预测下一个 token，而不是维护一个可查询的事实数据库。这个机制决定了模型天然会把“常见但未必正确”的表达方式当作优先输出。
第二，解码策略会放大高置信错误。即使模型对某个错误 token 的置信度只有 0.3，如果采样过程中其他候选更低，这个错误 token 仍然可能被选中。低温或贪心解码可以减少随机性，但不能消除概率分布本身对错误表达的偏好。
第三，上下文缺失或上下文冲突。如果用户输入的问题超出模型已学知识，或者检索到的文档本身互相矛盾，模型会在无法确定真相的情况下强行生成一个“看起来合理”的回答。
第四，检索错误被当成了事实。RAG 场景里，如果召回片段与问题不相关、切片切断了重要信息，或者排序模型把错误文档排在前面，模型会把该错误文档中的内容当作“证据”输出。这时候错误源头不在生成模型，而在检索链路。
1.3 安全视角：为什么一句胡编会升级成一条攻击路径
在安全视角下，问题不在于模型“说了错话”，而在于系统“默认相信了这句错话”。多数 LLM 应用的设计链路是：模型输出 -> 业务逻辑 -> 用户展示或工具执行。中间如果缺少事实校验和风险操作确认，幻觉输出就会直接从“文本错误”升级为“系统动作”。
这里要区分两类风险。一类是内容风险，比如 AI 客服把不存在的退款政策告诉用户，AI 编程工具生成存在安全缺陷的代码，AI 产品经理把虚构的竞品数据写入分析报告。另一类是执行风险，比如 Agent 根据模型生成的虚构参数调用了删除接口、发送了邮件或者触发了下游系统变更。对攻击者来说，后者更有价值，因为攻击面不再只是“让模型说错话”，而是“让模型替自己执行一个预设的错误动作”。
注意：这里提到的攻击利用模式，只用于防御侧识别和拦截，不涉及任何可利用的指令构造细节。安全意识的核心是知道系统在哪里可能被信任关系击穿，而不是学会怎么击穿它。
2. 防御侧要识别的三类幻觉滥用模式
2.1 虚假权威内容：把伪造引用包装成可信材料
第一类滥用发生在内容生成场景。模型的输出往往带有权威语气，当它捏造引用、法规、产品参数或论文出处时，读者很难仅凭文本判断真假。攻击者可以利用这种特性，批量生成带有虚假来源的误导性材料，用于舆情、客服欺骗或影响自动化审核系统。
从防御视角看，这类问题主要在输出侧拦截。生产系统必须能够区分“模型生成的文本”和“有依据的事实声明”。最简单的做法是要求模型在涉及具体数字、日期、人名、法规条款时输出证据编号，并在后端用检索结果或外部数据库校验。校验不通过时，宁可返回“无法确认”，也不要返回一段流畅的假话。
2.2 错误代码与配置建议：问题隐藏在 AI 编程工具里
第二类滥用与 AI 编程工具相关。模型在生成代码时可能给出结构完整、语义错误或存在安全问题的代码，比如绕过校验的 SQL 拼接、错误的正则、不安全的默认权限配置。攻击者可以通过精心构造的提示词，让助手在项目上下文中生成带有明显缺陷的补丁。如果开发者过度信任代码助手，不做 review 和静态扫描，这份缺陷代码就会进入仓库。
防御要点有两层。第一层是在开发流程上建立强制门禁，AI 生成的代码与手写代码走同样的审查、静态扫描和测试流水线。第二层是在 IDE 插件或 CI 侧识别“来自代码助手的变更”，提高审查优先级。不要因为代码来自“AI 助手”就默认它经过了质量保证。
2.3 自动执行链中的越权动作：伪造参数触发工具调用
第三类滥用最危险，发生在 Agent 场景。Agent 的核心特征是“模型输出会触发工具执行”，模型在 planning 时生成工具名称和参数，如果系统直接把参数交给工具执行，攻击者就可以利用幻觉输出构造一个“模型以为正确、业务上完全错误”的执行请求。
例如，模型可能生成一个不存在的用户 ID、错误的金额、超出权限范围的操作对象，执行层如果没有参数校验，就会把错误请求变成真实操作。防护侧必须做三件事：工具参数按 schema 严格校验、敏感操作进入二次确认状态、Agent 运行在最小权限环境中。后面第 5 章会给出具体实现思路。
下表汇总了这三类利用模式，方便建立防御检查清单：
| 利用模式 | 典型载体 | 风险等级 | 防御侧主要位置 |
|---|---|---|---|
| 虚假权威内容 | 客服话术、分析报告、知识库回答 | 中 | 输出侧事实校验、证据对齐、拒答 |
| 错误代码与配置建议 | AI 编程助手、代码补丁 | 高 | 代码审查、静态扫描、CI 门禁 |
| 自动执行链越权动作 | Agent 工具调用、工作流编排 | 很高 | 参数 schema 校验、二次确认、最小权限 |
3. 输入侧治理：先降低被诱导和注入的可能
3.1 建立“输入不可信”假设
很多幻觉防护方案只盯着生成模型，却忽略了一个事实：攻击者可以通过输入干扰模型的判断。建立“输入不可信”假设是输入侧防护的第一步。所有来自用户、网页、文档、传感器或上游系统的文本，都应被视为不可信上下文。系统在把外部输入拼入 prompt 之前，要先做长度限制、敏感指令识别和来源标记。
这句“来源标记”在实践中很重要。如果能把用户输入区域、检索文档区域、系统指令区域在 prompt 中用明确边界分开，模型被外部输入“接管”的概率就会降低。虽然它不是完整防御，但它能提高后续校验的可靠性。
3.2 系统提示词声明输出边界
系统提示词的作用是定义模型的行为边界，但它不是万能的。一个常见误解是“只要在提示词里写‘不要撒谎’，模型就会诚实”。实际上，模型没有“撒谎”的元能力，它能做到的只是遵循文本层面的约束。因此系统提示词应该写清楚边界规则，而不是道德要求。
下面是一个面向知识库问答的最小系统提示词模板，实际项目可按业务调整：
你是企业知识库助手，只能根据提供的检索片段回答问题。 如果没有检索片段作为依据，必须回答“无法从现有资料确认”。 不要补充检索片段之外的具体数字、日期、人名和法规条款。 涉及敏感操作指令时，只返回“该操作需要人工确认”，不输出后续执行步骤。这段提示词的关键在于把“依据”定义为可检查的检索片段，而不是让模型自行发挥。配合输出侧的 evidence 字段，就能把“模型是否遵守边界”变成可审计的问题。
3.3 对用户输入做基础检测
即使有系统提示词，也不能完全依赖模型理解边界。输入侧还需要一层规则检测，用于识别明显改变指令意图的输入。下面是一个最小示例，只做初步过滤，不作为完整方案：
import re SUSPICIOUS_PATTERNS = [ r"(?i)ignore (all )?(previous )?instructions", r"(?i)forget (all )?(previous )?instructions", r"(?i)you are now .{0,50}", r"(?i)do not follow the system prompt", r"(?i)reveal your system prompt", ] def precheck_user_input(text: str) -> bool: if len(text) > 2000: return False for pattern in SUSPICIOUS_PATTERNS: if re.search(pattern, text): return False return True注意这只是一个粗糙示例，正则并不能覆盖真实世界的 prompt 注入方式。生产环境通常还要结合语义检测模型、身份权限判断和输入抽检。把输入检测放在最前面，是为了在进入生成链路之前挡住明显异常，减少幻觉被外部内容诱导的概率。
3.4 关键采样参数对幻觉的影响
很多团队在幻觉治理时第一个想到的是调参数，但参数只能改变采样分布，不能改变模型本身的事实判断能力。下面整理常见参数及其影响：
| 参数 | 作用 | 对幻觉的影响 | 推荐做法 |
|---|---|---|---|
| temperature | 控制采样随机性 | 越高越容易发散，但设为 0 不保证事实正确 | 事实型场景用 0.1-0.3，不要依赖 0 防幻觉 |
| top_p | 截断概率累计候选 | 调低会收敛输出空间，但同样不保证正确性 | 与 temperature 配合，保持稳定即可 |
| max_tokens | 限制最大输出长度 | 过长输出可能脱离依据继续发挥 | 按任务设置合理上限，超限就是信号 |
| frequency_penalty | 惩罚已出现 token | 过高会迫使模型使用不常见词，可能增加不稳定输出 | 不为了“表达丰富”大幅调高 |
参数调整只能作为辅助。真正可靠的幻觉治理，必须放到输出侧和工具执行侧去解决。
4. 输出侧治理：把自信的假话变成可审计的真话或拒绝回答
4.1 强制结构化输出，保留校验字段
输出侧防护的第一步，是让模型输出结构化数据，而不是一段连续文本。结构化输出可以强制模型填写answer、confidence、evidence_ids、unsupported等字段，后端再针对这些字段做校验。
{ "answer": "本市 2025 年公积金缴存比例上限以当地最新通知为准", "confidence": 0.62, "evidence_ids": ["doc_001", "doc_002"], "unsupported": false }这里要说明两个容易误解的地方。第一，confidence字段是模型自己给出的，它反映的是模型内部概率感，并不是事实置信度，不能作为唯一依据。第二，evidence_ids必须由后端根据检索结果映射，不能只信任模型输出的字符串。结构化的价值在于让校验逻辑有明确的输入，而不是让校验逻辑去解析自由文本。
注意：
confidence字段代表模型的内部概率感，不代表事实置信度。任何情况下都不能把它当作“回答正确”的充分条件。
4.2 RAG 场景做引用对齐
在 RAG 场景，最有效的幻觉治理手段之一是“答案必须能在检索片段里找到依据”。具体做法是先让模型答题，再把回答拆成句子，与检索片段做相似度或实体对齐，低于阈值的句子视为未被证据支持。
def verify_evidence(answer: str, evidence_chunks: list[dict], threshold: float = 0.6) -> bool: answer_sentences = [s.strip() for s in answer.split("。") if len(s.strip()) >= 8] for sentence in answer_sentences: best_score = 0.0 for chunk in evidence_chunks: score = compute_similarity(sentence, chunk["text"]) best_score = max(best_score, score) if best_score < threshold: return False return Truecompute_similarity在实际项目中可以用 embedding 模型计算向量相似度，也可以结合实体抽取判断关键人物、时间、数字是否一致。这个函数只是说明思路，生产环境要补充更多细节，比如排除无信息量短句、处理口语转述、设置多阈值分级。
引用对齐不能只做一次。如果模型给出了多个证据编号，但证据内容互相冲突，校验也应该判定不通过。比较稳妥的方式是：证据冲突时直接拒答，而不是让模型“合并出一个答案”。
4.3 用独立校验器抽检关键内容
另一种输出侧手段是引入独立校验器。需要注意，独立校验器不一定是“另一个大模型”。在很多场景里，规则引擎、知识库检索、数据库查询比模型更可靠。
对于关键实体，可以用规则校验。比如回答中出现的金额、日期、电话、邮箱、工号，先用正则或实体识别抽取，再去权威数据源比对。比对不上的，标记为高风险。
如果确实要用大模型作为判官，需要避免三个问题：判官与生成模型使用同一套参数和 prompt 风格，容易继承相同的幻觉偏好；判官可能因为“讨好”倾向放过明显错误；判官本身也会被用户的诱导内容带偏。因此 LLM 判官的输出只能作为辅助信号，不能直接作为“事实正确”的结论。对判官判为“正确”的高风险问题，仍应抽样人工复核。
4.4 不满足条件时选择拒绝回答
输出侧最后一道关卡是拒绝回答。很多团队在设计 LLM 应用时只关注“回答质量”，却忽视了“有权利不回答”。当校验分数低于阈值、检索片段为空、用户问题涉及敏感操作时，系统应该返回固定话术，而不是让模型硬答。
if not verify_evidence(answer, chunks, threshold=0.6): return {"answer": "无法从现有资料确认，请补充有效依据后再提问。", "refuse": True}拒绝回答看似“能力变弱”，实际上是在保护系统可信度。对生产系统来说，一句诚实的“不能确认”远比一段流畅的虚构内容更有价值。拒答策略也可以分级别：完全无证据时拒答；有部分证据但置信度低时提示“请核实”；证据冲突时提示“资料存在矛盾”。
5. Agent 与工具调用侧：执行前必须过一道闸门
5.1 为什么 Agent 会放大幻觉
Agent 系统的风险在于“从文本决策到真实动作”的链路变短了。模型生成call_tool("send_email", {"to": "xxx", "body": "..."})，如果系统不理解to字段是否真实、body是否含有敏感内容就直接执行，幻觉就会从“文本错误”变成“系统事故”。
放大效应来自三个方面。第一，Agent 的 plan 由模型生成，错误 plan 会一路向下执行；第二，工具返回值会成为下一轮生成的上下文，错误返回值会继续污染后续决策；第三，长链路中每一步的错误都在累计，最后一步可能已经看不出最初的事实依赖。因此必须在工具调用入口处拦截，而不是等 Agent 执行完再回顾。
5.2 工具调用网关模式
工具调用网关是 Agent 执行链路的“哨兵”。所有模型生成的工具调用，都先经过网关校验，再把通过校验的请求交给真实工具。网关至少要做四件事：工具名白名单、参数必填校验、参数类型校验、风险等级判断。
TOOL_SCHEMAS = { "send_email": { "required": ["to", "subject", "body"], "type_checks": {"to": str, "subject": str, "body": str}, "risk": "medium", }, "delete_project": { "required": ["project_id", "confirm_reason"], "type_checks": {"project_id": str, "confirm_reason": str}, "risk": "high", }, } def validate_tool_call(tool_name: str, arguments: dict) -> dict: schema = TOOL_SCHEMAS.get(tool_name) if not schema: return {"ok": False, "reason": "unknown_tool"} for field in schema["required"]: if field not in arguments or arguments[field] in (None, ""): return {"ok": False, "reason": f"missing_parameter:{field}"} expected_type = schema["type_checks"].get(field) if expected_type and not isinstance(arguments[field], expected_type): return {"ok": False, "reason": f"wrong_type:{field}"} if schema["risk"] == "high": return {"ok": True, "need_confirm": True} return {"ok": True, "need_confirm": False}这段示例的核心思想是：不要把模型输出直接当成“可信参数”，而是把工具调用当作外部 API 请求一样对待。真实系统还可以扩展枚举校验、范围校验、权限校验、频率限制和变量替换检查。
5.3 敏感操作二次确认
高风险的 Agent 操作必须进入确认状态。常见的做法是把工具调用变成状态机：PENDING -> APPROVED -> EXECUTED。模型生成调用后，系统先创建一条待确认记录，包含工具名、解析后的参数、调用来源和上下文快照，然后等待人工或授权系统确认。只有确认通过，才真正执行工具。
这段设计要解决的是“模型自信地说错”的场景。即使参数校验全部通过，业务语义也可能错误，二次确认给了决策者一个纠错机会。确认页面或接口需要展示“模型原始输出”和“解析后的结构化参数”，方便审查。
待确认操作：删除项目 demo-project 参数： project_id: demo-project confirm_reason: 用户要求清理测试环境 来源：Agent session-20250801-004 风险等级：高 确认方式：需要项目管理员批准生成这样的确认记录后，系统可以把它接入审批流或消息通知。没有确认状态的敏感操作，应该直接从工具白名单中移除。
注意：二次确认不能只确认“是否执行”，还要展示“模型原始输出”和“解析后的结构化参数”，否则审查者只能看到被模型美化后的结果。
5.4 权限收窄与沙箱隔离
Agent 权限应该是“按任务最小授权”，而不是“模型能调用什么就都给”。可以考虑给不同的对话场景配置不同的工具集合和权限范围：
| 场景 | 允许的工具 | 权限范围 | 是否需要确认 |
|---|---|---|---|
| 普通知识问答 | 检索、文档读取 | 只读 | 否 |
| 数据分析 | 数据查询、报表生成 | 只读 + 临时计算资源 | 否 |
| 客服工单处理 | 创建工单、查询工单 | 业务账号最小权限 | 是（敏感字段脱敏） |
| 后台运维操作 | 部署、删除、改配置 | 独立运维账号，无生产写权限 | 是（必须审批） |
代码执行类 Agent 还应运行在沙箱容器中，限制网络、内存、磁盘和系统调用。即使模型生成了错误代码或攻击性命令，沙箱可以把影响范围限制在最小环境内。
6. 把幻觉从“感觉问题”变成“可量化指标”：评测与回归
6.1 构造幻觉评测集
幻觉治理不能靠人工上线前试几条问题。要建设一个可以重复运行、可以对比版本的评测集，让“幻觉变多还是变少”成为一个可量化数字。
评测集至少包含四类样本：
| 类型 | 说明 | 示例问题方向 |
|---|---|---|
| 事实型 | 答案可查证，依赖外部数据 | 某产品最新版本号、某法规实施日期 |
| 统计型 | 答案依赖明确数据，容易编造数字 | 某地区人口、某指标同比 |
| 时效型 | 答案随时间变化，模型旧知识容易过期 | 当前年份政策、最新 API 文档 |
| 反事实型 | 题干包含不可能前提，观察模型是否无条件接受 | “如果某接口返回空，是否还能确认成功” |
构造样本时，每一条都要记录：问题、期望答案或期望行为、提供的检索上下文、模型版本、评测标签。没有明确标签的问题不要放入评测集，否则判分结果会不稳定。
下面是一个最小评测样本的 JSON 示例：
[ { "id": "eval_001", "type": "factual", "question": "某产品最新版本号是多少？", "context": "该产品 3.2 版本于 2025 年发布。", "expected": "3.2" } ]6.2 用规则判分和 LLM 判官跑评测
评测打分可以采用“规则 + 判官”的组合。规则判分适合检查硬性错误，比如数字是否与给定上下文一致、是否出现不应出现的名词。LLM 判官适合评价答案与问题的相关性和忠实度，但需要先校准。
下面是一个最小评测脚本，重点展示流程而不是完整实现：
def evaluate_hallucination(dataset): total = len(dataset) hallucinated = 0 for item in dataset: answer = call_model(item["question"], item.get("context", "")) label = judge_with_rules(item, answer) if label == "hallucination": hallucinated += 1 return { "tested": total, "hallucinated": hallucinated, "hallucination_rate": hallucinated / total if total else 0, }判分结果要区分“错误类型”，比如事实错误、依据缺失、答非所问、拒答不当。只统计一个整体错误率会掩盖问题。实际项目可以在 JSON 里输出错误分类明细。
6.3 把幻觉率加入 CI 门禁
评测集跑通后，下一步就是把结果变成发布门禁。每次提示词版本、模型版本、检索策略或后处理逻辑变更，都要重新跑评测，超过阈值就阻断发布。
result = evaluate_hallucination(dataset) if result["hallucination_rate"] > 0.03: raise SystemExit( f"hallucination rate {result['hallucination_rate']:.2%} exceeds 3%, block release" )命令行运行方式可以按项目情况设计，例如：
python evaluate_hallucination.py --dataset data/hallucination_eval.json --threshold 0.03阈值要按业务场景设定。客服、医疗、法律、金融场景应该更严格；内容生成、营销文案场景可以适当放宽，但必须设置上限。门禁只负责拦截明显劣化，不能替代持续监控。
6.4 线上监控与反馈闭环
门禁解决的是“发布前”，线上监控解决的是“发布后”。生产环境需要对每次模型输出做抽样记录，保存 prompt、检索片段、模型参数、输出结果和校验分数。当校验分数低于阈值或用户点了“答案有问题”时，把样本写回评测集，形成事实库。
线上监控还要关注“幻觉率随时间的漂移”。外部知识在变化，模型输出分布也会变化。建议按周或按版本对比幻觉率，发现异常时回看链路上哪一层发生了变化，动态调整阈值。
7. 幻觉安全问题的排查链路与常见坑
7.1 排查链路：从现象倒推到根因
遇到“AI 回答看起来很专业但内容完全错误”的线上问题，建议按以下链路排查，不要一上来就怀疑模型本身。
先确定一下问题现象：是数字错误、引用不存在，还是触发了不该触发的操作。然后按以下顺序定位：
- 复现同一问题，记录完整 prompt 和上下文，确认不是偶发抖动。
- 检查用户输入是否包含诱导性内容，是否绕过了输入检测。
- 若是 RAG 场景，检查检索命中的文档、切分方式、排序分数，确认证据是否真实相关。
- 检查系统提示词边界，确认模型是否被允许“自由发挥”关键内容。
- 对比模型版本和采样参数，确定是否有版本升级或参数调整。
- 检查输出侧校验逻辑，确认
evidence对齐、拒答策略是否生效。 - 若是 Agent 场景，检查工具调用网关日志，确认参数校验、二次确认是否被跳过。
每一步都要有日志。没有日志的场景，排错会变成猜谜。建议在链路起始就记录 request_id，把所有阶段日志串起来。
grep "request_id=20250801-004" app.log | head -507.2 常见坑：这些做法并不能真正防住幻觉
| 错误做法 | 为什么没用 | 推荐做法 |
|---|---|---|
| 把 temperature 调到 0 防幻觉 | 低温度只降低多样性，不纠正事实性错误 | 把温度稳定在 0.1-0.3，事实校验交给后处理 |
| 提示词写“不要撒谎” | 模型没有“是否撒谎”的元能力 | 用依据来源、拒答规则和字段约束定义行为 |
| 让模型“引用来源”但不验证 | 模型可能生成不存在的引用 | 引用编号必须映射到真实检索片段，校验后再展示 |
| 用同一个模型既生成又判分 | 判官会继承相同的偏好和错误模式 | 独立判官 + 规则校验 + 高风险问题人工复核 |
| Agent 拿到参数直接执行 | 模型输出是概率采样，不是可信业务参数 | 工具 schema 校验、风险分级、二次确认 |
| 只测正常问题不测诱导问题 | 攻击者不会按正常问题路径走 | 评测集加入对抗样本、越权样本、矛盾上下文样本 |
这些坑在真实项目中非常常见，而且往往不是单个因素导致，而是多个环节都没有防护，最终叠加成一次严重事故。
7.3 上线前防御清单
在发布一个 LLM 应用之前，可以按这份清单逐项检查：
- 是否对用户输入做不可信假设，并配置输入检测。
- 系统提示词是否明确输出边界、依据来源和拒答规则。
- 关键数字、日期、人名、法规是否走外部校验。
- RAG 场景是否有引用对齐校验，证据冲突时是否拒答。
- 工具调用是否经过 schema 校验，是否有风险分级。
- 敏感操作是否进入二次确认，是否记录确认人。
- Agent 运行环境是否最小权限，代码执行是否沙箱隔离。
- 是否建设幻觉评测集，幻觉率是否进入 CI 门禁。
- 线上是否有全链路日志，是否保存 prompt、检索、输出快照。
- 是否有线上抽检和用户反馈回写评测集的通道。
这份清单适用于大多数对话、RAG 和 Agent 场景。不同业务可以根据风险等级增加审查项，比如金融场景增加金额一致性校验，医疗场景增加专业术语复核。
从一线实践看，AI 幻觉治理最核心的一步是改变团队认知：不要把幻觉当成“模型偶尔犯傻”，而是当成“系统缺少事实校验能力的必然表现”。一个值得投入的方向，是把幻觉评测和工具调用网关做成 AI 应用的公共组件，而不是每个项目临时拼凑。下一步可以从 RAG 检索质量评估、Agent 可观测性和提示词版本管理这几个方向继续深入。对新手来说，最有价值的练习是拿一个小型知识库 QA 项目，把输入检测、引用对齐、拒答逻辑、评测集和 CI 门禁完整跑一遍，再用诱导输入验证一次，很快就能理解幻觉风险是如何被系统性地放大的。
