Agent 结论发出前先对账值域对账验证层 n3 重复对照的搭建方法这两天 Agent 圈还在卷模型越来越聪明——更大的参数、更长的上下文、更强的推理。可查数场景有个反直觉的现实结论错了往往不是模型算错了而是它把 A 层级的东西填进了 B 层级的榜单还写得自信满满。我没跟着换更大的模型。我干了另一件事——把我自己维护的开源数据智能体工作台 daw 里2026 年 9 月 1 日那天落地的验证层verify完整拆了一遍。它的核心就一句话不信任回答者的自我声明结论发出前先拿数据库的真实值域对一遍账。看完我可以负责任地告诉你三件事。第一结构级错误层级错配、口径错配是可以用机械检查当场抓出来的不用等用户来骂。第二单次运行的结果说明不了问题同一个问题跑 3 次才能分清稳定缺陷和抽样噪声。第三纪律写成模板比写成说教管用而且管用的程度是可以度量的。1. 学习目标学完你会得到什么一句话学完这篇你会给自己的查数 Agent 搭一套验证层 重复对照的组合——结论里的每个实体先过值域对账每个评测问题跑 3 次再下结论交付纪律写成可机械检查的模板。先给大家科普一个概念「值域对账」。翻译成人话数据库里某列合法取值的全集就是值域。比如定金台账的 dept_lv2 列里只有战区级团队名那结论榜单里出现的每一个团队名都必须在这个集合里。榜单里冒出一个武汉咨询部——它在订单表里是部门级名不在战区值域里——那就是层级错配当场亮红灯。这篇的全部代码都在 daw 仓库里tools/verify_claims.py验证层、tools/eval_score.py打分器调用验证层、AGENTS.md完整的实验记录。2. 前置知识先说清验证层不做什么验证层有三个定位动手前必须先对齐否则写着写着就变味。第一验证层不判分只亮灯。v1 的设计是红灯只是疑似层级错配的高价值信号交由人工或上层定性不直接判 FAIL。为什么因为早期提取器有伪影误报直接判死刑会把好答案一起杀掉。先亮灯、攒数据、看红灯与真实错误的吻合度精度够了再收紧。第三验证层用的值域必须和金牌复标同源。daw 的做法是domain_sql就是一条直查 SQL跑在和金牌复标同一个数据库连接上。值域不是手写的一份清单——手写清单会漂移直查 SQL 不会。3. 第一步给每个评测用例写 verify 配置验证层的输入不是随便一段文本而是评测用例里的一段配置。长这样来自verify_claims.py的文档verify:[{name:好差榜单团队 ∈ 定金台账 dept_lv2 值域,domain_sql:SELECT DISTINCT dept_lv2 FROM ...,anchors:[用得最好,用得最差,用得好,用得差]}]三块内容一个都不能少name这条检查在查什么人能读懂。domain_sql值域的直查 SQL返回合法值全集。daw 支持-- connection_name前缀指定数据源缺省取 daw.db 里第一个 postgres 连接。anchors榜单句的锚点词。结论很长验证层只看含锚点的句子——用得最好的是 XX用得最差的是 YY这种榜单句。不锁定锚点正文里随口提到的团队名会被误当成榜单实体。锚点的作用是把宣称和随口提到区分开——提到一个名不等于把它当榜单答案交出来了。4. 第二步从榜单句里提取候选实体取到结论文本后验证层只看最后一个工具调用之后的那段纯文本结论段按句号和换行切句挑出含锚点的句子然后从句中提取候选实体。提取用的是一条组织实体后缀正则ENT_RE台账和订单表里的团队名都以这类后缀收尾——咨询部、事业部、战区、战队、军团、直辖、咨询中心、某部、某区、组、OB。用后缀锚定提取而不是随便切词是为了避免把渗透率客群特殊这类散文片段误当实体。光有正则还不够真实结论里有两种脏东西v2 就是为它们而生的脏东西一前缀散文。结论里写双优的苏州二部“郑州系和武汉咨询部”正则会把整段吞进来或把和二部当实体。解法是剥前缀散文按连词和助词和、与、及、或、的、顿号、逗号切分保尾段剥完剩下苏州二部“武汉咨询部”。v1 没做这一步“和二部”管理盲区这类伪影全是这么来的v2 加上剥离后短语伪影清零。脏东西二合法的零使用提及。“武汉咨询部没用这个工具里的实体确实不在值域里但它不是错配而是合法业务事实这家确实零定金。v2 的解法是零使用语境降级”实体前后 15 字窗口里出现没用、未使用、未收、零定金、0 笔、未开、从未这类词红灯降级为 warn。还有两类直接跳过、不当实体长度小于 3 的、还含助词连词的比如武汉的战区那是短语片段不是实体泛指描述短语“用得”“主力”“全国”“所有”“各战区”“各团队”。翻译成人话提取器的活儿不是多抓是抓准——抓错一个后面全是误报漏抓一个错配就溜过去了。v1 到 v2 的全部工作就是在这一步把抓准做扎实。5. 第三步值域对账——精确或包含匹配拿到候选实体后对账逻辑本身只有一句话候选实体对值域做精确或包含匹配命中算过没命中亮红灯。包含匹配是有讲究的苏州三部 ⊆ 苏州三部直辖这种人工截断也算命中——模型把全称截短了不算错配。匹配条件是候选长度 ≥3且候选在值域值里、或值域值在候选里。写的时候注意包含匹配是双向的只做单向会漏掉模型写了全称、值域里是简称的情况。对账的输出是 findings 列表每条带check、level、detail。level 分四档red答案实体不在值域内——疑似层级或口径错配。warn零使用语境提及合法业务事实或结论中没找到榜单锚点句可能漏检人工确认。errordomain_sql执行失败——值域本身没取到对账没法做。无 findings这条检查通过。还有一个边界结论文本为空直接返回一条 warn——“结论文本为空无法对账”。对账的前提是有结论可对没结论时不该静默通过。实战效果是验证层第一枪就命中2026 年 9 月 1 日的换模型对照里deepseek 把订单表部门级名武汉、大连、主动咨询部当定金台账团队列进好差榜单值域对账把 6 个真实错配实体全部机械拦下同一批 glm 的记录验证层 0 红灯。v2 上线后用 12 条存量记录验证glm 全部 0 红灯合法零定金提及全降级deepseek 真错配全数保留短语伪影清零——红灯数约等于真实结构错配数。6. 第四步n3 重复对照——分清稳定缺陷和抽样噪声验证层解决了这一轮对不对n3 解决的是这个失败是偶然还是必然。做法很简单同一个评测问题同一个模型跑 3 次分别计分再看 3 次的通过率和失败模式。daw 在 2026 年 9 月 1 日定案了这个协议理由是当天的实测数据deepseek 的团队好差问5 轮里只有 20% 通过3 轮踩层级陷阱——失败是稳定复现的不是抽了一次坏签。deepseek 的定金单数问3 轮 0% 通过来源表漏标稳定复现——这是纪律缺口不是噪声。glm3 轮 67%——召回路径 2 个工具、52 秒全对重算路径 10 个工具、217 秒 FAIL漏标来源表。同一模型内部都分层了召回路径全对重算路径会漏。三个结论第一deepseek 的失败是稳定行为不是抽样噪声。第二知识信任度本身是被测能力——召回路径和重算路径的表现可以天差地别。第三验证层第一枪命中——结构级错误当场现形。n3 还有个跑器教训eval_run的缺省模型查询会自我复读——上一条 eval 任务成了下一条的模型来源解法是缺省查询排除eval-任务。评测工具的 bug 比被测模型的 bug 更隐蔽因为它污染的是尺子本身。7. 第五步把纪律写成模板——剂量-响应定案验证层兜底之后daw 还做了一个对照实验回答纪律到底该怎么写。实验对象是结论末尾的来源清单行。三个版本v1 说教纪律提示词里写要标注来源——来源行合规率 0%。v2 要求有行要求结论末尾必须有来源清单行缺行等于未完成交付——deepseek 的 count 问从 0/3 到 3/3glm 从 0/3 到 3/3。v3 规定行格式来源行并进口径格式定死——口径行合规从 0/3 到全线 3/3crosscheck 双模型整卷通过率从 0%/33% 到 100%。这条曲线叫剂量-响应说教0%→ 要求有行v2→ 规定行格式v3合规率随模板精度单调上升。结论很硬模板化可机械检查的交付形态比说教式纪律更可遵守。把纪律写成模板是提示词工程在这个产品里剩余的有效杠杆模板降低违规率验证层兜底拦截残余两者互补。工程细节模板 v3 的检查是评分时即时计算的基线直接从存量记录算出不用重跑——打分器新检查必须是即时计算否则每加一个检查就要重跑整批评测。8. 为什么这样设计三条取舍第一先亮灯不判死刑。v1 红灯只报告不判 FAIL因为提取器精度还没验证过。先攒 12 条存量记录验证红灯 ≈ 真实错配再收紧一上来判 FAIL误报会逼你关掉整个验证层。第二值域直查不手写清单。值域来自domain_sql直查和金牌复标同源。手写清单漂移一次验证层就从裁判变成另一个错误来源。第三验证层和模板分工。模板是事前约束验证层是事后拦截。只做模板残余错配没人拦只做验证层模型永远在撞墙。两者互补才是生成 → 验证 → 纠错 → 再验证四步环。9. 避坑清单红灯先只报告不判 FAIL吻合度验证过后再收紧——一上来判死刑误报会逼你关掉验证层。实体提取必须剥前缀散文否则双优的苏州二部这类伪影会淹没真红灯。零使用语境必须降级为 warn——合法业务事实判成错配等于惩罚模型说真话。值域用直查 SQL和金牌复标同源——手写清单一定会漂移。同一问题跑 3 次再下结论召回路径和重算路径要分开看。打分器新检查必须即时计算评测跑器的缺省查询必须排除评测任务本身。10. 给开发者的建议先给最痛的一个榜单问加一条 verify 配置domain_sql 锚点词半小时就能跑起来。提取器先用后缀正则 剥散文 零使用降级三件套——这三件是 v1 到 v2 全部的精度来源。评测集里每个问题固定 n3把通过率和失败模式是否稳定一起记录。把你最想让模型遵守的一条纪律写成行格式模板行首锚点 格式定死而不是提示词里的一句说教。验证层拦下的红灯攒够一批就复盘一次——红灯分布本身就是下一轮纪律该往哪写的最准信号。不信任自我声明只信任对账结果。结论发出前先问一句它说的实体在值域里吗这个问题回答了查数 Agent 才算有了第一道真正的出厂检验。