文章核心概要研究问题大型语言模型LLM正从“回答问题”转向“执行操作”——即在多步交互中调用工具、收集信息、修改环境状态。然而现有基准测试要么只测单步API调用要么依赖真实系统导致难扩展、难复现缺乏一个既可控、可扩展又能真实反映多步工具使用挑战的评测平台。核心贡献作者提出了E-Bench及其代码增强版 E-Bench-Code一个完全合成的基准测试包含323个跨三个产品领域王者荣耀、QQ音乐、腾讯会议的状态变更任务用于系统评估LLM智能体的多步工具使用能力。一、E-Bench 的设计理念与核心机制1. 两大核心原则必须有连贯的环境不能是孤立的工具存根而是一个完整、有状态、引用完整的产品世界。任务不能走捷径必须通过与环境的真实多步交互才能解决。2. 两大核心机制解耦 不对称性机制说明环境合成与任务合成解耦先构建一个可复用的完整产品数据库每个领域约1.8万~2.9万行数据再从中衍生出大量任务。新任务无需重新设计底层数据。生成器-求解器不对称性任务生成器Claude Opus 4.7拥有完整数据库访问权query_sql和代码执行权exec_code求解器被测模型只能通过有限的领域MCP工具观察环境。这刻意制造了信息差和工具差。3. 环境构建的可靠性保障图引导的数据库填充按表依赖图拓扑顺序填充通过外键约束从根源上杜绝“孤立记录”。受约束的上下文感知合成LLM在填充时只能通过插入工具操作不能虚构ID确保引用完整性。生成后验证与修复自动修正时间顺序、聚合计数等语义错误。4. 任务构建的自动化与验证生成器通过“检查数据→决定目标→修改状态→总结意图”循环创作任务。记录数据库状态差异diff作为客观真实答案。由三个强验证器GPT-5.5、Claude Opus 4.7、GLM-5.1复核至少两者通过才采纳。最终评分完全基于确定性规则数据库diff比对无需LLM评判保证稳定性和可复现性。5. 六种能力类型任务被标注了六种能力分为两大组信息获取与计算型完整数据获取、多条件筛选、聚合与计算。推理与决策型跨步骤依赖、精确边界判断、跨实体级联。6. E-Bench-Code 扩展在基础设置上额外赋予求解器exec_code工具允许用Python批量调用领域API用于隔离分析“编排负担”与“信息获取推理”各自的难度。二、基准测试规模和统计特征维度数据总任务数323个三领域王者荣耀110 / QQ音乐104 / 腾讯会议109总数据量76,317行超过60万个数据单元格每个任务平均状态变更24.9行范围3~221行求解器可用工具基础版25~33个MCP工具Code版额外1个exec_code三、主要实验结果1. 多步工具使用远未解决最强模型Kimi-K3在E-Bench上的Avg3 仅为73.79%意味着即使最强模型单次尝试也失败超过1/4的任务。所有模型Avg3平均仅54.56%典型智能体单次尝试失败近一半。2. 可靠性是核心瓶颈Pass3三次至少一次成功与Pass³三次全部成功之间差距巨大。Kimi-K3Pass3 87.62%但 Pass³ 58.82% → 说明模型“偶尔能对但不稳定”。对于实际产品环境需要稳定可靠这种不稳定性是不可接受的。3. 代码执行E-Bench-Code显著提升性能但可靠性仍有限所有模型Avg3均有提升Opus-4.8升至81.11%Gemini-3.5-Flash相对提升46.7%。但最佳Pass³Opus-4.8仍低于70%→ 代码执行解决了部分问题但远非万能。4. 代码执行大幅降低交互成本MCP工具调用次数平均下降73.8%60.42 → 15.86。智能体操作轮数平均下降33.6%14.87 → 9.87。原因模型将多个独立工具调用折叠进一个exec_code块。5. 代码执行主要帮助“计算密集型”能力而非“推理密集型”增益最大多条件筛选10.61%、完整数据获取10.11%、聚合与计算9.45%。增益较小跨步骤依赖8.68%、精确边界判断7.55%。→ 代码执行擅长“批量干活”但不擅长“决定该干什么”。6. 模型选择性使用代码模型在困难、工具密集型任务上倾向使用exec_code而在简单任务上直接调用工具。使用代码时性能提升且成本降低不使用代码时两种设置表现几乎相同。7. 领域差异显著难度排序王者荣耀 腾讯会议 QQ音乐。模型排名跨领域变化大说明多领域评测的必要性。8. 成本-效率分析在相近准确率下API成本可差一个数量级以上。DeepSeek-V4-Pro、Hy3、Grok-4.5、Kimi-K3 处于帕累托前沿成本-效率最佳权衡。四、文章定位与创新点总结维度现有基准测试的不足E-Bench 的解决方案环境真实性多为单步API或静态QA完整有状态的模拟产品环境可扩展性依赖真实系统难扩展完全合成环境可控、任务可批量生成可复现性真实服务演化导致不稳定固定合成环境100%可复现评分客观性常依赖LLM评判或轨迹匹配确定性数据库diff比对无主观偏差任务难度缺少信息差和工具差通过生成器-求解器不对称性刻意制造评测维度偏重单次正确率引入Pass³衡量可靠性区分“偶尔能对”与“稳定能对”五、结论与展望结论当前最强LLM在多步工具使用任务上仍不可靠即使引入代码执行稳定性Pass³仍无法满足产品级部署要求。核心短板在于推理与决策如跨步骤依赖、边界判断而非单纯的计算或检索。代码执行能有效降低成本和提升计算型任务表现但不能替代真正的推理能力。未来工作扩展到真实领域CLI和在线产品后端。从单领域扩展到跨领域场景。将E-Bench作为可控训练数据来源用于提升智能体的多步工具使用能力和可靠性。E-Bench 是一个设计精良、完全合成、可控可扩展的基准测试通过刻意制造的信息差和工具差揭示了当前LLM在多步工具使用中“能干活但不稳定、会计算但缺推理”的核心短板为该领域的系统性改进提供了可靠的评测基础。这里是自己的论文阅读记录感兴趣的话可以参考一下如果需要阅读原文的话可以看这里如下所示摘要大型语言模型LLMs正越来越多地被部署为智能体这些智能体需要在多步操作中与有状态环境进行交互收集隐藏信息、组合工具调用以及执行状态变更。我们将这种能力称为多步工具使用。现有的基准测试推动了工具使用智能体评估的发展但通常侧重于孤立的API调用、短轨迹或难以扩展或控制的设置。我们引入了E-Bench一个完全合成的基准测试包含跨越三个产品领域的323个状态变更任务王者荣耀、QQ音乐和腾讯会议。E-Bench将环境合成与任务合成解耦基于图引导的数据库填充构建了可复用、无孤立数据的产品环境而生成器-求解器不对称性则创建了兼具信息差和工具差的任务要求智能体在执行状态变更前发现隐藏数据并组合多个工具调用。结果通过数据库状态差异进行确定性评分。由于环境和任务均为合成生成E-Bench在环境层面可控在任务层面可扩展。对11个前沿LLM的基准测试表明多步工具使用仍然具有挑战性最强模型的Pass3三次试验全部通过率仍低于60%即使在E-Bench-Code扩展中赋予代码执行能力其可靠性Pass3仍低于70%。图1 | E-Bench上图和E-Bench-Code下图中Avg3%与每任务总API成本美元的关系。计算细节包含在附录A.4中。虚线表示帕累托成本-效率前沿。1. 引言当前大型语言模型LLMs已超越回答独立提示词的范畴正越来越多地被部署为与外部环境交互以完成复杂任务的智能体Anthropic, 2024; Patil et al., 2024; Singh et al., 2025; Yao et al., 2022。因此成功所需的不仅仅是看似合理的响应LLM智能体必须反复识别缺失信息、决定调用哪些工具、跨步骤整合观测结果并将更改提交回有状态环境我们称之为多步工具使用。这种从“回答”到“行动”的转变要求基准测试能够在现实的交互约束下评估智能体行为而非仅仅是孤立的语言理解或单步工具选择。这一范式支撑着许多最有价值的现实世界应用从操作软件、查询数据库到编排业务流程然而这种基于环境交互的智能行为仍然难以系统性地评估。近期的基准测试探测了模型正确调用API的能力Patil et al., 2024, 2025; Qin et al., 2024以及在现实的Web、操作系统和软件工程环境中的操作能力Jimenez et al., 2024; Trivedi et al., 2024; Zhou et al., 2024。虽然这些基准测试揭示了模型在规划、工具接地和长周期执行方面的弱点但它们主要关注短的工具使用轨迹Mialon et al., 2023; Yao et al., 2024、孤立的API调用Patil et al., 2024, 2025或无需环境修改的静态问答Hendrycks et al., 2021; Rein et al., 2024; Yang et al., 2018因此未能捕捉到在部分可观测性、异构工具、长周期依赖性和精确状态变更操作下的智能体能力。此外尽管基于真实系统构建的基准测试提供了丰富的有状态交互但它们难以扩展、标注成本高昂、受数据安全和隐私约束敏感并且随着底层服务的演化而难以复现Liu et al., 2024; Xu et al., 2024; Yao et al., 2024。它们也可能难以去污染当任务依赖于公开事实、熟悉的接口或重复的工作流程时模型性能可能反映了先前的曝光而非通过工具主动获取隐藏状态的能力。因此一个可靠的基准测试必须提供一个完整、可控的环境使得模型无法通过捷径绕过预期的推理过程同时保持低成本扩展和安全发布。为此我们引入了E-Bench一个完全合成的基准测试用于评估多步工具使用智能体。E-Bench包含323个状态变更任务跨越三个模拟真实产品的领域王者荣耀、QQ音乐和腾讯会议。如图2所示这些任务采用逼真的自然语言请求形式图2a并通过与有状态产品环境的工具中介交互来解决正确性由精确的数据库状态差异决定图2b。E-Bench通过两个解耦的阶段构建环境合成和任务合成。对于每个领域我们首先构建一个可复用的、完全模拟的产品环境而非针对特定任务的状态快照然后从这个共享环境中合成大量状态变更任务。在第一阶段我们通过基于图引导的数据库填充合成一个大规模、多样化且一致的数据库。具体来说我们从关系模式构建一个表依赖图并使用强大的LLM按照拓扑顺序填充表通过构造强制执行引用完整性。这产生了一个无孤立数据、有状态的产品世界而非工具存根或任务局部装置。在第二阶段一个拥有SQL和代码访问权限的特权任务生成器通过一个逼真的产品循环检查数据 → 决定目标 → 修改状态 → 总结意图来探索此环境并创作任务。对于每个任务它记录诱导的数据库变更作为真实状态差异并标注所练习的工具使用能力。由于任务源自一个共享的可复用环境可以通过改变目标实体、约束和推理模式来生成新任务而无需重新设计底层数据。此外由于所有任务共享一个完整的底层环境而非任务特定的、不完整的局部快照求解器有更大的空间去探索可用上下文更好地反映了现实世界场景中遇到的上下文丰富性。在基准测试期间智能体求解器没有直接的数据库或SQL访问权限。在基础的E-Bench设置中它还被禁止执行代码而E-Bench-Code则授予此能力。这种生成器-求解器不对称性创造了信息差和工具差求解器必须发现隐藏数据、从部分观测中推理并组合可用工具例如发出并行的独立调用以产生正确的状态变更。结果通过将最终数据库状态与真实差异进行比较来确定性评分无需任何LLM评判。通过在模拟产品环境中通过多步工具交互来评估智能体E-Bench衡量它们收集必要信息、协调工具调用以及在行动前决定检索什么的能力。由于环境和任务都是合成构建的而非来自真实用户或在线服务E-Bench在环境层面可控在任务层面可扩展适用于面向训练的场景。我们的贡献如下1我们引入了E-Bench一个完全合成的基准测试用于系统评估LLM智能体在多步工具使用方面的能力包含323个状态变更任务跨越三个模拟真实公司产品的领域。2我们设计了一个完全合成的构建流程将环境合成与任务合成解耦使得单个可复用、保持完整性的环境能够支持可扩展的任务生成。评估使用确定性的数据库状态差异而非LLM评判。3我们对11个前沿LLM作为工具使用智能体进行了基准测试并发现多步工具使用远未解决最强模型Kimi-K3的Avg3平均通过率仅达到73.8%而Pass3三次试验全部通过率这一衡量一致性的指标仍低于60%。在E-Bench-Code中赋予代码执行能力提高了准确率但性能一致性仍然有限Pass33低于70%。2. 相关工作工具使用与函数调用基准测试。早期的工具使用基准测试评估模型是否能选择合适的工具并生成格式正确的调用。Gorilla (Patil et al., 2024) 将LLMs与大型API集合连接起来ToolLLM (Qin et al., 2024) 将指令遵循数据扩展到数千个真实世界的API而伯克利函数调用排行榜BFCL(Patil et al., 2025) 标准化了跨单次调用、并行调用、多轮和多步设置的函数调用评估。这些基准测试对于衡量API接地和调用结构正确性很有价值但它们主要将工具使用视为产生正确的调用。相比之下E-Bench评估与持久化环境的闭环交互智能体必须从观测中获取信息、跨步骤推理并执行影响后端产品状态的操作。用于工具使用基准测试的有状态智能体环境。第二类工作在更丰富、有状态的环境中评估智能体但通常在可控性、可复用性或自动化构建方面有所妥协。基于真实或在线MCP服务器构建的基准测试如MCP-Atlas (Bandi et al., 2026), MCP-Universe (Luo et al., 2025), MCP-Bench (Wang et al., 2026) 和 LiveMCPBench (Mo et al., 2025)提供了很高的生态效度但难以重置、扩展并且难以用于重复的状态变更评估。受控模拟器避免了在线服务的问题但常常将环境与单个任务耦合如AppWorld (Trivedi et al., 2024) 和 VitaBench (He et al., 2025)。更广泛地诸如VitaBench (He et al., 2025), τ-bench (Yao et al., 2024), ToolSandbox (Lu et al., 2025) 和 MCPMark (Wu et al., 2026) 等基准测试需要大量的人工或工程努力来封装用户请求、标注任务、创建真实答案或分别构建自定义检查器。MCPEval (Liu et al., 2025) 朝着自动化迈进通过从MCP工具规范生成任务并通过前沿智能体执行来验证它们然而它通过评估智能体与验证器生成的工具使用轨迹的一致性来评估这可能偏爱特定解决方案路径而非最终结果。E-Bench通过解耦自动环境和任务构建来解决这些局限性每个领域都是一个可复用、可控、基于数据库的产品世界跨越许多闭环任务共享。LLM智能体随后通过检查此环境、执行预期的状态变更并记录已验证的数据库差异作为轨迹无关的真实答案来合成任务从而实现无需特定任务工程或基于LLM评估的确定性评分。3. E-Bench一个多步工具使用基准测试3.1. 概述E-Bench遵循一个原则评估多步工具使用既需要一个连贯的环境也需要无法不与之交互就能解决的任务。为此E-Bench明确地将环境合成与任务合成解耦我们不是为每个任务构建一个特定任务的状态快照而是首先为每个领域构建一个可复用的、完全模拟的产品环境然后从这个共享环境状态中合成许多状态变更任务。因此E-Bench的构建有两个阶段。首先我们从关系模式构建一个纯合成的产品环境并通过基于图引导的数据库填充来填充它产生一个连贯、无孤立数据的、基于数据库的产品世界而非孤立的工具存根或任务局部装置。其次我们通过受控的生成器-求解器不对称性在预填充环境之上合成任务生成器可以检查完整数据库并使用特权工具而求解器只能通过受限的领域特定MCP工具观察环境。这通过设计引入了信息差和工具差迫使求解器恢复隐藏状态、组合多步且通常是并行的工具调用并执行可验证的状态变更。由于任务是从可复用的共享环境而非手工编写、带有任务特定数据装置的环境中生成的任务构建变得可扩展可以通过改变目标实体、约束和推理模式来衍生新任务而无需为每个任务重新设计底层数据。E-Bench在三个领域——王者荣耀、QQ音乐和腾讯会议——实例化了这一流程产生了323个状态变更任务。我们在图3中展示了一个来自腾讯会议的任务示例更多示例包含在附录B中。本节的其余部分组织如下第3.2节详述了基于图引导的环境构建第3.3节描述了自动任务构建和确定性评估第3.4节介绍了E-Bench-Code它授予求解器代码执行能力以部分弥合工具差第3.5节提供了E-Bench的全面统计总结。这些设计共同使E-Bench能够在现实的产品状态反馈下测试完整信息获取和多步并行工具使用。3.2. 可靠的环境构建E-Bench首先为每个领域构建一个完全由数据库模拟的产品环境。每个领域由一组表定义每个表对应一个具体的实体或关系。例如在音乐领域表代表用户、艺术家、专辑、歌曲、歌单、歌单-歌曲关系以及用户收藏在会议领域它们代表员工、部门、会议室、会议、参与者和员工日程。每个表进一步包含描述实体属性的字段例如专辑的发行日期、歌曲的歌词和版权状态或会议的开始时间和房间位置。因此环境构建的目标不是生成一小组看似合理的示例而是构建一个具有多样化实体类型、多跳关系和历史状态的产品级数据世界。基于图引导的数据库填充。每个领域内的表通过显式的外键依赖关系链接例如专辑引用已存在的艺术家歌曲引用已存在的专辑歌单-歌曲关系引用已存在的歌单和歌曲。这些依赖关系决定了记录的有效性因为只有当其引用的实体存在且语义一致时一行数据才有意义。因此E-Bench将每个关系模式转换为表级依赖图也参见图4左侧面板初始化一个具有主键和外键约束的空数据库启用外键检查并按拓扑顺序填充表。根表如艺术家、部门和会议室表首先生成随后仅在依赖关系物化后才生成下游表。此过程保证通过构造而非在自由形式生成后修复违规来确保引用完整性。受约束的上下文感知合成。在数据库合成期间E-Bench使用一个强大的LLM作为受约束的合成器而不是要求它自由生成整个数据库。在填充一个表时模型接收表模式、键注释、生成需求、全局领域上下文以及相关的现有记录。对于依赖于上游实体的表它基于每个父实体生成子记录如图4所示。例如在创建歌单-歌曲关系时模型观察当前歌单和采样的候选歌曲并在需要更多候选时发出只读查询。此过程通过工具中介的数据库交互来约束。模型仅通过插入工具插入记录允许数据库在插入时强制执行主键唯一性和外键有效性。对于必须从现有对象中选择的下游表模型被强制从当前数据库状态查询候选实体而不是虚构标识符。系统还会采样相关记录并沿着依赖图检索与父实体相关的上下文使提示保持紧凑同时保持跨表一致性。生成后验证与修复。数据库填充后E-Bench应用确定性验证和修复脚本以确保构建环境的保真度和完整性。这些脚本通过验证并自动修复跨字段、跨表和时间约束来纠正LLM合成数据中可能残留的语义错误例如不一致的时间顺序、不正确的聚合计数或不匹配的状态字段从而提高最终环境的一致性和质量。领域特定工具构建。验证后E-Bench在数据库之上构建领域特定的MCP工具。这些工具作为底层数据库的CRUD接口但向智能体暴露产品级语义例如搜索歌曲、查看歌单、添加收藏、查询会议室、创建会议和更新日程。因为所有工具都运行在同一个预填充、引用完整的数据库之上智能体在交互过程中会收到逼真的产品反馈检索到的歌曲链接到其专辑和艺术家会议链接到其参与者和房间歌单链接到实际存在的歌曲。我们进一步通过单元测试验证这些MCP工具的实现以确保工具行为与数据库语义保持一致。总体而言我们精心设计的构建流程避免了任务耦合基准测试中常见的不完整性在这种基准测试中环境可能只包含特定任务所需的对象。例如智能体可能检索到一个实体但无法访问其依赖项或相关上下文或者遇到引用缺失上游实体的下游记录即孤立记录。通过外键约束、基于图引导的数据库填充、受约束的上下文感知合成、受控插入以及确定性验证和修复E-Bench确保依赖字段在记录生成期间得到解析并且通过构造排除了孤立记录。结果不仅仅是一个可靠的合成数据库而是一个结构完整、跨表一致、工具可交互的产品状态空间为自动任务合成提供了稳定的基础。3.3. 可扩展的任务构建第二阶段将每个环境转化为基准测试任务遵循一个原则只有当一个任务真正需要与环境交互才能解决时才值得包含。E-Bench通过任务生成和求解之间的受控不对称性来强制执行这一点在生成期间一个强大的任务生成器Claude Opus 4.7在一个临时的数据库副本上工作可以检查全局状态并运行代码而在评估时求解器只看到一个自然语言请求和公共领域工具。这使得E-Bench能够创作出可确定性解决但无法走捷径的任务迫使智能体通过普通的工具调用来恢复隐藏信息并诱导所需的状态变更。这种不对称性有两个方面——通过构建引入的信息差和工具差——我们接下来将描述另请参见图5。信息差。信息差对求解器隐藏了全局数据库状态因此一个任务无法仅从其提示词中回答。看到完整模式和只读的query_sql生成器可以定义那些目标依赖于潜在状态而非命名值的任务——例如满足隐藏条件的所有歌曲、两个集合的交集、聚合下的顶级实体、隔几个外键跳的实体或最早可行的会议时段。这些知识永远不会泄露一个意图重写步骤将用户指定的值保持显式歌单名称、日期范围但将数据库派生的值替换为产生它们的规则因此查询说的是“将我收藏中未听过的歌曲添加进去”而不是列出歌曲ID或它们的数量。因此信息差的目标是完整信息获取它测试智能体是否能够在行动前主动收集完整的隐藏目标集合而不是在部分证据上过早提交。工具差。工具差使生成器在计算能力上强于基础求解器。在任务生成期间强大的任务生成器可以调用内部工具如query_sql和exec_code前者直接访问数据库而后者将公共工具作为可调用函数暴露使得能够编写分页结果、计算聚合、执行集合操作、遍历多跳关系和链接依赖写入的程序。这使得能够构建那些真实答案需要真正计算而非单次领域特定工具调用的任务。在评估时内部工具被移除只给智能体留下业务级别的领域特定MCP工具因此求解器必须通过普通工具调用来重现目标结果。这种差距测试了智能体是否能正确地组合和排序多步工具使用——包括在环境允许时发出独立的并行工具调用——以执行它们无法直接卸载的计算。E-Bench-Code通过授予求解器代码执行能力来部分弥合此差距比较这两种设置可以量化代码执行在多大程度上提高了性能上限。能力分类法作为合成指导。在定义了这两种差距后我们进一步为生成的任务定义了六种能力类型如表1所列。这些能力自然地从我们的基准测试设计中产生并分为两大类。第一组即完整数据获取、多条件筛选和聚合与计算主要由信息差驱动智能体必须检索、聚合和计算大量隐藏数据。工具差进一步放大了这些任务的难度但弥合它可以部分减轻负担。相比之下第二组即跨步骤依赖、精确边界判断和跨实体级联则更强调推理和决策要求智能体根据迄今积累的信息确定下一步行动。任务生成与验证。每个任务都通过一个面向产品的循环——检查数据 → 决定目标 → 修改状态 → 总结意图——为一个采样的用户和能力类型生成。我们在生成器写入前后对数据库进行快照记录确切的状态差异作为真实答案并丢弃那些没有状态变更、意图不可解析或工具使用过度的候选。通过初筛的任务随后由三个强大的验证器——GPT-5.5、Claude Opus 4.7和GLM-5.1——进行验证它们拥有与生成器相同的完整信息工具query_sql和exec_code。这将验证重点放在记录的状态变更的正确性上而非隐藏信息恢复。仅当至少两个验证器重现了与真实答案一致的变更时我们才接受该任务并进一步过滤掉那些能被弱基线轻松解决的任务。剩余的任务按能力类型分层以保持推理模式的平衡组合。最后每个被接受的任务都存储为一个自包含的JSON规范包含用户查询、预期的数据库变更和所练习的能力类型。由于正确性是根据确定性的数据库状态变更而非LLM评判来检查的因此评估是稳定的且对语义评判的变异性不那么敏感。3.4. E-Bench-Code弥合工具差由于E-Bench对求解器隐藏了代码执行能力强大的任务生成器和求解器之间仍然存在工具差第3.3节。我们的扩展E-Bench-Code通过授予求解器生成器的exec_code工具来部分弥合它通过该工具智能体可以编写Python代码将领域特定的MCP工具作为内部函数调用——以编程方式分页、聚合和执行集合操作而不是手动编排长调用序列。所有其他因素保持不变任务、工具、数据库副本和状态差异评估器因此任何性能差异都可归因于此接口。重要的是E-Bench-Code弥合了工具差但没有弥合信息差exec_code只暴露业务级别的领域特定API而不是query_sql或原始数据库访问因此智能体仍然必须通过可观察的环境来发现隐藏目标。这两种设置因此隔离了互补的能力E-Bench测试在极长的多步工具调用序列上的手动协调能力而E-Bench-Code则测试智能体是否提取了相关信息。比较它们揭示了有多大困难源于编排机制又有多少源于关于检索什么的推理。3.5. 基准测试统计表2总结了构建环境和任务的规模和多样性。每个领域形成一个连贯的产品世界而非薄弱的工具存根集合合成数据库包含12到16个表由16到29个外键关系连接总共有72到168列每个表有2到22列平均6.0到10.5。填充这些模式每个领域产生18.6K到29.4K行总计76.3K和超过60万个数据单元格围绕170个用户王者荣耀、54个用户QQ音乐和995名员工腾讯会议以及引用它们的英雄、歌曲、会议和其他实体组织。由于任务是从这个共享的、预填充的状态而非任务局部装置合成的每个环境支持大约一百个不同的任务。每个领域的设计目标如下王者荣耀一个MOBA游戏平台涵盖玩家社交互动、战队管理、房间匹配和对局回顾。智能体可以查询当前用户的玩家、英雄、段位、好友、战队、房间和对局记录并执行诸如添加好友、管理黑名单、创建或解散房间、发送或回应房间邀请、批准战队申请、收藏对局和购买英雄等操作。QQ音乐一个音乐平台涵盖内容搜索、用户偏好和歌单管理。智能体可以搜索和查看歌曲、艺术家、专辑、歌单、评论和收听历史并对当前用户执行诸如创建或删除歌单、添加或移除歌曲、收藏歌曲和关注艺术家等操作。腾讯会议一个企业协作平台涵盖组织结构、群聊、会议、会议室预订和员工日程。智能体可以查询员工、部门、群聊、会议、会议室和日程并对当前员工执行诸如创建会议、预订会议室、创建日程、取消会议、管理群聊成员和跨部门调动员工等操作。产生的任务需要实质性的状态变更而非单条记录编辑。每个任务都绑定了一个用于评分的真实数据库差异平均每个任务有24.9行级别的变更范围从王者荣耀的9.5到腾讯会议的48.5。单个任务诱导3到221个变更。变更模式是领域依赖的王者荣耀的任务混合了插入、更新和删除而QQ音乐和腾讯会议以插入为主反映了批量操作如添加收藏、预订会议和邀请参与者。这种规模和编辑类型的多样性要求智能体跟踪许多相互依赖的状态变更而不是执行单个局部操作。此外如表1所示不同领域强调不同的任务类别导致难度和评估重点的差异。4. 主要结果4.1. 评估设置模型。我们评估了11个前沿LLM在实验时从每个开发者处选择一个代表性模型GPT-5.5, Opus-4.8, Grok-4.5, GLM-5.2, Qwen-3.7-Max, Hy3, Seed-2.1-Pro, Gemini-3.5-Flash, MiniMax-M3, Kimi-K3, DeepSeek-V4-Pro 和 Muse-Spark-1.1。每个模型都作为一个智能体运行使用其最高可用的思考力度通过一个共享的测试工具运行该工具暴露每个领域的MCP工具并管理多轮交互循环。实验和指标。每个任务进行三次独立试验每次试验都从一个全新的、隔离的领域数据库副本开始以防止跨试验干扰。只有当智能体的最终数据库状态与我们的确定性基于规则的验证器下的真实差异完全匹配时试验才算成功否则不会获得部分分数。我们报告三个严格程度递增的指标。Avg3是所有任务和试验的平均每次试验成功率衡量平均性能。Pass3如果三次试验中至少有一次成功则计为任务解决。Pass33要求所有三次试验都成功衡量可靠性Pass3和Pass33之间的差距揭示了模型在重现正确状态变更方面的一致性如何。效率度量。除了准确性我们还记录了工具调用次数、智能体操作轮数以及跨任务的平均输入/输出令牌数以评估交互成本并描述智能体效率。我们在基础的E-Bench求解器只能访问领域特定的MCP工具和E-Bench-Code额外提供exec_code两种设置下评估所有模型。4.2. 主要结果表3报告了所有评估模型在E-Bench上按Avg3排序的性能以及在代码执行设置下测试的E-Bench-Code结果。图6和图7比较了每种模型在两种设置下的各领域Avg3和各领域交互成本MCP工具调用次数和智能体操作轮数。4.2.1. E-Bench多步工具使用远未解决。即使是最强大的智能体在E-Bench上仍有很大的提升空间。Kimi-K3实现了最高的Avg3达到73.79%其次是GPT-5.5, Opus-4.8和Grok-4.5均超过66%而没有其他模型超过53%。此外在所有11个模型中Avg3平均仅为54.56%。这表明一个典型的智能体在单次尝试中几乎失败了近一半的任务。可靠性仍然是核心瓶颈。Pass3、Avg3和Pass33之间的差距表明许多智能体只是间歇性地成功Pass3显著高于Pass33。即使是顶级模型也不稳健Kimi-K3从87.62%的Pass3下降到58.82%的Pass33GPT-5.5从82.97%下降到57.59%。对于较弱的模型可靠性几乎崩溃。由于E-Bench要求精确的状态变更且不给部分分数这种不稳定性在实际中具有重要意义只是偶尔解决任务的智能体尚不足以信赖去修改在线产品状态。4.2.2. E-Bench-Code代码执行提升了所有模型的性能但可靠性仍然有限。在E-Bench-Code中授予智能体exec_code提高了所有评估模型的Avg3无论模型强弱。增益是显著的Opus-4.8从68.78%上升到81.11%取代Kimi-K3和GPT-5.5成为榜首Gemini-3.5-Flash从42.62%攀升至62.54%——相对提升了惊人的46.7%较弱的模型如DeepSeek-V4-Pro也获得了38.32%的相对提升。然而即使有了代码执行最佳Pass33Opus-4.8仍低于70%最差的仅为21.13%在可靠性方面仍有很大的改进空间。代码执行重新洗牌了排行榜使更强的代码使用者受益。在排行榜上排名上升的模型往往是那些有效利用exec_code的模型Gemini-3.5-Flash从第9位升至第6位而Opus-4.8已知的强大编码器取代了它在E-Bench中的第三名占据了榜首位置。这些模型将大部分交互通过代码进行例如Gemini-3.5-Flash为95%Opus-4.8为93%用紧凑的程序取代了许多单独的工具调用即通常在exec_code内部调用领域特定函数而不是直接调用它们对应的MCP工具。我们将在第4.5节进一步分析这种行为。代码执行在降低成本的同时提高了准确性。exec_code带来的性能提升伴随着显著更低的交互成本。如图7所示启用exec_code将每任务的平均MCP工具调用次数从60.42减少到15.86下降了73.8%智能体轮数从14.87减少到9.87下降了33.6%这是11个模型和三个域的平均值。如前一节所述这种减少来自于一个exec_code块将多轮的领域函数调用折叠成一个顶层操作。结合图6中的Avg3增益这表明exec_code使模型能够以更低的成本解决更多任务。这些改进如何在任务间分布的进一步分析见第4.5节。4.3. 难度如何随领域变化各领域分析我们进一步分别分析每个领域。图6绘制了各模型在三个领域的Avg3。领域难度和代码执行增益都不均匀。图6显示王者荣耀是最具挑战性的领域而QQ音乐是最容易的。在E-Bench下王者荣耀、腾讯会议和QQ音乐的平均Avg3分别为43.64%、58.87%和61.39%。在E-Bench-Code下这些分别上升到52.36%、67.78%和71.94%。QQ音乐从代码执行中获益最多平均增加了10.55个百分点而王者荣耀和腾讯会议分别增加了8.72和8.91个百分点。这与其能力组合相匹配QQ音乐包含更多需要检索和聚合大量数据的任务例如完整数据获取和聚合与计算任务而需要推理决策的任务较少例如精确边界判断任务exec_code可以加速这些任务第4.4节。大多数模型排名因领域而异。跨领域和设置Kimi-K3、GPT-5.5和Opus-4.8构成了前沿梯队Grok-4.5是强大的第二梯队。然而排名对领域高度敏感。例如Grok-4.5在QQ音乐的E-Bench基础设置中是最好的模型但在王者荣耀中仅处于中游。在前沿梯队之下模型紧密聚集并在不同领域间显著重新排序。排名也因设置而转移因为exec_code不成比例地惠及强大的代码使用者。这些结果表明稳健的多步工具使用评估需要覆盖不同的领域而不是专注于单一领域。4.4. 代码执行在哪里有帮助各能力分析为了进一步确定exec_code在哪些方面有帮助表4按能力分解了添加exec_code带来的Avg3增益这是11个评估模型的平均值。代码执行对计算帮助大于推理。如表4所示exec_code带来的最大增益出现在机械密集型能力上多条件筛选、完整数据获取和聚合与计算同时具有最高的绝对和相对Avg3改进。这些任务需要穷举检索、精确筛选、聚合和中间结果跟踪代码可以通过循环和迭代可靠地处理这些。相比之下跨步骤依赖和精确边界判断的增益较小因为这些能力更多地依赖于选择正确的实体、依赖关系、阈值或操作顺序。因此exec_code主要卸载的是计算而非推理和决策这解释了其较大的平均增益以及E-Bench-Code中仍存在的提升空间。4.5. 模型何时选择编码各任务分析另一个有趣的观察结果是即使在E-Bench-Code下exec_code可用许多模型仍然在不使用它的情况下解决一些任务无论是在试验中一致地还是偶尔地。图8根据三次试验中exec_code的使用情况对任务进行分组所有试验都使用它all-C没有试验使用它no-C或者使用情况混合partial。对于这些组我们比较了任务平均性能Avg3、MCP工具调用和智能体操作轮数并附上配对的E-Bench结果作为参考。为清晰起见我们在主文中展示了三个代表模型的结果其他模型见附录A.2。代码执行拯救了困难任务同时降低了交互成本。模型一致避免使用exec_code的任务no-C相对容易通常需要的MCP工具调用最少交互轮数最短。相应地两种设置在no-C任务上的表现几乎相同工具调用和轮数基本不变Avg3仅有微小波动。相比之下模型一致使用exec_code的任务all-C是最苛刻的而exec_code在显著减少MCP调用和智能体轮数的同时带来了巨大的性能提升使成本接近no-C任务的成本。混合使用任务显示出相同的趋势Avg3从52.53%提高到57.70%而MCP调用平均从32.68下降到24.34。总体而言exec_code被选择性地用于苛刻的、工具繁重的任务在这些任务中它将多步、通常是并行的领域特定工具调用批处理成由更精确代码控制的更短的执行轨迹。这一发现进一步解释了图6和图7中显示的性能大幅提升和交互成本降低的来源。4.6. 花费更多有帮助吗性能与交互成本一个自然的问题是失败的智能体是否只需要更努力地尝试——发出更多的工具调用或消耗更多的上下文。图11附录A.3绘制了Avg3与三个每任务成本度量即任务平均MCP工具调用次数、轮数和总令牌数的关系每个模型领域一个点。困难任务需要更多交互。在E-Bench下每个动作都是一个普通的领域工具调用跨33个模型领域对的Avg3与工具调用次数呈中等正相关皮尔逊 r0.57。在某些领域内相关性甚至更强王者荣耀、腾讯会议和QQ音乐的 rr 分别为 0.86、0.61 和 0.89。这与基准测试预期的信息差相匹配求解器必须在提交状态变更操作之前通过多步、通常是并行的工具使用来收集隐藏信息。在这种基础设置中低调用次数通常表示过早行动而非效率。轮数和总令牌消耗也与成功率呈弱正相关r0.39 和 r0.38与困难任务需要更多交互和思考一致。相比之下在E-Bench-Code中跨相同33对Avg3与LLM发出的工具调用次数呈弱负相关皮尔逊 r−0.36在QQ音乐中负相关性更强r−0.87在腾讯会议和王者荣耀中较弱r−0.57 和 r−0.36。因为模型可以将许多领域特定函数调用折叠到单个exec_code块中更少的发出工具调用并不意味着更少的工作。相反结果表明通过代码执行可以在保持或提高性能Avg3的同时降低成本。附录A.3中提供了更多分析。关于效率和API成本图1的更详细分析见附录A。5. 结论与未来工作在这项工作中我们介绍了E-Bench及其支持代码的扩展E-Bench-Code这是一个完全合成的基准测试用于评估LLM智能体在多步工具使用方面的能力。E-Bench将环境合成与任务合成分离基于图引导的数据库填充构建了可复用、无孤立数据的环境而生成器-求解器不对称性则创建了具有信息差和工具差的状态变更任务。智能体必须在改变状态之前发现隐藏数据并组合多个通常是并行的工具调用。由于环境和任务都是合成的E-Bench是可控的、可扩展的并通过数据库状态差异进行确定性评分。对11个前沿LLM的基准测试表明多步工具使用仍未解决。最佳模型在E-Bench上的Avg3仅达到73.79%Pass3仍低于60%。E-Bench-Code中的exec_code改进了每个模型但即使最佳Pass33也保持在70%以下。增益来自于将工作折叠到代码中强大的智能体为计算密集型的数据获取、聚合和筛选批处理工具调用而推理密集型的跨实体级联和边界敏感决策仍然困难。未来的工作将把E-Bench扩展到真实领域的CLI和在线产品后端并从单领域任务扩展到能更好反映真实产品工作流的跨领域场景。我们也视E-Bench为一个可控、可扩展的训练数据来源用于提升智能体的多步工具使用能力和可靠性。 E-Bench: Benchmarking Multi-Step Tool-Use Agents inReal-World Product Scenarios在真实产品场景中对多步工具使用智能体进行基
文章核心概要研究问题大型语言模型LLM正从“回答问题”转向“执行操作”——即在多步交互中调用工具、收集信息、修改环境状态。然而现有基准测试要么只测单步API调用要么依赖真实系统导致难扩展、难复现缺乏一个既可控、可扩展又能真实反映多步工具使用挑战的评测平台。核心贡献作者提出了E-Bench及其代码增强版 E-Bench-Code一个完全合成的基准测试包含323个跨三个产品领域王者荣耀、QQ音乐、腾讯会议的状态变更任务用于系统评估LLM智能体的多步工具使用能力。一、E-Bench 的设计理念与核心机制1. 两大核心原则必须有连贯的环境不能是孤立的工具存根而是一个完整、有状态、引用完整的产品世界。任务不能走捷径必须通过与环境的真实多步交互才能解决。2. 两大核心机制解耦 不对称性机制说明环境合成与任务合成解耦先构建一个可复用的完整产品数据库每个领域约1.8万~2.9万行数据再从中衍生出大量任务。新任务无需重新设计底层数据。生成器-求解器不对称性任务生成器Claude Opus 4.7拥有完整数据库访问权query_sql和代码执行权exec_code求解器被测模型只能通过有限的领域MCP工具观察环境。这刻意制造了信息差和工具差。3. 环境构建的可靠性保障图引导的数据库填充按表依赖图拓扑顺序填充通过外键约束从根源上杜绝“孤立记录”。受约束的上下文感知合成LLM在填充时只能通过插入工具操作不能虚构ID确保引用完整性。生成后验证与修复自动修正时间顺序、聚合计数等语义错误。4. 任务构建的自动化与验证生成器通过“检查数据→决定目标→修改状态→总结意图”循环创作任务。记录数据库状态差异diff作为客观真实答案。由三个强验证器GPT-5.5、Claude Opus 4.7、GLM-5.1复核至少两者通过才采纳。最终评分完全基于确定性规则数据库diff比对无需LLM评判保证稳定性和可复现性。5. 六种能力类型任务被标注了六种能力分为两大组信息获取与计算型完整数据获取、多条件筛选、聚合与计算。推理与决策型跨步骤依赖、精确边界判断、跨实体级联。6. E-Bench-Code 扩展在基础设置上额外赋予求解器exec_code工具允许用Python批量调用领域API用于隔离分析“编排负担”与“信息获取推理”各自的难度。二、基准测试规模和统计特征维度数据总任务数323个三领域王者荣耀110 / QQ音乐104 / 腾讯会议109总数据量76,317行超过60万个数据单元格每个任务平均状态变更24.9行范围3~221行求解器可用工具基础版25~33个MCP工具Code版额外1个exec_code三、主要实验结果1. 多步工具使用远未解决最强模型Kimi-K3在E-Bench上的Avg3 仅为73.79%意味着即使最强模型单次尝试也失败超过1/4的任务。所有模型Avg3平均仅54.56%典型智能体单次尝试失败近一半。2. 可靠性是核心瓶颈Pass3三次至少一次成功与Pass³三次全部成功之间差距巨大。Kimi-K3Pass3 87.62%但 Pass³ 58.82% → 说明模型“偶尔能对但不稳定”。对于实际产品环境需要稳定可靠这种不稳定性是不可接受的。3. 代码执行E-Bench-Code显著提升性能但可靠性仍有限所有模型Avg3均有提升Opus-4.8升至81.11%Gemini-3.5-Flash相对提升46.7%。但最佳Pass³Opus-4.8仍低于70%→ 代码执行解决了部分问题但远非万能。4. 代码执行大幅降低交互成本MCP工具调用次数平均下降73.8%60.42 → 15.86。智能体操作轮数平均下降33.6%14.87 → 9.87。原因模型将多个独立工具调用折叠进一个exec_code块。5. 代码执行主要帮助“计算密集型”能力而非“推理密集型”增益最大多条件筛选10.61%、完整数据获取10.11%、聚合与计算9.45%。增益较小跨步骤依赖8.68%、精确边界判断7.55%。→ 代码执行擅长“批量干活”但不擅长“决定该干什么”。6. 模型选择性使用代码模型在困难、工具密集型任务上倾向使用exec_code而在简单任务上直接调用工具。使用代码时性能提升且成本降低不使用代码时两种设置表现几乎相同。7. 领域差异显著难度排序王者荣耀 腾讯会议 QQ音乐。模型排名跨领域变化大说明多领域评测的必要性。8. 成本-效率分析在相近准确率下API成本可差一个数量级以上。DeepSeek-V4-Pro、Hy3、Grok-4.5、Kimi-K3 处于帕累托前沿成本-效率最佳权衡。四、文章定位与创新点总结维度现有基准测试的不足E-Bench 的解决方案环境真实性多为单步API或静态QA完整有状态的模拟产品环境可扩展性依赖真实系统难扩展完全合成环境可控、任务可批量生成可复现性真实服务演化导致不稳定固定合成环境100%可复现评分客观性常依赖LLM评判或轨迹匹配确定性数据库diff比对无主观偏差任务难度缺少信息差和工具差通过生成器-求解器不对称性刻意制造评测维度偏重单次正确率引入Pass³衡量可靠性区分“偶尔能对”与“稳定能对”五、结论与展望结论当前最强LLM在多步工具使用任务上仍不可靠即使引入代码执行稳定性Pass³仍无法满足产品级部署要求。核心短板在于推理与决策如跨步骤依赖、边界判断而非单纯的计算或检索。代码执行能有效降低成本和提升计算型任务表现但不能替代真正的推理能力。未来工作扩展到真实领域CLI和在线产品后端。从单领域扩展到跨领域场景。将E-Bench作为可控训练数据来源用于提升智能体的多步工具使用能力和可靠性。E-Bench 是一个设计精良、完全合成、可控可扩展的基准测试通过刻意制造的信息差和工具差揭示了当前LLM在多步工具使用中“能干活但不稳定、会计算但缺推理”的核心短板为该领域的系统性改进提供了可靠的评测基础。这里是自己的论文阅读记录感兴趣的话可以参考一下如果需要阅读原文的话可以看这里如下所示摘要大型语言模型LLMs正越来越多地被部署为智能体这些智能体需要在多步操作中与有状态环境进行交互收集隐藏信息、组合工具调用以及执行状态变更。我们将这种能力称为多步工具使用。现有的基准测试推动了工具使用智能体评估的发展但通常侧重于孤立的API调用、短轨迹或难以扩展或控制的设置。我们引入了E-Bench一个完全合成的基准测试包含跨越三个产品领域的323个状态变更任务王者荣耀、QQ音乐和腾讯会议。E-Bench将环境合成与任务合成解耦基于图引导的数据库填充构建了可复用、无孤立数据的产品环境而生成器-求解器不对称性则创建了兼具信息差和工具差的任务要求智能体在执行状态变更前发现隐藏数据并组合多个工具调用。结果通过数据库状态差异进行确定性评分。由于环境和任务均为合成生成E-Bench在环境层面可控在任务层面可扩展。对11个前沿LLM的基准测试表明多步工具使用仍然具有挑战性最强模型的Pass3三次试验全部通过率仍低于60%即使在E-Bench-Code扩展中赋予代码执行能力其可靠性Pass3仍低于70%。图1 | E-Bench上图和E-Bench-Code下图中Avg3%与每任务总API成本美元的关系。计算细节包含在附录A.4中。虚线表示帕累托成本-效率前沿。1. 引言当前大型语言模型LLMs已超越回答独立提示词的范畴正越来越多地被部署为与外部环境交互以完成复杂任务的智能体Anthropic, 2024; Patil et al., 2024; Singh et al., 2025; Yao et al., 2022。因此成功所需的不仅仅是看似合理的响应LLM智能体必须反复识别缺失信息、决定调用哪些工具、跨步骤整合观测结果并将更改提交回有状态环境我们称之为多步工具使用。这种从“回答”到“行动”的转变要求基准测试能够在现实的交互约束下评估智能体行为而非仅仅是孤立的语言理解或单步工具选择。这一范式支撑着许多最有价值的现实世界应用从操作软件、查询数据库到编排业务流程然而这种基于环境交互的智能行为仍然难以系统性地评估。近期的基准测试探测了模型正确调用API的能力Patil et al., 2024, 2025; Qin et al., 2024以及在现实的Web、操作系统和软件工程环境中的操作能力Jimenez et al., 2024; Trivedi et al., 2024; Zhou et al., 2024。虽然这些基准测试揭示了模型在规划、工具接地和长周期执行方面的弱点但它们主要关注短的工具使用轨迹Mialon et al., 2023; Yao et al., 2024、孤立的API调用Patil et al., 2024, 2025或无需环境修改的静态问答Hendrycks et al., 2021; Rein et al., 2024; Yang et al., 2018因此未能捕捉到在部分可观测性、异构工具、长周期依赖性和精确状态变更操作下的智能体能力。此外尽管基于真实系统构建的基准测试提供了丰富的有状态交互但它们难以扩展、标注成本高昂、受数据安全和隐私约束敏感并且随着底层服务的演化而难以复现Liu et al., 2024; Xu et al., 2024; Yao et al., 2024。它们也可能难以去污染当任务依赖于公开事实、熟悉的接口或重复的工作流程时模型性能可能反映了先前的曝光而非通过工具主动获取隐藏状态的能力。因此一个可靠的基准测试必须提供一个完整、可控的环境使得模型无法通过捷径绕过预期的推理过程同时保持低成本扩展和安全发布。为此我们引入了E-Bench一个完全合成的基准测试用于评估多步工具使用智能体。E-Bench包含323个状态变更任务跨越三个模拟真实产品的领域王者荣耀、QQ音乐和腾讯会议。如图2所示这些任务采用逼真的自然语言请求形式图2a并通过与有状态产品环境的工具中介交互来解决正确性由精确的数据库状态差异决定图2b。E-Bench通过两个解耦的阶段构建环境合成和任务合成。对于每个领域我们首先构建一个可复用的、完全模拟的产品环境而非针对特定任务的状态快照然后从这个共享环境中合成大量状态变更任务。在第一阶段我们通过基于图引导的数据库填充合成一个大规模、多样化且一致的数据库。具体来说我们从关系模式构建一个表依赖图并使用强大的LLM按照拓扑顺序填充表通过构造强制执行引用完整性。这产生了一个无孤立数据、有状态的产品世界而非工具存根或任务局部装置。在第二阶段一个拥有SQL和代码访问权限的特权任务生成器通过一个逼真的产品循环检查数据 → 决定目标 → 修改状态 → 总结意图来探索此环境并创作任务。对于每个任务它记录诱导的数据库变更作为真实状态差异并标注所练习的工具使用能力。由于任务源自一个共享的可复用环境可以通过改变目标实体、约束和推理模式来生成新任务而无需重新设计底层数据。此外由于所有任务共享一个完整的底层环境而非任务特定的、不完整的局部快照求解器有更大的空间去探索可用上下文更好地反映了现实世界场景中遇到的上下文丰富性。在基准测试期间智能体求解器没有直接的数据库或SQL访问权限。在基础的E-Bench设置中它还被禁止执行代码而E-Bench-Code则授予此能力。这种生成器-求解器不对称性创造了信息差和工具差求解器必须发现隐藏数据、从部分观测中推理并组合可用工具例如发出并行的独立调用以产生正确的状态变更。结果通过将最终数据库状态与真实差异进行比较来确定性评分无需任何LLM评判。通过在模拟产品环境中通过多步工具交互来评估智能体E-Bench衡量它们收集必要信息、协调工具调用以及在行动前决定检索什么的能力。由于环境和任务都是合成构建的而非来自真实用户或在线服务E-Bench在环境层面可控在任务层面可扩展适用于面向训练的场景。我们的贡献如下1我们引入了E-Bench一个完全合成的基准测试用于系统评估LLM智能体在多步工具使用方面的能力包含323个状态变更任务跨越三个模拟真实公司产品的领域。2我们设计了一个完全合成的构建流程将环境合成与任务合成解耦使得单个可复用、保持完整性的环境能够支持可扩展的任务生成。评估使用确定性的数据库状态差异而非LLM评判。3我们对11个前沿LLM作为工具使用智能体进行了基准测试并发现多步工具使用远未解决最强模型Kimi-K3的Avg3平均通过率仅达到73.8%而Pass3三次试验全部通过率这一衡量一致性的指标仍低于60%。在E-Bench-Code中赋予代码执行能力提高了准确率但性能一致性仍然有限Pass33低于70%。2. 相关工作工具使用与函数调用基准测试。早期的工具使用基准测试评估模型是否能选择合适的工具并生成格式正确的调用。Gorilla (Patil et al., 2024) 将LLMs与大型API集合连接起来ToolLLM (Qin et al., 2024) 将指令遵循数据扩展到数千个真实世界的API而伯克利函数调用排行榜BFCL(Patil et al., 2025) 标准化了跨单次调用、并行调用、多轮和多步设置的函数调用评估。这些基准测试对于衡量API接地和调用结构正确性很有价值但它们主要将工具使用视为产生正确的调用。相比之下E-Bench评估与持久化环境的闭环交互智能体必须从观测中获取信息、跨步骤推理并执行影响后端产品状态的操作。用于工具使用基准测试的有状态智能体环境。第二类工作在更丰富、有状态的环境中评估智能体但通常在可控性、可复用性或自动化构建方面有所妥协。基于真实或在线MCP服务器构建的基准测试如MCP-Atlas (Bandi et al., 2026), MCP-Universe (Luo et al., 2025), MCP-Bench (Wang et al., 2026) 和 LiveMCPBench (Mo et al., 2025)提供了很高的生态效度但难以重置、扩展并且难以用于重复的状态变更评估。受控模拟器避免了在线服务的问题但常常将环境与单个任务耦合如AppWorld (Trivedi et al., 2024) 和 VitaBench (He et al., 2025)。更广泛地诸如VitaBench (He et al., 2025), τ-bench (Yao et al., 2024), ToolSandbox (Lu et al., 2025) 和 MCPMark (Wu et al., 2026) 等基准测试需要大量的人工或工程努力来封装用户请求、标注任务、创建真实答案或分别构建自定义检查器。MCPEval (Liu et al., 2025) 朝着自动化迈进通过从MCP工具规范生成任务并通过前沿智能体执行来验证它们然而它通过评估智能体与验证器生成的工具使用轨迹的一致性来评估这可能偏爱特定解决方案路径而非最终结果。E-Bench通过解耦自动环境和任务构建来解决这些局限性每个领域都是一个可复用、可控、基于数据库的产品世界跨越许多闭环任务共享。LLM智能体随后通过检查此环境、执行预期的状态变更并记录已验证的数据库差异作为轨迹无关的真实答案来合成任务从而实现无需特定任务工程或基于LLM评估的确定性评分。3. E-Bench一个多步工具使用基准测试3.1. 概述E-Bench遵循一个原则评估多步工具使用既需要一个连贯的环境也需要无法不与之交互就能解决的任务。为此E-Bench明确地将环境合成与任务合成解耦我们不是为每个任务构建一个特定任务的状态快照而是首先为每个领域构建一个可复用的、完全模拟的产品环境然后从这个共享环境状态中合成许多状态变更任务。因此E-Bench的构建有两个阶段。首先我们从关系模式构建一个纯合成的产品环境并通过基于图引导的数据库填充来填充它产生一个连贯、无孤立数据的、基于数据库的产品世界而非孤立的工具存根或任务局部装置。其次我们通过受控的生成器-求解器不对称性在预填充环境之上合成任务生成器可以检查完整数据库并使用特权工具而求解器只能通过受限的领域特定MCP工具观察环境。这通过设计引入了信息差和工具差迫使求解器恢复隐藏状态、组合多步且通常是并行的工具调用并执行可验证的状态变更。由于任务是从可复用的共享环境而非手工编写、带有任务特定数据装置的环境中生成的任务构建变得可扩展可以通过改变目标实体、约束和推理模式来衍生新任务而无需为每个任务重新设计底层数据。E-Bench在三个领域——王者荣耀、QQ音乐和腾讯会议——实例化了这一流程产生了323个状态变更任务。我们在图3中展示了一个来自腾讯会议的任务示例更多示例包含在附录B中。本节的其余部分组织如下第3.2节详述了基于图引导的环境构建第3.3节描述了自动任务构建和确定性评估第3.4节介绍了E-Bench-Code它授予求解器代码执行能力以部分弥合工具差第3.5节提供了E-Bench的全面统计总结。这些设计共同使E-Bench能够在现实的产品状态反馈下测试完整信息获取和多步并行工具使用。3.2. 可靠的环境构建E-Bench首先为每个领域构建一个完全由数据库模拟的产品环境。每个领域由一组表定义每个表对应一个具体的实体或关系。例如在音乐领域表代表用户、艺术家、专辑、歌曲、歌单、歌单-歌曲关系以及用户收藏在会议领域它们代表员工、部门、会议室、会议、参与者和员工日程。每个表进一步包含描述实体属性的字段例如专辑的发行日期、歌曲的歌词和版权状态或会议的开始时间和房间位置。因此环境构建的目标不是生成一小组看似合理的示例而是构建一个具有多样化实体类型、多跳关系和历史状态的产品级数据世界。基于图引导的数据库填充。每个领域内的表通过显式的外键依赖关系链接例如专辑引用已存在的艺术家歌曲引用已存在的专辑歌单-歌曲关系引用已存在的歌单和歌曲。这些依赖关系决定了记录的有效性因为只有当其引用的实体存在且语义一致时一行数据才有意义。因此E-Bench将每个关系模式转换为表级依赖图也参见图4左侧面板初始化一个具有主键和外键约束的空数据库启用外键检查并按拓扑顺序填充表。根表如艺术家、部门和会议室表首先生成随后仅在依赖关系物化后才生成下游表。此过程保证通过构造而非在自由形式生成后修复违规来确保引用完整性。受约束的上下文感知合成。在数据库合成期间E-Bench使用一个强大的LLM作为受约束的合成器而不是要求它自由生成整个数据库。在填充一个表时模型接收表模式、键注释、生成需求、全局领域上下文以及相关的现有记录。对于依赖于上游实体的表它基于每个父实体生成子记录如图4所示。例如在创建歌单-歌曲关系时模型观察当前歌单和采样的候选歌曲并在需要更多候选时发出只读查询。此过程通过工具中介的数据库交互来约束。模型仅通过插入工具插入记录允许数据库在插入时强制执行主键唯一性和外键有效性。对于必须从现有对象中选择的下游表模型被强制从当前数据库状态查询候选实体而不是虚构标识符。系统还会采样相关记录并沿着依赖图检索与父实体相关的上下文使提示保持紧凑同时保持跨表一致性。生成后验证与修复。数据库填充后E-Bench应用确定性验证和修复脚本以确保构建环境的保真度和完整性。这些脚本通过验证并自动修复跨字段、跨表和时间约束来纠正LLM合成数据中可能残留的语义错误例如不一致的时间顺序、不正确的聚合计数或不匹配的状态字段从而提高最终环境的一致性和质量。领域特定工具构建。验证后E-Bench在数据库之上构建领域特定的MCP工具。这些工具作为底层数据库的CRUD接口但向智能体暴露产品级语义例如搜索歌曲、查看歌单、添加收藏、查询会议室、创建会议和更新日程。因为所有工具都运行在同一个预填充、引用完整的数据库之上智能体在交互过程中会收到逼真的产品反馈检索到的歌曲链接到其专辑和艺术家会议链接到其参与者和房间歌单链接到实际存在的歌曲。我们进一步通过单元测试验证这些MCP工具的实现以确保工具行为与数据库语义保持一致。总体而言我们精心设计的构建流程避免了任务耦合基准测试中常见的不完整性在这种基准测试中环境可能只包含特定任务所需的对象。例如智能体可能检索到一个实体但无法访问其依赖项或相关上下文或者遇到引用缺失上游实体的下游记录即孤立记录。通过外键约束、基于图引导的数据库填充、受约束的上下文感知合成、受控插入以及确定性验证和修复E-Bench确保依赖字段在记录生成期间得到解析并且通过构造排除了孤立记录。结果不仅仅是一个可靠的合成数据库而是一个结构完整、跨表一致、工具可交互的产品状态空间为自动任务合成提供了稳定的基础。3.3. 可扩展的任务构建第二阶段将每个环境转化为基准测试任务遵循一个原则只有当一个任务真正需要与环境交互才能解决时才值得包含。E-Bench通过任务生成和求解之间的受控不对称性来强制执行这一点在生成期间一个强大的任务生成器Claude Opus 4.7在一个临时的数据库副本上工作可以检查全局状态并运行代码而在评估时求解器只看到一个自然语言请求和公共领域工具。这使得E-Bench能够创作出可确定性解决但无法走捷径的任务迫使智能体通过普通的工具调用来恢复隐藏信息并诱导所需的状态变更。这种不对称性有两个方面——通过构建引入的信息差和工具差——我们接下来将描述另请参见图5。信息差。信息差对求解器隐藏了全局数据库状态因此一个任务无法仅从其提示词中回答。看到完整模式和只读的query_sql生成器可以定义那些目标依赖于潜在状态而非命名值的任务——例如满足隐藏条件的所有歌曲、两个集合的交集、聚合下的顶级实体、隔几个外键跳的实体或最早可行的会议时段。这些知识永远不会泄露一个意图重写步骤将用户指定的值保持显式歌单名称、日期范围但将数据库派生的值替换为产生它们的规则因此查询说的是“将我收藏中未听过的歌曲添加进去”而不是列出歌曲ID或它们的数量。因此信息差的目标是完整信息获取它测试智能体是否能够在行动前主动收集完整的隐藏目标集合而不是在部分证据上过早提交。工具差。工具差使生成器在计算能力上强于基础求解器。在任务生成期间强大的任务生成器可以调用内部工具如query_sql和exec_code前者直接访问数据库而后者将公共工具作为可调用函数暴露使得能够编写分页结果、计算聚合、执行集合操作、遍历多跳关系和链接依赖写入的程序。这使得能够构建那些真实答案需要真正计算而非单次领域特定工具调用的任务。在评估时内部工具被移除只给智能体留下业务级别的领域特定MCP工具因此求解器必须通过普通工具调用来重现目标结果。这种差距测试了智能体是否能正确地组合和排序多步工具使用——包括在环境允许时发出独立的并行工具调用——以执行它们无法直接卸载的计算。E-Bench-Code通过授予求解器代码执行能力来部分弥合此差距比较这两种设置可以量化代码执行在多大程度上提高了性能上限。能力分类法作为合成指导。在定义了这两种差距后我们进一步为生成的任务定义了六种能力类型如表1所列。这些能力自然地从我们的基准测试设计中产生并分为两大类。第一组即完整数据获取、多条件筛选和聚合与计算主要由信息差驱动智能体必须检索、聚合和计算大量隐藏数据。工具差进一步放大了这些任务的难度但弥合它可以部分减轻负担。相比之下第二组即跨步骤依赖、精确边界判断和跨实体级联则更强调推理和决策要求智能体根据迄今积累的信息确定下一步行动。任务生成与验证。每个任务都通过一个面向产品的循环——检查数据 → 决定目标 → 修改状态 → 总结意图——为一个采样的用户和能力类型生成。我们在生成器写入前后对数据库进行快照记录确切的状态差异作为真实答案并丢弃那些没有状态变更、意图不可解析或工具使用过度的候选。通过初筛的任务随后由三个强大的验证器——GPT-5.5、Claude Opus 4.7和GLM-5.1——进行验证它们拥有与生成器相同的完整信息工具query_sql和exec_code。这将验证重点放在记录的状态变更的正确性上而非隐藏信息恢复。仅当至少两个验证器重现了与真实答案一致的变更时我们才接受该任务并进一步过滤掉那些能被弱基线轻松解决的任务。剩余的任务按能力类型分层以保持推理模式的平衡组合。最后每个被接受的任务都存储为一个自包含的JSON规范包含用户查询、预期的数据库变更和所练习的能力类型。由于正确性是根据确定性的数据库状态变更而非LLM评判来检查的因此评估是稳定的且对语义评判的变异性不那么敏感。3.4. E-Bench-Code弥合工具差由于E-Bench对求解器隐藏了代码执行能力强大的任务生成器和求解器之间仍然存在工具差第3.3节。我们的扩展E-Bench-Code通过授予求解器生成器的exec_code工具来部分弥合它通过该工具智能体可以编写Python代码将领域特定的MCP工具作为内部函数调用——以编程方式分页、聚合和执行集合操作而不是手动编排长调用序列。所有其他因素保持不变任务、工具、数据库副本和状态差异评估器因此任何性能差异都可归因于此接口。重要的是E-Bench-Code弥合了工具差但没有弥合信息差exec_code只暴露业务级别的领域特定API而不是query_sql或原始数据库访问因此智能体仍然必须通过可观察的环境来发现隐藏目标。这两种设置因此隔离了互补的能力E-Bench测试在极长的多步工具调用序列上的手动协调能力而E-Bench-Code则测试智能体是否提取了相关信息。比较它们揭示了有多大困难源于编排机制又有多少源于关于检索什么的推理。3.5. 基准测试统计表2总结了构建环境和任务的规模和多样性。每个领域形成一个连贯的产品世界而非薄弱的工具存根集合合成数据库包含12到16个表由16到29个外键关系连接总共有72到168列每个表有2到22列平均6.0到10.5。填充这些模式每个领域产生18.6K到29.4K行总计76.3K和超过60万个数据单元格围绕170个用户王者荣耀、54个用户QQ音乐和995名员工腾讯会议以及引用它们的英雄、歌曲、会议和其他实体组织。由于任务是从这个共享的、预填充的状态而非任务局部装置合成的每个环境支持大约一百个不同的任务。每个领域的设计目标如下王者荣耀一个MOBA游戏平台涵盖玩家社交互动、战队管理、房间匹配和对局回顾。智能体可以查询当前用户的玩家、英雄、段位、好友、战队、房间和对局记录并执行诸如添加好友、管理黑名单、创建或解散房间、发送或回应房间邀请、批准战队申请、收藏对局和购买英雄等操作。QQ音乐一个音乐平台涵盖内容搜索、用户偏好和歌单管理。智能体可以搜索和查看歌曲、艺术家、专辑、歌单、评论和收听历史并对当前用户执行诸如创建或删除歌单、添加或移除歌曲、收藏歌曲和关注艺术家等操作。腾讯会议一个企业协作平台涵盖组织结构、群聊、会议、会议室预订和员工日程。智能体可以查询员工、部门、群聊、会议、会议室和日程并对当前员工执行诸如创建会议、预订会议室、创建日程、取消会议、管理群聊成员和跨部门调动员工等操作。产生的任务需要实质性的状态变更而非单条记录编辑。每个任务都绑定了一个用于评分的真实数据库差异平均每个任务有24.9行级别的变更范围从王者荣耀的9.5到腾讯会议的48.5。单个任务诱导3到221个变更。变更模式是领域依赖的王者荣耀的任务混合了插入、更新和删除而QQ音乐和腾讯会议以插入为主反映了批量操作如添加收藏、预订会议和邀请参与者。这种规模和编辑类型的多样性要求智能体跟踪许多相互依赖的状态变更而不是执行单个局部操作。此外如表1所示不同领域强调不同的任务类别导致难度和评估重点的差异。4. 主要结果4.1. 评估设置模型。我们评估了11个前沿LLM在实验时从每个开发者处选择一个代表性模型GPT-5.5, Opus-4.8, Grok-4.5, GLM-5.2, Qwen-3.7-Max, Hy3, Seed-2.1-Pro, Gemini-3.5-Flash, MiniMax-M3, Kimi-K3, DeepSeek-V4-Pro 和 Muse-Spark-1.1。每个模型都作为一个智能体运行使用其最高可用的思考力度通过一个共享的测试工具运行该工具暴露每个领域的MCP工具并管理多轮交互循环。实验和指标。每个任务进行三次独立试验每次试验都从一个全新的、隔离的领域数据库副本开始以防止跨试验干扰。只有当智能体的最终数据库状态与我们的确定性基于规则的验证器下的真实差异完全匹配时试验才算成功否则不会获得部分分数。我们报告三个严格程度递增的指标。Avg3是所有任务和试验的平均每次试验成功率衡量平均性能。Pass3如果三次试验中至少有一次成功则计为任务解决。Pass33要求所有三次试验都成功衡量可靠性Pass3和Pass33之间的差距揭示了模型在重现正确状态变更方面的一致性如何。效率度量。除了准确性我们还记录了工具调用次数、智能体操作轮数以及跨任务的平均输入/输出令牌数以评估交互成本并描述智能体效率。我们在基础的E-Bench求解器只能访问领域特定的MCP工具和E-Bench-Code额外提供exec_code两种设置下评估所有模型。4.2. 主要结果表3报告了所有评估模型在E-Bench上按Avg3排序的性能以及在代码执行设置下测试的E-Bench-Code结果。图6和图7比较了每种模型在两种设置下的各领域Avg3和各领域交互成本MCP工具调用次数和智能体操作轮数。4.2.1. E-Bench多步工具使用远未解决。即使是最强大的智能体在E-Bench上仍有很大的提升空间。Kimi-K3实现了最高的Avg3达到73.79%其次是GPT-5.5, Opus-4.8和Grok-4.5均超过66%而没有其他模型超过53%。此外在所有11个模型中Avg3平均仅为54.56%。这表明一个典型的智能体在单次尝试中几乎失败了近一半的任务。可靠性仍然是核心瓶颈。Pass3、Avg3和Pass33之间的差距表明许多智能体只是间歇性地成功Pass3显著高于Pass33。即使是顶级模型也不稳健Kimi-K3从87.62%的Pass3下降到58.82%的Pass33GPT-5.5从82.97%下降到57.59%。对于较弱的模型可靠性几乎崩溃。由于E-Bench要求精确的状态变更且不给部分分数这种不稳定性在实际中具有重要意义只是偶尔解决任务的智能体尚不足以信赖去修改在线产品状态。4.2.2. E-Bench-Code代码执行提升了所有模型的性能但可靠性仍然有限。在E-Bench-Code中授予智能体exec_code提高了所有评估模型的Avg3无论模型强弱。增益是显著的Opus-4.8从68.78%上升到81.11%取代Kimi-K3和GPT-5.5成为榜首Gemini-3.5-Flash从42.62%攀升至62.54%——相对提升了惊人的46.7%较弱的模型如DeepSeek-V4-Pro也获得了38.32%的相对提升。然而即使有了代码执行最佳Pass33Opus-4.8仍低于70%最差的仅为21.13%在可靠性方面仍有很大的改进空间。代码执行重新洗牌了排行榜使更强的代码使用者受益。在排行榜上排名上升的模型往往是那些有效利用exec_code的模型Gemini-3.5-Flash从第9位升至第6位而Opus-4.8已知的强大编码器取代了它在E-Bench中的第三名占据了榜首位置。这些模型将大部分交互通过代码进行例如Gemini-3.5-Flash为95%Opus-4.8为93%用紧凑的程序取代了许多单独的工具调用即通常在exec_code内部调用领域特定函数而不是直接调用它们对应的MCP工具。我们将在第4.5节进一步分析这种行为。代码执行在降低成本的同时提高了准确性。exec_code带来的性能提升伴随着显著更低的交互成本。如图7所示启用exec_code将每任务的平均MCP工具调用次数从60.42减少到15.86下降了73.8%智能体轮数从14.87减少到9.87下降了33.6%这是11个模型和三个域的平均值。如前一节所述这种减少来自于一个exec_code块将多轮的领域函数调用折叠成一个顶层操作。结合图6中的Avg3增益这表明exec_code使模型能够以更低的成本解决更多任务。这些改进如何在任务间分布的进一步分析见第4.5节。4.3. 难度如何随领域变化各领域分析我们进一步分别分析每个领域。图6绘制了各模型在三个领域的Avg3。领域难度和代码执行增益都不均匀。图6显示王者荣耀是最具挑战性的领域而QQ音乐是最容易的。在E-Bench下王者荣耀、腾讯会议和QQ音乐的平均Avg3分别为43.64%、58.87%和61.39%。在E-Bench-Code下这些分别上升到52.36%、67.78%和71.94%。QQ音乐从代码执行中获益最多平均增加了10.55个百分点而王者荣耀和腾讯会议分别增加了8.72和8.91个百分点。这与其能力组合相匹配QQ音乐包含更多需要检索和聚合大量数据的任务例如完整数据获取和聚合与计算任务而需要推理决策的任务较少例如精确边界判断任务exec_code可以加速这些任务第4.4节。大多数模型排名因领域而异。跨领域和设置Kimi-K3、GPT-5.5和Opus-4.8构成了前沿梯队Grok-4.5是强大的第二梯队。然而排名对领域高度敏感。例如Grok-4.5在QQ音乐的E-Bench基础设置中是最好的模型但在王者荣耀中仅处于中游。在前沿梯队之下模型紧密聚集并在不同领域间显著重新排序。排名也因设置而转移因为exec_code不成比例地惠及强大的代码使用者。这些结果表明稳健的多步工具使用评估需要覆盖不同的领域而不是专注于单一领域。4.4. 代码执行在哪里有帮助各能力分析为了进一步确定exec_code在哪些方面有帮助表4按能力分解了添加exec_code带来的Avg3增益这是11个评估模型的平均值。代码执行对计算帮助大于推理。如表4所示exec_code带来的最大增益出现在机械密集型能力上多条件筛选、完整数据获取和聚合与计算同时具有最高的绝对和相对Avg3改进。这些任务需要穷举检索、精确筛选、聚合和中间结果跟踪代码可以通过循环和迭代可靠地处理这些。相比之下跨步骤依赖和精确边界判断的增益较小因为这些能力更多地依赖于选择正确的实体、依赖关系、阈值或操作顺序。因此exec_code主要卸载的是计算而非推理和决策这解释了其较大的平均增益以及E-Bench-Code中仍存在的提升空间。4.5. 模型何时选择编码各任务分析另一个有趣的观察结果是即使在E-Bench-Code下exec_code可用许多模型仍然在不使用它的情况下解决一些任务无论是在试验中一致地还是偶尔地。图8根据三次试验中exec_code的使用情况对任务进行分组所有试验都使用它all-C没有试验使用它no-C或者使用情况混合partial。对于这些组我们比较了任务平均性能Avg3、MCP工具调用和智能体操作轮数并附上配对的E-Bench结果作为参考。为清晰起见我们在主文中展示了三个代表模型的结果其他模型见附录A.2。代码执行拯救了困难任务同时降低了交互成本。模型一致避免使用exec_code的任务no-C相对容易通常需要的MCP工具调用最少交互轮数最短。相应地两种设置在no-C任务上的表现几乎相同工具调用和轮数基本不变Avg3仅有微小波动。相比之下模型一致使用exec_code的任务all-C是最苛刻的而exec_code在显著减少MCP调用和智能体轮数的同时带来了巨大的性能提升使成本接近no-C任务的成本。混合使用任务显示出相同的趋势Avg3从52.53%提高到57.70%而MCP调用平均从32.68下降到24.34。总体而言exec_code被选择性地用于苛刻的、工具繁重的任务在这些任务中它将多步、通常是并行的领域特定工具调用批处理成由更精确代码控制的更短的执行轨迹。这一发现进一步解释了图6和图7中显示的性能大幅提升和交互成本降低的来源。4.6. 花费更多有帮助吗性能与交互成本一个自然的问题是失败的智能体是否只需要更努力地尝试——发出更多的工具调用或消耗更多的上下文。图11附录A.3绘制了Avg3与三个每任务成本度量即任务平均MCP工具调用次数、轮数和总令牌数的关系每个模型领域一个点。困难任务需要更多交互。在E-Bench下每个动作都是一个普通的领域工具调用跨33个模型领域对的Avg3与工具调用次数呈中等正相关皮尔逊 r0.57。在某些领域内相关性甚至更强王者荣耀、腾讯会议和QQ音乐的 rr 分别为 0.86、0.61 和 0.89。这与基准测试预期的信息差相匹配求解器必须在提交状态变更操作之前通过多步、通常是并行的工具使用来收集隐藏信息。在这种基础设置中低调用次数通常表示过早行动而非效率。轮数和总令牌消耗也与成功率呈弱正相关r0.39 和 r0.38与困难任务需要更多交互和思考一致。相比之下在E-Bench-Code中跨相同33对Avg3与LLM发出的工具调用次数呈弱负相关皮尔逊 r−0.36在QQ音乐中负相关性更强r−0.87在腾讯会议和王者荣耀中较弱r−0.57 和 r−0.36。因为模型可以将许多领域特定函数调用折叠到单个exec_code块中更少的发出工具调用并不意味着更少的工作。相反结果表明通过代码执行可以在保持或提高性能Avg3的同时降低成本。附录A.3中提供了更多分析。关于效率和API成本图1的更详细分析见附录A。5. 结论与未来工作在这项工作中我们介绍了E-Bench及其支持代码的扩展E-Bench-Code这是一个完全合成的基准测试用于评估LLM智能体在多步工具使用方面的能力。E-Bench将环境合成与任务合成分离基于图引导的数据库填充构建了可复用、无孤立数据的环境而生成器-求解器不对称性则创建了具有信息差和工具差的状态变更任务。智能体必须在改变状态之前发现隐藏数据并组合多个通常是并行的工具调用。由于环境和任务都是合成的E-Bench是可控的、可扩展的并通过数据库状态差异进行确定性评分。对11个前沿LLM的基准测试表明多步工具使用仍未解决。最佳模型在E-Bench上的Avg3仅达到73.79%Pass3仍低于60%。E-Bench-Code中的exec_code改进了每个模型但即使最佳Pass33也保持在70%以下。增益来自于将工作折叠到代码中强大的智能体为计算密集型的数据获取、聚合和筛选批处理工具调用而推理密集型的跨实体级联和边界敏感决策仍然困难。未来的工作将把E-Bench扩展到真实领域的CLI和在线产品后端并从单领域任务扩展到能更好反映真实产品工作流的跨领域场景。我们也视E-Bench为一个可控、可扩展的训练数据来源用于提升智能体的多步工具使用能力和可靠性。