AI创业公司的前向部署工程师手册——Bob McGrew访谈

摘要
Bob McGrew曾是PayPal早期工程师、Palantir早期高管,后担任OpenAI首席研究官(Chief Research Officer),领导了ChatGPT、GPT-4和o1推理模型的开发。在本期节目中,Bob深入解析了"前向部署工程师"(Forward Deployed Engineer, FDE)模式——这一由Palantir发明的商业模式正在成为AI代理(AI Agent)创业公司的主流组织方式。Bob从Palantir为情报机构构建软件的经历出发,详细阐述了FDE模式的起源、Echo团队与Delta团队的分工、产品团队如何将客户现场的"碎石路"变为"铺装高速公路"、以及FDE模式与传统SaaS产品市场匹配(Product-Market Fit)策略的本质区别。他还讨论了FDE模式的定价逻辑(基于结果而非座位数)、组织纪律的重要性、为何AI代理公司特别需要FDE模式,以及他加入美国陆军预备役第201分遣队(Detachment 2011)后如何将FDE经验应用于军队技术转型。
FDE模式的定义与核心逻辑
前向部署工程师(Forward Deployed Engineer, FDE)是驻扎在客户现场的技术人员,其职责是填补产品能力与客户需求之间的差距。当一个新客户提出产品从未解决过的问题时,FDE相信通过一定量的工作可以解决该问题,并与产品团队协作,将现有产品调整为能够在客户现场真正交付结果的方案。
Bob强调,FDE模式与传统销售主导的产品发现(Sales-led Product Discovery)有本质区别:销售主导的方式是从外部与客户对话,而FDE是从内部解决问题。FDE不仅负责最初的实施部署,还承担客户关系管理,更重要的是,他们承担着产品发现(Product Discovery)的核心职能。
Palantir的起源:为间谍构建软件
Bob讲述了Palantir创立初期的故事。公司最初的目标是为情报界(Intelligence Community)——简而言之,为间谍——构建软件。但创始人面临一个根本性难题:他们不认识任何间谍,即便找到间谍,对方也不会告诉你他们具体做什么。
Palantir采取了在当时非常不寻常的方法:先构建一个演示(Demo),然后带给情报界的潜在客户。联合创始人Stephen Cohen亲自展示演示,客户说"这太糟糕了,跟我们做的事情毫无关系",Stephen便追问"那你们希望怎么做?"然后认真记录每一条反馈。这听起来像是标准创业建议——做出人们想要的东西,走出办公室与客户对话——但Palantir早在2000年代中期就这样做了。Bob笑称:"我花了多年掌握这项技术,Paul Graham一条推文就分享给了所有人。"
从产品市场匹配到FDE策略的转折
传统创业理论认为,早期应该做不可扩展的事(Do Things That Don't Scale)——深入客户、理解需求、发现产品市场匹配(Product-Market Fit),然后一旦找到匹配,就采取完全不同的策略:拥抱与客户的距离,专注于规模化,把所有客户一视同仁。正如《跨越鸿沟》(Crossing the Chasm)等经典著作所描述的。
Bob坦言,如果你的业务能够这样运作,那是极好的——不要做FDE模式。能够简单规模化、对所有客户一视同仁,是一种难得的天赋。但在Palantir,这行不通。
Shyam Sankar——Palantir极早期员工、现任总裁兼CTO——真正发明了FDE策略。核心发现是:每个客户需要的产品都略有不同。当Palantir从一个客户转向下一个客户时,发现他们的需求存在差异。解决方案不是为每个客户构建独立产品,也不是忽略差异只做完全正确的功能,而是构建一个平台(Platform)而非产品——一个在每个站点都可以大量定制的平台。而要实现这一点,就需要把人派到客户现场去理解用户需求并构建定制化方案。
Shyam的关键洞察是:可以将这种传统上被视为需要最小化的"服务"翻转过来,使其成为价值创造的核心——让FDE承担产品发现的角色。FDE在客户现场构建一条"碎石路"(Gravel Road),然后产品工程团队的责任是观察这条碎石路,找出如何将其推广到接下来5到10个客户,然后将碎石路变为"铺装高速公路"(Paved Superhighway)。
Echo团队与Delta团队:FDE的组织架构
Bob详细说明了Palantir FDE团队的核心结构——两个关键角色:
Echo团队:嵌入式分析师
Echo团队成员被派驻到客户现场,与用户直接对话,判断哪种演示或用例对该站点的用户最有意义,识别可解决的核心问题。他们同时担任客户关系管理者(Account Manager),负责维护客户现场的关系。
Echo团队的典型画像来自目标领域——可能是前陆军军官,或医疗行业的资深从业者。他们拥有深厚的领域知识,但有一个关键要求:他们必须是"叛逆者"(Rebels),Shyam更愿意称之为"异端"(Heretics)。他们必须理解现状,并认识到现状是不够好的、行不通的。因为如果他们认为现有方式就很好,就永远无法找到新软件必须实现的3倍或10倍提升。如果不能实现这种飞跃,就根本没有理由经历FDE模式的所有艰辛。
Delta团队:前向部署工程师
Delta团队成员是软件工程师,通常极其擅长快速编写代码——用Bob的话说,"吃下大量的痛"(Eating a lot of pain)。他们将Echo团队识别的创意变为现实,构建可运行的原型或解决方案,并在客户现场部署。整个过程在非常短的时间内完成——团队带着想法进入,几个月内向领导层展示进展,如果演示成功,就在全组织范围内部署。
Delta团队的正确画像不是追求代码完美的工匠(Craftsman)——那种确保抽象完全正确、代码可维护十二年的工程师不适合这个角色。FDE需要的是能够快速产出"粗糙但可用"代码的人,能够在紧迫的时间线上交付结果。第一版代码可能需要推倒重来,由同一个人或其他人写第二版——这才是关键能力。
Bob指出,这实际上非常像创业创始团队的技能组合,这也是为什么Palantir走出了如此多的创业公司创始人——FDE训练本质上就是创业创始人训练。
产品团队的角色:将碎石路变为高速公路
产品团队在FDE模式中扮演着独特角色。与构建高度垂直化产品(如Airbnb)不同,Palantir的产品团队核心职责是持有产品愿景(Product Vision)——当看到客户现场的新问题时,思考的是"适用于接下来10个客户的可泛化版本是什么"。
一个经典失败模式是:FDE为客户实施了某个方案,团队直接说"很好,就这样做",然后把它原封不动地放入产品——结果构建了过度针对单一客户的东西。真正的能力在于猜测正确的、总是比客户描述的更具一般性的问题。
Palantir本体论(Ontology)的诞生
最基本的例子是Palantir著名的本体论。最初与美国政府合作时,团队考虑是否需要为"人"建一个数据库表、为"钱"建另一个表——这在现在看来显而易见,但如果走那条路,部署到多个客户时数据库就完全说不通。解决方案是将思维提升到更高的抽象层:不定义具体的对象类型,而是允许FDE团队在每个客户站点定义本体论——包含对象(Objects)、属性(Properties)、媒体(Media)和对象之间的链接(Links)。
Bob回忆,Palantir很长时间没有招聘产品经理。当他终于开始面试来自其他公司的优秀产品经理时,发现他们很难在Palantir所需的抽象层级上思考——他们会描述某个客户的特定流程,但这正是错误的做法。产品经理需要上升一层,思考"在本体论的上下文中,这如何工作?如何修改本体论,使这个定制功能跨客户生效?"
内部张力与激励对齐
FDE与产品团队之间始终存在张力,但这更多是激励(Incentives)差异而非技能差异。在客户现场,FDE面对一个非常特定的问题,采取最简单的方法解决完全合理——这就是碎石路应有的样子。而铺装的高速公路则需要服务多个客户,形态往往不同。
Bob分享了一个关键实践:当FDE在一个客户发现了新功能需求时,他们会将其带回帕洛阿尔托的产品团队,讨论正确的泛化版本。FDE参与这些讨论至关重要。然后,团队会识别其他几个可能受益的客户,将那些站点的FDE也纳入设计过程。当三个不同但相似的工作流摆在面前时,就不再是"该泛化还是该特化"的争论,而是所有人都在解决同一个问题——激励自然对齐。
FDE模式不是咨询:商业模式的关键区分
Bob承认,外界——尤其是2015年前后——常有两个批评:一是Palantir是邪恶的,二是Palantir本质上是咨询公司、永远无法规模化、不是一个好的软件生意。团队花了大量时间评估这一判断是否正确。
从商业模式角度,FDE模式的关键特征是:进入一个新客户时,早期可能实际上在亏损。但在客户现场的时间越长:第一,产品因产品发现而更贴合客户需求,不再需要大量人员驻扎;第二,你应该"赢得"(Earn the Right)接触客户更重要问题的资格——正如Shyam所言。因此,每单位交付价值的成本应该下降,利润率从负变正——可能需要一年,也可能需要数年。从这一角度看,你交付的是真实、可重复的价值。
另一个更隐蔽的失败模式是:FDE构建的是客户要求的产品,而非客户真正需要的产品。客户是一个组织——你对话的可能只是CIO或某个中层赞助人,而非CEO。他们往往希望你解决对他们来说容易的问题,而非真正改善业务的高影响力问题。这就是为什么必须解决CEO前五优先级的问题——否则他们没有足够的精力坚持走完FDE部署这条更艰难的路。
为何AI代理公司特别需要FDE模式
Bob坦言,FDE模式在AI代理领域的大规模采用令他惊讶。他给考虑尝试FDE策略的人的第一、第二、第三条建议都是"不要在家尝试"——如果你能避免,就不要做,很可能你最终只是在做服务。只有在尝试了其他所有方法都不行时,FDE模式才可能成为你的护城河。
AI代理公司需要FDE模式的核心原因是:
- 市场的高度异质性:正如Palantir的市场——反扩散(Counter-proliferation)工作流与反恐(Counterterrorism)工作流截然不同,AI代理面对的也不是一个统一市场,而是需要逐一攻克的细分领域。在每个细分领域内,可以找到产品市场匹配并低定制化部署,但细分领域之间需要开发新的技术。
- 没有现有产品类别:与替代现有账单支付系统的SaaS产品不同,AI代理是一个全新的市场类别——没有现有产品可以替代。没人知道AI代理到底是什么——可能五年后回头看,"AI代理"甚至不是一个统一的类别,而是许多不同的东西。这种巨大的产品发现需求,只能从企业内部完成。
Bob总结:FDE模式本质上是"规模化地做不可扩展的事"(Doing Things That Don't Scale at Scale)。
定价策略:基于结果而非使用量
在SaaS模式下,定价基于使用量、订阅或座位数,追求简单、可重复、跨客户一致的合同,并且可以接受小合同——因为边际部署成本极低。
但在FDE模式下,你会被推向越来越大的合同。合同因复杂性而更灵活,定价基于交付的结果(Outcome)。Shyam的原则是:你卖的不是软件安装,而是你解决了一个问题。
Bob建议,早期创业公司应该承担全部风险——告诉客户"我们相信自己的执行力,如果有效你才付费"。这种不对称性在于:大企业因为经历过太多失败项目而不相信自己能做成什么,也不相信创业公司能做成——而创业公司知道自己能执行。如果创业公司不确定自己能执行,那本就不应该进入这个行业。
唯一可能出错的地方是:如果需要部署到企业内部(On-premise),就必须与IT团队对抗。更广泛地说,需要搞清楚组织内部谁需要说"是"——这些人不像创业者那样思考,也不与终端用户对齐。这就回到了为什么必须解决CEO前五优先级的问题——需要从高层获得授权和运营自由度。
衡量FDE模式成功的两个指标
- 交付结果的价值(Value of Outcome):这是真正的核心指标。你是否在为客户交付越来越有价值的结果?你是否具备将其货币化和定价的能力?也许暂时没有,但只要交付的价值在增长,方向就是对的。
- 产品杠杆(Product Leverage):FDE在客户现场交付结果时,从产品中获得的杠杆是否在增长?第一个客户部署需要大量工作,向第二个客户交付相同结果应该容易得多,且应该越来越容易。如果你正确抽象了核心概念,即使做不同的用例,也应该有更多产品杠杆。
Bob指出,这两个指标与产品市场匹配策略完全相反:在产品市场匹配策略中,你要减少每个客户的工作量、降低成本、保持合同规模不变;在FDE策略中,你要推动合同规模上升、做越来越有价值的工作,而每个客户的定制化程度可以保持不变。
演示驱动开发(Demo-Driven Development)
在传统SaaS中,演示驱动开发常被工程师看不起,但在FDE模式下它极其有效。Palantir早期只有一个演示——一个阻止恐怖阴谋的工作流。每集成一个新功能(如直方图、地图),团队都要思考"这个新功能如何帮助分析人员完成这个演示中的任务?"这让团队从"我能构建什么能力"转向"客户想要什么、我是否在解决他们的痛点"。
一个好的演示能让客户看到产品后产生渴望——他们想伸手抓住它、带入自己的生活。而且,反复做演示迫使团队思考功能之间的衔接——如果要从这个功能跳到那个功能,路径必须非常直观。这些产品痛点通常只在真正部署后才显现,而演示能提前暴露它们。
加入美国陆军预备役
Bob近期加入了美国陆军预备役第201分遣队(Detachment 2011),作为中校(Lieutenant Colonel)为军队提供技术建议。他们不是普通平民顾问,而是宣誓入伍的军官——参加了直接委任课程(Direct Commissioning Course),在军事学院接受培训(经常在东部时间凌晨5点以避免与日常工作冲突),并通过了陆军体能测试(Bob为此训练了9个月)。
这使得他们与被建议的组织利益一致——有切肤之痛(Skin in the Game)。陆军领导层——陆军参谋长Randy George将军、陆军部长Driscoll——已经明确了陆军转型计划,知道需要从伊拉克和阿富汗的战争模式转向乌克兰式的战争模式或大规模太平洋作战,需要更快地变革。他们给了分遣队成员各自的领域和自由,可以绕过常规流程、直接与一线军官合作解决问题,或向领导层升级。
Bob认为,这在许多方面很像在军队上运行FDE策略——看到领导层的前五优先级、取得进展,同时也帮助弥合领导层愿景与20年执行惯性之间的鸿沟。
创业者的最佳机会
Bob认为,当前最大的创业机会恰好在于AI能力(Capabilities)与实际采用(Adoption)之间的巨大鸿沟。从GPT-4o(2024年4月)到o3(2025年4月),能力进步极快,且将继续加速。但令人震惊的是,采用速度远未跟上能力的增长——未来5年,能力将持续飞速提升,而世界将感觉越来越平庸(Banal),就像坐在Waymo里却只觉得"哦,堵车了"。
在2018年,人们讨论AGI时想象它会在某个周末"活过来"并接管世界。但人们忽略的是:AI需要被采用——这不会自动发生,需要人类的智慧、探索和承受大量痛苦。正如FDE填补产品与客户需求之间的差距,如今有巨大的机会填补AI能力与客户实际采用之间的差距。
视频链接:https://www.youtube.com/watch?v=Zyw-YA0k3xo