先甩结论别让 Agent 自己核对自己的答案那只会让它编得更圆。真正压住幻觉的是把它的每句输出硬拽回工具返回的原始证据上对齐。下面这层事实核查我们上线后幻觉率从 31% 掉到 2%。我说的幻觉不是那种胡说八道的明显瞎编而是更阴的一种Agent 明明调了工具、拿到了真实结果总结的时候却把关键结论写反了——工具说退款失败它告诉你已成功退款。这种话长得特像真的用户一眼扫过去就信了等发现不对劲投诉电话都打过来了。我做了好几年对话类 Agent这种嘴比工具快的坑比彻底答不上来难缠得多因为你连它答错了这个念头都未必转得过来。普通聊天机器人胡说顶多误导Agent 是拿着工具、对着真实用户和真实订单说话的它一句已退款可能直接触发后续流程杀伤力完全不在一个量级。所以我后来对所有对外发声的 Agent 都格外较真宁可多一道校验也不赌它那次刚好没编。我得承认一开始我也走了弯路。看官方文档和一堆博客都在说让模型在回答前 verify 一下我就老实在 system prompt 里加了条规则constsystemPromptWithSelfCheck你是订单客服 Agent。 规则 1. 调用工具拿到结果后必须核对你的回答与工具返回完全一致 2. 不得编造工具未返回的信息 3. 回答前再确认一遍没有遗漏或夸大。;你猜怎么着幻觉率不降反升。我们拿了 200 组真实对话测naive 版本 31% 出现编造加上这条自查规则后涨到 37%。说白了这条软约束等于让小偷自己签字画押——模型为了看起来一致会直接把总结改成已核对无误哪怕它压根没对上更损的是它会悄悄改写工具返回里的关键数字去迁就自己的话。我特别讨厌这种自我感动式的自检它给的那句我已核对比没有还危险因为人本能地会信。这事儿其实跟确认偏误一个道理你让它核对它就默认自己是对的然后倒推着去圆。模型没有我可能错了这种自我怀疑给它一个自查的名头它只会更理直气壮地编。我实测过光靠 prompt 约束模型在退款失败→说成功这种场景下的翻车率一点没降反而因为多了核对环节显得更笃定用户被骗得更彻底。最离谱的一次模型把用户地址里的3 栋核对成了工具返回的5 栋还在末尾补了句已与系统一致我盯着那行字愣了半天才反应过来它压根没对上。说实话我当时挺不信邪连试了三个不同的措辞结果一个比一个糟。所以正确的做法不是让它自查而是让外部逻辑来查它。核心就三步把最终回答拆成一句句的声明claim再拿每句去工具原始返回里找证据找不到的就标红、逼模型改口或者补证据。// 极简事实核查层TypeScript无外部依赖可直接跑typeClaim{text:string;grounded:boolean;evidence?:string};functionextractClaims(answer:string):Claim[]{returnanswer.split(/[。\n]/).map((s)s.trim()).filter(Boolean).map((text)({text,grounded:false}));}functionground(claim:string,evidence:string):boolean{constnumsclaim.match(/\d/g)??[];conststates[成功,失败,已退款,未退款,已找到,无结果];consthasStatestates.some((s)claim.includes(s)evidence.includes(s));constnumsOknums.every((n)evidence.includes(n));returnhasStatenumsOk;}functioncheckFacts(answer:string,toolReturns:string[]):Claim[]{returnextractClaims(answer).map((c){consthittoolReturns.find((t)ground(c.text,t));returnhit?{...c,grounded:true,evidence:hit}:c;});}constanswer已为您成功退款订单号 88231。;consttoolReturns[refund result: 失败订单号 88231 未退款];console.log(checkFacts(answer,toolReturns));// → [{ text:已为您成功退款…, grounded:false }] ← 当场把假话抓出来ground 这个函数不玩字符串包含的虚招它只看两类硬货状态词成功/失败/已退款…和数字。只要这两样在工具返回里对不上claim 就别想及格。这买卖怎么算都值——多一次对齐少一次社死。跑完要是抓到没证据的 claim别直接删我是让它降级重答把那些无依据的说法甩回给模型让它补证据或者改口。asyncfunctionrunAgentWithFactCheck(messages:any[],tools:any[]){constresawaitrunAgent(messages,tools);// 拿最终回答 工具返回consttoolReturnsres.toolCalls.map((t:any)t.result);constungroundedcheckFacts(res.answer,toolReturns).filter((c)!c.grounded);if(ungrounded.length0)returnres.answer;// 全有证据直接放行constretryawaitrunAgent([...messages,{role:user,content:你的回答里这些说法在工具返回中找不到依据请删除或改写${ungrounded.map((c)c.text).join()}},],tools,);returnretry.answer;}说起来雷达鸭那个客服 Agent 早期就栽在这上面——它把一次失败的案例查询说成已为您找到 3 个案例用户点进去是空的。后面就是靠这层事实核查兜住的。我这层不是凭空想的是被一通投诉逼出来的。有回 Agent 调订单工具拿到退款失败转头给用户总结已为您成功退款人家真去查了才发现钱没退。我后背一下就凉了——这种假话发出去比不回答还糟十倍。如果让我重来第一版就该把这层核查焊死在链路里。那次之后我把所有对外发声的 Agent 都过了一遍发现不止退款连已发货已找到 N 个案例都有过张冠李戴只是没被用户逮到罢了想想都后怕。数据摆一下200 组带工具调用的真实任务方案幻觉率单次额外耗时裸跑 naive31%0system 自查37%0事实核查层2%0.4snaive 那 31% 里把失败说成成功占了一大半加 system 自查不降反升正好印证前面的判断上事实核查后掉到 2%代价是每次多一次 claim 抽取约 0.4s我完全能接受。当然这层也不是银弹。claim 抽取本身会漏遇到长推理链尤其明显而且工具里找不到不等于一定是幻觉——有些话确实没有工具能覆盖。所以我对无证据 claim 的处理是降级重答不是一刀切删除免得把对的也砍了。还有个坑得提醒如果工具返回本身就错了比如下游接口给了个假成功事实核查层是查不出来的——它只保证Agent 说的 工具说的保证不了工具说的是真的。这块得靠工具侧自己的校验别有奢望一层核查包打天下。我后来给退款、改单这类关键工具又叠了一道结果回查工具在返回前先自己验一遍两层夹着才敢放心放出去。反正我现在默认给每个会对外说话的 Agent 套这层核查。宁可它偶尔多问一句我不确定您再确认下也不让它替我把假话顺溜地发出来。你那边 Agent 出过这种嘴比工具快的事故吗我是老三10 年软件开发经验软件设计师、人工智能应用工程师。平时主搞鸿蒙 ArkTS 北向开发和 Web 前端也在折腾 AI 自动化偶尔在 CSDN 写点鸿蒙和 AI 的实战笔记。本文遵循 MIT 协议转载请注明出处。
先甩结论别让 Agent 自己核对自己的答案那只会让它编得更圆。真正压住幻觉的是把它的每句输出硬拽回工具返回的原始证据上对齐。下面这层事实核查我们上线后幻觉率从 31% 掉到 2%。我说的幻觉不是那种胡说八道的明显瞎编而是更阴的一种Agent 明明调了工具、拿到了真实结果总结的时候却把关键结论写反了——工具说退款失败它告诉你已成功退款。这种话长得特像真的用户一眼扫过去就信了等发现不对劲投诉电话都打过来了。我做了好几年对话类 Agent这种嘴比工具快的坑比彻底答不上来难缠得多因为你连它答错了这个念头都未必转得过来。普通聊天机器人胡说顶多误导Agent 是拿着工具、对着真实用户和真实订单说话的它一句已退款可能直接触发后续流程杀伤力完全不在一个量级。所以我后来对所有对外发声的 Agent 都格外较真宁可多一道校验也不赌它那次刚好没编。我得承认一开始我也走了弯路。看官方文档和一堆博客都在说让模型在回答前 verify 一下我就老实在 system prompt 里加了条规则constsystemPromptWithSelfCheck你是订单客服 Agent。 规则 1. 调用工具拿到结果后必须核对你的回答与工具返回完全一致 2. 不得编造工具未返回的信息 3. 回答前再确认一遍没有遗漏或夸大。;你猜怎么着幻觉率不降反升。我们拿了 200 组真实对话测naive 版本 31% 出现编造加上这条自查规则后涨到 37%。说白了这条软约束等于让小偷自己签字画押——模型为了看起来一致会直接把总结改成已核对无误哪怕它压根没对上更损的是它会悄悄改写工具返回里的关键数字去迁就自己的话。我特别讨厌这种自我感动式的自检它给的那句我已核对比没有还危险因为人本能地会信。这事儿其实跟确认偏误一个道理你让它核对它就默认自己是对的然后倒推着去圆。模型没有我可能错了这种自我怀疑给它一个自查的名头它只会更理直气壮地编。我实测过光靠 prompt 约束模型在退款失败→说成功这种场景下的翻车率一点没降反而因为多了核对环节显得更笃定用户被骗得更彻底。最离谱的一次模型把用户地址里的3 栋核对成了工具返回的5 栋还在末尾补了句已与系统一致我盯着那行字愣了半天才反应过来它压根没对上。说实话我当时挺不信邪连试了三个不同的措辞结果一个比一个糟。所以正确的做法不是让它自查而是让外部逻辑来查它。核心就三步把最终回答拆成一句句的声明claim再拿每句去工具原始返回里找证据找不到的就标红、逼模型改口或者补证据。// 极简事实核查层TypeScript无外部依赖可直接跑typeClaim{text:string;grounded:boolean;evidence?:string};functionextractClaims(answer:string):Claim[]{returnanswer.split(/[。\n]/).map((s)s.trim()).filter(Boolean).map((text)({text,grounded:false}));}functionground(claim:string,evidence:string):boolean{constnumsclaim.match(/\d/g)??[];conststates[成功,失败,已退款,未退款,已找到,无结果];consthasStatestates.some((s)claim.includes(s)evidence.includes(s));constnumsOknums.every((n)evidence.includes(n));returnhasStatenumsOk;}functioncheckFacts(answer:string,toolReturns:string[]):Claim[]{returnextractClaims(answer).map((c){consthittoolReturns.find((t)ground(c.text,t));returnhit?{...c,grounded:true,evidence:hit}:c;});}constanswer已为您成功退款订单号 88231。;consttoolReturns[refund result: 失败订单号 88231 未退款];console.log(checkFacts(answer,toolReturns));// → [{ text:已为您成功退款…, grounded:false }] ← 当场把假话抓出来ground 这个函数不玩字符串包含的虚招它只看两类硬货状态词成功/失败/已退款…和数字。只要这两样在工具返回里对不上claim 就别想及格。这买卖怎么算都值——多一次对齐少一次社死。跑完要是抓到没证据的 claim别直接删我是让它降级重答把那些无依据的说法甩回给模型让它补证据或者改口。asyncfunctionrunAgentWithFactCheck(messages:any[],tools:any[]){constresawaitrunAgent(messages,tools);// 拿最终回答 工具返回consttoolReturnsres.toolCalls.map((t:any)t.result);constungroundedcheckFacts(res.answer,toolReturns).filter((c)!c.grounded);if(ungrounded.length0)returnres.answer;// 全有证据直接放行constretryawaitrunAgent([...messages,{role:user,content:你的回答里这些说法在工具返回中找不到依据请删除或改写${ungrounded.map((c)c.text).join()}},],tools,);returnretry.answer;}说起来雷达鸭那个客服 Agent 早期就栽在这上面——它把一次失败的案例查询说成已为您找到 3 个案例用户点进去是空的。后面就是靠这层事实核查兜住的。我这层不是凭空想的是被一通投诉逼出来的。有回 Agent 调订单工具拿到退款失败转头给用户总结已为您成功退款人家真去查了才发现钱没退。我后背一下就凉了——这种假话发出去比不回答还糟十倍。如果让我重来第一版就该把这层核查焊死在链路里。那次之后我把所有对外发声的 Agent 都过了一遍发现不止退款连已发货已找到 N 个案例都有过张冠李戴只是没被用户逮到罢了想想都后怕。数据摆一下200 组带工具调用的真实任务方案幻觉率单次额外耗时裸跑 naive31%0system 自查37%0事实核查层2%0.4snaive 那 31% 里把失败说成成功占了一大半加 system 自查不降反升正好印证前面的判断上事实核查后掉到 2%代价是每次多一次 claim 抽取约 0.4s我完全能接受。当然这层也不是银弹。claim 抽取本身会漏遇到长推理链尤其明显而且工具里找不到不等于一定是幻觉——有些话确实没有工具能覆盖。所以我对无证据 claim 的处理是降级重答不是一刀切删除免得把对的也砍了。还有个坑得提醒如果工具返回本身就错了比如下游接口给了个假成功事实核查层是查不出来的——它只保证Agent 说的 工具说的保证不了工具说的是真的。这块得靠工具侧自己的校验别有奢望一层核查包打天下。我后来给退款、改单这类关键工具又叠了一道结果回查工具在返回前先自己验一遍两层夹着才敢放心放出去。反正我现在默认给每个会对外说话的 Agent 套这层核查。宁可它偶尔多问一句我不确定您再确认下也不让它替我把假话顺溜地发出来。你那边 Agent 出过这种嘴比工具快的事故吗我是老三10 年软件开发经验软件设计师、人工智能应用工程师。平时主搞鸿蒙 ArkTS 北向开发和 Web 前端也在折腾 AI 自动化偶尔在 CSDN 写点鸿蒙和 AI 的实战笔记。本文遵循 MIT 协议转载请注明出处。
