FDE正在从一个岗位，变成一条产业链

原文把「架构关系」这层讲透了，但一线上最容易翻车的环节没有展开：不是选型和PoC，而是评测与退出。谁写评测集，谁就实际控制验收——当厂商热情提出「帮你们搭好评测框架」，那就是客户交出基线的时刻。我经手过的项目里，翻车大多不是做不出系统，而是交接期没人接班：运行手册半年不更新即作废，客户内部骨干早在项目中途就被抽走，「退出」最终变成事实上的永久订阅——供应商退不出，客户也换不起。

还有一个原文没碰的硬约束：跨境合规。这条产业链成立的前提，是客户上下文能向上回流、变成伙伴与厂商的复用资产；可一旦交付跨了境，数据出境评估、PIPL和GDPR会把这股向上的流直接切断——评测样本、日志、上下文图谱在法律上根本不能离开客户环境。于是所谓「伙伴永久持有」的harness，在每个市场都得重长一遍，复利大打折扣。中国企业出海与外资在华做AI交付，这个约束必须在架构设计第一天就摆上桌，而不是等安全评审时才发现资产回不去。

给你一条可执行的建议：下一个FDE项目签约前，把三件事白纸黑字钉死——评测集与领域本体的所有权归客户，上下文回流的脱敏范围与出境白名单写进数据处理协议，退出验收的标准定为「客户内部团队独立运行满90天」。这三条谈得下来，你才分得清对面是把交付当渠道的玩家，还是真打算让你握住自己架构的长期伙伴。

—— FDEChina编辑部 · 实战派

# FDE正在从一个岗位，变成一条产业链

来源：FDE脑洞局 · 2026年8月31日 08:08

FDE研究档案 10｜云厂商、伙伴、服务商与企业内部的架构关系

这期只研究一个问题：当越来越多公司把工程师嵌进客户现场，它们是在扩一个岗位，还是在争企业下一轮技术架构的入口？

—— AFN

57天里，四家公司给出了四种很整齐、统计口径却完全不同的信号。

6月30日，AWS宣布投入10亿美元，建立专门的Forward Deployed Engineering组织，把数千名专家嵌入客户团队。当天发布的伙伴说明又把这套模式扩到咨询伙伴：伙伴组建独立团队，工程师先通过AWS定义的技术门槛，早期由AWS深度参与，之后逐步独立交付。

7月29日，微软在FY2026第四季度财报电话会上宣布成立Microsoft Frontier Co.，计划向客户嵌入6000名行业与工程专家。微软称，过去一年已经用这套模式在164家客户完成330多个项目；同一段发言还把Novo Nordisk项目的交付团队称作FDE团队。

8月20日，AI专业服务商Blend披露，目前有500名Forward Deployed AI Engineer，计划到2027年增至750人。6天后，金融数据平台FINBOURNE启动首批30人的FDE项目，工程师会进入客户的运营和技术团队，处理遗留系统、数据孤岛、治理、审计与控制。

这四组数字不能相加。AWS披露的是投资与组织规模方向，微软说的是一组行业与工程专家，Blend给出当前人数与扩张计划，FINBOURNE说的是首批团队。把它们写成“7280名FDE正在进场”，算术很省事，研究就没了。

人数之外，AWS把FDE和“架构关系”写在了同一套伙伴机制里。

伙伴说明说得很直白：先交付出结果的伙伴，会赢得客户未来的架构关系。它还列出了每次项目要留下的东西：领域本体、评测框架、MCP服务、Agent运维工具，以及记录架构选择、评测标准和行业模式的上下文图谱。

领域本体、评测和上下文图谱，描述的是一套交付机制，已经超出了个人职责清单。

FDE正在变成厂商获得企业架构关系的一条交付渠道。

FOUR MOVES

四家公司分别在动哪一层

AWS的动作最接近“把交付能力做成渠道”。

它一边扩自己的FDE团队，一边把生产方法、技术门槛和早期陪跑交给伙伴。伙伴要组建独立、经过AWS认证的工程团队；项目中形成的交付工具归伙伴长期持有，后续可以在别的项目复用。AWS提供产品、方法和标准，伙伴提供客户关系、行业知识和交付覆盖。

过去的云渠道常见动作是转售、实施、迁移和托管。这里多了一层：伙伴与云厂商共同进入业务流程，做出能运行的Agent系统，再把经验变成自己的交付资产。

