FDE：AI 落地最火的岗位，也可能是最短暂的岗位

推荐语

FDE岗位成AI落地新宠，却或如20年前咨询顾问般短暂？解析其价值本质与潜在风险。 核心内容： 1. FDE岗位现状：OpenAI等企业布局及岗位定义 2. FDE与咨询顾问的类比：知识差高溢价与行业认知扩散 3. FDE的核心使命：填补大模型与企业的能力断层及具体挑战

杨芳贤

53AI创始人/腾讯云(TVP)最具价值专家

最近参加一个 CIO 论坛时，我们聊到了一个现在硅谷非常热的岗位：FDE，Forward Deployed Engineer。

这两年 FDE 确实很火。OpenAI 已经专门建立 Forward Deployed Engineering 团队，招聘页面上可以看到医疗、法律、政府以及不同地区的大量 FDE 岗位；Anthropic 的 Applied AI 团队里，也已经出现 FDE、Technical Deployment Lead 等一系列类似角色。OpenAI 对这个岗位的定义也很典型：深入客户，理解问题，从技术方案、系统设计一直做到生产部署，再把客户现场发现的问题反馈给产品和模型团队。 Anthropic 也在持续扩充类似团队。

所以我并不认为 FDE 是一个“伪需求”。相反，在今天，它是真需求，而且很贵。

但越是看到 FDE 火起来，我越觉得它让我想起二十多年前的另外一个职业：咨询顾问。

而我恰好经历过那个时代。

一、FDE 为什么让我想起当年的 IBM 咨询顾问

我早年在 IBM 工作的时候，咨询顾问是一个非常值钱的职业。

那个时候，企业正在快速信息化，但真正经历过全球化 IT 建设的人并不多。一个大型集团的 ERP 怎么规划，全球 IT 架构怎么设计，项目管理怎么做，数据体系怎么建，业务流程怎么重构，这些 Know-how 在每个国家里都是非常稀缺的。

所以当时企业愿意花很高的价格，请 IBM、埃森哲这样的公司进来。

企业表面上买的是 Consultant，实际上买的是一种巨大的 Know-how Gap。

你知道，而我不知道；你在全球几十家公司见过，而我第一次做。这种知识差，本身就是巨大的商业价值。

但后来发生了什么？

企业自己的 CIO、CTO 和 IT 团队越来越成熟。大家做过 SAP，做过 Oracle，建过数据仓库，上过云，也踩过无数数字化转型的坑。过去只有少数国际咨询公司掌握的方法论，逐渐变成整个行业的常识。

咨询当然没有消失，但“咨询顾问”这四个字本身越来越不值钱了。大量工作逐渐从 Consulting 变成 Implementation，再从 Implementation 变成 Outsourcing。

这背后其实有一个非常简单的规律：

任何依靠知识差和能力差获得高溢价的职业，最终都会面对知识扩散。

我现在看 FDE，就经常有这种熟悉的感觉。

二、今天的 FDE，本质上在填大模型和企业之间的 Gap

为什么今天突然需要这么多 FDE？

不是因为过去几十年企业突然不会用软件了，而是因为大模型出现以后，又产生了一次巨大的能力断层。

大模型 Demo 很惊艳，但真正进入一家企业之后，马上会遇到完全不同的问题：数据在哪里？权限怎么拿？业务流程到底怎么跑？这个字段是什么意思？系统之间怎么调用？结果错了怎么验证？涉及财务、生产、采购的时候，谁来审批？出了问题由谁负责？

于是一边是一个能力极强、但高度概率性的大模型，另外一边是一家运行了二十年、有几百套系统、有大量历史流程和组织规则的企业。

中间出现了一个巨大的 Gap。

FDE 就站在这个 Gap 里面。

在 CIO 论坛讨论的时候，有一句话我印象很深：“模型能力不够，工程来凑。” 现场其实也有人直接提出疑问：FDE 会不会只是今天用一个新的名字和新的工具，重新包装了过去已经存在的交付和咨询市场？讨论最后又不断回到 Workflow、明确的输入输出、确定性执行，以及如何把一次性的工程经验抽象成可以重复使用的 Building Block。

这正是今天 FDE 高价值的原因。

你把一个优秀的工程师扔到客户现场，他既懂模型，又会写代码，还能和业务人员沟通。他帮客户接数据、接 API、调模型、写 Skill、做 Workflow、Debug Agent，最后把一个原来跑不起来的 AI Demo 真正塞进生产环境。

当然值钱。

但问题是：

这种价值能够持续多久？

三、企业真正缺的，可能根本不是更多 FDE

今天很多 CIO 面对 AI 落地困难，很容易得出一个结论：是不是我的 AI 工程师不够？是不是应该找一些更厉害的 FDE 进来？

