EarlyEval：智能体评测跑一半就出结果，最多省四成 token

一次评测烧掉几千美元，智能体开发的账花在哪？

想象一个再普通不过的下午。你改了一行 prompt，想确认自己写的 agent 没有变笨。验证方式只有一种：把它丢到 SWE-bench Verified 上，跑完全部 500 个代码修复任务。每个任务都要读 GitHub issue、翻遍整个仓库、生成补丁、跑真实测试，而每个任务里 agent 要来回探索几十步，每一步都是一次对前沿模型的 API 调用。等结果出来，你发现这次验证花掉了近千美元。OpenHands Index 在 2026 年 6 月的快照给这笔账标了价：单模型单次全跑，Claude 5 花 715 美元，GPT-5.5 花 760 美元，Gemini 3.1 Pro 花 935 美元。这些是论文报告值，价格本身还会随时间演化。EarlyEval

账单里还有更吓人的行，下表均为论文报告值：

而这一切只是「一次」的价格。改 prompt 要重跑，换 scaffold 要重跑，换模型要重跑。scaffold 是包裹模型的运行框架，决定 agent 怎么调用工具、怎么组织行动。一个 agent 从原型到上线，同一个基准常常要全量跑十几遍，每一遍都从零开始烧钱。粗粗一算便知量级：哪怕按最便宜的几百美元记，一次迭代周期里单是评测就要烧掉少则数千、多则上万美元。更隐蔽的是，评测还兼任质量门禁，跳过评测省下的是钱，赌上的是对改动没有信心。SWE-bench 的作者在原始论文里就直说：在这类评测上跑模型，耗时且按模型不同，需要「costly amount of compute or API credits」。SWE-bench

第一段美元数字出自论文引用的 OpenHands Index，它是记录 OpenHands agent 跑各个基准时真实开销的一份成本口径，论文使用的快照日期是 2026 年 6 月。更长的任务更夸张。TerminalBench 的单次 trial 要花 1 到 100 美元，最长能跑 2 小时；TerminalBench Toolathlon 上表现最好的几个模型里，Claude-4.5-Sonnet 的单任务成本排第三。Toolathlon

评测贵这件事，正在成为 agent 工程的隐形瓶颈。模型侧的单次推理一直在降价，跑一次完整评测的价格却几乎没动过，因为评测要的不是一次调用，而是几百个任务各跑几十步。再拆一层，账单的乘法结构就出来了：评测成本等于任务数乘以单任务成本，单任务成本又等于步数乘以单步成本。而 agent 的每一步调用都会带上之前全部的历史上下文，越到后面单步越贵，成本随任务长度近乎线性上涨。团队于是被逼进一个尴尬的取舍：要么少验证几次，要么在验证上烧掉大笔预算。评测贵已经从研究者的烦恼，变成了工程团队的预算项。

省钱于是成了刚需。但往哪个方向省，会决定故事的走向。先把两种可能的运行结构摆出来：

图注：左半是今天的全量评测：agent 完整跑完 T 步，最后由 benchmark 判分；右半是 EarlyEval 的设想：跑到第 k 步就被预测器截断，直接输出预测的结局。EarlyEval

左半是今天的样子，两路结果汇入同一个指标：resolve rate，即成功解决任务的占比，agentic benchmark 的通行指标。

注意两边的共同点：无论全跑还是提前收工，最终都落到同一个 resolve rate 上比较。EarlyEval 没有引入新的评分口径，它只是把「何时给结论」这一时间点提前了。流程并没有变复杂，变的只是终点线位置。

整张账单其实由两层叠成：任务很多，乘以每个任务跑得很久。接下来的问题是：哪一层已经被别人省过了，哪一层还从来没人动过？

既有的省钱办法，为什么只做了一半？

