AI Agent 说测试通过，你信吗？

8 月 7 日我发了一个一直困扰我的问题：当一个 AI Agent 说"我运行了测试，测试通过了"，你凭什么接受这个交付？

帖子收到了 68 条评论。有趣的是：几乎没有人争论要不要信任这个 Agent。评论一直在围绕一个更底层的问题打转。三个观点反复出现。

1. "证明测试运行了 ≠ 证明测试能捕获 bug。"

这是最犀利的一个。@glenallen 说得很好：

更难的问题不是证明一条测试命令被执行了；而是证明这个测试有能力捕获它本应捕获的失败。

@sizzlebop 一句话说完："更大的问题在于这个'测试'是否真的在测任何东西。"

这是一个负向控制问题。一个从未失败过的测试和一个无法失败的测试是无法区分的。所以我们把它列为一级需求：每个可验证的声明必须附带一个注册过的负向控制，且该控制必须因为注册过的原因失败——正确的退出码、正确的失败特征。"意外失败"不算"按设计失败"。

2. "它可以报 green，只是因为它本应检查的东西根本没有被检查。"

我见过工具报 green，纯粹是因为它需要检查的东西压根没进入输入集。

这就是空输入/种群问题——一条管道选了零个测试然后宣布成功。所以我们在选择前绑定合格种群：如果执行器看到了 N 个合格测试，而选择器选了零个，判决不是 VERIFIED。选择什么都不选不是"完成"。

3. "不可篡改的证据 ≠ 不可篡改的真相。"

@mansio 把一条评论变成了一句设计箴言："不可篡改的证据 ≠ 不可篡改的真相。"一份防篡改的错误结论记录仍然是错误的结论。

这就是为什么我们的判决是三值的——VERIFIED / REFUTED / UNKNOWN——也是为什么 @reidmarlow 的观察特别扎心：

UNKNOWN 退出码是我希望更多 Agent 工具复制的东西……让不确定性成为一种一级判决。

当证据无法支持结论时，我们就如实说出来，而不是悄悄教调用方一直重试直到仪表盘变绿。

我们用这三个答案做了什么

独立第三方审计（2 个关键 + 5 个重要发现），每个都逐条攻击关闭：先写出攻击，观察它通过，再做最小的修复来拒绝它。

一个五分钟挑战，让你自己验证——我们在一个仍然声称 VERIFIED 的交付物中精确改了一个字节，一条命令就能抓到它。

我们尚未解决的部分——因为我们的读者这样说了

评论区也是我收到过的最诚实的路线图：

@navid_gh_gh："复杂度无法接受……我希望这个过程是快的。"

@designbynaima："给每次工具调用都发密码学收据听起来会扼杀采用率。"

@skillselion："一个故意损坏的 fixture 会在两次 schema 迁移后变成一个仅仅是无效的 fixture"——腐烂问题。

这些不是反驳。它们是下一个里程碑。

我现在想问你一个问题

评论逼出了一个更好的问题。不是"我能信任这个 Agent 吗？"而是：

测试能因为正确的原因失败吗？——我能离线自己重新运行证据吗，不需要信任任何人的服务器？

如果你也带着这个问题，挑战只需五分钟：dev.to/dengyier/i-tampered-with-a-verified-ai-agent-delivery。

如果你踩过坑——"测试 green 但上线坏了"、"Agent 声称完成了但实际没有"——告诉我你怎么发现的。这才是我真正在收集的输入。