E-Bench评测：智能体多步工具使用能力待突破

多步骤工具调用是AI落地真实业务场景的核心门槛，但当前的智能体评测体系存在诸多盲区。为此，由多家AI研发团队与高校联合推出的E-Bench，为AI智能体打造了一场贴近真实业务的公平测试。

• 论文标题：E-Bench: Benchmarking Multi-Step Tool-Use Agents in Real-World Product Scenarios

• 论文地址：https://arxiv.org/abs/2607.23722

我们可以用一个日常场景来理解这类多步骤工具调用任务：让AI帮你完成一个连贯的实操操作——在音乐平台中，将你最近播放的某位歌手的全部歌曲整理成专属歌单，再分享给你指定的几位好友。这个任务看似简单，但对AI智能体来说，其实是一连串环环相扣的考验。

它需要先检索你的播放历史，找出目标歌手的所有歌曲（不能遗漏任何一首），然后创建新的歌单，将歌曲批量添加进去，再识别出你指定的好友，最后完成分享。任何一步出现取错、漏取或者顺序错误，整个任务就会失败，而且没有“部分正确”的容错空间。

即便是当前性能顶尖的大语言模型，面对这类任务的表现并不理想：

• 能力较强的模型单次任务成功率仅为73.79%；

• 11个前沿模型的平均成功率只有54.56%，相当于一个典型智能体每两次尝试就会失败一次；

• 即便是能够三次独立尝试全部成功的“稳定靠谱”表现，最强模型也仅有58.82%的比例。

这正是E-Bench想要解答的核心问题：当AI不再局限于静态的文本问答，而是能够真正与真实环境交互、完成复杂的实操任务时，当前的智能体技术到底处于什么水平？最终的测试结果显示，这类多步骤工具调用能力还远未达到成熟的阶段。

当前的大语言模型正在从“回答单一的自包含问题”，向“作为智能体与外部环境进行多步交互、完成复杂任务”的方向演进。要真正完成一项实操任务，模型仅仅给出一个看似合理的回答是不够的，它需要反复完成四个核心步骤：

1）识别当前任务还缺失哪些必要信息 ➡️ 2）决定调用哪个工具来获取这些信息 ➡️ 3）在多步交互中整合观察到的结果 ➡️ 4）将最终的改动写入有状态的运行环境。

这种能力被称为多步骤工具使用，它支撑着当下最有价值的落地场景——操作软件、查询数据库、编排业务流程。

从“静态问答”到“动态交互”的这一演进，对评测方式提出了全新的要求。现有的智能体评测基准虽然推动了该领域的发展，但普遍存在三类明显的盲区：

• 仅聚焦单步/短程任务：多数评测仅关注孤立的API调用、短程的交互轨迹，或是不修改环境状态的静态问答，无法全面刻画“部分可观测、异构工具、长程依赖、精确修改状态”下的真实智能体能力。

• 真实系统基准难以规模化且易受污染：基于真实系统的评测基准通常成本高昂、难以标注，受数据安全和隐私约束，还会随着线上服务的迭代难以复现；更关键的是，当任务依赖公开常识或大众熟悉的接口时，模型的优异表现可能只是因为“见过该任务”，而非真正通过主动调用工具获取隐藏状态来完成任务。

• 合成环境过于“干净”：为简化开发，不少合成环境仅保留任务直接需要的少量数据，数据量小、干扰信息极少且指向性过强。这会导致模型测试时一查即中，检索结果过于理想化，变相“泄题”，测试的其实是“猜题”能力，而非在海量噪声中真正检索目标的能力。而真实产品环境恰恰相反，数据量大且充满无关干扰，这本身就是任务难度的重要来源。

E-Bench基于三个以真实产品业务为原型的全合成虚拟环境构建测试场景：分别对应MOBA社交游戏平台、在线音乐服务平台以及企业协同会议工具平台。

🎮 MOBA社交游戏平台：包含加好友、管理黑名单、创建/解散房间、收发邀请、审批战队申请、收藏对局、购买英雄等操作场景

🎵 在线音乐服务平台：包含搜索歌曲/歌手/专辑、创建与删除歌单、增删歌曲、收藏、关注歌手等操作场景

📅 企业协同会议工具：包含创建会议、预订会议室、创建日程、取消会议、管理群成员、跨部门调岗等操作场景

