对今天的中国企业来说，模型似乎已不是 AI 落地中最明显的瓶颈。

7 月 14 日，月之暗面发布总参数 2.8 万亿的 Kimi K3；几天后，阿里千问预览总参数 2.4 万亿的 Qwen3.8-Max-Preview。不到一周，两款总参数超过 2 万亿的国产模型相继出现，企业能够调用的技术能力又向前走了一截。

模型固然决定着 AI 能力的上限。

但是，当模型供给在短时间内变得如此丰富，企业需要作出的决定实际上并没有随之减少，反而很快从“选哪个模型”延伸到一连串更具体的问题：模型的能力边界又突破到了哪里，业务上下文数据在哪套系统里，哪些人有权调用，模型出错以后由谁接管，生成结果能不能直接进入业务，以及业务人员是否要改变已经沿用了多年的工作方式等等。

我们经常说 AI 赋能千行百业，但是千行百业参差多态，具体负责 AI 落地的人，往往最先想听到的还是一个最佳实践：有没有同行已经做过，用了什么模型，最后效果怎么样。

最佳实践可以证明一个方向值得尝试，却很难把另一家企业的数据、权限和工作流程一起复制过来。当这些条件还没有理清，最容易被复制的往往只是产品的样子。于是，过去两年，企业里最容易完成的 AI 项目，往往还是一个 Demo。找一批资料接入知识库，再给大模型做一个自然语言入口，几个星期便能让系统回答问题。

Demo 和真实环境的差距显然是巨大的。

上线当天看起来什么都能做，过了一段时间却没有人继续使用，也不再产生模型调用。月抛型、周抛型，甚至日抛型 Agent 非常多见。

面对这种落差，人们很容易把原因归结为大型企业行动太慢。可在过去几十年的企业 IT 建设中，“慢”原本就是一种合理常态，而且很多时候，它也是大型组织控制风险的办法。在国内，央国企行事尤其秉承这个思路。

在 WAIC 2025 世界人工智能大会期间，国资委发布了首批 40 项央企人工智能战略性高价值场景，有一个很有意思的提法，叫推动“盆景式”试点落地到“雨林式”规模应用。所以，有什么“快捷方式”能实现这个跳跃？一家企业既要寻找 AI 的目的地，又要把系统建设到生产环境，谁来承担中间那段过去很少有人完整负责的工作？

今年 WAIC 2026，我又来到大会现场。就这个问题，和多家科技企业的负责人，包括阿里云智能集团副总裁霍嘉等做了一些交流。一个可以从中得出的结论是，大家正逐渐将答案聚焦于一个此前相对陌生，却已存在许久的岗位 ——FDE。

FDE 走上前台

Forward Deployed Engineer，国内通常译作前沿部署工程师或者前线部署工程师，简称 FDE。这个名字并不是大模型出现以后才有。

十多年前，Palantir 已经用它称呼一批深入客户现场的解决方案和集成工程师。他们一头连接客户正在处理的问题，一头连接公司的平台研发。

到了大模型时代，FDE 重新变得显眼。以几个 AI 实验室为例：OpenAI 对这个岗位的职责描述，已经从业务发现、项目界定和系统设计，一直延伸到开发、生产上线与采用效果。2026 年 5 月，它又成立 Deployment Company，把工程师进入复杂组织、与客户共同改造关键工作流程，做成一条正式业务线。Anthropic 等模型公司也在多个地区设置了相近岗位。

FDE 的回潮首先是一种全球现象，但国内 AI 落地似乎更需要 FDE。

我们常说中国拥有丰富的 AI 应用场景。场景丰富当然是一种优势，但换到落地一侧，它也意味着很难用一套标准答案解决所有问题。

中国既有高度数字化的大型企业，也有大量仍在补基础课的公司；即使在同一家集团内部，新建的数据平台、运行多年的业务软件、不同厂商提供的系统和分散在各部门的数据，也可能同时存在。AI 进入这样的企业，并不会绕过过去留下的系统关系，而会在读取数据、调用权限和改变流程时逐项遇到它们。

即使企业内部数据在物理层面统一了，数据本身还有责任边界的问题。

金融、能源、交通、医疗和大型工业企业处理的信息，往往涉及个人信息或者重要生产数据。模型能够看见什么，数据是否可以离开本地环境，生成结果由谁审核，系统怎样留痕和回退，都要在项目里落实。

最后大语言模型为代表的现代 AI 看起来使用简单，但背后的技术原理和实现工程复杂无比。霍嘉就和我讲了一个体感，现实中甚至能将 Transformer 架构说清楚的人，占比也并不高。知其然，不知其所以然，如何能做好 AI 落地？

FDE 的意义很大程度上就在这里。

它不只是增加一类工程师编制，而是让懂 AI 架构和能力边界的人提前进入场景，与掌握业务、数据和生产责任的人共同工作。

售前占比变大，项目总时间反而缩短

从我从阿里云得到的实践反馈，FDE 的介入，确实缩短了项目周期，也提高了客户的获得感。

