为什么 OpenAI 要把工程师派驻到现场：企业级 AI 的 FDE 实战手册

OpenAI 前沿部署工程负责人 Colin Jarvis 揭示了为什么更强的模型反而需要现场工程师来弥合演示能力与生产信任之间的鸿沟，详细阐述了评测驱动的开发、确定性-概率性边界，以及“吃进痛点 → 排出产品”的方法论，并涵盖 Morgan Stanley、半导体、供应链和 Klarna 等案例研究。

引言

本文记录了 2025 年前 Palantir 前沿部署工程师（FDE）Apoorv Agrawal 与 OpenAI FDE 负责人 Colin Jarvis 之间的一次对话。他们探讨了为什么在模型能力日益增强的情况下，OpenAI 仍在不断扩大 FDE 团队，以及 FDE 模式与传统咨询有何不同。

01 为什么更强的模型需要更多 FDE

Colin Jarvis 于 2022 年 11 月加入 OpenAI，就在 ChatGPT 发布前几周。早期的企业项目（Morgan Stanley、Klarna）表明，仅仅交付 API 和文档，很少能让客户真正走向生产环境。可靠的路径是：工程师驻场，深入理解客户的数据、流程，以及一线用户的实际工作方式。

Morgan Stanley 案例研究

2023 年，Morgan Stanley 希望利用 GPT-4 为财富顾问呈现内部研究成果——这在 RAG 尚未形成成熟工程模式的年代是一个典型的 RAG 场景。技术管线（检索调优、护栏）在 6–8 周内就已跑通。随后的 4 个月则花在了试点、标注、评测驱动的迭代，以及建立顾问信任上。由于 GPT-4 是概率性的，团队无法像传统软件那样保证确定性的输出。他们让顾问在实际工作中使用该系统，对结果进行标注，积累评测集，并针对真实失败案例进行迭代，同时保留对照源文档验证答案的能力。

结果：顾问采用率约达 98%，研究报告使用量增长约 3 倍。Apoorv 的心得是：“通过迭代建立信任，而不仅仅依靠技术卓越。”生产就绪需要回答这些问题：答案能否被验证？关键操作是否有防护？模型错误能否被追溯？用户是否愿意把工作流程托付给这个系统？FDE 的工作正是存在于“模型能做到”与“企业敢使用”之间的鸿沟之中。

02 部署 AI Agent：并非从第一天起就完全自主

半导体验证 Agent

在欧洲一家半导体公司，OpenAI 的前沿部署工程师花了数周时间梳理芯片研发价值链，并将重点放在验证环节——据估计，工程师 70–80% 的时间都花在运行测试、修复 Bug 和处理遗留兼容性问题上。最初的 Agent（使用 Codex）不修改代码，只负责调查故障——阅读日志、检查代码、生成带有假设根因的工单。只有在工程师信任这些调查结果之后，团队才加入执行环境，让 Agent 能够运行测试、观察结果并迭代修复方案。该工具最终演变为一个调试调查与分诊 Agent，目标是让简单问题在早晨之前得到解决，复杂问题在早晨之前完成预调查。

评测驱动开发

Colin 强调，真实的工程工作流涉及跨系统的 20 多个连续操作。OpenAI 首先与领域专家一起构建真实轨迹，创建带标签的评测集，然后针对这些评测集进行开发。LLM 驱动的能力在评测验证通过之前，不被视为完成。

汽车供应链编排器

对于一家亚太地区汽车制造商，OpenAI 将数据保留在现有系统中，并为 LLM 编排器构建了 API。在一个演示场景中（对中国→韩国出口征收 25% 关税），系统识别出受影响的零部件，分析了成本传导，并重新优化了采购方案。关键在于，硬性业务规则（如双源采购要求、交期限制）被编码为确定性约束，而不是提示词。Colin 的原则是：“只要能用确定性方法，就用确定性方法。”模糊的语义判断交给 LLM；需要 100% 正确性的规则交给确定性代码。验证路径让用户能够检查底层数据表。优化使用了模拟器：模型调整参数，运行多个场景，比较成本/交付的权衡，并推荐一个仍能通过确定性验证的方案。

Apoorv 总结了两大支柱：使用评测驱动开发，以及有意识地在确定性与概率性之间进行权衡。Agent 的成熟度不是以自主步骤数来衡量，而是以每扩展一项权限时都能增加一层可验证性的机制来衡量。

