超100家YC疯抢的 FDE 模式，正成为AI Agent的 PMF 范式！

最近硅谷在发生一件很有意思的事：很多的VC都在招聘一个叫 FDE（Forward Deployed Engineer）的岗位。

这是一个诞生于情报部门、看起来像咨询业务的模式，突然成了AI Agent创业公司的标配。

前OpenAI首席研究官、Palantir第二位工程师 Bob McGrew 透露，过去一年，他聊了很多AI初创公司，几乎所有创始人都只关心一件事，Palantir 的 FDE策略到底是怎么运作的，为什么能孵化数百家创业公司，10多家独角兽。

我找到了一个 Bob McGrew 的访谈，可以让我们对 FDE 有很好的认知。

传统PMF失效了，AI Agent需要新玩法

先说结论：AI Agent没法像传统SaaS那样靠标准化产品规模化。

Bob McGrew 的判断是，AI Agent是一个全新的市场类别，根本没有现成的产品。如果你在做标准SaaS产品，比如用一种新的支付工具取代旧工具，每个人都明白这个市场是什么。但AI Agent实际上可能意味着很多不同的事情，我们还在摸索阶段。

这就导致了一个问题：传统的 找到PMF → 规模化复制 → 对所有客户一视同仁 的路径走不通了。

FDE模式的核心逻辑跟这些相反 ： 以规模化的方式，去做那些看起来无法规模化的事情。

更进一步，FDE是一位技术人员，驻扎在客户现场，填补产品功能与客户需求之间的差距。

关键是，FDE交付的不是软件或服务，而是有价值的结果（outcome）。

Palantir是怎么发明FDE的？

Palantir创立时要给情报部门做软件，但他们连情报工作人员都不认识，更别说了解对方的需求了。即使找到情报人员问： 你的工作是什么，对方也不可能告诉你。

这倒逼他们走了一条非常规路线。

创始人之一Stefan Cohen会拿着demo去客户那里演示。

客户说：这产品太糟糕了，和我们做的事完全没关系。

Cohen继续问： 那你们希望它有什么不同？

客户提需求，Cohen记下来，回去改，再演示。

按传统观念，这些高度定制化的工作都属于服务，在PMF框架里应该尽量避免。

但Palantir早期成员、现任CTO Shyam Sankar把这套逻辑倒过来了。他的做法是：让FDE充当产品探索的过程。

FDE带着现有产品进场，填补产品能力与实际需求之间的gap，把路线先铺出来。总部的产品团队再把这些现场做法抽象、泛化，修成能服务接下来5-10个客户的解决方案。

FDE团队长什么样？

Palantir的FDE团队有两个关键角色：Echo团队和Delta团队。

Echo团队实际上是embedded analysts，他们去客户现场，与用户交谈，找出什么样的demo或use case对客户真正有价值。同时他们也是客户经理，负责管理客户关系。

Echo团队的理想人选是领域专家，这些人不仅了解现有做事方式，还能看到哪里不够好。如果看不到问题，就永远想不出新软件能带来的阶跃式变化。

Delta团队是部署工程师，本质上是软件工程师。但他们不是那种追求代码完美、希望软件能维护十几年的工匠型人才。Delta团队需要的是能在规定时间内快速交付原型的人，即便代码粗糙也没关系。

这里有个有意思的现象，Echo和Delta的人才画像听起来就像一个创业团队。

事实上，Palantir孵化出了350+家的创业公司，其中至少十多家达到独角兽级别，包括估值305亿美元的Anduril、估值25亿美元的Peregrine，以及ElevenLabs、Sourcegraph等明星公司。

Bob McGrew说的很直接：FDE培训就是成为创业公司创始人的培训。

FDE不是咨询，通用产品同样重要

很多人会质疑：这不就是包装后的咨询业务吗？

客观来说，FDE确实有这个风险。

