换 agent 框架跑同一道题,token 相差近十倍

An End-to-End Agent Auditing Engine

Haoning Wang, Mingxun Zhang, Chenyue Yu, Yingjun Shang, Xia Hu, Guanchu Wang, Na Zou

cs.AI

2026-08-07

上海 AI Lab 的 A²E 固定同一模型跑 9 个 agent 框架 × 23 项基准,发现框架间正确率差距很小、token 消耗却差数倍,没有任何框架通吃所有任务。

这篇在解决什么

harness(agent 框架,如 LangChain、CrewAI、OpenAI Agents SDK)是把 LLM 变成可用 agent 的脚手架:系统提示、工具接口、上下文管理、执行循环都捏在它手里。问题在于,大家评 agent 系统时几乎只盯着底座模型,框架这层没被系统地评测过。

已有工具各管一段。英国 AI 安全研究所的 Inspect AI 能跑基准,但要靠每个框架单独写适配器,还可能改动原生执行、损失轨迹保真度;Arize 的 Phoenix 提供可观测性,却不是一个能从头跑到出分的端到端基准器。要把它们扩展到新框架、新基准,都得动不少框架专属代码。A²E 想做的,是一个轻量、几乎不侵入、框架无关的底座,把基准执行和忠实轨迹采集统一在一个栈里。

方法

A²E 是三层结构。

Task Layer 建在自创的 Agent Task Protocol(ATP)上,把基准和框架解耦。每个基准产出一个 TaskInput,每个框架配一个 AgentRunner,中间靠 ATP 这套对象接口对接。这样 23 个基准 × 9 个框架能自由配对,不用为每一对单独写胶水代码。

Monitor Layer 基于 OpenInference,用 OpenTelemetry 的 span(一段带起止时间、状态和父子关系的操作记录)捕捉 agent 执行。它自动埋点,不需要每个 agent 自己写日志,把「模型调用 → 工具调用 → 观察 → 下一轮推理」这条链完整记下来。

Evaluation Layer 提出 Lifecycle-Aligned Evaluation:把每个指标挂到执行生命周期的具体阶段,即 Reasoning(推理)、Action(动作)、Final Answer(最终答案)和 Runtime Quality(运行时质量,含效率与安全)。规则类指标(正确率、成功率、延迟、token 用量、成本、步数)和 LLM-as-judge 类指标(推理质量、工具使用质量、指令遵循、安全)各管一类。所有轨迹、指标定义、结果都进数据库,而不是散落的日志文件;好处是新增一个指标可以直接在已存的轨迹上重算,不用重跑昂贵的 agent。

结果

主实验把 9 个框架(Agno、AutoGen AgentChat、CrewAI、Google ADK、LangGraph、LlamaIndex、OpenAI Agents SDK、Smolagents、Anthropic Python SDK)每个都跑全部 23 个基准,全部用同一个底座 DeepSeek-V4-Pro(FP4)、同样的推理设置、工具、步数和超时预算,每个基准抽 5 道题,共 1035 次评分。

维度跨 9 个框架的差距
单轮问答(arc、gsm8k、humaneval 等)正确率几乎一样,框架选择不可见
多轮任务正确率τ-bench 0.00–0.60、gdpval 0.00–0.60、traject-bench 0.20–1.00
token 消耗Claude-Agent-SDK 2063 → smolagents 7319,相差 3.5 倍,而正确率只 0.568–0.663

没有任何框架通吃。openai-agents 在 traject-bench 拿 1.00,在 τ-bench 只有 0.20、gdpval 直接 0.00;llama-index 在对话类基准领先,traject-bench 却只有 0.40。整体平均 agno 最高(0.68),但这主要被四个 sandbox 基准抬高:只看 19 个非 sandbox 基准,llama-index 反而领先。

换 GLM-5.2 跑跨基准对照(GDPVal、MMLU-Pro、τ³-bench),成功率差距分别到 0.20、0.30、0.66,每个基准的前三名框架各不相同。

最有说服力的是同一个 τ³-bench 任务上的案例。LangGraph 用 10122 token、4 次模型调用、3 次工具调用,判出账号欠费停机,正确率 1.0;CrewAI 用了 96704 token(约 9.6 倍)、9 次模型调用、5 次工具调用,反复重置 APN、重启、开飞行模式,始终没找到账号层原因,零信号收尾,正确率 0.0。

为什么重要

对选型的人是直接信号:agent 系统的性能不只是底座模型的事。框架的提示构造、工具表示、上下文管理、执行循环和终止策略,能造成数倍的成本差异和成败差异。固定模型并不能消除系统级的性能波动。如果你在意成本,只看「这道题答对没有」会选错框架;A²E 这类把整条轨迹(规划、工具、效率、安全)都量出来的评测,才暴露真正的差异。诚实地说,这是评测基础设施的进展,不是新模型或新方法,贡献落在工程评测这一层。

局限与存疑

作者自己承认,这次基准组合下那些丰富的过程类指标(规划、工具使用等)「动得很小」,怎么把它们变成框架设计的具体指导,留给了未来工作。也就是说,这套精细指标体系目前展示价值大于实战指导价值。

样本太小。每个格子只有 5 道题,分辨率只有 0.20,单元方差很高,作者明确说那张表「不是用来给框架排名的」。9 个框架、23 个基准也不算覆盖整个生态。CrewAI 的 LLM span 没有记录 token 数,被排除在 token 成本分析外。案例研究只取了一个任务,难以泛化。框架注册成功也不等于每个框架-基准配对都通过了端到端验证。

术语

原文与代码

社区讨论

相关论文

全部论文解读