所有想做 FDE 的人，都该读懂 Palantir 这套方法

📝 摘要 #

本文深入解析 Palantir 的 FDE（Forward Deployed Engineer）方法论，核心是 Ontology——将企业的数据、规则和权力关系翻译成机器可计算、员工可操作、管理者可治理的业务模型。文章指出，大模型进入企业后最难的一步是将隐性知识（Polanyi 的 tacit knowledge）和情境行动（Suchman 的 situated actions）变成 AI 能理解并安全执行的系统。Palantir 的 Ontology 不仅是语义层，还包含动力元素（Action Type、函数、动态安全机制），形成三层架构：数据层→业务对象层→应用/Agent 层。文章通过 Tampa General Hospital 床位管理（安置时间下降 83%）和 Jacobs 水处理厂运营优化（全厂电力节省约 20%）两个案例，展示了 Ontology 在真实系统中的落地形态，并对比了自上而下与自下而上两条建设路线，提出"从一个决策反推系统"的务实起点。

核心概念： Palantir 的 Ontology 是企业的 operational layer，不仅表示"世界有什么"（语义元素），还规定"怎样改变世界"（动力元素），是 AI Agent 进入生产系统的前提条件。

关键技术栈 / 关键要点：

1. 隐性知识外化 — FDE 的核心任务是将组织的隐性知识变成可执行、可修改、可审计的外部结构
2. Ontology 三层架构 — 数据层（连接清洗）→业务对象层（对象/属性/关系/动作）→应用/Agent 层（查询执行）
3. 动词比名词更难建模 — 企业依靠 Action Type 运行（创建订单、批准折扣等），每个动词带前置条件和后果
4. 决策闭环 — 实时数据→模型建议→操作员决定→结果反馈，Ontology 承担共同状态
5. 自上而下 vs 自下而上 — 前者上限高但启动重，后者速度快但可能积累局部记忆；务实起点是"一条可衡量的决策闭环"
6. AI FDE — 2026 年 3 月 Palantir 发布 AI FDE，用自然语言完成数据转换和 Ontology 编辑，但治理设计保留人工审批和审计日志
7. FDE 五问框架 — 从运营结果出发反推：做什么决定→依赖哪些对象→哪些约束→人机如何共享控制权→结果如何返回系统

关键结论 / 实践建议： FDE 离开客户现场时，留下的不应只是几张仪表盘，而是一套可以继续运行、继续学习、允许人安全接管的系统。Agent 降低了建模成本，但没有消除业务判断——Ontology 从一次大型工程，逐渐变成一项持续维护的组织能力。

---

大模型进入企业以后，最难的一步是把一家公司的数据、规则和权力关系，变成 AI 能够理解并安全执行的系统。

2026 年 5 月，OpenAI 成立了一家专门负责企业部署的新公司。它准备投入超过 40 亿美元，并计划通过收购 Tomoro，一次带入约 150 名 Forward Deployed Engineers 和 Deployment Specialists。OpenAI 在公告里把任务写得很具体：这些人要进入客户组织，和管理者、一线操作人员共同重做关键流程，再把模型接到客户的数据、工具、控制机制与业务流程上。

一家拥有前沿模型的公司，开始重金建设现场交付能力。模型进步没有消除部署，反而让部署承担了更多责任。AI 从回答问题进入生产系统以后，它会修改订单、分配资源，也可能触发一连串真实后果。

Palantir 很早就把工程师派进客户现场，并长期使用 Forward Deployed Software Engineer 这一职位。许多人把这套模式概括成“懂代码、懂业务、能驻场”。这个概括抓住了人的能力，却漏掉了工程师需要留下的系统资产。

Palantir 的方法要求团队把一家公司翻译成一种机器可计算、员工可操作、管理者可治理的业务模型。它给这层模型取了一个学术味很重的名字：Ontology，本体。

理解这套方法，比背下一份 FDE 职位说明更有用。

数据库里没有一家公司 #

设想你刚进入一家制造企业。销售负责人走过来，说：“这个客户很重要，先从别的仓调一批货过去。”

人类员工会在脑中补齐很多信息。他知道“这个客户”对应哪家法人主体，知道“重要”来自合同等级还是老板的临时判断，也知道哪些仓库不能动、哪类调拨需要审批。数据库里可能已经存在客户、库存和订单数据，却不会自动给出这句话在当前公司的完整含义。

