FDE-Gym 论文详解：AI 交付的最后一公里

← 返回目录

原文：FDE-Gym: The Last Mile of AI Delivery，arXiv:2610.22350，2026-10-15 提交 原文链接：https://arxiv.org/abs/2610.22350 （全文 HTML：https://arxiv.org/html/2610.22350v1） 作者：Dongxu Yang 等 26 人，第一单位 DeepLethe，含清华、上交、华为、Meta、Microsoft Research Asia 等 覆盖范围：正文 §1–§8、Table 1–4、公式（1)–(5)、Limitations 与利益披露全部读到；图表只读到 caption 与正文引用，图内像素级数据未逐图核；参考文献列表只扫标题未逐条读。 结构：前半导读（故事与判断，旧版叙事语气），后半精读（机制、数据与证据边界，重读版口径）。2026-10-27 混合定稿。

价值判断：值得 Stone 精读——这是他学习清单里与 AI Solutions Architect 岗位距离最近的一篇：它把”交付判断力”拆成了可测量的数字，而且其中三条结论直接落在他自己的三个项目上（thinktank 的成本纪律、open-memex 的复用价值、opencode-fuse 的档位风险）。

一句话结论

当前最强的模型在”把定义好的题做对”上已经很强，但在一场真实客户交付里——需求可能指错问题、关键约束没人写下来、每次问客户都要付费——平均只能拿到专家参考方案 56% 的业务改善；差距主要不来自”被错误需求带偏”，而来自”没写出来的约束挖不到、挖到了也翻译不成有效系统、以及提问本身的成本”。

为什么值得看

• 对他的职业线：论文把 FDE（forward-deployed engineer）的核心能力拆成可测维度（问题澄清、约束发现、系统构建、stakeholder 成本控制），这正是 AI Solutions Architect 面试里最难自证的部分，这篇给了他一套有数字的语言。
• 对 thinktank：论文的评分公式里，stakeholder contact cost 是直接从总分扣的一等项（§2.3）——”提问不是免费的”被量化了，与他给智囊团设的 estimate 与熔断是同一个思想的外部证据。
• 对 open-memex：约束与事实散落在文档、数据和 130 多个 stakeholder 脑子里，且会过期、互相矛盾（§3.3、§6 表 4 Discovery 行）；”查过的事实不要再付费问第二次”就是记忆系统的经济价值。
• 对 opencode-fuse：弱模型在这套任务上的期望贡献是负数（§5.4），三档路由里便宜档的风险不是”慢”，是”把客户做坏”。

叙事主线

论文开篇是一个真实改编的案例。某钻井公司的 VP 想要”给董事会的生成式 AI 成功故事”：每天一封摘要邮件，加一个 “Ask your wells” 聊天框，还特意说停机编码系统不在项目范围内。

照字面做出来，功能全过，却对客户业务指标零改善。真正的瓶颈在每月的停机信用索赔：现有关键词脚本把部分停机错误归因给承包商，每月至少一条争议，整月信用被暂停。要修，就必须动 VP 明确排除在外的停机编码系统——得找到适用合同条款、跟成本工程师确认解释、再找那个这周不在的审批人签字。

这就是 FDE 的日常：客户要的，未必是客户需要的。

作者改的不是模型、不是框架，而是”评分的对象”。不再测任务完成率，而是测交付系统在 held-out 生产数据上把客户自己的业务指标改善了多少，并把”打扰客户”计价扣分；再用四个 admission anchors 卡住每个任务的量表，让”照字面做”最高只能拿 0.2、”走捷径”最高 0.8。L0–L3 四档指令（环境与评分不变、只递减指令里的信息量）把”实现不行、约束没挖到、问题被指错”三种失败分开称重。

量表一换，排行榜就塌了：在 Terminal-Bench、Vibe Code Bench、Finance Agent 上能做到 88%、90%、61% 成功率的模型，在 FDE-Gym 上只有 0.19–0.56。而且降幅定位出乎作者自己预料：他们原假设瓶颈是”问题定义”，数据不支持——真正的坎是没写出来的约束。

