OpenAI FDE 负责人最新访谈：大模型想成功落地，要靠前线部署工程师

如今，每个科技公司都在谈论人工智能。但是，一个尴尬的现实是，绝大多数公司的 AI 项目都失败了。

MIT 一份报告给出的结论是，95% 的企业 AI 部署项目最终都无法落地。大家看到了无数酷炫的 Demo，但在解决真实世界的复杂问题时，这些技术往往会碰壁。

为什么会这样？因为先进技术和现实之间，存在一条巨大的鸿沟。填补这条鸿沟，需要的不仅仅是更好的算法或更强的模型。

那些成功的 5% 公司，它们做对了什么？OpenAI 和 Palantir 给出的答案是：前线部署工程（Forward Deployed Engineering，简称 FDE）。

最近，OpenAI 的 FDE 负责人 Colin Jarvis 分享了他们的工作方法。这套方法论，对于任何希望将 AI 技术真正转化为商业价值的公司来说，都极具参考价值。

一、什么是 FDE？

FDE 的概念很简单：将最懂核心技术的工程师，直接「嵌入」到客户的业务团队中，与行业专家并肩作战。

他们不是传统的销售工程师或技术支持。他们的任务不是演示产品，也不是解决 bug，而是：

1. 1. 深度理解领域：深入客户的业务流程，理解他们最棘手的、最有价值的问题。
2. 2. 紧密迭代：与客户一起，快速构建、测试、迭代解决方案。
3. 3. 解决特定问题：为这个特定场景，构建一个能实际运行、产生价值的系统。
4. 4. 提炼通用组件：从这个定制化的解决方案中，提取出可复用的、能够产品化的部分。

Palantir 的 CTO Shyam Sankar 用一句非常生动的话总结了 FDE 的精髓：

FDE 的工作是消化痛苦，排出产品（Eat pain, excrete product）。

（我觉得这个翻译可能还是太文雅了，换句话说就是，吃进去混乱的业务，拉出来可用的产品。）

所谓「消化痛苦」，就是深入到客户最混乱、最麻烦的业务一线，去承受和消化那些由复杂现实带来的挑战。「排出产品」，则意味着最终的产出物不是一份咨询报告，也不是一个一次性的项目，而是一个可复用、可扩展的「产品」雏形。

OpenAI 正是在这个理念的指导下，建立了一支快速成长的 FDE 团队。Colin Jarvis 透露，这支团队从年初的 2 人，一年内已经增长到 39 人，年底将达到 52 人。他们瞄准的问题，通常能为客户带来「数千万至数十亿美金」的价值。

二、OpenAI 的 FDE 实战手册

Colin Jarvis 在交流中分享了 OpenAI FDE 团队的几个核心工作原则。这些原则构成了他们的「实战手册」。

1. 从真正高风险的问题入手

成功的 AI 项目，不能选择企业边缘的、无关痛痒的场景，要做就做难的。因为只有核心业务，才能调动公司最好的资源，也只有解决了核心问题，才能产生巨大的价值。

有两个典型的例子：

• • 摩根士丹利：他们希望用 GPT-4 赋能财富管理部门，这是他们最大、最核心的业务之一。目标是将公司庞大的投研报告，高效地提供给每一位财富顾问，让他们能为客户提供更精准的洞察。
• • 某半导体巨头：这家欧洲公司向 OpenAI 的 FDE 团队提出了一个开放性问题——审视我们整个价值链，找出浪费最严重的环节，然后用 AI 提升效率。他们没有限定具体场景，而是让 FDE 团队去发掘最有价值的痛点。

选择这些高风险问题，本身就是一种过滤器，确保了双方都有足够的意愿和资源投入，去克服落地过程中的重重困难。

2. 通过迭代建立信任，而非仅仅依靠技术

对于企业级应用，尤其是金融、半导体这种严肃领域，技术的先进性远不足以让用户采纳。信任，才是关键。而信任，只能通过漫长而细致的迭代来建立。

在摩根士丹利的项目中，核心的技术管线其实只用了 6 到 8 周 就搭建完成了。但是，整个团队花了更久的时间，进行一轮又一轮的试点、评估和迭代。

他们让财富顾问亲自使用、标记数据、提供反馈，不断调整系统的输出，直到顾问们真正信任它，敢于用它来服务自己的高净值客户。