2015年人们谈论Palantir时，主要就两个评价：一是和情报部门合作的公司，二是永远无法规模化的咨询公司。

但数据证明了。Palantir的商业模式呈现一个清晰的趋势：新客户部署初期可能亏钱，但随着时间推移，产品越来越适配客户需求，交付成果的单位价值成本持续下降，利润率从负转正。

关键在于产品团队的作用。

Palantir有两个核心团队：FDE团队和产品管理团队。产品团队的角色是把握产品愿景，思考在客户现场看到的新问题，什么样的通用形态可以应用于接下来10个客户。

最经典的案例是Palantir Ontology的发明。

最初给情报机构做系统时，本能做法是给 人 建一张表，给 资金 建一张表。但很快发现这套逻辑无法跨客户通用。

于是他们把抽象层级拉高，底层只保留对象 、属性 、媒体 和 链接 这些极其通用的元素。具体语义由Ontology按每个客户的语境去定义。

Bob McGrew面试过不少在其他公司非常优秀的产品经理，但让他们在这种抽象层级上思考并不容易。很多人会直接落到 给这个客户设计一条具体流程，但在Palantir这是错的。需要在本体层思考，如何让某个专用功能跨客户复用。

图片

FDE vs 传统SaaS：KPI完全不同

FDE模式和传统SaaS模式的核心区别体现在KPI上。

传统PMF策略中，团队希望为每个客户做的工作越来越少，降低成本，保持合同规模不变。

但FDE策略的预期是提高合同规模。因为你在为客户做越来越有价值的工作，所以可以保持每个客户的定制化程度不变。

这导致了定价模式的根本性改变。SaaS时代按使用量、订阅或席位定价，FDE模式下销售的是成果。YC公司Kastle为银行提供AI语音agent处理抵押贷款，衡量指标就是成功处理的电话数量。Happy Robot做物流AI agent，和DHL合作，也是类似的逻辑。

Bob McGrew给出了两个关键的衡量指标：

第一，交付成果的价值。如果能为客户交付越来越有价值的成果，就做对了。

第二，产品杠杆。你是否正在获得越来越多的产品杠杆来放大那个成果，让FDE能用产品交付更多价值，而不是每次都要拉三个工程师进来。

为什么是现在？

Bob McGrew给创业者的判断很明确，当下存在一个巨大的机会窗口。

AI能力提升实际上非常快。从2024年4月GPT-4o到2025年4月o3，进步速度惊人。但真正令人震惊的是，AI采用速度远没有能力进展快。

极可能未来5年AI能力飞速前进，但我们在现实世界却感觉越来越平庸。就像坐在Waymo里不会想 无人驾驶实现了，而是在想 交通真堵，真慢。

FDE的机会在于填补AI能力实际上能做什么和客户能够采纳什么之间的gap。AI被大规模应用需要方法论，需要人类的创造力、探索，以及应对大量问题。

Bob McGrew给了一个类比：OpenAI像是本部产品团队，而创业公司们是FDE，在外面想办法让OpenAI研发出来的成果被真正采纳。

最后

简单几个核心要点：

• 如果你的市场能通过传统方式规模化，就不要尝试FDE。只有当不做FDE就一定会失败时，它才是你的护城河。
• 如果解决的不是客户领导层的核心痛点，就没有足够支持去突破组织内的阻力。
• 合同规模会越来越大，这是FDE模式的自然结果，和传统SaaS的规模化逻辑完全不同。
• 通用产品平台同样重要，FDE不等于咨询，底层必须有强大的产品杠杆，否则就是在做无法规模化的服务。
• 这是一个学习型公司的游戏，FDE模式本质上是在做产品探索，需要持续学习、快速迭代的组织文化。

AI Agent还在产品探索的早期阶段，没有现成的playbook。FDE模式提供了一种新的思路，以规模化的方式，去做那些看起来无法规模化的事情。

本文转载自​​探索AGI​​，作者：猕猴桃