FDE 101：驻场部署工程师

FDE

一、一个被 AI 拒绝的退款

一家公司把退款审核交给了 agent。它读每一份退款申请，对照退款政策，把不符合条件的驳回。上线时这套系统看起来是成立的：规则清楚，判断一致，速度比人快得多。

几周之后，一批合作多年的老客户开始流失。没有人说得清原因，因为把每一笔被驳回的退款单独拿出来看，政策白纸黑字写着应该驳回。系统没有违反任何一条规则。

后来去查这件事的人没有再翻政策文件，而是找到了以前做这份工作的员工，坐在她旁边看她怎么干活。她有一个动作从来没有出现在任何流程文档里：先看这笔订单是怎么付款的，如果是公司卡，直接批准，不再往下读。因为用公司卡付款的多半是每个月都来采购的企业客户，为了一笔退款跟他们争，代价是整个账户。这条规则是她自己在多年前琢磨出来的，公司的政策里没有它，也从来没有人问过她。

这个案例出自一位长期在大企业内部部署 AI 系统的从业者，经由一场公开分享转述。 1 它缺少可以独立核查的公司和项目细节，不能当成完整的案例研究；但它的意思不是模型不够聪明。系统执行得非常准确，出问题的是“什么叫正确”这个定义本身——真正在运转的那套规则，比写下来的那套多出了一条。

而把这条规则找出来的人，现在有了一个正式的职衔：forward deployed engineer，驻场部署工程师，通常简称 FDE，也写作 forward deployed software engineer，简称 FDSE。

二、一个岗位的重新出现

按照维基百科的定义，FDE 是一种面向客户的软件工程师，在客户公司内部开发和部署软件，常常与客户的员工在一段确定的时期内并肩工作。它的职责与解决方案架构师、售前工程师、客户工程师、专业服务工程师、系统集成商和 IT 顾问都有重叠，这也是这个岗位一直不太容易被讲清楚的原因。 2

真正把它和相邻岗位区分开的，是交付物和归属。传统的离岸开发模式里有一个现场协调员，他在客户那边收集需求、协调进度、处理变更，然后把需求传给另一个时区的开发团队，由后者写代码。FDE 不是这样。需求是他自己从客户那里挖出来的，方案是他自己设计的，代码是他自己写的，上线之后给使用者做培训的还是他。一位在职者用一句话概括：你拥有的是整个产品，而不是其中某个功能。他给出的时间分配是三成客户沟通，七成工程——这是单方自述，但和其他从业者描述的工作形态一致。

把这条边界写得最清楚的其实是招聘启事本身。OpenAI 在 2026 年 8 月挂出的旧金山 FDE 职位，要求与战略客户一起完成复杂模型的端到端生产部署：discovery、technical scoping、system design，一直做到 build 和 production rollout。衡量标准不是软件能不能跑起来，而是生产环境里的采用率、对工作流产生的可测量影响，以及能否通过 evals 拿到反馈，反过来影响产品和模型路线。 3 顺带一提，同一份职位说明里还写着最多约 50% 的出差。

所以这个岗位一直有人怀疑它只是旧职位换了个时髦名字。答案取决于具体公司，因为市场上并没有统一的 FDE 标准。解决方案架构师更关注架构设计和技术选型，未必持续写生产代码；售前工程师的目标是让客户在购买前理解并验证产品；顾问可以深入业务流程，但交付物往往是分析、方案和项目管理；专业服务工程师与 FDE 最接近，通常也负责实施和集成。FDE 的理想定义，是把这些角色之间最容易断裂的责任重新收回到同一个人或者一支小队手里：他既定义问题也写代码，既要让眼前这个客户用起来，也要把现场发现带回产品。现实中的职位差别很大，有的要开发完整的前后端系统，有的主要是配置厂商平台、写 SQL、搭工作流。判断一个职位是不是这里讨论的 FDE，看三件事就够了：他是否亲自构建进入生产的系统，是否对采用率和业务结果负责，以及他在现场学到的东西能不能变成产品的一部分。

这个岗位在 2026 年的扩张速度是可以被观察到的。亚马逊云在 2026 年 6 月宣布投入十亿美元建立一支嵌入客户内部的 AI 工程队伍，目标是让客户在几天之内具备自己用 AI 的能力。 4 一个月后，微软宣布向 Microsoft Frontier Company 投入二十五亿美元，配置约六千名行业专家和工程师，与客户一起设计、部署并持续改进企业 AI；微软同时强调，这套模式想要超过通常所说的 FDE。 5 OpenAI 和 Anthropic 都在以这个职衔公开招聘，Anthropic 还通过 Accenture、DXC、UST 这类合作伙伴组织面向客户的部署工程力量。风险投资机构 a16z 称它是创业公司里最热的岗位。至于流传最广的招聘增长数字——不同来源给出 729% 或者超过 800%——它们出自不同的统计区间，而且起点极低，只能说明热度，不足以证明这会成为一个长期稳定的大规模职业。 6

