跑一个AI智能体到底要花多少钱：这个数字可能会吓到你

先说一个具体的数字。

在SWE-bench Verified这个评测集上，让一个顶尖大模型跑一遍完整测试，光是模型调用费用就要花掉几百美元。如果换成SWE-bench Multimodal这样步骤更长的评测，单次跑完能烧掉超过2200美元。这还只是一次评测。

如果你是做AI智能体研发的团队，这个数字意味着什么？意味着你每改一次提示词、每调一次工作流程、每换一个底层模型，都要重新掏出几百甚至上千美元去验证效果好不好。一个开发周期里跑个几十次评测很正常，几百美元乘以几十次，账单很快就滚到让人肉疼的地步。

这篇来自上海交通大学、新加坡管理大学等机构的论文，就是奔着这个钱包痛点去的。

**评测贵，贵在哪**

*智能体（Agent）*：一种能自主执行多步骤任务的AI系统，通常由一个底层大语言模型加上具体的操作框架（比如读文件、跑命令、调工具）组成，业内也称为"脚手架（scaffold）+ 模型"的组合。

智能体评测和普通问答测试不一样。问答题问一句答一句，成本可控。但智能体要解决一个真实的软件问题，得先读代码、跑测试、发现报错、改代码、再跑测试，这个循环可能要来回几十次才能收尾。每一步都要调用一次大模型，步骤越多，账单越厚。

在这之前，学术界已经想过办法降成本，思路是"减少要测的题目数量"。比如从500道题里挑出几十道有代表性的，跑这几十道就能大致猜出跑全部500道的分数。这类方法统称为*基准蒸馏（benchmark distillation）*：通过筛选或压缩评测任务集合，用更少的题目逼近全量评测的结果。

这条路确实有效，但它只解决了"测多少题"的问题，没有碰"每道题测多久"这件事。就像你要检查100份作业，蒸馏方法帮你把100份压缩成20份抽查，可这20份作业你还是得从头看到尾。这篇论文琢磨的是另一个方向：能不能不看完整份作业，看到一半就知道这道题对不对？

**一个真实案例揭开的秘密**

研究者们翻出了一条公开的智能体运行记录，任务是修复tianocore/edk2-pytool-library项目里的一个路径处理bug。整个过程跑了45步才提交最终答案，但仔细看这条轨迹会发现一件有意思的事。

第20步，智能体写了个脚本复现了bug。第23步，它对源代码做了唯一一次修改，把路径分隔符改对了。从第23步之后一直到第45步，智能体再也没碰过源代码，剩下的22步全在各种测试和折腾。

如果有个"上帝视角"的观察者，手里拿着标准答案，在第23步就能看出这个修改是对的，任务已经实质性完成了。剩下的22步，说白了就是在原地打转。

这个发现戳中了一个反直觉的事实：我们默认智能体的评测必须等到它自己喊"提交"才算数，但实际上，胜负手往往在中途就已经写定了，只是没人在那个时刻按下暂停键。

**EarlyEval：给智能体装一个提前下课的铃**

基于这个观察，研究团队提出了EarlyEval，核心思路很简单：训练两个"裁判"，一个专门识别"这局要赢了"的信号，一个专门识别"这局要输了"的信号，边跑边判，一旦某个裁判拿到足够把握，就直接喊停，把预测结果当成最终成绩。

这两个裁判用的是*LightGBM*：一种基于决策树集成的机器学习算法，训练和预测速度极快，能在单个CPU核心上不到一毫秒内处理几百个维度的特征，非常适合需要频繁打分的场景。

为什么是两个独立的裁判，而不是一个又判赢又判输的裁判？研究者的解释是，成功和失败的信号往往是不对称的。判断"这题稳了"需要看到正确的修复代码被写下来；判断"这题凉了"则要看智能体是不是在原地反复重试同一个错误、面对同样的报错信息死循环。这两种模式长得完全不一样，混在一起训练反而会稀释信号。

