配图为主题示意，不代表真实产品界面或已经完成的验收。
10月11日，开源榜单聚合项目BenchBoard的维护日志写明，已补齐Terminal-Bench 4.0官方榜单的23条记录。[1] 这不是Terminal-Bench 4.0在当天发布，也不是BenchBoard自己做了23次测试。它做的是整理已有成绩，并把基准版本、来源、Agent Harness、推理投入、置信区间、Token消耗和成本条件等放到记录里。对拿榜单选终端智能体的团队来说，问题由此变得很具体：同一个“分数”到底算在模型头上，还是算在执行框架、预算和测试条件头上？
我的判断是，终端Agent的成绩应按完整运行配置看，而不是把排行榜第一名直接当成“最好的模型”。配置一旦被藏进脚注，采购者会把更多推理预算或更强的工具编排带来的收益误算为底层模型能力。BenchBoard此番整理的价值是把比较所需的账目摊开；它本身不是官方基准主办方，也不替代企业在真实环境里的验收。[1][2]
23条记录补了什么，没补什么
日报提供的事实很窄，也很有用：BenchBoard于10月11日补齐Terminal-Bench 4.0官方榜单的23条结果，并区分维护者执行的成绩与供应商自报成绩，同时保留Harness、推理设置、置信区间以及成本等字段。[1] 这里的“23条”是新增或补齐的榜单记录数量，不能改写成23个新模型、23次独立企业试点，或23项由BenchBoard亲自复测的实验。官方榜单地址用于对照基准来源，不代表该基准在10月11日才出现。[2]
成绩的来源为何要分开写？如果某次运行由基准维护者按指定配置执行，和供应商按照自有配置提交结果，记录的产生路径就不同。两者都可能有参考价值，但不能只因为最后一列数字相同，就认为采样和环境控制相同。没有原始配置和运行证据时，也不要反过来断言供应商成绩有问题。来源标签只是帮助读者知道下一步该向谁索取复现实验资料。
置信区间也是经常被忽略的一列。终端任务的成功率通常不是一块不会动的石头：抽到的任务、运行中的随机性、失败后是否允许重试，都会让观察值起伏。如果两个成绩差距不大，而区间有重叠，仅凭名次先后宣布某模型明显领先并不稳妥。日报没有列出这23条记录的具体分数或区间数值，因而这里不做任何型号之间的胜负判断。让区间出现在榜单旁边，是提醒读者别把一个点估计当作确定事实。
一次终端任务，分数是谁挣来的
终端智能体面对的不是一道只需输出答案的单选题。它要读文件、发命令、等待结果、修改代码或配置，再根据反馈调整行动。同一基础模型放进不同Agent Harness，可能拿到不同的工具描述、错误反馈、上下文压缩办法和停止条件。Harness若替它规划重试、保留关键状态，任务结果就可能变化。反之，模型即使很会解释问题，也可能被不合适的工具接口拖累。最终成绩属于“模型加运行系统”的组合。
推理预算同样要单列。允许更多生成Token，智能体可能有空间检查失败日志并再次尝试；也可能只是在坏路径上花更多钱。最长运行时间、可执行命令、容器初始状态、网络访问和重试次数都会改变完成任务的机会。说它们“会影响”是评测设计上的判断，不是说BenchBoard已经证明了某个因素带来多少百分点提升。没有同条件的对照实验，不能从两个公开榜单数字直接拆出模型与Harness各自的贡献。
采购讨论容易在这里走偏。假设甲配置的成功率高于乙，但甲每题消耗的Token更多、运行时间更长，且使用了乙没有的工具权限。甲未必不值得买；只是这笔差额要写出来，才能看它符合不符合生产系统的预算和安全要求。一个面向夜间自动修复的团队，可能更在意低频失败时能否稳妥回滚；一个供工程师交互使用的团队，可能更在意几分钟内给出可审查的操作建议。榜单数字无法替任何一方决定代价上限。
配图为主题示意，不代表真实产品界面或已经完成的验收。
先把“同一条件”说清楚
内部评测开始前，给每一次运行固定一张配置卡：基准名称与版本、任务集和题目排除规则、模型的准确版本或可追踪标识、Harness及版本、工具集合、执行容器、初始文件状态、网络策略、时间上限、Token上限、重试和采样设置。这里列的是企业自测建议，不是断言BenchBoard对所有公开结果都已记录这些字段。卡片版本有变，就另起一组成绩，别在旧结果上覆盖。
还要区分“运行成本”与“报价”。每任务模型调用费用会随Token价格和消费结构变化；基准成本表若只计模型调用，不一定包含工具计算、容器、人工复核和失败重试带来的运维开销。报价可能有折扣和包量，不一定对应榜单时点的实际账单。比较时最好同时给出每题Token、完成任务的平均费用、总体费用与计费口径，说明失败任务是否计入。日报只说项目记录成本条件，未给具体金额，不能据此声称某个模型更省钱。[1]
复现还需要保存可诊断的轨迹。每条任务至少记录最后是否成功、执行命令、错误输出、每次模型调用的消耗和重试原因。敏感环境里日志可能泄露源代码和密钥，要脱敏并分级保存；但只留一个“通过”或“不通过”，失败时几乎无从判断是模型理解错误、Harness传参错误、工具环境故障，还是任务本身有歧义。能把故障归因到哪一层，后续优化才有对象。
有些团队会说，官方榜单只要排名对就行，何必记录这些琐碎项？因为基准是一个经过控制的环境，而企业的命令行不是。内部依赖可能需要认证，生产网络可能不开放，仓库里也可能有机密配置。公开评测可让候选范围缩小，不能证明某个Agent已适合拿到企业仓库的写权限。先用只读任务或隔离仓库复测，再决定是否允许修改文件、创建分支以及执行部署命令。这是权限验收，不是替榜单补一个“安全分数”。
对照实验怎样避免混账
若要比较两个模型，尽量保持Harness、工具集、任务、预算和运行次数一致，仅改变模型；若要比较两个Harness，则锁定模型及其版本。现实里完全对齐不一定做得到，有的模型支持的工具调用方式不同，有的供应商提供不同的上下文长度。碰到不可对齐的地方，公开写出差别，不要在汇报里用“同口径”一笔带过。实验对照负责告诉你某个变动可能带来什么影响，榜单聚合则负责告诉你公开成绩附带了什么条件，两者不是一回事。
“成功率”也需要按任务类型拆开看。假设某团队日常要改脚本、排查依赖和生成测试命令，三个任务的错误成本差很大。总体通过率提高，可能只因为容易的题多了几道；真正高风险的依赖修复反而退步。内部可以按任务难度、权限级别和失败后果分层，分别记录成功率与人工修正时间。别为了让报表好看随意删掉难题，任务集的增删要留痕。没有本企业的任务分布，单一公开名次只能作线索。
还有一道经常被忽略的分账：把“任务做成”与“过程可接受”分开。一个Agent最终让测试通过，却在中途多次改写无关文件、尝试访问不该看的目录，对企业而言未必合格。给执行轨迹加上越权请求、无关修改、未验证断言和回滚次数等审查项。它们不一定是Terminal-Bench 4.0官方评分的一部分，这里是企业验收建议。引入内部过程指标后，也不要把它们冒称为官方榜单分数。
区间、重跑与选择偏差
一张榜单里的置信区间，首先要问它围绕什么指标、用什么样的重复与抽样算出来。题目重复运行的随机性，与只抽取一部分任务带来的误差不是一回事；具体计算办法应回到原始榜单的说明核对，不能看到“有区间”就默认各提交采用同一统计程序。企业若自己重跑，先固定采样设置与运行次数，再把每次任务的结果留下；只公布最好的一次会把运气记成能力。日报未提供这些记录的逐项统计口径，因此不能替它们写出显著性结论。[1][2]
同样，公开榜单上的配置往往经过选择。一个团队可能试过多种提示词、多个Harness版本与不同预算，最后提交最好看的组合；如果只看提交行，读者不知道探索过程花了多少成本。这里不是指控BenchBoard收录的某个供应商有此行为，而是任何开放提交机制都需要面对的比较难题。企业要求复现时，至少要锁定实际交付的产品版本，而不是用一次高度调优的演示配置代表长期服务；合同验收可以约定任务集、预算上限和重试规则，避免交付时换了账本。
失败成本还包括排队和人工等待。终端Agent如果连续试了许多命令才解决任务，模型费用可能可控，却占用受限执行容器很久；如果每次失败都要工程师阅读长轨迹，实际节省的工时也未必明显。可以同时报告任务完成率、达到完成所需的运行时间分布，以及一线工程师实际介入的次数。这里只是建议的企业指标，并不暗示Terminal-Bench 4.0官方榜单已有这些列。把未公开的维度写成自家补测数据，才不会让官方成绩背上本来没评的内容。
最后，要防止留出集逐渐变成公开练习题。每次根据失败案例调参数，都该记下调了什么，哪些题目已经被人看过。隔一段时间换一批同类、但未参与调优的企业任务，复测结果才有说服力。内部评测不必追求一个永远不变的完美题库，重要的是留下版本与改动记录，能解释为什么两个月后的分数和上个月不同。这一层工作很琐碎，却比争论榜单名次变化一位更接近采购决策。
给采购和研发团队的一张账本
采购会若只放一张从高到低的表，争论很快会变成“分数高几个点值不值”。不妨把候选写成配置行：模型版本与供应方、Harness版本、任务范围、允许的工具权限、预算上限、分数及区间、每任务成本、失败类型、运行来源。公开记录里的空白项如实写“未知”，并标出哪些由内部复测补足。对于供应商自报结果，要求提供可复现的方法说明；对于维护者运行结果，也核对版本与内部环境差异。来源分开，才谈得上比较。
试点周期里可先挑一个业务团队真实会遇到的任务包，给每个候选同样的时间和权限；保留一份此前没拿来调参的留出集，免得大家围着已知题目调Harness。重点看重复运行的稳定性、人工介入频次以及失败是否容易恢复。出现差距时，先检查配置卡，再讨论换模型。把工具权限关掉后成绩下降，原因可能是Agent失去完成任务所需的能力；把预算翻倍后成绩上升，也不能免费记在“模型升级”名下。
BenchBoard这23条记录最大的提醒，恰恰不在“新增了多少名次”。它让一些通常藏在榜单后面的条件有了单独的列。[1] 但列完整不等于所有成绩天然可比，更不等于聚合项目为每条结果提供了独立复核。企业要做的最后一步仍在自己手里：用相同任务核对配置、用真实费用核对Token账、用执行轨迹核对结果。Agent评测要算的是整套系统实际干活的账；只挑最好看的那一格，账一定对不上。
参考资料
[1] GitHub / SYuan03，《BenchBoard: Source-linked collection of published AI model benchmark scores》，日报记载2026-10-11更新；用于23条记录、成绩来源与配置字段。https://github.com/SYuan03/benchboard
[2] Terminal-Bench官方网站，《Terminal-Bench 4.0 Leaderboard》，日报记载2026-10-11访问；用于官方榜单背景，不作为当天发布基准的证据。https://www.tbench.ai/