FDE-Gym 论文详解：AI 交付的最后一公里
论文：FDE-Gym: The Last Mile of AI Delivery，arXiv:2610.22350，2026-10-15 作者：26 人，DeepLethe 牵头 + 清华/上交/北航等高校 + 华为/Meta/微软亚洲研究院等 提炼：2026-10-17，小沐（基于全文 14 页）
一、文摘（Abstract 中文翻译）
现有的 agent 评测通常只测定义清晰的任务（issue 报告、spec、工单）。但真实的客户交付完全不同：前置部署工程师（FDE）必须澄清模糊的需求、在真实系统上干活、挖出没说出来的约束。
为此我们提出 FDE-Gym：95 个端到端交付任务，来自 20 个客户场景、18 个行业，均由行业专家从真实交付项目改造而来。在模拟客户环境中（脚本化 stakeholders + 可修改的客户系统），agent 与 stakeholders 互动、在类生产系统上操作，交付可运行的方案。
评分不只看”做完没有”，而看交付系统让客户自己的业务指标改善了多少（0=没动，1=参考方案）；与 stakeholder 的互动要扣费（发消息、试运行、等待时间），防止无节制骚扰。FDE-Gym 还提供在线平台，让人类用同一套标准练习 FDE 技能。
我们测了 13 个模型配置（7 家 providers）。在真实设定下（隐性约束必须自己发现），最好的配置平均分只有 0.56，95 个任务只真正解决了 14 个（≥0.8 分且无事故）。发现隐性约束是主要瓶颈：需要自己挖约束时，分数断崖式下跌。但光拿到信息还不够：即使在最强配置拿全关键事实的 23 个任务里，也只有 10 个达到了 0.8 以上的业务提升。
结论：解”定义好的题”和”给真实客户交付有效系统”之间，有巨大鸿沟。
二、详细总结
2.1 为什么做这个 benchmark
开篇举了个例子：某钻井公司的 VP 想要”给董事会的生成式 AI 成功故事”，要求每天一封摘要邮件 + “问你的油井”聊天框，还特意说停机编码系统不在项目范围内。
但照字面做出来，功能全过，却对客户业务指标零改善。真正的瓶颈在每月的停机信用索赔：现有关键词脚本把部分停机错误归因给承包商，每月至少一条争议，整月信用被暂停。要修就必须动 VP 明确排除在外的停机编码系统——得找到适用合同条款、跟成本工程师确认解释、再找那个这周不在的审批人签字。
这就是 FDE 的日常：客户要的，未必是客户需要的。
2.2 怎么测（方法论）
任务结构：每个任务 = 1 个客户 + 1 个 sponsor（派活的人）+ 1 套生产系统。Agent 起手只有 sponsor 的一句话需求、一份客户生产系统的拷贝、相关文档历史数据、一份带联系方式的员工通讯录。标准 Python + SQLite 环境，不许装包、不许上外网。
四个指令级别（环境、stakeholders、评分标准完全一样，只变指令）：
- L0： underlying problem、适用规则、评分标准全给 → 只考”会不会做”
- L1：问题说清楚，规则约束自己挖
- L2：需求含糊但方向对
- L3：sponsor 原始需求（可能指向错误的问题）→ 还要先判断”这需求对不对”
L3 是主评测设定（最接近真实交付），覆盖全部 95 个任务。
评分公式：S = Uadj − C
- U = 归一化业务提升（交付后 KPI − 基线）/（参考方案 KPI − 基线）；0=没改善，1=达到专家参考方案，<0=不如不做
- Uadj：出了预定义 operational incident（如越权操作），正提升清零、负提升保留
- C = stakeholder 接触成本：每个 stakeholder 有隐藏的”每条消息价格”，问烦了或违反联系限制更贵；试运行、等待天数也收费
- 任务算”解决”：S ≥ 0.8 且无 incident
防作弊四锚点（每个任务必须满足）：
- 专家参考方案 ≥0.95
- do-nothing 基线 = 0
- 照字面执行 sponsor 要求 ≤0.2（即使 sponsor 需求是对的，漏掉约束也做不好；唯一的例外是需求本身完整正确，此时字面解=参考解）
- 走捷径（过拟合历史数据、猜整数阈值、把不确定的全推给人）≤0.8；试图绕过客户管控或操纵评分直接接近 0 分
20 个场景（18 行业）：银行反诈、建筑分包付款、校园订场、EV 充电客服、物业维修、资管对账、电网结算、物流招聘、医院分诊、电商合规、物流售后、制造 ChatBI、新闻快讯、石油钻井、oncall 响应、医保预授权、制造营收争议、科研文献筛选、仓库机器人、水库调度。
130+ 脚本化 stakeholders：知识、误解、披露信息的条件都是预设的；有耐心上限、要证据、先聊 A 才能聊 B、临时不在、联系限制。Agent 得从文档里自己推断”该找谁、怎么找”。
2.3 五个发现
发现 1：最好的模型离参考方案还差得远 L3 上 Claude Opus 5.5 平均 0.56（最高），Sonnet 5.5 0.49，GPT-6 Astra 0.38。95 个任务最多解决 14 个，5 个配置一个都解决不了。即使每个任务都选 13 个配置里最好的那个，平均也只有 0.70，解决 30 个——16 个任务没有任何配置超过 0.5。
发现 2：挖隐性约束是最大的断崖 同样 20 个原始任务：L0（规则全给）三个头部模型 0.73–0.82；L1（规则自己挖）掉到 0.39–0.62，光这一步就掉 0.28。而 L1→L3（需求从清楚变模糊再变跑偏）只再掉 0.04。也就是说：瓶颈不是”需求跑偏”，而是”约束没写出来”。一旦要自己挖约束，模型顺带也就搞清了 sponsor 真正要什么。
发现 3：拿到事实 ≠ 交出有效系统 头部模型平均问 10–12 个问题，拿到 72–85% 的关键事实，但交付系统只有参考方案 60–70% 的业务提升。即使在”拿全所有关键事实”的 23 个任务里，也只有 10 个达到 0.8。信息 discovery 只是第一步，把事实变成有效系统是第二道坎。另外 contact cost 再扣 0.14–0.22——模型问问题时当不要钱，实际很贵。
发现 4：弱模型不如不做 Claude Haiku 4.5 在 79/95 个任务上不如 do-nothing（比如该拒赔的赔了、钱算错对象、半夜叫错工程师）。买家的实操含义：弱 agent 不是”便宜版强 agent”，它的期望贡献是负的。
发现 5：没有全能选手，花钱多 ≠ 分高 5 个场景没有任何模型平均过 0.5；同一场景换一组关键事实，头部模型分数波动中位数 0.34–0.44。GPT-6.1 Sol 花 $0.24/25 turns 得 0.37，Gemini 3.8 Flash 花 $1.54/121 turns 得 0.19。知道什么时候算”做完了”本身就是能力。
2.4 和其他 benchmark 的对比
在 Terminal-Bench（88%）、Vibe Code Bench（90%）、Finance Agent（61%）上高分的模型，在 FDE-Gym 上只有 0.19–0.56。会写代码 ≠ 会交付：同样的模型，解七道工程题能对六道，但七个客户交付里最多做好一个。
2.5 局限（作者自己承认的）
- stakeholders 是脚本化的，真人更不可预测（变卦、答非所问）
- L0–L2 只在 20 个原始任务上测，样本小
- 还没有人类基线（正在 fde-gym.com 上收集专家数据，以后发）
- 所有模型用同一套极简 agent 框架，结论是对”模型+该框架”，不是对产品
- 20 个场景偏向受监管行业的 agent/workflow
三、对职业发展的启示（小沐解读）
-
你的护城河被量化了：0.56 vs 1.0 之间的 0.44 差距，就是”有经验的工程师” vs “AI”的价值差——主要来自三件事：挖隐性约束、把事实变成贴合组织的系统、控制 stakeholder 成本。这三件恰好是你 10 年企业架构 + Ping 身份专家经验里最强的部分。
-
FDE 的 JD 可以照着写：论文把 FDE 的能力拆成了可测量的维度——需求澄清、约束发现、系统交付、业务指标导向、stakeholder 管理。你面 AI Solutions Architect 时，可以按这个框架讲自己的项目经历，比空说”我懂业务”有力得多。
-
fde-gym.com 在线平台：人类可以用同一套标准练手、跟 AI 同场比。等人类基线出来后，值得去做几个任务——一是验证自己的水平，二是简历上可以写。
-
给客户的 pitch 话术：以后跟业务方聊 AI 落地，可以直接引用这篇：”MIT 式的 benchmark 上 90 分的模型，真实交付只能拿 56 分，弱的还不如不做——所以需要有人把最后一公里走完。” 这句话比任何技术术语都管用。
-
注意时间窗口：论文 2026-10-15 刚发，结论还新鲜。现在正是”AI 交付最后一公里”这个叙事刚起来的阶段，你提前占位，比等所有人都知道再说要主动。
原文：https://arxiv.org/abs/2610.22350（PDF：https://arxiv.org/pdf/2610.22350） 解读帖：https://x.com/Xudong07452910/status/2111306709318951189