核心机制 / 数据

1. 评分公式：S = U_adj − C（§2.3，公式 4)。U 是 normalized business uplift：交付系统相对 do-nothing 基线、向专家参考方案改善的比例（公式 1)；出了预定义 incident（如越权操作），正提升清零、负提升保留（公式 2)；C 是 stakeholder contact cost：每个 stakeholder 有隐藏的单条消息价，超耐心或违反联系限制加价，试运行与等待天数也计费（公式 3、§2.3)。S ≥ 0.8 且无 incident 才算 resolved（§2.3)。

2. 头部成绩：主设定 L3 下 Claude Opus 5.5 平均分最高，0.56（95% CI 0.50–0.62)，U = 0.70、C = 0.14、resolved 14 个（Table 3、§5.1)。一个容易看漏的细节：Claude Sonnet 5.5 平均分 0.49 低于 Opus，但 resolved 数是 15 个，反而多 1 个（Table 3）——”平均分最高”与”解决任务最多”不是同一个配置。把 13 个配置逐任务取最优，oracle 上限也只有 0.70、30 个 resolved（§5.1)。

3. 最大的降幅在约束，不在需求跑偏：同样 20 个原始任务上，L0（规则全给）到 L1（问题清楚、约束自己挖）平均掉 0.28（95% CI 0.17–0.39)；L1 到 L3（需求变模糊、再变指错问题）只掉 0.04（CI −0.03–0.14)(§5.2)。头部模型 L0 能到 0.73–0.82、解决 11–13/20;L1 掉到 0.39–0.62、只解决 1–7(§5.2)。

4. 知道 ≠ 做到，且提问要付钱：L3 下头部模型平均每任务问 10.0–12.3 个问题、拿到 72–85% 的关键事实，交付 uplift 却只有 0.60–0.70(§5.3)；Opus 在 23 个任务上拿全了每一个关键事实，其中 uplift ≥ 0.8 的只有 10 个（§5.3)。Contact cost 吃掉 uplift 的 0.14–0.22（Table 3、§5.3)；GPT-6 Astra 有 36 个任务 uplift 达 0.8，扣完联系成本只剩 9 个 resolved（§5.3）——模型问问题时”当作不要钱”（§5.3 原文：agents ask as if questions were free）。

5. 弱模型是负资产，花钱多不等于分高：Claude Haiku 4.5 在 79/95 个任务上低于 do-nothing 基线，给它加 extended thinking 反而从 −0.33 掉到 −0.35(§5.4、Table 3)；Mistral Small 4 交付的系统本体（还没扣联系成本）就在 51 个任务上低于基线（§5.4)。成本侧：GPT-6.1 Sol 每 run 花 $0.24、25 turns 得 0.37;Gemini 3.8 Flash 花 $1.54、121 turns 只得 0.19;Qwen 3.8 Flash 跑 169 turns、110 分钟，152 个组合里只按时提交 11 个（§5.6)。实验协议供参照：每个 run 上限 200 turns / 150 分钟 / $8 模型费用，每题跑 3 次取平均，全研究共 1,976 个组合（§4）。

增量（相对 Stone 已有认知与项目）

