评估AI Agent验证厂商的5个关键问题

当"可验证"成为营销话术

几乎每家厂商现在都在兜售"可验证的智能体"（verifiable agents）。这个词出现在新闻稿、定价页面和销售文稿里，听起来专业而严谨。但多数时候，它意味着厂商想让它意味着的任何东西。

这对采购方是个真实的问题。因为"验证"（verification）在技术上有精确含义：要么第三方能够在不信任任何相关方的前提下核查记录，要么不能。这里没有中间地带，而营销话术恰恰活在中间地带。

原文作者给出了五个能够穿透营销迷雾的问题，并建议按顺序提问。拥有真正验证能力的厂商会干脆利落地回答全部五个问题；而只有一块仪表盘的厂商，往往在第二个问题就开始含糊其辞。

问题一：第三方能否在零信任你的前提下验证记录？

这是整个博弈的核心。把执行记录交给一个由从未听说过该厂商的人编写的程序，这个程序只有记录、声称的结果字节和一个哈希函数——没有网络访问、没有API密钥、没有登录凭证。

它能否回答一个问题：这条记录自创建以来是否被修改过？

好的答案是："可以。验证就是纯粹的重新计算——对精确的输入输出字节做哈希，与收据比对，沿哈希链向上核验。任何人都能在一个下午内根据规范写出验证器。"

糟糕的答案则是"用我们的验证仪表盘""调用我们的API来检查""我们的验证器应用会确认"。每一个都从侧门偷偷把"信任"又塞了回来。如果验证需要厂商的基础设施、密钥或软件，你就不是在验证，而是在请厂商为自己背书。

这里隐含的技术基础是密码学哈希函数（cryptographic hash function）。哈希函数将任意长度的数据映射为固定长度的摘要（如SHA-256输出256位），其关键性质是"单向性"与"抗碰撞性"：给定输入极易算出哈希值，但从哈希值反推输入在计算上不可行；任何一个字节的改动都会导致完全不同的输出。"哈希链"（hash chain）则是将每条记录的哈希值包含在下一条记录的输入中，形成有序的密码学依赖链——篡改链中任意一条记录，其后所有节点的哈希值都会失效，任何人执行重算都能立即察觉。这就是为何"纯粹的重新计算"能够在零信任前提下完成验证：验证者不需要相信任何人告知他结果是什么，数学本身就是仲裁者。

问题二：验证究竟证明了什么？

精确性在这里区分了严肃者与推销者。要求厂商用一句话、不带任何形容词地陈述其主张。

好的答案是："一张经过验证的收据证明，被保存的结果自保存以来未被更改。"这就是全部主张。它刻意收窄——窄的主张才可核查，可核查的主张才能在审计中存活。

糟糕的答案是任何版本的"它证明智能体做对了事情"。对记录的验证不等于对正确性的验证。收据无法告诉你工具是否用合理的输入被调用、答案是否正确、现实世界中是否真的发生了什么。如果智能体调用了支付API，收据只能证明调用记录是完整的，并不能证明钱真的转了——那需要去核对银行。

要警惕答案中的"范围蔓延"。"证明执行完整性"听起来很强却什么也不是，"证明输出可信"是一种感觉而非一次核查。在这里夸大其词的厂商，其实是在告诉你他们并不理解自身的边界——这意味着你无法信任他们守住这条边界。

问题三：格式是开放的还是专有的？

收据格式只有在任何人都能实现时，才能作为基础设施发挥作用。要问："一位我从未谋面的工程师，能否仅凭你的文档、不接触你的系统就写出一个验证器？"

好的答案指向一份公开发布、带版本号、在开放环境中开发、经过公开评审并拥有真实修订历史的规范。黄金标准是走标准化流程的文档，例如IETF的Internet-Draft——与厂商成败毫无利益关系的陌生人阅读文本并提交问题。十五轮这样的评审会找出作者从未察觉的漏洞。

糟糕的答案是"我们的专有格式"、藏在登录墙后的文档，或是写着"验证API请联系销售"的规范。专有收据就是裹着密码学外衣的供应商锁定：审计者需要在十二个平台上开账户，证据会随着创业公司的消亡而死去。而且每家采用专有格式的厂商，都有一种悄然的动机——把验证维持在刚好困难到让你永远离不开的程度。

