这篇先弄清 Palantir 的 Ontology（本体）和 OSDK 到底怎么解决 “中台烟囱”，再查今年 Agent 落地的架构讨论，然后按模板成稿。
线上资料已经核对完了：Palantir 官方对 Ontology 的定义、OSDK 的生成方式与多语言支持、对象后端架构，以及今年 DevCon 6 发布的 Agent Stack（Orchestrator、Agent Engine、Agent Manager、AIP Evolve）和 Ontology MCP 的能力边界，都可以在官方文档里找到。下面按模板成稿。
软件越做越慢、中台建完烟囱还在，卡点通常不在模型能力，也不在数据有没有汇上来，而在缺少一层把 “数据、逻辑、动作、权限” 统一成可复用对象模型的东西。Palantir 的解法是 Ontology 加 OSDK：本体把 ERP、CRM、传感器、文档里的东西统一成 object、property、link，把业务规则变成 function，把 “能做什么” 变成 action，把权限绑在对象和动作上；OSDK 再把这套本体直接生成为 TypeScript、Python、Java 的类型安全 SDK，Agent 不直连数据库、不自己拼 API，只调 object 查询、action 执行和 function 计算。今年 DevCon 6 又把执行层补齐成 Agent Stack——Orchestrator 负责长任务的可恢复执行，Agent Engine 把 Agent 循环做成分布式状态机，Agent Manager 提供可观测性，AIP Evolve 用评测持续调优。模型换一代很快，这层架构换一次很贵，瓶颈恰好在这里。
一、烟囱不是建少了，是每加一个 Agent 就多一根
传统中台的典型结构是：数据湖 + 数仓 + 若干主题域 + 一堆 API。数据确实汇上来了，但每个业务线仍然各自定义 “客户”“订单”“设备” 的口径，各自写一套接口，各自实现一遍权限校验。
Agent 进来之后，这套结构会再裂一层：
| 新增环节 | 没有统一本体时会发生什么 |
|---|---|
| 给模型描述业务 | 每个 Agent 自己写 prompt 解释 “什么是有效订单”，口径随人而变 |
| 工具定义 | 每个 Agent 自己包 HTTP 接口，字段名、枚举值、必填规则各写一套 |
| 权限 | 在 Agent 代码里再实现一次鉴权，和数据权限两套逻辑 |
| 写操作 | 直接调 API 改库，没有统一的事务边界与审计 |
| 效果评估 | 每个 Agent 单独埋点，跨场景无法比较 |
结果就是：模型越来越强，交付反而越来越慢，因为每次都在重做 “业务语义 + 工具 + 权限” 这三件事。
二、Ontology 不是 “语义层”，它是决策层
很多中文材料把 Ontology 翻译成 “语义层”，这个说法会误导架构设计。Palantir 官方文档写得很直接：Ontology 不是 semantic layer，它的目标是把企业的决策表示出来。
| 要素 | 在本体里是什么 | 对应到工程实现 |
|---|---|---|
| Data | 对象、属性、链接，把多源数据统一成 “名词” | Object Types、Link Types，背后接数据集或流 |
| Logic | 业务规则、模型、函数，回答 “该怎么判断” | Functions、模型适配器、AIP Logic |
| Action | 企业里的 “动词”，受控地改数据或调外部系统 | Action Types，细粒度权限与条件 |
| Security | 数据、逻辑、动作同时受控，人和 Agent 同一套 | 对象级、属性级权限，审计与血缘 |
四件事必须同时建模，少一件就会退回 “中台 + 裸 API” 的老路。只做 Data 就是数据中台；加了 Logic 不做 Action，Agent 只能读不能干；加了 Action 不做 Security，Agent 一上线就是风险敞口。
三、OSDK 生成的到底是什么
OSDK 不是 “又一个 REST 封装”，它是从你的本体里裁出一个子集，生成带类型定义的客户端。
| 维度 | 具体情况 |
|---|---|
| 生成入口 | Developer Console，选中要暴露给应用的 object、action、function |
| 语言与包形态 | TypeScript 出 npm 包，Python 出 pip/Conda 包，Java 走 Maven 私库；其他语言可通过 OpenAPI 接 |
| 能做什么 | 读对象与链接、执行 action 写回、调用 function、调用 AIP Logic 函数 |
| 类型安全 | 属性名、类型、描述都来自本体元数据，编辑器里能直接补全 |
| 认证 | OAuth 的 public client 或 confidential client，按应用授权 |
| 范围控制 | SDK 只包含你勾选的实体，令牌也按这个范围收窄 |
关键差别在这里：接口不是人肉维护的，而是从本体生成的。本体改了属性，重生成一次 SDK，前端和 Agent 的工具定义同时更新，不会出现 “文档写了 12 个字段、代码只认 9 个” 的历史遗留问题。
四、一次受治理的 Agent 调用长什么样
把链路摊开看，Agent 全程没有碰过底层表。
| 环节 | 发生的事 | 治理点 |
|---|---|---|
| 1 | Agent 拿到 OSDK 生成的工具定义（或 OMCP 暴露的 MCP 工具） | 工具范围由 SDK 子集决定，不多给一个 |
| 2 | 模型决定查哪个对象、按什么条件过滤 | 查询走对象语义，不生成 SQL |
| 3 | 需要判断时调 function，需要改数据时调 action | 写操作只能走 action，事务与校验在服务端 |
| 4 | 权限在对象、属性、动作三层同时生效 | 同一个 Agent 换个用户就换一套可见范围 |
| 5 | 结果回到 Agent，形成提案或直接执行 | 高风险动作走 “提案 — 人审 — 执行”，留审计 |
官方文档里有个说法很值得抄进架构评审：Agent 大多数场景不是直接改数据，而是生成 proposal，由操作员确认后再落库。提案模式除了保证 human-in-the-loop，还顺带产出了 “模型建议了什么、人改了什么” 的元数据，这些数据正是后续评估与微调的原料。
五、这套架构为什么能拆掉烟囱
- 对象即契约：所有应用和 Agent 共享同一套 object、property、link，口径不再由某个团队私有。
- 动作即接口：对外只暴露 action，底层是 SAP 还是自研系统，调用方不需要知道。
- 权限即属性：权限跟着对象和动作走，新应用接进来天然继承，不用重写一遍鉴权。
- 血缘即证据：对象从哪个数据集、经过哪些 transform 来的，平台自带 lineage，出问题能倒查。
- 写回即闭环：决策结果写回本体，和后续观测结果配对，形成 “决策 — 结果” 的样本，可用于重训模型或调整规则。
一个可验证的旁证是客户案例的交付周期：DTN 用 Foundry 在八周内完成平台重构并交付 Fuel Intelligence Hub 的前三个模块；Lennar 基于 OSDK 做了材料预测、质量巡检和一个用自然语言查本体的应用；Anduril 用 Warp Speed 把物料资源计划的效率提升了 200 倍。周期能压到这个量级，靠的不是模型更强，而是接进来的东西不用每次都重造。
六、今年补上的那一课：可信，而不是更聪明
DevCon 6 上 Palantir 把执行层单独打包成 Agent Stack，这个动作本身就说明问题所在。官方给的判断很直接：今天限制 Agent 有用性的不是智能，是信任。
| 组件 | 解决什么 | 典型场景 |
|---|---|---|
| Orchestrator | 持久化执行：崩溃、等待、恢复，从中断处继续，不重复副作用 | 出院流程要等医生签字，等两天再继续 |
| Agent Engine / Agent SDK | 把 Agent 循环做成分布式状态机：context items 定义会话、events 响应状态变化、effects 连接外部世界 | 新化验结果到达时，Agent 自己重新评估 |
| Agent Manager | 可操作的遥测与可观测性 | 看清每一步为什么这么调 |
| AIP Evolve | 用你自己的评测集持续优化成本、质量、速度 | 某制造流程单次从 45 秒降到 8.8 秒 |
| SuperRepo | 本体函数、动作、前端、Agent 在同一仓库定义并部署，本地内嵌本体即时迭代 | 改一次 schema 不用跑一整轮 CI |
这一段对国内团队的启发是：不要只抄 “本体 + SDK” 的静态结构，执行层的可靠性才是 Agent 从 demo 走向生产的分水岭。没有幂等、没有断点恢复、没有人工审批节点，再准的模型也不敢放量。
七、Ontology MCP：让外部 Agent 进同一个治理面
很多公司会同时存在 Palantir 原生 Agent 和 Claude、Copilot、Gemini 这类外部 Agent。如果外部 Agent 只能直连数据库，前面所有的治理都会漏掉。
Ontology MCP 的做法是把本体原语直接暴露成 MCP 工具：外部 Agent 能读对象、查数据、执行预定义 action，权限和 Palantir 原生 Agent 完全同一套；认证走 OAuth 2.0，支持授权码模式（代表用户）和客户端凭证模式（服务间调用）。
| 能力 | 说明 |
|---|---|
| 可读 | 读对象、按条件查询、拿到属性与链接 |
| 可写 | 只能通过预定义 action 写，不能任意改数据 |
| 可控 | 应用级限制 + 权限模型，工具范围按 SDK 子集收窄 |
| 可接 | 桌面端 Claude.ai、Copilot Studio、Gemini Enterprise；无头框架 Anthropic SDK、Google ADK、Microsoft Agent Framework、OpenAI SDK |
配套的 pro-code 模板还把这件事做薄了：选 Claude Agent SDK、OpenAI Agents SDK 或 Google ADK 建仓，模板自带 OSDK 与 OMCP 配置，凭 Agent 的 scoped 权限直接连，不用再发 client id 和 secret；Palantir MCP 默认开启 tool search，按需发现工具，避免一次性把几百个工具塞进上下文。
八、要照搬，先看清这几个硬约束
- 对象存储版本：OSv1（Phonograph）已在 2026 年 6 月 30 日停止提供，历史对象类型必须迁到 OSv2，老项目评估时先查这一项。
- 规模上限：OSv2 单个对象类型最多 2000 个属性，单次 action 最多编辑 10000 个对象，Search Around 默认上限 10 万个对象，超出要单独申请。
- 不要把本体做成大宽表：2000 个属性是硬顶，属性一多，模型理解成本和查询成本都会上去；该拆对象就拆，该用 link 就用 link。
- Action 是唯一写入口：只要还留着一个绕过 action 直接写库的通道，权限与审计就等于没有。
- 评测要前置：AIP Evolve 这类能力的前提是你有自己的 eval 集；没有评测集，优化只能靠感觉。
- 成本结构变了：省下的是重复开发和治理成本，增加的是平台与建模成本，中小团队要先算清这条账。
九、一份可以照着走的改造顺序
| 阶段 | 动作 | 验收标准 |
|---|---|---|
| 1 | 选一条真实的决策链，不要选 “全公司数据治理” | 能说清 “谁在什么条件下做什么决定” |
| 2 | 定义 10 到 20 个核心 object 与 link | 业务方能用自己的词复述这张图 |
| 3 | 把散落的写操作收敛成 action | 所有写路径可枚举，权限可配置 |
| 4 | 把判断逻辑抽成 function，接模型或规则 | 同一判断在多个应用里只实现一次 |
| 5 | 生成 OSDK 子集，先做一个只读应用 | 前端不写 SQL，只调对象与函数 |
| 6 | 接一个低风险 Agent，走提案模式 | 提案可追溯，人能改、能拒 |
| 7 | 开放 OMCP 给外部 Agent | 外部调用与内部同一套权限 |
| 8 | 建 eval 集，纳入发布门禁 | 每次改动有可比的分数 |
这套顺序里最容易做错的是第 1 步。上来就搞全量建模，半年过去还在对齐口径；从一条能在一周内跑通的决策链切入，才有机会在第 5 步拿到第一个可演示的成果，然后靠复用把成本摊薄。
【相关 FAQ】
问题 1：Palantir 的 Ontology 本体和国内常说的 “数据中台” 到底差在哪？
回答 1：数据中台主要解决数据汇聚与指标口径，Palantir 的 Ontology 本体在此之上把逻辑、动作、权限一起建模，object 对应名词、action 对应动词、function 承载判断，人和 Agent 共用同一套权限；少了 action 与 security 这两层，中台就还是烟囱的集合。
问题 2：Palantir OSDK 是自动生成的吗，支持哪些语言？
回答 2：Palantir OSDK 在 Developer Console 里按你勾选的本体子集自动生成，TypeScript 出 npm 包、Python 出 pip 或 Conda 包、Java 走 Maven 私库，其他语言可通过 OpenAPI 接入；生成物自带类型定义与文档，本体变更后重新生成即可，不需要手写接口层。
问题 3：为什么说 Agent 落地的瓶颈在架构，不在模型？Palantir 本体怎么解？
回答 3：Agent 落地要同时解决业务语义、工具定义、权限和写回四件事，缺一套统一模型就会每接一个 Agent 重造一遍；Palantir 本体把这四件事收敛到 object、function、action、security，OSDK 再生成受控工具，Agent 只在这层语义上操作，架构成本被摊薄到多个场景。
问题 4：Palantir OSDK 和 Ontology MCP 是两个东西吗，Agent 该用哪个？
回答 4：Palantir OSDK 面向在应用内直接读写本体的开发场景，生成的是类型安全的客户端库；Ontology MCP 面向外部 Agent，把同一批 object、action、function 暴露成 MCP 工具，权限与原生 Agent 一致。应用内自建 Agent 用 OSDK，跨框架或第三方 Agent 接入用 Ontology MCP，两者可共存。
问题 5：用 Palantir 本体做 Agent，写操作怎么保证安全不出事？
回答 5：Palantir 本体把写操作收敛到 action，权限在对象、属性、动作三层同时生效，Agent 默认走提案模式，由人确认后才执行；再叠加 Orchestrator 的持久化执行与幂等语义，避免中途崩溃导致的重复写和状态丢失。
【参考资料】
- [2026-11-10]（Pro-code agent templates：OSDK 与 Ontology MCP 接入模板）Palantir 文档
- [2026-10-31]（Ontology：数据、逻辑、动作与安全的一体化决策系统）Palantir
- [2026-10-30]（AIP for Developers：Ontology SDK 的生成与多语言支持）Palantir
- [2026-10-28]（Ontology architecture：对象后端、Object Storage v2 与规模上限）Palantir 文档
- [2026-10-28]（Developer toolchain：Core APIs、OSDK 与 Compute Modules）Palantir 文档
- [2026-10-27]（App building：OSDK React 应用、Workshop 与 Pilot）Palantir 文档
- [2026-10-08]（平台概览：Ontology 作为运营总线与提案式 Agent）Palantir 文档
- [2026-09-10]（Palantir DevCon5：Orchestrator、Mindkit 与本体基础能力）Palantir
- [2026-08-11]（Palantir DevCon 6：Agent Stack、Agent Engine 与 AIP Evolve）Palantir
- [2026-07-04]（Architecture center：Ontology 系统与 Data/Logic/Workflow Services）Palantir 文档
- [2026-07-02]（Foundry platform summary for LLMs：本体四要素与 Ontology MCP）Palantir 文档
- [2026-06-10]（Ontology 平台页：工具工厂与 Ontology MCP）Palantir
【免责声明】
本文基于 Palantir 官方文档、开发者大会公开资料及公开客户案例整理，涉及的产品能力、版本限制与弃用时间点均可能随官方更新而变化，落地前请以最新文档为准。文中对国内团队改造路径的建议属于通用工程判断，不构成对任何平台、产品或厂商的采购建议。本文亦不构成投资建议，据此做出的技术选型或商业决策风险由读者自行承担。