但做过真正企业项目的人都知道，很多问题根本不是技术问题。假设明天给一家企业派来十个全世界最优秀的 FDE，他们首先还是得问：

库存数据哪个系统才是准的？ 采购超过多少钱需要审批？ 海外分公司的流程为什么不一样？ 客户投诉以后到底应该流转给谁？ 什么样的结果才算 Agent 把事情做对了？

如果这些问题企业自己都回答不清楚，再好的大模型也没用，再贵的 FDE 也只能陪着企业一起猜。

所以我最近越来越喜欢用一个很简单的说法来描述企业真正应该为 AI 做的准备：

一图、一表、一流程。

“一张图”，是把企业真正的业务世界画出来。客户、产品、订单、设备、组织之间究竟是什么关系。今天流行讲 Ontology，本质上就是要告诉 AI：你的企业世界到底长什么样。

“一张表”，不是简单列几个数据库，而是把数据真正讲清楚。指标怎么定义，字段是什么意思，哪个系统是 Source of Truth，哪些数据可信，哪些数据可以被 Agent 使用。这背后其实就是 Data Governance 和 Semantic Layer。

“一条流程”，则是把事情到底怎么完成讲清楚。从输入，到判断，到决策，到执行，到审批，到异常处理，再到结果验证。只有把这个 Workflow 真正梳理出来，Agent 才可能从“会聊天”进入“会干活”。

问题来了：

这些事情能不能外包给 FDE？

当然可以找顾问帮忙，可以让 FDE 帮你梳理，也可以请服务商帮你建设系统。

但最终不能外包。

因为一家企业真正无法外包的，不是 Python，不是 Prompt，甚至也不是 Agent。

真正无法外包的是：你的数据是什么意思，你的流程为什么这样运行，你的规则是什么，以及最后什么叫“把事情做对了”。

这些东西，本质上属于企业自己。

四、AI 落地最难的部分，恰恰不是 AI

这其实是很多企业今天最容易搞反的一件事情。

现在大家看到 Agent，就开始找模型、招工程师、买平台、做 PoC。但一个 Agent 真正进入生产以后，它面对的并不是一个干净的问题，而是一整个企业。

企业有自己的语言。

什么叫“核心客户”，什么叫“有效订单”，什么情况下可以退款，什么情况下必须人工审批，哪个数据可以给谁看，这些东西都不是互联网上的通用知识。

它们存在于 ERP 里，存在于 Excel 里，存在于 SOP 里，甚至大量存在于老员工的脑子里。

所以 Agentic Enterprise 真正困难的地方，不只是拥有一个更强的大脑，而是要为这个大脑建立一个可以理解的 企业世界模型（Enterprise World Model）。

Data、Ontology、Workflow、Governance，这些听起来都是上一代企业软件里的老词。

但到了 Agent 时代，它们反而比以前更重要。

以前一个人操作软件，很多语义存在于人的脑子里；今天你希望 Agent 自主操作企业系统，就必须把过去隐藏在人脑里的 Context 显式化。

从这个角度看，我甚至认为：

未来企业真正的 AI 基础设施，不只是模型，而是企业自身被机器理解的程度。

这件事情，没有任何一个 FDE 能替一家企业完成。

五、为什么我认为 FDE 的黄金时代可能不会太长

因为今天的 FDE 正好处在三股力量的夹击之中。

第一股力量来自模型。

今天很多 FDE 的价值，是因为大模型还不够聪明，所以需要工程师写代码、调 Prompt、做 RAG、写 Tool、Debug Agent。

但过去几年大模型进步最快的恰恰就是这些领域。

昨天一个工程师花几天写的 Workflow/Loop，今天 Codex、Claude Code 这样的 Coding Agent 已经可以完成很大一部分；过去需要人不断调整 Prompt，现在模型开始自己管理 Context；今天还需要工程师观察 Agent 为什么失败，未来 Agent 会越来越多地自己做 Evaluation、Reflection 和 Debug。

也就是说：

模型每升级一次，都在吃掉一部分 FDE 的“聪明”。

第二股力量则来自软件本身。

今天为什么需要一个人深入客户现场改那么多东西？

很重要的原因是：今天的软件太硬。

传统 SaaS 的逻辑是我先把产品设计好，客户来适配我的产品。如果你的流程和我的设计不一样，要么你改变业务，要么做 Customization，要么派 Professional Services。

FDE 其实没有彻底改变这个逻辑。

它只是把过去一个普通的实施顾问，升级成了一个更聪明、更懂 AI、更会写代码的工程师。

换句话说：

FDE 是用一个“柔性的人”，去弥补一个“刚性的软件”。

