← Work

Palantir 是怎么从 FDE 走到平台的？

15 October 2026 · 30 min read

Palantir 以 FDE（forward deployed engineer，前线部署工程师）出名，但最后成了一家平台公司。这到底是怎么做到的？我不想再听那个很泛的答案，派人去客户那里做项目，再把共性提炼出来产品化，这个谁都知道。我想知道的是具体怎么做的，细节越多越好。

先说结论：把它概括成派人驻场、提炼共性，只描述了结果。从专利、招股书、官方文档和前员工的一手叙述里，能找到几项具体的设计，真正起作用的是它们。

  • 差异放进配置。 从 2006 年起，数据模型就是一个可以随时修改的本体（ontology）。客户之间的差异先变成配置，而不是每家各写一套代码。
  • 安全做进平台。 权限、安全标记和审计日志都内建在平台里。FDE 最耗时的那部分工作，也就是谈数据访问，因此变成了产品功能。
  • 一套代码到处跑。 Apollo 把同一套代码同步升级到几百个环境，包括断网的涉密网络。定制不会分叉成一堆停在旧版本上的私有分支。
  • 成本看得见。 FDE 的成本记在销售费用里，按单个客户账户计算贡献利润率，所以每年都能在报表上看到产品化走到了哪一步。

再往外一层还有三件事：打官司逼政府按商业软件采购；只做单客户价值大到能摊平驻场成本的大机构；创始人控制权带来的十几年耐心。产品化也不是一次性完成的。FDE 的各类工作被平台按顺序吸收：先是数据建模和权限，然后是数据接入、分析、给一线用的小应用、部署运维、把方案复制到下一个客户、售前试点。到 2026 年，FDE 在平台里干活这件事本身也做成了产品，叫 AI FDE。

时间线

时间 事件 依据
2004–2008 主要靠 Thiel 个人出资，In-Q-Tel 两轮共投约 200 万美元；2005–2008 年 CIA 是唯一客户，也是 alpha 测试方 Forbes 2013
2006.11 申请动态本体专利，2011 年授权 US 7,962,495
2008 Gotham 发布；美军特种作战指挥官开始在中东使用 S-1
2009–2010 第一个商业客户 JPMorgan，最多约 120 名 FDE 驻场 Bloomberg 2018
2013 Credit Suisse 开始使用 Foundry S-1
2015–2017 Coca-Cola、AmEx、Nasdaq、Home Depot、Hershey 相继离开 BuzzFeed、CNBC、Bloomberg
2016 Foundry 正式发布；开始与 Airbus 合作；起诉美国陆军，10 月胜诉 S-1、Defense News
2017.06 Skywise 上线 S-1
2018 销售费用占收入 78%，贡献利润率 14%；年底才开始招直销 S-1
2019→2020 平均上线时间降到 14 天；每周升级次数从 2 万到 4.1 万，再到 15 万以上；2020 年 Q2 贡献利润率 55% S-1、2021 年 Demo Day
2021 Apollo 对外商用；推出 Foundry for Builders，并投资多家 SPAC 10-K、媒体报道
2023 发布 AIP，用 bootcamp 取代长试点；发布 OSDK 财报、官方公告
2024 推出免费的 Developer Tier；办首届 DevCon 10-K、官方公告
2025.07 陆军企业协议：75 份合同合并成 1 份，10 年上限 100 亿美元 美国陆军
2026 AI FDE 上线；Q2 营收 19.35 亿美元，美国商业收入同比增长 149% 官方文档、财报报道

一、先把 FDE 组织本身说准确

Palantir 人数最多的两类工程岗位叫 Dev 和 Delta。按官方博客 Dev versus Delta 的说法，Dev 是 Software Engineer，归属某个平台组件团队，端到端负责这个组件，博客举的例子是 Foundry 的存储基础设施和 Gotham 的 UX；Delta 是 Forward Deployed Software Engineer，这个名字来自早期的习惯，各个 Business Development 团队按北约音标字母命名。另一个驻场角色 Echo 是 Deployment Strategist，官方博客说它名义上更偏产品经理，Delta 更偏技术，但实际上两者都混着产品、工程和策略。

