Open Agent Leaderboard：评测 Agent 不能只看模型分数
Hugging Face 上的 IBM Research 团队在 2026 年 5 月 18 日发布 Open Agent Leaderboard，用于比较完整 Agent 系统，而不只是比较底层模型。公告强调，Agent 的效果取决于系统如何构建：它能用哪些工具，如何规划步骤，如何记忆上下文，遇到错误时如何恢复，以及这些能力对应多少成本。
这正好击中了当前 Agent 评测的痛点。很多团队仍然习惯拿模型 benchmark 分数推断 Agent 表现，但真实系统里，模型只是执行链路的一部分。工具设计、环境适配、状态管理和失败处理，都会让同一个模型表现出完全不同的稳定性。
为什么模型榜单不够用
模型榜单通常回答“这个模型在某个任务集上得分多少”。Agent 评测还要回答另一组问题：它是否能跨任务迁移，是否需要为每个 benchmark 做专门调参，是否能在工具失败后继续推进，是否能以合理成本完成任务。
例如同样是代码修复任务，一个 Agent 可能有文件搜索、测试运行、补丁生成和错误回读能力；另一个 Agent 只能生成建议。即使底层模型相同，两个系统的可交付结果也会差很多。把它们只归因于模型强弱，会误导工程决策。
成本应该成为一等指标
Open Agent Leaderboard 同时报告质量和成本，这一点很现实。Agent 往往会进行多轮推理、多次工具调用和长上下文读取。如果只追求成功率，很容易得到一个在演示里很强、在生产里太贵的系统。
工程团队做 Agent 评测时，至少应该记录三类成本：模型 token 成本、工具执行成本和人工审核成本。某些场景下，成功率提升 2% 可能需要多消耗数倍 token；另一些场景下，引入更好的工具约束反而能降低模型反复试错的成本。
如何把评测落到项目里
可以从一组真实任务样本开始，而不是只跑公开 benchmark。每个任务记录输入、允许工具、期望输出、人工验收标准和失败案例。然后比较不同 Agent 配置：提示词、模型、工具集合、记忆策略、重试策略和人工确认节点。
评测结果不要只给一个总分。更有用的是拆成完成率、错误类型、平均步骤数、平均成本、人工介入次数和可解释性。这样团队才能知道瓶颈在模型、工具、数据、权限还是工作流设计。
结论
Open Agent Leaderboard 的价值在于把讨论从“哪个模型更强”推进到“哪个 Agent 系统更适合部署”。2026 年做 Agent，评测对象应该是完整系统：模型、工具、记忆、规划、恢复机制和成本共同决定能否进入生产。
参考资料
文章分享
如果这篇文章对你有帮助，欢迎分享给更多人！