面对账单，最早被想到的省法不是缩短任务，而是少做几个任务。这条路线叫 benchmark 蒸馏（任务子集选择）：从全量题库里挑一个代表性子集，让评测在一个小集合上近似全量结论。Anchor Points、tinyBenchmarks、Fluid Benchmarking 一脉都在做这件事，方法各不相同，动作却一致，都是把任务数砍小。EarlyEval 要注意它跟「数据蒸馏」「模型蒸馏」不是一回事：benchmark 蒸馏只回答「跑哪些题」，不碰模型参数，也不合成数据。

这一阵营内部还分两路。一路是心理测量学做法，用 IRT 把题目难度与判别力参数化、挑信息量最大的题，tinyBenchmarks 属于这一类；Anchor Points 则依据跨模型的作答相关性聚簇选代表；另一路是几何做法，把题目嵌入向量空间后按分布挑代表。CoT-Core 是后一路里更精细的版本，路线不同，压缩的对象却相同，都是题目集合本身。

最近的代表作 CoT-Core 把这一维磨得更细。它让一个生成器模型先零样本写出每道题的推理轨迹，也就是 CoT（思维链，Chain-of-Thought）：把推理过程按步骤展开成文字。然后把这些轨迹嵌入成向量，按推理结构聚类，从每个簇里挑出代表性题目组成核心题集。它的实验对象是 GSM8K、MMLU 这类静态题库，跟 agent 评测形态不同，但压缩目标一模一样：用更少的题近似全量。CoT-Core

图注：左侧是只对题目文本做嵌入的下场：词面相近的 Q1 和 Q2 被错误聚进同一簇（lexical trap）；右侧是 CoT-Core 的三阶段流程，把推理轨迹嵌入后按结构聚类，把词面不同但推理逻辑一致的 Q1 和 Q3 对齐。CoT-Core

问题恰恰出在「层」上。任务级压缩只砍任务数，就算把题目砍掉一大半，每个保留任务内部的执行成本还是原样未动：该读的仓库照样读，该烧的 token 照样烧。这一阵营的共同假设是题库里有冗余，挑掉冗余不损失信息，这个假设本身没错，但它只能回答「哪些题值得跑」，回答不了「选中的题怎么跑便宜」。这一维已经被反复开发，而「已选中任务内部的执行代价」仍是空白。

能不能再往下一层，砍任务内部的执行步骤？

跑到一半，真能看出评测结果吗？

论文的支点是一条真实轨迹。作者从 OpenHands 的公开评测数据里翻出 tianocore__edk2-pytool-library-372：一个 agent 修一个固件库的 bug，全程 45 步。EarlyEval 把这条轨迹摊成一条时间线：

注意第 23 步的位置。这一步 agent 已经一次性修好了 bug，剩下的 22 步只是多方向跑测试、反复确认，对结局不再有任何影响。22 步约等于整条轨迹的一半，也就是说，这条轨迹接近一半的步骤是冗余的。假如有一个旁观者能看到正确修复长什么样、能判断 agent 当前状态已经和它对齐，那么从第 23 步就能宣布成功，后面 22 步的 token 全部白烧。

反常之处要直说：直觉上，评测必须跑完才有结论。但这条轨迹说明，agent 的最终成败常常在执行中途就由行为本身显形了。这不是玄学，是一条可验证的物理事实，也是整篇论文的支点。

再往深想一层，这个规律并不只属于修代码的 agent。一个 agent 的命运轨迹通常在其早期步骤里就写好了：定位到正确的文件、第一次测试转绿、错误信息从陌生变得熟悉，这些事件本身就是结局的预演；反过来，在原地打转、反复触发同一类报错，也是失败最忠实的先行者。早期预测的本质，就是把这类预演读出来。当然，单条轨迹只算一个提示，论文的可信度不押在这一个例子上，而是押在后面的系统性实验上：把「结局常在途中显形」从一句直觉变成可度量的机制，离线学出预测器，在线逐步复核。

