驻场之后呢？中国公司对 Palantir FDE 的最大误读

想象一个典型的“FDE 项目现场”。

三名工程师进驻客户办公室，白天和业务开需求会，晚上写接口、改 SQL、接模型、做 Agent。两个星期后，一个能跑的系统上线；三个月后，项目验收，工程师撤场。

代码留在一个客户专属仓库里，需求文档归档。半年后，另一家客户提出相似需求，公司重新派三个人过去，再做一次需求调研，再建一套数据库，再写一遍业务逻辑。

今天国内不少公司会把这种模式称为“Palantir 式 FDE”。

它当然属于高强度、贴近业务的一线工程交付。但如果要借用 Palantir 的 FDE 叙事，有一个更关键的问题需要回答：

工程师离开现场之后，这个项目究竟给公司的底层平台留下了什么？

如果答案主要是项目经验、客户关系和一套私有代码，那么它距离 Palantir 的 Forward Deployed Engineering，还有相当远的距离。

一、FDE 的关键，不在“Forward”，在它背后有没有 Platform

Palantir 自己对平台的描述其实已经把这一点说得很清楚。

在 Foundry 中，Ontology 被定义为企业的数字化模型：数据集和模型被映射成 Object Type、Property、Link Type 和 Action Type，由此描述企业里有哪些业务对象、对象之间如何关联，以及人和系统可以对这些对象执行什么动作。

Palantir 在平台架构文档中甚至直接把围绕 Ontology 构建的软件架构称为其关键差异化能力。

所以，当 Palantir 的 FDE 进入一家企业，他面对的工作并不只是“客户提需求，我来写功能”。

更核心的工作，是把客户现实世界里的业务语义转译成平台可以持续操作的结构：

业务实体变成 Objects；

实体关系变成 Links；

业务状态和可执行操作变成 Properties 与 Actions；

散落在 ERP、CRM、数据库、文件和 API 里的数据进入统一的数据管线；

最终，分析、应用、Agent 和自动化工作流建立在同一套企业语义模型上。

这一步非常重要。

因为单个应用会过时，需求会变化，模型也会换，但企业内部“订单是什么”“客户是什么”“设备和工单是什么关系”“谁有权执行什么动作”这类业务语义具有更长的生命周期。

FDE 真正有价值的工程产物，是把这些隐性的业务知识逐渐编码进一个可计算、可复用的企业模型。

驻场只是完成这件事的一种交付方式。

Palantir 自己现在招聘的 FDE 岗位甚至同时存在 on-site 和 hybrid，部分职位只要求根据需要前往客户现场。这本身已经说明，“每天坐在客户办公室”并不是定义这个角色的充分条件。

二、Ontology 为什么会产生“复利”

理解这一层之后，Palantir 经常被讨论的“复利效应”就容易理解了。

假设一个企业的核心业务对象、权限、关系、数据管线和 Actions 已经被建模进入 Ontology。

第一个 use case 往往很重。

FDE 要理解业务、接数据、处理权限、定义对象、建立关系、设计 Actions，再把它们组合成应用或工作流。

但第二个、第三个 use case 开始，很多底层工作已经完成。

新的 Agent 可以直接理解已有 Objects；新的应用可以复用既有权限和 Actions；新的自动化流程可以调用已经存在的数据管线；新的部门也可以继续扩展同一张企业语义网络。

于是会出现一个非常关键的工程现象：

客户增加一个新需求，需要新增的代码和建模工作，理论上越来越少。

这才是所谓“越做越快”的技术基础。

如果每一个客户项目都有自己的数据库、自己的 Prompt、自己的 Python 脚本、自己的权限系统和自己的前端，那么无论团队在客户现场待六个月还是两年，交付成本仍然大体呈线性增长。

多做十个项目，大概率还需要更多工程师。

Palantir 想追求的模式，是让第十个 use case 更多建立在前九个已经形成的资产之上。

这也是平台公司和项目公司的分水岭之一。

三、更容易被忽略的，是组织上的复利

技术架构只能解决一半问题。

另一半来自组织设计。

2026 年，一位拥有 14 年经验的 Palantir FDE 在 Palantir Developer Community 里谈到 Forward Deployed Engineering 时，用了一个很准确的词：metabolize。

一线团队获得的经验，要持续被“代谢”进入核心平台。他同时强调，core product engineers、field teams 以及内部运营团队，都属于 Forward Deployed Engineering 这个整体循环的一部分。

这点对于国内很多所谓 FDE 团队尤其重要。

一个团队完全可能拥有很优秀的工程师，也真的和客户坐在一起解决了复杂问题，但组织结构决定了这些知识最终停留在哪里。

项目结束，群聊解散；

代码留在客户仓库；

关键设计存在某个工程师脑子里；

为客户临时补的能力没有进入平台 Roadmap；

下一个团队甚至不知道上一个团队解决过类似问题。

这种组织结构几乎不可能产生复利。

它最终更接近一种工程能力很强的 IT Services。

真正的 FDE 模式要求一线交付和核心产品之间存在极短的反馈回路：

客户问题 → 一线抽象 → 平台能力 → 下一个客户复用 → 新问题再次反馈平台。

如果这条链路断了，Forward Deployed 就只剩下 Forward。

四、AIP Bootcamp 更值得研究的，其实是“提前形成的转换成本”

这也解释了为什么 Palantir 的 AIP Bootcamp 是一个非常值得研究的商业设计。

