Palantir 自动化机制：Ontology、Action 与 Automate
Palantir 的自动化（Automate）与动作（Action）是构建在 Ontology（本体/语义层）之上的核心执行机制，负责把”分析洞察”闭环为”真实业务写操作”。整体可概括为：Ontology 定义业务世界的”名词”，Action 定义”动词”（受治理的写操作），Automate 负责”何时、因为什么触发这个动词”。下面分四层说明其设计与实现。
一、Ontology 层 — 动作的作用对象
Palantir Ontology 把企业实体（如 Flight、Shipment、Alert）建模为 Object Type，属性为 Property，关系为 Link，构成机器与人类共享的语义层。
- Action 操作的是这些语义对象，而非直接操作底层数据库表。
- LLM/Agent 看到的是”设备、订单、告警”等业务对象，不直接接触原始存储。
二、Action（动作）— 受治理的事务性写操作
Action Type 是在 Ontology 中定义的可复用业务操作契约，每次提交是一次事务性写（Transactional Write）。
典型 Action Type 包含：
| 组件 | 说明 |
|---|---|
| Parameters（参数） | 输入必须符合类型定义，可设默认值、下拉过滤、自动捕获上下文（如当前操作人） |
| Edits（编辑） | 直接修改 Object 的属性或 Link（创建/修改/删除） |
| Submission Criteria（提交准则/前置门禁） | 执行前必须满足的业务条件（如”只有飞行控制组成员才能操作”且”目标飞机必须处于非检修状态”），不满足则事前拦截 |
| Backing Logic | 简单场景用 Rules；复杂逻辑可用 TypeScript/Python Function（Function-backed Action） |
| Side Effects（副作用） | Action 成功提交后触发——发送通知、创建/删除 Link、调用外部系统 Webhook 等 |
| Permissions & Authorization | 基于角色（RBAC）、标记（Marking-based）、用途（Purpose-based）的细粒度权限；Agent 调用同样受此约束 |
| Idempotency | 原生支持”存在则更新、不存在则创建”的幂等语义，降低重复写入风险 |
| Audit & Lineage | 每次执行记录 Action Execution、操作人、参数、时间戳，并纳入平台血缘追踪 |
设计哲学：AI Agent 不直接执行任意代码或 SQL，只能在授权范围内填充 Action 参数并提交，由平台完成校验、写回与审计。
三、Automate（自动化）— 事件驱动的编排引擎
Automate 是 Foundry 中统一业务自动化的应用，采用 Condition → Effect（条件→效果）模型。
触发条件（Condition）类型
- 时间条件：如”每周一 09:00 触发”
- Object 数据条件：监听 Ontology 对象变化，如”新创建且优先级=高的 Alert 对象出现时触发”
- 组合条件：时间 + 对象数据条件结合
可执行的效果（Effect）
- 提交 Foundry Action（最常见）
- 调用 AIP Logic 函数 / Foundry Function
- 发送平台通知或邮件（可带 PDF 附件）
- 通过 Webhook 调用外部系统 API
编排与容错能力
- 顺序 / 并行执行：多 Effect 可配置串行或并行
- Retry（重试）：单个 Effect 支持自动重试（可配退避策略）
- Fallback（回退）：主 Effect 失败时路由到备用处理分支
- 批处理与分组：对象集触发时可配置”每对象执行一次”或”全批执行一次”等分组模式
四、AIP Agent 如何调用 Action/Automate
在 Palantir AIP 中，LLM Agent 通过语义工具调用与 Action 交互：
- 上下文绑定：输入（如 ticket ID）映射到具体 Ontology Object，自动绑定其属性与关系。
- LLM 决策：模型基于业务规则（prompt + 确定性代码混合）判断该调用哪个 Action、填什么参数。
- Output Binding & 校验：模型输出被规范化为 Action 参数，平台按 Action Type 的 Schema 做类型/规则校验。
- Pre-Execution Governance：基于提交者身份、对象级权限、Marking、Submission Criteria 生成 Allow / Deny / Require Approval。
- 执行与审计：通过后在授权边界内产生副作用（Ontology 写回 + Webhook 外部系统），完整记录 ExecutionRecord + Provenance。
典型策略：低风险操作可自动执行（如更新 ETA），高风险操作强制 Human-in-the-loop 确认（如改承运商、大额支付）。
五、一句话总结
Palantir 不是让 Agent 直接碰数据库，而是：
Ontology 建模业务世界 → Action 把写操作封装为受权限/规则/审计约束的事务 → Automate 用条件触发编排这些 Action → AIP Agent 通过语义工具在治理边界内调用 Action，从而形成可溯源、可回滚、人机协同的企业级自动化闭环。