Google 把 FDE 改写成 Agent Engineer 这周，中国企业正在逼出另一种 FDE

过去这几天，FDE 没有大融资、没有大并购，但发生了一件更重要的事：它的定义在变。 而这套正在收敛的全球定义，搬进中国政企的机房，会先撞上三道门。

一、全球这周：FDE 的定义又往前挪了一格

最清晰的信号来自 Google Cloud 的最新岗位——它把 FDE 直接写成了 Agent Engineer：负责把早期的对话原型变成生产级系统，拥有端到端的工程生命周期，是进入客户环境写代码、共建 agentic 方案的 embedded builder，而不是传统顾问。

它不是孤例。IBM 开出了 AI Forward Deployed Engineer；做供应链软件的 Kinaxis 也在组建 FDE 小队，明确说"这不是咨询、不是功能团队，而是一个有创业 ownership 的多学科交付单元"；ServiceNow 和 Accenture 干脆把 FDE 做成了一个 Program——一套可售卖的交付产品，而不只是几个人。再往前，OpenAI 的 DeployCo、Stripe 的 Forward Deployed AI Accelerator，指向的是同一件事。

把这些动作压成一句话：全球 FDE 的定义，正在从"把 AI 接进去"收敛到"为企业 Agent 的结果负责"。 模型不是难点，让 Agent 在真实组织里持续、可信地干活，才是难点。

但这套定义有一个没说出口的前提——它默认你能随手调用最前沿的模型 API、跑在标准云上、数据可以自由进出。

把这个前提搬到中国政企的机房，前提本身就不成立。

二、三道门：私有化、信创、数据不出域

第一道门：私有化部署。 央国企、金融、政务的核心场景，几乎都不接受"调云端 API"。模型要进客户自己的机房，在内网、断网、甚至涉密环境里跑。这意味着 FDE 面对的从来不是"最强的那个模型"，而是"能在这台机器上稳定上线的那个模型"。

第二道门：信创。 2026 年的信创目录第一次把"大模型应用"单列成一类；按 79 号文的节奏，相关单位要在 2027 年前完成信创适配。落到工程上，就是底座要从英伟达加 CUDA，换成昇腾、海光、寒武纪、摩尔线程这些国产芯片，再加国产操作系统、国产数据库。麻烦在于：市面上绝大多数开源模型和工具链都是为英伟达高度优化的，直接搬到国产硬件上常常"水土不服"——装不上、跑到一半中断、显存溢出、推理变慢。于是市场上专门长出了一层做"国产算力适配"的中间件，把模型从"能跑"调到"高效跑"。这一整层，全球版 FDE 几乎不需要碰。

第三道门：数据不出域。 金融、政务对数据有"不出域"的硬约束：数据不能离开客户的安全域。它改写的不是某一个环节，而是整条链路——评测、RAG、微调、可观测，全部得在客户的墙里面重建。你不能把数据拉回来训练，不能用外部评测集，连"看模型到底为什么错了"，都要在内网里完成。

三、这三道门，具体改写了技能栈的哪几格

把全球版 FDE 的技能栈和中国政企版摆在一起，分叉清清楚楚地出现在四层：

模型层。 全球版拼的是"会不会用最前沿的模型"；中国政企版拼的是"在受限算力和国产模型上，把够用的能力调到能验收"。前者是选择题，后者是约束下的最优化。

基础设施层。 中国政企版凭空多出一整块——信创适配。算子、显存、推理引擎层面的国产化改造，是全球版 FDE 基本不必触碰的工作，在这里却是入场券。

数据与评测层。 全球 FDE 最近才把 evaluation（评测）加进核心能力，因为 Agent 上线后，问题从"答不答得出"变成了"稳不稳、可不可审计、能不能持续优化"。中国政企版同样需要这一格，但"数据不出域"又把它的难度抬高了一档：评测套件、可观测、归因，全部要在客户域内自建。

责任层。 在央国企，"出事了谁负责"的链条更长、更硬——要过备案、过合规、过审计。FDE 在这里交付的不只是一套方案，而是要把"这套 Agent 谁来兜底"写进一个可治理的结构里。

四、所以，中国不是"慢一拍的 FDE 市场"

很容易把中国政企的 AI 交付，理解成"硅谷的延迟版"——晚两年、抄作业、慢慢追。这个判断是错的。

真正的结构是：决定一个交付角色长成什么样的，从来不是技术本身，而是它被嵌进的那套约束系统。硅谷 FDE 的约束，是"前沿能力够不够、客户现场跑不跑得动"；中国政企 FDE 的约束，是"私有化、信创、数据不出域"这三道刚性门槛。约束不同，角色的形状就不同，技能栈自然分叉。

不是谁更先进，而是两种选择压力，长出了两种 FDE。 硅谷那一种，难在贴着技术前沿走；中国这一种，难在约束密布的现场里，依然要把东西交付上线、并且为结果负责。这是两种不同的硬。

五、一个可迁移的判断，和它的代价

可迁移的原则其实只有一句：当你想判断一个新岗位会长成什么样，先别看它用什么技术，先看它被嵌进了哪套约束。 约束是稳定的、慢变的；技术是流动的、快变的。约束决定形状，技术只决定填充。这条原则不止适用于 FDE，适用于任何一个正在被 AI 重写的交付型岗位。

但这条路有它真实的代价，必须说清楚：

中国政企 FDE 的产品化更难。私有化、信创、行业定制三样叠在一起，每个项目都更"重"，跨客户复用更难。全球那条关于 FDE 的争议——它会不会从"软件公司的高毛利岗位"退化成"高薪专业服务"——在中国政企的语境里，这个风险只大不小。

它换来的，是另一种护城河：数据不出域、自主可控本身，就是别人短期抄不走的壁垒。 交付越重，关系越深，就越不容易被一个通用产品一次性替换掉。

这两面是同一枚硬币。轻与重、可复制与有壁垒，往往不可兼得——这是中国政企交付层必须替自己回答的取舍。

六、下一站

全球 FDE 的下一站，是从"岗位"变成"企业 Agent 的责任接口"。中国政企的版本会走到同一个终点，但走的是一条约束更密的路——也正因为约束更密，它更早被逼着去回答那个真正的问题：当 Agent 开始替组织干活，谁定义目标、谁接入系统、谁划定边界、谁评估效果、谁在失败时兜底、谁把一次交付沉淀成一种可复制的能力。

这套"谁来负责"的结构一旦成形，它就不再是一个岗位，而是一层操作系统。