有个细节容易被忽略：FDE 最早挂在 BD 体系下，Nabeel Qureshi 在 Reflections on Palantir 里直接叫他们 BD engineers，S-1 也把执行试点和客户增长的人员成本记在销售费用里。所以无论组织上还是会计上，FDE 从一开始就被当作获客和扩张的投入，而不是交付部门。

Nabeel 2015 年以 FDE 身份入职，当时公司约 1500 人。他描述的情况是：每个客户配 4–5 人的小队，每周驻场 3–4 天，接到电话先上飞机再问细节；除了五六个 Director 和 CEO，全公司几乎没有头衔，大多数人挂的都是 FDE。S-1 写明工程师会在现场和研发之间轮换，并把现场工程师称为研发的一支。Bob McGrew 在 YC 的 Lightcone 播客里讲过招人标准（这里依据的是二手摘要）：Echo 要找有领域知识、对现有流程不满、敢推动三到十倍改进的人；Delta 要找能按期交出能跑的东西的人，代码可维护性排在后面。曾负责 Gotham 产品的 Adam Judelson 补充了两点：FDE 是进入新用例时的先头部队，不是一个永久状态；迭代以天为单位，连设计师也派到前线。规模上，Bloomberg 2018 年估计约两千名工程师里有一半在客户现场，2016–2017 年在职的 Sarah Constantin 估计至少三分之一的员工在客户现场。

FDE 收集的是什么？负责商业业务的 Ted Mabrey 在 Sorry, that isn't an FDE 里讲过这个角色的来源：Karp 观察过好的法国餐厅，服务员是厨房的一部分，你给鱼配错了酒，他会直接拒绝。也就是说，交付环节本身就是产品的一部分，而且必须有主见。所以 FDE 被训练成把自己当作客户业务的所有者，像一个没有任何权力的 CEO 那样对客户的结果负责；他们欢迎需求范围扩大，项目章程每个月重写一次也正常。这决定了 FDE 带回来的不是客户的需求清单，而是客户可能失败的原因。

二、第一层机制：一开始就把客户差异设计成配置

动态本体专利 US 7,962,495 于 2006 年 11 月申请、2011 年授权，发明人是 Akash Jain、Bob McGrew（后来的 OpenAI 首席研究官）和联合创始人 Nathan Gettings。专利背景写得很直白：传统数据库的本体在建库时就定死了，改 schema 对系统破坏极大，这种僵硬对组织是严重缺陷。它的方案是让用户随时修改对象类型和属性类型，每种属性配一份解析规则，把原始输入转换成该类型，规则可以是正则，也可以是代码模块，都通过管理编辑器维护。

这对 FDE 意味着，他们在每个客户那里的主要产出就是本体定义和解析规则。它们是产品内部的工件，下一个客户可以直接复用或改写，而不是一套只有那几个工程师看得懂的独立代码。McGrew 的说法与此吻合：不为每个站点分别建人、钱、物的专用表，而是用一个通用的对象、属性、媒体、链接模型，站点的特殊之处写在它上面。他的比喻是，FDE 先修碎石路，产品团队再铺成高速，而且要一直追问，对下五到十个客户来说，通用版本长什么样。

安全同样很早就做进去了。Forbes 2013 年的长文写到，为了兑现隐私承诺，Palantir 必须给客户数据打标签，按授权决定谁能看，并把所有操作写进不可篡改的日志。Nabeel 解释了这和产品化的关系：企业内部争夺数据访问权，一部分是出于真实的安全顾虑，一个 8–12 周的试点有时整段时间都耗在拿数据权限上，最后一周才赶出演示；把角色权限、行级策略、安全标记和审计做进数据集成层以后，接入 Palantir 反而让客户的数据更安全。FDE 工作里最大的一块政治性工作，就这样变成了产品功能。到 2013 年，Forbes 的描述是 FDE 几天就能把客户数据爬取、打标签、整合完，一次安装往往不到 100 万美元。

