Forward Deployed Engineering

Forward Deployed Engineering（工程师个体称 Forward Deployed Engineer，缩写 FDE）指把工程团队直接嵌入客户现场、围绕客户最难的问题构建可上线系统的工作方式。这个角色最早由 Palantir 推广；OpenAI FDE 团队由该文作者于 2025 年初创立，定位是弥合「deployment gap（部署鸿沟）」——模型看起来具备的能力与人们能在真实工作中可靠使用的能力之间的距离。中文社区译法不统一（前沿部署工程师 / 前线部署工程师 / 前置部署工程师均有使用），本库保留英文原名。

deployment gap 与 Capability Overhang（使用侧的能力闲置）是近亲但侧重不同：overhang 描述「能力已到、用户没用上」，deployment gap 描述「模型在 benchmark 上表现好、但放进真实变量与约束里干不了活」。FDE 的解法是双头的——模型今天能做的，与产品团队和客户一起做成可复制的方案；模型还做不到的，与 Research 一起把缺口定义清楚、推动下一版模型补上。

核心价值观：先要结果

OpenAI FDE 每次团队会议都放同一页 slide：Start with the outcome, do what it takes to succeed, then follow with scale（先要结果，想尽办法做成，然后再规模化）。顺序不可交换——LLM 让「快速做出一个 demo」变得容易，但 impressive demo 与生产可依赖之间隔着全部难活；正确的路径是先用速度把有价值的东西送进用户手里、弄清什么在实践中站得住，再放大站得住的部分。

这条路径对应一张能力曲线：FDE 把一个无人解决过的难题先做成 zero-to-one 方案，随着底层技术进步再把方案提炼成可复用包。它同时定义了 FDE 的「自我淘汰」标准：如果一次交付把这类问题的门槛抬高到下个客户不再需要 FDE，这次交付就算成功。

2025 年中，约 15 名 FDE 与一家大型半导体客户共建 10+ 个用例，目标是把芯片验证流程 AI 原生化（directed test generation、root cause analysis 与调试、architecture assistant——验证约占该项目 70% 的工作量）。部分 FDE 入职才几天、从未做过半导体，靠嵌入客户验证团队、业余补课芯片设计、与工程师共建 Evals（评估）完成学习。3–6 个月后全部用例进入生产：

指标	结果
AI directed test generation 节省时间	约 48%
kernel 优化带来的性能提升（中位数）	22%
调试耗时	数周压缩到数小时

复盘时客户的首席硬件官问的是「你们来之前是做芯片设计的吗？」——这引出 FDE 的人员原则：第一天不需要懂行业，但把行业学会是 FDE 自己的责任；团队则按 generalist 与领域专家混编（生命科学方向即由有科研背景的 FDE 去赢得 pre-clinical drug discovery 研究者的信任）。在编码助手把软件越做越快的背景下，理解客户业务反而更重要。

其他已披露的客户结果：

客户	领域	结果
John Deere	农业精准支持	基于 See & Spray（相机 + 机器学习识别杂草，减少化学品使用最高 70%）用 OpenAI API 把农民支持个性化、规模化：自然语言答疑、配置指导、发现设备未发挥的潜力
Thrive Holdings（Crete 会计事务所）	税务	Tax AI 试点处理 7,000 份报税、吞吐量提升约 50%；最难 rental-property 报税用 6 周工程 + 从业者复核做到 90% precision/recall，沉淀出可复用模式后推广到其他复杂税表，再扩展到 bookkeeping、audit、IT support
大型电信客户	客服语音	语音占其客服量约 90%、比 chat 更难 contain；scoping 时模型关键 eval 只有约 60%，引入 Research 后六个月内随模型 snapshot 依次到 80%、90%+，达到生产门槛；产出的 voice model 复用回该客户、其他定制客服部署与 Presence 托管部署

电信案例展示了 FDE 的第二种自我淘汰：模型当下做不到的工作，由客户承诺一起攻克、FDE 负责界定问题并搭建平台、Research 负责用 successive model snapshots 关闭能力缺口——把「今天的模型解不了的问题」变成「未来模型能交付的能力」。这要求 FDE 敢于在 scoping 时直接告诉客户「模型现在到不了」，而不是绕开 eval 造出好看的演示。

可复制的路径：从专用代码到公共 harness

