← 返回入门百科
GUIDE / 05

Palantir 的 FDE 模式拆解

14 分钟阅读

Palantir 的 FDE 模式拆解

阅读约 14 分钟 · 入门百科 05

要理解今天所有公司都在抄的 FDE 模式，必须回到它的原点：Palantir。这家公司花了二十年，把"派工程师进驻客户现场"这件看起来又重又笨的事，做成了数千亿美元市值的根基。它的打法值得逐层拆开看——包括它不愿意多讲的部分。

起源：从反欺诈软件到"进驻式"交付

Palantir 成立于 2003 年，核心班底来自 PayPal 的反欺诈团队，早期投资方包括 CIA 旗下的风投 In-Q-Tel。它最早的客户是情报机构：分析师面对海量碎片数据，需要工具帮他们"把点连成线"。

这个客户群决定了 Palantir 的命运。情报和国防客户有两个铁律：数据不能出门，业务不能外包给不理解场景的人。于是 Palantir 没有选择——只能让工程师进门。这就是 Forward Deployed Software Engineer（FDSE，前置部署软件工程师）的由来：不是销售带着 PPT 去，而是工程师带着键盘去，坐在分析师旁边，现场把数据接进平台、现场改产品。

2009 年，这套打法被复制到商业世界：Palantir 在摩根大通一家客户内嵌入了约 120 名工程师[^1^]。在当时的外界看来这是不可理喻的重资产——但 Palantir 内部有个清醒的判断：对这些客户，部署工作本身就是产品。软件在对方真实业务里转起来，才是收钱的原因。

双层编制：FDSE 与部署策略师

Palantir 的一线交付不是单一角色，而是两层配合：

  • 部署策略师（Deployment Strategist，DS）：偏业务侧。泡在客户组织里，搞清楚谁痛、痛在哪、哪个问题值得用技术解决，也负责客户关系和商业推进。可以理解为"懂技术的咨询顾问 + 客户经理"。
  • 前置部署软件工程师（FDSE）：偏工程侧。把 DS 定义出的问题变成运行在 Foundry / Gotham 上的真实系统——接数据、写管道、建应用，代码直接进客户生产环境。

这个分工解决了一个经典矛盾：纯工程师容易埋头做出没人用的系统，纯顾问容易卖出交付不了的方案。DS 负责"做对的事"，FDSE 负责"把事做对"，两层互相制衡。今天 AI 公司的 FDE 团队大多把两职合一（一个人既谈业务又写代码），但资深的团队里仍能看见这个分工的影子。

平台化：让"重交付"产生复利

如果 Palantir 只是把人派出去，它最多是一家高端外包公司。真正的杀招在于：每次交付的成果都沉淀回平台，让下一次交付更快、更便宜。

支撑这个复利的有两件事。一是 Gotham（政府线）和 Foundry（商业线）两个平台，把数据接入、权限、管道、应用构建做成了可复用的底座——FDE 在客户现场做的是"在平台上装配"，而不是从零造轮子。二是后来被反复提及的"本体"（Ontology）层：把客户业务里的对象（订单、设备、工单）和动作抽象成统一的语义层，使一个行业的解决方案可以迁移到同行业下一家客户。

效果体现在财报上：Palantir 的销售周期和单位交付成本逐年优化，新客户的起步越来越像在既有平台上"开机"，而不是重新交付。这就是 FDE 模式与外包 economics 的分水岭——外包的成本随客户数线性增长，平台化 FDE 的边际成本递减。

方法论：Audit → Evals → Deploy

AI 时代的 FDE 团队（包括 OpenAI 在内）普遍沿用了一个三段循环，其精神源头仍是 Palantir[^1^]：

  1. Audit（摸清现状）：看一线真实的工作流，而不是文档里的流程，产出"现状 vs 引入 AI 后"的业务地图；
  2. Evals（建立评测）：用真实案例 + 人工标注攒出黄金数据集，把"系统好不好"从口水仗变成通过率；
  3. Deploy（渐进上线）：沙盒起步，评测站住就放开一分自主权，全程监控。受监管行业从试点到信任要四个月以上——这是设计，不是拖延。

Palantir 的原版里没有 Evals（那是大模型特有的不确定性带来的），但"先证明、再扩权"的逻辑一脉相承。

为什么 2025 年之后全行业开始抄作业

2026 年 5 月是标志性的：Anthropic 宣布成立企业服务合资公司，八天后 OpenAI 通过收购 Tomoro 组建"部署公司"，配备约 150 名 FDE 和交付专家，客户名单包括惠普、Intuit、甲骨文、State Farm、Uber[^1^][^2^]。埃森哲、EPAM 这样的咨询巨头也在同月与 Anthropic 成立联合交付团队。高盛高管公开用"民主化"形容这波操作[^2^]。

抄作业的逻辑很直白：当模型能力趋同，交付能力就是差异化。API 谁都能调，但"把模型装进一家保险公司的真实流程并让它稳定创造价值"这件事，供给严重不足。a16z 干脆把 FDE 称为 AI 时代的商业模式而非岗位。OpenAI 自己的 FDE 团队一年内从 2 人扩到 39 人，且刻意保持小团队——只接"值得真实企业预算的问题"[^1^]。

批评与局限：Palantir 不讲的另一半

公允起见，这个模式有三个已知的软肋：

  1. 毛利压力。 再平台化，人还是要派出去的。Palantir 早期被质疑"本质是咨询公司"，直到近几年平台收入占比和经营利润率上来才翻身。抄作业的公司如果没有平台底座，很容易抄成一家烧钱的交付公司。
  2. 规模天花板。 OpenAI 把团队控制在 39 人是清醒还是无奈，见仁见智——优秀 FDE 的供给增长远慢于需求，这是整个模式的瓶颈[^2^]。
  3. 锁定争议。 深度嵌入客户业务 + 私有本体层，带来的客户粘性同时也是"供应商锁定"的指控来源。这对采用方是个真实考量，对企业甲方而言值得在签约前想清楚退出机制。

对中国的启示

Palantir 模式证明了一件事：在高复杂度、高敏感度的市场里，"重交付"不是缺陷，而是壁垒——前提是它有平台底座承接复利的产出。这个前提，恰恰是大多数中国 to B 公司缺的那块板。中国市场的特殊性（付费习惯、项目制预算、集成商生态）决定了 FDE 模式落地时必然变形，这是我们下一篇的主题：《中国企业需要 FDE 吗？》。

参考资料

[^1^]: Palantir 在 JPMorgan 的编制、OpenAI 部署公司与 FDE 方法论循环，见 https://www.ayautomate.com/blog/forward-deployed-engineer-business-model [^2^]: OpenAI / Anthropic 交付实体、高盛评论、JD 市场扫描，见 https://dexity.com/intel/fde-bottleneck-2026