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

全球FDE定义正从“接入AI”转向“为Agent结果负责”，而中国政企面临私有化、信创、数据不出域三大门槛，催生独特的本地化路径。 核心内容： 1. 全球FDE定义向Agent Engineer收敛，强调端到端交付与结果负责制 2. 中国政企面临私有化部署、信创适配、数据不出域三大核心挑战 3. 本土市场催生国产算力适配与墙内全链路重建的独特解决方案 过去这几天，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开始替组织干活，**谁定义目标、谁接入系统、谁划定边界、谁评估效果、谁在失败时兜底、谁把一次交付沉淀成一种可复制的能力。** 这套“谁来负责”的结构一旦成形，它就不再是一个岗位，而是一层操作系统。