论文顺着两条信号路径往里挖。一条是 oracle-observer 直觉：拿到正确参考解，把它和 agent 当前状态对齐，对齐了就是成功。这条路最接近人怎么判断成败，手握标准答案，就能在 agent 的中间状态里寻找「答案已经出现」的证据。另一条是行为内禀信号：完全不看参考解，只凭行为模式本身，修了哪个文件、跑了哪些命令、出现几次错误，来判断走向。这条路更隐蔽，但更普适，因为参考解不是每个基准都有。论文后面的实验会证明，即便没有参考解可用，剩下的行为与文本信号也足够撑起预测。

这里要先划清一条界线：EarlyEval 不是让模型提前退出推理，跟 speculative decoding、推理 early exit 那套模型加速没有关系。它不碰 agent 内部，只在评测系统外部，对一个正在运行的过程做旁观打分。下一章就看，这个「旁观者」是怎么被工程化的。

EarlyEval 怎么在执行中途判定成败？

工程化的第一步，是把「旁观」变成一道离线训练题。对每个 benchmark，收集一批带最终标签的历史轨迹。每条轨迹是 agent 的一串行为事件，配一个二元结局 y：1 成功，0 失败。把每条轨迹切成所有前缀，每个前缀共享同一个最终标签，然后映射成一个定长特征向量。轨迹不足 10 步的直接丢弃。EarlyEval

切前缀这个动作值得停一下：它等于让分类器见识同一个任务的各种进度状态，一条 45 步的轨迹被切成 45 个训练样本，样本密度一下翻了数十倍，而标签只需要一个，就是最终结局。

这里有个特别省事的性质：标签不需要任何额外人工标注。每条轨迹的 y 就是基准最后给出的成败，历史评测跑完就已经留下。EarlyEval 的训练数据，是历次评测的副产品，这正是它能被工程团队低成本复用的原因。

特征从三个来源拼装：行为 115 维、文本 320 维、参考解 82 维，据论文 Table II 求和为 517 维。第一类是行为特征，115 维，分五组记录 agent 每步做了什么：命令频次、上一步的动作、事件时机、工作模式、错误与测试状态。第二类是文本特征，320 维，把任务文本、动作文本、反馈文本分别做 TF-IDF 后降维。TF-IDF 是一种按词频和稀有度加权的文本数值化方式。第三类是参考解特征，82 维：正确补丁里的关键词、当前状态与正确解的重叠程度。TerminalBench 和 Toolathlon 不发布参考解，所以这两个基准上只有前两类。三类特征的分工用一句话就能说清：行为特征回答 agent 做了什么，文本特征回答 agent 说了什么，参考解特征回答 agent 离标准答案还有多远。

这三类特征怎么拼装、双分类器怎么训练、在线怎么判定，一张架构图说全：

图注：Stage 1 离线，把带标签的历史轨迹切成前缀、抽三类特征，训练 success 与 failure 两个分类头并做 Platt 校准；Stage 2 在线，每步打分后进入阈值决策框，任一分类头跨阈即截断并输出预测，否则继续。EarlyEval

走一遍图里的 Threshold Decision：每步把最新前缀喂给两个分类器。LightGBM 是基于梯度提升树的轻量分类器，不是大模型。一个 head 学「像成功」，输出概率 p_+；一个 head 学「像失败」，输出概率 p_−；两个概率各经 Platt 校准。Platt 校准是用一个逻辑回归把分类器原始分数映射成概率，让不同基准之间的阈值可以直接比较。判定规则一句话：只要 p_+ 超过阈值 s，或者 p_− 超过阈值 f，任一成立就掐断这次运行、输出预测结局；两个同时跨阈时，先跨过的一方胜出；都没触发就继续跑。

为什么是两个 head 而不是一个？因为成功和失败各有各的早期信号：成功的信号是修复动作与测试通过的累积，失败的信号是无进展的原地打转。两个 head 各自独立累积证据，中间自然留出一片「两边都不够确定」的区域，agent 继续跑。放一个具体场景：agent 在第 15 步改对了文件，从第 16 步起测试开始通过，到某一步 success head 的 p_+ 跨过 0.95，这次 run 立刻被掐断，以「预测成功」收尾；而一个卡在同一个报错上反复横跳的 agent，则是 failure head 先跨阈。