开放格式还让你能在同等条件下比较厂商。当每张收据都遵循同一规范，你比的就是谁铸造出最好的收据，而不是谁的仪表盘最光鲜。

IETF（互联网工程任务组）的Internet-Draft流程是理解"开放评审"含义的关键参照。Internet-Draft是RFC（Request for Comments，互联网标准的最终形式）的前身草案，任何人均可免费获取、公开评论，草案的每一轮修订与评审意见都有公开存档。IETF的工作组由来自全球不同组织、彼此无利益关联的工程师组成，他们的工作是挑毛病——找出歧义、安全漏洞和实现陷阱。这与厂商自行发布的"规范"有本质区别：后者的作者与实现者是同一方，没有外部压力驱动他们暴露对自身不利的边界情形。经过多轮公开评审并留存修订历史的规范，其可信度来源于过程的透明性，而非发布者的权威性。

问题四：厂商消失后验证还能存活吗？

要问：如果厂商下周二就关门，五年的收据会怎样？

好的答案是："什么都不会发生。验证就是针对收据和已保存字节的哈希重算，不需要网络、不需要厂商API、不需要许可证服务器。你的证据就是一个文件和一个哈希函数，两者都将继续存在。"

糟糕的答案则涉及任何实时依赖：一个API端点、一个证书服务、一个托管的验证器、一条由厂商运营的链。有过期日期的证据不是证据，而是一份订阅。

这个问题还能揪出"锚定"（anchored）的变体。锚定哈希只能证明某个哈希在某个时间点存在过，却对被哈希内容是否为真只字不提；而如果锚定方案依赖厂商的中继器或索引器，你又回到了信任厂商的老路。要问清楚：当他们消失后，你手里握着的到底是什么。如果答案是"我们的API"，掉头就走。

时间戳锚定（timestamp anchoring）是这一领域常见的技术方案，值得单独澄清其边界。锚定方案通常将某个哈希值提交到一个可信的第三方账本（如公共区块链或可信时间戳服务），以此证明"某个哈希在某个时刻存在"。这解决了时间可信性问题，但不解决内容完整性问题：锚定只能证明哈希值存在于某个时间点，无法证明该哈希对应的内容是真实或正确的。更关键的是，如果锚定方案依赖厂商运营的"中继器"将哈希值提交到账本，或依赖厂商的"索引器"来查询锚定记录，那么即便底层账本是去中心化的，验证路径仍然经过厂商——厂商消失后，你将无法独立完成从收据到锚定记录的追溯。真正具备离线存活能力的方案，要求验证所需的全部信息都包含在收据文件本身之中。

问题五：谁来捕获记录——智能体还是执行层？

这是厂商最希望你永远不问的问题，因为它暴露了这个领域最常见的失效模式。

好的答案是："由执行层在工具运行的那一刻、结果返回给智能体之前捕获记录。智能体从不接触收据，它无法伪造、编辑或压制一张收据，除非打断哈希链。"

糟糕的答案是任何形式的"智能体自我报告"：由应用写入的日志、对话记录、"智能体确认已完成"、事后生成的摘要。智能体是其自身行为最不可信的证人，它有一切动机报告成功。建立在自我报告之上的验证故事，是故事，不是核查。

继续追问时机。"在执行时捕获"意味着记录由运行工具的那一层写入，带着精确的输入输出字节，在执行的那一刻完成。"运行后记录"则意味着有人事后重建了它——而重建正是造假滋生的地方。

一句话总结

如果只记住一件事：验证意味着一个不信任任何人的陌生人，能够重算这道数学题并确认记录完好无损。其余一切都是营销。

原文提到，有一份开放的Internet-Draft正是定义了这一点：AER-1（可验证执行收据格式），目前在IETF datatracker上为draft-zambo-aer1-15。它规定了捕获什么、输入输出如何哈希、收据如何链接，以及第三方如何仅凭记录和哈希函数完成验证。它仍是草案而非最终标准，并已有多种语言的实现。Zambo则是其参考实现，为每次工具调用铸造可独立验证的收据。

对采购方而言，这五个问题提供了一套实用的尽职调查框架：不要听厂商怎么说，而要看证据能否在没有厂商参与的情况下自证清白。