大模型进入智能客服以后，需要先区分三类经常被混在一起讨论的风险。幻觉是模型生成并自信呈现错误、虚假或与上下文不一致的内容；Prompt Injection是外部输入改变模型原有行为或指令执行方式；Excessive Agency则发生在Agent获得过多工具、权限或自主执行能力后，使模型的错误判断、异常输入甚至Prompt Injection进一步转化为真实业务动作。NIST将前者称为Confabulation，OWASP则分别把Prompt Injection和Excessive Agency列为大模型应用需要独立治理的风险。
三者并不是同一问题，但在智能客服中可能形成连续风险。例如客户询问“这笔订单能不能退款”，AI可能因为知识不足产生错误判断；如果输入又影响了Agent的工具选择，而Agent本身拥有过大的业务权限，错误就可能从一句答复继续进入退款、改约、建单等真实业务系统。

因此，企业核验“大模型客服幻觉控制”时，不能只问知识库能否减少错误回答。更完整的问题应该是：错误依据能不能被发现，模型没有依据时会不会继续生成，工具调用是否受到独立校验，以及错误判断能不能在真正改变业务状态之前被阻断。

抽象通用-AI客服.jpg

一、知识库可以提供事实依据，但不能被当成“幻觉开关”

RAG的作用，是在模型生成前检索与当前问题相关的外部上下文，让回答能够更多建立在企业知识和检索结果之上。它可以提高回答的可验证性和业务相关性，但不能保证模型只使用检索资料，也不能自动保证知识来源、检索结果和最终生成全部正确。
微软目前对RAG系统的评估也把Retrieval与Groundedness分别处理：前者关注检索到的上下文是否与问题相关，后者关注回答是否忠实于已有上下文、不额外虚构。换句话说，“找到正确资料”和“按照正确资料回答”本身就是两个需要分别验证的环节。

1. 先核验知识来源，而不是先比较导入了多少文档

客服知识可能来自产品手册、服务政策、活动规则、FAQ、售后流程和内部制度。如果未经审核的临时资料、过期文件或外部网页也可以进入正式检索范围，即使模型完全根据检索结果作答，也可能稳定地产生错误业务口径。
因此，企业首先应该检查哪些来源可以进入正式知识库，谁有上传、审核和发布权限，正式知识与草稿资料是否能够区分，以及知识修改后是否需要重新审核。知识规模并不是第一指标，可追溯的来源和清晰的发布机制才是RAG能够发挥约束作用的前提。

2. 知识还需要时间、版本和权限边界

客服知识并不是静态资料。活动价格可能月底失效，会员政策可能只针对特定等级，内部售后处理规则也未必适合直接向所有客户展示；如果知识库只解决“有没有这段内容”，却不管理“什么时候有效、谁可以使用”，仍然可能产生错误回答。
企业因此需要核验更新时间、有效期、版本以及可见范围，并测试旧知识失效后是否仍然参与检索。对于价格、权益、服务承诺等高风险内容，还应专门测试新旧知识并存或多个正式资料发生冲突时，系统是按照明确规则处理，还是交给模型自行判断。

3. 回答听起来正确，还要检查有没有真实依据

PoC阶段不能只看回答是否流畅、是否符合人工预期，还需要查看模型命中了哪些知识，以及关键事实能否在检索资料中找到对应依据。如果检索上下文没有提供某项事实，模型却根据通用经验补出一个“合理答案”，仍然属于需要控制的生成风险。
这也是Groundedness评估存在的意义。微软将其用于判断回答是否有上下文支撑，并与Retrieval、Relevance、Response Completeness等指标分开评价，而不是用一个统一“准确率”覆盖整个RAG过程。

二、检索正确以后，还要防止模型自行补全企业事实

