摘要

OpenAI 的前沿部署工程（FDE）团队由 Colin Jarvis 领导，深入企业客户现场，利用大语言模型（LLM）解决高价值问题，并交付生产级 AI 应用。该团队专注于价值达数千万乃至数十亿美元的问题，与金融（Morgan Stanley）、制造（半导体、汽车）、电信（T-Mobile、Klarna）等多个行业的公司合作。通过深入理解客户领域、构建评测框架、实施防护机制，并花数月时间与用户持续迭代，FDE 团队实现了 20-50% 的效率提升和高采用率（Morgan Stanley 达 98%）。这一模式强调从零到一解决困难的新颖问题，将经验提炼为可复用的产品和框架（如 Swarm 和 Agent Kit），然后将解决方案推广至整个市场，同时保持战略重心在产品开发而非服务收入上。

In Production

每周二和周四，为您邮箱送上四个这样的 LLMOps 案例研究。

本页目录

概述

本案例研究通过对领导该团队的 Colin Jarvis 的访谈，深入剖析了 OpenAI 的前沿部署工程（FDE）组织。FDE 团队的设立是为了应对这样一个挑战：尽管 ChatGPT 引发了巨大热潮，但在生产环境中从 LLM 中获取企业价值却一直困难且不稳定。该团队代表了 OpenAI 的“5%”——即成功大规模部署 AI 的企业——与广为引用的 MIT 研究中“95% 的企业 AI 部署失败”的结论形成鲜明对比。

Colin Jarvis 于 2022 年 11 月加入 OpenAI，即 ChatGPT 发布的那个月，当时公司员工不足 200 人。FDE 业务从 2024 年初的仅 2 人增长到访谈时的 39 人，并计划到 2024 年底达到 52 人。这一快速扩张既反映了生产级 LLM 部署的需求，也体现了使其成功所需的专业技能。

前沿部署模式与理念

OpenAI 的 FDE 模式明确借鉴了 Palantir 等公司的类似实践，团队成员深度融入客户，理解其领域并交付可用的解决方案。其理念核心是“吃进痛苦，产出产品”——深入困难的客户问题，从中提炼出可推广的产品洞察和平台能力。不过，OpenAI 采取了有别于传统咨询的战略方式：FDE 团队被定位为一个从零到一的团队，专注于攻克新颖的高价值难题，而非提供长期服务。

团队有意瞄准价值在数千万到低数十亿美元之间的问题，确保被解决的问题具有显著的经济影响，并且从中获得的经验能够证明投入的合理性。这种有选择性的方法使 OpenAI 能够专注于产品开发和研究洞察，而不是被拉入纯粹的服务收入。FDE 团队明确地将能力沿两个维度划分：一些合作有明确的产品假设，他们会寻找完美的设计合作伙伴；另一些则瞄准有有趣技术问题的行业（如半导体或生命科学），即使没有即时的产品方向，他们也期望获得研究上的收获。

摩根士丹利：奠基性案例研究

摩根士丹利是 OpenAI 在 2023 年首家部署 GPT-4 的企业客户，这次合作帮助确立了 FDE 实践。该用例是通过一套 AI 驱动的系统，将摩根士丹利的财富管理研究交到所有财富顾问手中。这体现了一个关键模式：成功的企业部署解决的是业务核心中真正高风险的用例，而不是边缘案例。

当时的技术挑战非常艰巨，因为那时 RAG（检索增强生成）尚未成为成熟的模式。团队必须开发检索调优技术，以确保研究报告能够被准确地呈现并获得信任。技术流水线在 6-8 周内搭建完成，包括检索优化、防护栏和基础评测框架。然而，关键的洞察在于，技术就绪并不足够——还需要额外 4 个月的试点、用户反馈收集、评测完善和迭代，才能赢得财富顾问的信任。

这个漫长的信任建立阶段在受监管的金融环境中尤为重要，因为那里的准确性要求很高，而技术本身是概率性的。FDE 团队与顾问密切合作，标注数据、验证输出，并针对置信度较低的情况开发验证工具。结果非常出色：财富顾问的采用率达到 98%，研究报告的使用量增长了 3 倍，同时证明了技术上的成功和用户的接受度。

半导体制造：复杂的验证工作流

OpenAI 最大的持续项目之一涉及一家欧洲半导体公司，展示了 FDE 如何应对复杂的技术领域。合作始于 OpenAI 团队驻场数周，以了解整个价值链：芯片设计、验证和性能测量。团队将验证确定为价值最高的目标，因为工程师将 70-80% 的时间花在修复缺陷和维护兼容性上，而不是新功能开发。

