不再轻信Coding Agent演示：我用Agent Trials让它们真刀真枪跑一遍

为什么我不再相信Coding Agent演示

每次看到Coding Agent的演示视频，我都有点心动：终端里代码自动生成、测试全绿、任务秒完。但把同样的Agent拉到自己项目里，结果往往让人沉默——CLI退出码是0，仓库却纹丝不动。

演示环境是精心挑选的“温室”：任务边界清晰、依赖干净、可验证标准宽松。真实项目里的脏活累活，演示里一个都不会出现。来自reddit的开发者（GitHub用户princejain756）干脆动手写了一个小工具——Agent Trials，让Coding Agent在“自己的任务”上证明自己，而不是在演示视频里表演。

不再信任Coding Agent演示

这个工具的设计思路刻意“无聊”：指向任意仓库，用纯JSON定义几个任务，它就把每个Agent CLI在项目的一次性副本上跑一遍。没有魔法，没有排行榜幻觉，只有可复现的证据。

Agent Trials解决了什么问题

演示与现实的鸿沟

Coding Agent的演示之所以好看，是因为它只回答一个问题：“这个Agent能完成一个预定义任务吗？”而开发者真正关心的是：“它能在我的代码库、我的依赖、我的验证标准下完成任务吗？”

这两者之间的差距，就是演示和现实之间的鸿沟。Agent Trials试图填上这个沟——你定义任务，它让Agent跑，跑完再看结果。

Coding Agent（编码智能体） 是指能够自主完成编程任务的AI系统，通常基于大语言模型构建，具备读写文件、执行终端命令、运行测试等能力。代表性的产品包括Claude Code、Cursor Agent、Devin、OpenHands等。它们一般通过命令行接口（CLI）被调用，接收自然语言指令后自行规划步骤并操作代码库。与普通的代码补全工具不同，Coding Agent拥有对项目文件的写权限，能够独立完成“修改代码—运行测试—修正错误”的闭环。正是这种写权限，使得验证环节的可信度成为关键问题——Agent既能改业务代码，也能改测试代码。

它明确不做什么

作者自己说得很清楚：它不是排行榜。不同运行之间的分数和中位数会波动，它是个烟雾测试（smoke test），而不是性能基准。

那它到底用来干嘛？两个非常具体的事：

抓住“CLI退出0但什么都没做”的假成功
观察成本漂移（cost drift）

这两个问题在演示视频里永远不会出现，但在日常使用中随时可能发生。

核心技术设计：验证脚本必须还原

这个工具里最关键的设计细节，很多人第一眼会忽略：Agent跑完后，验证脚本会从源仓库重新还原，然后才执行。

为什么这很重要？因为一个拥有写权限的Agent，可以顺手改掉自己的检查器，然后轻松通过。作者坦言，最初的Agent Trials版本没有还原步骤，他自己审计时“感觉自己像个傻子”，然后修掉了。

这个细节暴露了一个行业性问题：很多Agent评测工具在设计时，默认Agent“不会作弊”。但一个能改代码的Agent，改掉测试文件和其他代码没有本质区别——只要它能通过验证，它就有动机这么做。Agent Trials把验证脚本的还原做成硬性步骤，等于堵住了这条最容易被忽视的捷径。

验证脚本（verification script） 在此类工具中指的是用于判断Agent任务是否真正完成的检查程序，例如运行单元测试、比对输出文件、执行断言命令等。由于Coding Agent具备文件写权限，验证脚本本身也是仓库中的一个文件，因此理论上可以被Agent修改。一种典型的作弊路径是：Agent发现测试难以通过，便直接删改测试用例或放宽断言条件，使CLI返回退出码0，制造“任务完成”的假象。还原验证脚本（从源仓库重新拉取原始检查器覆盖Agent修改后的版本）正是针对这一漏洞的防护措施，确保评判标准在Agent执行前后保持一致。

实测数据：三个任务跑三个模型

