易智企易成企业 AI 陪跑

行业观察

单厂商的技术栈,
交付时只够用四分之一

「我们支持多家模型」几乎每家公司都在说。但说到交付现场, 一个工程团队手上同时要处理的东西远比想象多。
这篇讲清一件事:供应商中立不是态度,是算术。 以及为什么越来越多企业急着把部署能力收回自己内部。

2026-10-15交付样本来自 Plank 自家项目,已标注局限

先说清楚

这份数据有立场,请先看清楚

下面的交付样本来自 Plank——一家卖 FDE 服务的公司—— 对它自己 15 个可完整标注的生产项目做的分析。 这不是行业抽样,是一家服务商对自己作品的披露。

它自己页面上也写明了两条限制:这些项目一个项目可能带多个标签, 所以比例相加会超过 100%;并且标注口径截至 2026 年 6 月,此后没有重算。 该公司当时列出的客户数是 47 家,被标注的只有这 15 个。

所以我们用它来说明「生产环境里的技术栈是异构的」这个现象, 不用它论证任何市场结论——它自家就是卖这个的,说这话有立场。 文中引的 Gartner、S&P Global、Christian & Timbers 则都回源核到了原始出处, 两类来源在下面分别标清。

一、交付现场什么样

15 个项目,没有一个栈是重复的

Plank 按工作负载、行业和工具标注了自己这 15 个项目,结果是这样的。

0

个项目技术栈完全相同

15 个可完整标注的生产项目

35+

种工具出现在交付里

含模型 API、agent 框架、语音栈、传统 ML 工具

60%

做的是 agentic systems

语音类占 27%,一个项目可能多标签

4

种工具是典型项目的中位数

这就是「一个厂商的栈要覆盖多少」的分母

「四分之一」这个数是怎么来的

典型项目用 4 种工具。在这些项目里出现最多的工具是 LangGraph, 但15 个项目里有 8 个没用它——也就是说连最主流的那个框架, 一半以上的项目都不需要。

单一厂商的技术栈要覆盖的,是这 4 样里的 1 样。这不是能力问题,是范围问题—— 一家厂商的工程师再强,他熟的那套东西也只占项目工作量的四分之一左右。

⚠️ 再强调一次:这是Plank 自家 15 个项目的观察,不是行业统计。 我们用它说明现象,不用它做结论。

二、一个更硬的第三方判断

吴恩达把这件事说成了可选性

Andrew Ng 在 2026 年 5 月 29 日的《The Batch》里讲这件事, 用词很克制但意思不客气——客户方常见的顾虑是,很难找到供应商中立的 FDE, 因为他们的存在意义就是把某一家厂商的产品深度集成进你的公司。

「当下很难预测一年后哪一家 AI 服务最好,所以可选性(日后能挑到最合适那家的能力)非常值钱。 反过来,让 FDE 把你的流程 tightly bind 住, 会显著降低这个可选性。」

—— 吴恩达《The Batch》,2026-05-29

他同一篇里还有一个判断值得放在这里:大部分公司更希望大量自己的员工会做 AI,而不是接受几个 FDE 嵌进来。 一家公司可能会接受少数 FDE 常驻,但更想要的是大量内部员工参与这些项目。

三、企业为什么急着把人收回内部

不是因为外部工程师不好,是因为怕流程外流

这是客户视角的利益逻辑,不是我们推销中立的说辞。

TechCrunch 2026 年 7 月 30 日那篇报道里,Christian & Timbers 的Jeff Christian 提到了几件反直觉的事:

  • 有些客户干脆买 Palantir 的技术,就为了能access 它的 FDE。
  • 但同时,企业在自建内部 FDE 团队——保险、金融、医疗、 游戏等行业的公司都有这个动作。
  • 动机很直接:大家都担心把专有业务流程交出去, 那些 AI 公司转头就能跟自己竞争——而这在很多行业里是真的。

一边买技术为了拿到人,一边自己养队伍看起来矛盾,其实指向同一件事:部署能力本身就是资产, 放在别人手里就等于把「怎么赚钱」这件事也交出去了。

70%

大型企业已在建或计划建内部 FDE 团队

出自 Christian & Timbers《AI-Native Builder Report 2026》。 同一份研究还发现一个经济学结论:招 3 到 5 个内部 FDE,靠减少外部部署采购, 大约 18 个月能把这笔投入赚回来。

18 个月

内部第二年的人,会积累出一种外部买不到的判断

原文的说法是:第二年的内部 FDE 已经知道「集成通常在哪里断」、 「审批流程实际怎么走」、「哪些系统最需要持续盯」。这个判断每多用一次就更值钱一次, 而且它只属于你们自己。

四、绑定的三种深浅

不是绑或不绑,是绑到哪一层

把话说具体一点,绑定程度是可以分级的。分清自己在哪一档,比争论「要不要中立」有用。

最轻的一种:单栈交付

一家厂商的工程师来做,用一家厂商的模型和框架。最常见,也最容易在合同里谈清楚边界。

风险不在技术,在三年后想换模型时整套东西搬不动。

中间一种:可迁移的交付

代码在客户仓库里,架构文档写清楚用了什么抽象层、哪一层是厂商专有的。换厂商时只需要改那一层。

