前线部署工程师与最后一次交接

这是新概念吗？

2026年8月，我与一位产品经理进行了一次备用通话。我们正在讨论他的解决方案和开发流程，这时他停下来问我是否知道"前线部署工程师"这个术语。他称其为新热点，是目前每个人都想采用的工作方式。他解释说，Palantir有一个基础产品，并派遣自己的工程师到客户现场进行适配。同一个人负责产品决策并编写代码。Anthropic也开始这样做。

我的回答是：这才是开发者本应一直采用的工作方式。

他立即表示同意，然后告诉了我一个更好的事情。他自己公司的主要产品正是以这种方式诞生的。多年前，一位客户告诉创始人，他本人可以更好地编程实现它。创始人说：那就去做吧。他去了客户那里，坐在钢厂里，一个版本接一个版本地改进软件。这就是为什么该产品至今仍能如此精准地贴合钢铁客户的需求。

两分钟的对话，整个论点就已经摆在了桌面上。一种被描述为全新的模式，被亲身经历者瞬间识别。一家公司的最优秀产品之所以存在，是因为有人曾经拒绝通过代理工作。

这个术语值得被严肃对待。它也值得被解构，因为行业讲述这个故事的方式，隐藏了真正起作用的部分。

这是新概念吗？

Palantir创造了这个角色，并在内部称之为"Delta"，这是当年业务开发部门每个团队都以北约字母表字母命名的遗风。该公司对这一分工的描述，正是承载整个理念的那句话：

"你可以将Dev的焦点理解为'一个能力，多个客户'，而Delta的焦点是'一个客户，多个能力'。"

这不是一份职位描述。这是一个切分决策，我们稍后会回到这一点。

到Palantir上市时，这个角色已成为投资案例的一部分。S-1文件告诉股东："我们的前线部署工程师（'FDE'）曾前往阿富汗的基地和中西部的工业工厂部署我们的平台"，并补充了关键机制："实地时间有助于我们平台的持续改进。"

Palantir商业业务负责人Ted Mabrey将这一灵感追溯到软件之外的事物。Alex Karp观察了法国优秀餐厅的工作方式。服务员是厨房的一部分。如果你为鱼肉点了错误的酒，他们会告诉你不行，因为关键在于让你获得最佳的一餐，而不是你恰好知道如何点的那一餐。

那么，这是新概念吗？实践并非新事物。自从软件开始销售以来，工程师就一直坐在客户现场，任何曾派遣过开发者的咨询公司都知道这种形态。我在那次通话中的回答是诚实的。

新的是三件事。这个角色有了一个名称，而有名称的角色就可以被招聘、定级和庆祝：风险投资公司a16z称其为科技行业最热门的工作。然后，一家供应商将其作为市场进入的主要方式，而不是依附于销售流程的支持功能——直到2016年左右，Palantir雇佣的FDE比普通软件工程师还多。最后，这种模式现在已跳转到构建模型的公司。

Anthropic在慕尼黑招聘一名前线部署工程师的广告，正是在那次通话前一天发布的，要求一个人做到：在客户系统内构建生产级应用程序，交付在生产工作流中运行的技术产物，将可复制的部署模式编入产品和工程部门，出差25%到50%的时间，并在整个参与过程中维系客户关系。Palantir自己的广告则说得更直白：其职责类似于初创公司的CTO。

新的不是实践。而是一家软件供应商将其作为市场进入的主要方式。

XP早已解决了这个问题，只是方向相反

二十年前，同一个问题有不同的答案。极限编程将了解问题的人与构建解决方案的人之间的距离识别为需要消除的东西，并通过移动客户来消除距离。Ron Jeffries描述了这个至今仍被遵循的实践：

"团队围绕一个被称为'客户'的业务代表形成，该代表与团队坐在一起，每天与他们一起工作。"

在《Extreme Programming Explained》第二版中，Kent Beck将"整个团队"列为主要实践，将"真实客户参与"列为辅助实践。方向是明确无误的：将客户带入团队房间。

