Agent开发中最混乱的领域——一文读懂Agent 评测现状

一、为什么 Agent 评测比 LLM 评测更难？

传统 LLM 评测（现在当然更复杂维度更多元化）关注的是文本生成质量——回答是否流畅、事实是否正确、格式是否合规。但 Agent 是一个完整的系统，它要自主决策、调用工具、与环境交互、在多轮对话中保持状态。这意味着：

1. 不能只看最终输出，还要看中间过程是否合理（中间过程非常重要）
2. 不能只看单次执行，还要看重复执行是否稳定
3. 不能只看功能正确性，还要看性能、成本、并发能力
4. 不能只在单一场景测试，还要覆盖工具调用、长上下文、多轮对话等维度（工具调用的能力评测也是目前的难点与重点）

LLM 评测像测发动机，Agent 评测像测整车——必须综合考察在各种驾驶条件下的表现。

二、评测维度的"四层模型"（非常重要）

综合上述框架，可以提炼出一个系统的 Agent 评测四层模型：

1. 基础性能（BasePerf）：延迟、Token 消耗、成功率

2. 对话质量（Dialogue）：格式合规、事实准确、指令遵循

3. 工具调用（Tool Use）：工具选择、参数填充、证据链完整性

4. 系统能力（System：可用性、性能、并发、稳定性

注意：底层不牢，上层不稳。 如果 Layer 1 的延迟就很高，Layer 4 的并发肯定扛不住；如果 Layer 2 的事实准确性不行，Layer 3 的工具调用结果也靠不住。

三、当前业界的主流做法：混合评测模式（无奈之举）

虽然上面列出了很多框架，但在实际工程落地中，直接使用现成框架评测 Agent 的做法目前还不够成熟。原因很现实：

• 学术框架（如清华 AgentBench、WebArena）环境依赖重，需要 Docker、浏览器、数据库等复杂基础设施
• 垂直框架（如 SWE-bench）场景单一，难以覆盖自有 Agent 的全部能力
• 各框架的协议不统一，Agent 接入成本高，结果难以横向对比

因此，当前给自己 Agent 项目做评测的主流方式，仍然是以下三种手段的组合：

这种"混合模式"的痛点在于：缺乏统一标准，各家自说自话。同一个 Agent，用不同的评测方式可能得出截然不同的结论。

四、Agent 评测正在走向规范化：Exgentic 的启示

Agent 评测的"各自为政"状态正在改变。2026 年初，IBM Research 与 MIT-IBM 联合团队在 ICLR上发表了 Exgentic，提出了一个通用 Agent 评测的统一协议。

Exgentic 的核心贡献在于：

• 统一协议层（Unified Protocol）：将不同 Benchmark 的交互模式抽象为标准化接口，Agent 无需为每个 Benchmark 单独适配
• 评测 Harness：支持将同一套通用 Agent 不加修改地接入多个 Benchmark（SWE-bench、τ-bench、GAIA 等）
• 首个 Open General Agent Leaderboard：首次实现了 5 个 Agent × 3 个 LLM × 6 个 Benchmark 的全因子对比

Exgentic 的实验发现也很有意思：

• 模型选择主导了 85 倍的方差，但 Agent 架构选择仍能带来最多 11 个百分点的差异
• 在超过一半的 Benchmark 上，通用 Agent 的表现匹配甚至超过了领域专用 Agent 的 SOTA 成绩

这说明：通用 Agent 评测标准化不仅是可行的，而且已经起步。Exgentic 的方向代表了行业共识——从"每个 Benchmark 一个接口"走向"统一协议 + 通用 Harness"。

五、总结

Agent评测目前并没有很规范很成熟的评测方式与评测框架，基本各家都是针对实际的Agent项目来自定义一个评测的附属项目，并使用行业通用benchmark或按照业务逻辑自定义benchmark。

虽然今年Exgentic这种通用协议开始被提出，但是到落地依然有很久的距离。加之Agent本身就有很强的自定义性与行业专属性，目前最好的方式依旧是针对自己的Agent项目独自开发一套独立的可复用benchmark的Agent评测附属项目。

对Agent评测有兴趣的可以去看看当前比较成熟的clawbench(github同名），就是针对openclaw这种知名的Agent项目而独立设计的一个非常成熟的评测框架。