Momentic工程师：AI编码代理不应自行验证代码

2026年11月13日 你的编程Agent不该给自己的作业打分

AI编程Agent如今能写设计文档、做前端原型，还能端到端实现整个项目。但能不能信任它们去验证自己写的代码真的能跑？

我在Momentic带领一个八人的工程团队，团队很早就积极采用了后台Agent。我的团队常常惊叹于这些前沿模型的原始智能，但也经常抱怨：Agent会信誓旦旦地宣布某个功能已完成，结果他们打开应用一测，基本功能就挂了。

问题不只是Agent会犯错。问题在于，它们自己的验证往往抓不到这些错误，于是导致过度自信。

具体来说，我们工程团队发现了三个反复出现的问题：Agent依赖浅层检查、继承自身的实现盲区，以及在上下文不断膨胀和反复失败的双重压力下变得越来越不可靠。

编程Agent倾向于选择容易写、也容易通过的检查。这通常意味着单元测试。

单元测试有其价值，但测试全绿并不代表软件能端到端跑通。

在Momentic，我们最近对monorepo中1,000个AI编写的单元测试做了一次人工审核的审计。结果：只有9.6%是有用的验证检查。

剩下90.4%几乎没有提供什么有意义的价值。近三分之一是低后果的测试，只检查基本的参数传递或格式化。另有22.8%重复了已有的覆盖，还有22.4%过度依赖mock，无法真实反映生产行为。

我们的发现并非孤例。在最近的一项实验中，AI研究员Kun Chen对比了允许自己写测试的编程Agent和被明确禁止写测试的Agent。

在111个编程任务中，自己写测试的Agent成功率为65.3%，而不写测试的为66.2%。

这并不意味着单元测试整体上没用。它意味着，Agent可以写出大量单元测试，得到看似令人安心的结果，却仍然无法验证真正重要的行为。

当工程师写一个功能时，他们首先会形成对要构建什么的理解，然后基于这个理解做实现决策。

表面上看，编程Agent的工作方式类似。问题在于，当它们自己写测试时，这些测试反映的是与实现阶段相同的、可能本身就错误的假设。

举个例子，假设你让Agent做一个富文本编辑器。它实现了加粗、斜体和下划线格式化，然后为这些按钮创建了测试。

但也许你从未指定撤销按钮也应该撤销已应用的格式。尽管这对人类来说理所当然，但如果这些场景在最初的提示中没有被明确考虑，那么它们大概率也不会出现在Agent的测试里。

说到这一点，2026年一项关于编程Agent验证的研究发现，Agent为自己补丁写的测试经常接受错误的实现。

所以问题不是Agent写不出有效的测试。问题是它们往往测试的是自己构建的东西，而不是应该构建的东西。

现代编程Agent可以自主运行数小时。在此期间，它们积累大量上下文：源文件、终端输出、截图、调试日志等等。

这带来了另一个问题。Agent在一个任务上工作得越久，就越难把原始需求与过程中做出的所有决策区分开来。尽管Agent可以压缩上下文，但原始材料永远无法以完美的保真度保留下来。

Chroma 2025年的Context Rot研究评估了18个LLM，发现随着上下文增长，性能急剧下降。在一项实验中，当上下文从300个token增加到113,000个token时，Claude Sonnet 4的准确率从89%骤降到仅38%。

Anthropic也对此做过自己的研究。

在今年4月进行的一项研究中，Anthropic给Claude Sonnet 4.5布置了带有不可能满足要求的编程任务。研究人员分离出一个特定的“绝望”向量，它在每次失败尝试后都会增强，当模型考虑作弊以通过测试时达到峰值。一旦测试通过，该激活就消退了，即使解决方案是错误的。

这并不意味着模型真的会感到绝望，或者它们一直在作弊。但它确实表明，反复失败如何能把Agent推向提前宣布完成，而不是全面验证。

那么，如果不是Agent自己来验证，那该由谁来？

在Momentic，我们转向了另一种方法：把写软件的Agent和负责测试它的Agent分开。

我们不再让编程Agent评估自己的工作，而是给一个独立的QA Agent提供原始需求和对运行中应用的访问权限。它还可以访问远程浏览器集群和远程移动设备，以高效地并行测试。

QA Agent不继承编程Agent的对话历史，甚至不知道实现细节。它从全新的上下文开始，只有一个干净的目标：找bug。

这里有三个重要原则在起作用：

第一，行为在现场验证，绝不推断。验证器不依赖静态分析、单元测试或mock的集成测试，而是通过真实的浏览器或移动设备执行真实的用户工作流。这确保“已验证的行为”与人类实际体验到的真正1:1一致。

第二，验证器完全独立。编程Agent无法控制验证器的验收标准，也无法修改测试来让任何失败消失。验证器返回可复现的bug报告，编程Agent甚至人类开发者都可以在pull request上高效理解。这也防止了reward hacking，并建立了对审查流程的信任。

（原文较长，此处译出前 6000 字，完整内容请点「打开原文」。）