前线部署工程师则沿着相同的论证反向运行：将团队送入客户现场。

同一个问题，相反的方向。有趣的问题是为什么方向发生了反转，答案并非时尚。而是可移动的东西发生了变化。

1999年，不可移动的是开发环境。构建机器、测试套件、结对工作站、故事卡片墙：所有这一切都在一个房间里，最便宜的做法是移动那个能为业务发声的人。今天，不可移动的是客户的上下文。数据因法律原因无法离开大楼。模式未经文档记录。流程知识是隐性的，存在于工厂车间人员的头脑中。有时网络是物理隔离的，什么也出不去。与此同时，工程师变得便携了，因为他们下面的平台——以及现在平台下的模型——可以随他们一同移动。

此时Scrum通常会被指责，但这种指责是错位的。有必要精确说明，因为误读才是本节真正的主题。

Scrum指南从未说产品负责人站在客户和团队之间，"代理"一词也未在其中出现。它分配了责任，然后用直白的语言排除了经纪人式的解读：产品负责人"可以亲自完成上述工作，也可以将责任委托给他人。无论如何，产品负责人仍然负责。"整个Scrum团队"负责从利益相关者协作开始的所有产品相关活动"，而Scrum Master被要求通过"消除利益相关者与Scrum团队之间的障碍"来服务。

名称本身也说明了这一点。是负责人，而非经理。责任在于做决策，而不是代表他人收集需求。

代理是一种现场模式，而非规则。组织想要一个明确的问责对象和一个看起来熟悉的职位来提拔人，而大量二级文献也乐于将需求经纪人版本的产品负责人卖给他们。这正是大多数企业实际运行的版本。

LeSS明确写下了纠正。其原则指出，产品负责人"是客户/用户与团队的连接者，而非中间人"，并且"团队与客户/用户进行详细的细化/分析（而非产品负责人）"。这是通过澄清路径，在一个规模化框架中，在软件行业还没有人公开提及前线部署之前很多年，对那种现场模式的解构。

因此，前线部署工程师所推倒的墙，从未存在于规则之中。它是在现场建造的，现在正从另一侧被拆除，并以创新的名义出售。

然而，有一个真正的区别值得精确指出。XP和LeSS是在一个组织内部——通常是客户自己的组织——移动人员。而FDE跨越了公司边界，并且费用由供应商承担。

缩小与客户的距离并非新事物。让供应商承担缩小距离的成本才是。

同一个问题，相反的方向：XP将客户引入内部，FDE将团队派出外部，并将所学反馈回来

为什么是一个角色，而不是一个团队？

以下是我对这种模式被推销方式感到困扰的地方。关于FDE的一切文字，都是关于一个人的。科技行业最有价值的证书。集产品经理、开发者和销售于一身的工程师。Mabrey写道，是熔炉将FDEs变成了巨人。这些文献是一个英雄故事，而英雄故事是复制错误东西的最可靠方式。

业界以这种方式构建框架，有三个诚实的原因。

一个职位头衔是招聘工具。你无法在招聘网站上发布一个"反馈循环"。你可以发布一个角色，定级，并为此付费，这就是一个正在扩展市场进入方式的公司所需要的。

客户边界是个人形态的。信任、地位和政治沟通发生在个体之间。在Palantir担任了近八年FDE的Nabeel Qureshi，对此异常直率：在客户处成功需要对社交背景有异常敏锐的感知，而公司的词汇表中充满了从即兴戏剧借用的术语。一个团队无法坐在利益相关者的办公室里。一个人可以。

经济因素需要一个名称。一个将系统集成成本内部化的供应商，希望该成本可按账户归因。

这三者都是真实的。但没有任何一点使个体成为产生结果的单位，而Palantir自己的材料也说明了这一点。Delta被描述为"直接支持一个客户的团队的一部分"。Qureshi描述了使该模型产生回报的机制：FDE在客户现场快速而粗糙地构建，然后产品开发工程师将FDE构建的东西产品化。Foundry并非作为一个现成产品到来并被部署。它的每一个工具都始于FDE在客户现场必须手动完成的苦差事，直到有人将其自动化。