三、差点掉进去的坑：商业化早期很像外包

政府业务靠上面两项设计没有变成外包，但商业业务的最初几年很像外包。第一个商业客户是 JPMorgan，Forbes 说是 2010 年经纽约警局介绍，Bloomberg 说 2009 年就开始了。工程师在翠贝卡租了一间阁楼，睡上下铺，先做反欺诈，再去拆有毒按揭资产。Bloomberg 2018 年的报道给了更多细节：最多约 120 名 FDE 支持该行的内部威胁调查组，每名工程师每天收费最高约 3000 美元，JPMorgan 实际上成了 Palantir 金融产品 Metropolis 的研发实验室和试验场，后来该行大幅缩减了使用。Metropolis 原名 Palantir Finance，2010 年还通过 Thomson Reuters 以 QA Studio 的名字转售，后来停掉，由 Foundry 接替。

问题在 2015–2017 年集中暴露。BuzzFeed 2016 年依据内部文件报道（Fortune 转述），Coca-Cola、American Express、Nasdaq 在一年内相继离开，有客户觉得每月最高约 100 万美元的费用不值；同一篇报道说，公司对外称 2015 年 bookings 为 17 亿美元，内部材料显示实收约 4.2 亿。Home Depot 2016 年底离开，Hershey 2015 年开始合作，两年后退出。Karp 对 Bloomberg 说，他们并不想做服务公司；Bloomberg 也写到，Foundry 的目标是更多自动化、更少依赖驻场工程师。S-1 里的数字能看出当时有多重：2018 年收入 5.95 亿美元，销售费用 4.62 亿美元，占收入 78%，按 Palantir 自己的口径，贡献利润率只有 14%。

这里的会计口径要单独说一下。按 S-1，销售费用主要是执行试点和推动客户增长的人员薪酬，加上试点用的云托管费用；营业成本包括运维和按需提供的专业服务，即用户支持、界面配置、培训，以及持续的本体和数据建模支持。所以 Palantir 那个接近软件公司的毛利率（2019 年 67%，剔除股权激励后 71%）并没有把大部分 FDE 成本算进去。真正反映产品化程度的，是贡献利润率和销售费用占收入的比例。

四、转换期（2015–2020）：FDE 的工作一类一类被平台吸收

1. 哪类工作被哪个产品吸收

FDE 原来手工做的事 吸收它的平台能力 依据
给每个客户设计数据模型 动态本体；S-1 提到的种子本体；DevOps 里可以安装的行业本体产品 专利、S-1、官方文档
争取数据访问、打消安全顾虑 平台内建的角色权限、行级策略、安全标记、审计日志 Forbes 2013、Nabeel
把数据接进来 Magritte 和 Data Connection（支持客户自己维护的连接器插件）；针对 SAP 等 ERP 的 HyperAuto/SDDI Nabeel、S-1、Demo Day
写分析、做图 Contour（点选式分析）；Quiver（大规模时序分析，相关能力最早服务油气井数据） Nabeel、S-1
给一线用户做小应用 Workshop（低代码，可写回本体）；Slate（可写 HTML/CSS/JS） Nabeel、S-1、官方文档
每个环境的安装、升级、打补丁 Apollo S-1、Demo Day、10-K
把一个客户的方案搬到下一个 Foundry DevOps 和 Marketplace 的产品包 官方文档
售前试点 AIP bootcamp 财报电话会
在平台里搭管道、改本体、写函数、测函数 AI FDE、AIP Evolve 官方文档；上线时间来自二手转述