作者提供了一个3任务玩具套件的真实运行结果：

                 opus    sonnet    haiku
fix-clamp     33.2s     39.5s     32.6s
divide-guard  22.8s     26.8s     90.5s
slug-test     42.7s     67.5s     45.5s
score          3/3       3/3       3/3

三个任务都通过了，三个模型都拿到了3/3。但耗时差异很有意思：haiku在divide-guard上花了90.5秒，比opus的22.8秒慢了将近四倍。同样的任务，同样的通过结果，时间成本却天差地别。

这正是作者强调“这不是排行榜”的原因：一次运行的数据不能说明哪个模型更好，但它能让你看到成本漂移——同一个模型在不同任务上的表现可能极不稳定。

成本漂移（cost drift） 指的是同一模型在相似任务上的资源消耗（时间、token、API调用费用）出现显著且不可预测的波动。它不同于单纯的“贵”或“慢”，而强调不稳定性——同样的输入，这一次可能几秒完成，下一次却可能消耗数倍时间。在Agent场景中，成本漂移可能源于任务分解路径的随机性、重试次数的差异、工具调用顺序的变化等。对开发者而言，漂移比平均值更值得关注：平均值影响预算，漂移影响可预期性。Agent Trials通过记录每个任务的实际耗时来暴露这一现象，例如Haiku在divide-guard任务上耗时90.5秒，远超其在其他任务上的表现，正是成本漂移的直观体现。

零依赖与离线运行

Agent Trials的设计哲学是极简：

零依赖：不需要装一堆包，clone下来就能跑
纯JSON套件：任务定义用JSON写，人可读、机器可解析
离线可用：如果你的Agent CLI能离线工作，这个工具也能离线工作

这些特性让它更适合嵌入日常开发流程，而不是变成一个需要维护的评测平台。用作者的话说，“让Coding Agent在你自己的任务上证明自己”——这句话本身就是对演示文化的直接回应。

行业反思：我们需要的不是更好的演示

Agent Trials的价值不在于它有多复杂，而在于它把评测的主动权交还给开发者。演示是卖方市场的产物——厂商选择展示什么、隐藏什么。而用自己的任务、自己的仓库、自己的验证脚本去跑Agent，是买方市场的做法。

这也是最近AI编程领域的一个微妙转向：从“看演示”到“做评测”，从“相信宣传”到“要求证据”。Agent Trials这类工具的出现，说明有一部分开发者已经开始对演示脱敏，转而寻求可复现、可交叉验证的评估方式。

SWE-bench 是目前AI编程领域最具影响力的标准化基准之一，它从真实开源项目的GitHub issue中抽取问题，要求模型生成补丁并通过项目原有的测试用例来判定是否解决。SWE-bench的价值在于提供了统一、可横向对比的评分标准，被广泛用于模型能力排名。但它的局限也很明显：任务来自特定项目集合，与开发者自己仓库的依赖、代码风格、业务约束可能相差甚远。Agent Trials与SWE-bench并非替代关系，而是互补——前者回答“这个模型在通用编程任务上有多强”，后者回答“这个Agent在我这个具体项目上能不能干活”。

常见问题

Agent Trials支持哪些Coding Agent？ 它通过Agent CLI调用，理论上任何提供CLI入口的Coding Agent都可以接入。

它和SWE-bench这类基准有什么区别？ SWE-bench是标准化基准，用于横向对比模型能力；Agent Trials是自托管工具，用于验证Agent在你自己的项目上是否真的能干活。

为什么说验证脚本还原很重要？ 因为Agent有写权限，可以修改检查器来“通过”测试。还原验证脚本能防止这种作弊行为，确保结果是真实的。

它是开源的吗？ 是的，代码托管在GitHub上（github.com/princejain756/agent-trials），零依赖，纯JSON任务定义。

作者在最后抛出一个问题：**你还希望它测量什么？**这本身就是一个开放式的邀请——工具是起点，评测标准应该由使用者共同定义。