企业 AI Native 怎么落地：从 Palantir Ontology 到真实 FDE 交付

很多企业 AI 项目从“接入一个大模型”开始：买一批账号、搭一个问答框、接一套知识库，再做一个看起来很完整的演示大屏。演示结束后，员工回到原来的 ERP、CRM、Excel、邮件和群聊里继续工作，系统没有真正改变任何决定。

Miles Ma 在 X 发布的长文《拆完 Palantir 的本体论，我发现国内 99% 的 FDE 都是扯淡》把问题说得很直接：企业 AI 的价值不在于能不能生成一段漂亮回答，而在于它是否进入了具体工作流程，帮助具体员工看到必要信息、做出具体决定、执行后续动作，并用真实结果验证价值。

本文根据该 X 帖子整理改写，并保留原帖公开配图。原帖发布于 2026 年 9 月 15 日，作者是 Miles Ma（@miles_mazy）。文中对 Palantir 产品、客户案例、5 天交付和 FDE 行业现状的判断属于原作者观点；其中 Palantir 公布的金额、周期和效果数据是公司案例口径，不能直接当成独立审计结果。后文补充的验收表、交付边界和 GPT88/Agent 工程建议，是本文的结构化延伸。

先看结论：AI Native 是工作流变化，不是工具采购

判断一个企业是否真的在做 AI Native，可以先把这句话填完整：

哪一类员工，面对哪一类具体问题，需要看到什么信息，做出什么决定，随后执行什么动作，最后用什么结果判断它有没有价值？

如果这句话写不出来，项目大概率还停留在工具展示、培训或概念包装阶段。一个企业 AI 场景至少要包含下面这条闭环：

具体员工
  → 具体问题
  → 相关对象和信息
  → 业务决定
  → 生产系统动作
  → 结果回写
  → 时间、错误、成本或收入变化

这条闭环比“用了哪个模型”“做了多少页面”“是否接入 Agent”更能说明项目是否有价值。

一、先别急着谈 Ontology，先说 AI Native

“AI Native”经常被简化成几个表面动作：给员工开通 AI 账号、在 OA 里放一个聊天框、让知识库生成一些文案，然后宣布企业开始转型。

更实用的理解是：AI 已经进入具体业务流程，并且承担其中一部分可以观察、可以审计、可以验收的工作。

过去，一个员工可能要在五六个系统之间反复搬运信息：

1. 在 CRM 查询客户和历史沟通；
2. 在 ERP 查看合同、发票或订单；
3. 在 WMS 或 MES 查库存、设备和生产状态；
4. 用 Excel 补充系统中没有的字段；
5. 通过邮件或群聊确认例外情况；
6. 最后回到某个系统点击批准、改价或改期。

AI Native 的目标不是把这些系统全部推倒重建，而是先找到其中一个重复发生、价值明确、可以验证的决定，把必要信息和动作连接起来。

老公司为什么不能等“全部治理完”再开始

成熟企业通常有多年积累的系统和规则：

业务信息	可能所在的位置
客户与商机	CRM
合同、发票和付款	ERP、财务系统
库存和物流	WMS、TMS
设备和生产状态	MES、工业系统
例外信息和临时确认	Excel、邮件、群聊

每套系统有自己的账号、权限、字段和历史约定。有些字段为什么这样填写，只有少数长期员工知道。你不能告诉管理层“要做 AI Native，就把这些系统全部换掉”；也不能说“等所有数据治理完成后再开始”，因为这很容易变成无限期等待。

更可行的路径是：选择一类员工，选择一件每天反复做的事，先改变其中一个决定。如果这条小闭环确实减少了时间、错误或损失，再向相邻流程扩展。

二、Palantir Ontology：一张能干活的公司地图

Palantir 官方把 Ontology 定义为企业的操作层。用更容易理解的话说，它不是数据库字典，而是一张可以帮助人和 AI 观察、判断并操作企业的业务地图。

以发票争议为例，员工可能需要同时查看：客户、合同、订单、服务记录、SAP 中的发票，以及 Salesforce 里的历史沟通。过去这些信息分散在多个系统里，员工为了尽快结案，可能直接给客户打折，却没有充分判断争议是否成立。

Ontology 试图把这些资料组织成业务可理解、Agent 可调用、权限系统可约束的对象世界：