难点在于大部分交付做不到这一层——抽象层要一开始就设计,事后补不出来。

最重的一种:把流程交出去

工程师不仅写了系统,还深度参与了业务流程的重新设计,而这些知识全部沉淀在工程师脑子里和厂商的项目文档里。

合同结束时客户手里剩下的是一份能跑的系统,和一个不知道它为什么这么跑的组织。

中小公司请不起内部团队,怎么办

答案是把绑定控制在第二档,不要滑到第三档。具体三件事:

  1. 代码进自己的仓库。这一条能把三年后换模型的成本,从「重做一遍」降到「改一层」。
  2. 专有框架的使用必须写进文档。换供应商时你至少知道要动哪里,而不是从零考古。
  3. 把项目切小,每次都留下能交接的东西。攒一个大的、最后谁都不敢动的系统,是最贵的失败方式。

说实话,这三条我们的服务边界就是这么定的——源资产(知识库、流程、提示词)归企业所有, 不是因为这样更体面,是因为客户出了这笔钱就有权拿走。

常见问题

还有五个问题

「供应商中立」听着像营销词,怎么判断一家服务商是不是真中立?

三个能当场问的问题。第一,代码进的是谁的仓库——如果答案是「我们的仓库,我们的模板」,后面都不用问了。第二,问他们做过哪些不同厂商的交付,能说出具体工具名才算数(说不出来多半只做过自家栈)。第三,问「如果客户明年要换模型,需要动多少东西」,答「很快」的不可信,答得出「哪一层要动、其他不动」才是真做过。最后看合同里有没有写清楚成果归属和退出交接。

为什么大公司反而更可能自己做,而不是买?

因为能力密度不够。有个反向的算账:一家公司招 3 到 5 个内部 FDE,靠减少外部部署采购,大概 18 个月能把这笔投入赚回来。这还是保守估计——如果这部分本来就要花。此外第二年的人会积累「在这个环境里集成通常在哪里断」的判断,这个判断每多用一次都更值钱。

中小公司请不起内部 FDE,是不是只能被绑定?

不是,但选择逻辑完全不同。中小公司的正确答案通常不是「选一个中立的」,而是「把绑定这件事控制在可接受范围内」。三个具体做法:第一,跟谁合作都行,但要求代码进自己的仓库——这一条能让迁移成本从「重做」降到「改一层」;第二,明确约定任何专有框架的使用都写进文档,将来换的时候你知道要动哪里;第三,更重要的是控制规模,把项目切成小步,每次交付都留下能交接的东西,而不是攒一个大的、最后谁都不敢动的系统。

文中引的 15 个项目,是不是行业普遍情况?

不是,要特别说明。这些数据来自 Plank——一家卖 FDE 服务的公司——对自己 15 个可完整标注项目的分析,不是行业抽样统计。样本小、有立场,是一份带营销意图的自家披露。我们用它来说明「异构环境是常态」这个现象,但不用它来论证任何市场结论。同理,文中引的 Gartner、MIT、S&P Global 等第三方数字我们都回源核到了原始出处,两类来源在正文中分别标注。

那我们到底该找谁做?

顺序比选择更重要。第一步不是挑服务商,是自己先想清楚「这件事为什么现在做、做完怎么算成功」;这一步不需要任何人进场。第二步是找愿意跟你一起把验收标准写清楚的人,而不是先比谁的案例多。第三步才是价格和速度。真正要签进合同的不是「我们派几个人」,而是三件事:代码进谁的仓库、什么算做完、做完之后谁接手。这三条不谈清楚,案例再多也不解决问题。

三个问题就能问出是不是真中立

代码进谁的仓库、做过哪些不同厂商的交付、换模型要动多少东西。 这三问答不上来,案例列得再多也不解决问题。

不承诺效果,只承诺把话说清楚。

数据来源与口径说明

  • 第三方来源(已回源核实):吴恩达《The Batch》2026-05-29; Christian & Timbers《Forward-deployed engineers are changing enterprise software buying》,其「70% 大型企业建内部 FDE 团队」与「3~5 人 18 个月回本」出自 《AI-Native Builder Report 2026》;人才规模与需求预测出自 Christian & Timbers 2026-07-30 的研究(独家提供给 TechCrunch,同日由C&T 官网释出更多细节)。
  • ⚠️ 自家披露(有立场,非行业统计):15 个项目的 35+ 种工具、0 个栈相同、60% agentic / 27% 语音、中位4 种工具, 引自 Plank《The State of FDE as a Service》(2026-06-11 发布、2026-10-09 更新)。 Plank 是一家提供 FDE 服务的公司,该数据是其对自家15 个可完整标注项目的分析,非抽样。该公司已披露:单项目可带多标签故比例会超100%, 标注口径截至 2026 年 6 月未重算,当时客户总数47 家、被标注的仅这 15 个。 本页仅用其说明「生产环境技术栈异构」这一现象,不用作任何市场结论。
  • 「tightly bind 会降低可选性」为吴恩达原话的中译,他的用词是 「significantly reduces optionality」,指日后更换供应商的自由度。
  • 本页不引用任何「全球 FDE 服务市场总营收」数字——多家报告(含 Plank 自身) 均未给出该口径的权威统计,多以资本投入与岗位数作替代指标。