FDE 正在分化：企业 AI 交付链条被重新拆开了

过去一年，Forward Deployed Engineer，简称 FDE，突然变成了 AI 行业里的高频词。

很多人第一反应是：这是不是又一个新岗位名称？是不是把“售前工程师”“解决方案架构师”“技术顾问”重新包装了一遍？

如果只看名字，确实容易这么理解。

但最近几个岗位信号放在一起看，事情没有这么简单。

Databricks 正在招聘 AI Engineer - FDE，面向美国联邦政府客户。岗位描述里有一个很关键的表述：AI FDE 团队是一个高度专业化、客户面向型的 AI 团队，负责帮助客户构建并生产化 first-of-its-kind AI applications，也就是过去没有标准模板、第一次在真实业务中落地的 AI 应用。

这句话很重要。

它说明 FDE 不是单纯“帮客户部署软件”，而是在客户现场，把数据、模型、业务流程和生产系统连接起来。

换句话说，AI 进入企业之后，真正困难的地方不再只是模型能力，而是模型如何进入真实组织。

一、Databricks 的 FDE：从数据平台走向 AI 生产化

Databricks 的这个岗位，重点不是“会不会用大模型”，而是能不能把 GenAI 应用真正做成生产系统。

岗位要求里提到 RAG、多 Agent 系统、Text2SQL、fine-tuning，也提到评估、优化、云平台部署，以及 Databricks Intelligence Platform、Spark 等大规模数据处理能力。

这背后的逻辑非常清楚：

企业 AI 不是漂浮在聊天窗口里的回答能力，而是建立在数据、权限、流程、评估和系统集成之上的生产能力。

很多企业今天做 AI 项目，最容易卡在两个地方：

第一，有模型，但数据不可用。
第二，有 Demo，但无法上线。

Databricks 的 FDE 正是站在这两个断点之间。

他既不是纯数据工程师，也不是传统 AI 研究员，更不是普通顾问。他的任务是把客户的业务问题，拆成可以由数据平台、模型能力和应用系统共同承接的工程方案。

所以 Databricks 代表的是一种非常典型的 FDE 类型：数据平台型 FDE。

它的核心任务不是单点部署模型，而是把数据、模型和应用真正生产化。

二、GitLab 的 FDE：从写代码走向 Agent 平台治理

GitLab 的岗位信号也很值得看。

GitLab 出现了 Field Strategist, Forward Deployed Engineer 和 Staff Forward Deployed Engineer。它的重点不是单个 AI 应用，而是 GitLab Duo Agent Platform 在复杂企业环境中的落地。

岗位描述里提到：自托管、受监管、受限环境、AI Gateway、身份、Runner、网络边界、模型连接、治理控制、参考架构。

这些词放在一起，指向一个新的问题：

当 AI Agent 进入软件研发流程之后，企业需要的不是“多一个智能助手”，而是一套可治理的 Agent 平台。

因为 Agent 不只是回答问题。它可能读代码、改代码、调用工具、触发流水线、接触敏感数据，甚至参与交付流程。

这就带来一连串组织问题：

谁允许 Agent 调用什么工具？
哪些代码可以被模型读取？
模型输出如何审计？
在内网、隔离网络、合规环境里，Agent 如何运行？
当 Agent 参与软件交付，责任边界怎么算？

GitLab 的 FDE 角色，本质上是在解决这些问题。

它不只是帮客户“用上 GitLab Duo”，而是把复杂客户现场的问题，转化成参考架构、迁移工具、治理模板和产品反馈。

所以 GitLab 代表的是第二种类型：Agent 平台型 FDE。

它的核心任务，是构建 Agent 平台、治理边界和工作流，让 Agent 在企业系统里可控、可审计、可扩展。

三、Amazon 的 FDE：从咨询建议走向现场集成

Amazon 出现的 Forward Deployed AI Integrator，则更像第三类信号。