第一个半导体项目证明了工作流有效，但每个用例都带着太多定制集成，无法推广到下一个团队。随着 Codex 能力增长，一位 FDE 重建了应用、团队把所有用例迁到以 Codex 为核心的公共 harness 上：定制应用变成基于 Codex 原语的 plugin 和 Agent Skills（技能），Codex 本身成为交互界面，原先为各用例写的终端 UI 和 CLI 全部退役。结果是每个项目砍掉约 90% 的定制代码。

以文中「incident analyst」（芯片验证事故分析）用例为例，重构前后的架构对比：

flowchart TB
    subgraph BEFORE["Before：多 Agent 架构"]
        TC1["Task context"] --> A1["Incident analyst"]
        SA1["Specialized agent #1\nhypotheses generator"] -->|Hypothesis 1..n| A1
        SA2["Specialized agent #2\nSpec expert"] -->|Spec versions 过滤 → Specs| TC1
        SA3["Specialized agent #3\nCode analyst"] -->|Ripgrep / Read lines → Code repo| TC1
        SA4["Specialized agent #4\nInteractive incident analyst\n（仅交互模式，读 Jira ticket / 用户上下文）"]
        CT1["Custom tools：List logs\nTail lines / Read lines"]
        A1 -->|Custom tools| CT1
        A1 -->|Artifacts .log/.txt/.json| TC1
        A1 -->|TB & RTL.md + Error snippet| SA1
        A1 -->|RCA report 1..n| SA4
    end
    subgraph AFTER["After：以 Codex 为核心"]
        TC2["Task context"] -.-> REPO["Code repo"] & ART["Artifacts .log/.txt/.json"]
        ART --> ERR["Error snippet"] --> CX["Codex\n（Codex harness）"]
        TB2["TB & RTL.md"] --> CX
        SK["Skills"] --> CX
        CUS["Custom tools"] -.->|MCP| CX
        CX --> RCA["RCA report\n（写回 artifacts）"]
        CX --> SV["Spec versions"] --> SE["Spec expert\n（保留的 specialized agent）"] --> SPECS["Specs"]
    end
    BEFORE ==> AFTER

这次重构不只是省代码，它改变了交付经济性：受 Codex 集中改进的红利摊薄了每个用例的 glue code；关键功能打包成 skills/plugins，可互相分享，也可由客户的 AI CoE 统一管控；向新团队扩展简化成「换 connector / MCP server + 重建 eval（连建 eval 也有 skill）」。文中的量化对照是：2026 年 8 月一个用例，初始部署花两个月，扩展到第二个团队只用一天。

与产品和研究的关系

FDE 的产出会回流成平台资产。OpenAI Presence（企业语音与聊天 Agent 托管产品）就是从真实客户部署长出来的：工作始于开源项目 Swarm，经 Agents API 演化，把各次部署中沉淀的公共构件搬进产品，如今一个客户超过一半的来电由 AI 处理；voice model 等单客户攻关成果也复用到 Presence 的托管部署。FDE 团队的验收标准由此构成闭环：每一次 engagement 都让「下一个客户的起点」更高——产品更容易部署、模型能处理更难的任务、定制工作更少。

方法论层面还有两条约束：一是大多数 LLM 开发场景适用奥卡姆剃刀，「最简单的方案最好」，在一个被夸大话术污染的行业里要造的是现场的人可以依赖的可靠系统；二是团队文化——「人人都想造前所未有的东西，愿意做到达那里所需的活的人更少」，FDE 的工作量恰恰在后者。

关联

Capability Overhang — 部署鸿沟的使用侧孪生问题：能力已到而用户没用上
Evals（评估） — FDE 判断「模型今天能不能干这活」的标尺，也是向 Research 定义缺口的共同语言
Codex — FDE 公共 harness 的核心原语，插件与技能的平台
Agent Skills（技能） — 定制应用被打包成的可复用资产形态
Model Context Protocol（模型上下文协议） — 定制工具与新团队 connector 的接入标准
OpenAI Presence — 从 FDE 部署沉淀出的企业 Agent 托管产品
Agents API — Swarm → Agents API → Presence 演化路径中的平台层
Harness Engineering（驾驭工程） — 与 FDE 互补的工程视角：把模型、工具、评估、运营组合成生产系统
企业 AI 原生转型 — FDE 交付模式所服务的企业侧进程