OpenAI 的 FDE 含义：前沿部署工程与部署差距

OpenAI 的前沿部署工程（FDE）团队旨在弥合“部署差距”——即模型表面上具备的能力与人们实际能可靠用于工作的能力之间的差距——并且该团队通过随着产品和模型的改进而让自己变得过时来衡量自身的成功。在一篇发布于 2026-10-22 的第一人称文章中，该团队的创始人解释了与 John Deere、一家大型半导体制造商、一家电信公司以及 Thrive Holdings 等客户的 FDE 合作如何将棘手且未解决的问题转化为生产系统、可复用的基于 Codex 的软件包，以及 OpenAI 研究部门需要填补的具体能力差距。

OpenAI 的 FDE 含义，用一段话概括

OpenAI 的前沿部署工程是与客户并肩工作，理解他们最棘手的问题，并构建他们可以在生产中依赖的解决方案的职能部门。该团队成立于 2025 年初，旨在弥合部署差距：模型能力的发展速度超过了将其投入使用所需的系统和流程。有时缺失的部分是一个产品；有时模型在基准测试中表现良好，但在现实变量和约束下却无法胜任工作。FDE 所学到的经验会反馈到 OpenAI 的产品中，并为研究部门提供具体的问题来解决。

该团队的既定目标是每次合作都为下一个客户留下更好的起点。正如文章所说：“如果我们把门槛提高到客户下次不需要 FDE 就能解决这类问题的程度，我们就做好了我们的工作。”

为什么 OpenAI 说 FDE 的工作应该变得过时

文章以一位同事在 Codex 发布时提出的问题开头：“当 Codex 能一次性解决我们过去几个月构建的用例时，我们该怎么办？”作者的回答是，这是进步，而不是威胁。

如果我们每隔几个月就让自己过时，我们的 FDE 团队就尽到了职责。

文章指出了团队让自己过时的两种不同方式。第一种是当更好的产品让 OpenAI 能够替换定制实现，同时保留其带来的价值时。第二种是当 FDE 帮助将当今模型无法解决的问题转化为未来模型能够提供的能力时。

操作原则：从结果出发

每次 FDE 团队会议都以一张幻灯片开始，上面写着一条核心价值观：“从结果出发，不惜一切代价取得成功，然后追求规模。”其理由是，一个令人印象深刻的演示可以在有人问它是否在现实世界中有效之前发挥很大作用，而团队的工作是将客户的问题解决到可以在生产中站得住脚的标准。

文章直言不讳地说明了为什么这很难：问题往往是开放式的，可能没有既定的基本事实，也没有现成的剧本。“每个人都想构建从未存在过的东西。但很少有人愿意付出努力去实现它。”

案例研究：约 15 名 FDE 在 10 多个用例中进行半导体验证

2025 年年中，大约 15 名 OpenAI FDE 与一家大型半导体客户在 10 多个用例上合作，目标是使客户的验证流程实现 AI 原生。在该行业，验证可能占项目工作量的约 70%。工作涵盖三个领域：

• 定向测试生成
• 根本原因分析和调试
• 架构助手

一些 FDE 几天前才加入 OpenAI，从未接触过半导体。他们嵌入客户的验证团队，利用业余时间学习芯片设计，并与客户的工程师一起构建评估，以测试 AI 是否能生成有用的测试并正确诊断芯片故障。在学习的同时，OpenAI 为各个用例构建了定制工具。在最初的 3-6 个月内，所有这些都达到了生产阶段并获得了早期用户采用。

报告的结果是：

• 通过基于 AI 的定向测试生成，节省了约 48% 的时间
• 通过内核优化，中位性能提升了 22%
• 数周的调试压缩到数小时

当结果反馈给客户时，客户的首席硬件官问道：“你们来之前是芯片设计师吗？”文章的结论是：“我们的 FDE 不需要在第一天就了解行业，但学习行业是他们的责任。”

领域专业知识被视为招聘要求，而非可有可无

文章认为，随着编码助手使软件构建更快，理解客户的业务变得更加重要。OpenAI 组建 FDE 团队时，混合了通才和领域专家，理由是既需要足够的知识来做出明智的判断，也需要足够的好奇心来质疑现状假设。

例如，在生命科学领域，FDE 的科学背景帮助他们赢得研究人员的信任，这些研究人员从事临床前药物发现任务，如靶点验证和优先级排序、基因表达分析以及化学合成路线重建。这种专业知识使他们能够就这些工作流程如何改进提供明智的判断。

FDE 如何通过 Codex、技能和 MCP 使成功可重复

一旦半导体工作流程带来了价值，每个流程仍然需要太多定制集成才能扩展到另一个团队。下一个挑战是在使软件更易于部署和维护的同时保留结果。

