SWE-bench 拿 88 分的模型，给客户交付时 7 单里只能成 1 单：FDE-Gym 把 AI 交付的"最后一公里"量化了

核心摘要：现在的智能体基准测试都在考"题目已经出好"的解题能力——issue 写清楚了、spec 给全了、hidden test 等着跑。但真实的企业交付根本不是这样：客户 VP 拍脑袋提的需求可能指向错误的问题，关键约束藏在某个不在岗的审批人脑子里，"做对了题目"和"帮客户赚到钱"是两回事。FDE-Gym（arXiv:2610.22350）把这最后一公里做成了基准：95 个端到端交付任务、20 个客户场景、横跨 18 个行业，全部由行业专家从真实交付项目改编。评分不看"做没做完"，看"客户的业务指标改善了多少"，问客户问题还要计费。结果相当扎心：最强的 Claude Opus 5.5 在真实设定下均分只有 0.56，95 个任务只"解决"了 14 个；弱模型更惨，多数任务交付完客户反而更亏。我的判断：这是今年最有工程现实感的 Agent 基准之一，不是刷榜玩具，是给"AI 能不能真的替人干活"这个问题立了一把尺。

📖 论文信息

• 标题：FDE-Gym: The Last Mile of AI Delivery
• 链接：https://arxiv.org/abs/2610.22350
• 作者：Dongxu Yang, Hongda Yan, Renxin Wang, Baoli Zhang, Haojia Zuo, Ying Zhao, Youmin Chen（共同一作/通讯）等 26 人
• 机构：DeepLethe 牵头，联合清华大学、上海交大、北航、厦门大学、南京大学、北交大、北邮、天大、上财、Harvard、Stanford、UCL、Cornell，以及华为、Atlassian、Meta、MSRA、中石油西南油气田勘探开发研究院等 23 家单位
• 时间：2026 年 10 月 15 日提交，14 页正文、8 图 4 表
• 资源：官网 fde-gym.com（含在线练习平台和榜单），代码 github.com/deeplethe/fde-gym，数据在 Hugging Face（DeepLethe/FDE-Gym）

作者名单很有意思：一半高校、一半产业界（包括真正的油田研究院），这解释了为什么场景真实得不像编的——因为本来就是从真实项目改编的。

🎯 先说个真实场景，你就知道这论文在干什么

论文开篇讲了一个钻井公司的例子，我转述一下：

钻井运营商的一位 VP 想在 11 月董事会前搞个生成式 AI 的标杆案例，于是提需求：给我做个每日摘要邮件，再做个"问你的井"聊天框。哦对了，停机编码（downtime coding）系统已经有了，不在项目范围内，别动它。

一个"听话"的智能体怎么做？照做呗。摘要邮件上线、聊天框上线，功能测试全过，按时交付。然后呢？客户的业务指标一分钱没涨。

真正的瓶颈在哪？这家公司每个月要向钻井承包商索赔停机损失，而现在跑的那套基于关键词的归因脚本会把一些不该算在承包商头上的停机错误归因过去，每个月至少产生一条有争议的记录——只要有一条争议，整个月的索赔就被挂起。所以钱全卡在这了。要解决这个问题，恰恰必须动那个 VP 明确说"不在范围内"的停机编码系统，还得找到适用的合同条款、跟成本工程师确认解释口径、再找审批人批准变更——而审批人这周不在岗。

这就是 FDE（Forward-Deployed Engineer，前置部署工程师）的日常工作：客户说的未必是客户要的，答案散在文档、遗留代码和一群各怀心思的干系人之间。

而现有的 Agent 基准在测什么？SWE-bench 给你写好的 issue 和 hidden test，部署类基准给你 spec，澄清类基准从一个本来就正确的任务里扣信息——问题本身永远是定义好的。说实话，这跟真实交付的差距，就像驾校考试科目二和真上路跑货拉拉的区别。

🧠 FDE-Gym 的设计：一套任务长什么样

FDE-Gym 包含 95 个任务，来自 20 个客户场景（18 个行业：银行、建筑、教育、充电桩、物业、资管、电网、物流、医疗、电商、制造、媒体、能源、软件、健康险、科研、仓储机器人、水务），每个场景由行业专家从 2024 年以来中国、新加坡、美国的真实交付项目改编而来。

图 1：FDE-Gym 的构建流程。专家把 18 个行业的真实交付项目改编成可运行的客户环境（20 个场景、130 多个有角色有立场的脚本化干系人），再修改关键事实生成任务变体（共 95 个任务），累计投入超过 1 万专家工时，并用 270 多种作弊/捷径策略验证评分器的鲁棒性。