03 Klarna：从定制项目到可复用产品

Apoorv 提出了对 FDE 的经典质疑：这不就是咨询吗？Colin 以 Klarna 客服项目作为回答。早期，数百条政策使得手写的提示词和工具调用难以维护。团队将指令和工具参数化，为每个意图配备评测，并将规模从约 20 条政策扩展到 400 多条。

在解决 Klarna 的问题之后，他们提炼出一个通用框架（后来以 Swarm 之名开源）。一次成功还不够；他们在更大、更复杂的项目（如 T-Mobile）上验证了这些基础组件。直到那时，FDE 团队和产品团队才将其产品化为 Agents SDK 和 AgentKit。OpenAI 将 FDE 定位为一支 0→1 团队：深入攻克最棘手的具体问题，然后移交给规模化团队或合作伙伴。

Apoorv 的“吃下痛苦 → 排出产品”框架：首次项目大约只有 20% 的代码可复用；做过 2–3 个类似项目后，可复用比例达到约 50%；只有到那时才推给平台团队。危险在于过早泛化——在发现真正的问题之前就构建通用解决方案。Colin 提醒创始人：要弄清楚 FDE 到底是为了服务收入，还是为了产品发现。两者混在一起会导致公司变成咨询店，因为短期的服务收入是会上瘾的。

OpenAI 针对两类问题：(1) 有明确产品假设的领域（如客服、文档生成），需要设计合作伙伴；(2) 极其困难的领域问题（半导体、生命科学），可能反哺研究。经济价值必须在 1000 万至 10 亿美元以上区间。截至访谈时，OpenAI 的 FDE 团队已从 2 人增长到 39 人，年底目标为 52 人，且无意成为数千人规模的实施部门。

04 超越 MCP：缺失的逻辑 / 元数据翻译层

被问及下一个重大机会时，Colin 指向的不是新的模型架构，而是将企业原始数据和隐藏的业务逻辑翻译成 LLM 真正能用的东西。数据存放在数据仓库、SharePoint 和内部系统中；逻辑则存在于没有文档记录的工作流里。MCP 连接器能让模型调用某个系统，但不会告诉它何时该把数据仓库的数据与 SharePoint 文档结合，也不会告诉它如何应用隐含的业务规则。FDE 们反复构建轻量级的“逻辑层”或“元数据翻译层”来弥合这一鸿沟。

Apoorv 将此与 Palantir 的 Ontology 联系起来。Colin 认同这一挑战并不新鲜——数据工程领域早就争论过集中式与虚拟访问层——但消费者变了：如今 LLM 会编写查询并组合数据，因此元数据、语义和数据组织方式直接决定了 Agent 的正确性。

未来：面向专业领域的微调

Colin 的长线押注是微调。随着 Agent 编排、工具使用、评测、标注和执行环境的成熟，团队可以更容易地生成训练数据、快速标注、构建训练集，并针对特定的 GenAI 用例（芯片设计、药物发现）微调模型。过去，这些领域缺乏足够的真实任务数据；现在 Agent 系统可以记录过程、评估结果并整理数据集。下一阶段可能不只是更复杂的 Agent 工作流，而是通过微调将某些能力蒸馏回模型本身。

从摩根士丹利、半导体、供应链、Klarna 到 T-Mobile，模式始终一致：模型撞上的是企业约束——信任、评测、数据、业务规则、环境限制——而不是原始智能。FDE 进入最具体的问题，解决它们，然后提炼出可成为产品的原语，而这些产品的生产闭环最终可能反哺模型改进。正如 Apoorv 总结的：“客户项目不是终点，而是产品发现的起点。”

已登录的读者可以通过 BestHub 的受保护跳转链接打开原文来源。

本文由原始资料提炼、总结后转载发布，仅供学习与参考之用。如您认为其侵犯了您的权益，请联系我们，我们将及时处理。

DataFunTalk

致力于分享和探讨大数据与 AI 技术应用，旨在赋能百万数据科学家。定期举办技术直播分享，并整理发布大数据、推荐/搜索算法、广告算法、NLP、智能风控、自动驾驶以及机器学习/深度学习等领域的文章。

社区反响如何

值得您花时间阅读吗？

0 条评论

有深度的读者会在这里留下实地笔记、不同意见以及来之不易的实操细节。