关于这篇文章是如何写成的说明：其中的思考、研究和观点都是我本人的，文字和图片皆是如此。AI 只负责组装。我之所以采用这种方式，是因为它让我学习和思考得更深入，而不是更浅，这一点值得公开说明，而不是悄悄地免责。

Palantir 的创始人在情报界拓展首批客户时遇到了一个具体问题：他们不认识任何间谍。没有人脉，没有热情的引荐，没有任何可以用来销售的关系。于是他们做了每个创始人都会被告知要做的事：做一个演示，把它摆在真实的潜在用户面前，收集反馈，然后迭代。

这部分故事是标准的创业建议。而非标准的是他们在找到产品市场契合之后发生的事情。

大多数公司一旦知道该构建什么，就会转向规模化：一个产品，以同样的方式卖给每个客户，目标是随着时间推移减少每个客户的定制工作。Palantir 做的却近乎相反。它构建了一个平台，并把自己的工程师直接派驻到每个客户的办公场所，在平台之上构建该客户所需的具体东西。这种嵌入式驻场并不是需要最小化的开销，而是被当作真正的产品本身。

这就是前沿部署工程师的起源。在你决定自己的公司是否应该建立这样一个团队之前，值得先理解其运作机制。

为什么 LinkedIn 上的版本并不是故事的全部

我在 LinkedIn 上关于这个话题的文章讲的是头条新闻：微软、亚马逊、OpenAI 和 Anthropic 都在同一个月向前沿部署工程部门投入了真金白银，合计接近 90 亿美元，因为 MIT 研究的 95% 的企业 AI 项目没有可衡量的业务影响。这是公开的论点，也是真实的。

它没有讲到的是，决定任何一个 FDE 项目能否成功的因素：那个将其与“头衔更好听的高价咨询”区分开来的内部设计决策。这是一个领导力问题，而不是招聘问题，也是我在建立或投资这类项目之前想要得到解答的问题。

招聘启事中遗漏的两个角色

Palantir 的模式依靠两个不同的职能协同运作。一个有时被称为 Echo 团队，是具有真正领域深度的嵌入式分析师（通常是前军人、前医疗行业人士，即曾亲身生活在所销售的目标世界中的人），其职责是找到客户关系并确定哪个问题值得解决。另一个是 Delta 团队，是快速将问题转化为可运行原型的工程师，并且默认第一版会被丢弃。

这两个角色缺一不可。没有 Delta 团队的 Echo 团队只会产出毫无交付成果的客户关系管理。没有 Echo 团队的 Delta 团队则会产出技术上令人印象深刻、但客户中没人需要的软件。

只有当发现的问题恰好属于客户自身 CEO 最优先的五项工作之内时，调研成果才能在客户组织中存活下来。如果解决的是与之相邻的问题，无论多么巧妙，客户组织内部都没有推动它落地的动力。

尚未完全化解的张力

大多数试图复制这一模式的尝试正是在这里悄然失败的。FDE 的职责是用最简单可行的方式解决某一个客户的问题：碎石路。产品团队的职责是构建能同时服务众多客户的东西：铺装路。这两件事在结构上通常截然不同。

如果产品团队试图坐在房间里苦思冥想来设计铺装路，而没有 FDE 的输入，他们往往会造出错误的东西。行之有效的模式是：FDE 团队为某一个客户交付成果，带回给产品团队，产品团队识别出哪些其他客户也能受益，而在设计通用版本时，来自这些其他客户的 FDE 也加入讨论。

这也是对“这不就是咨询吗”这一批评的诚实回应——这个批评提得有道理。新客户的利润率往往从负数起步，只有在现场工作一年或更久之后才转为正值，如果故事到此为止，看起来确实像一门服务业务。它之所以不是服务业务，原因在于 Palantir 投入建设了一个通用的底层模式（schema），一套由对象、属性和链接组成的“本体”（ontology），其灵活性足以编码截然不同的领域（一个人、一艘船、一笔转账），而无需为每个客户定制产品。为单个客户构建有永远过拟合于该客户的风险。关键纪律在于每次都向上提升一层抽象，直到找到跨客户共通的操作，正是这种纪律把嵌入式工程变成了一门产品业务，而非劳动密集型业务。

在规模化之前，领导者真正应该审视什么

如果你在评估一家供应商的 FDE 项目，或者考虑建立自己的 FDE 项目，职位名称说明不了任何问题。以下这些问题才有价值：

  • 它要解决的问题对客户而言是真正的前五优先级，还是可有可无？ 如果是后者，再多的嵌入式工程人才也无法推动它穿过客户自己的组织。
  • 交易结构是否为此而设计，还是只是一个名字更花哨的标准支持合同？ 访问级别、响应 SLA 以及由谁对结果负责，都必须是真实的承诺，而不是叠加在现有服务产品之上的营销话术。
  • 从单个客户的解决方案到可复用的产品功能，是否存在一条路径，还是每个客户都从零开始？ 如果没有任何东西能被泛化，那你运营的其实是一门服务业务，只不过恰好把员工称为工程师而已。
  • 你自己的平台是否复杂到需要这样做，还是复杂性来自别处（集成债务、职责不清，或是披着技术外衣的流程问题）？前沿部署工程成本高昂。当问题真实且值得解决时，这是值得的。但如果问题本来就不在工程层面，用它来粉饰问题就是一种昂贵的方式。

我曾见过 Salesforce、Agentforce 和 MuleSoft 的前沿部署工程师在同一客户账户上协作，实践中这一规律依然成立：当上述问题的答案是肯定时，工程投入会累积成客户愿意保留、供应商也能以其他形式再次出售的东西。当答案是否定时，那不过是一个品牌包装更好的顾问，客户最终会察觉。

接下来该检查什么

如果你的公司正在评估供应商的前沿部署项目，或者正在构建自己的项目，请把上述四个问题对照实际的合同和组织架构图来检验，而不是对照宣传演示文稿。这两份文件之间的差距，通常就是真相所在。

参考资料

  • Bob McGrew（OpenAI 前首席研究官；Palantir 早期高管；现服役于美国陆军预备役技术顾问部队），关于 Palantir 前沿部署工程模式的起源与运作机制，本文的背景资料。
  • LinkedIn 上的配套文章，涵盖 2026 年 Microsoft、Amazon、OpenAI 和 Anthropic 全行业范围的前沿部署工程建设：https://www.linkedin.com/pulse/microsoft-amazon-openai-anthropic-just-committed-9-devinarayanan-xnbjc
  • CNBC，Microsoft 投入 25 亿美元和 6,000 名员工组建 AI 实施部门：https://www.cnbc.com/2026/07/02/microsoft-commits-2point5-billion-6000-employees-ai-implementation-unit.html
  • TechCrunch，Microsoft 以 25 亿美元投入推出自己的 AI 部署公司：https://techcrunch.com/2026/07/02/microsoft-launches-its-own-ai-deployment-company-with-2-5-billion-commitment/
  • GeekWire，Microsoft 推出 25 亿美元的“前沿公司”，将 AI 工程师嵌入客户内部：https://www.geekwire.com/2026/microsoft-announces-2-5b-frontier-company-to-embed-ai-engineers-inside-customers/
  • Salesforce Ben，Salesforce 前沿部署工程师做什么以及如何成为其中一员：https://www.salesforceben.com/what-salesforce-forward-deployed-engineers-do-and-how-you-can-become-one/