Nabeel 对 Foundry 起源的描述，对应这张表的前半部分：FDE 在客户现场做大量重复的杂活，PD 工程师造工具把这些杂活自动化，接 SAP 或 AWS 的数据有 Magritte，可视化有 Contour，快速搭 web 应用有 Workshop。把这些工具直接交给客户用，在当时被看作很激进的一步，因为工具还不成熟。S-1 写到 Credit Suisse 2013 年就开始用 Foundry，比 2016 年正式发布早三年，这说明 Foundry 不是 2016 年另起炉灶做出来的，而是一套先给 FDE 用、再逐步开放给客户的工具链。

S-1 给了这条路上最硬的两个数字。从 2019 年 Q2 到 2020 年 Q2，客户开始在平台上处理自己数据所需的时间缩短了五倍多，平均 14 天，个别客户 6 小时；针对 ERP 的集成（即 HyperAuto）上线后，客户把数据映射到本体、开始搭应用的时间，从最长 45 天降到最短 4 天。Palantir 在 S-1 里把同期的利润改善，主要归因于安装、部署和管理平台所需的时间和工程师人数大幅减少。S-1 里还有一个跨行业复用的例子：为油气客户优化原油生产而开发的能力，后来被医疗设备厂商用来优化供应链，也被卫生部门用来分配防护物资；为处理油井流式时序数据而做的能力（S-1 说单口井每天的数据量超过 Twitter），也被其他客户复用了。

2. 产品团队和 FDE 之间刻意设计的矛盾

Ted Mabrey 那篇文章给出了目前公开资料里最具体的内部规则。按他的说法，这套关系本来就充满矛盾：FDE 被鼓励写定制软件；Dev 被鼓励丢下自己的路线图，去集中攻高价值的机会，同时又被鼓励不理会 FDE；FDE 不能偏离少数几条核心产品原则，但他没有列出是哪几条。核心产品的来源也各不相同：很多源于某个客户的具体方案，很多是天才从零做出来的，还有很多要经历 10–20 次不同的定制实现，才合成为一项承重的通用技术。他承认这种做法很乱，没有任何一条规则拿去对照 Palantir 最重要产品的发展史而不被违反，靠的是品味，而且高度依赖 Stephen Cohen、Shyam Sankar、Bob McGrew、Brian Schimpf 以及另外三到五个不那么有名的人，关键人风险很大。

矛盾背后有一个明确的取向：FDE 不是替客户压缩野心、把需求裁成产品今天能做的样子，而是把客户可能失败的每一个原因都算作产品的缺陷。他的原话是 "Those shortcomings define our roadmap." 与之配套，他认为 Palantir 的产品命题本质上做不完，Gotham 是同时提升安全和公民自由，Foundry 是让个人和组织的每个决策都建立在完整的事实上，所以衡量产品组织的唯一指标是产品边界扩张的速度，组织要围绕这一点来建。

另外两个视角可以互相印证。McGrew 说，产品团队应该把 FDE 当作最重要的用户，目标是给 FDE 杠杆，不听 FDE 的产品团队一定会做错东西。Nabeel 的说法更朴素：FDE 只管解决问题，不用担心过拟合；PD 的工作是把 FDE 做出来的东西泛化，更广义地说，是造出让 FDE 干得更快的软件。

3. 定制要有合法的落点

我没有找到公开资料证明 Palantir 有禁止在平台外写代码的硬性规定。能找到的是另一种更有效的安排：平台在每一层都给定制留了正式出口。S-1 里的数据连接框架支持客户自己维护的连接器插件；代码仓库和数据分支让开发者可以在不影响生产的情况下修改数据和应用；Slate 允许写 HTML、CSS 和 JavaScript；本体会自动生成领域 SDK，也就是后来的 OSDK，给客户的开发者用；官方的架构文档还提到 Compute Modules，可以把客户自带的容器放进 Apollo 管理的服务网格。

这份架构文档把目标描述为通过可维护的定制获得极端的差异化，并借用了投资里 alpha 和 beta 的比喻：一刀切的 SaaS 摘的是低垂的果实，那是 beta，Palantir 希望客户在平台上追求的是 alpha。我的推断是，正因为定制有合法落点，FDE 写的定制才会被版本化，受同一套权限和数据血缘管理，跟着平台统一升级；Dev 也才看得见哪类东西已经在 10–20 个客户那里被重复写过。这和 Ted 说的合成过程是同一件事。

