不稳定的测试（Flaky Test）对人类来说只是个小麻烦

在公司推行AI Agent自动化开发的时候，我发现一个很有意思的现象：很多原本在人类程序员眼里“没关系，重启一下就好”的不稳定测试，成了AI Agent的死循环陷阱。

人类在面对CI红了的时候，脑子里是有个“过滤网”的。比如资深开发知道某个集成测试在服务器负载高时偶尔会挂，于是他会叹口气，点一下重新运行，然后继续写代码。这种“经验主义”的过滤，让人们能迅速跳过噪音。

但AI Agent没有这种“潜规则”。在它的逻辑里，红条就是错误，绿条就是通过。它没法去问组长“这个测试是不是又抽风了”，也没法记得上周二这个报错其实是数据库没预热。它会极其认真地试图去“修复”那个根本不存在的Bug，结果导致代码被改得面目全非，陷入一个死循环：修复噪声 → 引入真Bug → 再次修复 → 崩溃。

这就是为什么在构建AI Agent工作流时，测试套件的确定性比什么都重要。

如果你正准备在团队里部署类似的自动化流程，建议从以下几个维度优化你的测试环境：

• 彻底清理不稳定测试： 那些偶尔失败的测试必须要么被修复，要么直接从Agent的运行路径中剔除。
• 强化确定性环境： 使用容器化隔离，确保数据库、时区等外部依赖是完全可控的。
• 建立显式标记： 如果某个测试确实不稳定且暂时无法修复，不要指望在Prompt里告诉AI“忽略它”，而应该在代码层面将其标记为 skipped 或 flaky，让Agent在运行逻辑中直接跳过。

说到底，AI Agent的强大在于它从不厌倦、不跳步，但这把双刃剑在面对噪声信号时会反噬。把测试套件当成给Agent的API，API如果返回随机结果，那这个系统绝对没法落地。