大模型幻觉在 Agent 服务化中会带来哪些问题，如何治理？｜阿里巴巴后端开发面经解析

60 秒回答模板

Agent 服务化后，幻觉不只是回答不准确，而可能变成错误工具调用、伪造执行结果、误改业务状态、越权访问或给用户虚假确认。因此治理要从服务操作控制入手。首先把 Agent 输出分成自然语言、计划、工具参数和最终动作，所有可执行部分必须经过 schema 校验、权限校验、业务规则校验和风险分级；其次对高风险操作采用 dry-run、用户确认、人工审批或只生成草稿；再次要求工具调用结果只能来自真实系统回执，模型不能自己声称已完成。服务层要有工具 allowlist、幂等、超时、回滚、审计日志、异常降级和人工接管。上线后用 badcase、告警和事故复盘优化工具描述、校验规则、评测集和权限边界。

考点 Agent 服务化的幻觉风险会从错误

难度 真实面经题

回答目标 治理 Agent 服务化幻觉风险

深入解析

服务化放大幻觉后果

聊天场景的幻觉主要是错误信息，Agent 服务化后会连接工具、数据库和业务流程，幻觉可能导致错误查询、误发消息、误删数据、错误下单或虚假执行确认。因此回答要把幻觉放到可执行系统里分析。

可执行内容必须校验

Agent 生成的工具名称、参数、目标对象、操作类型和理由都不能直接执行。服务层要做 schema 校验、枚举校验、权限校验、业务规则校验和风险分级，参数不完整或不可信时要拒绝、澄清或进入人工确认。

工具结果不能由模型伪造

模型可能声称已经完成某操作或编造系统返回。生产系统必须把工具调用和回执作为事实来源，最终状态以数据库、交易系统或第三方接口返回为准。面向用户的确认文案也应引用真实执行状态，而不是模型自由生成。

高风险动作先 dry-run

对于删除、支付、发布、发消息、改权限等高风险动作，Agent 可以先生成计划或 dry-run 结果，展示影响范围和风险，再由用户确认或人工审批。能撤销的动作和不能撤销的动作要有不同自动化等级。

服务层要有治理机制

治理不只靠 Prompt。还要有工具 allowlist、最小权限、速率限制、幂等键、超时重试上限、回滚或补偿、熔断、降级、审计日志和人工接管。模型输出异常时，服务应保守失败，而不是冒险执行。

用事故闭环降低复发

线上要收集幻觉导致的工具错误、用户投诉、虚假确认、权限拦截和人工接管样本，分类到提示词不清、工具描述歧义、权限设计不足、校验缺失或模型能力不足，再更新评测集和服务规则。

易错点

把答案写成泛泛的幻觉治理，只说 RAG、Prompt 和微调。
没有说明服务化后幻觉会影响工具调用和业务状态。
让模型生成的工具参数直接执行，缺少 schema 和权限校验。
允许模型自行宣称操作成功，不校验真实系统回执。
高风险操作没有 dry-run、用户确认或人工审批。
没有审计、告警、人工接管和事故复盘闭环。

面试官追问

Agent 伪造工具执行成功时，系统如何发现？

聊天幻觉主要影响答案可信度；Agent 幻觉可能触发错误工具、错误状态写入、越权操作、错误通知和错误承诺，因此需要把治理放在操作链路和权限控制上。

哪些操作必须要求用户确认，哪些可以自动执行？

例如编造订单已完成、调用不存在的工具、把查询结果当执行成功、用错误参数发起操作、伪造外部系统返回、或承诺已经通知用户。这些都会造成生产事故。

Prompt 约束和服务层校验分别解决什么问题？

通过工具白名单、schema 校验、参数范围检查、权限校验、状态机、dry-run、结果回读和人工确认。模型只能提出意图或候选动作，关键执行由系统规则拦截。

如何设计 Agent 工具的权限边界？

涉及资金、权限、删除、外部通知、不可逆写操作、合规风险和高置信承诺的动作都应确认。低风险查询和草稿生成可以自动执行，但仍要记录证据。

幻觉导致错误操作后，日志需要支持哪些追责信息？

记录模型输入输出、工具选择、参数、权限判断、外部返回、状态变化、用户确认、失败重试和最终结果。这样能判断事故来自模型、工具、权限还是状态同步。

Agent 服务化中的 dry-run 应该展示哪些内容？

把事故样本加入评测集，标注幻觉类型和影响级别；修复工具 schema、权限策略、Prompt、RAG 证据、回读校验和流程兜底，再用回放验证不会复现。