公众号文章系列 · 28

AWS 砸 10 亿美元
把工程师送进客户现场

但真正的问题是：他们什么时候离开
Speaker姚光华 Colin
Role声网 ConvoAI 产品负责人
SourcesAWS 官方公告 2026-06-30 · Uncapped #42 · Cheeky Pint #27
Date2026.07
06·30
AWS 宣布了一笔很不「云计算」的投资。
这笔钱买的不是课、证书或路线图，
而是在真实数据、真实权限和真实治理约束下，把系统跑进生产。
10 亿美元
把数千名工程师直接送进客户环境，与客户一起开发和部署 Agent 系统。
6 月 30 日，AWS 宣布组建 Forward Deployed Engineering 团队。FDE —— 前置部署工程师 —— 突然成了 2026 年最拥挤的新岗位。 （AWS 官方，2026-06-30：Introducing Forward Deployed Engineering for Partners。）
开场 · 三类公司在互相靠拢04
AWS 对这件事的判断很直接

客户不再问路线图

AWS · 官方 企业 AI 已经超出了咨询建议的阶段。客户在问：谁能把生产级 Agent 放进我的环境里 2026-06-30 · FDE for Partners
01模型公司开始长出咨询公司一样的手脚
02软件公司开始雇能改组织流程的人
03咨询公司努力把自己的交付方法做成软件
这句话与 OpenAI 的 Deployment Company、Presence，也与 Sierra 的交付方式，落在同一个方向上。
我想追问的不是「为什么都要去现场」
01
这些工程师，什么时候能离开？
为什么去现场已经不用问这个问题已经越来越清楚：产品还吸收不了现场复杂度。
驻场只是开始它究竟是产品能力还是昂贵外包，要看这个人什么时候能够离开。
这是一条更难的标准驻场能证明你负责。退出，才能证明你做成了产品。
ACT I / III
ENTER
为什么一定要有人进场
模型写回复，只是这件事最小的一部分。
你不听客户的真实录音，就不会知道问题究竟在模型、音频链路、业务规则，还是组织本身。
I 为什么进场II 沉淀什么III 什么时候走
ACT I · 为什么进场07
Bret Taylor 讲过的一个典型项目

一家大型医疗器械公司

把 40 个呼叫中心合并成 1 个 模型写回复 最小的一部分 40 套流程怎么并 合规责任放在哪 班组主管怎么调 绩效怎么重算 谁也不敢动的 历史系统 Bret 给参与这类工作的角色，起了一个很准确的名字 forward deployed change management engineer
ACT I · 为什么进场08
前置部署的变革管理工程师

这三个词，缺一个都不行

01只懂工程不懂业务，只能把 demo 接进 API
02只懂业务不会动手，会再交付一份很厚的咨询报告
03不进现场两样都懂，但看不到客户嘴上说的流程，和真实发生的流程之间那条缝
所以，FDE 不是一种服务态度。它是当前产品还无法吸收全部现场复杂度时，临时长出来的一层人肉接口。
ACT I · 为什么进场09
语音 Agent 尤其如此

很少出现在需求文档里的那几样

01口音同一句话，不同地方的人说出来不是同一段音频
02电话信道压缩、抖动、丢包，demo 环境里根本不存在
03背景声背景电视声、车里的风噪，被系统当成一次打断
04内部黑话这家公司自己的产品代号、工单术语、简称
05抢话坐席什么时候会抢话，这条经验没写在任何文档里
这些东西决定系统能不能用。你不听客户的真实录音，就不会知道问题究竟在模型、音频链路、业务规则，还是组织本身。
MONEY QUOTE · 01
FDE 不是一种服务态度 它是产品还吸收不了现场复杂度时 临时长出来的一层人肉接口
这句话既解释了它为什么必须存在，也解释了它为什么必须消失。
ACT II / III
HARNESS
不只是多派一些人
如果只是堆工程师，10 亿美元会迅速变成一张昂贵的工时表。
AWS 在公告里给出的关键答案叫 delivery harness。
I 为什么进场II 沉淀什么III 什么时候走
ACT II · 沉淀什么12
现场经验要被压成什么

下次不能还只活在他的脑子里

AWS 公告里的关键词 · DELIVERY HARNESS 现场经验 只活在他脑子里 领域本体 评测框架 MCP server Agent 运维工具 context graph 记录架构与业务 第二个项目不必从零开始，第三十个项目才有可能比第一个更便宜 如果每来一个客户都重新访谈、重新写胶水代码，那不是 FDE 的规模化，是把定制外包换了一个更贵的英文名字。
ACT II · 沉淀什么13
与传统项目制最大的区别

不在于人更聪明

传统项目制
每次交付都从零开始
重新访谈、重新写胶水代码、重新靠某位老员工记住那些坑。
第三十个项目和第一个一样贵。
delivery harness
每次交付让下一次变轻
现场经验被压成可复用的工具、规则、评测和上下文。
第三十个项目才有可能比第一个更便宜。
区别不在于人更聪明，而在于每次交付是否会让下一次交付变轻。
MONEY QUOTE · 02
工程师这次在现场 学到的东西 下次不能还只活在 他的脑子里
这是 delivery harness 这个词最白话的翻译。
ACT II · 沉淀什么15
公告里藏着一个很有意思的矛盾

同一份公告，两句话打架

一方面 系统应该为 self-sufficiency 而设计 另一方面 harness 由合作伙伴永久拥有 究竟是谁变得自给自足？ 客户，还是 AWS 的合作伙伴
交付 IP 和复利优势留在合作伙伴手里，业务结果归客户。 如果 harness 永远掌握在外部伙伴手里，那么依赖并没有消失，只是从 AWS 转移给了咨询伙伴。
ACT II · 沉淀什么16
从客户视角看，只有三样东西作数

