读懂 FDE（一）：模型越强，为什么企业越需要 FDE 下场？

长期关注并参与企业 AI 转型与落地。在一些业务场景里，做过从 PoC、数据与权限接入，到上线验证和运营复盘的完整实践。有顺利跑通的，也有做到一半才发现问题定义错了、必须返工的。

所以我写企业 AI，不只想聊模型有多强，更关心三件事：AI 是否进入了真实流程？谁对结果负责？做完一次，有没有为下一次留下可复用的能力？

前面的《读懂 Palantir Ontology》系列，讲的是企业如何把数据、业务语义、逻辑、行动和权限接起来。但写到最后，还会遇到一个更现实的问题：

这套东西，究竟由谁进到现场，跟着用户一起做出来，再让它真正跑起来？

这就是我准备继续写 FDE 系列的原因。

接下来，我计划用 18 篇主线 + 3 篇番外（会不会有点多了），把 FDE 从一个热门岗位，拆成一套企业 AI 从 Demo 走向结果的方法：怎么找问题、做最小可行部署、处理数据和权限、设计评测、进入真实流程、证明 ROI，以及如何避免把软件公司做成高端外包。

今天是第一篇，我们先从一个看起来有点反常的现象说起。

2026 年，FDE 开始从 Palantir 的特殊打法，变成一批 AI 和云计算公司的正式组织选择。

• • 5 月 11 日，OpenAI 宣布成立 Deployment Company，并计划通过收购 Tomoro，从第一天带入约 150 名 FDE 和部署专家。
• • 5 月 21 日，Microsoft 与 EY 宣布五年联合投入超过 10 亿美元，由 Microsoft FDE 与 EY 行业和变革团队组成联合队伍。
• • 6 月 11 日，Anthropic 与 DXC 宣布合作，DXC 计划培训数以万计、进入客户组织的 Claude 认证 FDE。
• • 6 月 30 日，AWS 公布了10 亿美元级别的 FDE 投入，要把数千名工程师直接嵌入客户，在真实数据、治理和环境约束下共建 Agent 系统。

这些数字来自各家公司公告，有的还是投资和培训计划，不等于能力已经全部建成。但几家公司在短时间内做出相似动作，至少说明了一件事：

企业 AI 的稀缺资源，正在从「模型能力」转向「部署能力」。

模型越强，企业能想象的用途就越大。原来只敢用 AI 润色邮件，现在想让它处理客诉、审查合同、调整库存、安排维修，甚至改变一条核心流程。

可任务越重要，出错代价越高，模型之外的问题就越难绕开。

Demo 验证能力，生产系统承担后果

想象一个采购 Agent。

演示时，你给它三家供应商的报价单，它很快就能提取价格、交期和条款，再给出一份有理有据的建议。这一步确实比几年前强了很多。

可一旦进入生产，问题会立刻变成：

• • 哪个供应商实体才是 ERP 里的正确主体？
• • 报价和框架协议冲突时，应该信哪一个？
• • 这笔采购是否超过了申请人的授权范围？
• • 加急采购可以跳过哪些步骤，谁能批准？
• • Agent 能只提建议，还是可以写回 ERP、生成订单？
• • 建议被驳回后，是模型错了、数据旧了，还是业务有一个系统里没写的例外？

Demo 关心「它能不能给出一个好答案」。

生产关心「这个答案在什么语境下有效、谁有权采用、可以引发什么动作、失败后谁接管，以及结果如何回来」。

两者之间差的不是一个 Prompt，而是一整套业务、工程和组织能力。

FDE 出现的地方，正是产品和现实之间的缝隙

FDE 的全称是 Forward Deployed Engineer，常被翻译为前线部署工程师。

但如果只把它理解成「去客户现场安装系统的工程师」，就会漏掉最重要的部分。

OpenAI 现在的 FDE 职位说明很有代表性：FDE 从问题发现、技术定界、系统设计、开发，一直负责到生产发布。它的成功也不是「项目验收了」，而是看生产采用、对工作流程的可测影响，以及基于评测的现场反馈是否反过来改变产品和模型路线。

我更愿意用三个「负责到底」来理解 FDE：

对业务结果负责。

他不只接一张需求单，还要和业务方一起确认：什么问题值得解决，当前基线是什么，谁会真正使用，改变了哪个结果。

对生产系统负责。

他需要把模型接入真实数据、工具、权限、审计和业务流程，写能维护的代码，处理异常和回滚，直到它能被日常使用。

