编者摘要：FDE‑Gym 是面向AI 落地交付最后一公里的全新智能体基准，由行业专家基于真实项目改编，涵盖 18 个行业、20 个业务场景，合计 95 项端到端任务。它模拟真实企业环境，内置脚本化客户人员、生产系统，要求智能体挖掘隐藏约束、识别客户真实业务痛点，而非简单完成字面需求。
基准设置 L0‑L3 四级任务指令，信息逐级递减，L3 贴近真实业务开局。评分不以任务对错二元判定，采用归一化业务收益，扣除沟通交互成本，0 代表不改动基线、1 代表专家最优解。
评测 7 家厂商 13 种模型配置：最优 Claude Opus5.5 仅 0.56 分，仅完成 14/95 任务。挖掘未写明约束是最大瓶颈；即便拿到全部关键信息，模型也未必产出有效方案；弱模型交付结果甚至劣于不做任何改动。现有编码类基准表现好，不等于真实客户交付能力强。该基准还提供线上平台，支持人类与 AI 使用同一套评价标准。
10 个关键问题 Q&A
- Q：FDE‑Gym 和 SWE‑Bench 这类代码基准核心区别？
A：SWE‑Bench 解决定义好的工单；FDE‑Gym 模拟真实客户交付，需要识别隐藏约束、分辨错误需求，评价看真实业务指标，不是只看代码能否跑通。 - Q：L0‑L3 四个等级分别代表什么？
A：L0 全部信息明文给出；L1 明确问题但隐藏约束；L2 模糊需求；L3 仅客户原始诉求（可能需求本身错误），L3 是主要评测等级。 - Q：什么是 FDE 前线部署工程师？
A：派驻到客户侧工程师，不只是实现客户表面需求，挖掘真实业务痛点，协调人员、改造系统拿到业务收益。 - Q：任务 “解决” 的判定标准？
A：FDE‑Gym 得分≥0.8，并且没有发生生产事故。 - Q：为什么沟通交互要扣分数？
A：现实中反复打扰客户有时间成本；避免智能体无限制疯狂提问把所有问题丢给人。 - Q：本次实验最优模型结果如何？
A：Claude Opus5.5 L3 平均分 0.56，95 项任务只解决 14 个。 - Q：最大性能瓶颈是什么？
A：挖掘没有明文写出的业务约束；其次拿到全部信息后转化为有效的业务系统。 - Q：会出现模型做了还不如不改的情况吗？
A：会，弱模型大量任务得分小于 0，交付系统带来业务损失。 - Q：传统代码基准分数高，能预示 FDE‑Gym 表现吗？
A：不能。很多模型编码测试成绩优秀，但面向客户端到端交付能力很差。 - Q：本工作有什么主要局限？
A：客户角色是固定脚本，非真实人类；还没有完整人类专家基线；全部模型共用同一套智能体框架。
核心作者
杨东旭 ¹,∗、闫宏达 ¹、王仁鑫 ¹、张宝利⁸、左浩佳 ²、赵颖 ²、陈友敏 ³ ∗通讯作者
贡献者
廖晓健⁴、高聪铭⁵、姜天洋 ¹⁵、陈怡潇 ¹¹、王擎⁶、余志国 ¹⁶、李夏卿⁷、张玉浩⁹、孙嘉文 ¹⁷、徐仁哲 ¹⁰、米德 ¹⁹、吴天成 ¹⁸、付先亚 ¹²、赵轩鲁 ¹³,²⁰、冯博 ²¹、任美萱 ²²、林冠铭 ¹⁴、周子恒 ²³、王新华 ²³
¹ 深隐智能 ² 清华大学 ³ 上海交通大学 ⁴北京航空航天大学 ⁵厦门大学 ⁶南京大学 ⁷北京交通大学 ⁸北京邮电大学 ⁹天津大学 ¹⁰上海财经大学 ¹¹ 哈佛大学 ¹² 斯坦福大学 ¹³ 伦敦大学学院 ¹⁴康奈尔大学 ¹⁵华为 ¹⁶Atlassian 公司 ¹⁷Meta 公司 ¹⁸微软亚洲研究院 ¹⁹星立方人工智能 ²⁰北京优智思科技有限公司 ²¹ 博派管理咨询（深圳）有限公司 ²² 中国石油西南油气田分公司勘探开发研究院 ²³ 昆仑数智科技有限责任公司
图 1 FDE‑Gym 的构建流程。行业专家将来自 18 个行业的 20 个真实交付项目改编为可运行的客户业务环境；通过修改关键事实生成变体任务；最终保留 95 项任务，这些任务的评分器均已根据预定义评分基准完成有效性校验。
摘要
现有的智能体基准测试，大多基于问题工单、需求规格、任务单据这类定义完备的任务来评估智能体。但现实中面向客户的项目交付，存在本质上截然不同的挑战：前线部署工程师（FDE）需要梳理模糊不清的需求、在真实运行的业务系统中开展工作，挖掘那些没有明文写出的约束条件。
针对这一研究缺口，本文提出 FDE‑Gym 基准数据集，包含来自 18 个行业、20 类客户业务场景的 95 个端到端交付任务，全部由行业专家基于真实落地项目改编而成。在模拟客户业务环境中，内置脚本化的利益相关方与可修改的客户系统；智能体需要和相关人员交互，在接近生产环境的系统上操作，输出可正常工作的解决方案。
本基准不只用 “任务是否完成” 这种二元结果评判，而是衡量智能体交付的系统能够为客户业务指标带来多大提升；评分做归一化处理：0 代表系统没有任何改动（维持现状基线），1 代表专家给出的参考最优方案。同时评分会扣除和客户人员沟通产生的成本（消息交互、试运行、等待耗时），以此避免智能体无节制、草率地反复咨询客户。FDE‑Gym 同时配套在线平台，人类使用者可以使用完全相同的评分规则，练习前线部署工程师的工作技能。
本文测试了来自 7 家厂商的 13 种模型配置。在贴近现实的测试条件下（需要自行挖掘未写明的约束），表现最好的模型平均得分仅 0.56；95 个任务里只完成 14 项（无事故且得分≥0.8 才算任务解决）。挖掘未明文给出的约束是当前最大瓶颈：缺少明确指引、需要模型自行发掘约束条件时，性能会大幅下滑。但仅仅收集到全部信息也不足以消除性能差距：即便是最优模型已经从客户方获取全部关键事实的 23 项任务中，也仅有 10 项任务归一化业务提升可以达到 0.8 以上。
实验结果表明：“完成定义清晰的任务” 和 “面向真实客户交付可用 AI 系统” 之间存在巨大鸿沟。想要弥合这一差距，智能体必须能够发现隐藏约束、稳定操作在线业务系统、实实在在提升客户业务指标。
1 引言
在企业环境部署 AI，远不止满足客户表面提出的需求。真正的难点往往在于找出哪些改动可以切实改善客户实际业务。本基准中的一个案例可以直观说明该问题：某钻井运营商副总裁，希望为 11 月董事会准备一份生成式 AI 成果展示。这位副总裁提出需求：实现每日摘要邮件、一个 “查询油井” 对话窗口；同时说明停机编码系统不在本项目改造范围，不需要改动。
如果完全按照需求文档去实现，方案可以按时交付、全部功能校验通过，但对客户真实业务指标不会带来任何改善。问题根源来自每月停机赔付申报流程：原有基于关键词的脚本会错误将部分停机责任归属于承包商，每个月至少会产生一条争议记录，直接导致当月赔付申请被冻结。想要解决这个业务痛点，就必须改动这位项目发起人明确排除在项目范围之外的停机编码系统。工程师需要找到适用的合同条款、和成本工程师确认条款解读、还要取得审批人签字，但该审批人那一周不在岗。
这就是前线部署工程师（FDE）的工作职责：作为供应商派驻到客户组织内部的工程师。他不只是完成客户发起人提出来的功能，更要识别真正能解决业务痛点的方案，对接客户系统与相关人员完成落地交付。
现有的基准测试很少覆盖 AI 交付的这 “最后一公里”，大多默认问题本身已经被清晰定义。软件工程类基准提供缺陷工单与隐藏测试用例 [1‑3]；部署类基准给出完备的规格文档 [4]；企业场景基准提供预先定义好的任务 [5‑6]；需求澄清类基准只是把信息从一个定义完好的任务中抽走一部分 [7‑8]—— 以上所有基准中，底层待解决问题本身是固定不变的。
近期部分基准更贴近真实交付场景：τ^τ‑bench [9] 评估智能体根据客户需求搭建客服系统，并且将系统部署在真实测试用户面前；一篇后训练相关基准论文 [10] 把模型设定为前线部署工程师，评估交付后模型实际业务效果；XYEval [11] 专门测试智能体如何处理带有误导性的用户请求。但这些基准都只孤立覆盖交付流程中的某一部分环节。
FDE‑Gym 将上述挑战整合到同一个基准集，包含来自 18 个行业 20 个业务场景的 95 项任务，全部由行业专家基于真实项目改编。客户发起人的需求本身就可能指向错误问题；关键约束必须通过和客户人员沟通挖掘；评价依据是客户真实业务指标。因此，如果解决方案解决的并不是真正业务痛点，就不会获得分数。
交付后的系统不做任何修改直接部署，使用未见过的生产数据进行评估。FDE‑Gym 得分等于业务指标提升值，再扣除沟通交互成本（2.3 节会详细说明扣费规则）。维持现状（不做任何改动）基线得分为 0，专家撰写参考方案得分为 1；完全字面照做客户发起人的需求，最多只能拿到 0.2 分。实验证明现有模型距离参考方案还有巨大差距。
为定位智能体的失效环节，我们给每个业务场景设置 4 种任务指令等级，提供的信息逐级减少：L0 问题描述完整完备，一直到 L3，只给客户原始诉求（诉求本身可能没有对准根本业务问题）。不同等级下，运行环境、客户角色、评分器全部保持不变；只有任务指令发生变化。因此性能差异可以直接体现 “信息缺失” 带来的影响。本文基于这套设置评估 7 家厂商的 13 种模型配置，得到五大核心发现：
-
即便是最强模型配置，距离参考方案仍然差距明显。L3 条件下 Claude Opus 5.5 取得最高平均分 0.56，只解决 95 项任务中的 14 项；13 种配置中有 5 种一项任务都无法解决。就算对每个任务都选用表现最好的模型，整体平均分也仅 0.70，仅完成 30 项任务。 - 挖掘未写明的约束是主流大模型最主要瓶颈
。当规则、约束全部明文给出时，三大头部模型得分可以达到 0.73‑0.82；一旦需要模型自行挖掘约束，分数骤降至 0.39‑0.62。在原始任务集上，L3 相比 L1，分数最多仅下降 0.08。 -
获取全部必要信息不等于交付有效方案。L3 设置下头部模型能够拿到 72%‑85% 客户侧关键事实，但交付系统只能实现参考方案 60%‑70% 业务收益；沟通交互成本会再把最终得分压低 0.14‑0.22。 -
能力弱的模型交付结果甚至比 “什么都不改” 更差。Claude Haiku 4.5 在 95 个任务中的 79 个任务得分低于维持现状基线；Mistral Small 4 就算还没扣除沟通成本，也有 51 项任务交付结果劣于基线。 -
没有模型可以在全部场景下都表现优秀。20 个业务场景中，有 5 个场景没有任何模型平均得分超过 0.5；同一个场景内部不同任务，头部模型得分的区间中位数达到 0.34‑0.44。
本文主要有三点贡献： 第一，构建 FDE‑Gym 基准，评估智能体是否可以定位客户底层真实问题，交付可落地方案、带来可量化业务收益。 第二，提出一套场景构建方法论：结合任务变体、脚本化客户角色、预定义评分锚点，实现可复现评估，同时避免模型靠机械字面理解、取巧捷径拿到高分。 第三，完成 13 种模型配置的大规模评测；同时上线在线平台，人类与 AI 智能体可以使用同一套打分标准练习交付任务。
2 任务组成结构
每一项任务对应一次真实客户项目：包含客户组织（也就是雇佣智能体的一方，智能体可以向组织内部人员提问）、一名任务发起人（客户方分配工作的人员），以及一套待优化的生产业务系统。图 3 展示一个任务的四大组成部分。
图 3 FDE‑Gym 任务组成：任务输入、智能体行为与输出、生产环境评估、得分解读。智能体读取任务输入，与客户方人员交换消息（客户角色也会主动发起对话）；交付出来的系统直接原样部署上线，使用从未见过的线上流量计算业务指标。只有满足图中标定的全部评分锚点，该任务才会被纳入基准集。
2.1 运行环境与可用信息
智能体工作空间包含：任务指令（客户发起人分配的工作描述）、一份客户生产系统副本、相关文档与历史业务数据，以及内部人员通讯录。运行环境内置标准 Python、SQLite；禁止安装额外第三方包，禁止访问公网网络。交付后的系统仅允许访问企业内部大模型网关，调用会产生计费。交付完成后，system/目录下全部内容原封不动部署到生产环境；原有程序入口保持不变，新增功能必须对接原有入口才可以生效。
智能体不会收到任何提示：包括和客户沟通会产生成本、部分人员不该联系、客户发起人的需求可能本身方向错误。识别这些问题，正是评测的核心目标。相关线索分布在通讯录、客户文档、业务数据中，和现实中前线工程师查找信息的来源保持一致。和真实项目一样：文档存在过时情况，遗留代码逻辑存在错误预设，很多关键信息不会显式写在材料内。
2.2 任务指令等级
4 档任务指令等级（见表 1），通过只修改任务描述文本、固定环境与评分标准，把挑战拆解为：代码实现、挖掘约束、厘清真实业务问题。 L3 是主要评测档位，最贴合真实客户项目刚启动时的状态。L0 也不是只需要写代码：全部事实给齐，但解决方案的设计依然需要模型自行完成。
表 1 四档任务指令等级。全部等级的运行环境、客户角色、打分规则完全一致；仅修改任务指令文本
|
|
|
|
|---|---|---|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2.3 FDE‑Gym 得分计算
FDE‑Gym 使用未见过的生产数据集，以客户自身业务 KPI 来评价交付系统。举例：售后系统看净财务收益；钻井业务系统看承包商停机赔付时长的识别准确率。
定义下面一系列指标衡量智能体交付效果：
- 归一化业务收益 U（Normalized Business Uplift）
对比交付方案与专家参考方案带来的业务提升： \(U=\frac{KPI_{delivered }-KPI_{baseline }}{KPI_{reference }-KPI_{baseline }} \tag{1}\)
-
\(KPI_{baseline}\)：系统不作任何改动（维持现状基线）业务指标 -
\(KPI_{delivered}\)：智能体交付系统的业务指标 -
\(KPI_{reference}\)：专家编写的参考最优方案业务指标
全部指标基于同一套隔离测试数据集计算。 \(U=0\)代表没有业务改善；\(U=1\)等同于专家方案效果；\(U<0\)代表交付结果比不改系统还要差。
- 事故校正 \(U_{adj}\)（Incident Adjustment）
如果发生预定义生产事故（例如越权操作）：正向业务收益直接清零，负向收益保留不变。 \(U_{adj }= \begin{cases} U, & \text{没有发生事故}, \\ min (U, 0), & \text{发生事故}. \end{cases} \tag{2}\) - 客户沟通成本 C（Stakeholder Contact Cost）
单位和归一化业务收益保持一致，是智能体所有客户交互产生扣费总和。 \(C=\sum_{k \in K} c_{k} \tag{3}\) K 代表本轮评测中所有产生计费的交互；\(c_k\)为单次交互扣费。每一个客户角色都有隐藏的单条消息计费；当智能体反复打扰对方、违反沟通限制时扣费会变高。对方未回复的消息不计费。如果环境支持试运行、日历时间，那么每一次试运行、每等待一天，同样会计入扣费。 - 单次运行 FDE‑Gym 得分 S
经过事故校正的业务收益，减去沟通交互成本： \(S=U_{adj}-C \tag{4}\) 无事故情况下简化为 \(S=U-C\)。 当无事故并且得分≥0.8，才判定该任务被成功解决。 - 平均 FDE‑Gym 得分 \(\overline{S}\)
用来汇总模型在多任务、多轮重复测试的综合表现。为避免个别灾难性负收益任务把平均分拉得过低，聚合统计前会把事故校正后收益下限限定为‑1（该下限只用于求平均，不改变单轮任务是否解决的判定）。 \(\overline{S}=\frac{1}{N} \sum_{i=1}^{N} \frac{1}{R} \sum_{r=1}^{R}\left[max \left(U_{adj, i, r},-1\right)-C_{i, r}\right] \tag{5}\) N 代表任务总数；R 代表每个任务重复运行轮次；i 为任务索引，r 为轮次索引；所有任务权重均等。 
图 4 案例演示：钻井业务场景 oil_npt，L3 原始任务。客户发起人表面想要 AI 会议摘要与对话助手，但真正业务痛点来自停机赔付申报错误；完全字面实现需求最多只能拿到 0.2 分。最优模型在该任务 L3 下得分 0.61。
3 基准数据集构建
3.1 基于真实交付项目构建业务场景
如图 1，行业专家将 2024 年以来，中国、新加坡、美国真实客户交付项目改编为 20 个业务场景，覆盖 18 个行业（表 2）。每个场景生成 1 个原始任务 + 若干变体任务，共享同一套客户环境，但修改部分关键事实。原始任务加上变体，最终合计 95 项任务。任务要求智能体交付智能体、业务工作流或者服务，运行在客户业务环境中。所有场景贴合行业实际规范；企业和个人全部做匿名化或者虚构处理，部分数据改编自公开行业数据源。
表 2 FDE‑Gym v1.0 全部 20 个业务场景。同一个场景的原始任务与变体共享业务环境，仅修改问题背后关键事实；全部合计 95 项任务。最后一列代表原始任务评估使用的隔离数据集。
|
|
|
|
|
|
|---|---|---|---|---|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
3.2 场景变体与底层事实
如果每个场景只设计单一任务，模型可能靠记忆固定方案完成评测。为规避该风险：每个原始任务会生成 2‑7 个变体；变体修改关键事实：例如哪条规则已经过期、谁掌握核心信息、客户发起人的需求是否对准真实问题。变体需要完全不一样的解决方案，同一场景内一个任务成功不代表变体任务也能成功。所有业务场景，没有任何一类问题模式出现超过三分之一任务。以上设计迫使模型根据每个任务证据推理，而不是套用固定模板。
3.3 客户角色模拟
20 个场景总共模拟超过 130 位客户人员。为保证可复现，全部角色回复使用脚本实现；已有研究证明，如果用大模型扮演用户，评测结果会发生明显偏移 [14]。一个小型模型负责把问题映射到话题；每个角色的知识、认知误区、信息披露条件全部预先写死。脚本内置角色耐心阈值、要求证据、对话上下文依赖、临时不在岗、沟通限制。智能体必须从客户文档推断角色身份与沟通约束。
3.4 准入锚点与反取巧校验
纳入 FDE‑Gym 的任务必须全部满足 4 条评分锚点（见图 3）：
-
专家参考方案得分≥0.95； -
什么都不改的基线得分 = 0； -
完全字面照抄任务指令、不去挖掘额外约束得到的 “字面解”，得分最高不超过 0.2。例外情况：当发起人需求本身完整准确，字面解等价于参考解，此时得分≥0.95；保证 “不相信发起人” 不会成为万能最优策略； -
各类取巧捷径方案得分≤0.8。捷径包括：过拟合历史数据、猜阈值、全部问题丢给人工处理。如果智能体尝试绕过客户管控、篡改评分器，得分会被压到接近 0。评测人员使用超过 270 种捷径、绕过策略对评分器完成测试。智能体无论是靠查阅文档，还是靠和人员交互获取信息，评分规则保持完全一致。
3.5 专家评审与线上平台
每一项任务经过多位行业专家交叉评审迭代；专家累计投入超过 10000 小时。FDE‑Gym 同时上线在线平台（fde‑gym.com），人类使用者可以使用和智能体完全相同工作空间，和脚本角色交互，接受同一套评分器打分。平台正在采集行业人类专家在 L3 任务下的基准结果，将在后续版本论文公布。
4 实验设置
测试模型：来自 7 家厂商共 13 套模型配置（12 个基础模型，其中 1 个分别开启 / 关闭深度思考模式）：Claude Opus 5.5、Claude Sonnet 5.5、GPT‑6 Astra、GPT‑6.1 Sol、GLM‑5.3 Flash、DeepSeek V4.1 Flash、Gemini 3.8 Flash、Qwen 3.8 Flash、GPT‑5.5、GPT‑6 Luna、Mistral Small 4、Claude Haiku 4.5、Claude Haiku 4.5（开启思考模式）。全部模型共用同一套极简智能体框架，提供 5 个工具：执行命令、读文件、写文件、编辑文件、列出文件，不对任何模型做定制化改造；调用命令完成向客户角色发消息。
实验流程：在 L0‑L3 四档指令等级开展评测。L3 作为主评测设置，覆盖全部 95 项任务（20 原始任务 + 75 变体任务）。L0‑L2 仅在 20 个原始任务上运行；3 个场景 L2、L3 任务文本完全一样，直接复用 L3 结果。每个任务‑等级组合重复运行 3 轮，取平均分。一轮运行结束条件：智能体主动提交交付；或者达到上限（最多 200 轮动作、150 分钟、模型调用花费 8 美元，满足任意一项即终止）。终止时系统状态直接部署做评估。
结果报告：报告每个指令等级下平均 FDE‑Gym 得分，通过自助抽样计算 95% 置信区间；同时给出未扣减沟通成本前归一化业务收益、沟通成本、单轮模型调用开销。
和其他基准对比：引用 Vals.AI 公开评测结果，和 Terminal‑Bench2.1、Vibe Code Bench、Finance Agent 做横向对比。注意其他基准输出任务成功率百分比；FDE‑Gym 输出归一化收益，图中并排展示，不代表指标等价。
开源资源：生成任务环境、模拟客户角色、打分的整套执行框架，以及实验运行器全部开源（github.com/deeplethe/fde‑gym v1.1.0）。20 个原始任务与评分器可申请获取（huggingface.co/datasets/DeepLethe/FDE‑Gym）；3 个任务作为样例完全公开。75 个变体任务、全部专家参考方案做保留，不对外公开。
5 实验结果
5.1 最优模型距离参考方案仍差距巨大
发现 1：最优配置平均得分 0.56，仅解决 95 项任务中的 14 项；就算每个任务选用最优模型，也无法消除性能鸿沟。
L3 条件下 Claude Opus5.5 得分最高 0.56（95% 置信区间 0.50‑0.62）；其次 Claude Sonnet5.5（0.49）、GPT‑6 Astra（0.38）、GPT‑6.1 Sol（0.37）。以上三者称为头部模型。还有 3 套配置得分接近 0.2，两套略大于 0，剩余 4 套得分小于 0。没有模型能解决超过 15 个任务；13 套配置里面 5 套 0 解决。
性能短板不是少数极难场景造成：只有 bank_scam_hold 一个场景，有模型平均分≥0.8。如果给每个任务选用全部 13 套配置里最好结果，整体平均分仅 0.70，完成 30 项任务；还有 16 项任务所有模型最高分也不足 0.5。
参考方案全部可以拿到≥0.95 高分；L0 条件下头部模型也可以达到 0.73‑0.82。目前人类专家在 L3 条件下的基准结果还在采集中。
5.2 隐藏约束缺失带来的性能下降最为显著
发现 2：约束条件被隐藏，三大头部模型在相同任务上平均下降 0.28（置信区间 0.17‑0.39）；后续需求描述模糊、需求本身方向错误，只会带来额外 0.04 的小幅下降（‑0.03~0.14）。
基于 20 个原始任务的评测结果：L0 所有规则全部写明，头部模型得分 0.73‑0.82，可以解决 11‑13/20 任务。L1 任务问题描述清晰，但约束条件需要自行挖掘；得分掉到 0.39‑0.62，仅解决 1‑7 个任务。性能下降来自两方面：交付系统本身业务收益从参考方案的 0.81‑0.90 下滑至 0.63‑0.80；同时挖掘约束带来沟通开销：单任务提问数量从 3.9‑7.0 上涨到 11.3‑13.0，沟通成本从 0.07‑0.10 上涨到 0.18‑0.24。
从 L1 到 L3，分数几乎不再明显下滑。Claude Opus5.5：L1=0.62，L2=0.54，L3=0.55；Claude Sonnet5.5：0.45、0.47、0.46；GPT‑6 Astra：0.39、0.34、0.33。配对统计 20 个原始任务、对三个头部模型取平均：L0→L1 平均降 0.28；L1→L3 仅再降 0.04。
也就是说，最大性能损失发生在 “需要自己找约束” 这一步；而不是需求本身描述模糊甚至需求本身错误。一个解释：当模型被迫主动挖掘约束时，同时也能识别客户发起人真实诉求。但弱模型不一样，L1 到 L3 性能会持续大幅下跌。
即便全部规则在 L0 明文给出，也没有模型得分超过 0.82：掌握全部事实，不等于能做好工程实现交付。
5.3 获取全部关键事实，依然不等于交付有效方案
发现 3：头部模型可以拿到绝大多数客户关键事实，但交付收益只达到参考方案的 0.60‑0.70；沟通成本进一步压低最终得分。
评分器会记录智能体从客户角色获取了哪些关键事实，从而区分 “信息收集” 和 “系统构建” 两个环节。L3 条件下三大头部模型每个任务提问 10.0‑12.3 次，拿到 72%‑85% 关键事实；但归一化业务收益仅 0.60‑0.70。
在 73 次（模型‑任务）实例中，头部模型拿到全部关键事实：归一化业务收益平均 0.66；仅 27 次（37%）收益≥0.8。单独看 Claude Opus5.5，23 个任务获取全部关键事实，其中只有 10 个业务收益≥0.8。
第二部分损失来自沟通扣费。GPT‑6 Astra 有 36 次任务交付系统业务收益≥0.8；但扣完沟通成本之后，只剩 9 个任务判定为解决。Claude Opus5.5 对应 40→14。智能体不会收到 “提问会扣费” 提示，因此会无节制提问。沟通成本消耗掉 Opus5.5 业务收益中的 0.14；消耗掉 GPT‑6 Astra 收益中的 0.22。反过来弱模型几乎很少提问：Mistral Small4 平均每个任务仅提问 0.7 次，只拿到 6% 关键事实。
5.4 弱模型大量任务交付结果劣于 “什么都不改”
发现 4：最差一批模型 60%‑83% 任务得分低于维持现状基线；这种情况下，不做任何改动反而对客户更有利。
得分下限不是 0：交付系统可能错误赔付、责任划分错误、错误触发告警，最终效果比改造之前更差。Claude Opus5.5 仅有 5 个任务得分小于 0；Sonnet5.5 为 7 个。反观 Claude Haiku4.5 有 79 个、GPT‑6 Luna 63 个任务结果比基线还差。
一部分负分来自沟通扣费，但更多根源来自交付系统本身。还未扣沟通成本时：Mistral Small4 有 51 项任务系统效果劣于基线；Haiku4.5 (thinking) 有 55 项；头部模型仅 1‑4 项。部分任务 Mistral Small4 造成的业务损失甚至超过参考方案带来的正向收益。开启深度思考对弱模型没有改善：Haiku4.5 普通模式‑0.33；开启思考‑0.35。
对业务使用者的现实启示：差的智能体不是 “便宜版强智能体”；在大量任务场景，它带来的期望业务价值是负数。
5.5 模型性能在不同业务场景、不同任务变体差异巨大
发现 5：20 个业务场景中 5 个场景没有任何模型平均分≥0.5；同一个业务场景修改内部事实，模型得分会发生巨大变化。
Claude Opus5.5 在 11 个场景拿到第一；Sonnet5.5 占 4 个；GPT‑6 Astra 占 2 个；剩余几家各占 1 个。即便是头部模型，同一业务场景内部得分差距也很大：revenue_dispute 场景三者分别为 0.12、0.27、‑0.44。20 个场景中 5 个场景，没有模型平均得分≥0.5；最难两个 news_incident、revenue_dispute 最优得分只有 0.18 和 0.27。
变体任务充分说明任务事实细节对结果影响巨大。同一业务场景内部，头部模型得分区间中位数 0.34‑0.44；20 个场景中 6‑8 个，分数跨度超过 0.5。
5.6 更高调用开销、更多轮次不等于更好交付效果
开销与轮次和模型排名相关性很低。GPT‑6.1 Sol 平均每轮花费 0.24 美元、25 轮动作，得分 0.37；Gemini3.8 Flash 平均 1.54 美元、121 轮动作，得分仅 0.19。Qwen3.8 Flash 平均 169 轮动作、110 分钟，大量任务无法在时限内提交，得分仅 0.07。三大头部模型全部可以按时提交，仅消耗 26‑60 轮动作。懂得判断 “工作已经完成”，是智能体一项重要能力。
5.7 和其他基准横向对比
Terminal‑Bench2.1（终端代码任务）、Vibe Code Bench（Web 应用开发）、Finance Agent（金融分析）这类前置环节基准上模型表现很好，但换到 FDE‑Gym 分数大幅下降。同一个模型，前面基准可以做到 80%‑90% 任务成功率，在 FDE‑Gym 归一化得分仅 0.19‑0.56。注意：任务成功率与归一化业务收益指标不能直接等价。FDE‑Gym 最接近 “任务成功” 的指标是 “任务被解决”（得分≥0.8 且无事故）。表现最好的 Opus5.5，95 项任务仅 14 项解决（约 15%）。
现实启示：模型在编码、终端操作、分析类基准上表现好，不能代表它可以完成面向客户的完整 AI 交付；同一批模型，平均 7 次业务交付里最多有 1 次可以真正改善客户业务指标。
6 相关工作
现有的各类基准，大多只评测交付流程中某一个阶段。表 4 按能力维度梳理已有工作。就我们所知，还没有基准完整串联整条因果链路：需求理解错误，即便代码写得再好，最终也无法带来业务收益，并且这一损失直接反映在业务指标上。
和本文最接近的同期工作：τ^τ‑bench [9]，智能体接收业务记录、客户、现有代码库，构建客服智能体，部署给模拟真实用户。它最优配置仿真通过率 23.9%，专家参考方案 82.2%；同样观察到大模型距离专家方案差距巨大。区别在于：FDE‑Gym 设置多档任务指令（从信息完备到需求本身错误）；交互沟通会产生成本；评价指标是相对基线的业务收益，分数允许为负；业务场景覆盖 18 个行业，交付物也不限于客服智能体。
Trains but Doesn’t Learn [10] 把智能体设定为前线部署工程师做模型后调优；揭示一类失效模式：全部检查项都通过，但模型没有业务增益；本文 “字面解锚点” 正是为识别这类交付失败。
两篇和任务指令缺失高度相关工作：XYEval [11] 把已有基准改造为 XY 问题（用户提出错误的表面方案，而非真实问题），性能最高下降 46.7%。但在 FDE‑Gym 中头部模型面对错误原始需求性能下降幅度不大；推测完整业务环境中文档、数据、多方客户角色可以给模型提供纠错线索。UnderSpecBench [35] 保持环境不变，逐级劣化任务指令，发现信息不足时模型倾向猜测而非直接失败；Implicit Intelligence [23] 在需要挖掘隐藏约束的简单任务最优通过率 48.3%；和本文结论一致：最大性能下跌来自未写明的约束条件。
有三篇基准直接启发 FDE‑Gym：TheAgentCompany [5] 同样拥有完整模拟企业与可对话同事；FDE‑Gym 改动点：把场景变为外部客户外包项目，评价方式从 “是否完成任务” 改成业务指标收益。LHAW [8] 系统研究信息缺失，建模提问成本；L0 到 L1 的性能下跌现象和本文一致；同时 LHAW 没有覆盖 “客户需求本身就是错的” 场景，而 L3 专门针对该场景。Vending‑Bench [30] 证明业务仿真可以替代人工评审；FDE‑Gym 把业务仿真绑定到工程交付产物上。
两项方法论启发：使用大模型扮演人类用户，评测结果会发生偏移 [14]，因此本基准全部角色使用固定脚本；单次运行成功率会高估真实可靠性 [36]，因此本基准每个任务重复跑 3 轮。任务准入锚点借鉴 “上线基准前，必须校验空操作、取巧方案” 的最佳实践 [38]。
7 局限性
- 模拟客户角色
所有客户人员使用脚本实现，保障可复现。真实人类会临时改变想法、答非所问、根据历史对话改变态度。沟通扣费由场景专家设定，属于对客户时间成本的建模，并非真实测量得到。 - 样本规模
L0‑L2 只基于 20 个原始任务评测；其中 3 个场景 L2 与 L3 文本完全复用。L0 到 L1 性能下降幅度很大，但 L1‑L3 之间没有观测到巨大落差，现有样本不足以排除小幅度的性能下跌。 - 暂无人类基线
本版本只报告模型结果。基准依靠 “不改系统基线” 和专家参考方案做刻度锚定，证明任务在完整信息下可被解决；但是人类专家只拿到 L3 原始需求时能做到什么水平，还没有公开数据。 - 统一智能体框架
全部模型使用同一套极简智能体运行框架。结果代表模型在这套框架上的表现，不等于厂商完整成品产品；更好的外层框架可能改变分数与相对排名。 - 隔离与计费
多台主机运行，进程隔离强度参差不齐；每轮运行会事后审计，但强容器隔离会进一步提升安全性。模型开销为调用链路计费，不是官方标价对比。 - 数据集污染风险
20 个业务场景取自真实交付，侧重强监管行业的工作流与智能体任务。企业名称全部虚构，任务变体修改关键事实；但无法完全排除训练数据中存在相似素材。
8 结论
FDE‑Gym 站在客户视角衡量智能体交付能力：评判标准不是 “是否输出系统”，而是 “客户业务有没有得到改善”。以此标尺来看，AI 交付的最后一公里依旧长路漫漫。13 套模型配置中最强版本平均得分 0.56，大约 7 个任务才能解决 1 个。
性能短板和最初设想并不一样：当客户原始需求本身方向错误，头部模型性能并不会剧烈下滑；模型大多可以收集到大部分关键事实。主要性能损失来自两点：把收集到的信息转化为真正有效的系统；交付过程中客户沟通交互带来的成本开销。
弱模型问题更严重：大量任务，什么都不做反而比模型交付结果更好。
上述能力正是资深现场工程师的核心价值。FDE‑Gym 让这种工程判断力变成可量化指标：同一套任务，无论是人类还是 AI 智能体，都输出一个基于客户业务指标的分数。
致谢与利益声明
DeepLethe 开发运营 FDE‑Gym 线上平台并维护排行榜；本文评测的所有模型均不属于任何作者所属机构。部分行业专家因为保密协议不在作者列表中，在此一并致谢。
参考文献（略）
注：文中 [1‑40] 为原文参考文献编号，翻译保留对应位置；部分专业名词兼顾行业习惯与论文术语，Forward‑Deployed Engineer 翻译为前线部署工程师（FDE）；stakeholder 译为客户利益相关方 / 客户角色；uplift 统一翻译为业务收益；anchor 翻译为锚点。 公式、表格、图片说明全部完整翻译。
