- tags
- [AI, 数据, Agent, 平台, 企业, 数字孪生]
- created
- 2026-04-16
- updated
- 2026-05-06
- sources
- [raw/notes/palantir-ontology-research-2026.md, raw/notes/rootswarm-strategy-brainstorm-2026-04-27.md, raw/notes/anthropic-openai-pe-jv-fde-mid-market-2026-05-04.md]
定义¶
Palantir Ontology 是 Foundry 和 AIP 平台的核心数据抽象层。不是数据仓库，而是组织的"数字孪生"——将原始数据映射为现实世界的实体（对象）、关系（链接）和操作（动作），叠加治理层和 AI Agent 能力。
核心洞见：数据仓库存储数据，Ontology 存储数据 + 语义 + 关系 + 动作 + 治理。 它不是存储层，是操作层。
双层架构：语义 + 动力¶
现实世界
│
▼
[Object Types] ── [Link Types] ── [Interfaces] 语义层（名词）
│
▼
[Action Types] ── [Functions] 动力层（动词）
│
▼
[数据集 / 虚拟表 / ML 模型] 数据层
│
▼
[原始数据源: 数据库 / API / 文件 / 流] 基础设施
语义层（Semantic Layer）¶
| 概念 | 含义 | 类比 |
|---|---|---|
| Object Type | 现实实体的 schema（员工、设备、订单） | 数据库表，但带业务语义 |
| Link Type | 实体间关系（"管理"、"属于"） | JOIN，但预定义+治理+可发现 |
| Interface | 跨 Object Type 的共享形状 | 面向对象的接口/多态 |
动力层（Kinetic Layer）¶
| 概念 | 含义 | 为什么重要 |
|---|---|---|
| Action Type | 可对对象执行的操作（回写、审批、触发工作流） | 数据平台的"动词"——从只读分析升级为操作系统 |
| Function | TypeScript 业务逻辑，查询对象+计算+返回 | 领域知识的编码，可被应用和 AI Agent 消费 |
Action 是 Ontology 与数据仓库的根本分界线：Databricks/Snowflake 是读取平台，Ontology 是操作平台。它不只告诉你"世界是什么样的"，还让你"对世界做事"。
与传统数据模型的区别¶
| 数据仓库/数据湖 | Ontology | |
|---|---|---|
| 抽象单元 | 表/列/行 | 对象/属性/链接（现实实体） |
| 语义 | 技术性 schema | 业务可理解 |
| 写回 | 只读分析 | Action Types（治理下的回写） |
| 治理粒度 | 表级权限 | 对象级/属性级/行级 |
| 关系 | ad-hoc JOIN | 预定义 Link Types |
| 消费者 | 分析师 | 运营人员 + 应用 + AI Agent |
| 数字孪生 | 无 | 整个组织建模 |
"Ontology as Tool Use"：AI Agent 的操作系统¶
这是 Palantir 最关键的架构洞见，也是与 harness-engineering 最深层的共鸣：
AI Agent
├── 读取 Object Types → 结构化、治理下的实时上下文
├── 调用 Action Types → 在真实世界执行操作（工具）
├── 查询 Functions → 获取计算后的业务逻辑结果
└── 受约束于 Governance → 安全/权限边界
Ontology 对 AI Agent 的价值： - Agent 不操作原始 SQL 或 API，而是操作有语义的对象和动作 - 治理层确保 Agent 在权限边界内操作，幻觉不会变成操作性灾难 - 对象 + 动作 = Agent 的 "感知-执行" 接口，Ontology 就是 Agent 的 Harness
这与 agent-runtime-architecture 的七层模型直接对应： - Object Types = Layer 2 REPL 中的能力面 - Action Types = Layer 4 Tool Runtime 的受控 syscall - Governance = Layer 5 Permission System 的四层决策链 - Functions = Layer 3 Query Loop 中的预取/业务逻辑
Ontology MCP Server（Beta）¶
Palantir 已将 Ontology 暴露为 MCP 工具服务器：
| Ontology MCP | Palantir MCP | |
|---|---|---|
| 目标用户 | 数据消费者 / 外部 AI Agent | Ontology 构建者 / 开发者 |
| 能力 | 读对象、执行动作、查询数据 | 70+ 开发工具修改 Ontology 结构 |
| 数据访问 | 生产数据（受控写入） | 仅 schema/结构 |
这意味着 Palantir 的专有 Ontology 通过 mcp-protocol 与开放生态连接——外部 AI Agent（Claude/Copilot 等）可以作为 MCP 客户端操作 Ontology 对象。
OSDK（Ontology SDK）¶
从 Ontology 定义自动生成强类型代码（类似 Prisma/GraphQL codegen）：
- TypeScript:
@osdk/client - Python / Java
- 定义 Object Type
Employee→ 自动生成 TS 接口、查询函数、Action helper - 类型安全 + IDE 自动补全
军事应用：战场的数字孪生¶
Ontology 的军事价值 = 战场空间的数字孪生：
| 概念 | 军事映射 |
|---|---|
| Object Type | 部队单位、装备、目标、地形 |
| Link Type | 指挥关系、威胁关联、补给线 |
| Action Type | 目标指派、资源调配、移动命令 |
| AI Agent | 实时决策支持（TITAN、Maven） |
关键合同：美国陆军 $10B/10 年（2025.07）、海军 ~$1B（2024.11）、英国国防部 GBP 315M。
Ontology 能在气隙网络和边缘设备上运行（通过 Apollo CD 平台），这是 Databricks/Snowflake 做不到的。
商业数据¶
| 指标 | 数据 |
|---|---|
| 2025 年收入 | $4.48B |
| 市值 | >$400B（2025） |
| 政府:商业 | 54:46 |
| 美国占比 | 74.4% |
| 估值倍数 | >600x 2024 PE |
批评与局限¶
- 深度供应商锁定：Object Types/Link Types/Actions 是专有抽象，无行业标准等价物。一旦建模，迁移成本极高
- 高成本 + 不透明定价：企业级定价，广泛被认为昂贵
- 前置建模成本高：需要大量组织变革，不只是技术部署
- 隐私争议：ICE 移民执法、NHS 数据、IDF 合作、预测性警务
- 估值泡沫：$4.5B 收入 vs $400B+ 市值，《经济学人》称其"可能是有史以来估值最过高的公司"
静态 vs 动态结构化引擎对照¶
Palantir AIP 是 Agent 三元论里 Refiner 类的企业级重装甲版本。它的特征是静态、长期、深度部署：
| 维度 | Palantir AIP（静态 / 重装甲） | 轻量 Refiner（动态 / 无人机蜂群） |
|---|---|---|
| 实施成本 | FDE（前沿部署工程师）驻场几个月 / 客单 $1M+ | 用户自助 / API 按需调用 / 客单 $50-500 |
| 数据状态 | 持久化 Ontology 数据库 / 长期治理 | 短期任务 / 数据用完即销毁 |
| 目标用户 | 政府 / 大企业 / 军方 | 中小企业 / 独立卖家 / 个人专业户 |
| Schema 来源 | 人工梳理 + Ontology 工程师参与 | 任务级动态生成（LLM 推断或 Schema-Driven 模板） |
| 商业模式 | 多年合同 + 软硬件深度集成 | outcome-based pricing（按结果付费） |
| 价值定位 | 企业治理基础设施 | 即用即走的"情报提纯" |
关键识别：Palantir AIP 在 Refiner 赛道占住"静态 + 重装甲"位置后，留下了一整片"动态 + 轻量"市场未被覆盖——这是为什么 Stripe Chargeback Defender / 跨境电商竞品分析 / 个人医疗账单争议等中小客单价的轻量 Refiner 应用有独立生态空间。
类比"Palantir for the rest of us"：用户不需要部署庞大的本地 Ontology 数据库，他只需要扔给系统 500 个杂乱网页或 100 份晦涩 PDF，10 分钟后吐出干净 Excel 或可视化图表。做完就销毁，极其轻量。
详见 agent-creator-refiner-operator 三元论。
FDE 模式被 frontier 模型公司行业级复刻（2026-05-04）¶
Palantir 商业模式两大核心组件 = Ontology（产品技术，本页）+ FDE（部署 + product formation 机制）。两者共同构成 Palantir 的 category-of-one 地位。
Anthropic / OpenAI 2026-05-04 同日宣布 PE-anchored FDE JV 把 FDE 模式 从 Palantir 一家专属，复刻成 frontier 模型公司的标准 mid-market 部署模式。这是 Palantir 哲学的外溢——不只 Ontology 概念被业界吸收（Sentino Memex 的 Object 化记忆 / sentino-agent 微型 Ontology），FDE 部署模式也被业界吸收。
关键差异：
| 维度 | Palantir FDE（自营 in-house） | Anthropic / OpenAI FDE（独立 JV 实体） |
|---|---|---|
| 法律主体 | Palantir 主体内部 unit | 独立 JV 实体（Anthropic JV / OpenAI DeployCo） |
| Product feedback loop | 强（FDE 学到的反哺产品团队） | a16z 警告：JV 实体可能丢失 feedback loop drift to pure services（详见 forward-deployed-engineer a16z 警告段） |
| 财务报表 | 拖累 Palantir 主体毛利率 | 不进主体合并报表，主体保持纯软件估值 multiple（详见 ipo-valuation-dual-track） |
| 资本动机 | Palantir 本身就是 services + software hybrid 估值 | Anthropic / OpenAI 主动用 JV 模式做估值套利（25× revenue vs 10× revenue 差距数千亿美元） |
对 Palantir 自身的潜在影响：如果 frontier 模型公司用"独立 JV + 纯软件主体"叙事获得显著估值优势，Palantir 是否会被市场质疑"为什么不剥离 services 业务获得 multiple uplift"——这是 Palantir 长期估值环境的新变量。
对 Sentino 的启示¶
Palantir Ontology 对 Sentino Agent 平台（→ sentino-agent）的启发：
- Standalone Agent 的数据查询 API 本质上就是一个微型 Ontology：Object Types = 设备状态/用户数据/传感器读数，Action Types = 控制设备/发通知，Functions = 业务规则
- "Ontology as Tool Use" 模式可直接复用：主 Agent 通过
read_xx工具读取 standalone agent 数据 = 通过 Ontology 对象获取上下文 - 治理层是 Enterprise 特性的架构支撑：Ontology 的对象级权限/审计与 Sentino SaaS 分层设计（普通用户极简 / Enterprise 治理层）同构
相关概念¶
- harness-engineering — Ontology 是 Harness 的一种企业级实现：语义层=上下文管理，动力层=工具执行，治理层=权限系统
- agent-runtime-architecture — Ontology 的 Object/Action/Governance 直接映射到七层模型的 Layer 2/4/5
- agent-tool-design — "对象=名词，动作=动词" 是工具设计从模型视角的极致体现
- mcp-protocol — Ontology MCP Server 将专有系统与开放 MCP 生态桥接
- claude-agent-sdk — SDK 的 Batteries-included 工具 vs Ontology 的 Action Types 是两种 Agent 工具提供方式
- platform-layer-collapse — Palantir 从数据层向 AI Agent 操作系统层坍缩，与 Anthropic 路径同构
- individual-vs-institutional-ai — Ontology 是组织 AI 的基础设施：组织的知识和操作被结构化为 Agent 可消费的对象
- sentino-agent — Sentino standalone agent 的数据服务模式可视为微型 Ontology
- agent-creator-refiner-operator — Palantir AIP 是 Refiner 类企业级重装甲代表；与轻量 Refiner（如 RootSwarm）形成"静态长期深度部署 vs 动态短期即用即走"对照
- forward-deployed-engineer — Palantir 立的 FDE 部署模式，2026-05-04 被 frontier 模型公司行业级复刻
- anthropic-openai-pe-jv-2026-05 — frontier 模型公司复刻 FDE 模式但用独立 JV 实体的标志事件
- ipo-valuation-dual-track — JV 实体而非 in-house unit 的财务动机，对 Palantir 自身估值环境是新变量