因为项目售前（项目论证）占比变长了，但从想法到上线的总时间反而缩短了。

这里用了两把尺子。

一把量的是项目里的时间怎样分配，另一把量的是整个项目究竟持续多久。

如果用一个近似的 20% 和 80% 来描述，传统企业项目通常先用 20% 左右的时间确认需求、设计方案和签订 SOW，剩下的大部分时间才用于开发、集成、测试、部署和验收。这样的安排延续了确定性工程的思路：售前阶段尽快固定范围，合同签完以后，建设团队沿着已经画好的路线向前走。

AI 项目里的比例正在反过来。

正式建设之前，FDE 等团队要进入业务现场筛选场景，检查数据和权限，做出 MVP（最小可行产品 / 方案），让实际使用者跑一遍，再判断技术路径是否成立、投入产出是否合理。一个场景没有价值，或者数据条件根本不支持，就应该在这个阶段停下来；方向在真实环境里跑通之后，开发、部署和上线才有可能迅速展开。

于是，在一个已经缩短的项目周期里，大约 80% 的时间可能被用来找对方向，剩下 20% 才用于方向明确后的建设。

这并不是把原来半年或一年中的 80% 原样搬到售前。传统流程里，一个错误假设可能直到开发、集成甚至验收时才被推翻，需求再沿着组织层级返回，前面的投入跟着变成返工。而 FDE 先用一两周的小规模试验，让最容易失败的判断在真实数据和流程中暴露出来。

总时间也就被压缩了。

只把验证提前，还不足以得到这种速度。MVP 做完以后，如果需求仍然要依次交给销售、解决方案架构师、产品经理、开发和交付团队，试验中刚刚获得的理解，还会在一次次转述中损失。

阿里云的 FDE 实践是把客户侧的业务、数据和 IT 人员，与厂商侧的产品、算法和工程人员组成 One Team。重点不在于大家是不是坐进了同一间办公室，而是能够作出不同判断的人进入了同一个工作现场。

上世纪七十年代，MIT 学者 Thomas Allen 研究研发组织中的沟通网络，发现物理位置会显著影响技术交流；他后来把那些连接组织与外部技术世界的人称为“gatekeeper”。阿里云的 FDE 就成了这个 AI 时代的“gatekeeper”。

如果说前面的变化压缩了项目时间，这里被缩短的就是组织空间。

模型训练和推理中，通信开销是新的瓶颈，AI 落地的组织协同也是如此。

两个项目，检验 FDE 的三种能力

谈完 FDE 的前世今生，接下来我们通过三个阿里云的案例，感受一下 FDE 的成效。

第一个是央视体育客户端的世界杯“AI 观赛助手”。

世界杯有一个不会等待项目流程的时间表，比赛持续发生，赛程、球员和比分随时变化，用户提问的时间又可能与数据更新时间错开。系统既要及时回答，也要以官方信源为依据，避免大模型编造内容。阿里云团队用一周左右把应用推入生产环境，让真实用户和实时数据尽早进入验证。

一周上线当然很快，但快并不是这个案例的全部意义。传统项目喜欢在交付以前尽量消除不确定性，这个项目则把真实使用本身变成了验证的一部分。系统先进入比赛，再根据现场问题，在结果可控的情况下不断优化调整。

第二个项目来自中石油昆仑数智。

常减压装置是炼化生产的第一道工序，后续环节建立在它稳定运行的基础上。AI 应用进入这类系统，面对的不只是一次回答是否准确，还要考虑连续运行、异常处置以及与原有系统的协同。据阿里云转述客户反馈，这是其系统内第一个在生产系统中 24 小时运行的 AI 应用。到了这里，FDE 要证明的已经不再是模型能不能回答，而是 AI 能不能留在核心业务里。

第三个来自于北京大学国际医院。

FDE 团队仅用 3 周即完成 7 大患者服务场景的 AI Agent 全链路交付 —— 从架构设计、24 个业务系统接口联调到微信小程序 " 小安 "AI 健康管家灰度上线，意图理解与召回准确率均达 90%，让 150 万患者实现 7×24 小时 " 挂号-导诊-报告解读-随访 " 一站式智能服务。验证了 " 小切口快速落地、标准化方案跨院复制 " 的 MaaS 交付模式，为医疗 AI 患者服务从单点试点走向规模化普惠提供了可参照的落地样本。

三个项目当然不是一条所有企业都能照搬的标准路线。它们却呈现出高价值场景的一些共同信号：AI 应用能够 Always On，使用过程持续产生新的高质量数据，基础模型升级以后，业务效果还能继续获益。

中国 FDE，更需要科技大厂牵头

在调研中，我们发现任何接触 FDE 概念的人，开始都会产生一个疑问。

如果岗位的责任已经改变，支撑这些人的合同却仍然大多按照项目、人天和交付物计算。一支由资深工程师组成的 FDE 团队成本不低，如果每个客户都需要从头投入相同的人力，这种方法越成功，厂商背负的交付压力反而越大。