FDE 团队在整个价值链中交付了 10 个不同的用例，目前在早期部门已实现 20-30% 的效率提升，总体目标为 50%。一个关键例子是基于 Codex 构建的“调试调查与分诊 Agent”。每天早上，工程师都要面对来自隔夜测试运行的数百个 bug。最初的方案是让模型调查 bug 并撰写详细工单，说明可能的原因。随着信任的建立，系统逐步演进为尝试修复并自动发起拉取请求。团队还添加了执行环境，使模型能够迭代地测试自己编写的代码。

这个案例展示了 LLM 能力与确定性系统之间的精心编排。团队 fork 了 Codex 并添加了大量遥测功能，基于专家轨迹——即人类工程师实际会遵循的 20 多个操作序列——构建了详细的评测。他们在开始开发之前与客户专家合作创建了带标注的评测集。其理念是“评测驱动开发”，确保任何基于 LLM 的代码在存在验证手段之前都不算完成。随着模型不断改进，评测框架提供了一种一致的进度衡量方式。FDE 团队在模型周围添加脚手架，确保某些组件保持确定性，同时利用 LLM 的优势处理需要细致判断的任务。

愿景是到 2025 年年中，工程师上班时会发现大多数 bug 已经修复，最棘手的问题也有清晰的文档记录，从而让他们能够专注于编写新代码，而不是在修复 bug 和开发之间来回切换。

汽车供应链：在概率性 AI 与确定性约束之间取得平衡

一家位于亚太地区的汽车制造客户提出了一个复杂的供应链协调问题。通常情况下，关税调整等中断事件需要通过电话和会议在制造、物流和采购团队之间进行人工协调，分析影响并制定应对方案需要数小时甚至数天。FDE 团队构建了一个带 API 的数据层，使 LLM 能够在不移动数据的情况下跨这些系统进行编排。

演示展示了一个系统如何应对从中国到韩国的商品被加征 25% 关税的假设情景。该解决方案架构体现了 FDE 的核心原则：尽可能使用确定性方法，仅在 LLM 的概率性特性能带来价值时才使用 LLM。团队实现了必须以确定性方式验证的硬约束——例如，始终为轮胎等关键部件保持至少两家供应商、满足交期要求，并确保所有物料都有覆盖。这些约束 100% 通过确定性代码进行检查，而不是信任 LLM。

该系统首先将 LLM 用于商业智能，查询各种数据库并生成以前需要 BI 团队跨部门协调才能获得的洞察。它以解释说明的方式呈现关税影响，提供详细表格供验证，并提供地图可视化。真正的价值体现在优化环节：系统运行复杂的模拟，寻找工厂与供应商的最佳组合，以最小化成本和交付周期。系统并不直接让 LLM 进行优化，而是让它访问一个模拟器，像一位有经验的企业用户那样探索参数空间。

在演示中，系统运行了五个优化场景，并推荐了最佳权衡方案。在生产部署中，这种方法可扩展到离线运行成百上千次模拟，由 AI Agent 返回有充分文档支持的推荐。面向客户偏保守的做法包括：在执行操作前展示推理说明、提供验证组件，以及展示详细表格供人工核查。这种分层方法在建立信任的同时，也让复杂分析能力得以普及。

Klarna 和 T-Mobile：从定制解决方案到平台产品

从 Klarna 的客服应用到 OpenAI 的 Agent SDK 和 Agent Kit 的历程，展示了 FDE 如何从客户痛点中提炼出产品。2023 年，Klarna 面临可扩展性问题：为 400 多条政策手动编写提示词难以为继。Colin Jarvis 与他们合作开发了一种对指令和工具进行参数化的方法，并为每个意图配备评测集，从而实现规模化。

这一模式效果足够好，以至于 OpenAI 将其固化成一个名为 Swarm 的内部框架，并最终开源。该框架在 GitHub 上获得了社区的高度关注。与此同时，FDE 团队开始与 T-Mobile 在客服领域展开合作，其业务量、政策数量和政策复杂度都“复杂 10 倍”。Swarm 的基础组件在经过扩展后被证明行之有效，验证了其通用性。

这种汇聚——在多个客户处取得生产环境成功、获得开源验证、以及明确的产品假设——促使 OpenAI 的产品团队构建了 Agent SDK。最近，它进一步演化为 Agent Kit，一个让底层框架更易于使用的可视化构建工具。从解决方案架构、FDE 式交付，到内部框架、开源验证、产品团队采纳，再到最终主流产品发布，这一演进过程展示了预期的从 FDE 到产品的流水线。