微软把“结果型工程”抬到了公司级组织。

6000人不能直接写成6000名FDE。微软的原话是“行业与工程专家”，官方也没有在这段披露中给出岗位构成、全职人数、地区分布或到岗节奏。不过，它把组织命名为Microsoft Frontier Co.，把工作方式定义为与客户共同设计、共同创新并持续改进AI系统，还用FDE团队解释其中一个项目。

它至少说明，嵌入客户不再只是少数产品团队的特殊打法，正在变成大厂可规模化调度的组织能力。

Blend在把FDE做成人才供给与服务产能。

公司计划通过自建ForwardAI Academy、全球招聘和定向收购，把500人的队伍扩到750人。这条扩张路径覆盖训练、筛选、编组和进入客户环境，再用项目结果支撑下一轮扩张。

Blend同时披露了PoC转生产和NPS数字。本文不采用这些数字证明效果，因为它们来自公司自报，公开页面没有提供逐项目样本、统计方法和独立复核。

FINBOURNE走的是垂直软件路径。

它从投资管理行业的数据、对账、交易流程、治理和审计切入。首批30名工程师被要求坐进客户组织，成为运营与技术团队的延伸。项目负责人此前长期负责专业服务和新客户实施。

这类FDE离行业流程很近。销售平台功能的同时，它还会参与平台怎样进入旧系统、控制怎样写进架构、数据怎样持续对账。垂直软件由此往专业服务生长，专业服务也开始带着产品和Agent往回走。

四家公司走的路不同。共同点是：FDE开始同时承担产品落地、客户交付、伙伴扩张和行业知识回流。

ARCHITECTURE RELATIONSHIP

订单结束以后，架构关系还在继续

企业采购一个模型席位，厂商拿到的是订单。FDE把模型接进采购、客服、研发、风控或投资数据流程，厂商才进入企业的依赖关系。

这段关系至少包含五样东西：业务流程怎样拆，数据从哪里来，系统能拿什么权限，什么结果算通过，上线以后由谁维护。

谁持续参与这些决定，谁就更容易影响下一次模型选择、云资源使用、数据架构、安全控制和合作伙伴名单。即使合同到期，项目中留下的评测集、领域本体、连接器、运行手册和架构决定也会继续影响后续选择。

这就是“架构关系”比一次项目更值钱的地方。

AWS的伙伴机制把这件事写得尤其清楚。每次交付都要形成可复用的harness，伙伴永久持有；AWS工程师前期深入参与，等模式稳定后，再转向帮助伙伴扩张。于是，一次项目同时产生三类回报：客户得到生产系统，伙伴得到可复用交付资产，AWS得到云上架构和产品使用。

渠道的分发单位也会跟着变。

传统渠道常以许可证、线索或实施项目为分发单位。FDE渠道分发的是一条能运行的业务流程。模型、云、数据服务、安全工具和运维能力，沿着这条流程进入企业。

服务费只是表面那一笔钱。后面还连着云消耗、产品采用、续约、扩场景和技术路线。

TWO FLOWS

这条产业链有两股流，争的是中间那层资产

— FDE产业链位置图：模型与平台、云厂商伙伴、专业服务、企业内部FDE之间的两股流与架构关系

从上往下流的是模型、平台、工具、方法、认证和生产标准。厂商希望这些东西经过伙伴和服务商，进入更多客户的真实流程。

从下往上流的是客户上下文：遗留系统的限制、权限冲突、评测失败、行业规则、异常处理和一线使用反馈。它们会回到交付团队，再进入伙伴的复用资产或厂商的产品路线。

中间被争夺的是架构关系，以及项目留下来的资产归属。

AWS说伙伴永久持有交付harness。客户又需要在项目结束后拿到系统、知识图谱、运行手册、架构文档和可以独立操作的内部骨干。两边都合理，也天然存在张力。

伙伴想积累跨项目复用的行业方法，平台希望现场反馈回到产品，企业则要保留自己的数据、评测、权限和切换能力。同一份“上下文”里，哪些能抽象复用，哪些只能留在客户环境，不能靠一句“共同创新”带过。

产业链真正形成以后，合同里最难谈的可能不再只是人天和模型单价，而是四件更具体的事：谁定义生产标准，谁拥有交付资产，谁可以把经验带到下一家客户，谁在供应商退出后继续承担运行责任。

