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

企业AI的稀缺资源正从模型能力转向部署能力

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

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

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

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

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

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

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

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

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

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

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

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

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

想象一个采购Agent。

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

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

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

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

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

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

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

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

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

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

对业务结果负责。

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

对生产系统负责。

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

对产品学习负责。

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

但FDE不是万能解药

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

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

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

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

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

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

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

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

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

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

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