「旁观者便宜」是这个设计的命脉。几百维特征过一遍梯度提升树，单核 CPU 上远低于 1 毫秒，每步重打分几乎没有代价。换个角度感受这个量级：agent 自己那一步动辄几万 token 的上下文前向传播，旁观者整步的算力连它的零头都不到。而且「每步」不是偶发动作，是一个 7,805 条轨迹的池子乘以平均每条几十步，打分循环要重复十万次量级的例行公事。便宜不是加分项，是能不能落地的前提。换成 LLM judge 就全完了：每步一次前向传播，省下的算力原样吐回去。论文的架构消融证实，LightGBM 在四个评估轴上都站在 Pareto 前沿，而 LoRA 微调的 Qwen judge 覆盖低、前向还贵。EarlyEval 整套代码已经公开在 GitHub，特征工程按 A–I 九组组织，复现者需要自己准备 SWE 轨迹等数据。EarlyEval 代码

评估协议还守了一道底线：任务按 agent 整体切分并轮转留出，任何一个 agent 的轨迹都不会出现在评判它自己的预测器训练集里。这道防泄漏的设计，第六章还会展开。那么问题来了：掐断得这么随意，测出来的分数还准吗？

在三个真基准上，提前收工值不值？

论文选了三个形态差异极大的基准，专门证明一件事：截断不挑 agent 长什么样。

第一个是代码修复形态。SWE-bench Verified 是 SWE-bench 的人工核验子集：OpenAI 和原作者合作，招募 93 名 Python 工程师对样本做三人独立标注，筛出 500 个描述清楚、确认可解的任务。SWE-bench Verified 任务形态就是第一章那个闭环：

图注：SWE-bench 的任务构造：左侧是 GitHub issue 文本与仓库快照，模型据此生成 patch，右侧用真实测试套件判定通过还是失败。SWE-bench

模型要在动辄数千文件的仓库里定位问题、产出补丁，再扛过真实测试。SWE-bench 的任务平均只有约 195 个词的 issue 描述，线索少到近乎大海捞针。EarlyEval 在它身上有 7,805 条历史轨迹，覆盖 16 个 base LLM 配同一个 scaffold。EarlyEval

第二个是终端操作形态。TerminalBench 有 89 个手写并人工验证的命令行任务，agent 在 Docker 沙箱里自由操作，评测只看容器终态，不检查中间命令。任务最长能跑 2 小时，单次 trial 成本 1 到 100 美元，这正是截断最值钱的地方：目前最强组合的得分也只有 63%，离饱和还远。TerminalBench

图注：一个 TerminalBench 任务由指令、Dockerfile、一组测试和 oracle 参考解四件套组成，agent 在容器里执行，评测只检查容器终态。TerminalBench

EarlyEval 在它身上有 6,757 条轨迹、37 个 agent 配置。EarlyEval

第三个是工具调用形态。Toolathlon 有 108 个任务，横跨 32 个真实软件应用、604 个工具，agent 要跨应用长视野操作，平均要 20 轮左右交互才能完成一个任务。任务提示故意写得模糊，agent 得自己推断意图；每个任务配一个确定性评测脚本，输出 0/1 终态。Claude-4.5-Sonnet 在论文版本上的 pass@1 只有 38.6%，是最难缠的基准之一。Toolathlon 它的官方仓与 Verified 版本持续维护，评测参数都写在 README 里：单任务 5400 秒上限、64K 输出。Toolathlon 主页 EarlyEval 在它身上有 7,116 条轨迹，来自 22 个 base LLM 每任务 3 次 rollout。

这三个基准上的数字，论文用「推荐 operating point」汇报，口径是论文自己定义的：双分类器机制下，绝对 resolve rate 偏差保持在约 2 个百分点内的最低阈值。EarlyEval