你把数据库直接交给大模型，它能看到 customer_id、sku、warehouse_code 和 available_qty。它仍然需要解决另一组问题：

• 订单和客户属于什么关系；
• 库存是账面数量，还是扣除锁定量后的可调数量；
• 调货会不会破坏其他交付承诺；
• 谁能发起，谁能批准，结果要写回哪些系统。

老一代 BI 和数据中台没有把这个矛盾暴露得如此明显。它们把清洗后的数据交给人，员工用自己的经验完成最后一段解释。现在，Agent 要亲自参与行动，公司必须把这段解释放进系统。

哲学家 Michael Polanyi 在 1966 年出版的《隐性维度》中提出一个判断，知识管理研究后来反复引用它：人所知道的，常常多于他能够完整说出的。员工会处理订单异常，不代表他能在一次访谈里列完判断规则；护士长会调配床位与班次，也不代表医院已经把她的判断写进信息系统。

Lucy Suchman 在《Plans and Situated Actions》中进一步指出，人的行动依赖现场情境，计划无法提前规定工作中的每一个分支。真实流程会遇到缺货、设备故障、客户改期和临时授权。员工根据眼前局面调整，再在事后用制度语言解释发生了什么。

这两项研究解释了 FDE 为什么必须进入现场。企业知识分布在制度、软件与人的经验里。会议纪要只能提供声明过的流程，实际工作才能暴露例外、冲突和权力边界。

FDE 面对的任务可以写成一句话：把组织的隐性知识变成一套可执行、可修改、可审计的外部结构。

Palantir 所说的 Ontology，比“语义层”多了两件事 #

计算机科学家 Thomas Gruber 在 1993 年把 ontology 定义为对某个共同概念体系的明确规格。一个领域里有哪些类别、关系和函数，参与者使用什么共同词汇，都可以写进 ontology。

这个定义能解释 Palantir 的一半。Palantir 确实把数据库里的表和字段映射成业务对象、属性与关系。它还加入了行动和治理，使 Ontology 从知识表示进入企业运行。

Palantir 把 Ontology 称为组织的 operational layer。在很多场景里，它承担企业数字孪生的角色，同时包含两类元素：

• 语义元素：对象、属性和链接；
• 动力元素：动作、函数和动态安全机制。

Palantir 在另一份说明中把一次运营决策拆成四部分：数据、逻辑、动作与安全。这四部分放在一起，才构成一个可以落地的决定。

数据中台通常重点处理第一项。一个能工作的 Agent 必须穿过后面三项。

为了方便理解，我们可以把整套结构画成三层：底部连接数据，中间用 Ontology 表达公司的业务世界，上层让应用、模型和 Agent 查询并执行任务。

第一层：把散落的数据接进来

ERP、CRM、仓储系统、传感器和文档记录了公司运行的不同切面。数据层负责连接、清洗、转换与血缘追踪，让系统知道一个数字从哪里来、经过什么逻辑处理。

这项工作解决了可用性，没有自动解决业务含义。同一家公司可能在三个系统里使用不同客户编号，两家工厂也可能对“完工”采用不同口径。数据工程师能把字段放到同一张表里，业务人员仍要决定它们能否代表同一件事。

第二层：把数据翻译成业务对象

Ontology 将行映射成客户、订单、设备、仓库等对象，将列映射成对象属性，再用链接表达它们之间的关系。

一个订单因此拥有了业务位置。它属于某个客户，包含一组商品，由某个工厂生产，依赖库存与物流。模型查询“哪些订单会受这次缺货影响”时，可以沿着这些关系寻找答案，不必猜测几十张表该怎样连接。

这一层还提供共同词汇。财务、销售和生产部门可能各自维护一套指标，Ontology 迫使团队讨论同一个对象究竟指什么。技术团队会发现，这类争论表面上围绕字段，背后经常涉及责任和决策权。

第三层：让模型和应用进入工作流

AIP、业务应用和 Agent 在 Ontology 上读取对象、调用函数、提出建议。获得授权以后，它们还能执行预先定义的动作，把结果写回 Ontology 或外部系统。

