智能体校验如何避免把未知当作通过

给 AI Agent 一个链上身份，离证明它可信还差得很远。作者做了两个开源校验工具，一个核对制裁名单声明，一个核对支付凭证，最后发现它们依赖同一条规则：没有完成核验，就不能给出通过结论。

这篇值得读的地方，是它把「可信」拆成了程序员能检查的条件：数据是否有效、必要字段是否校验、漏掉检查后测试会不会报警。作者也公开了零付费用户和一个尚未修复的漏洞，让这些经验的适用边界更清楚。

查不到，为什么不能默认通过

ERC-8004 为 AI Agent 提供链上身份，但身份只能回答「它是谁」，不能直接回答「它的声明是否属实」。原文还提到，简单平均声誉分数，可能把错误的 Agent 选成「最佳」。不过，作者没有展开那项实验，本文的证据仍来自他们自己的工具。

第一个工具 Al-Muqarin，核验的是一类具体声明：某家公司不在 EU、UK、OFAC、US 制裁名单上。它把声明与带签名、带日期的公开名单快照进行比对。

关键在于如何处理异常：名单缺失、过期，或者版本低于最低要求，都不能返回「clean」，而要返回 ONMEETBAAR，即「未测量」。

没有查出问题，和根本没能完成检查，必须是两种结果。

这就是失败关闭（fail-closed）的思路：证据不满足要求时，不给通过结论。否则，上游一次抓取失败，就可能被下游当成安全绿灯。

签名和最低版本要求也各有用途。签名用于核验快照来源及完整性，最低版本要求用于拒绝回滚后的旧名单。一份旧快照即使签名有效，也不代表它仍适合支撑当前判断。

作者承认，OpenSanctions 和托管工具 agentbroker 已经会对筛查结果签名，OpenSanctions 的数据覆盖还更广。他们声称自己没在其他地方找到的，是「对名单本身的快照签名，再用最低版本要求拒绝回滚」这一组合。这是作者的观察，不能当成经过全面调查的独家能力。

测试全绿，怎样证明检查真的存在

第二个工具 agent-receipt-verify 核验 x402/EIP-712 支付凭证，检查 Agent 是否确实支付了它声称的金额，以及是否使用了所声称的支付通道。规则相同：凭证没有完整通过校验，就如实报告，不能向上取整成「看起来没问题」。

两个工具之间，更值得复制的是测试方法。

作者会主动往代码里植入错误，例如删掉一项检查、翻转一个比较条件、漏掉一个字段，并要求每一个错误都必须触发测试失败。这类方法通常称为变异测试（mutation testing）。它检查的不是代码有没有跑过，而是代码被改坏后，测试有没有能力发现。

Al-Muqarin 当前能捕获 548/548 个植入错误。这支持一个具体结论：对于他们选择的这批错误，测试具有检测能力。它不能证明所有现实漏洞都已覆盖，原文也没有提供这些错误的分布、生成方式或独立评估。

对程序员而言，这比单看覆盖率更有启发。一个校验函数即使被执行过，测试也可能只断言「返回了对象」，没有断言错误输入必须被拒绝。

作者给出的检查办法很直接：如果系统会输出「verified」或「trusted」，就逐个删除检查条件，看看测试是否真的会失败。

我的判断

我认同它对结果语义的坚持。校验工具最危险的失误之一，是把「证据不足」包装成「校验通过」。明确返回未测量，能让调用方决定补数据、重试，还是暂停后续流程。

但失败关闭只是局部规则，不能自动拼出 Agent 信任体系。

作者自己的另一个影响声明校验原型就暴露了这个问题：它试图检查 Agent 的捐赠是否产生了所声称的效果，但「由谁核验」仍是自由文本。有人可以填写一段看不出与自身有关联的控制方描述，从而获得错误通过。作者已有测试证明漏洞存在，却尚未修复。

这说明，流程要求「独立核验」，不等于程序已经能识别核验者是否独立。字段齐全，也不等于证据成立。

商业有效性同样没有得到证明。Al-Muqarin 目前是零付费用户，作者把这视为真正的检验。与 OpenSanctions 等方案相比，原文没有给出准确率、维护成本或接入成本的对照数据，因此目前更适合把它看作一份工程经验，而非选型结论。

能拿来做什么

• 在 Node 校验接口中，把「通过」「未通过」「无法完成核验」表达为可区分的结果，并让调用方显式处理数据缺失和过期。
• 给日常 AI 编程生成的校验代码补一道检查：手动删除金额比较、必填字段检查等关键条件，确认现有测试会失败。
• 如果业务依赖外部名单快照，可以分别检查签名、日期和最低版本要求，避免把「签名有效」直接当成「数据可用」。
• 接入 Agent 支付或声明核验前，列清哪些结论由程序验证，哪些仍依赖自由文本或人工描述，尤其要检查「独立第三方」这样的身份前提。