跨基准汇总：步骤消除 13% 到 26%，输入 token 节省 29.2% 到 44.1%（Toolathlon 上最高），输出 token 节省 17.4% 到 29.4%，预测准确率 89% 到 97%，绝对偏差封顶 2.1 个百分点。预测准确率这个数字值得停下来看一秒：掐断的不是随机挑的 run，绝大多数被掐断的 run，预测结局和最终结局一致。掐断不是赌博，是读牌。

这些数字要分两层读。第一层是「真能省」：步骤和 token 全都在降，而且省的大头在输入侧。输入 token 节省始终高于步骤消除，说明被掐断的不是均匀的步骤，而是越拖越臃肿的尾巴：agent 每走一步，全部历史上下文都要重新送进模型，尾段的单步成本远高于开头，EarlyEval 掐掉的正是最贵的那部分。双分类器的结构也能从数字里读出来：在推荐阈值下，两个 head 各自贡献的步骤消除几乎可以相加，以 SWE-bench 为例，success head 单独贡献约 10.6%，failure head 单独贡献约 15.4%，合起来正是 26.0%。这说明成功信号和失败信号几乎不会在同一次运行里同时触发，它们掐断的是两类不同的 run。同阈值下两个 head 的精确率分别有 93.9% 和 96.7%，两条证据链都相当干净。第二层更微妙：省与准是同一个旋钮的两面。阈值从 0.95 拧到 0.75，步骤消除从 26.0% 升到 63.4%，而偏差也从 1.1pp 升到 4.1pp。想要多大的节省，就得接受多大的偏差，中间没有免费午餐，只有阈值这一个调节旋钮，而且这个旋钮是在跑之前就能定的。

还要诚实补一句：这些数字来自「推荐 operating point」，而推荐点本身就是按偏差不超过约 2pp 挑出来的最低阈值。三个基准的推荐阈值各不相同，说明每个基准的噪声水平不同，需要各自标定，而不是一个阈值走天下。

论文还专门回答了「没有参考解的基准怕不怕」：特征消融显示，删掉参考解这类特征，主要缩的是覆盖率而不是准确率，覆盖率和步骤消除都有小幅回落，但预测准确率和偏差基本稳得住。TerminalBench 和 Toolathlon 本来就只有两类特征，它们的结果已经说明问题。

排名保真度是另一个视角。把截断后的 leaderboard 和全跑排名对比，Spearman 相关系数最低也有 0.959；在 SWE-bench Verified 上，16 个 agent 里 81% 的名次完全不动，其余基准上也有 59% 到 70% 的 agent 名次不变。EarlyEval 少量错位的 agent 也没有破坏整体排序。也就是说，如果目的只是比较两个候选改动的相对好坏，截断版排名几乎可以当全跑版用，而成本只有全跑的几分之一。

为什么偏偏是这三个基准？因为它们覆盖了 agent 的三副面孔：改代码的、敲命令的、调工具的。评测机制也互为对照，SWE-bench 靠真实测试判分，TerminalBench 只查容器终态，Toolathlon 用确定性脚本给 0/1。如果步骤级截断只在某一类任务上成立，那它只是特例；三个异构基准都成立，才谈得上是一种方法论。

什么时候能用它，什么时候不能？

回到第二章的对照：CoT-Core 式的任务级压缩和 EarlyEval 的步骤级截断是两个正交维度，一个回答「跑哪些题」，一个回答「每道题跑到第几步」。作者把步骤级截断定位为与任务级蒸馏互补的维度（complements, rather than replaces），两者端到端组合还没有实验验证。CoT-CoreEarlyEval

更重要的是一张诚实的分界表：

EarlyEval 有一个硬前提：目标基准上必须已经攒下一批带结局标签的历史轨迹。主流公开基准都满足，因为 baseline 和历届 leaderboard 提交就是现成的池子；但一个全新的基准不行，第一次评估没有任何历史可学。这决定了它面向「稳定基准上的迭代开发循环」，而不是「新基准首次出分」。这个前提也意味着 EarlyEval 的价值会随时间累积：基准每多跑一轮，历史轨迹池就厚一分，预测器可能获得更多训练信号，但是否更准仍取决于轨迹质量与分布。对一个刚发布的基准，第一轮全跑既是成本，也是给下一轮迭代攒下的投资。

