Agent Execution Tax：浏览器代理基准测试的新衡量指标

# 智能体并非败在智能不足，而是败在执行不力 来源：https://fireworks.ai/blog/agent-execution-tax ### 720 次浏览器智能体运行揭示了智能体 AI 的真正瓶颈所在。 #### ANotte × Fireworks AI 基准测试报告。 --- 基础模型越来越聪明。它们在推理基准测试中表现出色，能写出流畅的代码，并通过专业考试。然而，当你把它们放入一个智能体循环中——在该循环中，它们必须观察网页、决定下一步行动，并连续十次输出结构化动作——它们大约有一半的时间会失败。 我们让四个大语言模型执行了 720 次浏览器自动化任务，以找出原因。答案并非智力问题，而是执行问题：**有一个模型将近五分之一的 LLM 调用浪费在了格式错误的 JSON 上，这些调用不得不被重试。** 即使该模型的原始推理能力具有竞争力，这个单一可靠性差距也导致了更高的延迟、膨胀的成本和更低的任务成功率。 我们将这种开销称为 **Agent Execution Tax**：即浪费的推理与有效推理的比率。在我们基准测试中表现最差的模型，这个税率为 22.9%。而表现最好的模型，税率为零。 在智能体系统中，可靠性的复利效应比智能更强大。胜出的模型并非那些推理分数最高的模型。而是那些每次都能以要求的格式可靠地执行指令的模型。 在生产环境中，这种可靠性不仅取决于模型本身，还取决于为其服务的推理基础设施：结构化输出的一致性、延迟的可预测性以及在重复的智能体循环下稳定的执行。 以每天 10,000 个智能体任务（一个适中的生产规模）计算，表现最差的模型每年因无效推理的执行开销造成超过 40,000 美元的损失。一旦将重试、失败和膨胀的调用次数考虑在内，一个看似每token成本更低的模型，其每次产出的实际成本可能会高得多。 > **范围说明。** 这是一个纯文本浏览器智能体基准测试。结果衡量的是多步骤智能体循环中的结构化输出可靠性和步骤效率——而非模型的通用智能、推理能力或多模态能力。请参阅下方“本基准测试范围”以获取完整的范围说明。 Agent Execution Tax：每 1 美元有效推理对应的浪费推理## **部署就绪评分卡** 如果您正在为智能体部署评估模型，以下是它们与生产约束条件的对应关系。 如果您需要...使用原因最高任务准确率GLM-557.1% 准确率；在 Google Maps、HuggingFace、BBC News、Wolfram Alpha 上达到 100%；在结构化数据提取和多步骤推理方面最强大规模下的最低成本MiniMax M2.5每个成功任务 $0.062（比 Gemini 便宜 2.3 倍）；经过 RL 训练的智能体，执行步骤最少（平均 9.8 步）且极少重试（1.6%）最快实时响应Kimi K2.5p50 LLM 延迟 2.1 秒；852 次调用中零解析重试；最适合感知速度对用户体验至关重要的面向用户型智能体严格的采购评估可靠性调整准确率Token 定价在模型选择阶段具有误导性；每个成功任务的成本和执行税才是反映您实际支付费用的指标 **每个模型一句话总结：** - •**GLM-5：** 准确率最高，成本也最高。适用于合规工作流、研究自动化以及错误会产生下游后果的任务。 - •**MiniMax M2.5：** 性价比最佳。大规模生产工作负载的默认选择。每年 40,000 美元的浪费计算量使其在大规模应用时成为经济上占主导地位的选项。 - •**Kimi K2.5：** 速度最快，执行开销为零。适用于面向客户的智能体、实时演示以及任何响应延迟会影响用户信任的工作流。 ## **智能体执行税** 从外部看，浏览器智能体任务看起来很简单：访问 Amazon，搜索商品，提取价格。但在引擎盖下，它是一个多步骤的循环： `观察页面 → LLM 生成动作 (JSON格式) → 执行动作 → 观察新页面 → 重复` 智能体循环一个典型任务需要 10 步。每一步都是一次 LLM 调用，必须返回有效的结构化输出：一个指定点击哪个元素、输入什么文本或提取什么数据的 JSON 对象。如果 JSON 格式错误，框架会重试。并且这个重试是隐形的：它不会出现在任务成功率或推理基准测试中。只有当你对引擎本身进行仪器化时，它才会以膨胀的调用次数、延迟和成本的形式显现出来。 ### **定义** `Agent Execution Tax = (总推理调用次数 − 有效调用次数) / 有效调用次数` **有效调用** 是指那些在首次尝试时就返回了有效结构化输出的调用。该税衡量的是，相对于完成的有效工作，你额外支付了多少推理成本。每一个百分点都代表着花在毫无产出的推理上的金钱。 注意分母：这与原始重试率（重试次数 / 总调用次数）不同。18.6% 的重试率转化为 22.9% 的执行税，因为当你移除浪费的调用后，分母就变小了。 ### **应用于我们的数据** 模型有效调用次数总调用次数执行税Kimi K2.58528520.0%GLM-58698840.6%MiniMax M2.58158281.6%Gemini 2.5 Flash72188622.9% 基于仪器化运行测量（每个模型 90 个任务）。所有模型均未记录到解析失败（耗尽重试次数）。 Gemini 每产生一美元的有效推理，你就需要额外支付 23 美分的浪费。Kimi 的税率为零。 （注意：文章开头的执行税条形图是本部分的规范可视化；此处不重复。上表包含了用于引用的确切数字。） ### **税收如何复利** 这个税不是单一成本。它会在三个维度上叠加： 1. **Token 税。** 格式错误响应中浪费的 token，加上每次重试时重新发送的完整输入上下文。Gemini 平均每步消耗 15,482 个输入 token；每次重试都会为产生零产出而重新发送整个上下文。 2. **延迟税。** 每次重试都会增加一次完整的 LLM 往返（Gemini 的 p50 约为 2.5 秒），每个任务大约增加 12 秒的死时间。 3. **级联税。** 第 8 步的一次重试可能会使智能体的内部状态失去同步，导致下游步骤误解页面而失败。这最难量化，但在大规模应用中最为危险。 ### **通用公式** `每个任务的预期重试次数 = n_steps × retry_rate / (1 − retry_rate)每个任务的 Token 开销 = 预期重试次数 × (平均输入 token + 平均输出 token)每个任务的延迟开销 = 预期重试次数 × 平均调用延迟` 对于一个 10 步任务，Gemini 的重试率为 18.6%：预期重试约 2.3 次，每个任务浪费约 36,500 个 token，每个任务约有 5.7 秒的死时间。 ## **结构化输出可靠性：根本原因** 执行税是观察视角。结构化输出可靠性是驱动因素，也是生产型智能体中最被低估的瓶颈之一。 ### **数据** 模型总 LLM 调用次数解析重试次数重试率每次调用/任务Gemini 2.5 Flash88616518.6%14.7MiniMax M2.5828131.6%9.8GLM-588450.6%10.3Kimi K2.585200.0%10.2 Gemini 2.5 Flash 在**近五分之一的 LLM 调用中**产生了无效的结构化输出。三个 Fireworks 模型合计：在 2,564 次调用中有 18 次重试（0.7%）。 ### **为什么这比你想象的更重要** 在一个 10 步的智能体任务中，至少需要一次重试的概率： - •Gemini（每次调用 18.6%）：**86.7%** - •MiniMax（每次调用 1.6%）：14.9% - •Kimi（每次调用 0.0%）：0% 使用 Gemini，87% 的任务会经历至少一次解析重试。这不是边缘情况；而是默认体验。Gemini 每个任务平均需要 14.7 次 LLM 调用，而 Fireworks 模型约为 10 次：额外的约 4.7 次调用几乎全部是重试及其迫使的下游步骤。 ### **可靠性调整准确率** 原始任务准确率告诉你智能体成功的频率。它不考虑达成目标的成本。一个复合指标，**可靠性调整准确率**，通过执行开销来折减任务成功率： `可靠性调整准确率 = 任务成功率 × (1 − 执行税)` 模型任务准确率执行税可靠性调整准确率GLM-557.1%0.6%56.8%MiniMax M2.557.5%1.6%56.6%Kimi K2.549.7%0.0%49.7%Gemini 2.5 Flash45.0%22.9%34.7% Gemini 原始准确率（45.0%）与其可靠性调整准确率（34.7%）之间的差距，最清楚地说明了执行税：Gemini 超过三分之一的运营能力被执行开销消耗掉了。Fireworks 模型则几乎没有变化。 ### **为什么没人衡量这个** 解析重试发生在 LLM 引擎内部，在智能体框架看到结果之前。除非你对引擎进行仪器化，否则重试是不可见的。静态基准测试（MMLU、HumanEval、ARC）孤立地衡量模型智能；它们不衡量模型能否在多步骤循环中维持结构化输出合规性。**解析重试率应该成为每个智能体基准测试中的一级指标。** 先前的工作记录了类似的发现。最初的 **WebVoyager 论文**，He 等人，2024）引入了我们这里使用的基准测试，并确立了端到端 Web 智能体性能是与静态模型评估不同的独立衡量标准这一框架。**AgentBench**，Liu 等人，2024）在八个智能体环境中评估了 LLM，发现模型能力分数与多步骤循环中的任务完成率之间存在巨大差距，这强化了智能体特定的可靠性指标——而非 MMLU 排名——应驱动采购决策。**SWE-bench**，Jimenez 等人，2024）将相同的观察扩展到软件工程智能体：在推理排行榜上名列前茅的模型只能解决一小部分真实的 GitHub 问题，因为在长时间的工具使用循环中持续的结构化执行不是静态评估所衡量的。 ## **这在实践中是什么样的** **任务：**“查找伊利诺伊州芝加哥市所有的优衣库门店。”（来自 WebVoyager 基准测试的 Google Maps） 两个模型都收到了相同的任务、相同的浏览器环境和相同的起始 URL。 **概览：** Kimi K2.5Gemini 2.5 Flash执行步骤数1216LLM 调用次数1225解析重试次数09总时长51.2 秒97.9 秒总 LLM 时间23.2 秒57.5 秒输入 Token87,063207,971输出 Token3,2368,411结果成功成功 两个模型都找到了答案。一个用了 51 秒和 12 次干净的调用完成了任务。另一个花了 98 秒，进行了 25 次调用才完成了 16 步。差别不在于推理能力，而在于执行开销。 **Kimi K2.5：12 步，0 次重试** 步骤动作LLM 时间1导航至 google.com/maps1.57 秒2点击“接受 Cookie”1.75 秒3点击搜索输入框1.30 秒4输入“Uniqlo Chicago IL”1.47 秒5按回车键2.06 秒6点击返回（关闭单个地点面板）2.20 秒7输入“Uniqlo stores Chicago”1.49 秒8点击搜索2.09 秒9点击“附近”按钮2.02 秒10在附近搜索中输入“Uniqlo”2.60 秒11点击搜索3.33 秒12提交答案（找到 3 个地点）1.36 秒 每次调用都在第一次尝试时就产生了有效的 JSON。 **Gemini 2.5 Flash：16 步，9 次重试（共 25 次 LLM 调用）** 步骤动作1导航至 google.com/maps/2点击“接受 Cookie”3输入“Uniqlo Chicago, IL”4点击搜索5点击结果（打开单个地点面板）6点击返回结果7点击“下一页”按钮8输入“Uniqlo Chicago, IL”（重新搜索）9点击搜索10点击结果（打开单个地点面板）11输入“Uniqlo Chicago”（新查询）12点击搜索13点击结果（打开单个地点面板）14输入“Uniqlo locations Chicago IL”15点击搜索16提交答案 Gemini 执行了 16 个动作，但进行了 25 次 LLM 调用。九次调用返回了格式错误的响应并被静默丢弃。从框架的角度看，每一步似乎都成功了；重试在推理层内部是不可见的。 **协议层面的解析重试是什么样的** 每一步，智能体都必须返回一个结构化的 JSON 对象： `{ "state": { "previous_goal_status": "success", "previous_goal_eval": "成功点击了返回按钮。", "page_summary": "Google Maps 显示芝加哥的优衣库搜索结果。", "relevant_interactions": [{"id": "B3", "reason": "下一页按钮"}], "memory": "在 State Street 找到了一家优衣库。需要找到所有地点。", "next_goal": "点击下一页查看是否有更多结果。" }, "action": { "type": "click", "element_id": "B3" }}` 当响应与此模式不匹配时（缺少必填字段、动作类型无效、JSON 周围有 markdown 围栏），框架会捕获验证错误并发回一条纠正消息： `解析 LLM 响应出错： [{'type': 'missing', 'loc': ('state', 'memory'),'msg': 'Field required', 'input': {…}}], 正在重试` 然后，模型会再次接收完整的上下文以及错误信息，并重新生成。每次重新生成都会花费一次完整的推理调用：输入token（整个对话历史）加上输出token。以 Gemini 的上下文大小，一次重试大约增加 12,000–16,000 个 token 和 2–3 秒的延迟。在 9 次重试中，这相当于一个任务中大约 20–25 秒的死推理时间。 Gemini 的 98 秒大致分解为：大约 40 秒浏览器操作、37 秒有效推理和 21 秒重试推理。Kimi 的 51 秒根本没有重试部分。这就是在一个任务层面可见的执行税。 ## **我们是如何衡量的** Notte 是一个开源、模型无关的浏览器智能体框架。更改模型字符串，相同的智能体管线就会在不同的提供商之间以相同的方式运行。这使其成为隔离模型行为与框架效应的理想测试平台。 ### **设置** - •**任务套件：** WebVoyager，包含 15 个真实网站（Amazon、GitHub、Google Flights、Booking.com、ArXiv、Coursera、ESPN、BBC News 等）上的 60 个多步骤浏览器任务。 - •**运行：** 每个模型每个任务运行 3 次（每个模型 180 次运行，**总共 720 次**），以控制网站变异性和非确定性。 - •**仪器化：** 为每次运行捕获每次调用的 LLM 延迟、解析重试次数、解析失败次数和 token 使用量。 ### **模型** 模型提供商架构定价（每百万输入/输出 token）Gemini 2.5 FlashOpenRouter专有$0.30 / $2.50Kimi K2.5Fireworks AI32B 活跃 (1T MoE)$0.60 / $3.00GLM-5Fireworks AI40B 活跃 (700B MoE)$1.00 / $3.20MiniMax M2.5Fireworks AI228.7B MoE$0.30 / $1.20 所有三个开放权重模型均由 **Fireworks AI 的无服务器推理**提供服务；Gemini 2.5 Flash 由 OpenRouter 作为专有基线提供服务。没有专用部署，没有自定义基础设施——全程使用标准按 token 付费的 API，这是大多数开发者实际使用这些模型的方式。 因此，结果既反映了模型行为，也反映了在实际多步骤智能体工作负载下的生产服务特性，包括推理层的延迟一致性和结构化输出可靠性。 ### **本基准测试范围** **该基准测试衡量纯文本浏览器智能体循环中的结构化输出可靠性和步骤效率。它不是对模型智能、推理能力或多模态能力的普遍比较。** 评估其他用例（聊天助手、代码生成、独立多模态任务）模型的读者不应直接外推这些发现。以下排名、每产出成本和执行税值具体适用于纯文本智能体设置。 在该范围内：所有模型都进行了纯文本测试（无截图），以确保公平比较，因为 3 个 Fireworks 模型中只有 1 个支持视觉。这使得 Gemini 2.5 Flash 处于结构性劣势，因为 Notte 的生产管线是围绕 Gemini 的多模态能力构建的。我们会在结果中直接解决这个问题，但