至此，AI 才拥有一个可工作的现场。它看到的不再是一批匿名字段，而是一组有含义、有关系、有动作边界的业务对象。

最难建模的部分，是动词 #

许多企业知识图谱停在名词上：客户属于某个行业，订单对应某件商品，设备安装在某座工厂。这些关系能支持搜索和分析，却不能单独支撑运营。

企业依靠动词运行。销售创建订单，仓库确认出库，主管批准折扣，维修人员关闭工单。每个动词都带着前置条件和后果。

Palantir 的 Action Type 用一套定义封装这些变化。根据官方文档，一次 action 可以在同一笔事务中修改多个对象、属性与链接；它还能设置参数、校验规则、提交条件，以及通知或 webhook 等副作用。函数则负责表达更复杂的业务逻辑。

回到调货案例。系统可以把“调货”定义成一个动作：

1. 申请人选择缺货订单与来源仓；
2. 函数计算调拨后的安全库存和受影响订单；
3. 系统根据金额、区域和客户等级选择审批人；
4. 获批后创建调拨单，通知仓库，并更新预计交付时间；
5. 实际到货与客户结果重新写回系统。

Agent 可以建议执行这个动作，却不能随意绕过其中的校验。权限系统还会决定它能读取哪些对象、能调用哪些动作。Palantir 默认建议通过 Action 控制对象编辑，而不是给应用开放任意写权限。

在这套结构里，说明书告诉 AI 世界里有什么，操作手册规定它怎样改变这个世界，权限体系控制它可以走到哪一步。

聊天机器人答错一句话，用户可以忽略。运营 Agent 改错一张订单，错误会进入供应链。模型能力越强，动作层越需要明确的边界。

两个案例：团队怎样把模型接进行动闭环 #

人们很容易把 Ontology 写成抽象架构。两个公开案例能看出它在真实系统里的位置。

医院：同一张床连接着多个决定

Tampa General Hospital 从 2021 年开始使用 Palantir，把护士排班、患者数量、手术计划等数据接入 Foundry Ontology，再围绕患者流转与人员配置建设应用和预测模型。医院后来把合作扩展到十多个场景。

病床管理看上去像一个库存问题，实际包含更多约束。患者的病情、科室能力、护士配置、手术安排与预计出院时间会同时影响分配。系统还必须保留临床团队的决定权，不能用一个模型分数替代医护判断。

Tampa General 在 2025 年公开的材料中披露，合作项目使患者安置时间下降 83%，PACU 滞留下降 28%，脓毒症患者住院时长下降 30%，MRI 周转时间改善 30%。医院还称其 Sepsis Hub 截至 2025 年 11 月已帮助挽救超过 700 条生命。

这些数字来自医院和供应商的公开材料，没有随机对照研究，也无法把所有变化单独归因于一套软件。它们仍然说明了部署的目标形态：团队把数据与模型接入床位安排、检查和临床干预，结果用运营指标而非聊天满意度衡量。

水处理厂：模型建议进入两次日常会议

Jacobs 与 Palantir 在亚利桑那州 Agua Nueva 水处理厂做了另一类部署。系统接入传感器、SCADA、实验室、维护和 ERP 数据，模型根据实时状态提出鼓风机运行建议。

Jacobs 把模型建议嵌入操作人员每天两次会议。操作员可以接受或拒绝建议，并把反馈交给流程工程师检查。模型因此进入一线人员已有的工作节奏。

Jacobs 与 Palantir 披露，单位处理量用电从约 2,000 kWh/百万加仑降至约 1,500 kWh/百万加仑。公开材料还报告了约 20% 的全厂电力节省、运营罚款消除，以及每年约 30 万美元的电费节省。

这套系统包含一个清楚的闭环：实时数据进入模型，模型生成建议，操作员根据现场情况决定是否执行，结果和异议再帮助团队修改规则。Ontology 在这里承担共同状态，动作和反馈让它保持更新。

Suchman 所说的“情境行动”也出现在这个循环里。团队没有试图提前写完水处理厂的所有规则，而是让计划与现场互相修正。FDE 的价值因此不止是做出第一版系统，他还要观察系统进入日常工作后，人在哪些地方接受、拒绝或绕开它。