4. Apollo：同一套代码到处跑

Palantir 的软件要跑在 AWS、Azure、各种涉密云、本地机房、断网的笔记本、潜艇和 9000 架飞机上。S-1 的描述是，不给每个安装配专门的团队，而是由一小组工程师管理几乎全部的部署，让最新功能和安全补丁在所有安装上几乎同时生效；断网和本地环境的部署速度和云上一样，所以即使是单租户的断网客户，也能拿到多租户云的经济性。S-1 里还没有出现 Apollo 这个名字，只有数字：每周升级次数从 2019 年 Q2 的 2 万次增加到 2020 年 Q2 的 4.1 万次。2021 年 1 月的 Demo Day 说，2020 年 Q4 已超过每周 15 万次。Palantir 自己的博客说，在受限、断网或偏远环境里运行服务，是建 Apollo 的主要原因；到了 IL6 涉密网络，做法是系统生成发布包，由网络运营中心按安全规程摆渡进去，之后自动应用。

这件事对 FDE 到平台的转变是决定性的。没有它，每个客户的定制都会把这个客户冻结在某个版本上，几年后就是几百个私有分支，FDE 的时间全花在维护旧版本上，这就是外包的终点。有了它，FDE 在客户 A 写的东西一旦合进平台，客户 B 下周就自动拿到。

Apollo 后来也变成了能卖给别人的平台。它 2021 年对外商用，之后又衍生出 FedStart：其他软件公司把产品放进 Palantir 已经拿到 FedRAMP 和国防部 IL 认证的环境里运行。走这条路的有 TRM Labs（2024 年）、Anthropic（2025 年 4 月，Claude 借此以 FedRAMP High 和 IL5 级别进入政府）、Unstructured（2025 年 8 月）。

5. 按客户账户算贡献利润率，管理 FDE 投入

S-1 把客户分成 Acquire、Expand、Scale 三个阶段，定义很机械：一年内确认收入不到 10 万美元的是 Acquire；超过 10 万美元但贡献利润率为负的是 Expand；超过 10 万美元且贡献利润率为正的是 Scale。贡献利润率等于收入减去营业成本和销售费用（都剔除股权激励）再除以收入，这个口径正好把 FDE 的主要成本都装了进去。

阶段 2019 年收入 贡献利润率
Acquire 60 万美元 贡献亏损 6540 万美元
Expand 1.763 亿美元 -43%
Scale 5.657 亿美元 55%（其中最好的四分之一客户 87%）

同一批 Expand 客户，到 2020 年上半年贡献利润率转为 +35%。S-1 还写明了几件事：他们会逐个客户账户评估工程师该多投还是少投；定价主要基于预期为客户创造的价值；合同平均剩余期限约 3.5 年；销售周期通常 6–9 个月。

这套口径把 FDE 当成一笔可以算回报的投资，产品化有没有进展也能直接看见：销售费用占收入的比例从 2018 年的 78% 降到 2019 年的 61%，再到 2020 年上半年的 42%；整体贡献利润率从 2018 年的 14%、2019 年的 21%，升到 2020 年 Q2 的 55%。另一个配套动作是，直销人员 2018 年底才开始招，2019 年底开始见效，在那之前，销售主要靠 FDE、前运营人员和高管。

客户选择也是这套账算得过来的前提。Constantin 描述的商业打法是：只卖给面临生存威胁的公司，先拿下高管，再靠帮一线用户省事赢得他们，然后上下夹击，压过通常最抵触外部供应商的中层 IT 和数据团队。Ted 的说法是宁可要对的客户，也不要所有的客户，前 20 大客户一年贡献超过 11 亿美元。S-1 的数字是 2019 年平均每个客户 560 万美元，前 20 大客户平均 2480 万美元、平均合作 6.6 年；到 2024 年，前 20 大客户平均已经到 6460 万美元（10-K）。单客户价值大到这个程度，驻场成本才摊得开，FDE 在一个客户那里学到的东西也才值得放进平台。

