最近硅谷在發生一件很有意思的事：很多的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模式的核心邏輯跟這些相反 ： 以規?；姆绞剑プ瞿切┛雌饋頍o法規?；氖虑?。

更進一步，FDE是一位技術人員，駐扎在客戶現場，填補產品功能與客戶需求之間的差距。

關鍵是，FDE交付的不是軟件或服務，而是有價值的結果（outcome）。

Palantir是怎么發明FDE的？

Palantir創立時要給情報部門做軟件，但他們連情報工作人員都不認識，更別說了解對方的需求了。即使找到情報人員問： 你的工作是什么，對方也不可能告訴你。

這倒逼他們走了一條非常規路線。

創始人之一Stefan Cohen會拿著demo去客戶那里演示。

客戶說：這產品太糟糕了，和我們做的事完全沒關系。

Cohen繼續問： 那你們希望它有什么不同？

客戶提需求，Cohen記下來，回去改，再演示。

按傳統觀念，這些高度定制化的工作都屬于服務，在PMF框架里應該盡量避免。

但Palantir早期成員、現任CTO Shyam Sankar把這套邏輯倒過來了。他的做法是：讓FDE充當產品探索的過程。

FDE帶著現有產品進場，填補產品能力與實際需求之間的gap，把路線先鋪出來?？偛康漠a品團隊再把這些現場做法抽象、泛化，修成能服務接下來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模式提供了一種新的思路，以規?；姆绞?，去做那些看起來無法規?；氖虑椤?/p>

本文轉載自??探索AGI??，作者：獼猴桃