因此，工作系统不是一个人。而是一个团队，后面还有第二个团队，以及两者之间运行的循环。将其称为角色，隐藏了循环，而这正是Mabrey观察模仿者失败的原因：

"他们在复制形式，而非FDE的功能。"

一个讽刺之处属于本节，因为这是同一错误在更高层面上的重演。Palantir故意几乎给所有人相同的职位头衔，其理论是头衔会变成欲望的对象，而欲望会变成内部政治。市场现在已将这个反头衔变成了它本意要防止的地位阶梯。

一个团队对其工作产生的结果负责。一个头衔则不会。

同样的根本原因

将系统性结果归功于个体，是一个舒适的错误，并非Palantir独有。每当结构性转变首先以某人工作的形态出现时，这种情况就会发生。这一切也并非AI时代的巧合。Andy和我在《The AI-Enhanced Team of the Future》中追溯了同样的力量，它产生了这两种现象。

这种力量是：一个单一社会单位能够掌控的价值链跨度已经变宽，因为其下方的层级已经成熟。这就是观察到的"进化聚焦"而非规定，其信条是：某物在从起源到商品的路径上的位置，决定了你如何围绕它进行组织。当计算、部署以及现在的生成走向商品化时，站在它们之上的单位可以用同样数量的人触及更远。

带着交接的视角重读团队演化的四个时代。组件团队将工作移交给集成者。全栈团队吸收了那次交接。DevOps团队吸收了与运营的交接。AI增强团队将生成和集成吸收到团队自身内部。每个时代都移除了公司内部的一次交接，到了第四时代，基本上只剩下一次：公司边缘的交接，即供应商停止而客户开始的地方。

那就是前线部署工程师移除了的交接。这是同样的运动，只是向外推进了一个边界。

Palantir与AI供应商之间的区别，仅在于平台来自何处。Palantir花了二十年，一次FDE参与接着一次FDE参与，构建自己的底层，直到Foundry存在。AI供应商则是从模型那里得到了一个现成的底层，可以尝试在单一轮招聘中达到同样的触及范围。相同的气候模式，不同的基质，而第二组尚未证明它能完成困难的一半。

一旦你将Dev和Delta的分工解读为一个切分问题，它也不再像一个组织结构图。切分产品区分了垂直切分——端到端地获取一个客户的价值——和水平切分——跨多个客户获取一个能力。"一个客户，多个能力"是垂直切分。"一个能力，多个客户"是水平切分。Palantir同时运行两者，且不假装这种张力不存在。Mabrey将FDE与核心产品团队之间的关系描述为冲突重重，并由持续的矛盾所定义：FDE被鼓励构建定制软件，Dev被鼓励为了高价值机会放弃他们的路线图，Dev同时也被鼓励忽略FDE。

团队演化的每个时代都移除了公司内部的一次交接。前线部署工程师移除了公司边缘的那一次。

共同点与不同点

| | 前线部署工程师 | AI增强团队 | | --- | --- | --- | | 范围 | 端到端，从发现到生产 | 端到端，从需求到市场增长 | | 代理 | 已移除，工程师直接与客户沟通 | 已移除，团队定义意图和验收标准 | | 方法 | 构建，在客户现场观察，修正 | 预见，推进，评估 | | 稀缺资产 | 单个客户的领域知识 | 领域知识和判断力 | | 责任单位 | 个体，以被推销的方式 | 团队 | | 定义性特征 | 位于另一家公司内部 | 范围与工具集，位置无关 | | 谁的目标 | 两个，处于张力中 | 一个目标，一个竞技场产品 | | 循环在哪里 | 公司特定，依赖关键人员 | 在规则中，匹配与锦标赛 |

该表的上半部分是共识，而且这种共识是实质性的。两种模式都押注端到端范围胜过专业化，中间经纪人成本高于其节省，并且随着执行成本降低，领域知识变得更加宝贵。杰文斯悖论适用于两者：降低构建成本，范围会扩大而非人员规模缩减。