自己是否真的摆脱依赖

01带走业务规则和评测集能不能带走
02自改客户自己的团队能不能独立修改和回滚
03续跑供应商退出后，系统是不是还能稳定迭代
供应商想把经验变成复利，客户想把经验变成自己的能力。 两边都合理，所以边界必须在合同和架构里写清楚。
MONEY QUOTE · 03
供应商想把经验变成复利 客户想把经验 变成自己的能力
这是 FDE 商业模式里最核心的利益张力。两边都合理。
ACT III / III
EXIT
判断 FDE 和外包，只看一个问题
Sierra 也会上门，但 Bret 特别强调：
大多数客户最终是自己搭建、自己维护 Agent；现场团队的任务，是确保客户把这件事干成，并且不需要长期代劳。
I 为什么进场II 沉淀什么III 什么时候走
MONEY QUOTE · 04
FDE 的交付物 不是一个上线的 Agent 而是客户以后能独立 上线第二个 Agent 的能力
如果项目结束后，客户离不开原班工程师，它更像外包。
ACT III · 什么时候走20
上门交付之后，那条更重要的曲线

什么时候能离开

TIME FDE 在场强度 客户自主能力 这里才是交付物 客户能独立上线第二个 Agent 如果项目结束后，客户离不开原班工程师 —— 那是外包，不是 FDE。
ACT III · 什么时候走21
我会给每个 FDE 项目加一张表

退出验收单

01独立发布客户团队能独立发布一个小改动 —— 不依赖原 FDE 完成一次上线
02定位失败失败能够定位 —— 客户自己从日志走到根因
03修改规则关键规则能修改 —— 业务 owner 能改策略并跑回归
04能够回滚系统能回滚 —— 模拟一次错误发布并恢复
05资产归属评测资产归属清楚 —— 数据、题库、scorer 的权限写进合同
没有这张表，「我们会一直陪着你」听起来很负责，长期却可能是最危险的承诺。
MONEY QUOTE · 05
「我们会一直陪着你」 听起来很负责 长期却可能是最危险的承诺
因为它把「无法产品化」重新包装成了「深度服务」。
ACT III · 什么时候走23
前半年看起来几乎一模一样

好的 FDE 团队，和差的

好的
不断消灭自己做过的重复劳动
每一次现场经验都被压进工具、评测和产品，下一个客户更便宜。
差的
因为客户越来越多而线性扩招
并把「深度服务」当成无法产品化的遮羞布。
两者前半年看起来几乎一模一样。 两年后，财务模型会把差别全说出来。
ACT III · 什么时候走24
一笔经常不算的经济账

这套模式只在两个条件下成立

条件一 单客户价值足够高 × 条件二 每次交付能沉淀出 下一次可复用的东西 = 缺任何一个 毛利被人力吃掉 FDE 很重：既懂 Agent、又懂客户业务、还能处理组织冲突的人，本来就稀缺。
更准确的说法是：今天的 Agent 产品还没有把足够多的现场复杂度吞进产品，所以人先补在缺口上。
ACT III · 什么时候走25
语音这一侧比文本 Agent 多一个麻烦

人一走，系统就失忆

语音 FDE · 现场知识应当依次变成 录音样本 失败模式 评测题 策略配置 可重复的发布门槛 这条链路跑通，下一家客户会更快；跑不通，团队只是越来越会救火。 某个工程师知道这个客户的线路为什么会抖，某个产品经理知道那句方言为什么必须转人工 —— 如果这些没进数据集，人一走就没了。
ACT III · 什么时候走26
我开始觉得它不是一个独立部门

FDE 更像一个探针

它做什么
插进客户现场
把产品尚未吸收的复杂度带回来 —— 那些没写在需求文档里、只在真实电话里出现的东西。
谁该看它的工单
产品团队
一个健康的产品团队，应该能从 FDE 的工单里看见路线图。
好的 FDE 团队，会不断消灭自己做过的重复劳动。
一个更冷的判断27
同一笔钱，两种读法

10 亿美元说明了两件事

读法一 · 进攻 一张进攻性的支票 这一轮 FDE 复兴，说明企业 AI 的机会很大 读法二 · 供词 一份关于产品成熟度的供词 如果 Agent 已经像数据库一样标准化，就不需要数千名工程师进场 但这并不丢人。所有进入生产的技术，都要经历一段人比产品更重要的时期。
重要的是别把过渡形态误认成终局。
MONEY QUOTE · 06
你进去以后，留下了什么 你离开以后，客户还会什么
驻场能证明你负责。退出，才能证明你做成了产品。
带走29
如果只带走三件事

回去可以立刻加进项目的三样

01
给项目
立项就写退出验收单
独立发布、定位失败、修改规则、能够回滚、资产归属 —— 五条过不了，就还没交付完。
02
给团队
盯住扩招曲线
好的 FDE 团队消灭自己做过的重复劳动。客户越多、人越线性增长，是危险信号。
03
给产品
从工单里读路线图
现场知识要依次变成录音样本、失败模式、评测题、策略配置和发布门槛。
直到这支团队可以离开。
谢谢 · 来源与证据边界

AWS 砸 10 亿美元
把工程师送进客户现场

驻场能证明你负责，退出才能证明你做成了产品
Author姚光华 Colin · 2026.07
一手源AWS 官方 2026-06-30《Introducing Forward Deployed Engineering for Partners》
已核验10 亿美元 · 数千名工程师 · self-sufficiency · partner-owned delivery harness 均为官方表述
立场提示Sierra 案例来自 Bret Taylor 公开访谈；「项目从不失败」属公司方口径，本文未采用