Palantir 在 2023 年给出的定义非常直接：客户与 Palantir 工程师一起 hands-on-keyboard，在五天甚至更短时间里，从 0 做出真实 use case。今天 Palantir 的官方文档仍然把 Bootcamp 描述为与工程师共同工作，在数小时或数天内完成 use case。

表面看，这是缩短 POC 周期。

从架构角度看，它还有更深的一层含义。

当客户已经开始把自己的数据、业务对象、决策逻辑和工作流编码进 Ontology，双方实际共同建设的已经是一部分企业运行模型。

如果这种共建发生在长期采购决策之前，那么一种转换成本就可能提前出现。

以后换平台，要迁移的东西已经不只是几张数据表。企业还需要重新表达 Objects、Links、Actions、权限、数据管线，以及围绕它们形成的工作流。

这里需要保持警惕。

这种机制当然构成 Palantir 的商业护城河，但从采购方视角看，它同时是一种非常有效的技术锁定设计。

企业在评估此类平台时，不能只问“POC 多快”，还应该问另一个问题：

今天共同建模的这些企业语义，将来离开平台时如何迁移？

好的平台复利与供应商锁定，很多时候来自同一套技术机制。

五、长合同是结果，不能把因果关系倒过来

另一个常见误读，是把 Palantir 的长期客户关系归因于“长期合同”。

Palantir 在 SEC 文件中披露，其通常提供 1 至 5 年的合同，同时也存在更短期限，而且不少合同允许客户提前终止。

更值得关注的是客户扩张。

Palantir 的 Net Dollar Retention 在 2024 年中约为 114%，此后升至 2024 年 Q4 的 120%、2025 年 Q1 的 124%、Q2 的 128%、Q4 的 139%、2026 年 Q1 的 150%，到 2026 年 Q2 已达到 157%。换句话说，可以粗略理解为近两年从 115% 附近一路上升到 157%。

NDR 本身当然无法证明 Ontology 是唯一原因。

但它至少揭示了 Palantir 商业模式的一个重要特征：大量增长发生在已经进入平台的客户内部。

客户先做一个场景，底层对象和数据开始被建模；随后增加第二个部门、第三个工作流、更多 Actions 和 AI use cases；随着平台逐渐成为运营基础设施，继续合作和扩大合同自然更合理。

因此，长周期合同更应该被理解为平台复利之后出现的商业结果。

如果一家“FDE 公司”主要依靠签三年框架合同、增加驻场人数来提高客户收入，它复制的是大型 IT 外包公司的经营模型。

真正需要观察的指标，是同一客户的第二个需求是否明显比第一个更容易交付，第三个是否继续更快。

六、还有一个容易混淆的概念：AI FDE

这里还需要澄清一个术语。

传统的 Palantir FDE 是人类工程师角色。

Palantir 后来又发布了名为 AI FDE 的产品：它在 2025 年 11 月进入 beta，并于 2026 年 3 月 12 日正式 GA。

AI FDE 是运行在 Foundry 里的 AI Agent，可以通过自然语言执行数据转换、管理代码仓库、创建和修改 Ontology、编写 Functions，以及操作其他 Foundry 能力。

两者不要混为一谈。

但 AI FDE 的出现反而进一步说明了前面的逻辑：当企业的数据、对象、Actions、权限和工作流已经统一存在 Foundry 中，很多过去需要人类 FDE 操作的平台工作，才有条件被 Agent 自动化。

AI FDE 的能力边界，本质上继承自前面已经完成的平台化建模。

七、中国公司要判断自己有没有在做 FDE，可以问六个问题

所以，与其给解决方案工程师换一个更时髦的 Job Title，不如检查下面六件事：

1. 所有客户项目是否建立在同一套核心平台架构上？ 如果每个项目最终都是独立代码库，首先要警惕。

2. 团队有没有持续抽象业务对象、关系和 Actions？ 完成功能只是第一层，形成可复用业务模型才会产生后续价值。

3. 同一客户的第二个 use case 是否显著更快？ 如果每新增一个需求仍然需要近似规模的人天，平台复利还没有发生。

4. 跨客户问题能否沉淀成平台能力？ 可以沉淀数据连接器、权限能力、工作流框架和通用组件，但需要严格区分客户私有业务语义与真正可产品化的能力。

5. FDE 和核心产品团队之间有没有制度化反馈机制？ 如果经验只能沉淀在个人，组织没有获得任何复利。

6. 是否能同时解释自己的客户锁定机制和退出机制？ 平台越深入业务，转换成本越高。成熟的企业级 AI 公司应该同时考虑数据可迁移性、模型可替换性和业务逻辑的可解释边界。

真正值得中国 AI 公司学习的，其实并不是“派一个既懂业务又会写代码的人去客户现场”。

那件事，咨询公司、SI 和软件外包公司几十年前就在做。

Palantir 更值得研究的地方，在于它试图把每一次客户现场的复杂性，逐渐转化成平台内部可以重复调用的结构。

客户越来越深，平台越来越厚；平台越来越厚，下一个需求越来越便宜。

当这条循环真正建立起来，Forward Deployed Engineering 才开始从一种高成本交付方式，变成一种能够产生复利的平台建设机制。

所以，下次再听到一家公司说自己正在组建“FDE 团队”，真正值得问的也许只有一句：

这些 FDE 做完一个项目之后，你们的平台究竟多了什么？