OpenAI FDE负责人Colin Jarvis今天发了一篇工程博客，讲他们的Forward Deployed Engineering团队到底在做什么。
Codex 出来的时候，OpenAI FDE 团队里有人问 Colin Jarvis：等 Codex 能直接秒掉我们花几个月做的东西，我们怎么办？
Jarvis 的回答是，那说明干得不错。如果团队每隔几个月就让自己过时一次，就是干对了。
FDE是OpenAI的一支特殊工程团队，2025年初由Colin Jarvis组建。它解决的问题，Colin称之为“部署差距”，模型看起来什么都能干，真到了客户手里，往往不是那么回事。FDE的工程师直接住进客户公司，跟业务专家一起把AI从“能跑demo”推到“能上生产”。模型当前能做到的，跟产品和客户一起把方案做可复制；模型还做不到的，跟客户和 Research 一起明确缺口、推动改进。每次服务完一个客户，下一个客户的起点应该更高。如果下次这类问题客户已经不需要 FDE 了，那才叫做好了。
John Deere 是个很好的例子。这家 200 年的农业公司，难题是怎么把给农民的个性化建议规模化。它有个 See & Spray 精准除草技术，用相机和机器学习识别杂草再喷洒，而不是整片田喷药，化学品用量最多能降 70%。但好处能不能兑现，取决于农民会不会配置设备、规划农季、随条件调整。John Deere 接 OpenAI 的 API 之后，AI 能用自然语言回答农民问题、给配置指导、识别设备是不是没发挥出全部潜力，还能帮农民理解自己从技术里拿到了什么价值。这不只是一次两次的交互，而是贯穿整个客户旅程的持续引导。
先做出结果：半导体
Jarvis 给团队定的一条原则：先做出结果，再谈规模化。他每次开会放一张幻灯片，配的是 Harrison 的两台航海钟。H1（1735）先让它存在，H4（1759）再让它变好。
2025 年年中，大约 15 个 FDE 和一家大型半导体客户合作，铺了 10 多个用例，目标是把芯片验证流程做成 AI 原生，覆盖定向测试生成、根因分析和调试、架构助手三个方向。验证在这个行业占项目工作量的约 70%。
有些 FDE 入职 OpenAI 才几天，从来没碰过半导体。他们直接嵌入客户的验证团队，业余时间啃芯片设计，再跟工程师一起设计 Eval（评估集，判断 AI 输出是否达到业务要求）和 Harness（跑评估的框架），看 AI 能不能生成有用的测试、正确诊断芯片故障。
前 3 到 6 个月，几个场景都上了生产：
- 定向测试生成省约 48% 时间
- 通过内核优化带来 22% 的中位性能提升
- 几周的调试压缩到几小时
复盘的时候，客户的首席硬件官问了一句：你们之前是不是干过芯片设计的？
Jarvis 的说法是，FDE 不需要第一天就懂行业，但学它是你的责任。团队里混着通才和领域专家，写代码越来越快之后，懂客户的业务反而更重要。生命科学那边同理，FDE 的科学背景帮他们跟做临床前药物发现的研发人员建立信任，像靶点验证与优先级排序、基因表达分析、化学合成路线重建这类活。
让成功可复制
项目上线只是第一步。
Jarvis 把 FDE 的工作拆成三个阶段：拿一个没人解决过的难题，先做出从零到一的方案，等技术条件成熟了，再把它变成可复用的包。
随着 Codex 能力提升，团队把原来的定制应用逐步改造成通用 Harness 上的 Skills 和插件。Codex 本身成了交互界面，原来各场景单独写的终端界面和命令行工具全部退役。
每个项目大约 90% 的定制代码被删掉。删完之后，三个变化：Codex 的集中化改进直接惠及所有用例，每个场景需要的胶水代码持续减少；关键功能打包成 Skills 和插件，由客户的 AI CoE 集中控制，团队间共享很容易；扩展到新团队时，基本只需要换上新的连接器和 MCP server，再用一个 Skill 生成新的 Eval，就能跑起来。第一次部署花了两个月，复制到第二个团队只用了一天。
Jarvis 管这个叫"让自己过时"的一种方式。之前为上线做的那些工作，界定了什么才是重要的。底层产品变强之后，就能把大部分定制实现换掉，价值还在。顺序很重要：LLM 让你能快速把东西做出来，先趁这个速度把有价值的东西送到用户手里，在实践中看清什么扛得住，再去规模化。
能删掉这 90%，本身就是 FDE 团队的目标之一：不断减少别人对自己的依赖。有网友点得很准，Eval 把边界跑清了才敢动，回归集里补了负样本以后，删代码反而变快。以前删不动，是因为回归集里只有 happy path。代码可以退役，踩过的坑不能跟着失忆。
这个判断比 90% 这个数字更值得琢磨。企业 Agent 项目里真正留得下来的，是 Eval、失败案例、沉淀成 Skill 的业务知识。为了补模型短板写的胶水代码，每次模型升级都该重新审一遍，随时准备删。如果你每接一个新客户还在从头写一套，说明东西还停在定制应用这一层，没沉淀下来。
同一套原则在别的项目里反复出现。
OpenAI Presence，那个做企业语音和聊天 agent 的产品，本身就从真实客户部署里长出来的。从 Swarm 起步，经过 Agents API 演化，如今有客户超过一半的来电由 AI 处理。每把一个部署推进生产，团队就看清了哪些问题真要定制方案、哪些构件别的团队也能用。这些构件被收进 Presence，开发者不用重搭底层基础设施就能自动化受监管的工作流。每次部署都在塑造产品，给下一个客户更好的起点。
Tax AI 跟 Thrive Holdings 合作，给 Crete 的会计师事务所做报税。FDE 和 Research 一起，跟着对方的工程师和会计师，试点期间处理了 7000 份税单，吞吐量提升约 50%。最硬的骨头是租赁房产税单的自动化，花了六周工程加从业者评审才做到 90% 的精确率和召回率。过程中留下的可复用模式，让团队能更快地把 Tax AI 扩展到其他复杂税表上。现在同样的方法正在往记账、审计、IT 支持上铺，系统通过从业者的反馈和真实使用持续改进。
补上能力缺口
有时候不是因为产品能简化，而是模型本身还干不了这活。只做现有模型已经能做的，就永远发现不了 Research 下一步要补的能力缺口。
他们跟一家大型电信客户本来就有客服平台，客户想扩展到语音。语音占客服流量的约 90%，比文字贵，口音、语调、延迟和准确率都要做到生产级。评估阶段，模型在关键 Eval 上只有约 60%，函数调用和指令遵循能力不够。他们把问题摆给客户，拉 Research 进来。FDE 搭平台、定义模型该做什么，Research 补能力缺口，每次模型快照都拿客户的需求测一遍。
六个月里，关键 Eval 从约 60% 涨到 80%，再到 90% 以上。
这个语音模型现在支撑那个客户的部署，也支撑其他定制客服部署和 Presence 的托管部署。一个客户业务里碰到的问题，帮出了能服务很多人的改进。Jarvis 把这叫做让自己过时的另一种方式：把一个今天模型解决不了的问题，变成未来模型能交付的能力。回报远超花在任何单一客户身上的时间。
去找更难的问题
Jarvis 常跟团队说，LLM 开发里大多数情况奥卡姆剃刀都适用，最简单的方案最好。这家公司以最前沿的研究著称，这个行业又满是夸大其词，他们想做的是在人手里可靠运行的东西。每次服务，要么让产品更好部署，要么让模型能处理更难的任务，要么让下一个客户少写一点定制代码。
全文结尾，那个问题只有一个答案：去找更难的问题。
FDE说白了就是人类脚手架，在AI还不足够强时，临时辅助之用。有网友评论说，能删代码反而说明架构真沉淀下来了。也有人问：删掉90%定制代码，那之前几个月到底在写什么？答案是，写的是对业务边界的理解，这些理解最后变成了Eval和Skill。
做企业AI落地的，建议把这篇收藏。做FDE哪些是持久的，哪些是临时的，有了边界才有沉淀。如果你每接一个新客户都还在从头写一套，说明东西还停在定制应用这一层，没沉淀下来。
原文在这里 (https://openai.com/index/forward-deployed-engineering-means)。