这就好比考试监考老师同时要盯两件事：谁提前写完卷子快步走出考场（大概率会做），谁在最后十分钟还在疯狂翻书找不到答案在哪页（大概率要挂）。这是两种完全不同的肢体语言，用同一套标准去识别，反而两种都识别不准。如果不这样拆开训练，论文的架构消融实验显示，用单一线性模型去同时判断成功失败，在SWE-bench Verified上的准确率只有43.8%，误差高达5.5个百分点，基本没法用。

**裁判靠什么信号做判断**

EarlyEval给两个裁判喂了三类食粮。

第一类是行为特征，覆盖了37种活动计数（比如智能体一共读了几个文件、改了几次代码、跑了几次测试）、最近一步的操作类型、关键事件的发生时间（第一次报错在第几步、第一次通过测试在第几步）、还有一些能反映"卡住"的信号，比如反复搜索同一个东西、连续多次只读不改。这一类特征加起来一共115个维度。

第二类是文本特征，把任务描述、动作历史、环境反馈这些自然语言内容，用*TF-IDF（词频-逆文档频率）*：一种衡量词语在文档中重要程度的经典文本表示方法，常用词权重低，特有词权重高，转成数字向量，再压缩成低维表示，一共320维。

第三类是参考解特征，只有当评测集公开了标准答案（比如SWE-bench Verified提供了官方补丁）时才能用，衡量智能体当前修改和标准答案在文件、函数名、测试用例上的重合程度，一共82维。

这里有个细节值得说一说。研究者发现，即使完全去掉第三类参考解特征，性能损失也很小，覆盖率只从34.8%掉到32.1%，节省的步骤只从26.0%降到24.7%。也就是说，行为特征和文本特征已经能撑起大部分判断力。这个发现很重要，因为很多评测集根本不公开标准答案，比如论文里测试的TerminalBench和Toolathlon就没有官方补丁，如果方法严重依赖参考解，这些评测集就用不上了。

**三个战场的实测结果**

研究团队在三个评测集上验证了EarlyEval：SWE-bench Verified（软件问题修复，500道题）、TerminalBench（命令行自动化操作，89道题）、Toolathlon（复杂工具调用，108道题）。为了模拟真实场景，采用的是"留一法"评测协议，也就是训练时故意藏起一个智能体不让它参与训练，专门拿它来测试预测准不准，避免"考试作弊"式的数据泄漏。

结果显示，在SWE-bench Verified上，把判断阈值设到0.95（意味着裁判要有95%的把握才敢喊停），能提前终止约35%的运行，准确率95.0%，节省26.0%的执行步骤，输入token省了32.7%，输出token省了28.7%，而最终测出来的成功率只比真实值偏差1.1个百分点。

在TerminalBench和Toolathlon上，即便在更严格的"训练集里连模型和框架都不能出现"的双重隔离条件下，依然能节省13%到26%的步骤，准确率维持在89%到97%区间，成功率偏差控制在2个百分点左右。

更让人意外的是排行榜的稳定性。研究者用EarlyEval跑出来的分数重新排了一次智能体的名次，和跑完整流程排出来的名次做对比，SWE-bench Verified上的排名相关系数达到0.991（满分1.0代表完全一致），16个智能体里有81%的名次分毫不差。哪怕是最难的TerminalBench无重复模型场景，相关系数也有0.959。

这意味着什么？意味着你不需要为了在排行榜上争一个准确名次而把每次评测都跑到底，早停版本给出的排序结论基本可信。

**和其他判断方式比一比**

论文还做了一组对照实验，把LightGBM换成其他架构，看看谁的性价比最高。

换成多层感知机（MLP，一种简单的神经网络），准确率掉到87.9%，节省步骤只有20.0%，成功率偏差涨到3.3个百分点，全面落后。

换成直接对密集特征做逻辑回归，准确率只有43.8%，几乎是瞎猜。