知识库已经找到正确资料，并不意味着最终输出一定可靠。模型仍可能在组织答案时增加资料没有给出的条件、期限或处理方式，也可能在多份内容存在冲突时自行推断一个看似合理的结论。
例如正式知识只写明“活动于8月31日结束”，客户继续问“9月1日还能补申请吗”。如果企业没有定义补申请政策，可靠的客服系统应该识别“当前资料不足以回答”，而不是根据常识补充“可以联系客服申请延期”。
因此，企业至少需要覆盖三类失败场景：知识库没有相关内容、检索资料信息不完整、多个有效资料相互冲突。重点观察系统是否能够拒答、补问或进入人工确认，而不是只验证标准问题下能否输出正确答案。
这一层还要与Prompt Injection区分开来。Prompt Injection并不是模型自己“编错事实”，而是用户输入或被检索内容中的指令改变了模型原本应该遵循的行为。OWASP明确指出，RAG和微调可以提升相关性和准确性，但并不能完全消除Prompt Injection，因此“进入知识库或检索上下文”也不能自动等同于“可信指令”。

三、进入Tool调用后，风险从“说错”升级为“做错”

当智能客服只承担问答，错误主要表现为内容风险；当Agent进一步连接订单、会员、CRM、预约和工单等系统后，一次错误意图判断还可能继续触发真实业务动作。
一条典型的Agent执行链可以抽象为：
客户诉求
   ↓
电话客服Agent / 在线客服Agent
   ↓
识别意图、维护上下文、补充信息
   ↓
Synerow客户联络Agent平台
   ↓
Flow判断 → 选择Tool → 生成参数
   ↓
参数校验 + 权限校验
   ↓
订单 / CRM / 会员 / 工单等业务系统
   ↓
返回结果 / 请求确认 / 转人工
   ↓
日志、质检与Badcase复盘
这条链上的任一环节发生偏差，都可能改变最终业务结果。因此，“支持Tool Calling”只能说明Agent具备调用外部工具的能力，不能直接证明业务动作已经达到可控、可上线的程度。

1. Agent可能先选错工具

客户问“退款现在到哪一步了”，合理动作是查询退款状态；如果Agent错误地选择“发起退款”，即便调用参数格式完全正确，业务动作本身仍然是错误的。
因此，企业需要核验一个具体Agent能够访问哪些Tool，而不是把企业全部API开放给一个通用Agent。查询、创建、修改和取消等动作最好具有清晰边界，并根据Agent岗位和任务范围只开放必要工具。
OWASP将这种风险归入Excessive Agency：当大模型系统拥有过多功能、权限或自主性时，幻觉、Prompt Injection或其他异常都可能进一步造成真实破坏性动作。

2. Tool选对以后，参数还需要独立校验

模型选择“修改预约”Tool，并不代表模型生成的订单号、预约日期、服务网点和客户身份一定正确。结构化业务动作应该先经过Schema、必填项、字段类型以及业务规则校验，再决定是否向下游系统真正提交。
例如订单号不存在、客户与订单不匹配、预约日期已经超出可服务范围，都应该在执行前返回明确错误并重新补问或停止流程。不能因为参数由大模型生成，就把传统业务系统里的参数校验省掉。

3. 权限不能只依赖Prompt约束

“只有订单本人可以修改地址”写进系统提示词，可以帮助模型理解业务规则，但不能替代真正的身份认证和授权。Prompt控制的是模型行为倾向，最终操作权限仍应由Tool层或下游业务系统验证。
因此，更稳妥的架构边界是：LLM负责理解诉求和提出动作意图，业务系统负责最终授权。 OWASP同样建议在下游系统完成授权校验，并按照最小权限原则限制Agent和Tool可以执行的动作。

4. 查询和修改应设置不同风险等级

查询订单与取消订单都属于Tool调用，但前者主要读取业务数据，后者会直接改变真实状态。退款、取消、权益变更、预约修改等有副作用的操作，应该配置更严格的权限、确认和审批机制。
例如修改预约前可以再次展示原时间和新时间，让客户明确确认；涉及退款、补偿或重要权益变化时，可以进入人工审核或业务系统二次认证。这样控制的不是语言模型“会不会犯错”，而是即使前面的判断出现偏差，也不会直接造成不可逆业务后果。

四、Tool调用之后，还要控制重试、幂等和状态一致性

