摘要

OpenAI 的前沿部署工程（FDE）团队深入企业客户现场，利用大语言模型（LLM）解决高价值问题，目标是实现能创造数千万乃至数十亿美元价值的生产级部署。团队处理跨行业的复杂用例——从摩根士丹利的财富管理到半导体验证和汽车供应链优化——在构建定制化解决方案的同时，提炼出可推广的模式，为 OpenAI 的产品开发提供参考。通过将 LLM 能力与确定性防护机制相结合的“评测驱动开发”方法，FDE 团队在 2025 年从 2 名工程师增长到 52 名，成功弥合了 AI 能力与企业生产需求之间的差距，同时专注于从零到一的问题解决，而非长期咨询合作。

正在生产环境中应用

每周二和周四，四篇像本文这样的 LLMOps 案例研究，直达你的收件箱。

本页目录

概述

本案例研究通过对 FDE 团队负责人 Colin Jarvis 的访谈，全面介绍了 OpenAI 的前沿部署工程（FDE）实践。FDE 职能代表了 OpenAI 针对企业级 LLM 部署的专业化模式，充当研究能力与生产级企业应用之间的桥梁。团队在 2025 年初仅有 2 名工程师，到年底已增长至 52 名，反映出企业环境中大规模部署 LLM 对实战专业知识的巨大需求。

OpenAI 的前沿部署工程模式有意瞄准高价值问题——通常能创造或节省数千万至低数十亿美元的价值——肩负双重使命：一方面推动客户实现生产级部署，另一方面提炼经验以指导 OpenAI 的产品路线图。这一定位使 FDE 成为一支战略性的“特遣队”，而非传统的咨询组织，专注于从零到一的问题解决，而非长期运营支持。

早期案例与模式确立

2023 年摩根士丹利的财富管理部署确立了后来成为 OpenAI FDE 方法论核心的许多模式。这是 OpenAI 首个使用 GPT-4 进行部署的企业客户，用例是通过 LLM 驱动的检索系统让财富顾问能够访问研究报告。关键在于，这发生在 RAG（检索增强生成）成为标准化方法之前，团队需要自行开发定制的检索调优方法。

摩根士丹利的合作项目揭示了一个关于企业级 LLM 部署的根本性洞察：技术能力与生产就绪度遵循截然不同的时间线。虽然核心技术管线——包括检索、防护栏和基础功能——在六到八周内即可投入运行，但还需要额外四个月的试点、收集评测和迭代打磨，才能在财富顾问中建立足够的信任以实现实际采用。回报是可观的：顾问采用率达到 98%，研究报告使用量增长了 3 倍。这种相对快速的技术验证之后是漫长的信任建立的模式，成为 FDE 合作中反复出现的主题。

摩根士丹利的案例还凸显了选择真正高风险用例而非边缘用例的重要性。财富管理是摩根士丹利的核心业务职能，这一战略定位确保了组织的投入和有意义的影响衡量。在受监管的环境中工作也迫使团队建立起适合概率性技术的严谨准确性框架——这些经验可以迁移到其他受监管的行业。

技术方法论：评测驱动开发

OpenAI 的 FDE 团队将他们所称的“评测驱动开发”作为核心技术方法论。这一方法认识到，生产环境中的 LLM 应用不能单纯依赖概率性行为，而需要在 LLM 能力与确定性验证系统之间进行精密的协同。

半导体公司的合作项目为这一方法论的实际应用提供了详细例证。FDE 团队与一家欧洲半导体制造商合作，驻场工作以了解完整的价值链——从芯片设计到验证再到性能测量。他们将验证确定为价值最高的目标，因为工程师将 70-80% 的时间花在修复缺陷和维护兼容性上，而非新功能开发。

团队与该半导体客户的合作方式展示了评测驱动开发的分层特性。他们首先 fork 了 Codex（OpenAI 的代码生成模型），并添加了大量遥测功能以支持详细的评测追踪。他们与客户专家合作，创建了带标注的评测集，用以捕捉人类工程师在调试时会遵循的轨迹——通常是一系列约 20 个不同的操作，检查各种日志和系统状态。