换成只对TF-IDF文本特征做逻辑回归，准确率倒是有79.5%，但触发条件太苛刻，只在2.4%的运行里敢下判断，等于基本不干活。

最有意思的对照组是用一个经过LoRA微调的小型语言模型（Qwen-0.5B）直接当裁判，读原始轨迹文本做判断。这个方案准确率90.7%，成功率偏差只有0.8个百分点，表现相当不错，但它的节省步骤只有17.9%，明显比LightGBM的26.0%少。原因很简单：用语言模型当裁判，每一步都要跑一次模型推理，这个推理开销本身就要花钱花时间，相当于为了省钱又多花了一笔钱，把省下来的部分吃掉了一半。

这就好比雇一个专家每隔五分钟就来检查一次工地进度，专家判断很准，但专家的工时费本身就不便宜，检查得越勤，请专家的钱花得越多，反而抵消了提前收工省下的材料费。LightGBM便宜就便宜在它判断一次几乎不要钱，可以随时随地插一脚看一眼，不心疼。

**这套方法的边界在哪**

论文也很坦诚地说明了适用条件。EarlyEval需要一批已经跑完、带有真实结果标签的历史轨迹数据来训练裁判，这对成熟评测集不是问题，因为公开评测集通常会积累大量历史提交记录和排行榜数据。但如果是一个全新发布、还没有任何人跑过的评测集，这套方法就无从下手，因为没有历史数据可学。

另外，研究者特别强调，EarlyEval提前预测的分数存在1到2个百分点的系统性偏差，不适合用来生成正式发布、要被引用的权威评测成绩。它的定位更像是研发过程中的快速反馈工具，帮团队在频繁迭代阶段快速判断改动是好是坏，等到要出正式榜单的时候，还是应该老老实实跑完整流程。

写在后面

读完这篇论文，我最触动的一点是它揭示了一个我们平时容易忽略的事实：结果的确定性和过程的完成度，其实是两件可以分开的事。

我们习惯性地认为，要知道一件事的结果，就必须等它彻底做完。但这篇论文用实打实的数据证明，很多时候答案早就写好了，只是流程还在惯性地往前走。这个观察其实可以推广到很多场景，比如面试官在候选人回答到第三句话时其实已经心里有数了，剩下的十分钟对话更多是走流程；比如产品经理在看到用户测试的前五个反馈时，其实已经能猜到这个功能大概率会失败。

另一个让我意外的细节是，参考答案居然不是最重要的信号。直觉上，有标准答案对照肯定能判断得更准，但实验数据显示去掉参考解特征只损失了一点点性能。这说明智能体在"要成功"和"要失败"时展现出来的行为模式本身就足够独特，识别这些模式甚至不需要知道正确答案是什么，就像一个经验丰富的老师，光看学生做题时的犹豫和反复，不用对照答案也能大致猜出这道题他会不会做。

这篇论文没有解决的问题是，如果一个全新的评测集刚刚发布，还没有任何历史数据积累，这套方法就用不上。对于快速迭代、评测集本身也在频繁更新的领域，这个冷启动问题恐怕会一直存在。

Q&A

Q1：EarlyEval是什么？

A：EarlyEval是一个通过预测智能体最终结果来提前终止评测运行的框架，它训练两个LightGBM分类器分别判断"任务成功"和"任务失败"的信号，一旦置信度达标就提前喊停，从而节省评测所需的计算成本。

Q2：EarlyEval会不会影响评测结果的准确性？

A：会有轻微影响，但幅度很小。论文数据显示，在多个评测集上，EarlyEval预测出的成功率与真实完整跑完的成功率相比，平均偏差只有1到2个百分点，同时排行榜名次相关系数保持在0.959以上。

Q3：EarlyEval适合什么场景使用？

A：它适合智能体研发过程中的频繁迭代评测，比如反复调试提示词或调整框架时的快速反馈，但不适合用来生成正式发布的权威评测成绩，正式榜单仍建议跑完整流程。