今天是 2026年7月14日，跟大家分享一下最近的研究。
Palantir 手里有几个看起来很装逼的词：Ontology（本体论）、FDE（前沿部署工程师）。它们到底是换汤不换药，还是真有东西？
几个数字，和一个问题
最近在研究 Palantir。下面的内容是我个人的理解，主要事实和数据尽量附了来源，结论部分是我自己的判断。
几份研究的数字都不好看。RAND 2024 年的报告引用估计称超过 80% 的 AI 项目会失败（报告原文用的是 “by some estimates”，这个数字本身是个估计值）。MIT Media Lab Project NANDA 2025 年的 v0.1 初步报告（未经同行评审）发现，定制化企业 GenAI 工具中绝大多数未带来可衡量的损益影响。IBM CEO Study 的调查里，仅 16% 的 AI initiatives 实现了企业范围规模化。
这几项研究的对象、年份、口径都不一样，不能当成同一件事。但方向一致：AI 从试点走向规模化运营，存在困难。
Palantir 的公开客户名单里有 Airbus、bp、Merck、摩根士丹利、法拉利。这些公司在各自行业里不是小角色。让我感兴趣的不是某个具体数字，而是 Palantir 在数据整合和企业级部署方面确实有实战经验。
一边是这些失败信号，一边是 Palantir 的客户名单。我心里冒出一个问题：模型这一层，GPT、Claude、Gemini 谁都能通过商业服务调用。那差距更可能出在别的地方。我猜测大概率在交付方式上。
下面是我研究后的理解。
软件变了，但交付方式还没跟上
要理解 Palantir 为什么搞出 Ontology 和 FDE，得先退一步看一件事：软件本身的形态变了。
我把软件演进分成四个阶段。这是我自己整理的框架，不一定严谨，但帮我理清了思路。
| 阶段 | 业务逻辑固化在哪里 | 用户怎么改系统 |
|---|---|---|
| 定制信息化系统 | 程序代码 | 提需求、改代码、重新发布 |
| SaaS 产品 | 标准功能与参数 | 开关功能、调参数、配权限 |
| BPM / 低代码平台 | 流程模型、表单和规则 | 拖拽流程、配置规则、搭应用 |
| AI 原生平台 | 目标、本体、工具、策略与 Agent | 描述目标，Agent 动态规划并执行 |
前三个阶段有一个共同点：系统的逻辑主要由预先定义的代码、配置和流程决定。需求来了，设计、编码、配置、发布、运行。SaaS 和 BPM 也有运行时的分支和规则引擎，但核心流程是人在设计期想好的。
到了 AI 原生这一阶段，事情变了。一部分业务逻辑不再在设计期固化，被推迟到了运行时。一个目标进来，Agent 先理解当前情境，动态制定计划，选数据和工具，平台检查权限和风险，执行动作，根据结果再调整。需要说明的是，工具定义、权限边界和安全策略这些是平台预先设定好的；Agent 在运行时动态生成的，是计划怎么走、什么时候调用哪个工具，权限本身不会被 Agent 凭空创造。
这个变化很大。但我观察到的一些做法，还在用第二、三阶段的方式做第四阶段的事。用卖 SaaS 的方式卖 AI，用做低代码的方式做 Agent。模型一上来就堆，提示词一塞就上线，出了事再补规则。
RAND 访谈了 65 名从业者，列出的失败原因包括五类：问题定义错误、数据不足、盲目追新技术、基础设施不够、任务超出 AI 能力。交付方式只是其中一环。不过在我看来，方法论错位是一个被低估的因素。你拿盖砖房的方式去盖一栋会自己变形的房子，盖不起来。
运行时动态规划这件事，我归纳出三个问题，每个都得有对应的解法：
- AI 在什么业务世界里行动？ 这架飞机到底是哪一架，这个订单关联了哪些客户，这个动作碰没碰到权限边界。这是 Ontology 要解决的。
- 平台能力怎么真正进到客户现场？ 平台再通用，每个客户的组织、数据、流程都不一样，必须有机制把能力适配进去。这是 FDE 要解决的。
- 动态生成的行动，怎么被权限和确定性系统控制住？ Agent 当场做出来的计划，不能直接就执行，得有人画边界、有系统兜底。这是确定性平台要解决的。
下面三章，分别讲这三个问题。
第一个答案：Ontology，AI 在什么业务世界里行动
先说 AI 在什么业务世界里行动。
Ontology（本体论）这个词最容易让人犯怵，因为大学哲学课里有个”本体论”，研究存在本身。但 Palantir 在这里讨论的不是哲学问题，而是 ontology 在知识工程中的工程化用法。Akshay Krishnaswamy（Palantir）在一次公开活动上说：“The Ontology is the substrate through which humans and AI work together to create operational value — rooted in your business.” 我的意译是：Ontology 是人和 AI 在你的业务里一起干活、产生运营价值的那层底座。
我对这句话的理解是：企业里有系统、有数据、有流程，但这些东西散在各个角落。Ontology 把它们映射成一个统一的、机器和 AI 都能理解的数字模型。飞机、订单、客户、交易、审批，每一个都变成模型里的对象。对象之间有关系，关系上有规则。
Ontology 里面有哪两类元素
Palantir 官方文档把 Ontology 的组成部分分成两大类：
语义元素（Semantic elements）：objects（对象）、properties（属性）、links（链接）。Objects 对应业务世界里的实体，飞机、订单、客户都是对象。Properties 是对象的属性，Links 是对象之间的关系。数据源被映射成这些语义元素。这一层让不同团队用同一种语言说话。财务部说的”客户”和运营部说的”客户”，指的是同一个对象。
动能元素（Kinetic elements）：actions（动作）、functions（函数）、dynamic security（动态安全）。Actions 定义了可以对对象执行什么操作，functions 是可执行的逻辑，dynamic security 控制谁能做什么。有了这一层，Ontology 才从静态模型变成活的系统。
这两类元素合起来说明一件事：Ontology 是一套连数据、带规则、能驱动的活系统。共享的 Ontology 可以减少不同应用重复定义对象和数据关系的工作。
Palantir 在官方博客里用一张图概括了 Ontology 怎么把决策拆成四个部分：
图片来自 Palantir 官方博客 Connecting Agents to Decisions
Onyx 案例：Ontology 怎么端到端工作
要看 Ontology 怎么端到端工作，Palantir 官方博客里有一个演示案例：Onyx，一家虚构的医疗设备制造商，碰上供应商中断、原材料短缺的场景。这个演示是目前能找到的最完整的 Ontology 工作方式说明。
Ontology 在这个场景里做了四件事：
数据：供应商、仓库、生产、配送、客户履约等全部整合成语义对象，运营负责人几步就能定位受影响的生产线和订单。
逻辑：预测模型和优化器连接进 Ontology，一个叫 Disruption Bot 的 Agent 找到了分析师没想到的新方案。
行动：Agent 的方案不直接执行，暂存为场景交人工审核，通过后才写回 ERP 和仓库系统。
安全：敏感数据自动隐藏，Agent 的查询、建议和执行权限被精确控制。
图片来自 Palantir 官方博客 Connecting Agents to Decisions。
案例展示了 Ontology 怎么把数据、逻辑、行动和安全串成闭环。真实客户的实现细节没有公开。
真实客户在怎么用
下面几个案例的成效数字，都是客户或 Palantir 自己在演示和报道里给出的，没有独立审计。
- American Airlines：在 Foundry 上建了叫 Vector 的航线网络规划系统，把航班时刻表和网络规划放进同一个 Ontology。美航运营副总裁 Anne Moroni 在 Palantir AIPCon 8（2025 年 9 月客户大会）上演示，称采用第一年带来数千万美元（tens of millions of dollars）的价值（AIPCon 8 演示）。
- Vantage Edge（陆军竞赛）：陆军办了一个叫 Vantage Edge 的比赛，200 多名士兵、文职和技术员在 Vantage 平台上 3 天内搭出了实际方案。陆军 AI 顾问 Maj. Zak Daker 在陆军官网（army.mil 原文）上说，编程背景参差不齐的人在不到 72 小时里完成了构建。部分方案未完整构建，可以用 PPT 或白板展示；优胜方案赛后进入 Beta。
- Novartis：在 Foundry 上建了叫 Data42 的研发数据平台，整合了覆盖 7 亿 patient lives 的真实世界数据（Birgit Schoeberl 的原话，这个口径不等于 7 亿名去重患者）和约 3000 个临床试验。诺华 Data42 负责人 Birgit Schoeberl 在 AIPCon 8 上演示，药物剂量预测从约一周压缩到约两小时，近 100% 的小分子项目在用（AIPCon 8 演示）。
- Andretti Global：在 Foundry + AIP 上建了叫 RaceOS 的赛车运营系统，把遥测、天气、轮胎、车手反馈放进一个 Ontology。Palantir 官方博客写的是赛后数据处理和分析从”数小时或数天”缩短到”几分钟”（Palantir 博客）。车手 Kyle Kirkwood 说 “The software is almost as fast as I am.”
这些案例的 Ontology 实现细节没有完全公开。美航、诺华和 Andretti 有运营使用的证据；陆军竞赛方案当时还在 Beta。
Ontology 解决的是哪个问题
Ontology 是给 AI 提供结构化业务上下文的一种方式。有了它，AI 看到的是一个有类型、有关系、有规则的对象，它知道”这架飞机”具体是哪一架，关联了哪些维护记录，当前处于什么状态。没有这类结构化上下文的时候，AI 只能从文本里推断业务事实，出错的概率更高。
Palantir 官方博客里把 Ontology 的作用收在一句：“The Ontology provides the guardrails needed for AI to safely take action within permitted boundaries.” 本体论为 AI 的安全行动提供了护栏。护栏这个词重要，AI 不是什么都能干的，让它能在允许的范围内安全行动，需要有人事先把边界画好。
回到开头那个问题：AI 在什么业务世界里行动？Ontology 给出的答案是，在一个被建模成对象、关系、规则的业务世界里行动。它在 Palantir 架构里是基础层，我个人认为这种结构化上下文是 AI 安全行动的前提。
第二个答案：FDE，把能力 Deploy 到现场
Ontology 解决了 AI 在什么业务世界里行动。但光有这一层还不够，还得有人把这些能力带进客户现场。Palantir 的第二个答案叫 FDE（Forward Deployed Engineer，前沿部署工程师）。
FDE 是什么
Brian 是 Palantir 的一名 FDSE（FDE 在内部叫 Delta），他在公司官方博客 “A Day in the Life of a Palantir Forward Deployed Software Engineer” 里给的定义：“A Forward Deployed Software Engineer (FDSE), or ‘Delta,’ is a software engineer who embeds directly with our customers to configure Palantir’s existing software platforms to solve their toughest problems.” 直接翻译：嵌入到客户现场，配置 Palantir 现有平台，解决客户最难的问题。
Palantir 的前线部署不只涉及一种角色。公开资料至少能确认两类：
Deployment Strategist（内部叫 Echo）：领域专家，通常来自客户的行业，比如军人、医生、金融分析师（FDE Academy 二手概括）。他们知道业务问题在哪，能看到技术能在哪里创造价值，是客户和工程团队之间的桥梁。名称对应来自前 Palantir 员工回忆。
FDSE（另一称呼 Delta）：执行导向的工程师，在不确定条件下快速迭代，优先解决客户问题，同时仍需遵守代码评审、测试和生产监控等工程实践。Brian 就是 Delta。（Palantir 官方博客）
在一些部署项目中，两类角色会配合工作。FDE Academy 把这种组合形容为客户环境里的微型创业团队。
有二手资料把这种现场方案产品化的循环概括为”碎石路到铺装公路”（gravel road to paved highway）：
- Delta 在客户现场快速开发粗糙方案（碎石路），快、务实、解决眼前问题
- 核心工程团队研究这些方案，在不同客户之间找共性
- 把共性固化成标准产品功能（铺装公路）
- 新功能发布后惠及所有客户
- Delta 继续去找下一个问题
一位前 Palantir 员工写过：FDE 在现场的工作本质上是在做研发（R&D），不应按单个客户核算的收入成本（COGS）。单个客户部署可能亏钱，因为它的价值不在这个客户身上，而在于现场方案里跑出来的东西，哪些能被工程团队提炼成产品功能。据前员工 Barry 回忆，Foundry 本身就是这么长出来的，不同城市的客户现场，一个一个方案积累出来的。这是他个人对这类投入的理解，不代表 Palantir 财报中的实际会计归类。
Brian 的经历正好说明 Delta 怎么工作。他是硬件工程背景加入 Palantir，被直接投入网络安全项目（之前没有相关经验）。他需要学 Foundry 的网络安全功能，发现客户特定的技术挑战并解决，借助 mentors 和团队成员一起推进。后来还参与了 COVID-19 响应项目，几天内部署并运行。他形容自己的核心体感：“rapid cycle between creating solutions and seeing them in action”，创造方案和看到它生效之间的快速循环。
FDE 在平台结构里配置什么、复用什么
现场方案要变成产品功能，得有平台可以承接。FDE 在一个已经搭好的平台结构上做客户差异化配置。这个平台结构我在下一章会完整展开（七层），这里先说 FDE 在这个结构里干什么。
按我的框架推演，第一个客户可能需要配置整套平台能力：业务本体、系统连接器、Agent 工具、策略和审批、行业知识、评测集、运行指标。
按我的推演，第二个客户开始，平台和 Agent 运行时可能不用重写，FDE 可能只需要替换：组织和数据映射、客户系统接口、权限与业务规则、少量行业差异。
如果现场到产品的反馈循环跑通，FDE 交付的就是可复用的平台能力。理论上边际成本会随客户数下降。
其他模型公司也在补部署能力
FDE 这套模式不是 Palantir 独有。OpenAI 在组建类似的部署团队。Anthropic 也通过合作伙伴（比如 DXC）扩展部署能力。
MindStudio 在一篇分析里写过一句话：“The deployment gap swamps the capability gap in practice.” 部署鸿沟在实践中远大于能力鸿沟。这句话我觉得说中了 OpenAI 和 Anthropic 组建这类团队背后的逻辑。
我的理解是，模型这一层的获取门槛降低了，GPT 和 Claude 这类主流模型通过商业服务就能调用。但”能调用”不等于”够用”，模型在准确率、成本、延迟、可靠性和领域能力上仍然可能是瓶颈。RAND 报告里”任务超出 AI 能力”就是这类。不过在部署侧，瓶颈同样明显：把模型能力真正部署到企业前线、变成日常运营的能力，这件事的难度容易被低估。
FDE 这个模式的陷阱
这里有一个需要说清楚的区分。Palantir 早期做 FDE 的时候，Foundry 还不存在。据前员工回忆，他们把顶级工程师派到客户现场，用高成本的方式试错，大部分项目失败了，但成功的那些逐渐长成了 Foundry 平台。这是一种用现场团队做产品探索的模式，成本极高。
Foundry 成熟后，产品部署型任务占了更重要的位置：FDE 更多是在已有平台上适配客户环境，同时继续把现场发现反哺产品。这是产品已经存在之后的部署型 FDE。
Palantir 早期那种用大量现场试错孵化产品的模式，需要顶级招聘标准、巨额预算和承受大量失败的能力，我暂时复制不了。
Thomas Otter（前 SAP，现投资人）在他的 Substack 上写过一篇批判性的文章。他认为 FDE 本质上就是技术实施顾问，Palantir 只是换了个名字。从财务角度看，如果 FDE 的工作向客户计费，那就是咨询收入；如果不计费，就是收入成本，不该算研发。他提了一个长期风险：如果 FDE 与产品工程师比例过高，公司看起来更像 AI 咨询公司而非产品公司。“几年后你会发现有几十个项目但没有多少标准产品。“需要说明的是，Otter 在文章里明确说他没有调查 Palantir 具体怎么核算这些岗位的成本和收入，所以他的财务判断是一般性原则，不是针对 Palantir 的调查结论。
把 Otter 的批判和我自己的判断放在一起：产品部署型 FDE 的价值在于把核心产品的能力适配到客户环境，同时把现场经验反哺回产品。但这个模式成立的前提是，你已经有核心产品，而且工程团队能从现场方案中提炼出标准功能。两个条件缺一个，FDE 就会退化成项目外包。
下面一章讲，为什么光有 Ontology 和 FDE 还不够，还得有一套控制 Agent 行动的机制。
AI 行动的边界在哪
Palantir 在 2026 年的官方博客 Connecting Agents to Decisions 里，把 data、logic、action、security 全部纳入 Ontology 的范畴。所以严格来说，下面讨论的控制机制在 Palantir 的产品架构里属于 Ontology 的一部分。我这里把它单独拿出来讲，是因为不管它叫什么，AI 行动的控制机制都是落地时必须面对的问题。
我看到的一些 AI 项目把 AI 原生简化成”大模型 + 提示词”。把业务逻辑塞进提示词，让大模型去理解，就能跑起来。
这个理解对了一半。
提示词的边界
提示词适合表达的东西：当前目标、任务背景、分析方法、输出要求、临时约束、异常处理思路。这些是软的、情境性的、可以随时调整的。
但有一类东西，不能只靠提示词：身份与权限、财务规则、密码与密钥、数据访问边界、强制审批、合规要求、风险阈值、高危动作限制、审计和责任认定。
原因有三个：模型输出是概率性的，同一个提示词在不同上下文里效果可能不同；prompt injection 是攻击者利用模型无法可靠区分可信指令和不可信输入来实施攻击；模型对规则的理解没有保证，可能遗漏或偏离。
你不会把银行转账规则写在提示词里然后指望模型每次都遵守。你也不会把”谁能看哪些数据”这种权限问题交给大模型自由发挥。
三元结构：行动权、控制权和责任怎么分
基于这个判断，我梳理了一个三元结构：
Agent 负责：理解、分析、规划、建议、异常处理
确定性系统负责：身份、权限、规则、审批、交易、执行、安全
人 负责：目标、边界、关键决策和最终责任我的思路是：Agent 动态生成执行计划，确定性平台负责验证和执行。
Agent 擅长理解模糊意图、拆解复杂任务、在多个选项里做判断。但 Agent 不擅长、也不该被信任去做的事情是：执行不可逆的高危动作、绕过权限、自行决定风险阈值。
确定性系统负责的就是这些。它不聪明，但行为更可预测、可审计，可以被设置为强制控制。审批流程、权限校验、交易执行、安全控制，这些被写死在系统里。
人负责的是目标和责任。系统的目标是什么、边界在哪、出了事谁担责，这些是人的事，不能甩给 Agent。
回到开头说的第三个问题：动态生成的行动，怎么被权限和确定性系统控制住。我梳理的这个三元结构把行动权、控制权和责任拆开，分别交给 Agent、确定性平台和人。
Palantir 官方博客里画了 Ontology 怎么控制 Agent 的行动：动作可以暂存为场景，经过审批后写回系统，全程有日志和权限管控。
图片来自 Palantir 官方博客 Connecting Agents to Decisions
七层平台，是实现三元分工的组件
把这个三元结构落到系统里，拆成了七层：
- 业务本体：定义人员、客户、订单、设备、任务、文档、事件之间的关系。对应 Palantir 的 Ontology。
- 工具与连接器：把查询、审批、派单、付款、发消息、控制设备等能力开放给 Agent。
- Agent 运行时：目标理解、任务分解、工具选择、记忆和多 Agent 协作。大致对应 Palantir 的 AIP（AIP 的范围实际上更广）。
- 策略控制平面：判断哪个 Agent 在什么条件下可以调用什么工具。
- 确定性工作流：审批、交易、安全控制等强制执行的流程。Foundry 的 Workflows 提供了部分流程编排能力。
- 评测与可观测性：记录 Agent 为什么这样判断、调用了什么、结果如何。
- 人工控制：审批、纠错和暂停。公开资料能确认 Palantir 支持权限控制、操作日志、动作暂存和人工审核；暂停、回滚和紧急终止的完整能力没有在公开资料中逐一证实。
这七层是我自己拆的框架，不是 Palantir 官方架构。七层是三元结构的实现组件：业务本体是 Ontology 那一层，给 Agent 划定行动的世界；Agent 运行时是 Agent 那一元；策略控制平面、确定性工作流、人工控制，合起来就是确定性系统加人那一元。提示词只是这个七层平台的一个输入接口，你跟系统说话，系统理解你的意图，但真正决定系统能不能安全、可靠、有效地行动的，是底下的六层。
研究到这里我有一个感受：只做大模型和提示词的 AI 平台，等于只搭了 Agent 那一元。上面没有业务本体，Agent 不知道在什么世界里行动；下面没有确定性工作流和人工控制，Agent 的动作没有兜底。
平台壁垒也变了
我以前觉得衡量一个平台，看它有多少功能就行了。AI 原生时代，衡量标准变了：理解多少业务对象、连接多少真实工具、控制多少关键动作、积累多少运行反馈、能否安全地让 Agent 行动。
这些才是新的壁垒。按我的七层框架去对应，Palantir 的公开产品覆盖了其中多个层面，不止做了一个产品。这是它跟市面上一些 AI 平台不一样的地方，我没有做严格的竞品对比，不敢说是跟所有 AI 平台的差别。
卖的东西也变了
以前卖的是一套系统、一个模块、一个账号、一次项目。
以后可能卖的是一个平台 + 若干 Agent + 若干可执行工具 + 行业任务包 + 持续运营服务。客户增加新场景时，有机会在原平台上扩展 Agent、工具和任务包，减少另建系统的需求。
总结
我个人的判断是，程序员的核心价值在抽象、判断和行业经验，写代码这个动作本身越来越不构成壁垒。这种能力在 AI 时代反而更稀缺。
回到标题那个问题：Ontology 和 FDE 是不是 Palantir 故弄玄虚的概念？
我对这个问题的回答分散在前面的内容里。Ontology 有工程实质，不是空概念。但 Ontology 跟知识图谱、语义层、数字孪生有多少重叠，FDE 跟技术实施顾问有多大本质区别，Palantir 没有给出比较，我也没有足够的信息下结论。能说的是：这些概念背后有真实的工程内容，不是纯粹的名词包装。至于有多少是新东西、多少是旧方法换了名字，这个问题比这篇文章能回答的要大。
但复制它的起点，是先想清楚自己的核心产品是什么，光抄一个角色名字没有用。
它主动寻找的是规模大、执行难、失败风险高的问题，因为这种问题：
- 普通 SaaS 解决不了；
- 客户自己开发经常失败；
- 一旦 Palantir 成功进入，就会不断扩张；
- 客户独特的业务逻辑会沉淀到 Ontology，形成极强黏性。
所谓 Forward Deployed Engineering，也不是普通“驻场实施”。它是研发机制：工程师进入真实运营环境，把客户任务反向传播给平台产品。
Palantir 官方甚至把它形容为“人类版本的反向传播”。
我现在还在学习和摸索的过程中。我的产品长什么样、团队怎么组织、第一个客户怎么选，这些问题我还没有答案。
但至少，我知道了该往哪个方向想。