• 修正一个流行叙事：通常说法是”agent 死在需求模糊、被客户带偏”。这篇的数据说，对头部模型，把需求从清楚降到指错问题（L1→L3）几乎不掉分（0.04，§5.2)；真正的坎是没写出来的约束。和他自己的经验同构：thinktank 评审里，问题文本写得再全（相当于 L0/L1)，framing 里没人写下的约束（真实目标、历史包袱、谁说了算）才是翻车点——他给陪审团喂数据的做法是在把任务往 L0 推，但真实客户场景里没人替他做这一步。
• thinktank 的成本纪律有了外部标尺：FDE-Gym 里联系成本吃掉 uplift 的两到三成（0.14/0.70、0.22/0.60，§5.3)。他的 tt-go estimate + 熔断本质上是在给”问几个模型、问多深”定价；这篇提示下一步可以把”发现约束的成本”也纳入裁决质量评估——陪审团答得对但太贵，净分是要扣的。
• open-memex 的价值主张可以量化着说：约束发现是主要成本项，而事实会散落、过期、互相矛盾（§3.3、§6）。记忆系统的卖点不是”记得多”，是”同一个约束不付第二次发现成本”——这与他定的捕获哲学”只记有价值的”正好咬合：值得记的就是下次还要付费才能再发现的东西。
• opencode-fuse 的档位警告：§5.4 的结论”弱 agent 不是便宜版强 agent，期望贡献是负的”，对三档自动选档是直接约束——降档省下的钱可能被负 uplift 吃掉还倒贴。这与他在 thinktank 模型档案里记的”掉档提醒”是同一件事的两个战场。
• 面试可直接引用的三个数字：0.56（最强配置的交付均分，Table 3)、0.28（约束被扣下时的降幅，§5.2)、”七个 engagement 最多做好一个”（§5.7 对 resolved 比例的客户语言翻译）。

证据不支持什么

• 不支持”AI 不会澄清需求”这个流行结论（至少对头部模型）：作者原假设就是问题定义是瓶颈，自己的数据推翻了自己（§5.2)。把这篇引成”模型被错误需求带偏”的人，多半没读 §5.2。
• 不支持”agent 不如人类 FDE”：人类基线还在收集中，本版只有模型数据（§3.5、§7)；量表两端只有 do-nothing = 0 与 reference = 1 两个锚，”人类能到多少”未测。
• 不支持把分数外推到成品 agent 产品：13 个配置全部跑在同一套极简框架（5 个工具、无模型专属适配）里（§4)，作者明说结果是”模型 × 该框架”，更强的框架可能改变分数与排名（§7)。
• 不支持把 contact cost 当现实价格：每个 stakeholder 的费率由场景专家设定，是成本模型不是实测（§7)；stakeholders 是脚本化的，真人会变卦、答非所问、受前序对话影响（§7)。
• 跨 benchmark 对比要打折：88%/90% 与 0.56 量纲不同（成功率 vs 归一化 uplift)，作者自己声明只是并置、不可直接比（§5.7)；引用”90 分变 56 分”时要带上这句。
• 摘要与正文有一处口径出入：摘要称最佳配置”解决了 14 个”任务，那是 Opus 5.5 的 resolved 数；按 Table 3，Sonnet 5.5 的 resolved 是 15 个，为全表最多。引用”最多解决几个”时按 Table 3 口径，不用摘要口径（详见下方 Abstract 全译节的译注）。
• 独立性提示：在线平台与 leaderboard 由 benchmark 作者 DeepLethe 运营，论文在 Acknowledgments 里做了利益披露，并声明受测模型无作者关联方的产品；这不是造假证据，但引用排名时应知道运营方是谁。
• 覆盖边界：L0–L2 只在 20 个原始任务上测，L1–L3 之间差异不显著，作者只声称”没看到大的进一步降幅”（§7)；场景取样偏受监管行业的 agent/workflow，且不能完全排除训练数据污染（§7)。

术语台账

• FDE（forward-deployed engineer）：厂商派驻客户组织的工程师，职责不止照单施工，还要判断什么才真正对客户有用（§1）。
• sponsor：客户方派活的人，其原始需求可能指错问题（§2）。
• stakeholder：客户方干系人，掌握事实与约束，回应是脚本化的，接触要计价（§3.3、§2.3)。
• task instruction level（L0–L3）：同一任务的四档指令信息量，L0 全给、L3 只给 sponsor 原始需求（Table 1、§2.2)。
• normalized business uplift（U）：交付对客户业务指标的改善，按 基线 0、参考方案 1 归一化（§2.3，公式 1)。
• incident：预定义的运营事故（如越权操作），触发后正提升清零（§2.3，公式 2)。
• stakeholder contact cost（C）：发消息、试运行、等待的合计费用，与 U 同量纲扣分（§2.3，公式 3)。
• do-nothing baseline：什么都不改的现有系统，U 与 S 的零点（§2.3、§3.4)。
• reference solution：专家写的参考解，锚点要求其得分 ≥ 0.95（§3.4)。
• literal solution：完全照指令字面做的解，锚点要求其得分 ≤ 0.2（§3.4)。
• admission anchors：每个任务入选前必须同时满足的四个分数量表条件（§3.4)。
• variant：同一场景改动关键事实（哪条规则过期、谁握有信息、需求是否指错）生成的任务，防背题（§3.2)。
• resolved：单任务 S ≥ 0.8 且无 incident（§2.3)。

