一张关键画面对应一段完整解说，按原视频时间推进。
Bob McGrew： AI Agent 没有一个可以直接替代的既有产品。因此，FDE 模式之所以正在兴起，我认为是因为还有大量产品发现工作要做。公司希望不断提高合同规模，也就是为当前客户、以及未来客户做越来越有价值的工作。FDE 模式本质上是在规模化地做那些通常被认为“无法规模化”的事情。
镜头为演播室圆桌全景，四位参与者围桌而坐；这段是节目开场前置引语，未出现图表或其他视觉证据。
Harj Taggar： 欢迎回到《Lightcone》。Gary 今天身体不适，无法参加，但我们很高兴请到 Bob McGrew。Bob 曾是 PayPal 的早期工程师、Palantir 的早期高管，最近担任 OpenAI 首席研究官，领导过 ChatGPT、GPT-4 和 o1 推理模型的开发。他现在正在探索 AI 的未来，并将在节目中谈到自己在美国陆军预备役的新角色。
Jared Friedman： Bob，谢谢你来。今天我特别想和你谈 Forward Deployed Engineer，也就是 FDE 模式。这个话题在我们的工作和生活中不断出现，尤其是我们一直讨论的 AI Agent 公司。你正好在这个模式诞生时身处其中，所以是解释它的最佳人选。你之前讲过一个故事：你参加 YC 组织的 AI 会议时，以为创业者会来问你 ChatGPT 是怎么做出来的，结果他们最关心的却是 Palantir 的 FDE 模式。
Bob McGrew： 确实不只是那一次会议。过去一年我在给创业公司提供建议时，发现很多公司几乎只想学习 FDE 策略。
Jared Friedman： 这已经成为一个非常受关注、也很及时的话题。现在它似乎成了 AI Agent 创业公司组织自己的主流方式。YC 招聘板上有一百多家公司在招聘 Forward Deployed Engineer，三年前几乎还没有这个职位。那先从基本问题开始：FDE 到底是什么，为什么现在相关？
代表帧为 Jared 的人物近景，演播室背景稳定；本段主要是嘉宾介绍和问题铺垫，画面没有独立的资料图。
Bob McGrew： FDE 通常是一个技术背景的工程师，驻在客户现场，填补“产品能做什么”和“客户需要什么”之间的差距。
Jared Friedman： 实际工作是怎样展开的？
Bob McGrew： 你带着现有产品进入一个新客户现场。客户想解决的问题，可能是你从未解决过的，但你相信通过一点、甚至大量工作，能够为这个客户解决，并交付对它非常有价值的结果。于是 FDE 在产品团队的帮助下，拿现有产品去实现这个结果，构建具体用例，并以真正适合客户工作的方式交付软件。
Jared Friedman： 那我们回到 Palantir 的起点。你当时就在场，而这种如今正在硅谷快速扩散的模式也是在那里被发明出来的。它最初是怎么发生的？
画面从 Bob 的人物近景转向 Jared 的提问镜头，仍是固定的 Lightcone 演播室布置；镜头变化对应定义和历史追问的交接。
Bob McGrew： Palantir 最初的目标，是为情报机构，具体说是为间谍，构建软件。难点在于，我不认识任何间谍，你可能也不认识；就算找到一个间谍去问他究竟在做什么，他通常也不会告诉你。因此，我们采取了当时很不寻常的方法：先做一个 Demo，拿给情报社区的潜在客户看。
Palantir 联合创始人 Stephen Cohen 曾经把 Demo 给客户看，问“你觉得怎么样？”客户回答说，这很糟糕，完全和他们的工作无关。Stephen 就继续问：“你希望它怎样不同？”客户提出一个个修改，他就坐在那里把所有修改记下来。
这听起来像今天给创业者的标准建议：做用户需要的东西，走出办公室去找客户。我们在 2000 年代中期已经这么做了。通常的产品市场匹配路径是早期深入客户、发现 PMF，然后反过来与客户拉开距离，专注销售和规模化，尽可能让所有客户都一样。如果这种方法对你的业务有效，那是很好的礼物，就应该继续规模化，不必采用 FDE。
但 Palantir 的客户在每个地方都需要略有不同的产品。我们没有为每个客户分别做一套产品，而是做了更像平台的东西，让每个现场都能定制。历史上这常被当作应该尽量减少的服务工作；Sham Sankar 发现，可以把它反过来，让 FDE 做产品发现：FDE 到现场，拿现有产品填补产品与用户需求之间的缺口，先修出一条“土路”。产品和工程团队再观察这条土路如何推广到下一个五个、十个客户，把它变成铺好的高速公路。
Harj Taggar： 销售人员以前也会去和客户交流、把信息带回工程团队。Palantir 为什么让工程师来做这件事？政府和国防业务不是更应该找有经验的销售吗？
Jared Friedman： 就像一位在国防部工作二十年的 Don Draper，穿西装请将军吃牛排，但你们没有这么做，对吧？
代表帧为圆桌全景，四位参与者都在场；这段没有展示 Palantir 界面，画面主要用于保留提问者和回答者的空间关系。
Bob McGrew： 我们早期和很多这类人谈过，他们会问：既然可以为大型国防承包商工作，为什么要和一家硅谷公司合作？即使某些人看起来可能适合这个角色，也很明显他们无法融入我们的文化，实际上不会成功。我们尝试过类似做法，但几乎从未奏效。
销售驱动的产品发现，是从外部和客户交谈；FDE 驱动的产品发现，则是在客户内部解决问题。传统实施往往从一个接近现有产品的东西开始，但你真正要解决的应该是公司领导已经识别出的关键问题。如果不是 CEO 排名前五的优先事项，项目很可能无法推进，因为客户没有足够精力坚持走完构建一块新产品、并让它真正适合自己的艰难路径。
解决第一个问题后，FDE 还能在企业内部发现其他关键问题，有些问题的价值可能远高于最初目标，而且一开始未必显得你的公司能解决。等你身处现场，通过产品洞察发现确实可以解决，就可以继续解决这些问题。这使模式从“如何把同一个东西卖给每个客户”切换为“如何先落地，再扩展”。
代表帧为 Bob 的单人近景，麦克风和演播室背景清晰可见；本段没有屏幕或图表，视觉重点是 Bob 的连续回答。
Jared Friedman： 如果给创业者一份 Palantir FDE 模式的说明书，团队是怎样组织的？
Bob McGrew： 具体迭代很多，但持续不变的是两个关键角色：Echo team 和 Delta team。Echo 是嵌入式分析师。他们去客户现场和用户交谈，找出对这个现场真正有意义的 Demo 或用例，判断最值得解决的问题，同时还承担客户关系管理。
Delta，也就是部署工程师，本质上是软件工程师。他们通常非常擅长快速写代码，也要能够承受大量痛苦。他们把 Echo 找到的想法带进现实，构建一个真正能工作的原型和解决方案，再部署给客户。整个过程要在很短时间内完成：先带着一个想法进入现场，几个月后向领导层展示进展，如果展示顺利，就在整个组织范围内部署。
Harj Taggar： 这两种角色需要完全不同的人。怎样找到合适的人？他们不仅要像工程师，Echo 也不能只是客户经理，还需要更强的技术能力。
Bob McGrew： Echo 的典型画像是来自目标领域的人，比如前军官或深耕医疗行业的人。他们有领域知识，但更重要的是要成为“叛逆者”，Sham 可能会称他们为异端：了解现状，同时意识到现状不够好。如果不能在组织里带来 3 倍或 10 倍的变化，就没有理由投入这套方法。
Delta 则要擅长原型设计。错误的画像是那种最在意抽象是否完美、希望代码可以维护十几年的工匠，因为这不是这个岗位的任务。需要的是能迅速理解问题、写出粗糙但能交付结果的代码的人。第一版可能要扔掉，重新写第二版，甚至由另一个人重写；关键是按时间表把结果交付出来。
代表帧为 Bob 与一位主持人的双人镜头，桌面上的麦克风和圆桌可见；没有演示 Echo/Delta 图表，角色结构由对话本身承载。
Jared Friedman： 这听起来很像创始团队。你会不会招聘以前的创业者，把他们培养成 Echo 或 Delta？还是反过来更多？Palantir 已经孵化出大量创业公司，FDE 训练似乎正好涵盖了创业者需要的技能。
Bob McGrew： 当年我们开始做这件事时，并没有大量创业者可以招聘；现在可能反过来了。但你说得对：每个客户现场的新环境，都有点像当一个创业者，只是 FDE 还拥有一块强大的产品杠杆，让工作更容易。这是很好的训练，也解释了为什么 Palantir 会产生那么多创业者。
Jared Friedman： 常见的批评是，FDE 只是披着漂亮营销语言的咨询。为什么这不对？
Bob McGrew： 我不想轻率地说它不对，因为这种风险确实存在。早在 2015 年，人们谈到 Palantir 时，一方面说它邪恶，另一方面说它是永远无法规模化的咨询业务，而不是软件公司。我们花了很多时间判断这种描述是否正确。
代表帧为 Bob 的中近景，随后切到主持人提问；演播室没有外部资料画面，视觉作用是显示问答交接。
Bob McGrew： 新客户部署的早期阶段可能在亏钱。但随着时间推移，产品通过产品发现越来越适合客户，你不再需要一大队人在现场理解客户、铺设那条“土路”。同时，你也应该逐渐获得接触客户更重要问题的资格。因此，交付结果的单位成本应该下降，利润率可能先是负的，过了一年或几年后变成正的。这样看，交付的就是可重复的真实价值。
Harj Taggar： 让这套模式成立并降低成本的关键，是产品团队。产品团队怎样和 FDE 团队协作？
Bob McGrew： 工程方面其实很有意思。Palantir 早期和后期都在做创始人驱动的发现、构建新产品，这对工程师来说很有吸引力。真正不同的是 FDE 团队和产品管理团队。产品不应该是高度垂直化、让数百万人走同一条流程的东西，而是产品团队要守住产品愿景：看到一个客户问题时，要想清楚它可推广到接下来十个客户的版本是什么。
一个典型失败是，FDE 为一个客户实现了某种做法，就直接把它放进产品，最后得到的是对单一客户过度专门化的东西。产品团队要从现场问题中猜出更一般化的问题。接下来要判断：这个东西只适用于一个垂直领域，还是能够推广？
Harj Taggar： 你能用产品和行业的例子说明怎样做这个判断吗？
代表帧为 Bob 和女性主持人的双人镜头，画面没有产品界面；本段的核心信息是从现场原型到可推广产品的抽象过程。
Bob McGrew： 最基本的例子就是 Palantir Ontology 的发明。最初和美国政府、情报部门合作时，我们可能会想：给人建一张数据库表，给钱建另一张表，再给其他东西建表。但如果这样做并部署给多个客户，数据库很快就失去意义。
正确的变化是把抽象层次提高：不要把特定对象类型写死，而是让 FDE 团队按客户定义对象。Palantir 政府产品的底层数据库非常通用，只包含对象、属性、媒体和对象之间的链接；Ontology 再编码每个客户的专门信息，例如这是一个人、这是一艘船、这是一条资金流。
不能只用一个客户的描述来设计系统，而要向上抽象：某个操作适用于拥有某种属性的对象。人可能有这个属性，船也可能有，但付款就未必有。Palantir 很长时间没有产品经理。后来招聘产品经理时，很多其他公司很优秀的产品经理仍然难以在这个抽象层次思考，他们会直接描述某个客户的流程，而不是思考怎样修改 Ontology 让这类特例跨客户工作。
Harj Taggar： 这会不会造成文化冲突？FDE 像异端一样只想为客户做最好的专门解决方案，而内部产品团队又需要能抽象、写出可维护代码的人。
Bob McGrew： 冲突一直存在，但不只是技能差异，更是环境和激励差异。在客户现场，面对一个非常具体的问题，FDE 采取最简单的办法是对的，那就是“土路”。铺好的路必须同时服务这家客户以及后面一批客户，所以它看起来不同。不能让产品团队闭门思考后直接构建，因为他们一定会构建错。通常做法是：先由 FDE 在一个客户处做出东西，再和产品团队一起找出一般化版本，再邀请其他客户的 FDE 参与设计，确保新功能既适用于原客户，也适用于其他客户。
当大家同时看到三个略有不同、但本质相同的工作流，关于“应该通用还是应该专门”的争论就会变成共同解决一个问题。要避免模式退化成咨询，确实需要很强的组织纪律，不能只做客户口头要求的产品，而要做对客户真正有价值的东西。
代表帧为黑色衬衫主持人的单人镜头，随后回到圆桌；视频没有展示 Ontology 图示，文字中保留对象、属性、媒体、链接等结构信息。
Bob McGrew： 成为咨询公司的更早期失败，是在现场构建客户要求的产品，而不是对客户真正有价值的产品。你面对的可能只是 CIO，或离 CEO 几层的一个赞助人；他们常常更愿意让你解决一个对他们容易、但对业务影响不大的问题。
Harj Taggar： 回到开场的问题：为什么现在大量 AI 公司突然开始招聘 FDE？上一代 SaaS 公司没有这样做。即使 Palantir 成功后，FDE 也常被看成政府业务这个特殊公司的特例；现在它却变得普遍。这是否让你意外？
Bob McGrew： 这完全出乎意料。我对想尝试 FDE 的人的第一、第二、第三条建议都是：如果能避免，就不要在家尝试。你很可能最后做成服务公司。只有当你真的努力避免、仍然失败，而且市场只有这条路时，它才可能成为护城河。
Palantir 必须这么做，是因为它面对的不是一个统一市场：国家情报机构、执法部门和军队有相似项目，但反扩散工作和反恐工作并不相同。市场应该被看成多个细分市场；在一个细分里找到 PMF 后，可以把类似工作部署给下一家客户，但跨到新细分市场时又需要新技术。大型政府客户甚至可能包含数万用户，所以“做不规模化的事”必须在每个细分市场反复、可复制地做。
AI Agent 也有类似特点，而且它是全新的市场类别。Palantir 用户以前像在 PowerPoint 里画关系图、互相发送文件；Palantir 让画图的动作实际改变共享数据库。对用户来说只是小变化，对企业来说却是全新的类别。普通 SaaS 是用一个产品替代另一个已知产品，市场和竞争对象都清楚；AI Agent 没有既有产品，而且“AI Agent”可能本身包含很多尚未区分的工作。正因为需要大量产品发现，FDE 才会从企业内部填补能力与采用之间的缺口。
Harj Taggar： 这和 YC 常说的“做不可规模化的事情”有什么关系？
代表帧为 Bob 与 Harj 的双人镜头；全片没有图表，视觉重点是主讲人和主持人的问答交接。
Bob McGrew： FDE 模式实际上是在规模化地做“不可规模化的事情”。
Diana Hu： YC 下一期项目正在申请。你有一个创业想法吗？现在申请 YC；申请永远不会太早，填写申请本身也会帮助你完善想法。
Jared Friedman： 回到节目。很多没有在 Palantir 工作过的人正在二手、三手地复制 FDE 模式。你看到他们常犯的错误或误解是什么？
Bob McGrew： 我观察到，最成功的 FDE 创业公司往往让 Palantir 的人来负责 FDE 模式。把一个有 Palantir 经验的人放进核心岗位，能带来很大帮助。工程团队可能和普通软件公司相似，但 FDE 如何运作、如何建立客户账户、如何找到客户真正愿意付费的结果，都和标准软件公司很不一样。
关键差异之一，是怎样选择问题，以及怎样给问题定价。FDE 模式卖的不是软件安装，而是结果；用 Sham 的话说，是卖“你已经解决了一个问题”。问题解决、用户得到价值之后，下一步就是：这个结果应该如何定价？这正是许多 AI 创业公司反复问的问题。
代表帧为 Bob 单人近景，画面保留稳定的演播室构图；中间的 YC 广告串场是独立的短暂口播，没有额外资料画面。
Harj Taggar： SaaS 时代通常按使用量、订阅或席位收费，但按结果收费完全不同。AI 创业者到底该怎样给自己的解决方案定价？
Bob McGrew： SaaS 和产品市场匹配追求的是简单、可重复、适用于所有客户的合同和价格。由于边际部署成本很低，较小的合同也可以成立。FDE 模式则会把公司推向越来越大的合同，因为每个客户的合同规模会随时间增长；合同更复杂，也会更灵活。
我合作的一家叫 Castle 的公司，做抵押贷款服务的 AI 语音 Agent，为大型银行提供服务。它们能够进入大型银行，正是通过逐步增加成功处理的抵押贷款请求数量来推进，并提前约定达到规模化时的指标。另一家 YC 公司 Happy Robot 为物流行业做 AI 语音 Agent，客户包括 DHL，也采用了类似方式。
创业公司和大型企业之间存在不对称。企业往往不相信自己能真正完成什么，因为过去有很多大型项目失败；它们也不相信创业公司能完成，因为认为创业公司和自己一样。创业公司则必须相信自己的执行能力，否则就不该做这门生意。早期可以由创业公司承担风险：如果做成了再付费，或者等到能够扩展时再付费。
代表帧为女性主持人与 Bob 的双人镜头；画面没有显示 Castle、Happy Robot 或 DHL 的资料卡，企业案例完全来自口头对话。
Bob McGrew： 大企业往往不相信自己能完成什么，因为过去有很多大型项目失败；它们也不相信创业公司能完成，因为认为创业公司和自己一样。创业公司反而知道自己能执行，否则就不该做这门生意。因此早期由创业公司承担风险是合理的：相信自己的执行，如果成功了再收费，或者等到能够扩展时再收费。
一个容易出问题的地方，是产品需要部署在企业内部、而不是完全运行在云端。你会遇到 IT 团队。更一般地说，你要找出部署所在组织里谁有权说“是”。这些人可能不按创业公司的方式思考，也不一定和最终用户站在一起，所以需要找到绕过组织阻力的方法。这也是为什么项目必须解决 CEO 排名前五的问题：你需要让最高层授权，让团队可以运行，并允许它使用适合的数据库和其他技术，而不是被企业内部 IT 规则束缚。
Harj Taggar： Palantir 当初怎样得到高管支持？现在一些 AI 公司在一年内从零增长到七、八位数收入，似乎也找到了高管支持，但往往很偶然。
Bob McGrew： Palantir 早期也是这样。后来这变成一种纪律和技能，需要 FDE 团队有很强的领导力，把有效方法分享出去，并在一个客户身上不断练习。Palantir 现在可能比任何公司都擅长这件事；我看到做得最好的公司，往往会把有经验的人带进来。但这种能力可以学习，我们当年也是学出来的。
代表帧为女性主持人与 Bob 的双人镜头，画面没有企业架构图；本段的视觉信息主要是主持人与嘉宾的问答关系。
Harj Taggar： Palantir 的 FDE 模式和 YC 的经典建议很接近：不要等人来网站，而是亲自去客户办公室，坐在他们旁边帮助安装。它一直是很好的起步策略，但多数创业公司一开始拿不到大合同，所以不能永远依靠人工、高接触流程；最终必须有能规模化的产品，让用户自己完成安装和使用。
AI 的不同之处在于合同现在可能足够大，高接触方式可以走得更远。很多 Office Hours 问题都是：这种定制工作可以继续到什么程度？我的建议是，每个客户做定制并没有问题，但要让每一个客户所需的定制越来越少。更具体地说，怎样判断是继续增加客户，还是应该停止扩张、抽象出真正的产品？
Bob McGrew： 这正好概括了产品市场匹配策略和 FDE 策略的核心差异。
代表帧为 Harj Taggar 的单人近景，黑色衬衫与麦克风清楚可见；没有屏幕或图表，画面对应主持人提出高接触与产品化问题。
Bob McGrew： 在产品市场匹配策略中，你希望为每个客户做更少的工作、降低成本、让合同规模保持不变。FDE 策略相反：你希望提高合同规模，为当前客户和未来客户交付越来越有价值的工作。因为价值越来越高，每个客户的定制量可以不下降。
所以一个内部指标可以是合同规模，但更一般的指标应该是交付结果的价值，因为那才是真正的东西。公司可能还没有能力把结果货币化、定价并捕获价值，但如果能交付越来越有价值的结果，就说明方向是对的。第二个指标是产品相对于结果提供的杠杆是否越来越大。
这在执行时非常反直觉。FDE 团队要为客户构建一些客户没有明确要求、但实际需要的东西。产品团队不能只把用户体验做得容易使用，还要记住 FDE 也是自己的另一类客户：产品应该在经过 FDE 定制后为最终用户交付好结果，同时为现场 FDE 提供更强的杠杆，而且这种杠杆应不断提高。
第一个客户可能需要大量工作；如果把同一结果卖给第二个客户，应该更容易，后面还要越来越容易。如果真正做成了，构建的不是一摞垂直用例，而是一个平台。正确抽象出核心概念后，即使面对相似但不同的用例，也能获得更多产品杠杆。优秀的 FDE 会主动选择使用平台，而不是自己重新做一次性方案，内部会形成一种“市场”来推动好产品被采用。
这个过程对所有人都很痛苦。我很多次以为自己做出了漂亮的东西，FDE 却说使用它反而更费事。多数时候我可能确实做错了；有时方向是对的，只是没有把产品做到足够容易使用，于是要派开发者到现场把早期方案推过终点。FDE 是否总是对，创始人是否应该自上而下要求他们照做？答案是这些情况都可能正确。什么能从第一家客户推广到三家、十家，第一次见到客户时通常没有足够信息，只能依靠判断。
Harj Taggar： 如果这些公司按结果定价，为什么还要重视 Demo？SaaS 工程师常常不喜欢 Demo 驱动的产品开发，但 FDE 似乎不同。
代表帧为 Bob 与女性主持人的双人镜头；镜头保持稳定，没有出现指标表格，因此合同规模、结果价值和产品杠杆由完整对话承载。
Bob McGrew： 如果产品类型合适，Demo 驱动开发非常有效。Palantir 早期有一个 Demo：帮助分析师阻止一场恐怖袭击。每加入一个功能，都要问这个功能如何真正帮助正在阻止阴谋的分析师。加入直方图时，要考虑它怎样和已有功能一起工作；加入地图时，也要做同样的检查。
如果从“我在构建什么”出发，你会按功能分别追求最好的实现；但构建 Demo 时，你会从客户角度思考。一场好的 Demo 应该让客户产生欲望，看到后想把它带回自己的工作中。那说明你找到了真实痛点，也会迫使团队检查功能是否能协同工作。因为 Demo 要反复展示，从一个功能移动到另一个功能的路径也必须足够直接；这些痛点，如果不做 Demo，可能要到实际部署后才会暴露。
Demo 把思考焦点从“我能构建什么”改成“客户想要什么，以及我是否解决了他的痛点”。
Harj Taggar： 这听起来像在一个高维空间里不断做梯度上升，不断改变变量。
Bob McGrew： 这可能正是关键：你需要构建的是一家学习型公司。Google 或 Meta 这种公司很容易停止学习，因为当下的事情有效，市场也在增长，可以沿着同一个策略继续前进。我的建议是加入一家年轻的公司，不一定是小公司；年轻公司仍在摸索、仍在学习、还没有成功。快速成长的年轻公司能让你看到成功是什么样，也能让你更有准备成为自己的创业者。
这也是 Palantir 产生许多创业公司的原因：即使规模已经很大，它仍然保持持续学习，仍然在做新公司那种不断试错、辛苦推进的工作。YC 的创业体验也是如此，不是顺流而下，而是在不确定能否成功的事情上非常努力。
代表帧为 Bob 与女性主持人的双人镜头；没有真实产品 Demo 画面，视觉上保留的是节目对谈，而非把口头描述误认为屏幕演示。
Harj Taggar： Palantir 已经是一家非常成功、规模很大的公司。听说你加入了另一个大型组织，美国陆军预备役。能不能介绍一下？你计划把哪些 Palantir 经验带过去？
Bob McGrew： 我最近加入美国陆军预备役 Detachment 201。先说明一点：下面说的都是我的个人观点，不代表美国陆军、国防部或美国政府。
我们所在的单位为陆军提供技术建议，而且不是旁边给建议的平民顾问，而是真正的军官。我们宣誓加入，我是美国陆军中校。我们参加了直接任命军官课程，接受军事学者训练，常常早上五点开始，因为这样不影响东海岸成员的日常工作；我还参加了陆军体能测试，为此训练了九个月。之所以重要，是因为我们不是站在组织外面提意见，而是实际属于正在提供建议的组织，自己也承担结果。
陆军现在的领导层和 Palantir 早期在 2005 或 2010 年接触到的情况不同。陆军参谋长 Randy George 将军和陆军部长 Driscoll 已经提出转型计划：从伊拉克和阿富汗式战争转向今天乌克兰的战争形态，或设想太平洋地区的大规模作战。他们知道陆军需要更快、更彻底地变化，我们参与了这套执行计划。
他们给出陆军的优先级和每个人负责的领域，也允许我们在组织中寻找问题，直接和一线军官解决，必要时向领导层升级。这个过程在很多方面像在陆军运行 FDE：先看领导层的前五个优先事项，再判断能否推进，同时处理领导想要的方向和二十年来实际执行方式之间的断层。改变需要时间，但我们正在帮助它发生。
代表帧为圆桌全景，Bob 位于中间；没有军队资料画面，陆军预备役、军官身份和组织转型信息来自口述。
Jared Friedman： 这个播客有一个固定问题：现在创业者最好的机会是什么？
Bob McGrew： 这又回到了一个问题：为什么 AI Agent 公司采用 FDE？如果从更高层次看，模型能力提升非常快。有人在 GPT-5 之后感觉能力停滞，但从 2024 年 4 月最好的模型 GPT-4o，到 2025 年 4 月 o3 发布，这个进步速度非常快，而且我认为还会继续。
真正令人震惊的是，采用速度远没有能力提升那么快。未来五年，能力可能不断向前冲，而世界却显得越来越平淡。你坐在 Waymo 里，不会一直感叹“居然没有人驾驶”，而只是觉得“交通怎么这么慢”。
这和 FDE 的世界很像：FDE 填补产品能力与客户需要之间的差距。现在有大量机会去填补 AI 实际能做什么与客户能够采用什么之间的空白。2018 年 AI 早期，我们围坐在桌旁讨论 AGI 出现后会怎样；很多人想象它可能一夜之间醒来、接管世界。但他们忽略了 AI 必须被采用，采用不会自动发生，需要人的创造力、探索以及承受痛苦的能力，才能让技术真正对人有用。
所以机会在于观察现有能力，再追问：怎样把它变成真正可用的产品？有一个可能有点勉强的类比：OpenAI 像产品团队，创业公司像 FDE，在现场寻找如何让 OpenAI 在“总部”做出的研究真正被采用。
Jared Friedman： 我觉得这个类比并不差，可能这正是 FDE 模式重新变得令人兴奋的底层原因。
Harj Taggar： 今天时间到了。Bob，谢谢你来，我们都学到了很多，下次再见。
代表帧为节目结束时的圆桌全景，四位参与者都在场；这是收尾对谈，没有独立图表或产品画面。