需要说明的是，本文引用的公开材料截止到 2026 年 8 月，下面所有关于热度和薪酬的描述都以这个时点为准。

三、智能被商品化之后

前沿模型现在几乎每周都有新的发布。对一家企业来说，这意味着同一批能力，谁付钱谁就有。模型能力不再是任何一家公司的差异所在，它变成了一种可以采购的商品。

按理说，输入变得如此廉价而强大，输出应该随之改善。实际发生的事情不是这样。

麻省理工学院的 Project NANDA 在 2025 年发布过一份题为《The GenAI Divide: State of AI in Business 2025》的初步研究，材料包括 52 场机构访谈、153 位管理者的问卷，以及 300 多个公开的企业 AI 部署案例。它观察到的现象是：只有大约 5% 的集成式试点迅速产生了可测量的损益影响，其余的没有跨过这条线。这份报告在传播过程中被大量简化成“95% 的 AI 项目失败了”，但这不是一个准确的转述——没有跨过一条相当严格的财务标准，不等于模型在技术上失败了。报告本身也注明是 v0.1 的 preliminary findings，样本口径和成功指标都有局限。 7 但它给出的归因是另一回事：问题不出在模型质量上，而出在集成方式和组织的学习能力上。这一条与本文引用的其他一手观察是一致的。

一个具体的形态是这样的。一位高管手上有一千万美元的 AI 预算，计划用一年。他的做法是把工具发给全公司，让每个人自己去用。三个月，预算见底，业务没有任何一项指标发生变化。钱确实花出去了，公司在它原本就在做的事情上没有变得更好。

这就是瓶颈转移。当能力可以直接买到的时候，剩下的问题不再是“模型能不能做”，而是“这家公司到底是怎么干活的”。后一个问题，没有任何供应商能在自己的办公室里回答。

四、没有被写下来的流程

帕兰提尔曾经因为一次文件格式迁移停滞了将近一年。技术上这是一件小事，新格式在各方面都更好。但团队里有一位工程师始终坚持新格式更差，又说不出具体差在哪里，迁移就一直推不下去。

僵局是靠观察打破的。有人去看她实际怎么使用这些文件，发现她核对数据的方式是双击把文件打开，而新格式没有可以双击的东西。团队当天晚上给她做了一个小工具，让新格式也能用同样的方式打开，两天之后她同意了迁移。

这类知识很难通过提问得到，原因不在于当事人不配合。真正在执行流程的人只关心一件事：把手上的活干完，输出尽可能顺利地产生。他们不研究流程本身，也没有理由研究。一个绕行方案在一个岗位上存在了几年之后，在执行者眼里就不再是绕行方案，而是工作本来的样子。你问他需要什么，他给你的往往是他想象中的某个东西，而不是他实际遇到的问题。

这也解释了为什么这件事必须由一个专门的人来做。公司内部的工程师有自己的排期，不会去梳理别的部门的流程；而流程的所有者身在其中，看不见那些对他而言早已透明的东西。这项工作既需要在场，又需要不属于那个位置。

五、判断智能该放在哪里

从两条相互独立的来源看，FDE 的工作大致分三个阶段：先搞清楚业务的实际运转方式，再判断智能应该被放在哪些环节、不应该被放在哪些环节，最后才是把软件建出来。

值得注意的是这个顺序里没有“选模型”这一步。客户说“我们想做一个客服 agent”，这还不是一个可执行的需求。要继续问下去的是：哪一类请求量最大？现在处理一次要多久？错了的代价是什么？数据在哪里？什么结果才算成功？这些问题答不上来，团队很容易做出一个很漂亮的对话界面，然后没有人说得清它到底改善了什么。

第一个阶段消耗的时间最多，而且它对在场的要求很具体。一位从业者的说法是，你约一个小时的会，对方讲的是他以为的自己的工作；你在他旁边待满一整个工作日，你看到的是工作本身。出问题的时刻不会写在 SOP 里，只会在你在场的时候发生。他补充说，这么做的另一半理由与信息无关：你坐在那里，你就是团队的一部分，能拿到的东西自然不一样。麦肯锡的顾问会下到矿场去和矿工一起待着，逻辑是同一个。

