E-Bench：从单步调API到真实状态流转，顶尖Agent可靠性为何不足60%？
E-Bench: Benchmarking Multi-Step Tool-Use Agents in Real-World Product Scenarios
让大语言模型（LLM）调用 API 已经不再是新鲜事，但让 Agent 在真实软件环境中连续完成一整套业务操作，依然是一道难以逾越的鸿沟。在现实业务中，用户的一句简单指令往往涉及复杂的状态依赖：排查日程、锁定会议室、拉通多位同事的空闲时间并最终发起预订，或者在对战游戏中调取多项战绩指标并调整战术配置。这类任务不仅要求模型给出单次正确的函数调用，更要求其在拥有状态（Stateful）的真实环境中，历经多步探索、收集隐藏信息、编排依赖工具，并对底层数据库产生预期的修改。
ArXiv URL：https://arxiv.org/abs/2607.23722v1
以往针对工具调用的基准测试，多聚焦于单步参数补全或孤立的 API 匹配，缺乏真正有状态的环境反馈；而直接基于在线真实系统搭建的测试集，又常常面临隐私合规受限、环境动态漂移、接口维护成本过高以及数据易受污染等困境。由东南大学、腾讯与清华大学联合推出的基准评测 E-Bench，正是为了打破这一僵局而设计。它构建了一个包含 323 个真实状态修改任务的全合成闭环评测平台，涵盖《王者荣耀》、QQ音乐与腾讯会议三大经典产品形态。
评测结果揭示了一个残酷的现实：即便面对当前全球最顶尖的 11 款前沿大模型，多步有状态工具调用依然是一个尚未攻克的难题。在无需写代码的基准设定下，最强模型的三次平均成功率（Avg@3）仅为 73.79%，而能够连续 3 次稳定完成任务的严格可靠性指标（$\text{Pass}^3$）更是一律跌破 60%（最高仅 58.82%）。即便赋予模型编写 Python 代码来批量编排工具的扩展能力（E-Bench-Code），其严格可靠性依然被压制在 70% 以下。这一结论表明，阻碍智能体走向工业级落地的真正瓶颈，已经从单纯的“指令遵循”演变为了“长程有状态规划与可靠执行”。
为什么以往的工具评测无法反映真实业务？
当前评估大模型工具使用能力的主流测试集，如早期的 Gorilla、ToolLLM 以及近期的 Berkeley Function Calling Leaderboard（BFCL），在规范 API 调用格式和检测语法结构方面做出了重要贡献。然而，这套逻辑本质上是将工具调用视作一种“特殊语法补全”，模型只需要在上下文充分的前提下，输出形如 func(arg1=val) 的正确格式即可拿分。
但是在真正的企业级应用中，工具调用从来不是孤立发生的。一个完整的业务流通常包含三层核心复杂性：
首先是部分可观测性（Partial Observability）。现实环境不会把所有上下文一股脑打包塞进提示词中。当用户发起“帮我预约明天下午所有参会人都空闲的会议室”时，模型必须先检索参会人员名单，再分别拉取每个人的独立日程，计算出时间交集，随后查询空闲会议室，最后才能调用创建接口。
其次是长程依赖与异构编排。模型需要维护跨轮次的状态观测，任何中间步骤的信息提取偏差都会在下游步骤成倍放大，导致最终动作彻底偏离轨道。
最后是不可逆的状态变更（State-Changing Operations）。查询数据只是手段，真实任务的终点通常是对底层系统进行增、删、改。传统的 LLM-as-a-judge 评估机制在面对这类复杂业务逻辑时，极易出现幻觉或语义误判，无法精确界定数据库状态是否完全正确变更。
如果为了追求真实性而直接把评测接入正在运行的线上产品，又会带来新的工程灾难。随着时间推移，线上数据不断变更，测试结果难以完全复现；公网服务的请求频率限制和敏感数据合规限制阻碍了基准的大规模开源与复用；更为关键的是，模型在预训练阶段极有可能已经接触过公开接口的文档和调用样本，造成严重的基准污染。
环境与任务解耦：图引导的数据填充机制
为了兼顾环境的逼真度与评测的完全可控性，E-Bench 采取了“全合成（Fully Synthetic）”的底层设计方案，并提出了核心原则：将环境合成与任务合成彻底解耦。
许多传统合成评测往往采用“为任务定制快照”的做法，每个问题只拼装一组恰好够用的局部模拟数据。这种做法导致环境极度贫瘠，Agent 稍微向外多走一步就会报错。E-Bench 摒弃了这种局部打补丁的思路，转而为三大业务领域（《王者荣耀》、QQ音乐、腾讯会议）分别构建完整映射真实业务架构的关联数据库底座。例如，在音乐领域，数据库完备定义了用户、歌手、专辑、歌曲、歌单、收藏关系等实体与关联；在会议领域，则严格覆盖了组织架构、员工属性、工位位置、会议室设备及多维排期表。
如何保证一个庞大且完全由大模型合成的业务数据库不出现逻辑漏洞？E-Bench 提出了一套图引导的数据库填充机制（Graph-Guided Database Filling）。该方法首先解析关系型数据表之间的外键约束，将其抽象为一个有向无环的表依赖图（Table-Dependency Graph）。随后，系统沿着图的拓扑排序顺序，借助强大的前沿大模型分批次、自底向上地填充实体数据。
在生成下游子表数据时，模型必须显式引用上游主表中已经生成的有效主键与字段约束，并在每个批次插入后执行确定性的代码校验和自动修复。这种自顶向下的严格依赖控制，彻底消除了关系数据库中常见的“孤儿记录（Orphan Records）”——即子表引用的外键在主表中根本不存在的情况。最终，E-Bench 构建出的并非脆弱的测试桩（Stubs），而是一套具有高阶实体关联、跨表一致性且支持高并发读写的可复用产品级环境。
生成器与求解器的非对称博弈
有了高度逼真且结构健壮的数字环境之后，评测任务又该如何自动演进和生成？E-Bench 设计了一套基于生成器-求解器非对称（Generator-Solver Asymmetry）的任务合成流水线。
在这一流水线中，充当任务设计者的“生成器（Generator）”拥有特权，能够直接执行底层的 SQL 查询和代码分析。它深入虚拟产品数据库，探查数据分布、关联关系与业务边界，模拟真实产品使用循环：审查数据 $\rightarrow$ 确定业务操作目标 $\rightarrow$ 触发状态修改 $\rightarrow$ 提炼用户自然语言意图。每当生成器成功完成一次操作，系统便会精确捕获底层数据库在操作前后的差异（Database-State Diff），并将其保存为该任务的绝对真值（Ground Truth）。
被评测的模型作为“求解器（Solver）”，则处于完全非对称的信息劣势地位：
-
信息差（Information Gap）：求解器绝对没有直接的 SQL 查询权限，也看不到数据库的全局结构视图。面对用户模糊或隐含约束的指令，它必须自行思考需要检索哪些中间数据，通过业务层面的 Model Context Protocol (MCP) 接口逐级发掘隐藏状态。
-
工具差（Tool Gap）：在基准 E-Bench 设定下，求解器无法运行自定义代码，必须依赖自身的大模型推理，一步步手动规划、发起串行或并行的 MCP 工具调用，并在多轮交互中自行聚合上下文。
评测的判卷过程完全摒弃了不可控的 LLM Judge，而是直接将求解器经过长程交互后对数据库造成的最终变更，与预先记录的底层数据库状态差异（DB Diff）进行比特级的确定性比对。只有当模型新增、更新、删除的行级记录完全匹配预期时，任务才算通过。全评测集涵盖的任务诱发的状态变更极为显著：平均每道任务需要精确触碰 24.9 行底层记录变更，部分极复杂任务甚至涉及高达 221 行的批量状态流转。
引入代码执行：E-Bench-Code 究竟弥补了什么？
既然纯手工多步调用对模型而言极度繁琐，如果赋予模型“代码执行”的权限，情况会发生什么变化？为此，研究团队构建了扩展测试设定 E-Bench-Code。
在 E-Bench-Code 模式下，求解器获得了一个额外的 exec_code 工具，允许其编写 Python 代码并调用各个业务域预先封装好的 MCP 内部函数。模型可以通过编写循环、分页、列表推导和集合运算，在单次代码块执行中自动化完成原本需要多轮交互的数据筛选和汇总。需要强调的是，E-Bench-Code 仅仅消除了“工具差”，并没有打破“信息差”——代码环境中依然禁用了直接的 SQL 访问，模型依旧必须基于业务 API 自行摸索环境。
通过将这两种设定进行对照，模型在面对长程任务时的底层能力短板被清晰地解构开来。实验数据表明，代码执行带来了立竿见影的效率跃升：在全部 11 款前沿模型的平均测试中，单任务的 MCP 工具调用量从 60.42 次断崖式下跌至 15.86 次，降幅达 73.8%；交互交互轮次（Turns）从 14.87 轮缩减至 9.87 轮，降幅达 33.6%。
深入的能力维度细分分析（Per-Capability Analysis）进一步揭示了代码执行的收益边界。代码化接口收益最大的能力类型，是多条件过滤（Multi-Condition Filtering）、全量数据拉取（Full-Data Acquisition）以及聚合计算（Aggregation and Computation）。这些任务依赖机械式的长列表循环和统计，模型直接在自然语言上下文中跟踪极易出错，而 Python 脚本能够以确定性的算法完美替代这部分机械劳动。
然而，在涉及跨步骤依赖（Cross-Step Dependency）和精确边界判断（Precise Boundary Judgment）的任务上，代码执行带来的提升幅度却大幅收窄。这意味着，代码解释器可以出色地承担“计算搬运工”的角色，但在“决定检索什么数据、何时终止检索、如何裁决复杂业务分支”这些涉及高阶认知规划的决策层面，代码本身无法提供任何智力捷径，瓶颈依然牢牢卡在底座模型的推理与规划本体之上。
评测结果：可靠性断层与模型格局
研究团队对全球范围内的 11 款顶尖模型进行了严密评测，涵盖 GPT-5.5、Opus-4.8、Grok-4.5、Kimi-K3、Qwen-3.7-Max、GLM-5.2、Hy3 等。所有模型均在支持的最大思维链（Thinking Effort）配置下运行，并采用统一的 Agent Harness 进行驱动。测试记录了单次运行平均成功率（Avg@3）、三次至少成功一次概率（Pass@3），以及最具工业价值的指标——连续三次测试均成功完成的严格可靠率（Pass3）。
1. 连续可靠性（Pass3）全面遇冷
在基础 E-Bench 环境中，Kimi-K3 取得了 73.79% 的最高 Avg@3，紧随其后的是 GPT-5.5（71.21%）、Opus-4.8（68.78%）与 Grok-4.5（66.87%）。这四款模型组成了稳固的第一梯队，而其余 7 款模型的 Avg@3 均未能越过 53% 的门槛。
更为严峻的问题在于从偶尔成功到稳定交付的可靠性断崖。在许多企业级场景中，偶发性成功毫无落地意义，因为一次失控的状态修改就可能导致底层业务数据损坏。实验显示，所有模型在严格可靠性指标 $\text{Pass}^3$ 上均遭遇了腰斩：
-
Kimi-K3 的 Pass@3 高达 87.62%，但其 $\text{Pass}^3$ 骤降至 58.82%；
-
GPT-5.5 的 Pass@3 达到 82.97%，其 $\text{Pass}^3$ 仅有 57.59%；
-
至于第二梯队及之后的模型，$\text{Pass}^3$ 表现几乎全线失守，多款模型在连续三次测试中的全通率甚至跌至 20% 以下。
这一断层清楚地表明，当前大模型在处理含状态长程业务时，内部推理规划仍然存在显著的随机扰动与不可控性。
2. 代码加持下的分化与局限
在引入 exec_code 的 E-Bench-Code 模式下，几乎所有模型都获得了不同程度的性能增益。擅长代码编写的 Opus-4.8 展现出极强的弹性，Avg@3 从 68.78% 大幅提升至 81.11%，反超 Kimi-K3 跃居榜首；Gemini-3.5-Flash 在代码赋能下的表现同样抢眼，Avg@3 实现了 46.7% 的相对提升；DeepSeek-V4-Pro 的相对增益也达到了 38.32%。
但是，代码并非万灵药。哪怕是在代码赋能的理想状态下，全场 $\text{Pass}^3$ 的天花板依旧没能突破 70%（Opus-4.8 仅为 69.97%），排名靠后的模型更是徘徊在 20% 左右。这再次印证了此前的推论：阻碍长程任务交付的从来不仅仅是接口调用繁琐度，而是模型对业务状态的连续理解与审慎决断。
3. 领域的特异性与泛化死角
实验数据还打破了“最强模型在所有业务领域通吃”的神话。各家模型在不同产品形态中的表现呈现出剧烈的领域敏感性。例如，Grok-4.5 在涉及流媒体操作的 QQ 音乐场景中力拔头筹，但在规则交织、状态繁杂的《王者荣耀》领域却滑落至中游；而在腾讯会议涉及多方日程冲突消解的场景中，各家模型的失误率普遍出现飙升。这一现象说明，仅凭通用的代码微调或简单的函数调用对齐，无法直接赋予模型在垂直业务场景下稳健处理状态依赖的能力。
从单步匹配迈向深水区规划
E-Bench 带来的核心启示在于，工业级 Agent 技术的演进重心必须从“如何调用工具”迁移到“如何管理环境状态”。单纯提高单次调用的结构合法率，在真实多步业务面前早已不再是核心矛盾。
长期以来，社区依赖基于大模型裁判（LLM Judge）的评估体系，掩盖了许多模型在逻辑细节上的暗病；而采用不可篡改的底层数据库状态差异（DB Diff）作为判卷标尺，则以极其客观的物理事实证明，当今最领先的前沿模型在应对连贯的现实任务时，稳定性依然远未成熟。
无论是通过强化学习（RL）将长程状态流转纳入奖励建模，还是赋予 Agent 自主设计代码管线以收敛交互复杂度的能力，E-Bench 提出的这套完全合成、环境与任务解耦、且能够自洽演进的数据构建流水线，都为长程多步工具使用的系统性训练和精准测量铺平了道路。在 Agent 真正走进各行各业去“替人干脏活累活”之前，如何将其连续任务成功率从不足 60% 稳步提升至工业生产所需的 99.9%，将是整个行业在未来相当长一段时间内需要合力攻坚的硬核命题。