整个基准包含323个需要修改环境状态的实操任务，覆盖41张数据库表、超过76000条数据行以及逾60万个数据单元。每个领域的环境都是一个连贯的“产品世界”，而非一堆孤立的工具桩。

评测流程革新：解耦环境与任务合成

E-Bench最关键的设计步骤，是将整个评测体系的构建过程解耦为两个独立阶段：环境合成与任务合成。与传统评测为每个任务单独构建“状态快照”不同，E-Bench首先为每个领域构建一个可复用、完全模拟真实产品的运行环境，再在这个共享的完整环境之上批量生成大量测试任务。

环境的构建采用了图引导的数据库填充技术：

• 从关系型schema出发，构建表级依赖关系图；

• 初始化带主键/外键约束的空库并开启外键检查

• 按拓扑顺序填充数据：先生成根表数据（比如歌手、部门、会议室等），再生成依赖这些根表的下游数据

• 使用高性能大语言模型作为受约束的合成器，仅通过插入工具写入数据，下游表必须从当前库中查询候选实体，不能凭空捏造ID

• 最后用确定性脚本进行校验与修复，修正时间顺序、聚合计数、状态字段等语义错误

这套流程可以生成一个无孤立记录、跨表一致、数据丰富且支持工具交互的产品状态空间。E-Bench的每个数据库都被填充到较大的规模，目标实体被大量结构相似、语义相近的记录环绕，模型无法通过“数据库中只有少量记录”来蒙混过关，只能在充分的上下文信息中真正进行检索、过滤和比对，才能凑齐完整的目标集合。也正是因为环境完整、自洽且贴近真实规模，任务的难度才完全聚焦于“该获取哪些数据、该如何修改环境状态”，模型无法通过环境的稀疏或残缺来投机取巧，最终的评测结果才具备可信度。

出题逻辑：构建能力不对称的测试场景

如何确保测试任务必须通过与环境交互才能完成，而非仅凭prompt就能解答？E-Bench采用了精心设计的“能力不对称”机制，让出题的一方比答题的一方拥有更多的信息和更强的计算能力：

• 出题模型拥有特权：可以查看完整的数据库，能够运行SQL查询和代码

• 被测模型在测试时只能通过受限的领域工具观察环境，更贴近真实使用场景

这种设计天然制造了两道核心鸿沟：

● 信息鸿沟：全局的数据库状态对被测模型是隐藏的，任务无法仅通过阅读prompt就得到答案。测试过程中会通过“意图改写”步骤，将数据库生成的具体数值替换为生成该数值的规则，比如将“把我收藏里所有已下架的歌曲添加到歌单”作为任务描述，而非直接列出具体的歌曲ID或数量。这考验的是模型能否在动手操作前搜集到完整的必要信息，而非仅凭片面的证据就草率行动。

● 工具鸿沟：出题模型的计算能力更强，可以支持分页、聚合、集合运算、多跳遍历、链式写入等复杂操作；而在测试时，这些内部工具会被移除，被测模型只能使用业务级的工具，通过正确组合和排序多步（通常是并行）的工具调用来复现目标。

基于这两道鸿沟，E-Bench定义了六类核心的智能体能力：全量数据获取、多条件过滤、聚合与计算、跨步依赖、精确边界判断以及跨实体级联。每个任务都遵循“查看数据→确定目标→修改状态→总结意图”的产品化循环生成，并由三个不同的高性能智能体模型进行交叉验证，至少有两个模型复现一致的任务才会被采纳。

评分机制：基于数据库状态差异的确定性判断

E-Bench采用确定性的规则来判断任务是否完成。每个测试任务都绑定了一份“标准答案”，也就是出题模型操作前后的数据库状态差异。在评测时，只有当智能体最终生成的数据库状态与标准的状态差异完全匹配时，才算该次任务通过，不会给予任何部分得分。整个基准平均每个任务涉及24.9处行级改动，最多的单个任务甚至达到221处。这种评分方式稳定、可复现，不受语义判断的主观方差影响。

此外，E-Bench还提供了扩展版本E-Bench-Code，为被测模型开放exec_code工具，允许其在测试环境中编写Python代码，将领域工具作为函数调用。这个扩展版本补上了工具鸿沟，但保留了信息鸿沟，因此可以清晰地拆分出任务难度的来源：到底是难在“工具编排机制”，还是难在“想清楚该获取哪些信息”。

