Agent 会用测试与验证技术吗？26 种指令条件的 Zstd 实现评测

软件质量似乎在变差，尽管编码 agent 用好测试技术比以往更容易达到特定质量线——这说明开发者默认用的方式可能不太奏效。Dan Luu 做了一个直接实验：给 agent 明确的指令，让它用特定测试技术或库，能不能提高实现正确性？

实验复用 Zstd 实现评测（Rust 实现），26 种 prompt 条件：TDD、属性测试（property-based testing）、差分测试、模糊测试、突变测试、元变形测试，以及形式化方法一族（ACL2、Alloy、Creusot、Kani、Lean 4、Verus、TLA+、Verus、SMT 求解器含 Z3/cvc5/Yices）等；另测了 4 个 skill（含 25 万 stars 的 ECC test skill、Trail of Bits 属性测试 skill 等）。所有实现用 Rust，每种条件与 effort 各 80 次运行取平均。

预注册预测

• TDD 会表现不佳（55% 置信）——作者特意加入 TDD 就是预期它不行；
• 形式化方法不会超常（52% 置信）——好的测试方法同样有效，简单问题上形式化方法不应碾压；
• "不要犯错"（Make no mistakes）不会优于无指令（95% 置信）——开玩笑式的提示，真有用早被人发现了；
• 大 skill 不会优于（低置信）——它们更像教程而非 agent 指令。

核心结果

• 没有东西真正碾压。但 Default（无额外指令）表现高于平均；
• xhigh effort 下，模糊测试与属性测试相关条件平均略好于形式化方法；medium 下情况更混杂；
• 推荐的测试 skill 普遍表现不佳，而作者自己写的短 skill 表现尚可（关键区别：自写 skill 是"把 agent 从默认行为推向更有生产力的行为"，其他 skill 更像教程）；
• TDD 果然不好（预测命中）。

Agent 实际在做什么

整体看，agent 不怎么会用这些工具或技术：要么在另一种技术框架里写它们平时会写的测试，要么表面使用技术但没做真正让技术产生价值的事。引用 Gary Bernhardt 的观察：agent 的测试方式是把 15 年前反对 mock 的人想象出的病态用例当成测试策略主干——过度 mock 的天真梦想。指名形式化方法时，它们大多证明不相关的性质（如"给定合法游标/索引/距离，操作保持界内"——不是 bug 来源），还经常写 A => A 的空证明。

一个典型失败模式：agent 经常搞反 encode/decode 的位流顺序，而测试因为回文结构检测不到——某种反转证明或许能让 agent 换一种思考方式。

实践建议

• 别只报库名或技术名：agent 拿到名字不会真正用好；要像自写 skill 那样"推离默认行为"，给出具体怎么做；
• 简单任务上形式化方法并不必然更好，先用便宜的模糊/属性测试；
• 用"Default + 针对性纠偏"作为基线，再验证加技术是否真提升，而不是默认"更先进的技术 = 更正确"。

来源：How well do agents use test/verification techniques? - Dan Luu