对产品学习负责。

他不能把每个客户的问题都留成一段私有代码。现场学到的连接方式、异常类型、评测样本、权限模板和产品缺口，要被沉淀为下一个项目能复用的能力。

这三种责任少一个，FDE 都容易变形。

没有业务结果，它会变成技术展示；没有生产工程，它会变成会写方案的咨询；没有产品学习，它会变成越做越重的定制外包。

Palantir 真正特殊的，不是把工程师派出去

FDE 被广泛关注之前，Palantir 已经用这种方式做了很多年。

Palantir 在 Architecture Center 里把 FDE 方法称为「人类版反向传播」：工程团队尽可能接近问题，与核心工程团队协同，持续综合现场反馈并发布新能力。

这个比喻的重点不在「驻场」，而在「反传」。

传统软件的理想分工，是产品团队在总部完成通用能力，销售、实施和客户成功再把它交付给客户。但在复杂企业环境里，客户往往无法事先写出完整规格。很多关键信息，只会在真实使用中暴露：

• • 用户嘴上说的流程，和他实际执行的流程不一样；
• • 系统里看起来很干净的状态，业务人员根本不相信；
• • 文档里有通用规则，真正决定结果的却是老员工才知道的例外；
• • 一个建议在界面里很完整，用户却因为需要重复录入三个系统而拒绝使用。

所以现场不只是交付终点，它还是产品研发的输入端。

为什么 AI 时代更需要这种回路？

第一，模型能力越通用，价值实现反而越本地。

同一个大模型可以进入制造、保险、零售和政府，但它在每家企业里要读的数据、能做的动作、不能越过的责任线，都是当地的。模型可以跨行业复用，业务上下文不会自动长出来。

第二，AI 是非确定系统，上线之后仍然需要运营。

传统软件的一个接口调用，对同样的输入通常有稳定输出。Agent 可能因为上下文、模型版本、工具返回和历史消息的不同，给出不同结果。这意味着团队需要真实样本、评测、升级机制、人工接管和持续复盘，不能把「发布」当作项目结束。

第三，很多企业 AI 产品还处在「问题和产品一起被发现」的阶段。

客户可以告诉你「我想要一个采购 Agent」，却很难在第一天准确说出它应该获得哪些数据、什么时候必须拒答、哪类决定要升级给人，以及最后如何算成功。这些不是等一份完整需求文档就能解决的，而是要在部署中一边做、一边学。

但 FDE 不是万能解药

这里需要先给大家泼一点冷水。

把工程师派到客户身边，是一种昂贵的组织选择。如果问题很标准，实施路径已经明确，一套配置化产品和正常客户成功就能解决，那么不应该用 FDE 堆人。

Decagon 的一次公开复盘就提到，早期前向部署容易让每个客户的边角问题都涌向工程团队，交付很快变成瓶颈。他们后来强调的不是「每个人更英雄地救火」，而是把每次定制里的重复工作变成自助能力和共用系统。

所以，真正健康的 FDE 应该同时完成两件事：

1. 1. 把这一次 zero-to-one 做成，直到客户在生产中用它解决真问题；
2. 2. 让下一次 zero-to-one 更便宜，把可复用的数据模式、评测、连接器、权限模板和交付方法留下来。

如果只有第一件，FDE 最终会变成高端外包。如果只有第二件，团队又会远离现场，重新回到「在办公室里猜客户需要什么」。

企业不一定要招 FDE，但需要有人承担 FDE 职能

对大多数企业来说，第一步不是马上新设一个 FDE 职位。

更实际的做法，是先检查项目里有没有人完整承担以下职能：

• • 从业务结果定义问题，而不是从模型功能出发；
• • 跟着真实用户跑完一次任务，看到系统外的补丁和例外；
• • 能亲自做出生产系统，也能在权限、合规和运营约束下做取舍；
• • 把驳回、失败和例外变成评测和产品输入；
• • 从项目开始就设计交接与退场，不让现场团队永久成为人肉接口。

这个人可以叫 FDE，也可以是企业内部的 AI 产品负责人、技术负责人和业务专家组成的小队。名字不是最重要的，但端到端责任不能是空的。

关于 FDE 的第一个结论

FDE 走红，不是因为模型不够强。

恰恰相反：正因为模型能做的事越来越重要，企业才更需要一类人走进真实环境，把业务上下文、生产工程和产品学习接在一起，并对最后的结果负责。

模型解决的是能力上限，FDE 解决的是这个能力能否穿过企业现实。