企业级 Agent 最缺的不是聪明，是"不敢编"——企查查智能体数据平台的三层反幻觉工程

推荐语

当AI Agent自信地编造企业数据，后果可能是一场灾难。本文揭秘企查查如何用三层工程让AI“不敢编、不能编、编了也露馅”。

核心内容：
1. AI在企业尽调中的四类致命数据幻觉
2. 三层反幻觉工程与工具描述工程的具体实现
3. 验证有效性的方法与边界成本

杨芳贤

53AI创始人/腾讯云(TVP)最具价值专家

01

问题的真身：缺的不是聪明，是"不敢编"

当 Agent 开始替人查企业、做尽调、过合规，一个反直觉的事实摆在面前：制约它的往往不是模型不够聪明，而是它太敢说——在没有依据的地方，它会用和正确答案一样的口吻，把错误答案讲得无比自信。（下一节那个差点批了贷的事故，就是活例。）

把"数据幻觉"摊开看，其实是四类很具体的错，也是我们在产品上每天正面硬刚的四类：

• 认错主体：名称一字之差，查错了对象；
• 凭空编造：没有的股东、持股平台、融资轮次、估值，也敢一本正经写出来；
• 解读过期：拿企业的旧名称、已下架的历史记录当现状作答；
• 空数据误判：把"没查到"当成"没有"，进而推导出"该企业绝对无风险"。

这四类错有一个共同点：换个更强的模型治不好。恰恰相反，模型越流畅，编得越像真的、越难被一眼识破。

真正能摁住它们的，是模型之外那层工程。这和社区最近在聊的 Harness / Loop Engineering 是同一个道理——决定一个 Agent 靠不靠谱的，往往不在模型参数里，而在包裹模型的那层执行骨架。对一个企业数据平台来说，这层骨架就是反幻觉工程。我们把它落成三层防御，外加一层常被忽略的工具描述工程——这套工程就跑在企查查智能体数据平台（agent.qcc.com）上。

四类错里最致命的是第一类——认错主体。讲一个让我们后背发凉的真实事故（已匿名）。

一家银行的智能尽调助手接到任务：用户问"查一下这家公司有没有失信"。Agent 拿到名字，去查，返回"未发现失信记录"，于是给出结论——"该主体信用状况良好，可进入下一步"。

问题是：它查的根本不是那家公司。要查的企业名字里带着"信息技术"几个字；而在一批名称高度相似的主体里，模型匹配到了另一家只差几个字、确实干净的公司。于是一家本身就有公开失信记录、本应被一眼查出的企业，在 Agent 眼里成了'可以放贷'的优质客户。

整个过程没有任何一步报错：接口正常返回、模型流畅作答、结论看起来专业得无可挑剔。这恰恰是企业级 Agent 最危险的地方——返回了数据，不等于返回了可信的数据。模型不会告诉你它查错了人，它只会把错误答案说得和正确答案一样自信。

把上面的问题落到工程上，是三层依次收口的防御。

第一层 · 实体强锚定：先锁定"你查的到底是谁"

上一节那个事故，根子在第一步就埋下了：还没确认"查的是谁"，就开始查"它有没有事"。后面查得再准，也是在错误的主体上准。

我们的做法是：任何风险类调用之前，强制先做实体识别、锁定 18 位统一社会信用代码。名称只要存在微差、或命中多个高度相似主体，业务工具不会"猜一个最像的返回"，而是停下来——要么返回候选清单交由上层（人或编排）确认，要么返回明确的"未唯一匹配"。一句话：宁可不给，也不给错。

这里有一个反直觉、但很关键的工程取舍：名称近似时，正确的返回不是"最佳猜测"，而是一个明确的"未命中 / 请消歧"信号。很多接口习惯在模糊匹配时返回排序第一的结果——这在搜索框里是体验优化，在 Agent 链路里却是灾难：模型拿到一条"看似命中"的数据，根本不知道这是赌出来的。把"消歧"这件事显式交还给上层，而不是让模型在黑箱里替你赌一把，是实体强锚定的核心。

第二层 · 强语义负向防御：把"空数据"变成"强信号"

第二类高频幻觉来自一个字：空。

传统接口查不到时，返回一个空数组 []。这对人没问题，对大模型却是灾难：它分不清这个 [] 到底是"真的没有"，还是"查询失败 / 参数不对 / 这个维度本就不该有数据"。分不清，它就倾向于脑补一个合理解释——而脑补出的"该企业无任何风险"，正是上一节事故的另一种来路。

我们的做法是把空结果转成带明确语义的状态码。比如查一家公司有没有严重违法记录，真实返回是这样（实调，未做任何美化）：

get_serious_violation("某科技股份有限公司")
{
  "企业名称": "某科技股份有限公司",
  "搜索结果": "经企查查底层数据库全量核查实体 某科技股份有限公司，当前未发现任何【严重违法】记录。此项核心合规风控排查安全，允许进入下一步审计。"
}