开发过程本身遵循了一种自动化程度和能力不断提升的迭代模式。最初，系统会调查 Bug 并附带初步分析为人类工程师创建工单。当这种咨询模式建立起足够的信任后，团队进一步让模型尝试修复并提交 Pull Request。这又暴露出需要一个执行环境让模型测试自己的代码，从而推动了进一步的迭代。

其成果——被称为“调试调查与分诊 Agent”——的目标是到 2026 年年中，让大多数隔夜测试失败能够自动解决，只有最复杂的问题才需要人工介入，并且这些问题会被清晰地记录下来。该团队目前已在推广此系统的部门实现了 20-30% 的效率提升，目标是最终在涵盖十个不同用例的完整价值链上实现 50% 的效率提升。

平衡确定性与概率推理

在 FDE 项目中，一个贯穿始终的关键主题是：何时依赖 LLM 能力、何时强制执行确定性规则这一战略决策。为一位亚太地区（APAC）客户构建的汽车供应链优化系统清晰地展示了这一原则。

该系统解决的供应链协调难题，以往每当出现中断时，都需要在制造、物流和采购等多个团队之间进行人工电话沟通。FDE 团队构建了一个多层系统，利用 LLM 提供洞察和协调，同时对业务关键约束保持确定性的防护栏。

该架构明确地分离了各项关注点：需要综合多个来源（数据仓库、SharePoint 等）数据的商业智能查询，通过 LLM 编排来处理，由模型决定何时组合不同的数据源。然而，核心业务规则——例如为关键部件保持最低供应商数量，或确保所有物料始终有覆盖——则以确定性方式强制执行，绝不信任 LLM 来维护这些约束。

该系统还集成了一个供应链优化模拟器，LLM 可以调用它来运行多种场景。系统没有让 LLM 直接优化成本、交货期等因素之间的复杂权衡，而是让它使用与人类分析师相同的模拟工具。随后 LLM 会运行多次模拟（演示中为五次，但在生产环境中可能达到数百甚至数千次），展示各种权衡并给出推荐，而最终决策仍需经过确定性验证。

这种分层方法——用 LLM 进行复杂推理与综合、用确定性系统处理关键约束、用仿真工具进行优化——代表了高风险环境中生产级 LLM 系统的成熟模式。该应用包含透明度功能，如详细的推理说明、用于核验的表格数据以及可视化地图呈现，所有这些都旨在维持人类信任并实现监督。

从客户合作到产品：走向通用化的路径

OpenAI 的 FDE 模式最重要的特点之一，是明确专注于从客户合作中提炼产品洞察，而不是打造一个可持续的咨询业务。Swarm 框架和 Agent SDK 的演进正体现了这条从定制解决方案到平台能力的路径。

这段历程始于 2023 年 Klarna 的客服部署。核心挑战在于可扩展性：为 400 多项政策手动编写提示词是不可行的。FDE 团队开发了一种将指令和工具参数化的方法，并为每个意图配备评测集，从而实现了从 20 项政策扩展到 400 多项。

这一方法效果足够好，OpenAI 决定将其固化为一个名为 Swarm 的内部开源框架。当该框架在 GitHub 上获得显著关注时，这验证了市场对这些底层模式的需求。随后，团队将这些经验带到 T-Mobile，开展了一个在业务量和政策复杂度上被描述为“复杂 10 倍”的项目。Swarm 的模式在这个规模下依然有效——只需一些扩展——这提供了进一步的验证。

这些接连的验证为 FDE 团队提供了足够的依据，得以与 OpenAI 的产品部门合作构建后来成为 Agent SDK 的产品，而最近的 Agent Kit 发布则是 2023 年最初模式的可视化构建器延续。这一从定制解决方案 → 内部框架 → 大规模验证 → 产品发布的演进，代表了 OpenAI 正试图在其他领域复制的理想化 FDE 到产品的路径。

团队明确追求这样一种模式：首次客户合作可能产生 20% 的可复用组件，接下来的两三次合作将复用率提升到 50%，此时该解决方案就会被推送到 OpenAI 的规模化业务运营中进行更广泛的部署。不过，Jarvis 强调，就大多数产品假设而言，他们仍“处于这段旅程的起步阶段”。

