前线部署工程在 OpenAI 意味着什么
我们做什么、如何开展工作，以及如何解决企业最棘手的问题，带来切实成效
作者：Colin Jarvis，OpenAI 前线部署工程负责人
Codex 推出时，团队里有人问我：“如果 Codex 一次就能完成我们过去几个月才构建好的用例，我们该做什么？”
这个问题直指核心：前线部署工程在 OpenAI 究竟意味着什么。我们与客户并肩工作，理解他们最棘手的问题，并构建值得信赖的解决方案。从中获得的经验帮助我们塑造产品，也为研究团队提供了需要解决的具体问题。
这就是进步。如果每隔几个月，我们都能让自己变得不再必需，就说明前线部署工程师团队尽到了职责。
我在 2025 年初组建了这支团队，旨在弥合我们所说的“部署鸿沟”：也就是模型看似具备的能力，与人们在工作中能够可靠使用的能力之间的差距。
模型能力的发展速度，已经超过了将其投入实际应用所需的系统和流程。有时，缺少的是一款产品。有时，模型在基准测试中表现出色，却无法在现实中的各种变量和约束下完成工作。
我们专注于客户最棘手的问题。对于当前模型已经能够胜任的任务，我们与产品团队及客户合作，让解决方案可以复用；对于模型能力尚有不足的地方，我们与客户和研究团队共同明确差距，推动改进。我们的目标是让每一次合作都为下一位客户留下更好的起点。如果我们把基础能力提升到这样的水平：下次客户解决同类问题时，不再需要前线部署工程师，那么我们就出色地完成了工作。
对于拥有 200 年历史的农业企业约翰迪尔而言，挑战在于如何大规模地为农民提供个性化建议。
See & Spray 精准除草技术就是一个例子。它利用摄像头和机器学习来识别杂草并进行定点喷洒，而非对整片农田施药，从而将化学药剂用量最多减少 70%。
但要实现这些效益，农民必须懂得如何配置这项技术、规划农时，并随条件变化调整作业方式。
约翰迪尔部署了 OpenAI 的 API，以便大规模提供个性化支持。
AI 可以用自然语言回答农民的问题，提供有针对性的设置指导和建议，识别设备何时可能未发挥全部潜力，并帮助农民了解这项技术带来的价值。
机会并不局限于单次互动：我们可以在整个客户旅程中提供切合需求的指导，帮助农民更好地使用设备，同时提高效率和可持续性。
这正是 OpenAI 前线部署工程师致力于解决的挑战：帮助组织将 AI 能力转化为系统，在复杂的真实环境中创造实际价值。
但这些问题往往高度开放，可能没有公认的标准答案，也没有现成的方法可循。人人都想创造前所未有的东西，但愿意为此付诸必要行动的人要少得多。
要找到优秀的前线部署工程师，同时不断提高“足够好”的标准，就需要持续试验和实践。
每次前线部署工程师团队会议开始时，我都会展示一页幻灯片，上面写着一条核心价值观：“从目标成果出发，为成功付诸必要的行动，再实现规模化。”
一个令人惊艳的演示，往往能赢得许多认可，直到有人追问它在现实中是否管用。
我们的职责是解决客户的问题，并让方案达到我们敢于对其生产环境表现负责的标准。
2025 年年中，我们约有 15 名前线部署工程师与一家大型半导体客户合作，推进 10 多个用例。我们的目标是让其验证流程实现 AI 原生化，涵盖：
定向测试生成
根因分析与调试
架构助手
在这个行业中，验证工作可能占项目总工作量的约 70%。其中蕴藏着巨大的机会，也有许多可供切入的方向。
有些前线部署工程师几天前才加入 OpenAI，此前从未从事过半导体相关工作。他们深入客户的验证团队，利用业余时间学习芯片设计，并与工程师共同构建评估，检验 AI 能否生成有用的测试并正确诊断芯片故障。
在学习的同时，我们也为各个用例构建了定制执行框架。在最初的 3 至 6 个月内，所有用例都已投入生产，并开始有用户使用。这些投入的回报体现在以下指标中：
通过 AI 生成定向测试，节省约 48% 的时间。
通过内核优化，性能提升的中位数达到 22%。
将数周的调试工作压缩到数小时
当我们汇报这些成果时，首席硬件官问道：“你们来这里之前做过芯片设计吗？”
我们的前线部署工程师不必从第一天起就了解所在行业，但有责任主动学习。
随着编程助手加快软件开发速度，理解客户的业务变得更加重要。我们组建的团队兼具通才和领域专家。
你需要足够的知识来作出可靠判断，也需要足够的好奇心，去质疑那些将现状视为理所当然的假设。
例如，在生命科学领域，我们的前线部署工程师凭借科学背景，能够赢得研究人员的信任。这些研究人员从事靶点验证与优先级排序、基因表达分析、化学合成路线重建等临床前药物发现工作。这些专业知识让他们能够就如何改进工作流提出有依据的判断。
我们已经证明这些工作流能够创造价值，但要推广到另一个团队，每个工作流仍需要大量定制集成。接下来的挑战是，在保留这些成果的同时，让软件更易于部署和维护。
那时，Codex 的能力已经有所提升。一名前线部署工程师尝试围绕 Codex 重构应用，随后与团队合作，将这些用例迁移到以 Codex 为核心的通用执行框架上。
原先的定制应用变成了基于通用 Codex 基础能力构建的插件和技能。Codex 也成为了交互界面，使我们可以停用此前为各个用例单独编写的终端界面和命令行界面。
我们得以移除每个项目中约 90% 的定制代码，这改变了我们构建、维护和规模化推广这些工作流的方式：
我们可以直接受益于 Codex 的统一改进，减少各个用例所需的胶水代码
关键功能被封装为技能和插件，既方便团队之间共享，也便于 AI 卓越中心集中管控。这意味着，从一个团队推广到下一个团队，可能只需更换连接器或 MCP 服务器、构建新的评估（我们也有专门用于此项工作的技能），就能启动运行。
以 2026 年 8 月的一个案例为例，首次部署花了两个月。将解决方案推广到第二个团队，只花了一天。随着规模扩大，后续团队的接入速度越来越快，而且这一趋势还在持续：2026 年 8 月的一个用例中，首次部署花了两个月，第二个团队接入却只用了一天。
这就是让我们自己变得不再必需的一种方式。此前为投入生产所做的工作，让我们明确了真正重要的是什么。随着底层产品不断改进，我们可以替换掉大部分定制实现，同时保留它们创造的价值。
这就是顺序之所以重要的原因。LLM 让我们能够快速构建。利用这种速度，先把有价值的东西交到用户手中，了解哪些做法经得起实践检验，再将有效的做法规模化推广。
同样的原则适用于所有合作项目。
OpenAI Presence 是我们面向企业语音和聊天智能体的产品，诞生于实际的客户部署项目。这项工作从 Swarm（在新窗口中打开） 起步，随后通过 Agents API 持续演进。如今，已有一家客户通过 AI 处理超过半数的来电。
将这些系统部署到生产环境后，我们明确了哪些问题需要定制解决方案，哪些基础组件可供其他团队复用。我们将这些组件整合到 Presence 中，让开发者无需重建底层基础设施，就能更轻松地实现受监管工作流程的自动化。每次部署都推动了产品完善，也为后续客户提供了更好的起点。
在与 Thrive Holdings 的合作中，OpenAI 的 FDE 及研究人员携手工程师和会计师，为 Crete 旗下的会计师事务所开发了 Tax AI。在试点阶段，Tax AI 处理了 7,000 份纳税申报表，单位时间内的处理量增加了约 50%。
最棘手的挑战之一，是实现租赁房产纳税申报处理的自动化。经过六周的工程开发与税务专业人员审核，系统的精确率和召回率均达到了 90%。这项工作形成了可复用的模式，让 Tax AI 更容易支持其他复杂的纳税申报附表。
目前，各团队正将同样的方法应用于簿记、审计和 IT 支持 — 构建能够结合专业人员反馈和实际使用情况持续改进的系统。
有时，更好的产品能让我们简化已有系统；但有时，模型本身尚不能胜任任务。
如果我们只做当前模型已经能做到的事，就无法发现研究团队接下来需要弥补的能力差距。因此，我们许多重要合作都是从这些能力边界起步，由客户、前线部署工程师和研究团队共同投入，携手突破。
我们此前已与一家大型电信客户共同开发了客户服务平台，对方希望将其扩展到语音服务。
语音服务约占其客户服务总量的 90%。与聊天服务相比，在无需人工介入的情况下解决这些问题成本更高；要让口音识别、语气、延迟和准确率达到生产环境要求，也带来了一系列新的技术挑战。做好这件事，将为他们的业务带来显著改变。
在确定项目范围时，我们用关键评估来判断模型能否胜任生产环境中的任务，当时模型的得分约为 60%。我们已经触及了它的能力上限。模型在客户服务场景下的函数调用和指令遵循能力仍需提升。
我们向客户说明了这一点，并邀请研究团队参与。前线部署工程师与客户共同搭建平台，明确模型需要完成的任务。研究团队则着力弥补能力差距，陆续推出模型快照，让我们能够对照客户需求检验进展。
六个月内，模型在关键评估中的得分从约 60% 提升到 80%，随后超过 90%，达到了生产环境要求。
由此开发的语音模型如今不仅支持该客户的部署，还支持其他定制客户服务部署，以及通过 Presence 进行的托管部署。一家客户在业务中遇到的问题，帮助我们找到了能惠及更多客户的改进方向。
每一方的贡献都不可或缺。客户愿意投入，共同攻克模型尚无法解决的问题。前线部署工程师始终深入一线，明确问题、搭建平台，并从头到尾推动合作。研究团队则提升了底层模型的能力。
这是让我们自己变得不再必需的另一种方式：把当下模型无法解决的问题，转化为未来模型能够具备的能力。我们工作的回报，远不止于为某一位客户投入的时间。
我加入 OpenAI，是为了让 AI 真正帮助人们开展日常工作。这一初衷至今仍指引着团队。我经常对团队说，在 LLM 开发中，奥卡姆剃刀原则适用于大多数情况：最简单的解决方案就是最好的。我们所在的公司以尖端研究见长，而整个行业却不乏夸大其词的宣传。我们希望打造的是能可靠运行、让一线人员放心依赖的东西。
我们的目标是让每一次合作都为后续工作带来改进：让产品更易部署，让模型能够应对更难的任务，或减少为下一位客户提供解决方案时所需的定制工作。
如果你有想解决的难题，我们很愿意与你合作。如果你想帮助解决这些问题，我们期待你的加入。
那么，当 Codex 能够胜任我们花费数月才实现的工作时，我们该做什么？
去寻找更难的问题。