模型读到的不再是一个冷冰冰的 []，而是一句有方向的话：已全量核查、当前未发现、可继续下一步。它不需要、也不会再去"猜"这个空到底意味着什么。

但有一个边界必须讲清楚，否则就从一种幻觉滑向另一种："当前未发现"不等于"绝对没有"，它等于"在这个数据源、这个时点、全量核查之后没有"。强语义的价值不是给模型一个更强的承诺，而是把"我查了什么、查的范围有多大"说清楚，让模型基于事实推理，而不是基于空白想象。

第三层 · 上下文脱水：少喂、喂准，省 token 也降幻觉

第三层和幻觉的关系没那么直接，但同样关键。

传统接口习惯把一整页原始数据一股脑塞给模型。数据量一大，两件坏事同时发生：token 烧得快、上下文被占满；关键信息淹没在噪音里，模型更容易抓错重点，甚至在超长截断之后"脑补"被截掉的那部分。

我们的做法叫上下文脱水：不返回原始 JSON 堆，返回"摘要先导 + 按需明细"。比如查一家公司的立案信息，返回长这样：

get_case_filing_info("某公司")
{
  "摘要": "该主体累计共有 3531 条记录，系统已为您实时检索 2025-06-05 至今的动态，包含 30 条记录。最近一次立案日期为 2026-04-09，案由为侵害商标权纠纷。",
  "提示": "该维度数据较多，已为您展示前 30 条。"
}

模型一眼拿到的是"总量多少、这次给了多少、最近一条是什么"——一个能直接决策的结论，而不是 3531 条原始记录。配合"参数下推"（按需索取字段、按需控制返回粒度）和分页降噪，既省 token，又因为"喂得准"而少了一类信息过载型幻觉。

这里也有一条必须守住的纪律：返回多少条，由返回体里的摘要告诉用户，而不是在工具描述里承诺"返回所有 / 全量"。因为任何数据源都有分页上限，"全量"是一句迟早翻车的话——而工具描述里的每一句话，模型都会当真。

一个反例，我们自己踩过。为了在 AI 会话里给用户一个"下一步可以问什么"的引导，我们一度把引导文案直接写进某个工具的返回文本。结果两头不讨好：这段文案每次都被灌进模型上下文，既烧 token 又干扰推理——正好违反我们自己定的脱水原则；而它要不要出现、怎么措辞、放在哪，全凭模型自由发挥，可能被改写、被吞掉、被挪位。上线没多久就撤了。教训很直接：要稳定地影响模型的行为，得把规则放在工具描述、协议这些"固定位"上（下一节就讲），而不是往返回文本里塞话——长在 AI 转述里的东西，不可控。

04

容易被忽略的第四层 · 工具描述工程：让模型"选对工具、不越界"

前三层解决的是"单次调用可信"。但当平台的工具一多——我们现在是 6 个 Server、182 个工具（agent.qcc.com 上免费可用）——新的幻觉就冒出来了：模型选错工具，或者一次把好几个相近的工具全调一遍（我们内部叫"散弹枪"），再把"当前在册"和"历史已移出"混在一起，给一个没有时间窗的笼统结论。

治这个，靠的是工具描述工程——把每个工具的 description 写成 AI 的"路由规则"，而不只是"功能说明"。两条最有用的纪律：

(a) 默认意图归属。同一个维度往往有"当前"和"历史"两个工具。我们在描述里显式声明：用户说"查 X"、且没有历史限定时，默认只调当前那个；只有出现"曾经 / 历史 / 已移出"这类词，才去调历史那个。

举一个真实的、已匿名的例子：用户问某头部互联网公司"有没有失信"。AI 初次仍是散弹枪——当前、历史两个工具都调了。我们追问它一句"你为什么调了历史那个？"，它读了一遍工具描述里的"调用语义"，自己纠正过来："不应该调。用户没有历史限定，我只该查当前在册，多调了一次是多余的。"这件事的意义不在"AI 会认错"，而在于：当描述把路由规则写清楚，模型能据此自我推理、自我收敛——描述从一份"说明书"变成了一道"护栏"。

(b) 数据服务商的边界。工具描述只陈述客观事实，绝不替客户写业务决策。我们会写"当前在册有效的失信记录、仍在公示期"，但绝不会写"建议拒绝开户 / 一票否决 / 加强监测"。因为我们是数据方，"这条数据意味着该不该放贷"是客户的风控系统该定的事。把决策规则写进数据描述，看起来"更懂业务"，实则是越界——也是另一种幻觉的温床：让模型替客户拍了它根本不该拍的板。

05

怎么知道它真有效：AI 测试 AI + 双源核验 + 四层穿透

反幻觉工程最怕"自我感觉良好"。我们用三件事来确认它真的有效，而不是"看起来有效"：