这个漫长的过程换来了惊人的成果：最终，该系统的采纳率达到了 98%，投研报告的使用量提升了 3 倍。

这个案例说明，AI 落地最大的障碍，往往不是技术，而是人与系统之间的信任鸿沟。FDE 的核心工作之一，就是通过持续的迭代和验证，来填补这条鸿沟。

3. 评估驱动开发（Eval-driven Development）

如何科学地建立信任？OpenAI 的 FDE 团队有一个标准方法论，叫做「评估驱动开发」。

任何一段由 LLM 驱动的业务，在拥有一套能够验证其有效性的评估（evals）之前，都不能算完成。

这意味着，在开始构建复杂的功能之前，团队会和客户的领域专家一起，定义一个评估集（eval set）。这个评估集包含一系列的输入和期望的输出，用来衡量系统的表现。

这个过程贯穿始终：

• • 项目初期：定义核心指标，建立基准。
• • 开发过程：每次模型或代码的改动，都必须通过评估集的测试，确保性能不回退。
• • 项目交付：这套评估框架会成为交付物的一部分，交给客户的内部团队，让他们有能力持续维护和迭代这个系统。

评估驱动开发，为概率性的 AI 系统，提供了一个确定性的质量保障框架。它是建立信任和实现可靠交付的基石。

4. 权衡确定性（Determinism）与概率性（Probabilism）

LLM 本质上是概率性的，这使得它在处理模糊、复杂的自然语言任务时表现出色。但企业应用中，有很多环节要求 100% 的准确和可靠。

FDE 的一个核心设计理念，就是清晰地划分这两者的界限，并进行有效组合。

让 LLM 去做它们最擅长的事——处理细微差别和复杂性。但是，用确定性的护栏（guardrails）把它们包裹起来，处理那些必须 100% 正确的事情。

Colin 在演示了一个为汽车制造业客户构建的供应链管理系统，完美地诠释了这一点。

• • 场景：假设从中国出口到韩国的商品，被加征 25% 的关税。
• • LLM 的任务（概率性）：理解这个自然语言指令，分析它对哪些零部件产生影响，然后调用内部的模拟器，生成几个不同的供应链调整方案（比如，更换供应商、调整工厂产能）。这是一个复杂的、需要权衡多种因素的决策过程，非常适合 LLM。
• • 护栏的任务（确定性）：系统后台有一系列写死的业务规则，比如「轮胎的供应商必须始终保持至少两家」、「物料必须 100% 覆盖」。在 LLM 提出任何方案后，系统会用这些确定性的规则去校验。只有通过校验的方案，才会被采纳。

通过这种方式，系统既利用了 LLM 的灵活性和智能，又保证了最终决策的可靠性和合规性，解决了企业在应用 LLM 时最大的顾虑。

三、从咨询到产品：FDE 的价值闭环

听到这里，很多人会有一个疑问：这听起来不就是一种昂贵的咨询服务吗？

这是对 FDE 最大的误解。Colin 强调，FDE 团队有一个清晰的北极星指标：

你必须带着产品离开（You must leave with product）。

FDE 的本质是一个「从 0 到 1」的产品发现过程。它与咨询的核心区别在于，它的目标不是交付一个一次性的解决方案，而是孵化一个可复用的产品。

这个过程遵循一个典型的模式：

1. 1. 第一次实践（20% 可复用）：为第一个客户解决问题时，大部分工作是定制化的。可能只有 20% 的代码或模式是可以复用的。
2. 2. 多次验证（50% 可复用）：将这套模式应用到两三个相似的客户身上。通过不断地抽象和重构，可复用性可以提升到 50% 甚至更高。
3. 3. 产品化（>80% 可复用）：当模式被充分验证后，就将其移交给公司的正式产品团队，进行标准化和规模化，推向更广泛的市场。

OpenAI 的 Agent SDK 和 Agent Kit 的诞生，就是这个模式的体现。

• • 源头（Klarna）：FDE 团队最早在与瑞典金融科技公司 Klarna 的合作中，为他们的客服场景构建了一套复杂的 Agent 系统。当时，他们开发了一个内部框架来参数化指令和工具，并为每个意图包裹评估集，以实现从 20 个客服策略扩展到 400 个。
• • 扩展（T-Mobile）：随后，团队在与 T-Mobile 的合作中，遇到了一个复杂度高出 10 倍的类似场景。他们发现，在 Klarna 项目上开发的框架，经过一些扩展后，同样适用。
• • 产品化（Agent SDK / Agent Kit）：这两个成功的案例证明了这套框架的通用价值。于是，FDE 团队与产品部门合作，将其正式产品化，最终发布了 Agent SDK，以及最近的可视化构建工具 Agent Kit，让所有开发者都能使用。

