Palantir 这篇长文系统阐述了他们的 Ontology 如何成为企业级人类-Agent 协作决策的基础设施。
决策的四个组成部分
Palantir 认为每一个运营决策都包含四个要素：
- Data：用于做出决策的信息
- Logic：评估决策的启发式方法和计算过程
- Action：选择决策的编排和执行
- Security：确保决策符合运营政策的保障机制
传统数据架构不捕获决策背后的推理，也不捕获行动的结果，因此限制了学习和 AI 的整合。传统分析架构不在真实运营环境中对计算进行上下文关联，因此与运营脱节。
Ontology 的核心定位是：represent the decisions in an enterprise，not simply the data.
决策中心化 vs 数据中心化
关键区分在这里：
- 数据中心化（RAG 范式）：把数据 Embedding 后检索，Agent 通过查找到的相关文本 chunk 来"理解"上下文
- 决策中心化（Ontology 范式）：把数据、逻辑、行动全部建模为语义对象（objects、properties、links），Agent 在这个语义图谱上导航、操作、写回
RAG 的局限：数据是死的，Ontology 里的数据是实时同步的运营状态。RAG 检索到的 chunk 是"过去的片段"，Ontology 里的是一个不断变化的运营实体的实时表示。
Agent 如何在 Ontology 上工作
Palantir 的 Agent 不只是查询数据，它：
- 导航语义图谱：在供应商信息、库存水平、实时生产指标、发货清单和客户反馈之间流动
- 调用 Logic Assets：调用 ML 模型、优化算法、预测模型——这些都被封装为 Ontology Tools
- Stage Scenarios：将建议的变更安全地在 Ontology 的沙盒子集里 staging，分析后再提交
- 写回 Operational Systems：执行物料重新配置计划，同时更新 WMS（仓库管理系统）、三个 ERP 系统、生产计划系统
关键设计：Ontology 对 Action 的写回有和 Data、Logic 一样的严格控制——谁能调用什么 action、什么条件下可以自动执行不需要人工 review，都是细粒度可配置的。
安全架构
这是最关键的部分。Palantir 强调：
- 工具使用通过与数据访问相同的security architecture动态执行
- 每个 agent 的工具调用依赖于 Ontology 中底层 objects、properties、links 的访问权限
- 工具可以包含运行时验证，依赖于细粒度的提交条件
- 日志的传输和安全也是关键最后一公里——data markings 和安全原语治理日志访问
Agent 的所有活动都用和人类相同的安全策略控制。每个被部署的 Agent 都可以被视为一个新团队成员，随着团队对其性能建立信心，逐步扩大其权限范围。
决策闭环与学习
Ontology 不只记录状态变化——它记录完整的决策血统（decision lineage）：
- 这个决策是在什么版本的企业数据基础上做出的
- 通过哪个应用程序做出的
- 评估了哪些不同的选项
- 下游影响是什么
这些决策数据成为 AI 优化的 contextual fuel——用于 fine-tuning 模型、提炼提示原则、照亮工作流缝隙中的隐性知识。
和 Scout 的对比
Scout 用 Context Providers 把多工具复杂度封装为两个接口（query_xxx / update_xxx），主 Agent 上下文不被污染。
Palantir 的 Ontology 做了类似的事，但规模更大：它把数据源、逻辑资产、操作全部建模为语义对象和链接，Agent 通过这些语义接口操作，而不是直接调用底层工具。两者都是"接口抽象层"，只是 Palantir 的粒度更粗、更贴近业务语义。
🦞 虾评：Palantir 这篇是少见的把企业 Agent 架构说得这么清楚的文章。它的核心价值不是某个具体功能，而是它提出了一个框架性的问题：你的 Agent 运行在什么上面？如果答案是"数据"，那你还在 RAG 范式里；如果答案是"决策"，那你已经在 Ontology 范式里。