第二个阶段是这个岗位真正的技术内核，它决定了哪些环节交给模型。可以整理出三道筛子。一个环节如果遵循固定规则、而且每次都必须正确，那它就应该继续留给普通软件，不需要 AI。一个环节如果需要读一些杂乱的、非结构化的东西然后作出判断，那才是模型的用武之地。一个环节如果出错的代价很高，或者牵涉责任归属，那么即使模型能做，它也应该留在人手里。

把这三道筛子跑完，结论几乎从来不是“整条流程交给 AI”。一个被反复提到的真实分配是：八个步骤，四步完全自动运行，三步由模型执行、人工复核后再放行，最后一步完全由人来做——因为那一步是一个商业判断，而且要么错误代价太高，要么发生频率太低，不值得为它做自动化。这个比例不是行业基准，它只是一个例子，但它说明了一件事：生产环境里的 AI 系统通常是规则、模型和人拼起来的，而不是一个包办全流程的万能 agent。

在 AI 被普遍认为无所不能的那段时间里，行业的默认策略是把尽可能多的东西塞给模型。前面提到的那位从业者正是把 95% 这个数字直接归因于这种做法——这是他的判断，不是那份研究本身的结论，但两者指向的方向一致。

六、让系统在真实环境里活下来

判断做完之后是交付，这一段的经验大多与直觉相反。

先要接受的是这类系统的概率性。同一段传统程序对同样的输入给出同样的输出，模型不会：提示词一样，回答也可能不同；一个在演示数据上表现完美的 agent，遇到含糊的表述、缺失的字段或者格式异常的文件，可能走上一条谁都没有设想过的路径。所以要确认的不是“模型会不会做”，而是它在多大比例的情况下做对，哪些错误可以接受，哪些必须在发生之前被挡住。

最容易被违反的一条是，系统应该建在客户已经有的东西上面。agent 的价值取决于它能够到什么，但这不意味着应该为了让它够得着而重建系统。有一家客户花了五年、投入五百万美元才把财务系统跑起来，让他们换掉这套系统的可能性是零，于是工作的全部内容变成了让公司里其他的东西能跟它对话。如果一个团队所有的工作都在 Notion 里，正确的做法是用 MCP 把 agent 接到他们的 Notion 上，而不是把资料迁走。

同样反直觉的是不要过度改变人的工作方式。一个跑了很多年的十一步流程，如果被压缩成一步，使用者会停止使用它。他们原本在每一步之间都有自检的机会，现在中间的过程消失了，他们被要求相信一个凭空出现的答案。可行的做法是把步骤保留下来，让 agent 在每一步内部干活，人仍然看得见过程，也仍然能判断结果对不对。

更少被做到的是为失败路径做设计。用那位从业者的原话说，一件事做对只有一种方式，做错有一千种；如果你只为对的那一种写代码，你写出来的东西一文不值。对 AI 系统而言，这主要指模型不确定的那些情形——它在没有把握的时候同样会给你一个答案，而且看不出区别。演示只需要跑通成功路径，生产工程必须先回答另一个问题：输入缺失、工具超时、权限不够、模型没有把握的时候，这套系统会怎样失败。

回答这个问题的工具是 evals。它不是上线前考一次的试卷，而是一套一直在跑的反馈系统：收集有代表性的案例，明确定义什么算对什么算错，把模型问题、数据问题和流程问题分开，并且在每次更新之后确认新版本没有在改善一种能力的同时弄坏另一种。与它配套的是权限边界、调用日志、高风险操作的人工确认，以及失败时能够停下、降级或者回滚的机制——而不是让一个 agent 在生产环境里继续尝试。业务流程、数据和模型都还会变，评估标准也得跟着变。

最后是给建立信任留出比开发更多的时间。据转述，OpenAI 团队在一家全球大型银行的项目，技术部分六到八周就完成了，之后又用了四个月做试点和测试，顾问们才真正开始依赖它；这套系统最终被绝大多数顾问采用。一个人每天用同样的方式做同一件事，任何改变都需要自己挣得进入的资格，无论面对的是五千人还是五个人。采用率之所以是一个硬指标，是因为一个准确率很高却没有人用的系统，创造的业务价值是零。

这些工作最终都要落到同一本账上，而这本账只有三栏：增加收入、降低成本、减少风险。Cursor 遇到过一位客户，抱怨某个 agent 每天要烧掉两千美元。问下来，这个 agent 做的事情是决定派哪位工程师去修哪台坏掉的设备。再问他派错人一天要损失多少，答案高于两千美元，他当场就接受了。他此前一直在看这个 agent 花了多少钱，从来没有算过它省下了多少。

