两份资料，两种口径
Palantir 的 2025 财年年报（10-K，美国上市公司每年提交给证监会的年度报告）说公司有四个主要软件平台：Gotham、Foundry、Apollo 和 AIP。但它当前的开发者文档（架构中心）只列了三个集成平台：AIP、Foundry 和 Apollo。Gotham 的核心应用已集成到标准架构中，由 Foundry 管理的 Ontology 驱动。
这不是笔误。年报面向投资者，回答”公司卖哪些产品”；开发者文档面向技术人员，回答”这些产品怎么协作”。两份资料描述的是同一套产品体系，但产品口径和架构口径划出的边界不同。如果只看一份就去判断 Palantir 是什么类型的公司，看到的产品边界也会不同。
这个问题值得花时间搞清楚，因为 Palantir 把软件平台、AI 能力和深度项目交付放在一起做。它到底怎么把这几样东西组合成一门生意，决定了你能从它身上学到什么。
先看它卖什么
年报把收入来源分为三类：Palantir Cloud 订阅、客户环境中的软件平台加持续运维、Professional Services。Professional Services 不只是售后支持，年报明确写了它还包括持续的 Ontology 与数据建模支持。换句话说，Palantir 在商业文件里就不只是卖软件许可证。
它还有一套获客方式叫 AIP Bootcamp。官方博客 把它描述为一个密集的动手工作坊，参与者可以在 1 到 5 天内从零做出一个用例。但 10-K 把 Bootcamp 放在客户获取阶段，通常由 Palantir 投入成本，以免费或低价方式向潜在客户提供，并且不保证产生后续收入。一个 5 天的工作坊能快速展示一个用例，但不等于客户已经把平台跑进了日常运营。
据 FY2025 10-K 和 Bootcamp 官方博客整理。蓝框为软件订阅类，橙框为服务类；占比未拆分
平台之间怎么协作
Palantir 给开发者的技术文档把分工说得很清楚。
- Foundry 管数据、逻辑、Ontology 开发和工作流。
- AIP 管和大模型的安全连接，同时提供 Agent 工具链、应用和评估能力。
- Apollo 管持续交付，负责承载 Foundry 和 AIP 运行的底层基础设施。三者是集成关系，共享横跨平台的安全架构。
真正让这套架构特别的是 Ontology。它比通常说的”语义层”多一层操作性，把数据、业务逻辑、操作动作和安全权限绑在同一个核心系统里。客户在 Foundry 里建 Ontology，把业务对象和它们之间的关系定义出来，然后应用、工作流和 AI 能力都挂在这套模型上。
AI 直接接在业务模型上。一个 Agent 想执行动作，它走的权限路径在 Ontology 里有定义，同时还要通过平台层和基础设施层的安全控制。对想做企业 AI 的人来说，值得注意的是模型能力、业务逻辑和安全控制通过同一个核心模型连接。
Palantir Architecture Center 官方平台图
按功能位置整理，Gotham 在商业文件和技术文档中位置不同，不代表产品被合并或降级
按照 Palantir 的开发者文档，这套标准架构的设计目标是支持跨环境扩展。它能不能在不同客户之间复用，是后面判断 Palantir 增长来源的关键。
项目怎么落地
平台能买，但客户真正用起来还差一层：谁来把 Foundry 和 Ontology 接进具体业务流程。
这个阶段有一些公开信息。年报写了一条关键信息：与现有客户合作的工程师负责平台的部署和日常运维，同时不断寻找新用途。这已经超出普通售后支持范围：工程师会深度介入平台部署、运行和客户扩展。
开发者文档描述了一种叫 FDE（Forward Deployed Engineering）的产品开发范式，并把这种反馈机制比作”人类版本的反向传播”，意思是现场工程师的经验会反馈到产品开发里。年报里的工程师和架构文档里的 FDE 可能是同一群人，但公开资料没有证明重合程度。
从 Bootcamp 到正式部署之间，还隔着一段看不见的距离。初步用例做出后是否进入生产、由谁承担实施、需要多久、转化率多少，年报和开发者文档都没有说。
按公开能力整理，具体分工和转化率未见披露
Maven Smart System 是一个能看到结果但看不到过程的案例。Reuters 报道称，其审阅的一封美国国防部副部长 Steve Feinberg 于 2026 年 3 月 9 日发出的信件显示，它将成为国防部的正式采办项目，预计当财年结束前生效。美国陆军和国防部的公开报道显示它已用于目标识别与指挥控制相关工作流。但具体怎么部署、用例怎么选、Ontology 怎么建，公开资料不足以还原。
有多能赚钱，赚了多少钱
据 Palantir 的 2025 财年（截至 2025 年 12 月，下称 FY2025）财务公告和 10-K：
- 全年收入 44.75 亿美元，同比增长 56%
- 营业利润 14.14 亿美元，FY2024 只有 3.10 亿；营业利润率从约 11% 升到约 32%
- 贡献利润率（Palantir 自定义的非 GAAP 指标，收入减收入成本和销售营销费用，不含股权激励）从 60% 升到 66%
- 全职员工 4,429 人，相比 FY2024 的约 3,900 人增长约 12.5%，收入增速是员工增速的四倍多（10-K 同时披露公司还使用兼职人员、独立承包商和第三方人员，这些人数没有公布）
- 前三大客户平均合作十年，占收入约 16%
来源为 Palantir 向 SEC 提交的 FY2025 10-K 和 Q4 财务公告
这些数据至少说明，FY2025 的收入没有伴随全职员工同比例扩张，利润率也明显改善，Palantir 在这一年跑出了经营杠杆。我的判断是，这已经不像单纯依靠全职员工同步扩张的项目生意。但 10-K 没有披露兼职人员、独立承包商和第三方人员数量，因此不能据此排除新增交付对增长的贡献。
这种杠杆有多少来自平台复用，有多少依赖新增现场交付？公开资料没有披露每个账户的部署人员、工时和扩张成本，因此无法判断。10-K 还能说明另一件事：FY2025 政府收入增量 8.33 亿美元中，原有客户贡献了 7.74 亿；商业收入增量 7.77 亿美元中，原有客户贡献了 4.25 亿。合计约 75% 的收入增量来自原有客户，说明增长很大程度上依赖现有客户持续扩张。但这种扩张既可能来自平台在更多部门和工作流中复用，也可能依赖新增交付。
别人能学吗
回到开头的问题。Palantir 更接近”软件平台加深度项目交付”：它有标准化的技术底座，同时用工程师深度介入客户的部署和运行。
对想学习 Palantir 的人来说，Ontology 的架构文档是公开的，可以独立研究。Foundry、AIP 和 Apollo 的定位也不难理解。但真正难复制的不是这些概念。
复制门槛至少有几项。
- 第一是平台研发投入：FY2025 研发费用超过 4 亿美元（不含股权激励），花得起这个钱只是必要条件，不等于形成了壁垒。
- 第二是现场工程与核心研发的协同：年报写了工程师负责部署运维和寻找新用途，开发者文档又把现场经验回流产品作为 FDE 范式的一部分，难点不只是招聘人数，还在于这两套组织怎么协作。
- 第三是涉密政府项目准入：10-K 明确写了人员安全许可和设施许可能影响能否投标和履约，获取许可是一个漫长过程。
- 第四是长期客户关系：前三大客户平均合作十年，这种关系沉淀不是新公司能快速建立的。
只复制 FDE 和 Ontology 这些概念，复制到的只是概念层。现场工程与核心研发的协同机制、涉密政府项目准入和长期客户关系，并不会随之出现。
据 FY2025 10-K 和开发者文档整理。A/B/C 为示意，不对应真实客户
总结
Palantir 在 FY2025 跑出了高增长和明显的经营杠杆：收入增长 56%，营业利润率从 11% 升到 32%，约 75% 的收入增量来自原有客户，前三大客户平均合作十年。这说明自建平台加深度项目交付的组合在这一年运转得很好，但单年数据不足以证明长期规模效应，也不能排除阶段性因素。 但如果你想复制这套打法，要面对几个硬问题：平台研发投入门槛多高？现场工程与核心研发怎么协同？政府项目准入和长期客户关系怎么获得？现场经验有多少能沉淀回平台？