关键的洞察在于：可复用性源于解决真实的客户问题，而不是过早地追求通用化。团队学到的是，在没有明确问题的情况下从高概念化的通用方案入手会导致失败，而深入解决具体的客户问题几乎总能揭示出可推广的模式。

评测驱动的开发与信任构建

各个部署项目中的一个共同主题是评测框架的核心地位。FDE 团队的方法首先是对领域进行深入理解，然后在重大开发开始之前创建详细的评测集。以半导体为例，这意味着与客户专家合作定义轨迹——即专家为解决特定问题所采取的一系列行动。这些轨迹成为带标签的评测集，用于衡量 LLM 的表现。

其理念是：没有评测来验证有效性的 LLM 应用是不完整的。这种“评测驱动开发”的方法带来多项好处：它迫使团队明确成功标准，能够在模型改进时客观衡量进展，通过透明度建立客户信心，并为迭代改进创建反馈循环。

漫长的信任建立阶段（摩根士丹利为 4 个月，其他地方的时间线也类似）不仅仅是为了提高准确性——更是为了在用户与 AI 系统之间建立共同理解、确立验证机制，并建立组织信心。在受监管的环境或高风险应用中，这种对信任的投入是不可妥协的，即使在技术上准备就绪之后，它仍占部署时间线的很大一部分。

技术架构模式

在 FDE 部署中出现了几种技术模式：

带护栏的编排：LLM 在复杂系统中充当编排者，但由确定性护栏保护关键约束。汽车供应链的例子明确分离了关注点：对硬性要求（供应商最低数量、交货周期、物料覆盖）使用确定性检查，而对优化和洞察生成则使用概率性的 LLM 推理。

检索与数据层：FDE 团队通常不移动数据，而是构建翻译层或元数据层来支持 LLM 访问。这解决了是集中数据还是就地使用数据的经典问题。既然 LLM 能够生成查询，问题就变成了数据是否还需要移动。Colin 将这种“元数据翻译层”视为一个被低估但潜力巨大的领域，并将其类比为传统商业智能，但针对 LLM 的消费方式进行了适配。

工具访问与执行环境：Agent 会获得与其任务相匹配的工具，从 API 和模拟器到用于测试代码的执行环境。半导体调试 Agent 拥有执行环境来迭代测试其修复方案。供应链系统可以访问模拟器来探索各种权衡。这种让 LLM 拥有专家会使用的工具、并结合适当护栏的模式，使其能够进行复杂的问题求解。

遥测与可观测性：团队为生产部署添加了大量遥测，从而能够深入理解模型行为、识别故障模式并持续改进。这种可观测性对于建立信任和迭代提升性能都至关重要。

确定性-概率混合设计：一条核心架构原则是判断何时使用确定性逻辑、何时使用概率推理。关键业务规则、数学约束和验证步骤应当是确定性代码，而非 LLM 输出。LLM 最有价值之处在于需要细腻处理、自然语言理解、复杂推理以及应对变化的任务。

产品与服务的张力

Colin 强调了服务收入与产品开发之间的战略抉择，并指出咨询公司往往无法完成这一转型，因为短期服务收入会把组织从战略性的产品投入上拉走。在 OpenAI，FDE 团队秉承“先研究、后产品”的公司基因，这有助于保持对平台开发的专注，而非追逐服务收入。

团队明确避免成为“千人军团”，而是保持精选原则，确保所解决的问题要么能推动研究走向新方向，要么有通往平台产品的清晰路径。他们愿意拒绝那些不推进战略目标的丰厚服务机会。不过其中也有细微之处：有时即使没有明确的产品假设，只要研究层面的收获能证明投入是值得的——即让模型更擅长解决此类问题能广泛惠及 OpenAI——经济价值高的问题也会被纳入。

能力分配正体现了这一点：一些项目与理想的设计伙伴合作，针对具体的产品假设；另一些则探索拥有有趣技术问题的行业，以提炼研究洞见。预期的路径是与首个客户完成从零到一（也许 20% 可复用），再经过两到三次迭代达到 50% 的可复用性，然后推向规模化业务运营，实现广泛的市场部署。

错误与经验教训

Colin 认为最大的错误是“过早泛化”——看着 ChatGPT 的功能，就试图打造通用企业解决方案，而没有深入解决具体的客户问题。这会导致“没有明确问题的高概念解决方案”，无法获得市场认可。相反，在客户的问题上“深挖到底”几乎总能带来可泛化的洞见。

这与 Paul Graham 关于早期做不可扩展之事的建议相呼应。FDE 的座右铭明确就是“做不可扩展的事”，在尝试泛化之前先深入理解问题。从 Swarm 到 Agent Kit 的演进正说明了这一点：泛化是从解决真实问题中自然涌现的，在产品化之前已经得到多个客户和开源采用的验证。