所以，如何让 FDE 成为一门可持续的生意？

这里至少有三本账要同时算得过来。

客户先要从应用中得到可以观察的价值：节省了多少时间，增加了多少收入，降低了多少风险。上线、验收和准确率只是中间指标，持续使用与业务结果才会决定下一年是否续约。

客户持续使用以后，厂商才可能获得模型调用、算力供给、数据平台和运维服务带来的长期收入，让 FDE 不必完全依靠一次性项目费存活。

与此同时，FDE 在现场积累的经验、在授权与合规边界内形成的数据反馈，以及行业 know-how，还要反哺模型、Agent 平台和相关云产品。产品因现场实践变得更好，又可以服务更多客户和行业，FDE 创造的效益便不再停留在单个项目里，后续项目的交付也有机会变得更轻。

客户价值、厂商收入和产品复用，少了任何一项，FDE 都很难从一批成功项目变成可持续的产业机制。

付费方式也可能随之变化。眼下常见的仍是一次一单，双方在合同里写清需求、周期和交付物。可当一个新场景用一两周便能判断是否值得继续，重新立项、招标、报价和验收所花的时间，可能比试验本身还长。

因此，按年签订持续服务合同，可能会比一次次购买项目更适合 FDE：客户购买的是一支在约定边界内不断发现、验证和上线高价值场景的团队，一个方向失败以后，可以把资源转向下一个。

再往前一步，理想状态是按结果付费，即现在讨论很多的 Result as a Service。客户购买的不再是工程师投入了多少人天，也不只是交付了几个智能体，而是周转时间缩短、故障率下降、收入增加或者风险减少。

但这一步显然还需要更成熟的条件。企业要有可以比较的业务基线，双方也要分清哪些结果来自模型，哪些来自流程调整、数据质量和组织配合；厂商能够控制多大范围，才可能为多大范围的结果负责。安全责任、极端事件和长期收益如何定价，也需要更多案例数据。

项目费用、长期服务合同和结果付费，更像逐步演进的三种关系，不会在所有企业中同时完成切换。

也正因为这套循环要求前线经验能够迅速回到模型、Agent 平台和产品研发，中国 FDE 的落地，科技大厂可能是更合适的牵头者。

Palantir 把这套机制称为“人类反向传播”。FDE 不是为每个客户永远手工解决问题，而是要把反复出现的问题带回研发体系。第一个项目里需要工程师处理的缺口，如果在第二个项目里变成平台的标准功能，现场服务才可能越来越轻。

一个企业提出的要求可能只是定制，多个行业反复遇到的权限、评测、高可用和数据治理问题，才值得被做成标准能力。平台公司既可以跨客户观察这种重复，也拥有把它送进产品路线图的研发资源。如果前线只能按照既定范围实施，却无法影响产品，它所做的工作更接近高级交付。

企业 AI 的生产问题又很少停留在单一层面。一次响应缓慢，背后可能是模型推理、算力调度或者数据库的问题；一个 Agent 无法进入流程，也可能牵涉数据治理、安全权限和生产运维。FDE 不必亲自解决每一层问题，但要在组织内找到相应的产品团队。

拿阿里云来说：它拥有从基础设施、模型服务、AI 开发平台到数据库、安全和运维的产品体系，现场问题因此有了比较完整的回流路径。全栈的意义并不是向客户方案里塞入更多产品，而是跨层问题能够找到责任人，也有机会沉淀进模型、Agent 平台和云产品，在下一个项目中不再重新解决。

应用真正运行以后，还会持续产生模型调用、Token、算力、数据库和平台服务的需求。云厂商可以用工程服务推动采用，再从持续使用中获得回报，也就不必完全依靠出售工程师人天覆盖成本。

翻看工业革命史、经济史里有一段与今天的 AI 落地颇为相似。

19 世纪末，工厂开始使用电动机，很多厂主最初只是把蒸汽机换成电机，厂房里的皮带、传动轴和机器布局却原封不动。

经济学家保罗 · 戴维研究电气化历史时指出，更大的生产率提升是后来才出现的：每台机器拥有自己的小电机以后，工厂不再必须围绕中央传动轴布置，机器位置、物料运输和生产流程都可以重新安排。

真正的生产力释放不在模型发布那一天，而在 AI 按照业务逻辑重新排列工作流程的那一刻 ——FDE 正是推动这个重新排列的人。

免责声明：本文为本网站出于传播商业信息之目的进行转载发布，不代表本网站的观点及立场。本文所涉文、图、音视频等资料之一切权力和法律责任归材料提供方所有和承担。本网站对此咨询文字、图片等所有信息的真实性不作任何保证或承诺，亦不构成任何购买、投资等建议，据此操作者风险自担。

广告声明：文内含有的对外跳转链接（包括不限于超链接、二维码、口令等形式），用于传递更多信息，节省甄选时间，结果仅供参考，IT之家所有文章均包含本声明。