最近 AI 编程工具越来越多，大家做横评的时候也越来越容易陷入一个问题：看起来数据很多，最后却不知道到底在比什么。

有的直接比 BUG 找出了多少个，有的比任务跑了多久，有的拿一个 Demo 跑完就宣布“效率提升多少倍”。更常见的是，两边用的模型、上下文、人工提示次数都不一样，最后得出一个 Agent A 比 Agent B 强的结论。

这种测试看着热闹，但严格来说，很难说明问题。

最近看了润迅关于 XunOPC 的一次 Agent 对照测试，我反而觉得其中比较值得聊的不是最后谁高了 1 分，而是AI 编程 Agent 到底应该怎么测。如果以后这类工具真的要进企业开发环境，这套评测思路可能比单纯看排行榜更有意义。

先把模型锁死，不然你测的根本不是 Agent

这是我觉得最容易被忽略的一点。

现在很多所谓 AI Coding Agent，本质上都是“模型 + 工具调用 + 上下文管理 + 任务编排 + 执行环境”的组合。底层模型本身的能力差异非常大，所以如果 A 用一个模型，B 用另一个模型，最后拿结果直接比较，很难判断差异究竟来自模型，还是来自 Agent 系统本身。

润迅这次测试采取的办法比较直接：两端统一锁定 deepseek-v4-flash，从代码检查、问题定位一直到修复和验证，中途都不更换模型。

这个条件一锁，很多东西才有比较价值。

因为模型变量被拿掉之后，剩下比的才是 Agent 自己的能力：怎么拆任务、怎么读项目、什么时候调用工具、怎么判断风险、改完以后怎么验证，以及出现异常以后怎么继续往下走。

这其实和测数据库、编译器甚至硬件 Benchmark 是一个道理。你不能一边 CPU、内存、系统环境全换了，一边最后告诉我某个软件快了 30%。

控制变量，是所有 Benchmark 最基本的前提。

不要拿十几行代码测试“自主编程”

另一个我非常认同的点，是别再拿玩具项目测试 Agent。

让模型看几十行 Python，然后问一句“这里有什么 BUG”，这最多只能测试模型有没有读懂这段代码，离真正的软件工程还有很远。

真实项目不是一道 LeetCode。

它可能有前端、后端、依赖、配置、构建脚本、数据库、接口调用，甚至还有历史遗留代码。一个 BUG 最后可能横跨几个模块。

原测试使用的是一个 826 个文件的 Java 后端 + Vue3 前端多模块工程，任务也不是简单的“找到 BUG”，而是要求 Agent 独立完成：

检查 BUG → 判断高危问题 → 修改 → 验证。

这就开始接近真实开发环境了。

因为企业真正关心的并不是：

AI 能不能告诉我这里写错了？

而是：

我把一个完整任务交给它以后，它到底能不能自己把事情做完？

这两个问题完全不是一回事。

最狠的一条：测试过程中，人不要救它

这一点可能会让很多 Agent 的 Demo 当场失效。

测试过程中不应该不停地给提示。

比如 Agent 找错方向了，人告诉它“你看看这个目录”；编译失败了，人告诉它“换个命令”；修错文件了，再提醒一句“问题应该在后端”。

这么测当然也能把任务完成，但最后测出来的其实是：

一个熟练工程师带着 AI 能不能完成任务。

而不是 Agent 本身能不能完成任务。

所以这次测试里设置了一个很重要的条件：**全程 0 人工介入。**任务发出去以后，不纠偏、不补充信息、不重新提示。

我觉得以后评价 Agent，“人工介入次数”甚至应该直接变成一个标准指标。

因为同样都是“任务完成”，一个 Agent 自己跑完，和一个 Agent 中间被人救了 7 次，完全不是一个级别。

一个总分，根本解释不了 Agent 强不强

现在各种 AI 榜单最喜欢给一个数字：

87.6 分。

看着很科学，但你根本不知道这 87.6 到底意味着什么。

如果真正从工程角度评价 Agent，我觉得至少应该拆开看几个维度。这次 XunOPC 的评测拆成了八项：