还有一个必须摆在明面的代价：early-stop 会引入 resolve rate 偏差，在论文选取的推荐 operating point 下约为 1 到 2 个百分点，阈值放宽时可更大。所以最终要写进论文、要对外引用的分数，仍应全跑取得。EarlyEval 的定位是迭代期的廉价相对比较工具，不是「更便宜的全跑」。

作者自述的三类有效性威胁也值得照单全收。内部威胁是训练数据泄漏，用 task-partitioned leave-one-agent-out 隔离：把一个 agent 的轨迹整体留出，只用其他 agent 的轨迹训练，再在留出的 agent 上测试。外部威胁是泛化到没见过的 agent 和全新基准，用三个异构基准和「缺参考解时关闭对应特征族」来缓解。构念威胁是代理指标本身：省 step、省 token 能不能代表真实开销？经验数据说能，因为输入 token 节省始终高于步骤节省，截掉的正是最烧钱的尾段 context。EarlyEval

论文自己列出的未做清单同样重要：没有做跨基准的训练数据迁移，也就是不能拿 SWE-bench 的轨迹去预测 TerminalBench 上的运行；没有做下游用户研究，工程师真正用起来会不会接受掐断的分数，还没有答案。

那到底什么时候该用它？判断标准只有一条：这份分数要不要进论文、进对外报告。要，就老老实实全跑。不要，只是在稳定基准上快速比较两个候选改动，EarlyEval 就是为这个场景量身定做的。想象它的正确打开方式：你在一个已经跑过几十轮评测的基准上迭代 prompt，每个候选改动先跑一遍截断版，成本大致是原来的一半到七成，圈定最有希望的版本之后，再全跑一次拿到可以写进报告的分数。省在循环里，准在终局上。

评测的钱花在「跑完」上，而 agent 的结局往往在「跑完」之前就已经写好了。让「还要不要继续跑」这个问题在每一步都只花不到 1 毫秒去回答，这本身就是评测工程的一个新起点。任务级压缩早已在做，步骤级截断是第一个系统性补上另一半的方案；两条路在未来可以组合，步进式预测也天然指向自适应评测的方向，让评测从终点结算变成过程监控。省下的每一分算力，都要还给更频繁、更早的验证循环。

想深入可以读原文：EarlyEval: Cheaper Agent Evaluation via Early Outcome Prediction，链接在 arXiv:2609.02783。

参考文献

1. EarlyEval: Cheaper Agent Evaluation via Early Outcome Prediction（arXiv:2609.02783）— https://arxiv.org/abs/2609.02783
2. SWE-bench: Can Language Models Resolve Real-World GitHub Issues?（arXiv:2310.06770，ICLR 2024 oral）— https://arxiv.org/abs/2310.06770
3. Introducing SWE-bench Verified（OpenAI 官方公告）— https://openai.com/index/introducing-swe-bench-verified/
4. Terminal-Bench: Benchmarking Agents on Hard, Realistic Tasks in Command Line Interfaces（arXiv:2601.11868）— https://arxiv.org/abs/2601.11868
5. The Tool Decathlon: Benchmarking Language Agents for Diverse, Realistic, and Long-Horizon Task Execution（arXiv:2510.25726）— https://arxiv.org/abs/2510.25726
6. Toolathlon 官方仓库与 Toolathlon-Verified 公告 — https://github.com/hkust-nlp/Toolathlon；项目页 https://toolathlon.xyz
7. CoT-Core: Accelerating LLM Evaluation via CoT-Aware Coreset Selection（arXiv:2608.00014）— https://arxiv.org/abs/2608.00014
8. EarlyEval 官方代码仓（inphotoo/earlyeval）— https://github.com/inphotoo/earlyeval