自上而下和自下而上，差别在从哪里开始付成本 #

完整 Ontology 的建设很重。团队要统一对象定义，连接数据源，梳理权限，还要处理不同部门之间的冲突。自上而下路线先把公司的关键模型建清楚，再让应用和 Agent 在统一基础上运行。它的上限高，启动时间和治理要求也高。

Palantir 把产品与人力交付放在同一套方法里。FDE 和 Deployment Strategist 进入现场，把业务问题拆成工作流，再与客户一起构建生产系统。现场团队填补了平台与具体企业之间的距离。

另一条路线从任务开始。Agent 先连接有限工具，处理一个具体工作；遇到模糊规则时向人确认；系统记录人的纠正、批准与结果，再逐步沉淀对象和规则。它把一部分前期建模成本移到运行过程，适合尚未拥有高水平数据治理的团队。

这两条路线代表两个理想类型，真实项目通常会在中间汇合。纯自上而下容易画出一张精致却没人使用的企业地图；纯自下而上会积累局部记忆，同一个“重要客户”可能在不同 Agent 里拥有不同定义。

更稳妥的起点是一条可衡量的决策闭环。团队先选择一个真实动作，例如订单调拨或床位分配，只建立完成该动作所需的最小对象、关系、规则与权限。系统上线以后，再根据异常和反馈扩展 Ontology。

这种做法保留了自下而上的速度，也要求团队把运行中学到的知识升级成共享结构。聊天记录只能保存一次交流；企业 Ontology 还要处理版本、冲突、权限、审计与复用。

Palantir 自己也在把这项工作交给 Agent。它在 2026 年 3 月宣布 AI FDE 正式可用。AI FDE 可以用自然语言完成数据转换、代码仓库管理、Ontology 编辑与函数开发，并采用“执行、观察结果、决定下一步”的闭环。系统让用户选择模型可以看到的上下文和可用工具。

它的治理设计更能说明问题。AI FDE 使用用户本人的身份和权限，修改操作需要批准，所有动作进入审计日志。

Agent 降低了建模和开发成本，没有消除业务判断。它让 Ontology 从一次大型工程，逐渐变成一项持续维护的组织能力。

想做 FDE，先学会从一个决定反推系统 #

Palantir 方法可以压缩成五个连续问题。它们比“会不会写提示词”更接近 FDE 的日常工作：

1. 公司正在做哪个决定？ 从调货、排班、定价或维修中选一个能衡量结果的动作。
2. 这个决定依赖哪些业务对象？ 找出客户、订单、设备等对象，以及它们之间的关系。
3. 哪些逻辑和权限约束行动？ 写清规则、例外、批准人和风险边界。
4. 人和 Agent 怎样共享控制权？ 决定哪些步骤自动执行，哪些步骤需要确认，怎样回退。
5. 结果怎样返回系统？ 记录执行效果、人工修改和异常，让下一轮决策拥有更好的依据。

这套顺序从运营结果出发，再向后寻找数据和技术。它能避免团队一开始就试图“把整家公司建模完”，也能避免 Agent 只会调用一堆工具，却不知道自己正在改变什么。

FDE 留下的应该是一家公司新的运行能力 #

OpenAI 愿意为部署投入超过 40 亿美元，说明前沿模型与企业价值之间仍有一段很长的工程距离。客户需要把自己的数据、控制机制和工作流程重新组织起来，模型才能进入日常运营。

Palantir 提供了一套经过长期实践的方法：从现场理解业务，把数据翻译成对象与关系，把决定编码成逻辑、动作和安全边界，再用真实结果持续修改这套模型。

人类 FDE 曾经承担其中大部分翻译工作。AI FDE 和新一代 Agent 会接手数据连接、初步建模和代码生成，人的注意力会更多放在对象定义、冲突处理和责任边界上。

一个 FDE 离开客户现场时，留下几张仪表盘远远不够。客户需要获得一套可以继续运行、继续学习，也允许人安全接管的系统。

下一次有人说“这个客户很重要，先把货调过去”，Agent 应该知道“客户”“货”和“调拨”在这家公司里的具体含义；它还要知道自己有权做什么，哪一步必须停下来找人。

Palantir 把这层能力叫作 Ontology。

它也是 FDE 最应该学习的方法。