任务的四个组成部分

图 2：一个 FDE-Gym 任务的完整结构。智能体读取任务输入（赞助人的任务书、生产系统副本、文档和历史数据、干系人通讯录），在客户工作区里 read/ask/change/test，交付的系统原样部署到生产环境，用智能体从未见过的留存流量按客户自己的业务指标评估，最终换算成一个 0 到 1 之间的分数。

几个设计细节值得单独说：

环境是"活"的。工作区里有客户生产系统的副本、文档、历史数据、员工通讯录。运行时只有标准 Python 和 SQLite，不许装包、不许上公网，交付的系统只能调公司内部的 LLM 网关（按用量计费）。交付后 system/ 目录原样部署，生产继续调原来的入口——你的新功能必须挂到原入口上才生效。这个细节非常真实，改遗留系统的人都懂。

干系人是脚本化的，不是 LLM 扮演的。130 多个干系人，每个人的知识、误解、透露信息的条件都预先写死：有耐心上限、要证据、依赖之前的对话、会临时不在岗、有接触限制。为什么不用 LLM 模拟用户？论文引用了之前的研究——换一个扮演用户的模型，测出来的 Agent 成功率会漂移好几个百分点。为了可复现，全部脚本化。这个取舍我很认同，宁可牺牲一点"真人感"，也要分数可比。

关键：没人告诉智能体这些规则。没人告诉它问问题要花钱、有些人不该联系、赞助人的需求可能是错的。这些都得自己从文档和数据里嗅出来——而文档可能过时，遗留代码可能反映着错误的假设。

四个任务指令级别：信息递减的对照实验

这是整个设计里最精巧的部分。同一个场景，环境、干系人、评分器完全不变，只改任务书里的信息量：

因为只有任务书在变，各级别之间的分数差异就干净地隔离出了"被扣掉的信息"的影响。L3 是主评测设定——它最接近真实交付的起点。说实话，这个对照设计比很多基准"换个数据集就说自己更真实"的做法高明多了。

评分：不看完成率，看客户的 KPI 涨没涨

FDE-Gym 的分数设计是整个基准的灵魂，四步：

1. 归一化业务增益 U：

分子是交付系统相对"什么都不改"的业务指标改善，分母是专家参考方案的改善。U 等于 0 是原地踏步，等于 1 是追平专家方案，小于 0 就是还不如不改——比如售后系统赔了不该赔的钱、夜间值班系统叫醒了不该叫的工程师。

2. 事故调整：如果发生预定义的运营事故（比如越权操作），正的增益直接清零，负的保留。

3. 干系人联系成本 C：每发一条消息、每跑一次试用环境、每等一天，都按预设费率计费，换算成和 U 相同的归一化单位。每个干系人有隐藏的每条消息费率，超出耐心或违反接触限制会更贵。

4. 最终分数：\(S = U_{\mathrm{adj}} - C\)。分数达到 0.8 且无事故，任务才算"解决"（resolved）。

还有四个入场锚点保证任务质量：参考方案必须 ≥ 0.95；什么都不做必须等于 0；照章办事的字面解最多 0.2；捷径策略（过拟合历史数据、猜整数阈值、把不确定决策全甩给人）最多 0.8。评分器用 270 多种作弊和绕过策略测试过。

字面解封顶 0.2 这条太狠了，也太对了。它的潜台词是：你照着任务书一字不差地做完，最多拿两分——因为任务书本身可能就指错了方向，就算方向对，漏掉的约束也足以让交付失败。

图 3：钻井场景（oil_npt）的完整例子。左边是赞助人的 L3 原始需求——摘要邮件加聊天框，且明确说停机编码"不在范围内"；右边是真相——钱全卡在每月的停机索赔上，关键词归因脚本每月制造争议导致索赔挂起，要解决问题必须动那个"不在范围内"的编码器。照做最多得 0.2；最强模型拿到 0.61；13 个模型里有 10 个得分不超过 0.05。

看到这个 10/13 我愣了一下：绝大多数模型在这个任务上基本等于白干。

📊 实验结果：数据比想象中难看