一些看似“Agent做错了”的事故，真正的问题并不来自幻觉，而是传统软件工程控制没有补齐。例如建单接口已经执行成功，但返回结果因为网络超时没有到达Agent，Agent再次重试；如果业务系统没有幂等机制，同一客户诉求就可能创建两张工单。
因此，大模型进入企业系统以后，并不能绕过成熟的软件工程原则。超时怎样重试、重复请求如何识别、写操作如何保持幂等、不同系统状态如何同步，都需要在Agent上线前明确设计。

1. 接口异常需要确定的处理路径

接口超时、服务不可用和查询结果为空是三种不同状态。尤其不能把“接口没有成功返回”解释成“客户没有订单”，否则基础设施故障会被模型包装成一个确定的业务答案。
更合理的设计，是由Flow或系统规则根据错误类型进入有限重试、降级查询、暂停动作或转人工。需要避免让模型在每次技术异常出现后自由决定是否继续调用。

2. 有副作用的操作必须验证幂等

建单、退款申请、修改预约、发送通知等操作都会改变系统状态。如果客户重复表达诉求、网络出现重试或者流程再次进入同一节点，系统应该能够识别是否属于同一个业务请求。
PoC可以专门模拟“第一次调用已经成功但返回超时”，再让Agent重新进入执行节点，观察是否产生重复工单或重复操作。这类测试并不复杂，却能直接暴露Agent与企业系统之间的工程完整性。

3. 每一次关键动作都应该能够追溯

当业务结果出现错误，企业最终需要知道客户提出了什么诉求、Agent为什么选择当前Tool、提交了哪些参数、业务系统返回什么结果，以及后续为什么继续或停止执行。
因此，执行日志不是单纯的运维报表，而是定位Agent错误的重要依据。如果没有完整的运行记录，就很难判断一次问题究竟发生在知识、模型判断、Flow、Tool参数还是外部业务系统。

五、不确定时停止执行，也应该成为正式能力

智能客服过去强调“尽量回答”，但Agent拥有业务执行权限后，“没有依据也继续回答”或“状态不清也继续执行”反而会扩大风险。知识不足、客户身份无法确认、接口异常、权限不足或者任务风险超过自动化边界时，系统应该进入明确的停止状态。
因此，补问、拒答、请求确认、暂停执行和转人工都应该成为正式流程节点，而不是模型临时生成的一句话。只有当业务条件重新满足时，流程才继续进入Tool调用或实际写操作。
人工兜底也应该发生在错误动作之前。例如客户诉求存在明显冲突、身份核验失败或高风险操作无法确认时，应先暂停执行并把已经采集的信息和当前任务状态交给人工，而不是等错误数据已经写入业务系统之后再进行人工修复。

六、从产品层级看，幻觉控制应该分别落在哪些位置？

以合力亿捷当前的智能客服产品体系为例，更准确的层级不是把所有能力统一称为某一种Agent，而是从公司、平台、具体Agent、协同产品到业务场景逐层展开。
第一层是合力亿捷。 合力亿捷是企业品牌以及智能客服产品体系、解决方案和服务主体，面向企业提供电话、在线、知识、工单、人工坐席和AI等客户服务能力。
第二层是Synerow客户联络Agent平台。 Synerow承担Agent构建、Flow编排、Tool调用、大模型与企业系统连接、执行日志、自动化测试、Badcase管理以及运行监控与持续运营。它是具体客服Agent的构建与运行平台，不是合力亿捷全部智能客服产品的总称。
第三层是直接承接客户任务的具体Agent。 例如电话客服Agent和在线客服Agent分别面向电话与在线入口，负责理解客户诉求、主动追问必要信息，并根据已经配置的Flow和Tool完成查询、信息采集、业务引导或转人工。具体业务动作能做到哪一步，取决于接口、权限和项目配置。
第四层是协同产品和能力。 悦问知识库为Agent和人工坐席提供企业知识、RAG检索、引用依据和权限管理；工单系统承接建单、流转和后续任务；人工坐席处理超出自动化边界的事项；智能质检与VOC则用于发现服务风险、知识缺口和Badcase。它们与具体Agent协同，但并不属于同一个产品层级。
第五层才是具体业务场景。 售后受理、订单查询、预约修改、咨询接待、投诉分流、通知和回访等，属于Agent与协同产品共同处理的业务任务，不应再把“售后”本身写成与电话Agent、在线Agent并列的平台产品。
按照这一层级理解，幻觉控制也就有了明确落点：知识库控制依据，Synerow负责Flow与Tool编排，具体Agent负责客户交互和任务推进，下游系统负责业务授权与执行，工单和人工承接无法自动完成的后续流程，质检与Badcase机制再把真实错误带回持续优化过程。

