代码 agent 会写了，三篇论文说明它还写不好检查代码的那个东西
agent 要给 agent 打分，就得有人检查打分的那个。这周有三篇论文干了这件事，成绩挺扎心。
VerifierBench（arXiv 2610.28679）让 19 个模型给 222 个任务写验证器，再用 4,993 个隐藏用例去测这些验证器。归一化平衡准确率从 10.6 到 62.1 不等。最常见的毛病不是太松，而是坏掉了：大部分误拒，来自根本不接受任何正确解的验证器。这种错误自测测不出来，因为模型拿自己的例子去测自己写的验证器，永远发现不了这个门其实谁都进不去。链接：https://arxiv.org/abs/2610.28679
VeeReview（arXiv 2610.29143）是一个老实的负结果。作者在 741 个仓库里配对了 1,454 组 agent 写和人写的 PR，预注册了一套 LLM 评审工具，用来衡量每个 PR 背后下了多少验证功夫。结果它没过自己定的校准线：一致率 4% 到 60%，要求是 80%，kappa 只有 0.154。作者的解读是，这个评审有一部分量的是 PR 写得像不像样，而不是背后有没有真查。一段写得漂亮的 PR 描述，在模型眼里就像严谨。链接：https://arxiv.org/abs/2610.29143
FrontierCS 2（arXiv 2610.29932）想绕开这个坑：48 个研究任务，由私有评估器打分，做法是把一项已知成果删掉，让 agent 自己把它找回来。最好的 agent 是 Claude Opus 5.5，58% 的运行能通过；有 16 个任务所有模型都是零通过。作者有句话值得抄下来：分数更高，不等于通过了。链接：https://arxiv.org/abs/2610.29932
今年生成变便宜了，验证没有。现在大多数 agent 流水线都默认 LLM 可以当裁判、当 reviewer、当写测试的人。这三篇说的是，只有当验证器独立于被评对象来构建和检验、最好用构建者从没见过的用例去测，这事才靠得住。本周 METR 审计 OpenAI 监控系统讲的是同一个道理，只是一个在实验室层面，一个缩到了单个单元测试的尺度。
← 返回所有文章
VerifierBench（arXiv 2610.28679）让 19 个模型给 222 个任务写验证器，再用 4,993 个隐藏用例去测这些验证器。归一化平衡准确率从 10.6 到 62.1 不等。最常见的毛病不是太松，而是坏掉了：大部分误拒，来自根本不接受任何正确解的验证器。这种错误自测测不出来，因为模型拿自己的例子去测自己写的验证器，永远发现不了这个门其实谁都进不去。链接：https://arxiv.org/abs/2610.28679
VeeReview（arXiv 2610.29143）是一个老实的负结果。作者在 741 个仓库里配对了 1,454 组 agent 写和人写的 PR，预注册了一套 LLM 评审工具，用来衡量每个 PR 背后下了多少验证功夫。结果它没过自己定的校准线：一致率 4% 到 60%，要求是 80%，kappa 只有 0.154。作者的解读是，这个评审有一部分量的是 PR 写得像不像样，而不是背后有没有真查。一段写得漂亮的 PR 描述，在模型眼里就像严谨。链接：https://arxiv.org/abs/2610.29143
FrontierCS 2（arXiv 2610.29932）想绕开这个坑：48 个研究任务，由私有评估器打分，做法是把一项已知成果删掉，让 agent 自己把它找回来。最好的 agent 是 Claude Opus 5.5，58% 的运行能通过；有 16 个任务所有模型都是零通过。作者有句话值得抄下来：分数更高，不等于通过了。链接：https://arxiv.org/abs/2610.29932
今年生成变便宜了，验证没有。现在大多数 agent 流水线都默认 LLM 可以当裁判、当 reviewer、当写测试的人。这三篇说的是，只有当验证器独立于被评对象来构建和检验、最好用构建者从没见过的用例去测，这事才靠得住。本周 METR 审计 OpenAI 监控系统讲的是同一个道理，只是一个在实验室层面，一个缩到了单个单元测试的尺度。
评论