评测了 7 家厂商的 13 个模型配置（Claude Opus 5.5 / Sonnet 5.5 / Haiku 4.5 及 thinking 版、GPT-6 Astra / GPT-6.1 Sol / GPT-6 Luna / GPT-5.5、GLM-5.3 Flash、DeepSeek V4.1 Flash、Gemini 3.8 Flash、Qwen 3.8 Flash、Mistral Small 4）。全部跑在同一个极简 Agent 框架里（5 个工具：执行命令、读、写、编辑、列文件），每个任务跑 3 次取平均，单次上限 200 轮 / 150 分钟 / 8 美元。

主结果表

图 4：左图是 13 个配置在 95 个任务上的 L3 均分（实心条为扣分后的最终分，浅色部分为扣联系成本前的业务增益）；右图是四个指令级别下的分数曲线，作者把 L0 到 L1 的那道断崖直接标成了"The Cliff"。

五个核心发现，一个个说。

发现一：最强模型离参考方案也差得远

Claude Opus 5.5 以 0.56 领跑（95% 置信区间 0.50–0.62），95 个任务只解决 14 个；13 个配置里有 5 个一个都解决不了。就算作弊——每个任务挑所有模型里最好的那次成绩——拼起来也只有 0.70、解决 30 个，还有 16 个任务没有任何配置能上 0.5。

20 个场景里只有 bank_scam_hold（银行反诈骗挂断队列）一个场景有模型能均分上 0.8。差距不是被几个变态场景拉出来的，是普遍性的。

发现二：真正的断崖在"约束没人说"，不在"需求指错路"

这是全文最反直觉的结果，也是作者自己承认赌错了的地方。

看主表左半边：给全规则（L0）时头部三模型 0.73–0.82；到了 L1，问题还是说清楚了、但约束要自己找，分数直接掉到 0.39–0.62——平均掉 0.28（95% 区间 0.17–0.39）。但从 L1 到 L3，需求从"说清楚的问题"退化成"模糊"再退化成"可能指错路"，分数只再掉 0.04（区间 -0.03 到 0.14），基本持平。

作者的原话大意：我们本来以为问题定义才是瓶颈——给个错误的需求，Agent 会造出错误的系统。数据不支持这个假设。他们的解释是：一旦模型被迫去找约束，它顺着文档和干系人摸下去，往往也顺带搞明白了赞助人到底想要什么。整个交付环境里有太多东西在"反驳"那个错误的需求。

我琢磨了一下，这个解释说得通，但也可能有个更平庸的版本：L1 已经把"主动探查"这个动作筛选出来了，能过 L1 的模型本来就会自己核实需求。不管怎样，结论对工程很重要——当前模型的短板不是"怀疑客户"，而是把没人明说的约束挖出来这件事。

掉分由两部分构成：交付的系统本身变差了（从参考增益的 0.81–0.90 掉到 0.63–0.80），加上找约束要付出代价——每任务提问数从 3.9–7.0 涨到 11.3–13.0，联系成本从 0.07–0.10 涨到 0.18–0.24。

发现三：问到答案 ≠ 能交付

头部三模型在 L3 每个任务问 10.0–12.3 个问题，拿到了 72–85% 的关键事实。然后呢？交付的系统只实现参考增益的 0.60–0.70。

更扎心的是那 73 个"事实全拿到"的任务-模型组合：平均业务增益只有 0.66，增益上 0.8 的只有 27 个（37%）。Claude Opus 5.5 有 23 个任务拿全了所有关键事实，只有 10 个增益达标。

还有联系成本这把刀。GPT-6 Astra 交付的系统有 36 个任务增益上 0.8，扣掉联系成本后只剩 9 个算"解决"；Opus 5.5 是 40 变 14。智能体不知道提问要花钱，于是问得好像提问免费一样——Opus 5.5 的 0.70 增益被联系成本吃掉 0.14，GPT-6 Astra 的 0.60 被吃掉 0.22。

这个设计戳中了一个真实痛点：问客户问题是有代价的，不只是钱，还有对方的耐心和你的专业信誉。一个把客户每个干系人都骚扰一遍的 FDE，在现实中活不过第二个项目。

发现四：弱模型的期望贡献是负的

零分不是地板。Claude Haiku 4.5 有 79/95 个任务得分低于"什么都不做"；Mistral Small 4 在扣联系成本之前就有 51 个任务的系统是负收益，其中 23 个任务造成的伤害比参考方案带来的收益还大。开 thinking 也没用：Haiku 4.5 不开是 -0.33，开了 -0.35。

图 5：13 个配置在 95 个任务上的分数带分布。红色段是"不如不做"的任务数——头部模型只有个位数，而尾部模型几乎全线飘红。0.2 以下的分数对应着"照章办事"的字面解上限。