这个岗位不是写“战略建议”，而是嵌入 Field Engineering 团队，识别高价值 AI 工作流机会，推动 AI 辅助工具采用，并把成功实验变成区域标准。

注意这里的关键词：嵌入、工作流、采用、标准化、生产力结果。

这说明 Amazon 看到的问题不是“有没有 AI 工具”，而是现场工程团队里已经出现大量零散尝试，需要有人把这些尝试系统化。

很多企业现在也处在同样阶段：

员工已经开始用 AI。
团队已经有局部实验。
但组织还没有统一标准。
成功经验没有沉淀。
AI 带来的效率提升也没有被管理层清楚看见。

这时候需要的不是一个“AI 布道师”，而是一个现场集成者。

他要进入真实工作现场，理解工程师如何排查问题、写报告、做分析、构建工具，再判断哪些流程适合被 AI 改造，哪些不适合。

所以 Amazon 代表的是第三种类型：现场集成型 FDE。

它的核心任务，是把 AI 接入客户或内部现场基础设施，让 AI 从个人实验变成组织标准。

四、FDE 已经不是一种岗位，而是四种交付角色

把 Databricks、GitLab、Amazon，以及 OpenAI、Anthropic、Google Cloud、ServiceNow 等公司放在一起看，可以看到一个更大的趋势：

FDE 正在分化。

它不再是一个统一岗位，而是沿着企业 AI 交付链条，拆成了几类不同角色。

这张表背后，其实是企业 AI 交付逻辑的变化。

过去企业软件的交付链条比较清楚：

产品公司负责软件。
实施公司负责上线。
客户 IT 负责维护。
业务部门负责使用。

但 AI 打破了这个分工。

因为 AI 系统不是安装完就结束。它需要持续学习客户语境，理解业务流程，接入数据系统，经过评估和调优，再嵌入组织决策链条。

这使得“交付”不再是项目结束前的一段工作，而变成产品能力的一部分。

五、为什么企业越来越需要 FDE？

原因很简单：AI 的价值不在模型本身，而在模型进入组织后的行为改变。

一个 AI 应用真正上线，至少要经过五层转化：

从模型能力，转化为业务场景。
从业务场景，转化为数据和工具链。
从数据和工具链，转化为可运行应用。
从可运行应用，转化为组织流程。
从组织流程，转化为可衡量结果。

传统售前只能讲清楚第一层。
传统实施通常做到第三层。
但企业真正买单的是第五层。

FDE 的价值，就在于打通这五层。

他既要懂技术，也要懂客户现场；既要能写代码，也要能判断业务价值；既要解决当下交付问题，也要把重复出现的问题反馈给产品和工程团队。

这也是为什么越来越多公司把 FDE 放在工程、产品、专业服务和客户成功之间。

FDE 不是边缘角色，而是连接产品能力与客户结果的关键接口。

六、对企业的启发：不要只买 AI 工具，要设计 AI 交付结构

对企业来说，这个趋势有一个直接启发：

未来评估 AI 供应商，不能只看模型参数、功能清单和演示效果。

更要看它有没有能力帮助你完成生产化落地。

具体来说，要看四件事：

第一，是否能理解你的真实业务流程。
第二，是否能处理你的数据、权限和系统约束。
第三，是否能把 Demo 变成可运营、可评估、可迭代的应用。
第四，是否能把一次性项目沉淀成组织能力。

如果没有这些能力，AI 很容易停留在“看起来很聪明”的阶段。

但真正的企业 AI，不是让模型表现得像人，而是让组织多出一条新的决策与执行链条。

FDE 的兴起，说明企业 AI 正在进入下一阶段。

第一阶段是模型能力竞争。
第二阶段是应用场景竞争。
第三阶段是交付结构竞争。

谁能把 AI 放进真实组织，谁才能获得长期价值。

所以，FDE 不是一个新头衔。

它是 AI 从演示走向生产，从工具走向组织，从能力走向结果时，必然出现的新分工。