6. 让客户自己成为 builder，再借行业平台分发

S-1 对 Scale 阶段的描述是，软件铺满整个企业以后，客户在使用上越来越自给自足，开始自己在平台上搭应用。这要靠前面那些工具被开放出来。

Airbus 是最好的例子。Nabeel 入职后的第一个客户就是 Airbus，他在图卢兹工厂驻了一年，每周四天和制造团队一起干活。CEO 说最大的问题是 A350 的产能爬坡，于是他们把工单、缺件、质量不合格项这些分散的数据放进一个界面，能勾选工作进度，看其他团队在做什么、零件在哪、排程如何，还能模糊检索历史上的质量问题和当时的处理方式。他自己形容这是造飞机用的 Asana，并说它帮助 A350 的制造节奏提高到原来的四倍。这段合作 2016 年开始，2017 年 6 月扩展成面向整个航空业的 Skywise；S-1 说三年内从零增长到 100 多家航空公司、15 家供应商、9000 架飞机，而且是 Airbus 和 Palantir 一起去卖，每家航空公司都成了现有或潜在客户。

Palantir 在 S-1 里把这一点写成增长战略：通过平台合作，成为整个行业的操作系统。同类安排还有和 Merck KGaA 的 Syntropy（2018 年 12 月，按软件许可收费），以及在日本和 SOMPO 的合资；今天官方文档列的例子还有 Fujitsu 在 Foundry 和 AIP 的开发工具链上做专门的 agent 应用，以及 Andretti 车队做的 RaceOS。

把方案搬到下一个客户，后来有了专门的产品机制，就是 Foundry DevOps 和 Marketplace。按官方文档，任何 Foundry 资源的组合都能打包成一个产品，类型包括本体（完整的行业标准本体或本体片段）、用例、数据管道和模型；产品声明自己需要哪些输入，安装方把自己的数据映射上去，就能生成输出；产品有版本、依赖管理、发布渠道和维护窗口，可以管理一整批安装；Palantir 自己还维护一个面向所有 Foundry 用户的 Foundry Store。文档列出的用途之一，是装一次作为新定制用例的起点。这和 S-1 里提到的种子本体一脉相承：FDE 的方案先变成可以安装的起点，再在新客户那里继续定制。

7. 在采购规则上拒绝被当成外包

政府业务的产品化，有一半是在法庭上打出来的。2016 年，陆军为 DCGS-A 第二阶段选择了从零定制开发。Palantir 先向 GAO 抗议，没有成功，6 月 30 日在联邦索赔法院起诉，依据是 1994 年的《联邦采购简化法》：机构必须在可行范围内优先采购商业产品，并先评估商业产品能否满足需求。10 月 31 日，Marian Blank Horn 法官判 Palantir 胜诉，联邦巡回上诉法院 2018 年 9 月维持原判。

此后陆军改为采购商业方案。2018 年 3 月，Palantir 和 Raytheon 双双拿到上限 8.76 亿美元、为期 10 年的 Capability Drop 1 合同；经过一年的对比试点，Palantir 在 2019 年 3 月拿下第一个任务订单，首期约 2000 万美元。S-1 里能看出这件事对商业模式的分量：Palantir 只卖商业产品和服务，不承接非商业的开发服务；这部采购法的执行，让它和联邦政府的生意显著增长。

这条线的终点是 2025 年 7 月 31 日陆军宣布的企业协议：把 15 份主合同和 60 份相关合同、共 75 份合并成一份，10 年上限 100 亿美元，理由包括去掉合同和转售商的过手费，并允许陆军按需单项采购。从按项目开发的承包商，到被当作企业软件整体采购，这就是政府业务的平台化在合同形式上的样子。