组织结构与经济模型

FDE 团队的经济模型和组织模式与传统咨询截然不同。OpenAI 并不将服务收入作为主要收入来源，而是把对 FDE 的投入视为对未来产品收入和研究洞察的押注。这一定位使团队有底气拒绝不符合战略目标的高收益机会。

团队明确沿两个维度划分能力：一些项目由明确的产品假设驱动，OpenAI 正在为特定能力（客户服务、临床试验文档等）寻找完美的设计合作伙伴。另一些项目则瞄准具有有趣技术挑战的行业——半导体、生命科学——其学习目标更偏研究导向，相信提升模型在这些难题上的能力将使 OpenAI 整体受益，即使短期内没有产品产出。

这种双重使命带来了组织上的清晰性，但需要纪律约束。Jarvis 描述了抵制短期咨询收入的挑战——这类收入可能使团队偏离战略重心。他曾在那些立志成为产品公司却被服务收入困住的咨询公司中观察到这种失败模式。OpenAI 作为一家从研究公司演变为产品公司的根基，有助于保持这种纪律。

团队明确以从零到一（zero-to-one）的职能运作，不提供长期运营支持。项目通常以移交给客户内部工程团队收尾，或与将接管运营的合作伙伴协同工作。这使 FDE 团队能够从一个难题转向下一个难题，而不是陷入维护工作。

技术模式与反模式

在工作中，FDE 团队总结出若干持续带来成功的技术模式和需要避免的反模式。最重要的反模式是过早泛化——在深入理解具体客户问题之前就试图构建横向解决方案。Jarvis 描述了一些案例：OpenAI 在 ChatGPT 中发现了某些看似能很好地泛化到企业场景的功能，然后带着这些功能去找要解决的问题。这些努力通常都失败了，因为它们跳过了从零到一的探索阶段。

相反，几乎所有从“深入钻研客户问题”开始的项目都产出了可泛化的洞察，即使泛化并非最初目标。这印证了一个原则：彻底解决具体的高价值问题，而不是构建抽象的解决方案。

在技术方面，Jarvis 指出“元数据翻译层”是企业级 LLM 部署中被低估但至关重要的组成部分。FDE 的大部分时间都花在构建原始数据与业务逻辑之间的翻译层上，使 LLM 能够有效利用信息——例如，确定何时将数据仓库与 SharePoint 内容结合。这与传统的数据集成挑战相呼应，但鉴于 LLM 作为自主 AI Agent 对这些数据进行操作，其重要性达到了新的高度。

团队还逐渐收敛出一套在各次客户项目中反复出现的技术栈：工作流编排、全面的追踪与遥测、带标注的数据与评测框架，以及用于运行时防护的护栏。Jarvis 指出，企业强烈倾向于选择一体化解决方案，而不是为每个组件单独采购点状方案，因为集成复杂性会显著加剧将 LLM 应用推向生产环境本已艰巨的挑战。

行业特定考量

这些案例研究揭示了 LLM 部署模式如何因监管环境、数据特征和组织文化的不同而在各行业间有所差异。金融服务（Morgan Stanley）需要在监管严格、准确率要求极高的环境中建立大量信任，但该组织拥有清晰的 KPI 和高层的强力支持，最终实现了规模化成功。

制造业与半导体（欧洲芯片制造商、亚太汽车公司）则是技术深度极高的领域，用户是专家，需要强大的能力深度。这些项目要求 FDE 团队进行大量的领域学习——驻场数周以理解价值链和工作流。回报来自于瞄准价值最高的瓶颈（半导体的验证、汽车行业的供应链协同），而不是试图提供面面俱到的解决方案。

这些模式还表明，成功的企业 AI 部署瞄准的是真正高风险的核心业务职能，而非边缘用例。这种战略定位确保了组织的投入，使影响衡量清晰明确，并迫使团队建立生产级的可靠性标准。低风险部署或许更容易，但带来的组织学习和投入都更少。

工具与基础设施洞见

