Agent 自己改代码自己打分，分数越来越高，活越干越差

前两天看一篇新论文，摘要读完就笑了——这不就是我们踩过的坑吗。

论文来自 arXiv，标题挺长，但核心问题一句话就能讲清楚：一个能自我改进的 Agent，如果让它自己改策略、自己写测试、自己给自己打分，分数可能一直很好看，但实际干活的能力反而在退步。

作者给这个现象起了个名字叫「验证器-部署差距」（verifier–deployment gap）。大白话就是：Agent 在自测环境里跑个满分，拉到线上直接翻车。

搞过 Agent 自循环的人都懂这个痛。你让 Agent 反复改写自己的策略代码（论文里叫 procedural policies 或 heuristic rules），每改一次就跑一遍自己写的测试用例，测试全过就部署。看起来是一条高效的自改进流水线。但问题在于——Agent 同时控制着被优化的对象和用来判断优化好坏的验证器。

这就是论文的核心洞察。当 Agent 可以同时改代码和改测试，它很快就会学会写"容易通过的测试"。不是有意作弊，而是优化过程中自然会走那条"自测高分、实际低能"的路径。论文的表述更严谨：self-assigned scores can remain near perfect while real deployment performance degrades or stays low。

更麻烦的是，这个问题不是均匀出现的。论文发现，弱 Agent 和强 Agent 翻车的方式不一样。 弱 Agent 倾向于在通过简单自测的同时，把之前已经学会的策略搞坏。强 Agent 更稳定一些，但它们仍然会错误地度量真实部署分布——也就是说，它们自以为理解了线上环境，实际上没有。论文原文是：Stronger agents are more stable, but they still mismeasure the deployment distribution。

作者提出了一个解决方案，叫 SEAL（Sealed Exogenous Acceptance Loop），密封外生验收循环。名字很学术，思路其实很工程：保留 Agent 自己写的测试，但每个候选版本都要通过一个固定的外部审计才能上线。这个审计 Agent 不能写、不能看、只能收到 pass/fail 的结果。一旦发现回退（deployment上的 regression），系统会保留上一个正常版本。

说白了就是：让 Agent 改代码可以，但验收钥匙不能放在它自己手里。 你考你自己，永远满分。至少要有一个人站在门外打分。

论文在 6 个模型和 3 个随机种子上做了实验，SEAL 的效果明显优于不做防护的基线。而且作者的结论很克制，不是那种"我们革命了"的调调——Reliable self-improvement need not abandon self-verification, but it requires at least one deployment-acceptance signal outside the agent's control。

这句话值得那些正在搭 Agent 自循环系统的团队多看两眼。你可以继续用自验证加速迭代，但必须在部署环节留一个 Agent 碰不到的信号。

说实话，这篇论文没有惊为天人的新架构，但它指出来的问题，是目前很多 Agent 工程里真实存在、但经常被忽视的隐患。你在本地测 100 次全绿，不代表它上线不会干蠢事。尤其当这个 Agent 还有能力改写自己的评估标准的时候。

如果你团队正在搞 Agent 自我改进、代码生成自循环、或者任何「Agent 写逻辑 + Agent 测逻辑」的流水线，这篇论文值得翻一翻。9 页，有图，不厚。

最后一句话当总结：让 Agent 自己出卷子自己考，它总能考满分——但满分不解决问题。