五、AIP 时期：把获客和 FDE 本身也产品化（2023–2026）

1. 本体从数据模型变成决策模型

2006 年的专利和 2020 年的 S-1 里，本体主要还是对象、属性、关系，加上从本体生成的 SDK 和所见即所得的应用搭建工具；S-1 那时已经有可写回本体的 Workshop，以及支持双向集成的写回连接器。今天的官方架构文档把本体定义为数据、逻辑、动作和安全四者的整合：数据对象只是名词，必须配上动作才能描述一个决策，动作要能实时写回业务系统和边缘系统；动作背后的逻辑可以是业务规则、传统机器学习模型、LLM 函数或多步编排；文档还明确说，本体不是语义层，而是由语言、引擎和工具链组成的系统。

Nabeel 的判断是，将来驱动核心业务流程的 agent 需要对关键业务数据有读写权限，十年的企业数据集成正好是这件事的地基。AIP 在 2023 年能很快落地，靠的是 FDE 过去在几百个客户那里留下的本体、动作和权限体系。

2. Bootcamp 把 Acquire 阶段从几个月压到几天

在 2023 年 Q3 电话会上，Palantir 说整个获客流程改成了 AIP bootcamp，五天或更短时间内在客户的真实数据上交付真实工作流，而传统试点一般要一到三个月；10-K 也写明，2023 年起 bootcamp 成了获客的第一步。规模上，到 2024 年 2 月已经在 465 个组织做了 560 多场，到 2024 年 5 月参与的组织超过 915 个。公司口径的两个例子：一家美国有线电视公司从 LinkedIn 上的冷联系开始，经过五天 bootcamp，签下近 300 万美元的企业协议，全程不到一个季度；一家大型电信公司在已有本体上最快 24 小时交付新用例，促成了数百万美元的扩约。

对比 2019 年 Acquire 阶段 60 万美元收入、6540 万美元贡献亏损，以及 Nabeel 说的 8–12 周试点全耗在拿数据权限上，这等于把 FDE 工作里最贵的那一段直接产品化了。前提是平台已经成熟到客户自己的人几天就能上手。

可以对照的是 2021 年那次失败的尝试。Foundry for Builders 把 Foundry 卖给初创公司，同时 Palantir 通过 PIPE 投资了 14 家 SPAC，共约 3.1 亿美元，很多被投公司同时签了 Foundry 合同。美国商业客户数因此从 2020 年底的 17 家涨到 2021 年底的 80 家，但这些公司的股价后来大跌，有二手估计跌去八成以上。用资本买来的客户没有带来持久的平台采用，压缩交付时间才带来了。

3. 面向开发者的平台

OSDK 在 2023 年 6 月以 TypeScript beta 发布，9 月 GA，开发者可以在自己的开发环境里读本体、通过动作写回、调用本体函数；2024 年加入 Java，11 月首届 DevCon 发布 OSDK 2.0。2024 年还推出了有额度限制的免费 Developer Tier。官方文档也写到，Gotham 的核心多模态应用现在由 Foundry 管理的本体驱动，国防产品最早的组件早于这套标准架构，但现在已全部并入。FDE 时代各自长出来的政府和商业两条产品线，最终合并成了一套架构。

4. AI FDE：把 FDE 本身做成产品

Palantir 官方文档把 FDE 形容为人肉版的反向传播：工程师贴近问题，和核心团队配合，不断把反馈综合进新功能。2026 年，这个角色本身被做成了产品。AI FDE 是一个通过对话操作 Foundry 的 agent，能建和改数据管道、管理数据连接、编辑本体里的对象、链接和动作、写函数并用 AIP Evals 测试、审计权限和标记，以及写基于 OSDK 的 React 应用。它继承用户本人的权限，默认在分支上工作，改动以分支提案或 PR 的形式交给人审核。