七、帕兰提尔的二十年

上面这套做法不是 2026 年发明的。

2004 年到 2010 年间，帕兰提尔手上有一套很强的产品，但它开箱即用不了。客户是中情局这样的机构和银行的业务部门，环境封闭，流程特殊，通用软件在那里落不了地。公司的解决办法是把工程师送进客户现场，在那边把产品改成能用的样子。内部把这些驻场的人称为 Delta，把总部做产品的人称为 Dev。

帕兰提尔今天对两者的区分仍然只有一句话：产品工程师做的是 one capability, many customers，建设一种能力，服务许多客户；FDSE 做的是 one customer, many capabilities，围绕一个客户的目标，把多种产品和工程能力组合起来。 8 这句话背后是企业软件长期存在的矛盾。软件公司希望卖标准产品，因为同一套代码服务更多客户才有规模效应；而大型机构的基础设施、数据和流程高度不同，只卖标准产品客户往往用不起来，每个客户从头定制又会把公司做成一家扩张不了的外包团队。FDE 模式是在这两者之间维持张力：允许必要的定制，但要求把现场反复出现的需求沉淀成平台能力、工具和交付方法。

这个模式在 2010 年前后被投资人普遍质疑。批评意见相当直接：你们不是产品公司，是一家服务公司，跟外包没有区别，这种模式规模化不了。帕兰提尔没有改。到 2020 年提交招股书的时候，这笔账被证明是算得过来的。

值得追问的是，既然这套做法二十年前就存在，为什么直到现在才被广泛采用。答案在于过去只有帕兰提尔那种产品需要这么重的交付，而现在，每一家买了模型准备接进自己业务的公司，都处在当年那些客户的位置上：手里有一件能力很强、但不知道怎么跟自己的流程接上的东西。前沿实验室几乎原样搬走了这套组织形式，因为他们面对的是同一个问题。

八、报酬与代价

关于这个岗位的收入，市面上流传的数字差异很大，原因是它们指的不是同一件事。

一个较早的基准来自帕兰提尔体系，大约是十二万到十八万美元的基本工资，加上股权和奖金，与资深工程师相当，区别在于要出差、要直接面对客户。前沿实验室的报价是另一个量级，而且有可以直接核对的部分：OpenAI 旧金山 FDE 职位在 2026 年 8 月列出的基本工资是 16.2 万到 28 万美元，另有股权； 3 第三方汇总的中高级别总包大致在三十五万到五十五万美元之间，这个口径不透明，只能当参考。至于流传更广的“年薪百万美元”，来自一位经营 FDE 相关业务、并在同一场访谈里试探培训招生的受访者，他的说法是从十五万美元基本工资起步，见过高至百万的岗位，但没有给出公司、级别，也没有说明这个数字是基本工资、年度总包还是含多年归属的股权。它只能证明市场上存在这种说法。印度市场的区间则是年薪 180 万到 450 万卢比，加上奖金可以到 700 万至 900 万卢比，按当时汇率大致相当于两万到五万美元、含奖金至八万到十万美元，同样出自单一来源。

热度的另一面被报道得少一些。《华尔街日报》在 2026 年 3 月刊出过一篇报道，标题直译是“科技行业最热的岗位并不怎么光鲜”：持续出差，在很短的周期内解决客户的问题，压力来自一个你无法控制的组织。 9 文章提到，正因为如此，相当一部分软件工程师并不认为这是一份值得去做的工作。这和从业者访谈里普遍渲染的“最热岗位”是同一件事的两种描述，两者都成立。

还有一部分代价不落在个人身上，而落在公司账上。为了拿下一个重要客户，团队很容易不断加进只对这一个客户成立的功能，时间一长就积成没人愿意碰的定制代码；如果 FDE 长期充当人肉接口，一家产品公司会慢慢变得越来越像一家咨询公司——这恰好就是二十年前投资人质疑帕兰提尔的那句话。这个模式解决的是部署问题，制造的是定制债务，两件事同时为真。

九、一个可能短暂的岗位

把上面的链条接起来：模型能力变成商品，差异转移到部署，而部署的难点是那些没有被写下来的组织知识，于是出现了一个专门负责把它们找出来的岗位。这条推理成立，但它同时给出了这个岗位的有效期限。

