Agent 评测开始算总账：Hugging Face 与 IBM 把成本和失败也放上榜

Hugging Face 与 IBM Research 做了一件很实际的事：发布 Open Agent Leaderboard，用开放框架评测完整 AI Agent 系统。

它不只看模型答题分数。评测对象是“模型 + Agent 架构 + 工具调用 + 规划 + 记忆 + 失败恢复”的组合。

这才是反常点。过去聊 Agent，很多讨论最后都会落回“用了哪个模型”。但企业真要部署时，另一个问题更早出现：它能不能稳定做完任务？失败时会不会越试越贵？

我更在意的变化也在这里。Agent 评测正在从“比模型强弱”，转向“比完整系统能不能部署”。

这次评的不是模型，是整套 Agent 系统

Open Agent Leaderboard 覆盖六类基准：SWE-Bench Verified、BrowseComp+、AppWorld、tau2-Bench Airline、tau2-Bench Retail、tau2-Bench Telecom。

这些任务不是同一种题型。它们分别指向代码修复、网页研究、跨应用个人任务、航空客服、零售客服、通信技术支持等场景。

这会逼 Agent 暴露更多问题。一个系统在代码任务里能跑，不代表它在客服流程里也稳；会网页搜索，也不代表能处理跨应用操作。

榜单每个配置报告三类结果：平均成功率、平均单任务成本、分基准结果。也就是说，它不只问“成没成”，还问“花了多少钱成的”，以及“在哪些任务上容易掉链子”。

这张表的意义，不是给模型排一个新座次。

它把过去常被一句“模型能力不足”带过的差异拆开了：同一个模型，搭配不同 Agent，可能得到不同成功率，也可能产生不同成本。

对开发者来说，这会改变优化顺序。不是只换更强模型、拉长上下文、塞更多工具。工具选择、任务分解、错误恢复，都可能直接影响结果。

对企业评估负责人来说，采购动作也会更谨慎。以前可以先问“你用的是什么模型”。现在更应该多问一句：同样任务下，你这套 Agent 的平均单任务成本是多少？失败任务怎么算？

成本和失败，开始从脚注变成主指标

原文里有个数字，比排名更值得看：失败任务的成本比成功任务高 20%–54%。

这很符合 Agent 的真实风险。Agent 不是答错一道选择题就停。它可能继续搜索、继续调用工具、继续改计划，最后还是失败。

任务没完成，账单却已经跑完一圈。

这也是为什么“平均成功率”不够。一个 Agent 成功率略高，但失败时成本暴涨，放到生产里未必划算。另一个系统成功率略低，却能更快识别失败、及时停止，反而可能更适合预算有限的试点。

这里最受影响的是两类人。

一类是 Agent 开发团队。接下来要做的不只是换底座模型，还要检查工具 shortlisting、规划链路、失败恢复策略。原文提到，工具 shortlisting 在测试模型中普遍改善表现，并让一些原本失败的配置变得可用。

另一类是企业 AI 应用负责人。试点验收不能只写“完成率达到多少”。更现实的指标应该包括：单任务平均成本、失败任务平均成本、失败后是否需要人工接管。

换句话说，Agent 的部署价值开始从“演示能跑”，变成“坏账可控”。

这条线很硬。

这个榜单有用，但不能当 AGI 证明

Open Agent Leaderboard 衡量的是跨任务 Agent 泛化能力，不是 AGI。

六类基准比单项测试更接近真实工作流，但它仍然覆盖不了所有企业场景。权限系统、私有数据、合规审计、人类接管流程，都不会在榜单里完整呈现。

还有一个限制要讲清楚：这些 Agent 是按通用系统测试的，没有针对每个 benchmark 做专门调优。它也没有复用模型开发者在单项榜单里常见的提示词和环境优化。

所以，Open Agent Leaderboard 的结果可能不同于 SWE-Bench Verified、BrowseComp+ 等原始榜单。它不能直接替代单项排名。

这不是缺点，反而是它的定位。

单项榜单适合看某类能力的上限。Open Agent Leaderboard 更适合看一套 Agent 在多类任务里的平均表现、成本结构和失败方式。

接下来最该看三件事。

目前只能下一个克制判断：模型仍然关键，但已经不是唯一解释变量。

Agent 架构、工具策略、恢复机制和失败成本，正在一起决定系统是否值得部署。古话说“功夫在诗外”，放在这里也合适。Agent 的分数在榜上，真正的成本在流程里。