• AI 测试 AI：不靠"没人反馈所以没问题"，而是主动拿真实的 AI 客户端，按典型问句成批跑，看它到底调了什么、答了什么。"没有客户报错"从来不等于"没有错"，只等于"还没被发现"。
• 双源核验：任何"它编了 / 它错了"的判定，自己也要有两个独立来源印证（比如平台实时数据 + 一份官方披露文档）。单源判定很容易把"口径不同"误伤成"造假"，反过来也会漏掉真错。
• 四层穿透：判断一次调用算不算"成功"，要穿透四层——① AI 选对工具了吗 ② 工具返回的数据对吗 ③ 这组数据的业务含义，客户能正确理解吗 ④ 客户据此做的决策对吗。四层全过才算成功，错一层就是事故。

用这把尺子回量前面那个"认错主体"的事故就很清楚：工具没坏（数据本身是对的），但实体错了、语义也就错了、决策跟着错——四层里只过了一层，妥妥的事故。而上一节那个头部互联网公司的例子，自我纠错之后四层基本都过——这才是真正的"成功示例"，不是"它调了好多工具、显得很全面"。把"调了很多工具"当成"很智能"，是另一个隐蔽的认知陷阱：对 Agent 来说，正确的行为是准确路由 + 最小必要调用，不是散弹枪。

有意思的是，反幻觉不只是我们在工具层单方面使劲，模型本身也在往"诚实"走。Anthropic 发布 Claude Opus 4.8 时，把"会说'我不确定'、更擅长发现自己代码里的问题"做成了头号卖点（据其发布说明，模型漏报自身代码缺陷的概率约降到前代的四分之一）。

我们正好撞上一个真实样本。一次本来只是复盘官网访问数据的任务，模型注意到一个登录扫码页的指标很反常：到达后几乎无人继续往下走、平均停留只有 38 秒——典型的"死胡同"形态。它没有停在"建议优化扫码体验"，而是去翻了前端代码，发现二维码里编码的那个地址、前端根本没有对应路由；于是给出一个可验证的假设——"用户若用手机相机 / 微信扫，浏览器打开它，多半是 404"，并且明确把这句标成"假设、待实测"，没当结论。我们当场在浏览器里一试，真的就是 404。一个潜伏的线上 bug，被一个数据信号牵了出来，当天就出了修复。

我想强调的不是 bug 本身，而是这套打法与"诚实"的关系：数据异常 → 反查代码 → 提出假设（标成假设）→ 实测验证，每一步都拿证据说话。模型这边把"会说我不确定"做成升级，我们这边一直在抓"证不出来就说不确定、事实必须有 evidence 锚点"的工程纪律——两边方向一致，才有了"靠证据揪出 bug"这种结果。反幻觉的终局，不是让模型变得更敢说，而是让它在没有依据时，敢说"我不确定"。

07

边界与成本：压得住，但压不到零

要诚实地说：这套工程能大幅压制幻觉，但压不到零。

• 残留要靠人兜底。强锚定、强语义、四层穿透能拦住绝大多数，但总有边角 case，需要保留人工复核这道闸——尤其在金融、尽调这类"错一次代价极高"的场景。
• 验证是有成本的。AI 测试 AI、双源核验、多次重跑，都要烧 token 和人力。它值得，但要花在"错一次代价高"的地方，而不是给每一次调用都套上全套。
• 越自动，越要留住刹车。工具层做得越稳，人越容易不再去看过程。所以我们把判断、验收、刹车这三样权力，始终留在人手里。

承认边界，本身就是反幻觉的一部分——一套号称"零幻觉"的方案，往往是最大的那个幻觉。

08

写在最后：Agent 的可信，不在模型参数里

如果说过去两年大家比的是"谁的模型更强、谁的提示词更妙"，那么当 Agent 真的开始替人做有后果的决策时，比的会是另一件事：谁把模型和真实世界之间的那层工程做得更扎实。

对一个企业数据平台来说，这层工程就是反幻觉——实体强锚定让它"不认错人"，强语义负向防御让它"不把空白当没有"，上下文脱水让它"不被噪音带偏"，工具描述工程让它"选对工具、不越界"；四层之上，再压上 AI 测试 AI、双源核验、四层穿透，以及最终那道人工刹车。

企业级 Agent 最缺的，从来不是更聪明的脑子，而是一套让它"不敢编、不能编、编了也露馅"的工程。

动手试一试 · 企查查MCP

为 AI 智能体注入真实的商业世界：在 WorkBuddy / QoderWork / QClaw / IMA 等主流 AI 工具，以及任何支持 MCP 协议的 AI 工具，一句话调用企业工商、司法、知产、风险数据。6 个 Server · 182 个工具 · MCP + CLI 双栖 · 免费接入 → https://agent.qcc.com