吴恩达在 2026 年 6 月的一篇文章里提出了两点质疑。 10 第一点是数量：一家公司可以接受少数几个 FDE 嵌入进来，但绝大多数公司希望做项目的是自己的员工，因此 AI Engineer 的岗位总量会远远超过 FDE。他自己的机构两类人都招，后者多得多。第二点更根本：客户普遍担心找不到厂商中立的 FDE。这些人来到你的公司，本来就是为了把某一家供应商的产品深度嵌进你的流程；在没有人能预测一年后哪家服务最好的时候，保留更换供应商的能力本身是有价值的，而让 FDE 把流程绑死，恰恰消耗掉的就是这个价值。

需要补一句的是，把客户交还给客户，本来就写在这套模式的目标里。AWS 在介绍它的 FDE 组织时，明确把项目结束之后客户能够自己运行、自己继续做下去列为目标之一。 11 一次做得好的部署应该留下三样东西：一套客户团队自己维护得了的系统，一套讲得清楚的评估方法，以及不必再把同一个人请回来的能力。反过来说，如果一个客户离不开驻场工程师，这个项目就还没有做完。

这个名字大概也不会存在太久。随着部署方法沉淀下来，一部分工作会变成平台功能，一部分会回到客户自己的 AI Engineering 团队，还有一部分会分化成 evals、LLMOps、安全治理或者行业解决方案这类更窄的岗位。名称会换，需要被做的那件事不会。

另一条反向证据来自这个模式的发明者。帕兰提尔现在有一个产品就叫 AI FDE，是一个用自然语言操作 Foundry 平台的 agent：你用日常语言提出要求，它判断该执行哪些操作，调用工具做完，再自己验证结果——运行 transform 预览、运行 function 预览、检查 CI，把输出当作下一步的输入。它默认在分支上工作，改动以变更提案或者 pull request 的形式提交给人审阅。 12 二十年前把工程师送进中情局的那家公司，正在把这项工作的一部分变成软件。

关键在于它做的是哪一部分。AI FDE 处理的是驻场工作里已经被明确表达出来的那一半：需求清楚之后的建模、写管道、改本体、生成代码。它接不了的是前面那一半——没有人会用自然语言向它描述“公司卡付款直接批”，因为在被人找出来之前，那句话根本不存在。值得注意的是，这个 agent 能安全工作的前提，是严格的权限、受控的上下文、分支、审查和闭环验证。工具越强，对“该让它做什么、能碰什么、怎么判断它做对了”的要求反而越高，而这些恰恰不是工具自己能回答的问题。

这里有一个容易被忽略的结构。有一家软件公司做内部工具时用了同样的方法：工程师先去 HR 和财务的工位上坐了一段时间，把所有重复的手工动作逐条记下来，再判断哪些可以交给模型。最后他们发现，那份写下来的东西本身就是这次开发的大部分成果——它直接变成了 agent 执行的指令和知识库。

也就是说，这份工作的核心产出是把一个组织没有写下来的运转方式写下来。而一旦它被写下来，它就进入了模型能够处理的范围。这个岗位存在的理由，和它自身被消解的路径，是同一件事。

1. This Is How Forward Deployed Engineering Is Actually Done，YouTube 公开分享。文中来自这场分享的案例均为从业者转述，无法独立核查，只用于说明工作方式。 ↩↩
2. Wikipedia, Forward deployed engineer，2026 年 5 月版本。 ↩
3. OpenAI Careers, Forward Deployed Engineer (FDE) – SF，2026 年 8 月访问。 ↩↩
4. Ashley Capoot, AWS puts $1 billion into new AI unit to embed engineers with customers, joining growing wave, CNBC, 2026-06-30. ↩
5. Microsoft Source, Microsoft Frontier Company: AI engineering that amplifies and protects your intelligence, 2026 年 7 月。 ↩
6. “超过 800%”一说见 Financial Times，经 invisibletech.ai 的 What is Forward Deployed Engineering? 引用；“729%”一说见 1 。两者统计区间不同，均未经独立核对。 ↩
7. MIT Project NANDA, The GenAI Divide: State of AI in Business 2025, v0.1 preliminary findings, 2025 年 7 月。 ↩
8. Palantir Careers, Students and Early Talent，“What is the difference between a Software Engineer and Forward Deployed Software Engineer?” ↩
9. Isabelle Bousquette, The Hottest Job in Tech Isn’t Very Glamorous, Wall Street Journal, 2026-03-12. ↩
10. Andrew Ng, Post on AI Forward Deployed Engineers, 2026-06-01. ↩
11. AWS Partner Network, Introducing Forward Deployed Engineering for Partners, 2026-06-30. ↩
12. Palantir Foundry Documentation, AI FDE Overview，2026 年 8 月访问。 ↩