但我认为下一代软件最重要的变化，恰恰是软件本身开始变得柔性。

我之前一直在思考 Flexible Software 这个概念。未来的软件很可能是“核心越来越硬，外围越来越软”。

底层的 Security、Governance、Permission、Data Model、Audit、Runtime 必须越来越确定；但是外围的 Workflow、UI、Integration、Automation 和 Business Logic，却越来越可以由 Agent 根据企业 Context 动态生成。

于是以前的路径是：

业务提出需求 → FDE 理解 → 写代码 → 测试 → 部署。

未来越来越可能变成：

业务表达需求 → Agent 理解 Context → 调用企业 Ontology → 生成 Workflow → Harness 验证 → 执行 → 反馈。

当 Agent Stack 越来越成熟，今天由 FDE 手工完成的大量 Glue Code、Integration 和 Workflow Adaptation，就会逐渐变成软件产品自己的能力。

所以：

Agent Stack 每成熟一层，也会吃掉一部分 FDE 的“工程”。

第三股力量，则来自企业自身。

当企业逐渐完成自己的 Data Governance、Ontology 和 Workflow 整理之后，过去掌握在外部 FDE 手中的 Know-how，会逐渐沉淀回企业内部。

这和二十年前咨询顾问经历的事情非常相似。

最初我什么都不知道，所以你很贵。

后来我自己会了，价格自然就会下来。

于是 FDE 今天恰好站在一个非常微妙的位置：

上面，大模型越来越聪明。

下面，Flexible Software 和 Agent Stack 越来越成熟。

另一边，企业自身对 AI、数据和流程越来越理解。

三股力量同时在挤压今天 FDE 的价值空间。

六、FDE 不会消失，但会回到它真正应该在的位置

所以我并不认为未来企业完全不需要 FDE。

恰恰相反，我认为最优秀的 FDE 仍然会非常重要。

只是他的工作不应该是给 Customer A 接 Salesforce，给 Customer B 改审批流，再给 Customer C 生成一套新的 Apache SeaTunnel Code。

如果一个 SaaS 公司每增加一百个客户，就必须增加几十个 FDE，那么无论它怎么包装，这个商业模式最终都会越来越像一家技术服务公司。

真正优秀的 FDE，应该去解决的是未知问题。

进入一个过去没有被 AI 改造过的行业，发现一个产品还没有理解的新场景，帮助第一批客户跑通，然后从这些现场经验中找到 Pattern。

接下来最重要的一步不是继续招聘更多 FDE，而是：

FDE → Pattern → Product → Platform。

把一次性的客户问题抽象成产品能力，把一个人的 Know-how 沉淀成所有客户都可以使用的 Building Block。

然后 FDE 再去解决下一个从来没有解决过的问题。

从这个意义上说：

一个优秀 FDE 的目标，不应该是证明客户永远需要 FDE，而应该是让同一个问题下一次再也不需要 FDE。

这其实也是软件行业几十年来反复发生的事情。

咨询解决第一次问题，产品解决第一千次问题。

七、终局不是更多 FDE，而是更柔性的软件

所以今天我看硅谷大规模招聘 FDE，并不觉得这是一个错误。

它恰恰说明 AI 正在从 Demo 进入真实企业，而任何一项重大技术进入产业早期，都需要大量的人去填补技术和现实之间的缝隙。

二十年前，这个人叫 Consultant。

十年前可能叫 Solution Architect、Customer Engineer、Professional Services。

今天叫 FDE。

名字在变，但技术产业发展的规律没有变。

真正值得讨论的，不是哪个名字听起来更性感，而是：

这些今天必须靠人解决的问题，明天能不能变成产品？

如果不能，那么 FDE 最终只是更昂贵的技术外包。

如果可以，那么 FDE 今天踩过的每一个坑，都应该成为明天 Flexible Software 和 Agent Stack 的一部分。

我越来越相信，Agent 时代真正的软件革命，不是简单在 SaaS 上面放一个 Copilot，也不是给每个客户配几个更贵的工程师。

它应该走向另外一个方向：

过去是人去适配软件；今天是 FDE 帮企业适配 AI；未来，是软件主动适应企业。

但在那之前，还有一件事情任何模型、任何软件、任何 FDE 都替代不了：

企业必须先把自己讲清楚。

你的数据，你的流程，你的规则，你的组织，你的经验。

当这些东西真正沉淀成 AI 可以理解的企业世界，模型才有大脑，Agent 才有上下文，软件才真正拥有柔性。

到了那个时候，我们今天如此追捧的 FDE，也许依然存在。

只是它不会再站在每一个客户和软件之间。

因为真正成熟的技术，最终一定会把人的经验产品化，把人的重复劳动软件化。

这才应该是 FDE 最终完成的使命。