工具与技术栈

文中提到了几个具体的工具和技术：

OpenAI Playground：Colin 认为这个工具被低估了，可以用来快速验证用例的可行性。通过一个简单的界面直接与 API 交互，能够实现快速迭代和合理性检查。他描述了用 N=10 的测试来验证浏览器自动化用例——如果 7-8 个成功，该用例很可能在生产环境中可行。

Codex：其自主工作的能力被描述为具有变革性。Colin 的“顿悟时刻”是开了四个小时的会回来后发现工作已经完成了。在半导体项目中，Codex 被分叉并扩展了领域特定的能力。

Swarm 框架：这是一个先内部使用后开源的框架，用于参数化指令和工具，将策略从数十个扩展到数百个，并带有评测包装器。这成为了 Agent SDK 的基础。

Agent SDK 和 Agent Kit：Swarm 原语的产品化演进，其中 Agent Kit 提供了一个可视化构建器界面，以便更广泛地推广使用。

MCP（Model Context Protocol）：被提及作为数据连接的起点，不过 FDE 团队通常会在原始 MCP 连接器和 LLM 消费之间构建额外的逻辑层。

DALL-E：出现在可口可乐“Create Real Magic”营销活动中，这是一个早期项目，需要在 DALL-E 3 发布前对其进行调优，以生成完美的圣诞图像，同时管理越狱风险。

未来预测与行业方向

Colin 预测 2026 年可能是“微调之年”或“一键上线之年”，而不仅仅是 Agent 之年。他的理由是，构建复杂 Agent 系统的基础组件现在已经就位，下一个前沿是优化：利用已经搭建好管道的编排式 Agent 网络，从其运行中生成训练数据，高效地进行标注，并针对芯片设计或药物发现等特定领域对模型进行微调。这将实现从“Agent 被使用”到“Agent 在专业领域被完美使用”的转变。

这一演进过程体现了成熟度：先确立复杂任务是可行的（Agent 时代），然后通过专业化针对特定领域进行优化（微调优化时代）。用于创建训练数据、构建评测集和管理开发生命周期的基础设施现在已经建立起来，从而能够实现这一下一步演进。

组织与招聘洞察

FDE 团队在一年内从 2 人快速增长到 52 人，这既反映了市场需求，也反映了这一角色的专业性。Colin 指出，这些是最难招聘的职位之一，需要深厚的技术能力、客户同理心、领域适应性以及对模糊性的从容应对。团队必须在研究、产品开发和客户交付之间周旋，同时保持战略聚焦。

起源故事——从欧洲一两个人与 John Deere 的首次合作开始——展示了规模化之前的白手起家阶段。团队的结构反映了双重关注点：以产品假设为驱动的客户合作，以及以探索性研究为驱动的行业部署。

战略定位与市场背景

这段访谈回应了“AI 泡沫”的叙事以及 MIT 关于 95% 企业部署失败的研究发现。OpenAI 的 FDE 团队将自己定位为“让部署成功的 5%”——即将大语言模型的潜力转化为生产现实的专门能力。这一定位强调，成功的企业 AI 部署不仅仅取决于模型能力，还需要深入的领域理解、细致的工程、信任建设以及组织变革管理。

OpenAI 内部 B2B 与 B2C 之间的钟摆摆动也构成了背景。Colin 描述了一个低谷期：从第一届 Dev Day（2023 年底，发布了 Assistants API）到下一届之间，公司重心大幅偏向消费级产品。尽管交付了 Morgan Stanley 和 Klarna 等重大企业级成果，FDE 团队仍感觉自己的工作未被优先重视。在此期间，由于内部对面向 B2B 的框架缺乏兴趣，开源 Swarm 的部分原因也在于此。2024 年底，钟摆重新摆向 B2B，FDE 团队的扩编随之获得批准。

这一组织背景表明，即使在 OpenAI 内部，保持对企业部署的战略聚焦也需要在相互竞争的优先事项中周旋，并通过客户成功和开源验证来证明价值。

结论

OpenAI 的 FDE 实践代表了一种成熟的企业级大语言模型部署方法，在即时客户价值与长期产品和研究目标之间取得平衡。其关键原则——深度领域嵌入、评测驱动的开发、战略性的问题选择、对确定性组件与概率性组件的精心编排、长期的信任建设，以及从具体解决方案中提炼出可泛化的产品——为成功的生产级大语言模型部署提供了范本。团队的快速成长和高价值成果既证明了对这种能力的需求，也证明了这一方法在让企业 AI 部署真正落地方面的有效性。