据 DataFun 转述 Palantir 的公告，AI FDE 在 2026 年 3 月正式可用；9 月又推出 AIP Evolve，用户设定优化目标、验证方式和允许改动的范围，由多个 AI FDE 分工改模型、改提示词、跑评测，最后提交方案。这两个时间点我没能在 Palantir 的一手页面上核实。

5. 结果

指标 2019 2024 2025 2026 Q2
收入（美元） 7.43 亿 28.7 亿 44.8 亿 单季 19.35 亿（+93%）
全职员工 2,391 3,936 4,429 —
人均收入（美元） 约 31 万 约 73 万 约 101 万 —
客户数 125 711 — 1,049
美国商业客户数 17 382 571 653
前 20 大客户平均收入（美元） 2480 万 6460 万 — —

人均收入是我用年收入除以年末人数算的；2019 列的客户数是 2020 年上半年的数字，美国商业客户数是 2020 年底的数字。

2026 年 Q2 的其他数字：美国商业收入 7.64 亿美元，同比增长 149%；净收入留存率 157%；Palantir 自己算的 Rule of 40 为 155%（报道；美国商业客户数见 YCharts）。Karp 在 2026 年 Q1 电话会上说，公司大约只有 70 名销售，真正在卖的大概 7 个人（247wallst）；Q2 股东信又说，销售人数微不足道，而且还在减少。不过他 2025 年 8 月提出的目标，收入翻 10 倍、员工 3600 人（Fortune），并没有体现在人数上：2025 年底的员工数反而比一年前多了 13%。

六、为什么别人学 FDE 常常学成外包

2026 年，AWS、Google Cloud、Microsoft、OpenAI 和 Anthropic 都在建 FDE 团队（Channel Dive）。Shyam Sankar 在 Q2 电话会上嘲讽说，只有 Palantir 有真正的 FDE，别人有的只是销售工程师。Ted 的批评更具体：模仿者把产品的边界定得很窄，指望从第一天起就零边际成本地卖同一个东西，结果只是把原来外包给系统集成商的成本搬回自己家，却没有得到长期的杠杆；去了这些公司的前 Palantir FDE，说感觉像坐牢。

把上面的材料放在一起，我的判断是，模仿者通常缺下面四个条件中的一个或几个：

  1. 一套代码到处跑、能统一升级的部署体系；
  2. 定制在平台内有合法落点，能被看见、被版本化、被合并；
  3. 按价值定价、按账户算 FDE 的回报，而不是按人天收费；
  4. 单客户价值足够大、资本足够有耐心，能撑过要定制 10–20 次才合成一个通用能力的周期。

Palantir 自己早期的商业业务，缺的恰恰是第三条，也就是 JPMorgan 那种按人天收费的方式，以及随后的一批客户流失。这也说明这几条不是天生就有的，而是一次次付出代价补上的。

七、边界和反证

FDE 没有因为平台化而消失。Palantir 从不披露 FDE 人数，Shyam 在 2026 年仍把增长主要归功于 AIP 和 FDE 团队，政府项目依然很重。也有分析师持不同看法：Omdia 的分析师认为增长更多来自 AI 热潮和与现政府的关系，FDE 排在后面；HSBC 下调评级时认为，agent 框架和 MCP 正在削弱 Palantir 的护城河。平台化也没有消除政治和主权风险，据 Wikipedia 汇总，2026 年法国国内安全总局宣布改用 ChapsVision，英国至少 20 家 NHS 信托停用了它的等候名单工具。

有几处证据是薄的：Ted 没说核心产品原则具体是哪几条；Foundry 的各个组件分别是从哪个客户那里长出来的，没有官方记录；McGrew 的说法来自播客的二手摘要；AI FDE 和 AIP Evolve 的上线时间来自二手转述；Palantir 官方博客的几篇文章我只读到了搜索摘录；Shyam 在 Invest Like the Best 第 462 集里专门讲过 FDE 的起源，但全文需要登录，没有读到。

参考文献

本文根据 2026 年 10 月 13 日与 Claude 的一次调研对话整理，资料检索截至当日。