Palantir 的 Actions 和 Rules：从数据洞察到业务操作的桥梁
每个使用过 BI 工具的人都经历过这个场景：
Coomia发布于 2025年6月12日26 分钟阅读
分享本文Twitter / X
Palantir 的 Actions 和 Rules：从数据洞察到业务操作的桥梁
“系列：S1 Palantir 解密 · 第 11 篇 | 难度：入门 | 阅读时间：15 分钟
#TL;DR
- Palantir Actions 是将数据洞察转化为业务操作的核心机制——每个 Action 都是一个原子化的、可审计的、带权限控制的业务操作单元，包含参数校验、前置条件、副作用声明和权限约束。
- Rules 引擎通过"条件 -> 触发 -> 动作链"的模式实现自动化决策，让系统不只是"看到问题"，而是"自动处理问题"——这是 Palantir 区别于所有 BI 平台的根本性差异。
- coomia-dip 通过 ActionEngine（10 种执行器类型）和 ReasoningEngine（规则引擎）完整实现了这一闭环，并支持 Python/TypeScript/Groovy/WASM/Kotlin 五种语言的 Function 沙箱。
#引言：BI 平台的终极困境——"看到了，然后呢？"
每个使用过 BI 工具的人都经历过这个场景：
Code
传统 BI 平台的使用流程：
第 1 步：看到报表
┌──────────────────────────────────┐
│ 库存预警仪表盘 │
│ │
│ 物料 A-2047: 库存 12 件 (低于安全库存 50 件)
│ 物料 B-1193: 库存 0 件 (已断货!)
│ 物料 C-0872: 库存 8 件 (低于安全库存 30 件)
│ │
│ [导出 Excel] │
└──────────────────────────────────┘
第 2 步：打开邮件客户端，写邮件给采购
第 3 步：采购收到邮件，打开 ERP 系统
第 4 步：在 ERP 中查找供应商信息
第 5 步：创建采购订单
第 6 步：等待审批
第 7 步：审批通过，发送给供应商
第 8 步：跟踪到货状态...
整个过程涉及 4 个系统、3 个人、至少 2 天时间。
而断货每天造成的损失是 ¥50,000。
问题的根源在于：传统 BI 只解决了"看到"，没有解决"做到"。
Palantir 的 Actions 和 Rules 正是为了弥合这个鸿沟。
Code
Palantir 的闭环流程：
┌──────────────────────────────────┐
│ 库存预警仪表盘 │
│ │
│ 物料 A-2047: 库存 12 件 │
│ [一键补货] [切换供应商] [暂停产线] │
│ │
│ > 规则已自动触发： │
│ - 已向首选供应商发送补货请求 │
│ - 已通知仓储经理 │
│ - 已调整生产计划优先级 │
└──────────────────────────────────┘
同一个场景：0 个额外系统、0 封邮件、30 秒完成。
这就是"数据到行动的闭环"——Palantir 最核心的竞争力之一。
#一、Action 的内部解剖
#1.1 什么是 Action？
在 Palantir Foundry 中，Action 是一个结构化的业务操作单元。它不是简单的 API 调用，而是一个包含完整语义信息的操作描述：
Code
Action 的完整结构：
┌─────────────────────────────────────────────┐
│ ActionType: "补货下单" │
│ │
│ ┌─────────────────────────────────────────┐ │
│ │ Parameters (参数) │ │
│ │ - materialId: ObjectReference<Material> │ │
│ │ - quantity: Integer (min: 1, max: 10000)│ │
│ │ - supplierId: ObjectReference<Supplier> │ │
│ │ - urgency: Enum(NORMAL, URGENT, CRITICAL)│ │
│ │ - notes: String (optional) │ │
│ └─────────────────────────────────────────┘ │
│ │
│ ┌─────────────────────────────────────────┐ │
│ │ Preconditions (前置条件) │ │
│ │ - material.status != DISCONTINUED │ │
│ │ - supplier.status == ACTIVE │ │
│ │ - user.role IN [BUYER, MANAGER] │ │
│ │ - quantity <= material.maxOrderQuantity │ │
│ └─────────────────────────────────────────┘ │
│ │
│ ┌─────────────────────────────────────────┐ │
│ │ Side Effects (副作用声明) │ │
│ │ - CREATE PurchaseOrder │ │
│ │ - UPDATE Material.lastOrderDate │ │
│ │ - CREATE Notification → warehouse_mgr │ │
│ └─────────────────────────────────────────┘ │
│ │
│ ┌─────────────────────────────────────────┐ │
│ │ Permissions (权限约束) │ │
│ │ - REQUIRES: procurement:order:create │ │
│ │ - REQUIRES: material:read │ │
│ │ - IF urgency == CRITICAL: │ │
│ │ REQUIRES: procurement:emergency │ │
│ └─────────────────────────────────────────┘ │
│ │
│ ┌─────────────────────────────────────────┐ │
│ │ Validation Rules (校验规则) │ │
│ │ - totalCost <= user.approvalLimit │ │
│ │ - supplier NOT IN blacklist │ │
│ │ - delivery_date within fiscal_year │ │
│ └─────────────────────────────────────────┘ │
└─────────────────────────────────────────────┘
#1.2 ActionType 的六大组成部分
| 组成部分 | 作用 | 示例 |
|---|---|---|
| Parameters | 定义操作需要的输入 | 物料ID、数量、供应商 |
| Preconditions | 操作执行前必须满足的条件 | 物料未停产、供应商活跃 |
| Side Effects | 声明操作会产生的影响 | 创建订单、更新库存 |
| Permissions | 需要的权限集合 | 采购员或经理角色 |
| Validation | 业务规则校验 | 金额不超过审批额度 |
| Audit Config | 审计配置 | 记录操作人、时间、变更详情 |
#1.3 为什么"副作用声明"如此重要？
传统系统中，一个 API 调用会做什么，只有看代码才知道。Palantir 的 Action 把所有副作用显式声明出来：
Code
传统 API： Palantir Action：
POST /api/restock ActionType: Restock
Body: {materialId, qty} Side Effects:
- CREATE PurchaseOrder
返回: {success: true} - UPDATE Material.lastOrderDate
- UPDATE Material.pendingQty
// 实际做了什么？ - CREATE AuditLog
// 谁知道呢... - SEND Notification → buyer
// 得看 500 行代码
// 一眼就知道会发生什么
这使得：
- 权限系统可以精确知道需要检查哪些对象的哪些权限
- 审计系统可以精确记录每个变更
- 回滚机制知道需要撤销哪些操作
- 影响分析可以在执行前展示给用户
#二、Action 的执行生命周期
#2.1 从按钮点击到操作完成
Code
用户点击 [补货]
│
▼
┌──────────────┐
│ 1. 参数收集 │ ← 弹出表单，填写数量、选择供应商
│ & 校验 │ ← 实时校验：数量范围、供应商状态
└──────┬───────┘
│
▼
┌──────────────┐
│ 2. 前置条件 │ ← 检查物料是否可订购
│ 检查 │ ← 检查供应商是否活跃
└──────┬───────┘
│ 条件通过
▼
┌──────────────┐
│ 3. 权限检查 │ ← 用户是否有下单权限？
│ │ ← 金额是否超过审批限额？
└──────┬───────┘
│ 权限通过
▼
┌──────────────┐
│ 4. 影响预览 │ ← "此操作将创建 1 个采购订单，
│ (Dry Run) │ 预计金额 ¥12,500"
└──────┬───────┘
│ 用户确认
▼
┌──────────────┐
│ 5. 事务执行 │ ← 在一个事务中执行所有副作用
│ │ ← 原子性：要么全成功，要么全回滚
└──────┬───────┘
│
▼
┌──────────────┐
│ 6. 审计记录 │ ← 记录操作人、时间、参数、结果
│ │ ← 记录前后状态快照
└──────┬───────┘
│
▼
┌──────────────┐
│ 7. 后续触发 │ ← 触发关联的 Rules
│ │ ← 发送通知
└──────────────┘
#2.2 Dry Run（试运行）机制
Palantir 的 Dry Run 是一个极其强大的功能——在不实际执行的情况下，预览操作的全部影响：
Python
# Dry Run 返回的预览信息
{
"action": "Restock",
"preview": {
"objects_created": [
{"type": "PurchaseOrder", "properties": {
"supplier": "ABC Electronics",
"total_amount": 12500,
"expected_delivery": "2026-04-10"
}}
],
"objects_modified": [
{"type": "Material", "id": "A-2047", "changes": {
"pending_quantity": {"before": 0, "after": 100},
"last_order_date": {"before": "2026-02-15", "after": "2026-03-24"}
}}
],
"notifications": [
{"to": "warehouse_mgr", "template": "new_order_placed"}
],
"estimated_cost": 12500,
"requires_approval": False
}
}
用户在确认前就能看到所有将要发生的变更——这在传统系统中几乎是不可能的。
#三、Rules 引擎——自动化决策
#3.1 从"人工发现问题"到"系统自动处理"
Rules 是 Palantir 的自动化决策引擎。它的核心模式是：
Code
条件 (Condition) ──→ 触发 (Trigger) ──→ 动作链 (Action Chain)
示例：
┌─────────────────────────┐
│ Rule: 库存自动补货 │
├─────────────────────────┤
│ │
│ WHEN: │
│ material.stock_level │
│ < material.safety_stock │
│ AND material.status │
│ == ACTIVE │
│ │
│ THEN: │
│ 1. 计算补货数量 │
│ (EOQ 公式) │
│ 2. 选择最优供应商 │
│ (价格 + 交期 + 评级) │
│ 3. 创建采购订单 │
│ 4. 通知仓储经理 │
│ 5. 更新库存预测 │
│ │
│ UNLESS: │
│ 已有未完成的补货订单 │
│ OR 物料即将停产 │
│ │
│ THROTTLE: │
│ 同一物料 24 小时内 │
│ 最多触发 1 次 │
└─────────────────────────┘
#3.2 Rule 的三种触发模式
| 模式 | 触发时机 | 适用场景 | 示例 |
|---|---|---|---|
| 事件驱动 | 对象状态变化时 | 实时响应 | 库存低于阈值立即补货 |
| 定时驱动 | 按 Cron 表达式 | 定期检查 | 每日凌晨检查过期合同 |
| 手动触发 | 用户主动执行 | 批量处理 | 季末批量审核供应商 |
#3.3 规则链——复杂场景的编排
真实业务场景往往不是单一规则能处理的。Palantir 支持规则链（Rule Chain）：
Code
规则链示例：设备异常处理
事件: 传感器温度 > 阈值
│
▼
┌────────────────────┐
│ Rule 1: 初步评估 │
│ IF temp > 80°C │
│ AND duration > 5min│
│ THEN: 创建告警 │
│ severity=WARN │
└────────┬───────────┘
│ 告警创建事件
▼
┌────────────────────┐
│ Rule 2: 升级判断 │
│ IF temp > 95°C │
│ OR 同设备 24h 内 │
│ 第 3 次告警 │
│ THEN: 升级为 CRITICAL│
│ 通知值班经理 │
└────────┬───────────┘
│ 升级事件
▼
┌────────────────────┐
│ Rule 3: 自动处置 │
│ IF severity == │
│ CRITICAL │
│ AND 设备类型支持 │
│ 远程控制 │
│ THEN: 降低功率到 50%│
│ 创建维修工单 │
│ 通知维修团队 │
└────────┬───────────┘
│ 维修工单创建
▼
┌────────────────────┐
│ Rule 4: 产线调整 │
│ IF 关键设备停机 │
│ THEN: 重新排产 │
│ 通知下游工序 │
│ 更新交付预测 │
└────────────────────┘
这四条规则各自独立定义，但通过事件链自动串联。这就是规则引擎的强大之处——每条规则都简单，但组合起来可以处理极其复杂的场景。
#四、Functions——用户自定义逻辑
#4.1 Functions 的定位
当 Actions 和 Rules 的内置能力不够时，用户可以编写自定义 Functions。Functions 在 Palantir 中的定位是：
Code
复杂度光谱：
简单 ◄──────────────────────────────────► 复杂
[内置 Action] [Rules 编排] [Functions] [Pipeline]
点击按钮 条件触发 自定义逻辑 数据管道
即可执行 自动处理 需要编程 需要设计
#4.2 Functions 的编写方式
Palantir 支持在 TypeScript 和 Python 中编写 Functions：
TypeScript
// TypeScript Function 示例：计算最优补货供应商
import { Function, OntologyObject } from "@palantir/functions-api";
@Function()
export function selectOptimalSupplier(
material: OntologyObject<"Material">,
requiredQuantity: number
): OntologyObject<"Supplier"> {
// 获取该物料的所有活跃供应商
const suppliers = material.suppliers
.filter(s => s.status === "ACTIVE")
.filter(s => s.available_capacity >= requiredQuantity);
if (suppliers.length === 0) {
throw new UserFacingError("没有可用的供应商能满足该订单量");
}
// 按综合评分排序：价格 40% + 交期 30% + 质量评级 30%
return suppliers.sort((a, b) => {
const scoreA = a.unit_price * 0.4
+ a.avg_delivery_days * 0.3
+ (5 - a.quality_rating) * 0.3;
const scoreB = b.unit_price * 0.4
+ b.avg_delivery_days * 0.3
+ (5 - b.quality_rating) * 0.3;
return scoreA - scoreB;
})[0];
}
Python
# Python Function 示例：异常检测
from palantir.functions import function
from palantir.ontology import ObjectSet
@function()
def detect_anomalies(
equipment_id: str,
lookback_hours: int = 24
) -> list[dict]:
"""检测设备传感器数据中的异常模式"""
readings = Objects.search("SensorReading") \
.filter(equipment_id=equipment_id) \
.filter(timestamp__gte=now() - hours(lookback_hours)) \
.order_by("timestamp") \
.all()
anomalies = []
window_size = 10
for i in range(window_size, len(readings)):
window = readings[i - window_size:i]
mean = sum(r.value for r in window) / window_size
std = (sum((r.value - mean) ** 2 for r in window) / window_size) ** 0.5
if abs(readings[i].value - mean) > 3 * std:
anomalies.append({
"timestamp": readings[i].timestamp,
"value": readings[i].value,
"expected_range": [mean - 3 * std, mean + 3 * std],
"severity": "HIGH" if abs(readings[i].value - mean) > 5 * std else "MEDIUM"
})
return anomalies
#4.3 Functions 的安全沙箱
Functions 不是在用户的机器上运行的——它们运行在 Palantir 的安全沙箱中：
Code
Function 执行环境：
┌──────────────────────────────────────────┐
│ Palantir Function Runtime │
│ │
│ ┌────────────────────────────────────┐ │
│ │ 安全沙箱 │ │
│ │ ┌──────────────────────────────┐ │ │
│ │ │ 用户 Function 代码 │ │ │
│ │ │ - 只能访问声明的 Ontology 对象│ │ │
│ │ │ - 不能直接访问网络/文件系统 │ │ │
│ │ │ - 执行时间限制（默认 30s） │ │ │
│ │ │ - 内存限制（默认 256MB） │ │ │
│ │ └──────────────────────────────┘ │ │
│ │ │ │
│ │ ┌──────────────────────────────┐ │ │
│ │ │ Ontology API (受限接口) │ │ │
│ │ │ - Objects.search() │ │ │
│ │ │ - Objects.get() │ │ │
│ │ │ - Actions.apply() │ │ │
│ │ └──────────────────────────────┘ │ │
│ └────────────────────────────────────┘ │
│ │
│ 权限继承自调用者 ← 关键安全设计 │
└──────────────────────────────────────────┘
#五、Webhook 集成与批量操作
#5.1 Webhook——连接外部世界
Actions 不仅可以操作 Ontology 内部的对象，还可以通过 Webhook 连接外部系统：
Code
Webhook Action 流程：
┌──────────┐ ┌──────────────┐ ┌──────────────┐
│ Palantir │ │ Webhook │ │ 外部系统 │
│ Action │────→│ Gateway │────→│ (ERP/CRM/ │
│ │ │ - 签名验证 │ │ MES/...) │
│ │ │ - 重试机制 │ │ │
│ │ │ - 超时控制 │ │ │
└──────────┘ └──────┬───────┘ └──────┬───────┘
│ │
│ 回调确认 │
│◄────────────────────┘
│
▼
┌──────────────┐
│ 更新操作状态 │
│ 记录审计日志 │
└──────────────┘
Webhook 配置示例：
JSON
{
"actionType": "sync_order_to_erp",
"webhook": {
"url": "https://erp.company.com/api/v2/purchase-orders",
"method": "POST",
"headers": {
"Authorization": "Bearer ${secrets.erp_token}",
"Content-Type": "application/json"
},
"body_template": {
"order_id": "${action.params.orderId}",
"material_code": "${object.Material.code}",
"quantity": "${action.params.quantity}",
"supplier_code": "${object.Supplier.erp_code}"
},
"retry": {
"max_attempts": 3,
"backoff": "exponential",
"initial_delay_ms": 1000
},
"timeout_ms": 30000,
"success_condition": "response.status == 201"
}
}
#5.2 批量 Actions
处理大规模数据时，逐条执行 Action 效率太低。Palantir 支持批量操作：
Code
批量 Action 执行：
输入: 2,847 个需要更新状态的订单
┌────────────────────────────────────────┐
│ Batch Action: 批量更新订单状态 │
│ │
│ 分批策略: 每批 100 条 │
│ │
│ Batch 1: [###########] 100/100 ✓ │
│ Batch 2: [###########] 100/100 ✓ │
│ Batch 3: [###########] 100/100 ✓ │
│ ... │
│ Batch 28: [###########] 100/100 ✓ │
│ Batch 29: [####### ] 47/100 ✓ │
│ │
│ 结果: 2,841 成功 / 6 失败 │
│ 失败原因: │
│ - 3 条: 订单已被其他用户修改 │
│ - 2 条: 供应商已停用 │
│ - 1 条: 权限不足 │
│ │
│ [重试失败项] [导出失败报告] [查看详情] │
└────────────────────────────────────────┘
批量操作的关键设计原则：
| 原则 | 说明 |
|---|---|
| 部分失败容忍 | 单条失败不影响其他记录 |
| 进度可见 | 实时显示处理进度 |
| 失败可重试 | 只重试失败的记录 |
| 审计完整 | 每条记录独立审计 |
| 并发控制 | 乐观锁防止冲突 |
#六、Action 审计链路
#6.1 为什么审计如此重要？
在金融、医疗、政府等受监管行业，"谁在什么时候做了什么"不是可选项，而是法律要求。
Code
Action 审计记录结构：
┌────────────────────────────────────────────────────┐
│ Audit Entry │
│ │
│ Action ID: act_20260324_143052_a7b3c │
│ Action Type: UpdateOrderStatus │
│ Timestamp: 2026-03-24T14:30:52.847Z │
│ User: zhang.wei@company.com │
│ User Role: procurement_manager │
│ IP Address: 10.0.12.47 │
│ Session: sess_x8k2m │
│ │
│ Parameters: │
│ orderId: PO-2026-00847 │
│ newStatus: APPROVED │
│ comment: "价格已确认，批准采购" │
│ │
│ Affected Objects: │
│ PurchaseOrder/PO-2026-00847: │
│ status: PENDING → APPROVED │
│ approved_by: null → zhang.wei │
│ approved_at: null → 2026-03-24T14:30:52Z │
│ │
│ Triggered Rules: │
│ - rule_auto_notify_supplier (SUCCESS) │
│ - rule_update_budget_consumed (SUCCESS) │
│ │
│ Execution Time: 127ms │
│ Result: SUCCESS │
└────────────────────────────────────────────────────┘
#6.2 审计的不可篡改性
Code
审计日志存储架构：
Action 执行
│
▼
┌────────────┐ ┌────────────┐ ┌────────────┐
│ 同步写入 │ │ 异步归档 │ │ 合规检查 │
│ 操作日志 │───→│ 长期存储 │───→│ 定期审计 │
│ (Append- │ │ (对象存储) │ │ 报告生成 │
│ Only DB) │ │ 不可修改 │ │ │
└────────────┘ └────────────┘ └────────────┘
│
│ 完整性保证
▼
┌────────────┐
│ 哈希链验证 │
│ 每条记录的 │
│ hash 包含 │
│ 上一条的 │
│ hash │
└────────────┘
#七、coomia-dip 如何实现 Actions 和 Rules
#7.1 ActionEngine 的 10 种执行器
coomia-dip 的 ActionEngine 提供了 10 种执行器类型，覆盖所有常见的业务操作场景：
Code
coomia-dip ActionEngine 架构：
┌──────────────┐
│ ActionEngine │
│ (调度器) │
└──────┬───────┘
│
┌───────────────┼───────────────┐
│ │ │
┌─────┴─────┐ ┌─────┴─────┐ ┌─────┴─────┐
│ 对象操作 │ │ 关系操作 │ │ 扩展操作 │
└─────┬─────┘ └─────┬─────┘ └─────┬─────┘
│ │ │
┌──────┼──────┐ ┌───┴───┐ ┌──────┼──────────┐
│ │ │ │ │ │ │ │ │
▼ ▼ ▼ ▼ ▼ ▼ ▼ ▼ ▼
Create Update Delete Create Delete Invoke Web- Noti- Simple Composite
Object Object Object Rela. Rela. Func. hook fic. Op Op
| 执行器 | 功能 | 示例 |
|---|---|---|
| CreateObject | 创建 Ontology 对象 | 创建采购订单 |
| UpdateObject | 更新对象属性 | 修改订单状态 |
| DeleteObject | 删除对象（软删除） | 取消作废的订单 |
| CreateRelation | 创建对象间关系 | 关联订单与供应商 |
| DeleteRelation | 删除对象间关系 | 解除供应商绑定 |
| InvokeFunction | 调用自定义函数 | 运行价格计算逻辑 |
| Webhook | 调用外部 HTTP 接口 | 同步数据到 ERP |
| Notification | 发送通知 | 邮件/短信/站内信 |
| SimpleOp | 简单表达式运算 | 字段赋值、数学计算 |
| CompositeOp | 组合多个操作 | 编排复杂业务流程 |
#7.2 CompositeOp——操作编排
CompositeOp 是最强大的执行器类型，它可以将多个操作编排成一个事务：
Python
# coomia-dip CompositeOp 定义示例
from ontology_sdk import ActionBuilder, CompositeOp
restock_action = ActionBuilder("restock_material") \
.parameter("material_id", type="object_ref", object_type="Material") \
.parameter("quantity", type="integer", min=1) \
.precondition("material.status == 'ACTIVE'") \
.precondition("material.stock_level < material.safety_stock") \
.composite_op([
CompositeOp.invoke_function(
"select_optimal_supplier",
args={"material_id": "${params.material_id}",
"quantity": "${params.quantity}"},
output_as="selected_supplier"
),
CompositeOp.create_object(
"PurchaseOrder",
properties={
"material_id": "${params.material_id}",
"supplier_id": "${steps.selected_supplier.id}",
"quantity": "${params.quantity}",
"status": "PENDING",
"created_by": "${context.user.id}"
},
output_as="new_order"
),
CompositeOp.update_object(
"${params.material_id}",
updates={
"pending_quantity": "${object.pending_quantity + params.quantity}",
"last_order_date": "${now()}"
}
),
CompositeOp.notification(
template="new_order_created",
recipients=["warehouse_manager"],
data={"order_id": "${steps.new_order.id}"}
)
]) \
.build()
#7.3 ReasoningEngine——规则引擎实现
coomia-dip 的 ReasoningEngine 是规则引擎的核心，它实现了完整的条件评估和动作触发：
Code
coomia-dip ReasoningEngine 架构：
┌─────────────────────────────────────────────────┐
│ ReasoningEngine │
│ │
│ ┌───────────────┐ ┌───────────────────────┐ │
│ │ Event Bus │────→│ Rule Matcher │ │
│ │ (事件总线) │ │ 匹配触发条件 │ │
│ │ │ │ │ │
│ │ - ObjectChanged│ │ Condition Evaluator: │ │
│ │ - TimerFired │ │ - Property comparisons │ │
│ │ - ActionDone │ │ - Aggregation checks │ │
│ │ - ExternalEvent│ │ - Time-based conditions│ │
│ └───────────────┘ │ - Cross-object queries │ │
│ └───────────┬─────────────┘ │
│ │ │
│ ▼ │
│ ┌───────────────────────┐ │
│ │ Action Chain Executor │ │
│ │ 按顺序执行动作链 │ │
│ │ │ │
│ │ Step 1 → Step 2 → ... │ │
│ │ │ │
│ │ 支持: │ │
│ │ - 条件分支 │ │
│ │ - 并行执行 │ │
│ │ - 错误处理 │ │
│ │ - 重试策略 │ │
│ └───────────────────────┘ │
└─────────────────────────────────────────────────┘
#7.4 FunctionRuntime——多语言沙箱
coomia-dip 的 FunctionRuntime 支持五种语言的安全沙箱执行：
Code
FunctionRuntime 多语言支持：
┌──────────────────────────────────────────────┐
│ FunctionRuntime │
│ │
│ ┌──────────┐ ┌──────────┐ ┌──────────┐ │
│ │ Python │ │TypeScript│ │ Groovy │ │
│ │ Sandbox │ │ Sandbox │ │ Sandbox │ │
│ │ │ │ │ │ │ │
│ │ CPython │ │ Deno │ │ GraalVM │ │
│ │ 3.11+ │ │ Runtime │ │ Sandbox │ │
│ └──────────┘ └──────────┘ └──────────┘ │
│ │
│ ┌──────────┐ ┌──────────┐ │
│ │ WASM │ │ Kotlin │ │
│ │ Sandbox │ │ Sandbox │ │
│ │ │ │ │ │
│ │ Wasmtime │ │ Kotlin │ │
│ │ Runtime │ │ Script │ │
│ └──────────┘ └──────────┘ │
│ │
│ 公共能力层: │
│ ┌──────────────────────────────────────────┐ │
│ │ - Ontology API 访问 (受权限控制) │ │
│ │ - 执行时间限制 (默认 30s, 可配置) │ │
│ │ - 内存限制 (默认 256MB, 可配置) │ │
│ │ - CPU 限制 (单核, 可配置) │ │
│ │ - 网络访问控制 (默认禁止) │ │
│ │ - 文件系统隔离 (只读临时目录) │ │
│ └──────────────────────────────────────────┘ │
└──────────────────────────────────────────────┘
每种语言沙箱的适用场景：
| 语言 | 适用场景 | 优势 |
|---|---|---|
| Python | 数据分析、ML 推理、科学计算 | 丰富的数据科学库 |
| TypeScript | 前端逻辑、API 集成、字符串处理 | 类型安全、生态丰富 |
| Groovy | 规则表达式、动态脚本 | JVM 生态、DSL 友好 |
| WASM | 高性能计算、跨语言 | 近原生性能、安全隔离 |
| Kotlin | JVM 集成、Android 扩展 | 与 Java 互操作 |
#八、实战：端到端业务闭环
#8.1 场景：智能采购流程
让我们用一个完整的例子串联 Actions、Rules 和 Functions：
Code
┌──────────────────────────────────────────────────────┐
│ 完整闭环：智能采购流程 │
│ │
│ ① 传感器数据 → 库存系统更新库存数量 │
│ │ │
│ ▼ │
│ ② Rule 触发：库存 < 安全库存 │
│ │ │
│ ▼ │
│ ③ Function 执行：selectOptimalSupplier() │
│ - 比较 3 家供应商的价格、交期、评分 │
│ - 检查年度合同剩余额度 │
│ - 返回推荐供应商 + 建议数量 │
│ │ │
│ ▼ │
│ ④ Action 执行：创建采购订单 (CompositeOp) │
│ - CreateObject: PurchaseOrder │
│ - CreateRelation: PO → Supplier │
│ - UpdateObject: Material.pendingQty │
│ - Notification → 采购经理 │
│ │ │
│ ▼ │
│ ⑤ Rule 触发：订单金额 > ¥50,000 │
│ │ │
│ ▼ │
│ ⑥ Action 执行：创建审批任务 │
│ - 路由到部门总监 │
│ - 设置 48 小时审批 SLA │
│ │ │
│ ▼ │
│ ⑦ 总监审批 (手动 Action: ApproveOrder) │
│ │ │
│ ▼ │
│ ⑧ Rule 触发：订单状态变更为 APPROVED │
│ - Webhook → ERP 系统同步 │
│ - Webhook → 供应商门户通知 │
│ - UpdateObject: 预算已用金额 │
│ │
│ 全流程：自动 7 步 + 人工 1 步 = 原来 2 天 → 现在 2 小时 │
└──────────────────────────────────────────────────────┘
#8.2 使用 coomia-dip SDK 实现
Python
from ontology_sdk import OntoPlatform, ActionBuilder, RuleBuilder
platform = OntoPlatform(endpoint="grpc://localhost:9090")
# 定义 Rule: 库存低于安全库存时自动补货
low_stock_rule = RuleBuilder("auto_restock") \
.description("库存低于安全库存时自动触发补货流程") \
.when("Material") \
.condition("object.stock_level < object.safety_stock") \
.condition("object.status == 'ACTIVE'") \
.unless("object.pending_quantity > 0") \
.throttle(hours=24, per="object.id") \
.then_action("restock_material", {
"material_id": "${trigger.object.id}",
"quantity": "${trigger.object.safety_stock - trigger.object.stock_level}"
}) \
.build()
# 定义 Rule: 大额订单自动提交审批
approval_rule = RuleBuilder("auto_approval_routing") \
.description("采购金额超过阈值时自动路由审批") \
.when("PurchaseOrder") \
.condition("object.status == 'PENDING'") \
.condition("object.total_amount > 50000") \
.then_action("create_approval_task", {
"order_id": "${trigger.object.id}",
"approver_role": "department_director",
"sla_hours": 48
}) \
.build()
# 注册规则
platform.reasoning.register_rule(low_stock_rule)
platform.reasoning.register_rule(approval_rule)
# 执行 Action (手动触发)
result = platform.actions.execute(
action_type="restock_material",
params={
"material_id": "MAT-A2047",
"quantity": 100
},
dry_run=True # 先预览
)
print(f"预览: 将创建 {len(result.preview.objects_created)} 个对象")
print(f"预计金额: ¥{result.preview.estimated_cost}")
# 确认执行
result = platform.actions.execute(
action_type="restock_material",
params={
"material_id": "MAT-A2047",
"quantity": 100
},
dry_run=False # 实际执行
)
print(f"执行结果: {result.status}")
print(f"审计 ID: {result.audit_id}")
#九、Actions vs. 传统方案对比
#9.1 与 REST API 的对比
| 维度 | REST API | Palantir Actions |
|---|---|---|
| 语义 | 技术操作 (POST/PUT/DELETE) | 业务操作 (补货/审批/转移) |
| 参数校验 | 手动编码 | 声明式定义 |
| 权限 | 中间件拦截 | 内置于 Action 定义 |
| 审计 | 另外实现 | 自动记录 |
| 影响预览 | 不支持 | Dry Run 内置 |
| 批量操作 | 自行实现 | 框架支持 |
| 副作用 | 隐式（看代码） | 显式声明 |
#9.2 与工作流引擎的对比
Code
传统工作流引擎 (Camunda/Activiti):
┌──────────┐ ┌──────────┐ ┌──────────┐
│ 工作流 │────→│ 外部服务 │────→│ 数据库 │
│ BPMN 图 │ │ (REST) │ │ (SQL) │
└──────────┘ └──────────┘ └──────────┘
流程定义 业务逻辑 数据存储
(三者分离，需要大量胶水代码)
Palantir Actions + Rules:
┌────────────────────────────────────────┐
│ Ontology │
│ │
│ Objects ←→ Actions ←→ Rules │
│ (数据) (操作) (逻辑) │
│ │
│ 全部在 Ontology 语义下统一 │
│ (零胶水代码) │
└────────────────────────────────────────┘
#Key Takeaways
-
Actions 的核心价值在于"副作用声明"——每个 Action 显式声明它会创建、修改、删除哪些对象，这使得权限检查、审计记录、影响预览、回滚机制都可以自动化实现，而不需要开发者手动编码。这是 Palantir 区别于传统 API 的根本性设计。
-
Rules 引擎实现了"从看到做"的自动化闭环——通过"条件 -> 触发 -> 动作链"的模式，系统可以在检测到业务条件时自动执行一系列操作。单条规则保持简单，但通过事件链串联可以处理极其复杂的业务场景。
-
coomia-dip 的 ActionEngine 提供 10 种执行器类型，ReasoningEngine 提供规则引擎，FunctionRuntime 支持 5 种语言沙箱——这三者组合实现了从简单的按钮操作到复杂的自动化决策链的全覆盖。CompositeOp 执行器允许将多个操作编排成原子事务，是实现企业级业务流程的关键。
#下篇预告
“第 12 篇：Palantir 的权限模型——为什么政府敢把机密数据交给它
Actions 和 Rules 让系统能够自动执行操作，但谁有权限执行什么操作？数据安全是 Palantir 的立身之本。下一篇我们将深入解析 Palantir 的多层安全模型：从军事级别的信息分区到细粒度的行列级权限控制，揭示为什么世界上最敏感的组织信任 Palantir 处理他们最机密的数据。
#palantir #actions #rules #functions #automation #ontology #coomia-dip #closed-loop