FOUR POSITIONS

四种FDE，名字相同，位置不同

模型与平台公司的FDE：把现场失败送回产品

这类FDE最靠近模型、云服务或垂直平台的产品路线。

它的优势是能直接调用产品团队、改变接口、补工具、建立参考架构。把客户做上线是一份产出，识别反复出现的问题、把相应能力做成产品默认值，是另一份产出。

判断这类FDE做得好不好，可以看两类证据：客户系统是否稳定进入生产，现场失败是否真的变成了评测、工具或产品改动。

风险也很明确。产品公司既提供能力，又参与选型和验收，容易让自己的技术路线变成默认答案。客户需要保留独立基线和替代方案。

FINBOURNE这类垂直平台FDE也在这一层。它带回产品的内容包括技术反馈，也包括投资管理行业的控制、审计和数据语义。

云厂商伙伴体系里的FDE：把生产方法复制出去

这一层要检验的是：云厂商能否把生产标准交给伙伴，又不把标准稀释成一张证书。某个工程师驻场多久，反倒是次要问题。

AWS的做法给出了几个可检查的部件：独立编组、工程师准入、早期共同交付、统一生产门槛、项目资产复用，以及伙伴逐步独立。

这类FDE做成以后，云厂商获得规模，伙伴获得能力和客户资产。做不成时，它会退回熟悉的老路：重新贴牌的实施团队，材料上写着Agent，现场仍按人头排期。

所以，伙伴FDE最重要的证据要看独立交付后留下了什么。下一次同类项目能否少走一段路，才说明方法开始复用。认证人数回答不了这个问题。

专业服务公司的FDE：把行业上下文变成生产系统

Blend代表的是另一种优势：它不必绑定单一模型或云，可以用行业知识、数据工程和客户关系承接复杂改造。

专业服务公司离遗留系统和组织协同更近，也更容易覆盖多个厂商。它们的难题在商业模型里。FDE通常比传统顾问更贵，项目又需要长期进入生产；如果每个客户都从零开始，人数越多，成本也越诚实。

因此，这一层能不能形成利润，要看项目知识能否转成评测、连接器、领域模型、部署工具和运营方法。Blend计划用学院、招聘和收购扩人，解决的是供给规模；交付资产能否复用，决定规模能不能变成效率。

企业内部FDE：保住最后的授权与接管能力

企业内部未必把岗位叫作FDE。平台工程、企业架构、AI产品、数据、安全和业务运营团队，都可能承担其中一部分工作。

它们和外部FDE最大的区别，是站在责任终点。供应商可以搭系统、给建议、做评测，企业内部团队仍要决定数据能不能用、Agent能不能写入、异常由谁接管、版本什么时候回滚，以及结果是否足以进入下一轮预算。

AWS把客户独立接管写进了FDE项目设计：客户工程师从观察者变成共同建设者，再成为独立操作方。这个过程恰好说明，成熟的外部FDE需要一个能接管系统的内部对应层。

内部没有这层能力，外部FDE很容易成为事实上的架构负责人。企业有一支能定义接口、保管评测和执行退出方案的内部队伍，模型公司、云厂商和服务商才会在清楚的边界里竞争。

THREE GATES

岗位扩张不等于产业链成立

我会用三道门判断这次变化有没有走到“产业链”。

第一，能力能否脱离明星个人被复制。AWS的准入与伙伴编组、Blend的学院和FINBOURNE的行业团队，都在回答供给问题。只靠少数高手救火，仍然是一门手艺。

第二，每次项目是否留下可复用资产。AWS已经明确列出本体、评测、MCP服务、运维工具和上下文图谱。其他公司如果只有人数增长，没有项目资产，规模越大越像传统人力生意。

第三，客户能否独立接管并保留选择。系统、文档、评测、权限、日志和内部负责人都要能交回企业。否则“嵌入客户”很容易变成更深的供应商依赖。

三道门里，前两道决定FDE能不能规模化，最后一道决定这条产业链是不是健康。

MONEY & POWER

钱和权力会沿着交付重新分配

以下推断来自四家公司的组织动作，不是它们披露过的经营结果。

模型与云厂商可能愿意承担更高的前期工程成本。FDE做成一条生产流程以后，收入不只来自本次服务，还可能来自长期的模型调用、云资源、数据与安全产品。对它们来说，FDE可以同时是交付成本、产品研究和获客成本。

