PalantirOSDKOntology开发者体验SDK代码生成
Palantir OSDK 深度解析：Ontology-first 开发范式如何重塑企业软件
深入解析 Palantir OSDK 的设计哲学与核心能力，对比传统 ORM 和 REST API，探索 Ontology-first 开发范式的变革意义。
Coomia 团队发布于 2025年6月1日22 分钟阅读
分享本文Twitter / X
#TL;DR
- Palantir OSDK 让开发者用 TypeScript/Python 像操作普通对象一样操作 Ontology 实体，背后是从 Ontology Schema 自动生成类型安全的客户端代码
- OSDK 的核心理念是"Ontology-first, not table-first"——开发者永远不需要写 SQL 或关心底层存储，所有操作都围绕业务对象（Object Type）和业务动作（Action）展开
- Coomia DIP 通过 Python SDK 的 OntoPlatform 门面（覆盖 28 个子模块、39 个 gRPC 客户端）和 TypeScript OSDK 代码生成器，实现了同等甚至更灵活的开发者体验
#1. 什么是 OSDK？
OSDK（Ontology Software Development Kit）是 Palantir 提供给开发者的官方 SDK，让开发者能用自己熟悉的编程语言（TypeScript 或 Python）直接与 Foundry 上的 Ontology 进行交互。
#OSDK 在 Palantir 生态中的位置
Code
+------------------------------------------------------------------+
| 开发者应用层 |
| +------------------+ +------------------+ +----------------+ |
| | Web App (React) | | Backend Service | | Data Pipeline | |
| | 使用 TS OSDK | | 使用 Python OSDK | | 使用 Python | |
| +--------+---------+ +--------+---------+ +-------+--------+ |
| | | | |
+-----------+----------------------+--------------------+-----------+
| | |
v v v
+------------------------------------------------------------------+
| OSDK 抽象层 |
| +------------------+ +------------------+ +----------------+ |
| | TypeScript OSDK | | Python OSDK | | REST API | |
| | 类型安全客户端 | | 类型安全客户端 | | （底层协议） | |
| +--------+---------+ +--------+---------+ +-------+--------+ |
| | | | |
+-----------+----------------------+--------------------+-----------+
| | |
v v v
+------------------------------------------------------------------+
| Ontology 层 |
| +------------+ +-----------+ +---------+ +----------------+ |
| | Object | | Link | | Action | | Function | |
| | Types | | Types | | Types | | Registry | |
| +------------+ +-----------+ +---------+ +----------------+ |
+------------------------------------------------------------------+
| | |
v v v
+------------------------------------------------------------------+
| 数据层 |
| +------------+ +-----------+ +----------------------------+ |
| | Datasets | | Streams | | External Sources | |
| +------------+ +-----------+ +----------------------------+ |
+------------------------------------------------------------------+
#OSDK 的核心能力
OSDK 提供了以下核心能力：
Code
+---------------------------+------------------------------------------+
| 能力 | 说明 |
+---------------------------+------------------------------------------+
| 类型安全的对象访问 | 编译时检查属性名和类型 |
| 对象查询和过滤 | 支持复杂的条件过滤、排序、聚合 |
| 关系遍历 | 通过 Link Type 在对象间导航 |
| Action 执行 | 调用预定义的业务操作 |
| Function 调用 | 执行注册在 Ontology 中的自定义逻辑 |
| 实时订阅 | 监听对象变更的实时推送 |
| 权限感知 | 自动遵守 Ontology 层面的权限控制 |
| 代码生成 | 从 Ontology Schema 自动生成客户端代码 |
+---------------------------+------------------------------------------+
#2. OSDK 的核心设计哲学：Ontology-first
理解 OSDK 最关键的一点是它的设计哲学：Ontology-first, not table-first（本体优先，而非表优先）。
#Table-first vs. Ontology-first
大多数开发者习惯的是 table-first 的开发模式：先有数据库表，然后用 ORM 映射到代码中的对象。OSDK 颠覆了这个模式：先定义 Ontology（业务对象和关系），然后由平台处理底层存储。
Code
Table-first（传统 ORM 模式）:
数据库表 --> ORM 映射 --> 代码对象
employees 表 Employee 类
+---------+-------+ class Employee:
| id | INT | id: int
| name | VARCHAR| name: str
| dept_id | INT | dept_id: int <-- 外键，需要手动 JOIN
+---------+-------+
问题：
- 开发者必须理解表结构和 SQL
- 关系通过外键和 JOIN 表达，容易出错
- 权限需要额外实现
- 业务语义在代码中，不在数据模型中
Ontology-first（OSDK 模式）:
Ontology 定义 --> 代码生成 --> 类型安全客户端
Employee Object Type Generated Code
+------------------+ const employee = await
| 属性： | client.objects.Employee
| name: string | .where({ dept: "Eng" })
| email: string | .fetchPage();
| role: string |
| 关系： | // 自动处理：
| department → | // - 底层存储查询
| Department | // - 关系遍历
| manages → | // - 权限过滤
| Employee[] | // - 类型检查
+------------------+
#为什么 Ontology-first 更优？
Code
+------------------+------------------+------------------------+
| 维度 | Table-first | Ontology-first |
+------------------+------------------+------------------------+
| 抽象级别 | 低（行和列） | 高（业务对象和关系） |
| 类型安全 | 运行时 | 编译时 |
| 关系表达 | 外键 + JOIN | 声明式链接 |
| 权限控制 | 需要额外代码 | 内置于 Ontology |
| Schema 变更 | 需要迁移脚本 | 平台自动处理 |
| 跨数据源 | 需要 ETL | 透明联邦查询 |
| AI 可理解性 | 低 | 高（语义化元数据） |
| 开发者学习曲线 | 低 | 中等（需要理解 Ontology）|
+------------------+------------------+------------------------+
#3. TypeScript SDK：类型安全的 Ontology 操作
Palantir 的 TypeScript OSDK 是前端和全栈开发者与 Ontology 交互的主要工具。
#安装和初始化
TypeScript
// 安装 (Palantir 风格）
// npm install @osdk/client @osdk/oauth
import { Client } from "@osdk/client";
import { createConfidentialOauthClient } from "@osdk/oauth";
// 初始化客户端
const auth = createConfidentialOauthClient({
clientId: "your-client-id",
clientSecret: "your-client-secret",
url: "https://your-foundry-instance.palantirfoundry.com",
});
const client = new Client({
auth,
baseUrl: "https://your-foundry-instance.palantirfoundry.com",
ontologyRid: "ri.ontology.main.ontology.abc-123",
});
#对象查询
TypeScript
// 获取所有 Employee 对象（分页）
const employees = await client.objects.Employee.fetchPage({
pageSize: 100,
});
// 条件过滤
const engineers = await client.objects.Employee
.where({
department: "Engineering",
startDate: { $gte: "2023-01-01" },
status: "Active",
})
.orderBy("name", "asc")
.fetchPage({ pageSize: 50 });
// 访问属性 —— 类型安全！
for (const emp of engineers.data) {
console.log(emp.name); // string -- 编译时确认
console.log(emp.salary); // number -- 编译时确认
// emp.nonExistent; // 编译错误！属性不存在
}
#关系遍历
TypeScript
// 获取一个 Employee 管理的所有下属
const manager = await client.objects.Employee.get("emp-123");
const directReports = await manager.links.manages.fetchPage();
// 获取 Employee 所属的 Department
const dept = await manager.links.department.get();
console.log(dept.name); // "Engineering"
// 链式遍历：获取 Department 下所有 Project
const projects = await dept.links.projects.fetchPage();
#聚合查询
TypeScript
// 按部门聚合平均薪资
const avgSalary = await client.objects.Employee
.aggregate({
select: {
salary: "avg",
__count: true,
},
groupBy: ["department"],
});
// 结果类型安全
avgSalary.data.forEach((group) => {
console.log(`${group.group.department}: $${group.values.salary.avg}`);
console.log(` 人数： ${group.values.__count}`);
});
#4. Python SDK：数据科学家的 Ontology 入口
Python OSDK 主要面向数据科学家和后端工程师，提供了与 TypeScript SDK 类似的类型安全体验。
#Palantir Python OSDK 使用示例
Python
from foundry.v2 import FoundryClient
# 初始化
client = FoundryClient(
auth=UserTokenAuth(hostname="https://your-instance.palantirfoundry.com",
token="your-token"),
)
# 查询对象
employees = client.ontology.objects.Employee.list(
page_size=100,
where={
"department": {"eq": "Engineering"},
"status": {"eq": "Active"},
},
order_by=[{"field": "name", "direction": "asc"}],
)
# 遍历结果
for emp in employees:
print(f"{emp.name} - {emp.role}")
# 执行 Action
result = client.ontology.actions.PromoteEmployee.apply(
employee_id="emp-123",
new_role="Senior Engineer",
effective_date="2024-01-01",
)
#Python 在数据管道中的使用
Python
import pandas as pd
# 将 Ontology 对象导出为 DataFrame
df = client.ontology.objects.SalesOrder.to_dataframe(
where={"status": "Completed", "year": 2024},
properties=["order_id", "customer", "amount", "region"],
)
# 用 pandas 做分析
summary = df.groupby("region")["amount"].agg(["sum", "mean", "count"])
print(summary)
# 将结果写回 Ontology（通过 Action）
for region, stats in summary.iterrows():
client.ontology.actions.UpdateRegionMetrics.apply(
region=region,
total_sales=stats["sum"],
avg_order_value=stats["mean"],
order_count=int(stats["count"]),
)
#5. 代码生成：从 Schema 到 SDK
OSDK 最强大的特性之一是自动代码生成——从 Ontology Schema 定义直接生成类型安全的客户端代码。
#代码生成流程
Code
+-------------------+
| Ontology Schema |
| （在 Foundry 中 |
| 定义 Object Type,|
| Link Type, |
| Action Type) |
+---------+---------+
|
v
+-------------------+
| Schema Export |
| (JSON/Protobuf) |
+---------+---------+
|
v
+-------------------+
| Code Generator |
| (@osdk/generator) |
+---------+---------+
|
+----> TypeScript 类型定义 (.ts)
| interface Employee {
| name: string;
| department: string;
| salary: number;
| links: {
| manages: Link<Employee[]>;
| department: Link<Department>;
| };
| }
|
+----> Python 类型定义 (.py)
class Employee(OntologyObject):
name: str
department: str
salary: float
# links auto-generated
#生成的代码结构
Code
generated/
├── objects/
│ ├── Employee.ts # Employee 对象类型定义
│ ├── Department.ts # Department 对象类型定义
│ ├── Project.ts # Project 对象类型定义
│ └── index.ts # 导出所有对象类型
├── actions/
│ ├── PromoteEmployee.ts # 升职 Action 定义
│ ├── TransferEmployee.ts # 调动 Action 定义
│ └── index.ts
├── links/
│ ├── EmployeeToDepartment.ts
│ ├── EmployeeManages.ts
│ └── index.ts
├── queries/ # 预定义查询
│ └── index.ts
└── index.ts # 主入口
#Schema 变更时的自动更新
当 Ontology Schema 变更时（比如给 Employee 添加一个新属性），重新运行代码生成器即可获得更新的类型定义。如果代码中引用了被删除的属性，TypeScript 编译器会立即报错——这是编译时安全性的核心价值。
Code
Schema 变更： Employee 添加 "location" 属性
之前的代码：
emp.name // OK
emp.salary // OK
emp.location // 编译错误！属性不存在
重新生成后：
emp.name // OK
emp.salary // OK
emp.location // OK -- 新属性可用
Schema 变更： Employee 删除 "fax" 属性
之前的代码：
emp.fax // OK
重新生成后：
emp.fax // 编译错误！属性已被删除
// 开发者必须处理这个变更
#6. Functions：在 Ontology 上编写逻辑
Functions 是 Palantir 允许开发者在 Ontology 之上编写自定义逻辑的机制。与传统的"存储过程"不同，Functions 运行在 Foundry 的安全容器中，可以访问 Ontology 对象并遵守权限约束。
#Function 定义示例
TypeScript
// 在 Foundry 中定义一个 Function
import {
Function,
OntologyEditFunction,
Edits,
Integer,
} from "@foundry/functions-api";
import { Employee, Department } from "@foundry/ontology-api";
export class EmployeeFunctions {
// 只读 Function：计算部门预算利用率
@Function()
public async departmentBudgetUtilization(
department: Department
): Promise<number> {
const employees = await department.links.employees.all();
const totalSalary = employees.reduce(
(sum, emp) => sum + (emp.salary ?? 0),
0
);
return totalSalary / (department.budget ?? 1);
}
// 编辑 Function：批量调薪
@OntologyEditFunction()
public async batchSalaryAdjustment(
department: Department,
percentageIncrease: number
): Promise<void> {
const employees = await department.links.employees.all();
for (const emp of employees) {
const currentSalary = emp.salary ?? 0;
emp.salary = currentSalary * (1 + percentageIncrease / 100);
}
}
}
#Function 与 Ontology 的关系
Code
+-------------------------------------------------------------------+
| Function 执行环境 |
| |
| +-------------------+ |
| | @Function() | 只读： 查询对象、计算结果、返回值 |
| +-------------------+ |
| |
| +-------------------+ |
| | @OntologyEdit | 读写： 可以创建、修改、删除对象 |
| | Function() | 所有修改作为事务提交 |
| +-------------------+ |
| | |
| v |
| +------------------------+ |
| | Ontology Transaction | |
| | - 权限检查 | |
| | - 约束验证 | |
| | - 审计日志 | |
| | - 原子提交 | |
| +------------------------+ |
+-------------------------------------------------------------------+
#7. Actions：封装业务操作
Actions 是 Palantir Ontology 中封装业务操作的机制。每个 Action 定义了输入参数、验证规则和执行逻辑，类似于 DDD 中的 Command。
#Action 定义
Code
Action Type: "TransferEmployee"
+-----------------------------+
| 参数： |
| employee_id: string （必填）|
| target_dept: string （必填）|
| effective_date: date |
| reason: string |
| |
| 验证规则： |
| - employee 必须存在 |
| - target_dept 必须存在 |
| - 日期不能是过去 |
| - 用户必须有转岗权限 |
| |
| 副作用： |
| - 修改 Employee.dept |
| - 创建 TransferRecord |
| - 通知 HR 系统 |
| - 记录审计日志 |
+-----------------------------+
#通过 OSDK 调用 Action
TypeScript
// TypeScript 调用
const result = await client.ontology.actions.TransferEmployee.apply({
employeeId: "emp-123",
targetDept: "dept-456",
effectiveDate: "2024-06-01",
reason: "Team restructuring",
});
// 结果包含执行状态和验证信息
if (result.validation.result === "VALID") {
console.log("Transfer completed successfully");
} else {
console.log("Validation errors:", result.validation.errors);
}
Python
# Python 调用
result = client.ontology.actions.TransferEmployee.apply(
employee_id="emp-123",
target_dept="dept-456",
effective_date="2024-06-01",
reason="Team restructuring",
)
#Action vs. 传统 API 调用
Code
+------------------+----------------------------+---------------------------+
| 维度 | 传统 REST API | Ontology Action |
+------------------+----------------------------+---------------------------+
| 定义位置 | 代码中（Controller） | Ontology Schema 中 |
| 验证 | 手动编写 | 声明式规则 |
| 权限 | 中间件/注解 | Ontology 权限模型 |
| 事务性 | 需要手动管理 | 自动事务 |
| 审计 | 需要手动记录 | 自动审计日志 |
| 可发现性 | Swagger/OpenAPI 文档 | Ontology 浏览器 |
| AI 可调用 | 需要 Function Calling 定义 | AIP 自动发现和调用 |
| 跨应用复用 | 需要微服务拆分 | 所有应用共享 |
+------------------+----------------------------+---------------------------+
#8. 开发者工作流：从编码到部署
Palantir 的完整开发者工作流覆盖了从编码到部署到监控的全生命周期。
#端到端工作流
Code
阶段 1: 设计 Ontology
+-------------------------------------------------------------------+
| Foundry Ontology Manager |
| |
| 1. 定义 Object Types (Employee, Department, Project, ...) |
| 2. 定义 Properties (name: string, salary: number, ...) |
| 3. 定义 Link Types (Employee --manages--> Employee, ...) |
| 4. 定义 Action Types (TransferEmployee, PromoteEmployee, ...) |
| 5. 配置权限和约束 |
+-------------------------------------------------------------------+
|
v
阶段 2: 生成 SDK
+-------------------------------------------------------------------+
| 代码生成器 |
| |
| $ osdk generate --ontology my-ontology --lang typescript |
| $ osdk generate --ontology my-ontology --lang python |
| |
| 输出： generated/ 目录下的类型定义文件 |
+-------------------------------------------------------------------+
|
v
阶段 3: 编写代码
+-------------------------------------------------------------------+
| 开发者 IDE (VSCode / IntelliJ) |
| |
| - 使用生成的类型定义获得 IntelliSense |
| - 编写 Functions （业务逻辑） |
| - 编写前端应用 (React + OSDK) |
| - 编写后端服务 (Node.js / Python + OSDK) |
+-------------------------------------------------------------------+
|
v
阶段 4: 测试
+-------------------------------------------------------------------+
| 本地测试 + Foundry 测试环境 |
| |
| - 单元测试： 模拟 OSDK 客户端 |
| - 集成测试： 连接测试 Ontology |
| - 端到端测试： 完整流程验证 |
+-------------------------------------------------------------------+
|
v
阶段 5: 部署
+-------------------------------------------------------------------+
| Foundry 部署管线 |
| |
| - Functions 部署到 Foundry 运行时 |
| - 前端应用部署到 Foundry Hosted App |
| - 自动化 CI/CD 集成 |
+-------------------------------------------------------------------+
|
v
阶段 6: 监控
+-------------------------------------------------------------------+
| Foundry 运营面板 |
| |
| - Function 执行日志和性能指标 |
| - Action 执行历史和审计追踪 |
| - 对象变更时间线 |
| - 告警和通知 |
+-------------------------------------------------------------------+
然而，Palantir 完整的工作流虽然强大，却完全绑定在其封闭生态中。对于需要自主部署或希望避免厂商锁定的企业，Coomia DIP 提供了同样完备的 Ontology-first 开发工作流，但基于开放标准和开源技术栈。
#9. 与传统方案对比：OSDK vs. ORM vs. REST API
为了更直观地理解 OSDK 的价值，让我们把它与传统的 ORM 和 REST API 方案做一个全面对比。
#同一需求的三种实现
需求：获取工程部门所有活跃员工，按入职日期排序，包含其所属项目信息。
方案 A：传统 SQL + ORM（SQLAlchemy）
Python
# 需要理解表结构、外键关系、SQL JOIN
from sqlalchemy import select, and_
from models import Employee, Department, ProjectAssignment, Project
stmt = (
select(Employee, Project)
.join(Department, Employee.dept_id == Department.id)
.outerjoin(
ProjectAssignment,
Employee.id == ProjectAssignment.employee_id
)
.outerjoin(
Project,
ProjectAssignment.project_id == Project.id
)
.where(
and_(
Department.name == "Engineering",
Employee.status == "Active",
)
)
.order_by(Employee.start_date.asc())
)
results = session.execute(stmt).all()
# 还需要手动处理：
# - 权限过滤（谁能看到哪些员工？）
# - 数据脱敏（薪资信息是否需要隐藏？）
# - 审计日志（谁在什么时候查询了什么？）
方案 B：REST API
Python
import requests
# 需要知道 API 端点、参数格式、分页逻辑
response = requests.get(
"https://api.example.com/v1/employees",
params={
"department": "Engineering",
"status": "Active",
"sort": "start_date:asc",
"include": "projects", # 需要 API 支持 include
"page_size": 100,
},
headers={"Authorization": f"Bearer {token}"},
)
employees = response.json()["data"]
# 如果 API 不支持 include，需要 N+1 查询：
for emp in employees:
projects_resp = requests.get(
f"https://api.example.com/v1/employees/{emp['id']}/projects",
headers={"Authorization": f"Bearer {token}"},
)
emp["projects"] = projects_resp.json()["data"]
方案 C：OSDK（Ontology-first）
TypeScript
// 不需要知道底层存储、不需要写 SQL、不需要处理 JOIN
const engineers = await client.objects.Employee
.where({
department: "Engineering",
status: "Active",
})
.orderBy("startDate", "asc")
.fetchPage({ pageSize: 100 });
// 关系遍历是一等公民
for (const emp of engineers.data) {
const projects = await emp.links.projects.all();
console.log(`${emp.name}: ${projects.map(p => p.name).join(", ")}`);
}
// 权限、脱敏、审计——全部由 Ontology 层自动处理
#全面对比矩阵
Code
+--------------------+------------------+------------------+------------------+
| 维度 | ORM (SQLAlchemy) | REST API | OSDK |
+--------------------+------------------+------------------+------------------+
| 学习曲线 | 中等 | 低 | 中等 |
| 类型安全 | 部分（运行时） | 无 | 完整（编译时） |
| 关系遍历 | 需要 JOIN | N+1 或 include | 一等公民 |
| 权限控制 | 手动实现 | 中间件 | 内置 |
| 审计日志 | 手动实现 | 手动实现 | 内置 |
| 数据脱敏 | 手动实现 | 手动实现 | 内置 |
| Schema 演进 | 迁移脚本 | API 版本控制 | 自动适配 |
| 跨数据源 | 多个连接器 | 多个 API | 透明联邦 |
| AI 集成 | 无 | 需要额外封装 | 原生支持（AIP) |
| 实时订阅 | 需要 CDC | WebSocket/SSE | 内置 |
| 代码量 | 多 | 中 | 少 |
| 调试复杂度 | 高（SQL跟踪） | 中（HTTP跟踪） | 低（Ontology视图） |
+--------------------+------------------+------------------+------------------+
当然，Palantir 的 OSDK 虽然技术上令人赞叹，但其封闭的生态和高昂的许可费用（年费 $1M+）意味着大多数企业无法享受这种开发体验。Coomia DIP 基于同样的 Ontology-first 理念，提供完全开源的 SDK，让任何规模的团队都能获得相同的开发范式优势。
#10. Coomia DIP 的实现：Python SDK + TypeScript OSDK
Coomia DIP 在开发者体验方面采取了与 Palantir OSDK 相同的哲学，但在实现上有自己的特色。
#架构对比
Code
Palantir OSDK Coomia DIP SDK
+--------------------+ +--------------------+
| TypeScript OSDK | | TypeScript OSDK |
| (npm package) | | （代码生成器） |
+--------------------+ +--------------------+
| Python OSDK | | Python SDK |
| (pip package) | | (OntoPlatform) |
+--------------------+ +--------------------+
| |
REST API gRPC (39个客户端）
| |
+--------------------+ +--------------------+
| Foundry Backend | | 8-Plane Backend |
| （封闭源码） | | （开源） |
+--------------------+ +--------------------+
#OntoPlatform 门面：28 个子模块
Coomia DIP 的 Python SDK 核心是 OntoPlatform 类——一个统一的门面（Facade），覆盖了平台的所有能力：
Python
from ontology_sdk import OntoPlatform
# 初始化——一行代码连接整个平台
platform = OntoPlatform(
host="localhost:50051",
project_id="proj-001",
world_id="world-main",
)
# 28 个子模块，每个对应一个领域
platform.ontology # Ontology CRUD
platform.objects # 对象实例操作
platform.query # 查询引擎
platform.actions # Action 执行
platform.functions # Function 管理
platform.decisions # 决策树
platform.reasoning # 规则推理
platform.scenarios # 场景模拟
platform.worlds # World/Branch 管理
platform.pipelines # 数据管道
platform.analytics # 分析查询
platform.search # 全文搜索
platform.subscription # 实时订阅
platform.metrics # 指标管理
platform.governance # 审计治理
platform.auth # 认证授权
platform.data_export # 数据导出
platform.datasources # 数据源管理
platform.tenants # 租户管理
platform.instance_detail # 对象聚合详情
# ... 共 28 个子模块
#实际使用示例
Python
from ontology_sdk import OntoPlatform
platform = OntoPlatform(
host="localhost:50051",
project_id="proj-001",
world_id="world-main",
)
# 1. 定义 Object Type
platform.ontology.create_object_type(
name="Employee",
properties=[
{"name": "name", "type": "STRING", "required": True},
{"name": "email", "type": "STRING", "required": True},
{"name": "department", "type": "STRING"},
{"name": "salary", "type": "DOUBLE"},
{"name": "start_date", "type": "DATE"},
],
primary_key="employee_id",
)
# 2. 创建对象实例
platform.objects.create("Employee", {
"employee_id": "emp-001",
"name": "Alice Chen",
"email": "alice@example.com",
"department": "Engineering",
"salary": 120000,
"start_date": "2023-06-15",
})
# 3. 查询对象
results = platform.query.find_objects(
object_type="Employee",
filters={"department": {"eq": "Engineering"}},
order_by=[{"field": "name", "direction": "ASC"}],
page_size=50,
)
# 4. 执行 Action
platform.actions.execute(
action_type="PromoteEmployee",
params={
"employee_id": "emp-001",
"new_role": "Senior Engineer",
"effective_date": "2024-01-01",
},
)
# 5. 规则推理
inference = platform.reasoning.infer(
ruleset_id="salary-band-rules",
input_data={"role": "Senior Engineer", "years_exp": 5, "location": "Beijing"},
)
print(f"推荐薪资范围： {inference.result}")
# 6. 决策树执行
decision = platform.decisions.execute(
tree_id="hiring-approval",
variables={"candidate_level": "senior", "budget_remaining": 500000},
)
print(f"决策结果： {decision.outcome}")
# 7. 场景模拟
scenario = platform.scenarios.fork_world(
name="2025-budget-scenario",
description="模拟 2025 年预算削减 20% 的影响",
)
#Palantir vs. Coomia DIP 开发者体验对比
Code
+----------------------+---------------------+-------------------------+
| 维度 | Palantir OSDK | Coomia DIP SDK |
+----------------------+---------------------+-------------------------+
| 语言支持 | TypeScript, Python | Python （完整）, TS （生成） |
| 协议 | REST + WebSocket | gRPC + WebSocket + SSE |
| 门面模式 | 按资源拆分 | OntoPlatform 统一门面 |
| gRPC 客户端数量 | N/A (REST) | 39 个专用客户端 |
| 子模块数量 | ~15 | 28 |
| 代码生成 | 有 | 有 |
| Async 支持 | 有 | 有 |
| 流式支持 | 有限 | 原生 gRPC streaming |
| 开源 | 否 | 是 |
| 自部署 | 否 | 是 |
| 推理/决策 SDK | 通过 AIP | 原生集成（9个推理客户端）|
| 场景模拟 SDK | 有限 | 原生 World Fork |
+----------------------+---------------------+-------------------------+
#Key Takeaways
-
OSDK 的核心价值不在于"又一个 SDK"，而在于"Ontology-first"的开发范式转变。 开发者不再需要关心底层存储、JOIN 逻辑和权限实现——所有这些都由 Ontology 层自动处理。这种范式让 AI（通过 AIP）也能理解和操作业务系统。
-
代码生成是类型安全的关键。 从 Ontology Schema 自动生成的类型定义让开发者在编译时就能捕获 Schema 变更导致的错误，而不是在运行时才发现。这大大降低了大型系统的维护成本。
-
Coomia DIP 的 Python SDK 在深度上已经超过了 Palantir OSDK——28 个子模块、39 个 gRPC 客户端、原生推理/决策/场景模拟集成。 开源和 gRPC 原生支持是关键差异化优势，允许更灵活的部署和更高的性能。
#想要 Palantir 级别的能力？试试 Coomia DIP
Palantir 的技术理念令人赞叹，但其高昂的价格和封闭的生态让大多数企业望而却步。Coomia DIP 基于相同的 Ontology 驱动理念，提供开源、透明、可私有化部署的数据智能平台。
- AI 管线构建器：用自然语言描述，自动生成生产级数据管线
- 业务本体：像 Palantir 一样建模你的业务世界，但完全开放
- 决策智能：内置规则引擎和假设分析，数据驱动每一个决策
- 开放架构：基于 Flink、Doris、Kafka 等开源技术栈，零锁定
相关文章
Palantir开源Ontology
为什么我们要做开源版 Palantir？Coomia DIP 的愿景与路线图
Palantir 无法服务全球 70% 的企业市场，Coomia DIP 用开源方式让 Ontology 驱动的智能决策能力成为每个企业都能使用的基础设施。
Coomia 团队2025年6月6日25min
阅读全文Palantir股价分析数据平台
Palantir 股价从 $6 到 $80：资本市场读懂了什么？
深度分析 Palantir 股价从 IPO 低谷到历史新高的完整旅程，解读 AIP 催化剂、Rule of 40 突破以及 Ontology 驱动平台的估值逻辑。
Coomia 团队2025年5月26日21min
阅读全文Palantir竞争格局数据平台
为什么没人能复制 Palantir？7 层技术壁垒深度分析
深度分析 Palantir 的 7 层技术壁垒，解读 Databricks、Snowflake、C3.ai 等竞品为何无法复制其完整能力栈，以及开源替代方案的机会。
Coomia 团队2025年5月21日24min
阅读全文