E-Bench对11款前沿的大语言模型进行了测试，包括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，每个任务都会独立运行3次，且每次测试都会从全新的数据库副本开始。

发现1：即便是性能最强的模型，也还有很大的提升空间。 在基础版E-Bench上，11款模型的平均成功率仅为54.56%。

发现2：可靠性是核心瓶颈。能够做到“稳定靠谱完成”（三次独立尝试全部成功）的比例，最强模型也仅有58.82%。

发现3：代码执行能力可以普遍提升测试表现，但可靠性仍受限制，表现最好的Pass³（Opus-4.8）也仍低于70%。

发现4：性能强的模型往往成本也高，成本是产品化落地中绕不开的关键因素。值得一提的是，即便不开启代码执行工具，Hy3也能够稳定完成复杂的长链路任务。比如在企业协同会议工具的测试场景中，Hy3可以一气呵成地完成“参会人选择→日程检索→会议室预订→会议创建→日历更新→群聊创建”这条跨多个实体、环环相扣的操作。

数据量与干扰信息是任务难度的核心来源：真正拉开测试表现差距的，往往不是任务描述的复杂程度，而是环境中存在的无关信息数量。E-Bench的数据库拥有7.6万+行数据和60万+个数据单元，目标实体常常被淹没在大量结构相似、语义相近的记录中，模型必须反复进行检索、过滤和比对，才能凑齐完整的目标集合。这也解释了为什么“过早行动”是最常见的失败模式：不是模型不会完成任务，而是它在信息还不完整的时候就开始了操作。数据规模与上下文丰富度，正是检验模型能否真正找全目标的试金石。

优秀的智能体需要兼顾性能与成本：能力与成本必须结合起来看。E-Bench的测试结果显示，不少模型虽然性能强劲，但单任务的开销很高。真正具备产品落地价值的，是那些能够同时站在“高准确率”和“低成本”两端的模型，而非单纯依赖堆砌算力的方案。

“想清楚该取什么信息”才是真正的瓶颈：在基础版E-Bench中，任务成功率与工具调用次数呈正相关：调用工具太少往往意味着模型在探索信息不足的情况下就过早行动；而在E-Bench-Code版本中，这种相关性变为弱负相关，因为一段代码可以折叠多个工具调用，“调用次数少”并不代表“完成的操作少”。这也印证了E-Bench的设计初衷：信息鸿沟才是智能体能力提升中最硬的骨头。

代码工具主要解决计算密集型任务：exec_code工具对“多条件过滤、全量获取、聚合计算”这类需要大量计算的任务收益最大；而对“跨步依赖、精确边界判断”这类需要推理决策的任务，收益则相对有限。这说明代码工具主要是将计算负载转移出去，而非解决核心的推理问题。

解耦环境与任务合成是高效的开发方式：一套完整、自洽且可复用的产品环境构建完成后，可以反复生成上百个测试任务，边际成本极低。而且当环境足够真实、数据足够丰富时，任务的难度自然会聚焦于信息鸿沟，无需为每一道测试题手工埋点。这也是E-Bench能够实现“环境层可控、任务层可扩展”的核心原因。

E-Bench的核心价值在于：采用全合成的测试环境，实现了环境层可控、任务层可扩展；采用确定性的数据库状态差异评测，避免了语义判断的主观方差；可复用的环境设计，一套环境可以支撑上百个测试任务；双鸿沟的设计，迫使模型主动搜集完整的隐藏信息，并正确组合多步或并行的工具调用。

核心结论：多步骤工具调用能力还远未被解决。即便是最强的模型，Avg@3也仅为73.79%，Pass³比例低于60%；即便开放代码执行工具，表现最好的Pass³比例也仍低于70%。

未来方向：将E-Bench拓展到CLI场景，增加更多的产品后端支持，从单一领域的测试走向跨领域的综合测试；同时，将E-Bench作为可控且可扩展的训练数据来源，用于持续提升智能体的多步工具调用能力与可靠性。欢迎通过以下链接参与相关合作：https://doc.weixin.qq.com/forms/AJEAIQdfAAoAa8ALgaVADMCNVsu10zNJf?page=1