专业服务公司会被迫回答一个更难的问题：项目结束以后，除了发票，还留下了什么可复用的东西。能把交付资产用于下一次项目，它就有机会摆脱纯人天；每次仍从零开始，FDE只是更贵、更难招的驻场工程师。

垂直软件公司则可能借FDE扩大产品边界。原来只卖一套系统，现在开始参与数据迁移、控制设计、流程改造和持续运营。产品更贴近客户，退出也会更难。企业要提前谈清楚数据、架构文档、评测与替换接口。

企业内部FDE会获得更多预算与议价权。它不一定自己做完所有工程，但要能把外部供应商放进同一套基线、权限和验收框架里。谁掌握这层接口，谁就不必把每次厂商更换都做成一次组织失忆。

USE THE MAP

用《FDE产业链位置图》判断自己交付的是什么

图里的四个位置，不是职业等级，也没有谁天然更高级。

如果你在模型与平台公司，最该积累的是“现场问题怎样进入产品”的证据；如果你在云伙伴体系，要证明方法离开原厂工程师以后仍能稳定交付。

专业服务公司要证明项目资产可以复用。团队很能熬，不算交付资产。企业内部团队则要证明自己能定义基线、管理权限、接管异常并保留供应商切换能力。

这张图也可以拿来检查一个FDE岗位。

看它的钱从哪里来，生产标准由谁定，项目资产回到哪里，最后的运行责任落在谁身上。四个问题答完，岗位在产业链里的位置通常就清楚了。只看招聘标题，容易把产品团队、咨询顾问、集成工程师和企业架构负责人装进同一个纸箱。

FDE会不会成为一条产业链，不由扩招人数决定。

当模型与标准、规模交付、行业集成和企业责任开始由不同组织承接，又能通过同一套生产资产连接起来，产业链才真正出现。

这会把FDE的稀缺性推向另一个位置。会写代码、能驻场只是入场券。更难替代的是：你能不能让一次客户交付变成下一次可复用的方法，同时让客户仍然握着自己的架构、证据和退出权。

SOURCES & LIMITS

方法、来源与证据边界

本文以2026年6月30日至8月26日四家公司公开材料为主样本，用于观察FDE组织怎样进入云厂商、伙伴网络、专业服务与垂直软件。样本不是全球FDE公司清单，也不代表四种组织已经取得相同的商业结果。

本文使用四类信息：

已核实公告事实：公司明确披露的日期、投入、人数口径、组织安排和工作方式；

公司自报计划：Blend到2027年的扩张目标、各家公司对项目效果或交付优势的描述；

作者判断：架构关系、两股流、四种产业位置和三道门；

尚未验证：实际到岗人数、逐项目ROI、独立验收结果、FDE业务收入与利润率、客户长期留存及供应商切换成本。

微软的6000人不能直接等同于6000名正式岗位名称为FDE的员工。AWS的10亿美元是支持专门FDE组织的投资口径，不能拆成招聘预算或已经发生的支出。Blend的500人与750人来自公司公告，FINBOURNE的30人是首批项目团队；这些数字都不是审计后的人力统计。

公开来源：

AWS Partner Network：Introducing Forward Deployed Engineering for Partners：10亿美元FDE组织、伙伴模式、AWS定义的工程门槛、伙伴独立团队、交付harness与架构关系表述。

About Amazon：AWS invests $1 billion to embed AI forward deployed engineers with customers：专门FDE组织、数千名专家、客户团队嵌入方式、客户自立、交付物与伙伴投入。

Microsoft FY2026 Q4 earnings call：Microsoft Frontier Co.、6000名行业与工程专家、164家客户、330多个项目和FDE团队表述。

Blend：Blend to Grow Forward Deployed AI Engineering Force to 750 by 2027：当前500人、2027年750人目标及学院、招聘、收购三类扩张方式。人数和效果均为公司披露。

FINBOURNE：FINBOURNE launches Forward Deployed Engineering programme：2026年8月26日启动、首批30人、客户团队嵌入、遗留系统与治理控制范围。

你所在的FDE团队，项目结束后最容易被带走的，是人、方法，还是客户的架构关系？

我是 AFN，一名做了一年多 FDE、仍能独立回消息的活人。