Ontology 要素	发票争议示例	作用
对象	客户、合同、订单、服务、发票	表达业务世界中的实体
属性	金额、日期、争议状态、付款期限	描述对象当前状态
关系	订单属于合同、发票对应服务	连接对象之间的业务关系
动作	批准、驳回、改付款日期、请求材料	把判断转成可执行行为
权限	谁能查看、谁能修改、什么金额要升级	约束可见范围和动作资格

只有名词，没有动词，还不算落地

很多项目可以很快列出一批对象：客户、订单、合同、产品、设备。但如果系统不能支持动作，它更像一层新的数据展示，而不是业务操作层。

真正的闭环至少还要回答：

• 员工点击批准后，状态是否写回 Salesforce？
• 付款日期发生变化后，是否写回 SAP？
• 写入失败时，谁接管、如何重试、如何回滚？
• 写入成功后，是否留下审计记录？
• 下一次决策能否使用这次动作的结果？

因此，Ontology 的关键不是把数据库换一种命名方式，而是把对象和动作放在同一条可审计的业务路径里。

三、数据仓库、Ontology 和 Agent 的区别

可以用下面的方式区分三类系统：

系统层	主要回答的问题	常见结果
数据仓库	过去发生了什么？	报表、指标、历史分析
Ontology	企业有哪些对象、关系和可执行动作？	业务对象、权限、动作和规则
Agent 工作流	当前应该如何判断和推进？	调研、建议、工具调用和任务执行

数据仓库把数据集中起来，通常到报表和查询就结束了。Ontology 进一步定义对象、关系、动作和权限。Agent 则在这些受控对象和工具之上，帮助员工完成检索、判断、规划和执行。

这三者不能互相替代：

• 没有可靠数据，Ontology 只是空壳；
• 没有对象、关系和权限，Agent 只能对文本猜测；
• 没有 Agent 或其他执行界面，Ontology 可能只停留在建模层；
• 没有写回、审计和结果指标，任何一层都无法证明业务真的改变了。

四、五天 PoC 交付的真实含义

原帖讨论了 Palantir AIP Bootcamp 中“5 天以内从 0 到用例”的说法。这个说法最容易被误读成“5 天改造一家公司”或“5 天必然签单”。更合理的解释是：用真实数据跑出一个足够窄的闭环，让客户看到这件事继续做下去是否值得。

五天 PoC 应该交付的是价值证据，而不是企业级终局系统：

选择一个具体决定
  → 获取该决定所需的最小数据
  → 建立对象、关系、动作和权限
  → 让真实用户处理真实任务
  → 将动作送回生产流程
  → 比较时间、错误、成本或收入

以下工作通常不应该被包装成“五天全部完成”：稳定数据接口、长期权限、数据清理、生产写回、回滚、培训、采购、安全评审、法务、合同和规模化部署。它们仍然需要几周或几个月，企业采购还可能有另一条时间线。

PoC 的验收线应该怎么写

不要用“完成 AI 改造”作为验收标准。可以写成：

在 5 个工作日内，让采购人员使用真实物料清单，
识别满足成本和生产约束的替代原料，并把建议写入审核队列。
采购负责人可以批准或拒绝，所有动作留下日志。
验收比较：单条物料决策耗时、人工错误、可追溯性和继续使用意愿。

这条标准可以被验证，也能明确五天之后还缺哪些生产化工作。

五、从公开案例反推 FDE 的交付 SOP

原帖强调，下面这套流程是根据 Palantir 公开的用例生命周期、Bootcamp 和案例反推出来的，并不等于 Palantir 内部正式手册。作为企业 AI 团队的实践框架，它可以拆成七步：

1. 找到真正做这件事的人

不要先找最高层最宏大的转型目标，而要去现场观察每天执行任务的一线员工：他打开哪些系统，复制哪些字段，等待哪些权限，在哪些步骤最容易出错，哪些例外需要找老员工确认。

2. 把“建设智能系统”压成一个决定

先问“要改变哪个决定”，而不是“要做一个什么平台”。决定越具体，所需的数据、对象、动作和验收指标越容易确定。

3. 只获取闭环真正需要的数据

不要因为某个数据源“以后可能有用”，就把所有数据都接进来。先拿到完成当前决定所需的最小集合，并记录字段来源、负责人、更新时间和权限。

4. 建立最小对象模型

