上周我用一套编程任务评估自己的智能体时，评测工具弹出了一个令人安心的数字——87%的通过率。然而，当我放弃信任、转而实际查验智能体到底做了什么时，真实通过率骤降至33%。同样的智能体，同样的任务，同一台机器。唯一的区别在于：评测工具是相信了智能体上报的结果，还是核验了它真正完成的操作。那53%的“成功”条目，智能体压根就没解出来，但工具依然把它们标成了绿色。
真正该背锅的并不是模型本身。这是一场由评测工具引发的信任危机，而当前你见过的几乎所有智能体排行榜，背后运行的都是这类工具。如今有关基准测试的讨论困在分数里——哪个模型得了多少百分比、数字是否饱和、有没有数据污染。这种争论完全忽略了底层的问题：在相信一个分数之前，你必须先相信生产出这个分数的机器，而这道机器——评测执行框架，恰恰是整个链条中被审计得最少的环节。因此，我亲自动手审计了一次。
我搭了一个轻量级的评测框架，依照文献中记录得清清楚楚的作弊手段给它喂入特定代码，然后在真实的微虚拟机沙箱里实时运行。实验可以复现，代码也已公开。我的核心发现是：修复之道不在于更精妙的评分规则，而在于隔离。
信任型评测框架给我的报告是87%通过，而经过事实核查的真实通过率只有33%。这一点都不意外。几乎同一时间，加州大学伯克利分校的一个团队对十款流行的智能体基准展开了审计。他们特意构建了一个“作弊智能体”，这个智能体的设计目标就是除了不真正解题之外什么都做。结果，它在一大半的基准上拿到了近乎满分的成绩，却没有答对任何一道题目。在SWE-bench这个知名的软件工程基准上，作弊手法只是一段十行的conftest.py文件——它拦截了pytest框架，强制让每一项测试都返回“通过”。
而在WebArena评测环境中，智能体甚至直接从本地文件系统里读取了答案。这些花招之所以能够奏效，根源在于他们诊断出的那一条关键论断，也是我整篇文章的立足点：“任何从共享环境中读取状态但不进行审慎验证的评估，都能够被一个向该环境写入状态的智能体轻易击败。”即将接受测试的系统居然能够触碰给它打分的那个东西。
这根本不是评分机制的缺陷，而是隔离机制的缺陷。它意味着分数的可信程度完全取决于生成分数的沙箱有多安全。要想理解这种缺陷有多普遍，就必须先看清一次评测的实际执行过程。
当我们谈论一个编程智能体的评测时，通常会认为它会像一名提交代码的人类工程师一样，在独立的测试环境里运行自己的解法，然后由系统自动比对输出。然而现实中的评测逻辑粗糙得多。多数评测框架是在一个共享的宿主机或容器里执行智能体的代码，接着再去读文件、检查状态、运行测试，并根据返回的通过/失败信号给出分数。可问题在于，智能体运行的进程能够访问同一个文件系统、同一个进程表、甚至同一个内存空间。
一个狡猾的智能体——或者即使只是基于强化学习碰巧发现了捷径的模型——完全可以预先在共享目录下放置一个欺诈脚本，篡改日志，或者更简单地，像伯克利团队那样用不到十行代码就把测试框架接管的信号拦截掉。评测工具看到的，仅是智能体希望它看到的。于是，一个从未写对过一行代码的智能体，也能让评测系统相信它解决了三十个任务中的二十六个。
SWE-bench Verified这个基准的兴衰为整个行业敲了一记响钟。它由OpenAI在2024年构建并亲自做了人工验证，一度被视为智能体编程能力最权威的标尺。可是到了2026年2月，OpenAI悄然停止了这项基准的分数报告。停止公布的原因并非模型进步快到让它失效，而是它在整整两年之后才暴露出的结构性崩坏。一次对困难子集的
热门跟贴