这个「Klarna → T-Mobile → Agent Kit」的路径，清晰地展示了 FDE 如何「消化痛苦，排出产品」。如果没有深入 Klarna 和 T-Mobile 一线的痛苦实践，就不可能诞生出 Agent Kit 这样真正解决问题的产品。

四、给创始人的建议

对于那些希望在自己公司建立 FDE 团队的创始人或 CEO，Colin 给出了一个最核心的建议： ruthlessly clear about purpose （对目标毫不含糊）。

你必须想清楚一个根本问题：

你的 FDE 团队，到底是为了什么而存在？你是想依靠服务收入作为一项关键的收入来源，还是希望通过这些项目中的成功赌注，来驱动未来的产品收入增长？

Colin 指出，他见过太多的失败模式：一家公司怀揣着成为产品公司的愿景，但由于服务收入在短期内更容易获得，团队逐渐被拖入了做项目的泥潭，最终「失去了战略视角」。

这需要极强的纪律性。你必须在困难的时候说「不」，哪怕有人愿意为一些非战略性的工作付给你一大笔钱。

FDE 团队应该服务于两个战略目标：

1. 1. 产品假设验证：寻找理想的设计伙伴，共同打磨一个有潜力成为通用产品的解决方案。
2. 2. 前沿研究探索：在一些战略性行业（如半导体、生命科学），与头部客户合作解决极具挑战性的问题，即使短期内不确定能否形成产品，但其过程中的学习和对模型的推动，对公司有长远的战略价值。

OpenAI 的 FDE 团队，正是按照这两个方向来分配资源的。

五、更多观点

在交流的最后，Colin 还分享了一些有趣的观点。

• • 要避免的错误：过早地泛化（Generalizing too early）。许多团队总想一开始就做一个通用的平台，结果往往是做出一个谁也用不好的「高概念」解决方案。正确的做法是，先深入一个具体问题，把它做到极致。Paul Graham 的名言「做无法规模化的事（Do things that don’t scale）」，是 FDE 团队的信条。当你真正解决了一个具体问题后，通用化的部分自然会浮现。
• • 看好的领域：数据与 LLM 之间的「元数据翻译层」。FDE 项目中，大量时间都花在了数据准备和业务逻辑注入上，以便让 LLM 理解并有效使用企业数据。那些能够构建智能本体、解决这个翻译问题的公司，拥有巨大的价值。
• • 不看好的领域：LLM 应用链条上的单点工具公司。构建一个 LLM 应用需要编排、追踪、评估、护栏等多个环节。对于大型企业来说，他们不想去整合五六个不同供应商的单点工具，他们需要一个端到端解决方案。
• • 被低估的工具：OpenAI Playground。在投入大量工程资源之前，Playground 是一个极其强大的工具，可以用来快速验证一个想法是否可行。Colin 举例说，他曾经通过截图、粘贴到 Playground 并与模型对话的方式，在 10 分钟内就验证了一个浏览器自动化用例的基本可行性。

• • 对 2026 年的预测：回归微调（Fine-tuning）的一年。Colin 认为，今年大家都在谈论 Agents，但部署 Agents 依然很复杂。随着 Agents、数据管道等基础设施的成熟，大家终于有了足够的「弹药」（高质量的标注数据）去为特定领域（如芯片设计、药物研发）精调专门的模型。这可能会开启一个新时代，让 AI 在专业领域的表现实现质的飞跃。

结语

FDE 模式，本质上是科技公司在面对企业级市场复杂性时，进化出的一种产品研发和社会学相结合的解决方案。

它不是简单的技术支持，也不是咨询服务，而是一个深入客户业务、与客户共创、最终将解决方案沉淀为产品的战略引擎，从而弥合了先进技术与混乱现实之间的鸿沟。

正如「消化痛苦，排出产品」这句简短而精辟的概括，真正的创新，往往诞生于最痛苦、最棘手的一线问题之中。对于所有致力于将 AI 技术落地的探索者而言，这或许是最值得借鉴的一条路径。