把当前场景需要的对象、属性、关系、动作和权限显式写出来。暂时不需要支持的对象不要为了完整性强行加入。

5. 让真实用户处理真实任务

界面出来后，不要只演示一条准备好的成功路径。让用户处理真实的批准、拒绝、纠正、升级和异常情况，观察他是否真的愿意把工作交给系统。

6. 把动作送回原来的生产流程

建议可以留在聊天窗口里，但真正的批准、改期、变更和分配必须写回原系统，或进入一个明确的待处理队列。写回失败、权限不足和数据冲突都要有可见状态。

7. 复用连接器、对象模型和工作流

第一个项目做出的通用连接器、对象模型、权限模板和工作流步骤，应当回收到产品或共享能力层。否则客户 A 和客户 B 各做一套，工程师离开后项目就从头开始，交付仍然只是一次性外包。

六、为什么“驻场”不等于 FDE

FDE 不是“会写代码的人去客户现场”，也不是把售前、实施或驻场外包换成一个更有吸引力的职位名称。

一个真正承担交付责任的 FDE，至少需要连接以下角色：

客户一线用户
  ↕
FDE：现场调研、场景设计、集成、验证和反馈
  ↕
产品、平台、数据、安全和业务负责人
  ↕
可复用的连接器、对象模型和产品能力

单个 FDE 不能独自承担所有工作。客户不给权限时，需要业务负责人推动；业务部门不愿意对结果负责时，需要管理层拍板；写回生产系统出错时，需要平台、安全和业务共同兜底；试点人人叫好但没人持续使用时，需要有人决定继续、修改还是停止。

如果一个项目只有驻场工程师，没有平台、产品、数据、安全和客户业务负责人的共同参与，那么它很可能只是换了名字的实施项目。

七、用四个问题识别“FDE cosplay”

判断一个 FDE 项目是否真实，可以直接问四个问题：

问题	需要看到的证据
是否有真实用户？	明确的岗位、任务、使用记录和反馈
是否接入真实数据？	数据来源、字段权限、更新时间和异常记录
是否执行真实动作？	工具调用、审批、写回、失败处理和审计日志
是否产生真实结果？	时间、错误、成本、收入或持续使用指标

如果项目只展示需求访谈、流程图、知识库问答、精美大屏和一段模型回答，却无法说明谁在什么时候用它改变了什么决定，就不能把它称为企业 AI 落地。

不能用证书替代交付证据

没有做过真实交付的人，也可以讲清需求访谈、业务流程、PoC 包装和方法论。但真正的交付会遇到更难的问题：

• 客户不给权限，谁推动？
• 业务部门不愿意对结果负责，谁拍板？
• 写回生产系统出了错，谁兜底？
• 试点会上人人叫好，回去没有人使用，是否停止？
• 第一个客户做出的能力，如何进入下一个项目？

这些问题没有答案，培训证书再漂亮也不能证明交付能力。

八、Palantir 案例数字应该怎样使用

原帖提到 Palantir 的发票争议案例、物料替代案例、Panasonic Energy North America 案例和电网本体案例，并引用了部分交付周期与效果数字。阅读这类案例时，建议把信息分成三层：

信息层	可以怎么用	不能怎么用
公司公开案例	理解问题类型、系统结构和价值指标	不能当作独立审计结论
客户故事中的结果	作为待验证的目标参考	不能保证复制到任意企业
原作者的行业判断	用来提出讨论和审查问题	不能直接当行业统计

例如，“每年多收回 5000 万美元”“流程从四小时降到 15 分钟”这样的数字，至少还需要知道原始口径、基线、样本范围、时间窗口、实施成本和是否存在其他同时发生的变化。项目评审时，应该把它们放到“待核实案例数据”一栏，而不是直接写进自己的销售承诺。

九、把这套方法接到 Agent 和 GPT88

如果要用 GPT88 或其他兼容 API 实现类似的 FDE 工作流，可以采用以下分工：

业务负责人定义目标与验收
          ↓
Agent 读取受控上下文并提出计划
          ↓
工具提供对象查询、计算和待审批动作
          ↓
Backend 校验身份、权限、状态和参数
          ↓
人工或规则批准高风险动作
          ↓
系统写回生产环境并记录结果

模型负责什么

