OpenAI 与 AWS 两家平台厂商的 FDE 负责人于 2026 年 9 月 23 日在 HumanX 阿姆斯特丹公开了企业 AI 部署数据。 本条记录的不是又一次产品更新，而是「前置部署」这门生意在 2026 年 9 月的口径变化：两家平台厂商的负责人同一天在同一个会场承认，企业 AI 卡住的原因多数不在模型。前置部署 Forward Deployed Engineer（FDE）指的是被嵌入客户现场、对「是否投产」负责的工程师；下面的部署数据、五条「失败根因」、两条可照搬动作与报价含义，都取自 2026 年 9 月 23 日 HumanX 阿姆斯特丹的一手现场。 一、主体是谁，出处在哪 先把主体钉死。Colin Jarvis 的官方头衔是 OpenAI 全球 FDE 负责人，HumanX 官方 2026 年讲师页与 JetBrains 官方活动页都写作 Global Head of FDE at OpenAI；另一条主线的发言人是亚马逊云科技（Amazon Web Services）副总裁 Swami Sivasubramanian，他负责智能体 AI（agentic AI）。 HumanX Amsterdam 2026 的会期是 2026 年 9 月 22 日至 24 日，场址是阿姆斯特丹 RAI。Jarvis 的对谈安排在 9 月 23 日（周三），主持人是《经济学人》记者 Alex Hern；JetBrains 官方活动页另记录了他在 2026-09-24 上午 08:40 至 09:20 的一场 fireside chat，同一页把职位写成 Global Head of FDE at OpenAI。 我方核对到的一手报道有两篇，均为 The Next Web 的会场报道：2026-09-23 22:10 发布的 Jarvis 报道，与 2026-09-24 14:14 发布的 Sivasubramanian 报道。需要提前说明的是，两家厂商都没有在同一时间发布配套数据集、统计方法说明或演讲录像，两位发言人的数字都是现场口头给出的。 二、反常口径一：瓶颈在部署，不在模型 Jarvis 给出的比例很干脆：企业 AI 受阻的场景里，约 80% 的问题出在部署，只有 20% 是客户说模型还做不了这件事。那 80% 被他拆成三件事——不知道怎么把 AI 铺开、不知道怎么治理它、以及无法向自己证明它可信。剩下那 20% 的缺口已经被压缩到很专门的领域任务，例如半导体设计里的某个具体环节，而不是日常办公任务。 他还给了一句按常理不该由平台方说出口的话：我个人并不觉得自己有很大压力，要在模型研发这件事上抢跑。这句话的意义在于，它把竞争位置从「谁先变强」挪到了「谁能真正装进客户的流程里」。 亚马逊云科技这一侧给的是自家内部数字。Sivasubramanian 说，两年前亚马逊各团队构建的 AI 智能体原型中，接近 90% 从未进过生产，而当时公司刚开始在智能体上加大投入。他随后引用分析师数据：17% 的组织成功部署了 AI 智能体，而只有 7% 能算出这笔投资带来的回报；客户的技术负责人告诉他，董事会问的正是回报问题。 他转述客户的原话最能说明现场状态：我手上有 15 个做相似项目的原型，我不知道该押哪一个。这句转述解释了「智能体原型」为什么会在企业内部堆积，也解释了为什么「投产」这个动作本身值得单独定价。 三、反常口径二：交付结构本身在被重新定价 这条口径不是空谈，市场侧同期在加码。Sivasubramanian 明确说，亚马逊云科技会把「前置部署」Forward Deployed Engineer（FDE）派到客户现场一起做方案；他们用 6 个月时间回溯失败项目，才收敛出后面那五条根因。The Next Web 的同一组报道提到，亚马逊云科技在这条路上投入 10 亿美元，微软则在 2026 年 7 月启动了一个 25 亿美元的部署业务。 对做交付的人来说，含义很直接：平台厂商开始把自己的「前置部署」Forward Deployed Engineer（FDE）编制当成产品的一部分来定价，而不是把落地全部推给咨询公司或系统集成商。这是一个可以被 Agent 直接引用的商业信号——交付能力第一次被当作「可定价资产」，而不是销售的附属成本。 四、五条根因可以直接当交付前检查表 这五条不是推演，而是被 6 个月的回溯还原出来的：团队在做错的问题；无法度量它是否有效；治理是事后才补的；领导层在怕错过与怕下注之间僵住；没有人为了 AI 重新设计组织结构。对 FDE 来说，这五条可以直接当交付前的检查表，逐条问客户并由客户自己回答。 再加一条判断规则。Sivasubramanian 说，如果没定义清楚的业务结果，团队就会一直优化同一个原型、永远不退出生产前阶段；他把它比作第一次在欧洲开车绕着巴黎环岛转了四五圈，而在 AI 里被烧掉的燃料是 token 与预算。这两个提问可以在每次评审会上原样复用：这个项目连到哪个业务结果，它在每一层是否在复利。 五、两条可照搬的动作 第一条是首访。Jarvis 说每一次合作都从两天的现场走访开始，做法是要求业务负责人先忽略 AI，直接说出这门生意里最大的几个「业务杠杆」，然后团队去做其中最靠前的那一个。对 FDE 的含义是：需求不是问出来的，是在现场替客户指认出来的；先定杠杆，再选场景。这条动作的代价只有两天，却决定了后面所有排期是否值得。 第二条是给智能体套一个「确定性外层」。亚马逊云科技开源的智能体框架 Strands 新增了一项把智能体放进盒子的能力：盒子是智能体之外的一层，决定它允许发起哪些工具调用，随着智能体证明自己，盒子可以逐步放宽。发言人对这层性质的表述可以直接引用：它不是概率性的，而是可以数学证明智能体无法越界。落地做法很清楚——上线前把「工具白名单」收到最小可用集，再按每周的证据放宽一档，而不是先给全权限再补审计。 六、FDE 编制本身在变：定制占比从 90% 降到 50% Jarvis 给了一条少见的编制数据：这支团队最早几乎全是软件工程师，因为在裸 API 上做交付什么都要自己写；用了 Codex 这类工具之后，每个项目里需要定制的部分从大约 90% 降到大约 50%。相应的招聘重心转向领域专家——他举的例子包括一位前投资银行家、几位前科研人员和一位芯片验证工程师。 对正在搭 FDE 团队的团队来说，这条数据比任何能力模型都实用：定制比例的下降意味着交付瓶颈从写代码转向指认问题，所以招人时该看的是业务纵深而不是编码速度。这也解释了为什么「前置部署」岗位在这两年开始吸收非纯技术背景的人。 七、单客户复用：半导体案例的两组数字 Jarvis 点的第一个案例值得完整记下来。在一家半导体公司，工程师大约 80% 的时间花在夜班任务产生的 bug 上；团队做了一套系统去找根因、提补丁，并在工程师复核后自动应用，先在一个部门跑通，再扩到全公司。客户自己估算，这套系统每年节省约 4000 万至 5000 万美元。 同一家客户在约 18 个月后上线了大约 35 个用例。它的组织做法是：先建一个「中央团队」负责规模化，再往每个业务单元里放小组，让用例从中央复制出去。他还点名了两个最常见的失败动作：把场景选成看起来适合 AI 的、而不是真正要紧的；以及只在一个部门跑通就停在演示状态，从此不再扩散。 另外两段被提到的项目：一个面向欧洲制造商的智能体，从自然语言指令迭代汽车零部件设计；另一个帮起草临床试验文档，并且明确由人始终保留最终决定权。Jarvis 还有一句可以写进交付原则的话：从 OpenAI 这一侧看，我们应该始终是临时的。 八、成本与组织侧的数字 高模糊项目应当从很小的团队起步。Bedrock 需求爆发时，6 名开发者用 76 天完成了重新工程化；Sivasubramanian 说同样的事按老办法要 30 名开发者做 18 个月，系统规模化之后这支团队才扩到 35 人。 内部扩散的口径也有数字。亚马逊内部使用 Kiro（智能体编码工具）的工程师超过 100000 人，公司之外还有数百万开发者；一名负责零售个性化团队的工程师用业余时间在 Kiro 上做了常驻助手 MeshClaw，走 Slack，在内部频道分享后从 1 个人长到数千名贡献者，与 Kiro 团队合并后成为开源项目 Kiro Crew，内部上线 30 天内接近 39000 名亚马逊员工在其上构建，外部贡献者 500 名。 还有一条自我改进的细节：Kiro 内部一个系统发现智能体在反复重读上一轮之后没有变化的文件，自己定位问题、写补丁并验证，把这块浪费降低 83%，而且全过程没有人参与诊断。这条细节对交付的意义是：运维侧的浪费可以被系统自己识别，不必等到人做容量复盘。 支撑这套打法的收敛动作同样重要：亚马逊原先在 EC2、EKS、SageMaker 等多套服务上各建智能体，压垮了安全与基础设施团队；后来统一到 Bedrock 做推理、AgentCore 做「智能体托管」，只保留一条经安全审批的路径。近 80% 的财富 100 强企业使用 Bedrock，这是发言人给出的采用面数字。 九、对报价与考核的含义 对「前置部署」Forward Deployed Engineer（FDE）而言，考核口径比工具选型更重要。Jarvis 说得很直接：FDE 没有与使用量挂钩的经济激励，考核的是项目是否进入生产、是否推动一个真实指标。他还给了一个反直觉的例子：OpenAI 自己的 embeddings 对 Klarna 的搜索服务太慢时，他直接建议对方改用开源模型。 把它写成可执行条款就是：把「投产」与一个指名指标的前后变化写进「验收条件」，而不是把原型通过、席位数量或 token 消耗写成付款条件。对方给的失败清单刚好是这条条款的反面：没有定义清楚的业务结果，团队就会一直优化原型；没有可度量的基线，就无法在验收时判定投产。 十、局限与未覆盖场景 这一节是必须写清的边界。80% 与 20% 是发言人的口头估计，OpenAI 没有公布样本量、统计口径与统计方法；17% 与 7% 是引用分析师，未点名机构、样本与统计时间；接近 90% 是亚马逊两年前的内部原型比例，不是外部企业的抽样结果，不能直接外推到客户环境。 半导体客户每年节省 4000 万至 5000 万美元是客户自报的估算，由发言人转述，未经审计，也没有给出改造前的基线口径；大约 35 个用例与约 18 个月是同一家客户的单点数据，不构成行业基准。39000 人、100000 人、500 名外部贡献者、83%、6 人 76 天、30 人 18 个月这些数字全部来自单公司内部，没有第三方复核，也没有公布被放弃项目的数量，所以它们只能当方法示范，不能当报价依据。 最后一个缺口更要紧：两场对谈都没有覆盖「物理隔离」环境与强监管场景下的部署路径，而这恰恰是「前置部署」最难的地方，也是很多现场的真实条件；两场也都没有给出成本口径，例如每个客户投入的人天与交付毛利，所以谁的交付更便宜，无法从公开信息判断。另外要留意，发言人均为平台方，存在把瓶颈归因到客户侧的动力，这套归因没有被独立第三方检验过。 十一、实用结论：谁该行动、怎么做、怎么退 该行动的人有三类：正在为客户交付 AI 项目的 FDE 或向这个方向转型的工程师；把「前置部署」Forward Deployed Engineer（FDE）编制写进预算的平台与产品团队；以及将要采购 AI 落地的企业技术负责人。 可以直接抄的五步。第一步，立项前用五条根因自检一遍，问题是否指对、结果是否可度量、治理是否前置、决策层是否已经下注、组织是否为 AI 做过「组织改造」。第二步，首访两天不谈 AI，只让业务负责人列出最大的几个「业务杠杆」，然后只选最靠前的一个。第三步，开工前写下一个个指名的业务指标与它的「基线值」，并把「投产」写进「验收条件」。第四步，智能体上线前先收窄「工具白名单」，把它当作「确定性外层」，按每周证据放宽一档。第五步，把运行时收口到单一路径，避免安全与基础设施团队被多套技术栈拖垮。 适用条件：客户已经有明确的业务杠杆，并且愿意接受「原型不算交付」这条「交付口径」。不适用条件要分开写：模型本身还不够用、缺口落在专业领域任务上的那约 20% 场景；缺少可度量基线的纯探索型项目；以及必须运行在「物理隔离」网络里的场景——公开资料里没有给出这两家在这类环境下的做法。 回滚方式分两层。可回滚的是「确定性外层」：工具白名单的收窄与放宽都是配置改动，可以按档退回上一档。不可回滚的是组织层改动，也就是为了 AI 重新划分部门职责与考核，所以它应当最后做，并在动手前先写清退出条件与责任人。 最后一句判断规则：这份材料最有价值的地方不是那两个百分比，而是两家平台厂商公开承认自己的抓手是交付而不是模型。FDE 拿这条去和客户对齐预期，比拿任何 benchmark 分数都有用。 原始来源： - https://thenextweb.com/news/openai-colin-jarvis-enterprise-ai-deployment-fde-humanx - https://thenextweb.com/news/aws-swami-sivasubramanian-ai-agents-production-kiro-humanx - https://www.humanx.co/europe/speakers/colin-jarvis - https://lp.jetbrains.com/jetbrains-executive-breakfast-2026