Palantir 的商业模式不能简单归类为 SaaS 或咨询外包。它更像是通用平台、Forward Deployed Engineering 和客户运营结果之间的组合。
系列：Palantir 系列 7 / 8
Palantir 很难用传统 SaaS 的框架理解。
如果你把它当成标准 SaaS，会觉得它太重、太定制、销售周期太长。
如果你把它当成咨询公司，又会低估它的平台能力和软件复用。
更准确的理解是：
Palantir 用通用平台承载高度定制的运营系统，再通过 Forward Deployed Engineering 把平台推到客户真实问题里。
传统 SaaS 的逻辑
标准 SaaS 通常追求几个东西：
- 产品流程标准化。
- 客户配置轻量化。
- 部署环境统一。
- 边际交付成本低。
- 客户自助使用比例高。
这类模式适合相对通用的流程，例如 CRM、项目管理、财务、人力资源、客服工单。
问题是，Palantir 进入的很多场景并不标准。
一个能源企业的资产运营、一个医院的资源协调、一个制造企业的供应链、一个政府部门的任务系统，往往有大量历史系统、权限约束、现场流程和组织差异。
这些问题很难靠一套固定表单解决。
普通外包的逻辑
普通咨询或外包也能做定制。
但它的问题是复用差。
每个客户一个项目，每个项目一套代码，每个系统一堆集成，交付结束后维护成本持续上升。
这种模式很难形成软件平台效应。
Palantir 不想做纯外包。
它的底层是 Foundry、Ontology、AIP、Apollo 等平台能力；FDE 的任务不是从零手写一个系统，而是把平台能力组合到客户问题中。
所以它介于两者之间：
- 比标准 SaaS 更贴近客户问题。
- 比普通外包更依赖统一平台。
FDE 是商业模式的一部分
Forward Deployed Engineer 不是传统售前，也不是普通实施顾问。
Palantir 博客里对 FDSE 的描述很清楚：他们嵌入客户现场，配置 Palantir 的现有软件平台，解决客户最难的问题。
这解释了 Palantir 为什么不像传统 SaaS。
它不是卖完账号让客户自己慢慢配置，而是派工程力量进入现场，把业务问题翻译成平台对象、数据管道、Ontology、工作流和应用。
这类角色承担三个任务：
- 理解客户真正的运营问题。
- 用平台快速组合出可用系统。
- 把现场反馈带回产品和模型。
FDE 让 Palantir 可以处理非标准场景。
但它也让 Palantir 的交付更重。
这就是商业模式上的张力。
平台和定制如何共存
Palantir 的关键问题是：定制能不能沉淀到平台里。
如果每个客户需求都变成一次性项目，规模化会失败。
如果平台太标准，又无法进入复杂运营现场。
Palantir 的做法是把共性能力沉淀在平台层：
- 数据接入。
- 权限和治理。
- Ontology。
- 工作流构建。
- AI Agent。
- 持续交付。
然后在客户层组合这些能力，形成适合具体业务的系统。
这也是为什么它的产品看起来不像一个单点工具，而像一套开发和运行环境。
这种模式的优点
第一，它能进入高价值复杂场景。
很多企业最核心的问题不是标准 SaaS 能覆盖的。Palantir 通过 FDE 和平台组合，可以进入这些难场景。
第二，它能贴近业务结果。
不是卖一个工具，而是围绕某个运营目标交付系统，例如降低库存风险、提高产线效率、协调医疗资源、改善任务态势。
第三，它能形成深度嵌入。
一旦 Ontology、工作流、权限和动作写回进入客户运营，替换成本会很高。
这种模式的风险
它也有明显风险。
第一，交付重。
FDE 模式需要高质量工程人才，不能像纯 SaaS 那样完全靠产品自助扩张。
第二，销售周期可能长。
复杂客户的问题重要，但决策链条也长。
第三，边界容易模糊。
客户可能把 Palantir 当成万能定制团队，平台公司也可能被项目需求牵引过度。
第四，外界很难估值。
它不像纯 SaaS 那样可以只看标准订阅指标，也不像咨询公司那样只看人天收入。
结尾
Palantir 不像传统 SaaS，不是因为它还没有标准化。
而是因为它选择进入的战场，本来就不是标准 SaaS 最舒服的战场。
它面对的是复杂组织的运营系统问题。
这些问题需要平台，也需要现场工程。
用一句话概括：
Palantir 的商业模式，是用通用平台和 FDE 把复杂组织的运营问题软件化。
理解这一点，才能理解为什么它既不像 SaaS，也不像咨询，而更像一种平台化的企业工程交付模式。