细读指引

• 精读 §1：钻井案例是全文唯一完整的 engagement 还原，看懂它，后面的量表设计都好懂（原文真实案例改编，非假想）。
• 精读 §2.3 + §3.4：评分公式与四锚点。他以后设计 thinktank 的裁决评分、防”照字面讨好”的锚点时，这是现成的参照系。
• 精读 §5.2 + §5.3：全文的数据核心——降幅定位（0.28 vs 0.04）与”知道 ≠ 做到”，引用这篇时最容易引错的就是这两节。
• 扫读 §7：Limitations 写得诚实，引用前先知道边界在哪。
• 可跳：§6 的 Table 4 逐项对照、References 40 条、§5.5 的逐场景细节（除非要查某个具体行业的分数，再回来翻 Figure 7 / Table 2）。

读完正文后按惯例验收：小沐会用 local-questioning 追问三层（这篇的量表为什么这样设计 / L0–L3 是怎么把三种失败分开的 / 这套评测的 trade-off 与盲区），不用你开口要求。

按长期要求：Abstract 中文全译

［说明：以下为旧版（2026-10-17）的文摘翻译，本次合并恢复。译文忠实摘要原文、数字不私自改动；与正文口径不一致处在译文后加译注标注。］

现有的 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 以上的业务提升。

［译注：摘要原文的”解决了 14 个”是最佳配置 Claude Opus 5.5 的 resolved 数；按正文 Table 3，Claude Sonnet 5.5 实际 resolved 15 个，为全部配置中最多——因此”最多解决 14 个”的说法不成立，本稿核心机制与证据两节均按 Table 3 口径。摘要其余数字（13 个配置、0.56 均分、23 个任务拿全事实其中 10 个达 0.8）与正文 §5.1、§5.3 一致。］

结论：解”定义好的题”和”给真实客户交付有效系统”之间，有巨大鸿沟。

按长期要求：职业启示

［说明：旧版有 5 点启示，本次只保留能直接挂住论文证据的 3 条；每条末尾括注依据。］

1. 你的护城河被量化了：最强配置 0.56 与参考方案 1.0 之间的差距，主要由三件事构成——挖出没写出来的隐性约束、把拿到的事实翻译成有效的系统、控制打扰客户的成本。这正是企业架构与交付经验的价值所在，论文把它从”我觉得重要”变成了可测的降幅构成。（依据：§5.2 约束被扣下时平均降幅 0.28、为全表最大；§5.3 拿全事实的 23 个任务只有 10 个 uplift 达 0.8；§2.3、§5.3 contact cost 扣掉 uplift 的 0.14–0.22）
2. FDE 的能力维度可以照着用作面试框架：论文把交付能力拆成问题澄清、约束发现、系统构建、业务指标导向、stakeholder 管理等可测维度；面 AI Solutions Architect 时按这个框架讲自己的项目经历，比空说”我懂业务”有力得多。（依据：§2 的任务与评分设计、§3.4 的 admission anchors 即按这些维度构造量表）
3. 在线平台值得去练手：FDE-Gym 提供在线平台，让人类用与模型完全相同的标准做任务、练 FDE 技能；人类基线尚在收集，此时去做几个任务既是自测，也能在人类对比数据出来之前先占一个参照点。（依据：摘要与 §3.5 所述在线平台；§7 人类基线仍在收集中）