文章目录腾讯混元E-Bench技术解析323项真实产品任务如何测出智能体多步工具调用可靠性一、引言二、评测范式演进从答题、调函数到改变系统状态2.1 为什么传统基准不够用了2.2 E-Bench 的关键选择三、核心架构环境合成与任务合成彻底分离3.1 全流程架构3.2 图引导数据库填充3.3 生成者与求解者为什么必须不对称3.4 数据库差分不看过程像不像只看结果准不准四、数据规模三个产品原型如何组成323道大考4.1 六类能力不是互斥标签五、评测指标一次成功为何远远不够六、实验结果前沿模型仍卡在可靠性6.1 基础版与代码版完整结果6.2 第一平均成功率掩盖了重复执行的不稳定6.3 第二代码执行普遍有效但主要替代机械劳动6.4 第三代码同时降低工具调用和交互成本6.5 第四领域排名并不稳定七、横向对比E-Bench在智能体基准中处于什么位置八、工程实践如何把E-Bench方法迁移到企业Agent评测8.1 第一步把业务系统变成可重置测试环境8.2 第二步从真实失败模式设计任务8.3 第三步把“正确”写成状态契约8.4 第四步同时测能力、可靠性和成本九、局限与风险不要把合成高分直接等同于生产可用9.1 合成环境仍然缺少线上噪声9.2 三个领域不能代表所有Agent任务9.3 精确差分严格也可能过于严格9.4 任务生成质量仍受模型与规则影响9.5 代码执行扩大了能力也扩大了攻击面十、总结腾讯混元E-Bench技术解析323项真实产品任务如何测出智能体多步工具调用可靠性一、引言亲爱的朋友们创作不容易若对您有帮助的话请点赞收藏加关注哦您的关注是我持续创作的动力谢谢大家有问题请私信或联系邮箱jasonai.fngmail.com大模型会不会调用一个 API已经不是智能体评测里最难的问题。真正困难的是面对一句含有多重条件的自然语言请求智能体能否先找全隐藏信息跨多张表计算和筛选再连续调用几十次工具最后只修改应该修改的状态而且三次运行都不出错。2026 年 7 月 26 日腾讯混元团队联合清华大学智能产业研究院AIR与东南大学计算机科学与工程学院提交 E-Bench 论文8 月 3 日腾讯混元正式发布项目解读。E-Bench 以《王者荣耀》、QQ 音乐、腾讯会议三类真实产品为原型构造了323 个会改变后端状态的任务但不连接线上服务也不使用真实用户数据而是在完全合成、可重置的数据库环境中测试智能体。它最值得关注的不是又做了一张模型排行榜而是把评测问题从“模型说得对不对”推进到“智能体做完以后系统状态到底对不对”。实验结果也相当直接基础 E-Bench 中表现最好的模型 Kimi-K3 的 Avg3 为 73.79%但连续三次全部成功的 Pass³ 只有 58.82%即使增加代码执行能力最佳 Pass³ 仍低于 70%。会做一次与能够可靠地反复做对是两种不同能力。二、评测范式演进从答题、调函数到改变系统状态2.1 为什么传统基准不够用了大模型评测最早主要检查知识、推理与代码答案输入和输出都是静态文本。Agent 出现后BFCL、Gorilla、ToolLLM 等基准开始测试工具选择、参数生成和函数调用格式。再往后AppWorld、τ-bench、ToolSandbox 与一批 MCP 基准把模型放进可交互环境开始考察多轮操作。问题在于真实软件任务通常同时具有四个特征信息没有一次性给全、工具接口各不相同、后续动作依赖前序结果、操作会产生不可忽略的状态变化。只检查某个函数调用是否与参考轨迹一致可能误判一条不同但有效的路径只让 LLM 裁判阅读最终回复又可能出现“嘴上完成实际没改”的假成功。评测阶段主要问题常见判定方式难以覆盖的能力静态问答答案是否正确标准答案、规则或 LLM 裁判环境探索与真实操作单步函数调用工具与参数是否选对调用结构匹配长链依赖、隐藏信息轨迹匹配是否走过参考步骤工具序列相似度多条等价解法状态型 Agent最终系统是否被正确修改环境状态或任务检查器环境构建与判定成本较高E-Bench多步工具调用能否精确、稳定地完成数据库字段级差分仍不等同于开放世界线上系统2.2 E-Bench 的关键选择E-Bench 没有直接复制线上产品也没有为每一道题手工搭一个孤立沙盒。研究团队选择先生成完整、可复用的产品数据库再从同一个环境中自动生成许多任务。这样既保留了产品世界里的实体关系和历史状态又能随时恢复环境、扩充任务和进行重复实验。这条路线是在两组矛盾之间取平衡真实服务更接近生产但难以重置、成本和风险高简单模拟器容易控制却常常只包含完成某一道题所需的少量数据。E-Bench 的回答是产品是原型数据和任务是合成的最终结果由真实数据库状态判定。三、核心架构环境合成与任务合成彻底分离3.1 全流程架构产品关系模式 表结构 · 主外键 · 字段约束 · 业务语义 │ ▼ 图引导数据库填充 按依赖拓扑生成记录 → 约束校验 → 确定性修复 │ ▼ 可复用的合成产品环境 王者荣耀 · QQ音乐 · 腾讯会议 │ ├──────── 特权生成者SQL 代码 完整数据库视图 │ │ │ ▼ │ 探索数据 → 选目标 → 修改状态 → 反写自然语言任务 │ │ │ └── 保存标准数据库差分与能力标签 │ └──────── 被测求解者仅有领域 MCP 工具 │ ▼ 查信息 → 计算/筛选 → 多步调用 → 修改状态 │ ▼ 实际数据库差分 标准数据库差分这套架构包含三个重要分离数据库生成与任务生成分离、任务生成者与被测智能体权限分离、执行轨迹与最终判定分离。它们分别解决环境复用、任务难度和多路径判分问题。3.2 图引导数据库填充关系数据库里的记录不能随意拼接。歌曲必须引用已存在的专辑专辑必须属于已存在的歌手会议参与人、员工日程和会议室预订也必须相互一致。E-Bench 先将表之间的外键关系转成依赖图再按拓扑顺序生成数据先生成歌手、部门、会议室等根实体然后生成依赖这些实体的下游记录。生成模型不会一次性自由编造整库而是在表结构、键约束、领域上下文和已有记录限制下通过工具查询候选对象并插入数据。数据库负责在写入时检查主键唯一性与外键有效性随后再由确定性脚本修复时间顺序、汇总计数和状态字段等语义冲突。机制解决的问题工程价值依赖图拓扑生成下游记录引用不存在的实体从结构上避免孤儿记录受约束的上下文生成模型虚构 ID 或生成无关内容让合成受 Schema 和现有数据限制数据库约束主键重复、外键失效在插入时立即拒绝结构错误生成后校验与修复时间、计数、状态语义不一致提高整个产品世界的可用性领域 MCP 工具层被测模型直接读取数据库用产品级 CRUD 接口制造真实信息差3.3 生成者与求解者为什么必须不对称任务生成者拥有 SQL、代码执行和完整数据库视图。它先查看现有数据决定一个满足复杂条件的目标集合真实执行修改再根据结果写出自然语言请求并保存标准数据库差分。被测智能体则看不到 SQL 和底层表只能调用领域 MCP 工具逐步找回信息。这种非对称故意制造两道缺口缺口生成者拥有求解者必须完成信息缺口完整数据库和 SQL 查询通过搜索、分页、详情查询找全隐藏状态工具缺口SQL 与通用代码可直接处理集合组合多个粒度较细的产品工具完成同一操作例如“收藏所有播放不少于 5 次、但尚未收藏的歌曲”生成者可以用查询直接得到集合求解者要先获得完整播放历史与收藏状态再筛出目标最后对每首歌调用收藏工具。论文案例中目标共有 38 首歌。Hy3 在一次并行轮次中发出 38 个收藏调用并成功完成Grok-4.5 分批串行处理虽然也成功但总 Token 为 225.5K约为 Hy3 的 1.6 倍。3.4 数据库差分不看过程像不像只看结果准不准每次测试都从一份全新的隔离数据库副本开始。执行前后分别获得数据库状态计算真实差分再与任务生成阶段保存的标准差分精确比较。插入、更新和删除都在判定范围内多改一个字段、漏删一条记录或修改方向错误都会失败而且不提供部分分。defverify_task(initial_db,final_db,expected_diff):actual_diffdiff_database(initial_db,final_db)returnnormalize(actual_diff)normalize(expected_diff)这段伪代码表达了 E-Bench 的判分本质。它不要求智能体复刻生成者的 SQL 或工具轨迹因此允许“先查 A 再查 B”和“并行查询 A、B”等不同路径但对最终副作用极其严格。论文中的《王者荣耀》案例里Hy3 通过了 8 项检查中的 7 项却因好友关系方向字段多写了一次错误状态而整题失败。这正是生产系统需要关心的错误目标选对并不意味着写操作安全。四、数据规模三个产品原型如何组成323道大考E-Bench 的三个领域并不是换皮问答集而是三套具有不同关系密度、工具粒度和操作风险的状态环境。整个基准包含 41 张表、345 个字段、69 条外键关系、76,317 行合成数据和 1,219 个主要实体。统计项王者荣耀QQ 音乐腾讯会议总计数据表16121341字段16872105345外键关系29162469数据行18,64628,32129,35076,317主要实体170 位用户54 位用户995 名员工1,219任务数110104109323每题标准差分3255807221-求解工具数332725-E-Bench-Code 工具数342826-腾讯会议任务平均产生 48.5 项数据库变化中位数为 35最高达到 221 项适合测试跨员工、日程、会议室、参会人和群组的联动操作。《王者荣耀》涉及带方向的好友关系、对局统计与亲密关系边界判断更容易出错QQ 音乐则包含大量检索、聚合与批量收藏适合观察并行工具调用效率。4.1 六类能力不是互斥标签一项任务可以同时要求多种能力。例如先读取完整好友列表按最近 30 天共同对局和胜率筛选选出亲密度最高者再设置星标和亲密关系就同时涉及完整数据获取、多条件过滤、聚合计算、跨步骤依赖、边界判断和跨实体联动。能力标签任务要求任务数完整数据获取行动前找全隐藏状态避免根据局部结果决策197多条件过滤同时满足多个属性、关系或状态条件72聚合与计算计数、排序、汇总或计算派生结果159跨步骤依赖后一步依赖前一步查询或操作结果207精确边界判断处理阈值、容量、排名、时间和可用性144跨实体联动在多种关联实体之间传播操作106这一能力划分的价值在于团队不必只看总分。若内部 Agent 在“完整数据获取”上表现差应先检查分页、停止条件和上下文管理若在“精确边界判断”上失败则要检查时区、开闭区间、排序稳定性和业务约束。五、评测指标一次成功为何远远不够每个模型在每项任务上独立运行三次每次使用干净数据库。E-Bench 用三种指标把“平均能力”“偶尔能成”和“稳定做对”区分开来。指标计算方式回答的问题Avg3所有任务、所有三次试验的平均成功率随机执行一次通常有多大概率成功Pass3三次中至少成功一次即算该任务通过多给几次机会模型是否有可能做成Pass³三次必须全部成功才算通过模型能否稳定复现正确状态变化如果 Pass3 很高、Pass³ 很低说明模型并非完全不会而是计划、检索范围、工具参数或调用顺序不稳定。对聊天机器人而言重试可能只改变措辞对会删除好友、修改日程或创建群组的 Agent 而言一次随机失败就可能留下真实副作用。因此Pass³ 比“最佳一次演示”更接近上线门槛。六、实验结果前沿模型仍卡在可靠性6.1 基础版与代码版完整结果E-Bench 测试了 11 个前沿模型。基础版只提供领域 MCP 工具E-Bench-Code 额外提供exec_code允许智能体用代码组织循环、过滤、聚合和批量调用。下表按基础版 Avg3 排序。模型E-Bench Avg3E-Bench Pass3E-Bench Pass³Code Avg3Code Pass³Kimi-K373.79%87.62%58.82%77.61%65.80%GPT-5.572.03%82.97%57.59%77.19%66.90%Opus-4.868.78%84.33%50.81%81.11%68.66%Grok-4.566.10%80.50%52.32%69.24%55.75%GLM-5.252.32%71.52%30.96%60.99%42.25%Qwen-3.7-Max50.88%70.59%30.34%61.92%44.01%Hy350.15%74.30%26.63%64.40%44.01%Seed-2.1-Pro47.94%65.33%28.79%53.04%30.99%Gemini-3.5-Flash42.62%64.71%21.98%62.54%40.49%MiniMax-M341.07%62.85%20.12%46.85%21.13%DeepSeek-V4-Pro34.47%53.56%17.34%47.68%25.35%这里有四个值得单独讨论的结论。6.2 第一平均成功率掩盖了重复执行的不稳定基础版 11 个模型的 Avg3 平均值只有 54.56%。即使排名第一的 Kimi-K3Pass3 达到 87.62%Pass³ 却下降到 58.82%两者相差 28.8 个百分点。这意味着相当一部分任务属于“试三次总能撞对一次但不能连续三次都做对”。对于生产 Agent这类波动可能来自分页没读完、筛选集合变化、并行结果处理遗漏、工具调用失败后恢复不一致或者多写了一个不该写的字段。E-Bench 不给部分分看似严厉却准确揭示了写操作系统的风险。6.3 第二代码执行普遍有效但主要替代机械劳动加入exec_code后所有模型的 Avg3 都有提升。Opus-4.8 从 68.78% 上升到 81.11%超过 Kimi-K3 和 GPT-5.5Gemini-3.5-Flash 从 42.62% 提升到 62.54%相对增幅约 46.7%。能力基础 Avg3Code Avg3绝对提升多条件过滤51.94%62.55%10.61完整数据获取53.55%63.65%10.11聚合与计算52.85%62.30%9.45跨实体联动60.08%68.88%8.80跨步骤依赖54.11%62.79%8.68精确边界判断57.39%64.94%7.55提升最大的前三类都适合用循环、集合运算与精确过滤处理提升较小的边界判断和跨步骤依赖更依赖目标选择与业务推理。结论不是“给 Agent 一个 Python 就解决了”而是代码可以压缩机械调用不能替代正确决策。6.4 第三代码同时降低工具调用和交互成本论文统计显示加入代码执行后11 个模型平均每题 MCP 调用数从 60.42 降到 15.86下降 73.8%平均行动轮次从 14.87 降到 9.87下降 33.6%。一个代码块可以在内部遍历集合并多次调用领域函数避免模型在每一轮重新读取长上下文。这也解释了为什么“调用越少”不能脱离工具形态解释。基础版中调用少有时表示信息没查全就贸然行动代码版中顶层调用少可能意味着模型把大量确定性工作压进了程序。评测 Agent 效率时必须同时记录成功率、领域操作总量、模型轮次、Token、延迟与费用。6.5 第四领域排名并不稳定三个领域的平均难度差异明显基础版《王者荣耀》、腾讯会议、QQ 音乐 Avg3 分别为 43.64%、58.87% 和 61.39%代码版分别提升到 52.36%、67.78% 和 71.94%。《王者荣耀》的方向关系和精确更新更难QQ 音乐的大批量检索与收藏更容易由代码加速。这说明单一领域榜单容易把“模型恰好擅长某种工具形态”误判为通用 Agent 能力。企业自建评测集时也不能只选一条顺利的业务流程至少要覆盖检索密集、计算密集、关系联动、边界敏感与高风险写入等不同任务。七、横向对比E-Bench在智能体基准中处于什么位置E-Bench 不是第一个工具调用或状态环境基准它的差异在于把可复用的合成产品世界、自动任务生成和轨迹无关的数据库判分放在了一起。基准类型/代表项目环境形态主要考察判定方式与 E-Bench 的关键差异BFCL函数集合与对话工具选择、参数、并行与多轮调用调用结构和预期结果更擅长测函数调用基本功状态世界较弱τ-bench受控行业环境用户与工具交互、规则遵循、任务完成环境任务检查真实工作流强环境与任务构建人工成本较高AppWorld多应用模拟世界跨应用长链任务状态与任务检查场景丰富但不少环境状态围绕具体任务组织MCP-Atlas / MCP-Universe 等真实或在线 MCP 服务真实工具发现与调用任务或服务结果现实性高但重置、版本漂移和重复写入更难控制MCPEval从 MCP 规范自动生成MCP 工具使用与验证者轨迹对齐自动化程度高但轨迹对齐可能偏爱某条解法E-Bench完全合成、数据库驱动的产品世界隐藏信息获取、多步并行工具、精确状态修改数据库字段级差分可控、可扩展、路径无关但领域和现实噪声仍有限从纵向演进看E-Bench 继承了函数调用基准对工具格式的要求也吸收了状态型基准对闭环执行的关注它新增的工程贡献是把完整环境合成和任务合成拆开让一套一致的数据库可以持续产生新任务。从横向位置看它更像一个“Agent 后端集成测试场”而不是通用智力考试。团队可以用它观察模型如何处理分页、过滤、关系方向、并行工具调用和精确副作用却不能据此断言某模型在浏览器操作、桌面 GUI、安全攻击、开放网络搜索等能力上也同样领先。八、工程实践如何把E-Bench方法迁移到企业Agent评测E-Bench 最适合借鉴的不是三套腾讯产品数据而是其评测方法。企业可以在不暴露生产数据的前提下为订单、工单、CRM、日程或云资源 Agent 构造一套状态型回归测试。8.1 第一步把业务系统变成可重置测试环境选择一个边界清晰的业务域抽取表结构、实体关系、约束和产品级工具。数据应完全合成或严格脱敏并保持主外键、时间、权限和状态机一致。每次任务从数据库快照或事务模板恢复保证测试之间互不影响。8.2 第二步从真实失败模式设计任务任务不应只是把一个 API 包装成自然语言而应包含真实工作中常见的难点。失败模式任务设计方法应记录的诊断信号分页遗漏目标分散在多个分页末页也放置有效对象查询覆盖率、停止位置条件边界错误加入等于阈值、跨时区、并列排名样本命中集合与边界解释关系方向错误使用双向、主从或邀请关系修改字段和关系方向误操作放置名称相近但 ID 不同的实体多余数据库差分长链中断后续创建依赖前序返回 ID失败步骤、重试与补偿并行效率差要求处理几十个独立对象每轮调用数、Token 与耗时8.3 第三步把“正确”写成状态契约为每项任务保存允许的插入、更新和删除集合并明确禁止的额外变化。若业务允许多种等价终态应将标准答案从单个精确 Diff 扩展为约束集合例如“会议创建成功且所有目标参会人加入会议室可为 A 或 B”不要强迫 Agent 复刻唯一答案。{must_insert:[meeting:generated_id],must_update:[room:A:reservedtrue],must_not_change:[employee.salary,room:B],invariants:[participant_count room.capacity]}8.4 第四步同时测能力、可靠性和成本至少独立运行三次报告平均成功率、至少成功一次和全部成功同时保留工具轨迹、数据库差分、调用轮次、Token、延迟、费用及失败标签。高风险写操作还应记录是否在执行前复核目标集合、是否支持幂等、失败后能否回滚。离线评测通过 │ ▼ 影子模式只计算计划不执行写入 │ ▼ 低风险写入小流量 审批 完整审计 │ ▼ 扩大范围按任务类型设置权限和预算 │ └── 任一回归指标跌破阈值 → 自动回退E-Bench 的 Pass³ 仍然只是三次重复试验。企业上线门槛通常应更严格对删除、支付、权限和外部消息等操作除了高重复成功率还要有参数校验、预览确认、事务、幂等键、补偿动作和人工接管。九、局限与风险不要把合成高分直接等同于生产可用9.1 合成环境仍然缺少线上噪声E-Bench 的可控性来自完全合成。它避开了真实服务中的网络抖动、API 版本变化、权限过期、限流、脏数据、并发写入和用户中途改需求。模型在 E-Bench 中取得高分证明其在这类结构化状态任务中较强不等于可以无人监督地接管真实账号。9.2 三个领域不能代表所有Agent任务《王者荣耀》、QQ 音乐和腾讯会议覆盖社交关系、内容收藏与企业协同但不包含浏览器视觉定位、软件工程、开放网络检索、支付、安全攻防和物理世界控制。排行榜适合比较指定环境下的多步工具能力不适合推导“最强通用智能体”。9.3 精确差分严格也可能过于严格字段级精确匹配能有效发现多写、少写和方向错误但真实业务可能存在多个合法终态。若会议室 A 与 B 都满足需求单一标准 Diff 可能把另一条正确路径判错。企业复用时应结合数据库 Diff、业务不变量和允许结果集合而不是机械追求字节级一致。9.4 任务生成质量仍受模型与规则影响生成者拥有更强权限并不保证每道任务都自然、重要或无歧义。虽然数据库约束和确定性修复能保证结构一致仍需要人工抽检任务措辞、业务价值、难度分布和能力标签。公开任务还可能被模型开发者针对性优化因此长期评测应保留未公开测试集并持续生成新变体。9.5 代码执行扩大了能力也扩大了攻击面E-Bench-Code 证明代码能减少调用和 Token却不等于生产环境应向 Agent 开放任意代码执行。代码沙盒需要限制网络、文件系统、运行时间、依赖、密钥和可调用函数高风险领域工具仍需独立授权。否则效率提升可能以更大的安全边界为代价。十、总结维度核心要点研究定位E-Bench 测试智能体在状态环境中的多步工具调用而非静态问答或单次函数格式环境设计以三类腾讯产品为原型构造完全合成、可重置、数据库驱动的产品世界任务设计生成者拥有 SQL 与代码求解者只有 MCP 工具形成信息缺口与工具缺口判定机制用最终数据库差分精确判分不依赖 LLM 裁判也不限定唯一执行轨迹数据规模323 项任务、41 张表、76,317 行数据、1,219 个主要实体核心发现基础版最佳 Avg3 为 73.79%最佳 Pass³ 仅 58.82%可靠性仍是主要短板代码价值提升全部模型表现并显著减少顶层工具调用但更擅长替代计算而非推理落地边界合成高分不能直接代表线上可用仍需权限、事务、幂等、审批与持续回归E-Bench 代表了智能体评测的一次重要转向从检查模型是否生成了合理的调用转向检查它是否对真实状态做出了完整、精确且可重复的改变。这一转向会让很多漂亮演示失去光环却更接近 Agent 进入生产系统前必须面对的事实。它给模型团队的信号也很清楚。下一阶段的竞争不只是更长思维链或更高单次成功率而是完整信息获取、并行工具调度、精确副作用控制、失败恢复与成本之间的综合平衡。一个能偶尔完成复杂任务的 Agent 适合演示一个连续多次都只改对该改的状态、并且知道何时停手的 Agent才接近真正可用。参考资料E-Bench: Benchmarking Multi-Step Tool-Use Agents in Real-World Product Scenarios — arXivE-Bench 论文 HTML 全文 — arXivBerkeley Function Calling Leaderboard — Gorillaτ-bench: A Benchmark for Tool-Agent-User Interaction in Real-World Domains — arXivAppWorld: A Controllable World of Apps and People for Benchmarking Interactive Coding Agents — arXiv注本文数据均来自 E-Bench 论文 v1 与腾讯混元 2026 年 8 月 3 日公开解读统计与模型排名对应论文当时的实验设置模型版本、价格和榜单可能随时间变化。 【腾讯混元E-Bench技术解析】323项真实产品任务如何测出智能体多步工具调用可靠性
文章目录腾讯混元E-Bench技术解析323项真实产品任务如何测出智能体多步工具调用可靠性一、引言二、评测范式演进从答题、调函数到改变系统状态2.1 为什么传统基准不够用了2.2 E-Bench 的关键选择三、核心架构环境合成与任务合成彻底分离3.1 全流程架构3.2 图引导数据库填充3.3 生成者与求解者为什么必须不对称3.4 数据库差分不看过程像不像只看结果准不准四、数据规模三个产品原型如何组成323道大考4.1 六类能力不是互斥标签五、评测指标一次成功为何远远不够六、实验结果前沿模型仍卡在可靠性6.1 基础版与代码版完整结果6.2 第一平均成功率掩盖了重复执行的不稳定6.3 第二代码执行普遍有效但主要替代机械劳动6.4 第三代码同时降低工具调用和交互成本6.5 第四领域排名并不稳定七、横向对比E-Bench在智能体基准中处于什么位置八、工程实践如何把E-Bench方法迁移到企业Agent评测8.1 第一步把业务系统变成可重置测试环境8.2 第二步从真实失败模式设计任务8.3 第三步把“正确”写成状态契约8.4 第四步同时测能力、可靠性和成本九、局限与风险不要把合成高分直接等同于生产可用9.1 合成环境仍然缺少线上噪声9.2 三个领域不能代表所有Agent任务9.3 精确差分严格也可能过于严格9.4 任务生成质量仍受模型与规则影响9.5 代码执行扩大了能力也扩大了攻击面十、总结腾讯混元E-Bench技术解析323项真实产品任务如何测出智能体多步工具调用可靠性一、引言亲爱的朋友们创作不容易若对您有帮助的话请点赞收藏加关注哦您的关注是我持续创作的动力谢谢大家有问题请私信或联系邮箱jasonai.fngmail.com大模型会不会调用一个 API已经不是智能体评测里最难的问题。真正困难的是面对一句含有多重条件的自然语言请求智能体能否先找全隐藏信息跨多张表计算和筛选再连续调用几十次工具最后只修改应该修改的状态而且三次运行都不出错。2026 年 7 月 26 日腾讯混元团队联合清华大学智能产业研究院AIR与东南大学计算机科学与工程学院提交 E-Bench 论文8 月 3 日腾讯混元正式发布项目解读。E-Bench 以《王者荣耀》、QQ 音乐、腾讯会议三类真实产品为原型构造了323 个会改变后端状态的任务但不连接线上服务也不使用真实用户数据而是在完全合成、可重置的数据库环境中测试智能体。它最值得关注的不是又做了一张模型排行榜而是把评测问题从“模型说得对不对”推进到“智能体做完以后系统状态到底对不对”。实验结果也相当直接基础 E-Bench 中表现最好的模型 Kimi-K3 的 Avg3 为 73.79%但连续三次全部成功的 Pass³ 只有 58.82%即使增加代码执行能力最佳 Pass³ 仍低于 70%。会做一次与能够可靠地反复做对是两种不同能力。二、评测范式演进从答题、调函数到改变系统状态2.1 为什么传统基准不够用了大模型评测最早主要检查知识、推理与代码答案输入和输出都是静态文本。Agent 出现后BFCL、Gorilla、ToolLLM 等基准开始测试工具选择、参数生成和函数调用格式。再往后AppWorld、τ-bench、ToolSandbox 与一批 MCP 基准把模型放进可交互环境开始考察多轮操作。问题在于真实软件任务通常同时具有四个特征信息没有一次性给全、工具接口各不相同、后续动作依赖前序结果、操作会产生不可忽略的状态变化。只检查某个函数调用是否与参考轨迹一致可能误判一条不同但有效的路径只让 LLM 裁判阅读最终回复又可能出现“嘴上完成实际没改”的假成功。评测阶段主要问题常见判定方式难以覆盖的能力静态问答答案是否正确标准答案、规则或 LLM 裁判环境探索与真实操作单步函数调用工具与参数是否选对调用结构匹配长链依赖、隐藏信息轨迹匹配是否走过参考步骤工具序列相似度多条等价解法状态型 Agent最终系统是否被正确修改环境状态或任务检查器环境构建与判定成本较高E-Bench多步工具调用能否精确、稳定地完成数据库字段级差分仍不等同于开放世界线上系统2.2 E-Bench 的关键选择E-Bench 没有直接复制线上产品也没有为每一道题手工搭一个孤立沙盒。研究团队选择先生成完整、可复用的产品数据库再从同一个环境中自动生成许多任务。这样既保留了产品世界里的实体关系和历史状态又能随时恢复环境、扩充任务和进行重复实验。这条路线是在两组矛盾之间取平衡真实服务更接近生产但难以重置、成本和风险高简单模拟器容易控制却常常只包含完成某一道题所需的少量数据。E-Bench 的回答是产品是原型数据和任务是合成的最终结果由真实数据库状态判定。三、核心架构环境合成与任务合成彻底分离3.1 全流程架构产品关系模式 表结构 · 主外键 · 字段约束 · 业务语义 │ ▼ 图引导数据库填充 按依赖拓扑生成记录 → 约束校验 → 确定性修复 │ ▼ 可复用的合成产品环境 王者荣耀 · QQ音乐 · 腾讯会议 │ ├──────── 特权生成者SQL 代码 完整数据库视图 │ │ │ ▼ │ 探索数据 → 选目标 → 修改状态 → 反写自然语言任务 │ │ │ └── 保存标准数据库差分与能力标签 │ └──────── 被测求解者仅有领域 MCP 工具 │ ▼ 查信息 → 计算/筛选 → 多步调用 → 修改状态 │ ▼ 实际数据库差分 标准数据库差分这套架构包含三个重要分离数据库生成与任务生成分离、任务生成者与被测智能体权限分离、执行轨迹与最终判定分离。它们分别解决环境复用、任务难度和多路径判分问题。3.2 图引导数据库填充关系数据库里的记录不能随意拼接。歌曲必须引用已存在的专辑专辑必须属于已存在的歌手会议参与人、员工日程和会议室预订也必须相互一致。E-Bench 先将表之间的外键关系转成依赖图再按拓扑顺序生成数据先生成歌手、部门、会议室等根实体然后生成依赖这些实体的下游记录。生成模型不会一次性自由编造整库而是在表结构、键约束、领域上下文和已有记录限制下通过工具查询候选对象并插入数据。数据库负责在写入时检查主键唯一性与外键有效性随后再由确定性脚本修复时间顺序、汇总计数和状态字段等语义冲突。机制解决的问题工程价值依赖图拓扑生成下游记录引用不存在的实体从结构上避免孤儿记录受约束的上下文生成模型虚构 ID 或生成无关内容让合成受 Schema 和现有数据限制数据库约束主键重复、外键失效在插入时立即拒绝结构错误生成后校验与修复时间、计数、状态语义不一致提高整个产品世界的可用性领域 MCP 工具层被测模型直接读取数据库用产品级 CRUD 接口制造真实信息差3.3 生成者与求解者为什么必须不对称任务生成者拥有 SQL、代码执行和完整数据库视图。它先查看现有数据决定一个满足复杂条件的目标集合真实执行修改再根据结果写出自然语言请求并保存标准数据库差分。被测智能体则看不到 SQL 和底层表只能调用领域 MCP 工具逐步找回信息。这种非对称故意制造两道缺口缺口生成者拥有求解者必须完成信息缺口完整数据库和 SQL 查询通过搜索、分页、详情查询找全隐藏状态工具缺口SQL 与通用代码可直接处理集合组合多个粒度较细的产品工具完成同一操作例如“收藏所有播放不少于 5 次、但尚未收藏的歌曲”生成者可以用查询直接得到集合求解者要先获得完整播放历史与收藏状态再筛出目标最后对每首歌调用收藏工具。论文案例中目标共有 38 首歌。Hy3 在一次并行轮次中发出 38 个收藏调用并成功完成Grok-4.5 分批串行处理虽然也成功但总 Token 为 225.5K约为 Hy3 的 1.6 倍。3.4 数据库差分不看过程像不像只看结果准不准每次测试都从一份全新的隔离数据库副本开始。执行前后分别获得数据库状态计算真实差分再与任务生成阶段保存的标准差分精确比较。插入、更新和删除都在判定范围内多改一个字段、漏删一条记录或修改方向错误都会失败而且不提供部分分。defverify_task(initial_db,final_db,expected_diff):actual_diffdiff_database(initial_db,final_db)returnnormalize(actual_diff)normalize(expected_diff)这段伪代码表达了 E-Bench 的判分本质。它不要求智能体复刻生成者的 SQL 或工具轨迹因此允许“先查 A 再查 B”和“并行查询 A、B”等不同路径但对最终副作用极其严格。论文中的《王者荣耀》案例里Hy3 通过了 8 项检查中的 7 项却因好友关系方向字段多写了一次错误状态而整题失败。这正是生产系统需要关心的错误目标选对并不意味着写操作安全。四、数据规模三个产品原型如何组成323道大考E-Bench 的三个领域并不是换皮问答集而是三套具有不同关系密度、工具粒度和操作风险的状态环境。整个基准包含 41 张表、345 个字段、69 条外键关系、76,317 行合成数据和 1,219 个主要实体。统计项王者荣耀QQ 音乐腾讯会议总计数据表16121341字段16872105345外键关系29162469数据行18,64628,32129,35076,317主要实体170 位用户54 位用户995 名员工1,219任务数110104109323每题标准差分3255807221-求解工具数332725-E-Bench-Code 工具数342826-腾讯会议任务平均产生 48.5 项数据库变化中位数为 35最高达到 221 项适合测试跨员工、日程、会议室、参会人和群组的联动操作。《王者荣耀》涉及带方向的好友关系、对局统计与亲密关系边界判断更容易出错QQ 音乐则包含大量检索、聚合与批量收藏适合观察并行工具调用效率。4.1 六类能力不是互斥标签一项任务可以同时要求多种能力。例如先读取完整好友列表按最近 30 天共同对局和胜率筛选选出亲密度最高者再设置星标和亲密关系就同时涉及完整数据获取、多条件过滤、聚合计算、跨步骤依赖、边界判断和跨实体联动。能力标签任务要求任务数完整数据获取行动前找全隐藏状态避免根据局部结果决策197多条件过滤同时满足多个属性、关系或状态条件72聚合与计算计数、排序、汇总或计算派生结果159跨步骤依赖后一步依赖前一步查询或操作结果207精确边界判断处理阈值、容量、排名、时间和可用性144跨实体联动在多种关联实体之间传播操作106这一能力划分的价值在于团队不必只看总分。若内部 Agent 在“完整数据获取”上表现差应先检查分页、停止条件和上下文管理若在“精确边界判断”上失败则要检查时区、开闭区间、排序稳定性和业务约束。五、评测指标一次成功为何远远不够每个模型在每项任务上独立运行三次每次使用干净数据库。E-Bench 用三种指标把“平均能力”“偶尔能成”和“稳定做对”区分开来。指标计算方式回答的问题Avg3所有任务、所有三次试验的平均成功率随机执行一次通常有多大概率成功Pass3三次中至少成功一次即算该任务通过多给几次机会模型是否有可能做成Pass³三次必须全部成功才算通过模型能否稳定复现正确状态变化如果 Pass3 很高、Pass³ 很低说明模型并非完全不会而是计划、检索范围、工具参数或调用顺序不稳定。对聊天机器人而言重试可能只改变措辞对会删除好友、修改日程或创建群组的 Agent 而言一次随机失败就可能留下真实副作用。因此Pass³ 比“最佳一次演示”更接近上线门槛。六、实验结果前沿模型仍卡在可靠性6.1 基础版与代码版完整结果E-Bench 测试了 11 个前沿模型。基础版只提供领域 MCP 工具E-Bench-Code 额外提供exec_code允许智能体用代码组织循环、过滤、聚合和批量调用。下表按基础版 Avg3 排序。模型E-Bench Avg3E-Bench Pass3E-Bench Pass³Code Avg3Code Pass³Kimi-K373.79%87.62%58.82%77.61%65.80%GPT-5.572.03%82.97%57.59%77.19%66.90%Opus-4.868.78%84.33%50.81%81.11%68.66%Grok-4.566.10%80.50%52.32%69.24%55.75%GLM-5.252.32%71.52%30.96%60.99%42.25%Qwen-3.7-Max50.88%70.59%30.34%61.92%44.01%Hy350.15%74.30%26.63%64.40%44.01%Seed-2.1-Pro47.94%65.33%28.79%53.04%30.99%Gemini-3.5-Flash42.62%64.71%21.98%62.54%40.49%MiniMax-M341.07%62.85%20.12%46.85%21.13%DeepSeek-V4-Pro34.47%53.56%17.34%47.68%25.35%这里有四个值得单独讨论的结论。6.2 第一平均成功率掩盖了重复执行的不稳定基础版 11 个模型的 Avg3 平均值只有 54.56%。即使排名第一的 Kimi-K3Pass3 达到 87.62%Pass³ 却下降到 58.82%两者相差 28.8 个百分点。这意味着相当一部分任务属于“试三次总能撞对一次但不能连续三次都做对”。对于生产 Agent这类波动可能来自分页没读完、筛选集合变化、并行结果处理遗漏、工具调用失败后恢复不一致或者多写了一个不该写的字段。E-Bench 不给部分分看似严厉却准确揭示了写操作系统的风险。6.3 第二代码执行普遍有效但主要替代机械劳动加入exec_code后所有模型的 Avg3 都有提升。Opus-4.8 从 68.78% 上升到 81.11%超过 Kimi-K3 和 GPT-5.5Gemini-3.5-Flash 从 42.62% 提升到 62.54%相对增幅约 46.7%。能力基础 Avg3Code Avg3绝对提升多条件过滤51.94%62.55%10.61完整数据获取53.55%63.65%10.11聚合与计算52.85%62.30%9.45跨实体联动60.08%68.88%8.80跨步骤依赖54.11%62.79%8.68精确边界判断57.39%64.94%7.55提升最大的前三类都适合用循环、集合运算与精确过滤处理提升较小的边界判断和跨步骤依赖更依赖目标选择与业务推理。结论不是“给 Agent 一个 Python 就解决了”而是代码可以压缩机械调用不能替代正确决策。6.4 第三代码同时降低工具调用和交互成本论文统计显示加入代码执行后11 个模型平均每题 MCP 调用数从 60.42 降到 15.86下降 73.8%平均行动轮次从 14.87 降到 9.87下降 33.6%。一个代码块可以在内部遍历集合并多次调用领域函数避免模型在每一轮重新读取长上下文。这也解释了为什么“调用越少”不能脱离工具形态解释。基础版中调用少有时表示信息没查全就贸然行动代码版中顶层调用少可能意味着模型把大量确定性工作压进了程序。评测 Agent 效率时必须同时记录成功率、领域操作总量、模型轮次、Token、延迟与费用。6.5 第四领域排名并不稳定三个领域的平均难度差异明显基础版《王者荣耀》、腾讯会议、QQ 音乐 Avg3 分别为 43.64%、58.87% 和 61.39%代码版分别提升到 52.36%、67.78% 和 71.94%。《王者荣耀》的方向关系和精确更新更难QQ 音乐的大批量检索与收藏更容易由代码加速。这说明单一领域榜单容易把“模型恰好擅长某种工具形态”误判为通用 Agent 能力。企业自建评测集时也不能只选一条顺利的业务流程至少要覆盖检索密集、计算密集、关系联动、边界敏感与高风险写入等不同任务。七、横向对比E-Bench在智能体基准中处于什么位置E-Bench 不是第一个工具调用或状态环境基准它的差异在于把可复用的合成产品世界、自动任务生成和轨迹无关的数据库判分放在了一起。基准类型/代表项目环境形态主要考察判定方式与 E-Bench 的关键差异BFCL函数集合与对话工具选择、参数、并行与多轮调用调用结构和预期结果更擅长测函数调用基本功状态世界较弱τ-bench受控行业环境用户与工具交互、规则遵循、任务完成环境任务检查真实工作流强环境与任务构建人工成本较高AppWorld多应用模拟世界跨应用长链任务状态与任务检查场景丰富但不少环境状态围绕具体任务组织MCP-Atlas / MCP-Universe 等真实或在线 MCP 服务真实工具发现与调用任务或服务结果现实性高但重置、版本漂移和重复写入更难控制MCPEval从 MCP 规范自动生成MCP 工具使用与验证者轨迹对齐自动化程度高但轨迹对齐可能偏爱某条解法E-Bench完全合成、数据库驱动的产品世界隐藏信息获取、多步并行工具、精确状态修改数据库字段级差分可控、可扩展、路径无关但领域和现实噪声仍有限从纵向演进看E-Bench 继承了函数调用基准对工具格式的要求也吸收了状态型基准对闭环执行的关注它新增的工程贡献是把完整环境合成和任务合成拆开让一套一致的数据库可以持续产生新任务。从横向位置看它更像一个“Agent 后端集成测试场”而不是通用智力考试。团队可以用它观察模型如何处理分页、过滤、关系方向、并行工具调用和精确副作用却不能据此断言某模型在浏览器操作、桌面 GUI、安全攻击、开放网络搜索等能力上也同样领先。八、工程实践如何把E-Bench方法迁移到企业Agent评测E-Bench 最适合借鉴的不是三套腾讯产品数据而是其评测方法。企业可以在不暴露生产数据的前提下为订单、工单、CRM、日程或云资源 Agent 构造一套状态型回归测试。8.1 第一步把业务系统变成可重置测试环境选择一个边界清晰的业务域抽取表结构、实体关系、约束和产品级工具。数据应完全合成或严格脱敏并保持主外键、时间、权限和状态机一致。每次任务从数据库快照或事务模板恢复保证测试之间互不影响。8.2 第二步从真实失败模式设计任务任务不应只是把一个 API 包装成自然语言而应包含真实工作中常见的难点。失败模式任务设计方法应记录的诊断信号分页遗漏目标分散在多个分页末页也放置有效对象查询覆盖率、停止位置条件边界错误加入等于阈值、跨时区、并列排名样本命中集合与边界解释关系方向错误使用双向、主从或邀请关系修改字段和关系方向误操作放置名称相近但 ID 不同的实体多余数据库差分长链中断后续创建依赖前序返回 ID失败步骤、重试与补偿并行效率差要求处理几十个独立对象每轮调用数、Token 与耗时8.3 第三步把“正确”写成状态契约为每项任务保存允许的插入、更新和删除集合并明确禁止的额外变化。若业务允许多种等价终态应将标准答案从单个精确 Diff 扩展为约束集合例如“会议创建成功且所有目标参会人加入会议室可为 A 或 B”不要强迫 Agent 复刻唯一答案。{must_insert:[meeting:generated_id],must_update:[room:A:reservedtrue],must_not_change:[employee.salary,room:B],invariants:[participant_count room.capacity]}8.4 第四步同时测能力、可靠性和成本至少独立运行三次报告平均成功率、至少成功一次和全部成功同时保留工具轨迹、数据库差分、调用轮次、Token、延迟、费用及失败标签。高风险写操作还应记录是否在执行前复核目标集合、是否支持幂等、失败后能否回滚。离线评测通过 │ ▼ 影子模式只计算计划不执行写入 │ ▼ 低风险写入小流量 审批 完整审计 │ ▼ 扩大范围按任务类型设置权限和预算 │ └── 任一回归指标跌破阈值 → 自动回退E-Bench 的 Pass³ 仍然只是三次重复试验。企业上线门槛通常应更严格对删除、支付、权限和外部消息等操作除了高重复成功率还要有参数校验、预览确认、事务、幂等键、补偿动作和人工接管。九、局限与风险不要把合成高分直接等同于生产可用9.1 合成环境仍然缺少线上噪声E-Bench 的可控性来自完全合成。它避开了真实服务中的网络抖动、API 版本变化、权限过期、限流、脏数据、并发写入和用户中途改需求。模型在 E-Bench 中取得高分证明其在这类结构化状态任务中较强不等于可以无人监督地接管真实账号。9.2 三个领域不能代表所有Agent任务《王者荣耀》、QQ 音乐和腾讯会议覆盖社交关系、内容收藏与企业协同但不包含浏览器视觉定位、软件工程、开放网络检索、支付、安全攻防和物理世界控制。排行榜适合比较指定环境下的多步工具能力不适合推导“最强通用智能体”。9.3 精确差分严格也可能过于严格字段级精确匹配能有效发现多写、少写和方向错误但真实业务可能存在多个合法终态。若会议室 A 与 B 都满足需求单一标准 Diff 可能把另一条正确路径判错。企业复用时应结合数据库 Diff、业务不变量和允许结果集合而不是机械追求字节级一致。9.4 任务生成质量仍受模型与规则影响生成者拥有更强权限并不保证每道任务都自然、重要或无歧义。虽然数据库约束和确定性修复能保证结构一致仍需要人工抽检任务措辞、业务价值、难度分布和能力标签。公开任务还可能被模型开发者针对性优化因此长期评测应保留未公开测试集并持续生成新变体。9.5 代码执行扩大了能力也扩大了攻击面E-Bench-Code 证明代码能减少调用和 Token却不等于生产环境应向 Agent 开放任意代码执行。代码沙盒需要限制网络、文件系统、运行时间、依赖、密钥和可调用函数高风险领域工具仍需独立授权。否则效率提升可能以更大的安全边界为代价。十、总结维度核心要点研究定位E-Bench 测试智能体在状态环境中的多步工具调用而非静态问答或单次函数格式环境设计以三类腾讯产品为原型构造完全合成、可重置、数据库驱动的产品世界任务设计生成者拥有 SQL 与代码求解者只有 MCP 工具形成信息缺口与工具缺口判定机制用最终数据库差分精确判分不依赖 LLM 裁判也不限定唯一执行轨迹数据规模323 项任务、41 张表、76,317 行数据、1,219 个主要实体核心发现基础版最佳 Avg3 为 73.79%最佳 Pass³ 仅 58.82%可靠性仍是主要短板代码价值提升全部模型表现并显著减少顶层工具调用但更擅长替代计算而非推理落地边界合成高分不能直接代表线上可用仍需权限、事务、幂等、审批与持续回归E-Bench 代表了智能体评测的一次重要转向从检查模型是否生成了合理的调用转向检查它是否对真实状态做出了完整、精确且可重复的改变。这一转向会让很多漂亮演示失去光环却更接近 Agent 进入生产系统前必须面对的事实。它给模型团队的信号也很清楚。下一阶段的竞争不只是更长思维链或更高单次成功率而是完整信息获取、并行工具调度、精确副作用控制、失败恢复与成本之间的综合平衡。一个能偶尔完成复杂任务的 Agent 适合演示一个连续多次都只改对该改的状态、并且知道何时停手的 Agent才接近真正可用。参考资料E-Bench: Benchmarking Multi-Step Tool-Use Agents in Real-World Product Scenarios — arXivE-Bench 论文 HTML 全文 — arXivBerkeley Function Calling Leaderboard — Gorillaτ-bench: A Benchmark for Tool-Agent-User Interaction in Real-World Domains — arXivAppWorld: A Controllable World of Apps and People for Benchmarking Interactive Coding Agents — arXiv注本文数据均来自 E-Bench 论文 v1 与腾讯混元 2026 年 8 月 3 日公开解读统计与模型排名对应论文当时的实验设置模型版本、价格和榜单可能随时间变化。