• 整理访谈、流程和业务上下文；
• 识别候选对象、关系和待确认字段；
• 生成场景简报、测试计划和操作建议；
• 根据真实工具结果解释差异；
• 为人准备审批所需的证据和影响范围。

代码和 Backend 必须负责什么

• 当前用户身份和租户范围；
• 数据源权限与字段级访问；
• 对象状态、版本和并发冲突；
• 动作参数、数量、金额和范围校验；
• 幂等、回滚、重试和审计；
• 写回生产系统后的结果确认。

不要让模型直接执行任意 SQL、直接持有客户 Token，或把“模型输出了已完成”当成系统已经完成。模型可以提出动作，执行器和业务后端必须决定动作是否允许发生。

十、五天 PoC 的最小验收表

可以把一个窄场景的 PoC 验收拆成下面几组：

场景

• 已明确岗位、任务、触发条件和目标结果；
• 已确定要改变的具体决定；
• 已记录当前人工流程和基线耗时；
• 已列出不属于本次 PoC 的范围。

数据与对象

• 每个字段都有来源、更新时间和访问边界；
• 对象、属性、关系和动作可以被业务人员理解；
• 缺失、冲突和过期数据有明确处理方式；
• 未授权的数据不会因为 Agent 请求而自动暴露。

执行与写回

• 只开放当前场景需要的工具；
• 高风险动作需要人工批准或规则门禁；
• 写回失败、重复执行和状态冲突可见；
• 每次动作都有调用者、参数、时间和结果记录。

结果

• 真实用户处理过真实任务，而不是只看演示；
• 至少记录一项时间、错误、成本、收入或使用率指标；
• 用户可以纠正、拒绝、升级和接管；
• 已决定继续扩展、修改方案或停止。

十一、从一次交付积累产品能力

FDE 项目最容易失败的地方，是每个客户都从头做一遍：重新写连接脚本、重新解释字段、重新搭页面、重新设计权限、重新写 Agent Prompt。这样项目数量越多，维护成本越高，工程师离开后能力也无法留下。

每个项目结束后，至少应当回收五类资产：

1. 连接器：对 CRM、ERP、WMS、MES 或文件系统的稳定访问方式；
2. 对象模型：已经验证过的对象、属性和关系；
3. 动作模板：批准、改期、分配、升级和回写流程；
4. 验收模板：同类场景的基线、指标和失败条件；
5. 业务知识：字段含义、例外规则、权限责任和用户反馈。

这些资产不是为了把所有行业强行做成一个模板，而是为了让下一次项目从已经验证过的部分开始。真正的速度来自复用，而不是每次都宣称“5 天从零完成全部工作”。

十二、给企业 AI 团队的最终判断

如果要评估一个 FDE 或企业 AI 项目，不要先问它用了哪个模型、是否有一个很大的知识库、界面是否足够漂亮。先问：

谁在什么具体场景下工作？
他原来如何做决定？
Agent 看到了哪些真实对象和关系？
它提出或执行了什么动作？
动作是否写回生产系统？
谁可以批准、拒绝或接管？
结果如何证明这次改变值得继续？

回答越具体，项目越接近真实交付；回答越停留在概念、名词和演示，越应该降低承诺，先做一个窄场景验证。

FDE 的价值不在职位名称，而在它是否把企业的业务能力伸到客户现场，并把现场验证过的连接器、对象、动作和结果带回产品。Ontology 的价值也不在名词本身，而在它是否让人和 AI 能在权限边界内看懂业务、做出决定、执行动作，并知道动作带来了什么结果。

结语：先改变一个决定

企业不需要先完成一次宏大的“全公司 AI 改造”才能开始。更可靠的最短路径是：

找到一个真实员工
  → 观察一个重复任务
  → 选择一个具体决定
  → 建立最小对象和动作闭环
  → 让真实用户处理真实数据
  → 写回生产流程
  → 用结果判断下一步

五天可以用来证明一个窄场景值不值得继续，不能用来承诺整家公司已经完成智能化。FDE 可以成为企业 AI 落地的重要角色，但前提是它背后有真实平台、数据、权限、安全、产品和业务负责人，而不是只有一个人在客户办公室里等待接口和字段。

这也是这篇 X 长文最值得保留的判断标准：别看项目讲了多少 Ontology、Agent 和 FDE，去看它是否真的改变了一个人的工作决定，并把结果带回了业务系统。