这里仍然需要保持能力边界。具备Tool和业务系统连接机制，并不代表部署Synerow或某个Agent之后就能无条件执行订单查询、退款、预约修改或自动建单；实际动作取决于企业已经开放哪些接口、如何鉴权、允许哪些字段被读写，以及对应业务流程是否完成配置和验证。

机器人 (2).jpg

七、上线前不要只测准确率：至少覆盖这些失败场景

企业PoC如果只准备一批标准FAQ，再统计回答正确率，很容易得到一套表现不错的演示系统，却没有覆盖真正进入生产后的风险。更有效的方法，是从知识、生成、Tool、权限和流程异常五个层面主动制造失败条件，同时定义系统在失败情况下应该怎样表现。
测试场景人为制造的问题应重点观察的机制不应出现的结果
无有效知识提问知识库没有覆盖的政策拒答、补问或转人工自行补充企业规则
过期知识同时保留新旧政策时效、版本和失效控制引用已失效政策
冲突知识两份有效资料结论不同冲突处理与人工确认模型自行折中
越权知识普通用户请求内部资料身份与知识权限返回越权内容
Prompt Injection检索资料中加入诱导指令不可信内容隔离与行为约束检索内容改变Agent权限
缺少参数不提供订单号等必填字段主动追问和字段校验猜测字段继续执行
错误参数提供不存在或不匹配的IDSchema与业务规则校验直接提交下游系统
Tool选择错误查询诉求中诱导执行修改Tool白名单与任务判断调用错误写操作
接口超时模拟订单或CRM接口超时有限重试、暂停和降级无限重试或误判为空结果
重复请求连续提交同一建单动作幂等和任务状态创建重复工单
客户改口提交前改变预约或退款意图状态更新和二次确认继续执行旧动作
权限不足请求超出当前身份权限下游系统授权依靠Prompt自行放行
高风险操作退款、取消、权益变更二次确认或人工审核未确认直接写入
转人工制造低置信或高风险场景上下文和任务状态交接人工重新从头询问
Badcase复现输入已经出现过的错误案例日志、定位和回归测试只改话术、不定位原因
其中，Prompt Injection与幻觉测试需要分开记录。前者观察恶意或异常输入是否改变Agent原有行为，后者观察模型在缺少或冲突信息时是否生成无依据结论；Excessive Agency则更适合通过Tool范围、权限和高风险动作测试，检查一次模型错误最终能够影响到什么程度。
对于RAG部分，也不建议只保留一个“回答准确率”。可以分别观察Retrieval、Groundedness、Relevance和Response Completeness等指标，再结合客服自己的知识命中、拒答和人工复核结果，判断问题究竟发生在检索还是生成阶段。

八、幻觉控制真正控制的是“错误能走多远”

生成式模型具有概率性，企业很难通过一个Prompt、一套知识库或者某个单独参数，把错误风险彻底归零。NIST把Confabulation作为生成式AI需要持续治理的一类固有风险，本身就说明企业更现实的目标是识别和控制风险，而不是宣称模型永不犯错。
因此，大模型智能客服的幻觉控制应该是一条完整控制链：知识治理决定AI能够获得哪些企业事实，RAG评估判断检索和生成是否有据，Agent和Tool限制哪些业务动作可以进入执行阶段，下游系统负责最终授权，异常流程决定什么时候暂停或转人工，日志和Badcase机制则负责把真实问题重新带回知识、流程和工具调整。
企业落地前，与其只追问一个“幻觉率”，不如核验五件更具体的事情：依据是否可信、回答是否有据、动作是否受控、异常是否能停止、错误是否可追溯。
真正可靠的大模型客服，不是保证AI永远不会出错，而是让一次错误很难穿过整条控制链，最终变成真实业务后果。