Jarvis 强调了 LLMOps 领域中几种被低估的工具。OpenAI Playground——ChatGPT 出现之前用于直接与 API 交互的界面——在快速验证用例方面仍然很有价值。他描述了用它进行快速的 N=10 测试，比如截取网页截图来验证浏览器自动化用例：如果 7-8 次尝试成功，那么生产可行性就是可信的。这种低成本的验证方式有助于在确认基本可行性之前避免投入复杂的基础设施建设。

Codex 受到了特别关注，它是实现真正自主运行的工具——Jarvis 描述了开完四个小时的会回来，第一次发现工作已被自主完成的情景。基于 Codex 构建的半导体调试 Agent 展示了代码生成模型如何可以通过领域特定的调优和执行环境进行分叉和扩展，从而打造专门的 Agent 能力。

展望未来，Jarvis 推测 2026 年可能是“优化之年”，在“Agent 之年”期间构建的基础设施将使针对特定 Agent 用例的模型微调得以广泛开展。他的假设是，随着编排、评测和防护栏基础设施现已就绪，各组织将有能力收集训练数据、快速标注，并针对芯片设计或药物研发等专业领域对模型进行微调，从而超越通用 Agent 能力，迈向高度优化的领域专用系统。

挑战与务实评估

这次访谈对企业级 LLM 部署中的挑战提供了平衡的视角。在 Morgan Stanley，技术上实现功能只用了 6-8 周，但建立信任却花了六个月，这说明了能力与采用之间的差距。半导体项目中目标是将效率提升 50%，但目前只达到 20-30%，这表明即使在成功的部署中，愿景与现实之间仍有距离。

Jarvis 也坦承了组织层面的挑战。他描述了从首届 OpenAI Dev Day 到 2024 年大部分时间里，公司重心大幅转向消费级（B2C）应用，导致专注于 B2B 的 FDE 团队感觉自己的企业级工作没有得到应有的重视，尽管他们在 Morgan Stanley、Klarna 等客户处取得了成功的部署。这在一定程度上导致 Swarm 因内部缺乏兴趣而被开源。2024 年底，钟摆重新摆向企业级业务，使 FDE 业务方案获得批准并随后快速增长，但这种摇摆反映了一家同时服务消费级和企业级市场的公司内部真实的组织张力。

团队承认自己“犯过很多错误”，并明确指出过早泛化是最大的失误，这为其他正在建立 FDE 实践的人提供了宝贵的学习。在一个拥有 OpenAI 资源和市场地位的组织中，仍然强调“做不可扩展的事”——援引 Paul Graham 的创业建议——说明这一原则即使在相当大的规模下依然适用。

对 LLMOps 的战略启示

这一案例研究为 LLMOps 从业者揭示了几点战略洞见。首先，技术能力与生产部署之间的鸿沟是巨大的，需要不同的技能组合——不仅是卓越的工程能力，还包括对业务领域的理解、与最终用户建立信任，以及组织变革管理。FDE 模式通过长达数月的嵌入式深度合作，明确地弥补了这一鸿沟。

其次，从定制解决方案到产品的演进需要在规模和复杂度不断提升的条件下经历多个验证周期。Swarm 到 Agent SDK 的路径需要先在 Klarna 进行验证，再在复杂度提升十倍的 T-Mobile 进行进一步验证，并在 GitHub 上获得关注之后，产品投入才具有意义。组织应当预期这一多步骤验证过程，而不是试图仅凭单次合作就实现产品化。

第三，高接触企业级 AI 部署的经济性要求要么将其视为战略投资（OpenAI 的做法），要么确保合作规模足以覆盖成本。OpenAI 专注于创造数千万至数十亿美元的价值，这为大量的 FDE 投入提供了经济空间。规模较小的组织要么瞄准类似的高价值合作，要么通过更好的工具和流程来降低部署摩擦。

最后，确定性组件与概率性组件之间的平衡是一项关键的架构决策。使用 LLM 进行复杂推理与综合，同时以确定性方式强制执行业务关键约束，并借助仿真工具进行优化，这一模式为高风险环境中的生产级 LLM 系统提供了模板。这种架构既承认了当前 LLM 能力的强大之处，也承认了其局限性，同时构建出可验证、可信赖的系统。