作者的点评很直白：对采购方来说，弱 Agent 不是强 Agent 的廉价版，它在这些任务上的期望贡献是负的。这句话值得打印出来贴在每个想"先上个便宜模型试试水"的立项会上。

发现五：烧钱和烧轮次都不等于高分

GPT-6.1 Sol 每轮花 0.24 美元、25 轮交卷，得 0.37；Gemini 3.8 Flash 花 1.54 美元、121 轮，得 0.19。Qwen 3.8 Flash 最能熬——平均 169 轮、110 分钟，152 个任务-级别组合里只有 11 个在限额内提交，最终 0.07 分。头部三模型全部组合按时交卷，26–60 轮收工。

知道什么时候活干完了，本身就是交付能力的一部分。这话听起来像鸡汤，但数据摆在这。

跨基准对比：组件能力强 ≠ 能交付

作者用 Vals AI 的公开数据对比了 Terminal-Bench 2.1、Vibe Code Bench、Finance Agent：在组件类基准上能解决 88%、90%、61% 任务的模型们，到 FDE-Gym 上只有 0.19–0.56，最强的 Opus 5.5 只解决 15% 的任务。作者特意声明两类指标不同、不直接可比，但结论方向很清楚——模型在组件基准上的表现，对预测它能不能给客户交付价值，是个很弱的信号。

🤔 我的判断

这篇论文最值钱的地方在哪？

我觉得不是 95 个任务本身，而是它把"交付"拆成了一条因果链：判断需求对不对 → 挖出没人说的约束 → 设计并落地方案 → 集成进活系统 → 在客户自己的 KPI 上见效，然后用 L0–L3 的对照设计告诉你在哪里断。之前每个环节都有单独的基准（TheAgentCompany 测企业任务、LHAW 测信息缺失、τ-bench 测交付后评估、SWE-bench 测写码），但把它们串成"看错问题会让好代码一文不值、损失直接体现在业务指标上"的完整链条，这是头一个。

有几个地方要泼冷水。

一，干系人是脚本化的。换来可复现性，丢掉的是真人会改主意、会答非所问、会看心情——作者自己在 Limitations 里也承认了。所以这个基准测的是"交付能力的下界环境"，真人只会更难搞。

二，联系成本是专家拍脑袋设的费率，是"干系人时间成本的模型"，不是测量值。C 的绝对值是否校准合理，会直接影响 Finding 3 里"36 变 9"这种结论的锐度。

三，L0–L2 只在 20 个原始任务上报，其中 3 个场景的 L2 直接复用 L3 结果。样本量不大，作者也只敢声称"L1 之后没有可见的大幅下降"。这个克制态度本身倒是加分项。

四，也是最重要的——现在还没有人类基线。人类专家在 L3 设定下能拿多少分正在线上平台采集。如果人类 FDE 也只能拿 0.6，那"最后一公里"的叙事就要重新审视了：也许不是 AI 不行，是这活儿本来就难。我挺期待那个数字的。

对工程的启发：

• 如果你在卖/部署企业 Agent，这个基准是个现成的体检表——你的方案在"需求模糊、约束不明说、提问有成本"的设定下还剩多少分？
• "字面解封顶 0.2"这个锚点设计可以直接抄：任何声称评估真实能力的基准，都应该先验证照章办事能得几分。
• 联系成本机制提醒所有 Agent 产品设计者：无节制的工具调用和提问本身就是一种交付失败。

📝 收尾

行业里有个说法，AI demos 和 AI 产品之间隔着一整个交付团队。FDE-Gym 做的事，是把这道鸿沟第一次变成了可测量的数字：一个任务一个分数，用客户自己的尺子量，人和 Agent 同一套规则。0.56 这个数字不好看，但一个诚实的 0.56 比十个刷到 95% 的榜单更能推动行业往前走。

顺带一提，他们还开了个在线平台（fde-gym.com），人类可以用和 Agent 完全相同的评分标准练手。我已经想去试试自己能不能打过 Opus 了。

参考资料

• 论文：https://arxiv.org/abs/2610.22350
• 代码：https://github.com/deeplethe/fde-gym
• 数据：https://huggingface.co/datasets/DeepLethe/FDE-Gym
• 官网与在线平台：https://fde-gym.com/paper

觉得有启发的话，欢迎点赞、在看、转发。跟进最新AI前沿，关注我