到那时，Codex 的能力已经增强。一位 FDE 测试了围绕它重建应用程序，然后与团队合作，将用例迁移到以 Codex 为核心的通用工具上。定制应用程序变成了基于通用 Codex 原语构建的插件和技能。Codex 也成为了界面，使 OpenAI 能够淘汰为各个用例编写的独立终端 UI 和 CLI。

团队能够从每个项目中移除约 90% 的定制代码。根据文章，这以三种方式改变了工作流程的构建、维护和扩展：

• 对 Codex 的集中改进减少了个别用例所需的粘合代码量。
• 关键功能被打包为技能和插件，使其更易于共享，并由客户的 AI 卓越中心集中控制。从一个团队扩展到下一个团队可能就像更换新的连接器或 MCP 服务器、构建新的评估（团队也有相应的技能）并快速启动一样简单。
• 入职速度显著加快。在 2026 年 8 月的一个例子中，初始部署花了两个月，而将解决方案扩展到第二个团队只花了一天。

文章总结了这背后的排序原则：“LLM 让我们快速构建。利用这种速度将有价值的东西交到用户手中，了解在实践中什么有效，然后扩展有效的方法。”

OpenAI Presence 源于客户部署

OpenAI Presence，该公司的企业语音和聊天代理产品，源于真实的客户部署。这项工作始于 Swarm，并通过 Agents API 发展。如今，一个客户超过一半的电话由 AI 处理。

将这些部署投入生产教会了 OpenAI 哪些问题需要定制解决方案，哪些构建块可以被其他团队使用。这些构建块被引入 Presence，使开发人员更容易自动化受监管的工作流程，而无需重建底层基础设施。

案例研究：Thrive Holdings 的 Tax AI 在试点中处理了 7,000 份申报表

与 Thrive Holdings 合作，OpenAI FDE 和研究人员与工程师和会计师并肩工作，为克里特岛的会计师事务所构建了 Tax AI。在试点期间，Tax AI 处理了 7,000 份纳税申报表，吞吐量提高了约 50%。

最困难的挑战之一是自动化租赁物业申报，这需要六周的工程和从业者审查才能达到 90% 的精确度和召回率。这项工作创造了可复用的模式，使将 Tax AI 扩展到其他复杂的税务附表变得更加容易。团队现在正在将同样的方法应用于簿记、审计和 IT 支持，构建通过从业者反馈和实际使用而改进的系统。

案例研究：将语音模型智能差距从约 60% 缩小到 90% 以上

有时更好的产品让 FDE 简化其构建；有时模型本身还无法胜任工作。文章认为，如果 OpenAI 只构建当今模型已经可能实现的东西，它就不会发现研究部门下一步需要填补的智能差距。因此，许多重要的合作始于这些极限，客户、FDE 和研究部门共同致力于解决这些问题。

一家大型电信客户已经与 OpenAI 开发了一个客户服务平台，并希望将其扩展到语音。语音约占该客户客服量的 90%，这些案例比聊天更难处理，并且带来了新的技术挑战，如口音、语气和延迟/准确性达到生产标准。

在范围界定期间，模型在用于评估其能否在生产中胜任工作的关键评估上得分约为 60%——这是其能力的极限。客户服务场景中的函数调用和指令遵循需要改进。OpenAI 向客户解释了这一点，并将研究部门引入工作：FDE 与客户一起构建平台并定义模型需要做什么，而研究部门则致力于缩小能力差距，通过连续的模型快照让团队根据客户要求测试进展。

在六个月内，关键评估的性能从约 60% 上升到 80%，然后上升到 90% 以上，达到了生产所需的水平。文章还引用了 Audio Big Bench 的准确性在五个模型快照中从 2024 年 12 月的 65.6% 上升到 2026 年 5 月的 92.29%。

由此产生的语音模型现在支持该客户的部署、其他定制客户服务部署以及通过 Presence 进行的管理部署。在一个客户的业务中遇到的问题帮助确定了可以为许多其他客户服务的改进。

FDE 模式对 AI 部署方式的启示

文章为困难的部署划分了明确的职责分工：客户承诺解决模型尚无法解决的问题，FDE 保持足够接近以定义问题、构建平台并从头到尾推动合作，而研究部门则改进底层模型能力。这项工作的回报超出了与任何单个客户相处的时间。

作者表达的工程偏好是简单：“在大多数 LLM 开发案例中，奥卡姆剃刀原则适用——最简单的解决方案是最好的。”在一家以尖端研究和“充满夸张”的行业著称的公司中，既定目标是构建可靠工作且现场人员可以依赖的东西。

每次合作的目标是改进下一步——更易于部署的产品、能处理更难任务的模型，或为下一个客户减少定制工作。而文章开头问题的答案就是文章的结尾：当 Codex 能处理团队花了数月构建的工作时，“去寻找更难的问题。”