下半部分是我们分道扬镳的地方，最后一行是最重要的。Palantir的循环有效，Mabrey大致指出了没有哪八个人他认为该循环无法运转。一个依赖公司内特定人员的循环，不是运营模式。它是一种幸运的配置，而那些致敬乐队就是证据。

那么，AI增强团队成员就是前线部署工程师吗？

部分是的，而不同之处才是关键。

在范围和姿态上是的。第四时代团队成员拥有业务成果而非组件，在价值被评判的现场进行实证工作，并且不等待代理为他们翻译客户。除了他们所在的房间之外，不改变这个人的任何东西，招聘广告读起来也会一样。

在责任单位和谁的产品被构建上则不是。一位FDE同时服务于两个目标——客户的成果和供应商的平台——并亲自保持这种张力。一个竞技场中的团队服务于一个目标和一个竞技场产品，张力由结构承载，而非个人的耐力。

这给出了更清晰的表述。前线部署工程师是当目标要求团队处于客户系统内部，而非客户处于团队系统内部时，AI增强团队所呈现的样子。它是一种部署模式，而非一个独立的工程师物种。

这种解读也告诉你该做什么，以及不该做什么。复制头衔而没有背后的团队，也没有反馈到产品的循环，你就购买了模型中最昂贵的东西，却得不到任何杠杆。你已将系统集成成本内部化并为此雇佣了人员。这是"AI不会修复你的官僚主义"这个失败模式穿上新职位头衔的表现：一个看起来像进步的变化，因为它在组织结构图上可见，而产生问题的结构却原封不动。Mabrey自己的结论，从内部来看，也是一样的：

"主要经验教训是不要复制FDE，而是要促使你问自己：你对公司的架构做出了哪些假设，以及你是否应该复制任何东西。"

前线部署工程师不是一个工程师物种。它是一个站在不同房间里的团队。

这对你意味着什么

三个问题，值得按顺序回答。

哪一次交接是你最后的交接？映射从客户问题到工作结果的路径，找到仍然需要翻译的边界。在大多数企业中，这根本就不是供应商边界。而是那些与客户交谈的人和那些构建产品的人之间的边界，而且它通常有一个部门名称。

谁对结果负责，是个人还是团队？如果答案是一个被点名的人，你就有一个英雄模型，它只会在那个人留下的时间内有效。如果答案是团队，你就拥有了在有人离职后仍能存续的东西。

你在客户那里学到的东西如何重新进入你的产品？这个问题区分了模式和致敬乐队。如果一个参与的洞察落在一个幻灯片、一份经验教训文档或无处可去，你已经为接近客户付了费，却扔掉了回报。Palantir将这种回报变成了Foundry。在AME3中，同样的回报有一条明确的路径：它作为一个改进进入竞技场待办列表，而匹配迫使某人去看它。

这种模式是真实的，围绕它的热情是应得的。只是不要把站在客户面前的那个人，误认为是让一切奏效的那个东西。

参考文献

• Bruno Pontes Soares Rocha, Dev versus Delta: Demystifying Engineering Roles at Palantir, Palantir Blog, April 8, 2019
• Palantir Technologies Inc., Form S-1/A, SEC, September 2020
• Ted Mabrey, Sorry, that isn’t an FDE, September 20, 2024
• Nabeel S. Qureshi, Reflections on Palantir, 2024
• Gergely Orosz, What are Forward Deployed Engineers, and why are they so in demand?, The Pragmatic Engineer, 2025
• Anthropic, Forward Deployed Engineer, Munich, posted August 17, 2026
• Kent Beck with Cynthia Andres, Extreme Programming Explained: Embrace Change, 2nd Edition, Addison-Wesley, 2004
• Ron Jeffries, What is Extreme Programming?
• Craig Larman and Bas Vodde, Customer-Centric Thinking, LeSS
• Ken Schwaber and Jeff Sutherland, The Scrum Guide, November 2020
• Definition entry: Forward Deployed Engineer