完成率、总耗时、人工介入次数、结果质量、可追溯性、可控性、可复用性、使用成本。

这里面有几个指标其实比“代码写得快不快”重要得多。

比如结果质量。

代码改完能编译，不代表真的修好了；修好了当前 BUG，也不代表没有顺手制造三个新 BUG。所以最后一定要有验证过程。

再比如可控性。

Agent 如果准备执行删除、批量覆盖或者其他高风险操作，系统到底能不能发现并拦下来？

还有一个我觉得企业以后一定会越来越关注的东西：可追溯性。

Agent 最大的问题，不是犯错，而是不知道它怎么犯的

人写代码出了问题，至少还能 Git Diff。

Agent 真正进入工程环境以后，问题会更复杂。

它可能连续读几十个文件、执行命令、调用工具、修改多个模块，最后告诉你一句：

“已经修复。”

那企业敢直接信吗？

肯定不敢。

所以我越来越觉得，未来企业选 Agent，“聪不聪明”只是一部分，另一部分是出了问题之后能不能查。

至少应该能回答这些问题：

它看过哪些文件？

执行过哪些操作？

为什么改这里？

到底改了哪几行？

哪一步开始偏离预期？

修改能不能撤销？

如果这些东西完全看不到，Agent 越自主，风险反而越高。

这也是为什么 XunOPC 这类产品一直在强调 Worktree、Diff、执行记录和可回放。不是为了把界面做复杂，而是因为 Agent 一旦真的开始动代码，工程系统必须留下证据链。

还有一个很有意思的结果：不同 Agent 看到的“问题”可能完全不一样

这次同模型对照测试还有一个数据挺有意思。

一端检查出了 20 项问题，其中 4 项高危；另一端检查出 14 项，其中 3 项高危，但双方真正重合的问题只有大约 2～3 项。

也就是说，即便模型完全一样，不同 Agent 的任务编排方式、工具链和工程判断方式，也会让它们把注意力放在完全不同的位置。

一个偏前端，一个偏后端。

这反而说明了一件事：

Agent 不是简单给大模型套一个 IDE 壳。

真正产生差异的，很可能恰恰是模型外面的东西。

怎么扫描工程、先看什么文件、什么时候扩大上下文、如何使用终端、如何验证自己的判断、什么时候认为任务已经结束，这些最后都会影响结果。

这也是为什么只比较“大模型能力”已经越来越解释不了 AI Coding Agent 的实际体验。

Benchmark 最重要的不是证明自己第一

最后还有一点我挺认可。

这次八项指标加起来，两端最终是 37 分和 38 分，只差 1 分。

如果按照传统宣传稿的写法，这种数据其实不太“好写”。

但反过来看，这反而更像一次正常实验。

一次测试、一个真实项目、一个模型，本来就不应该直接推导出“谁永远更强”。

n = 1 就是 n = 1。

Benchmark 真正有价值的地方，不是想办法证明自己赢，而是把模型版本、项目规模、任务条件、人工介入情况、评分标准都摆出来，让别人可以重新跑一次。

别人能够复现，也能够质疑，甚至有机会把你的结论推翻，这才叫测试。

否则所谓“领先 30%”“效率提升 5 倍”，最后很容易变成另一种营销素材。

写在最后

AI Coding Agent 已经开始从“帮我补几行代码”走向真正执行工程任务。

到了这个阶段，我觉得评测方法也必须跟着升级。

以后再看到一份 Agent Benchmark，我大概会先看五件事：

是不是同一个模型，项目是不是真实项目，中间有没有人工救场，指标有没有拆开，以及整个执行过程能不能追溯。

这五个问题交代不清楚，后面的分数再精确，也只能看看。

反过来，如果把这些变量全部钉死，哪怕最后两个产品只差 1 分，这个结果反而比一句“遥遥领先”更有参考价值。

因为 Agent 真正进入生产环境以后，我们需要的从来都不是一个永远不会犯错的 AI。

而是一个出了问题以后，知道它做了什么、为什么这么做，而且随时能够检查和撤回的工程系统。