Palantir Ontology 实战：用 Action 把数据动词变成业务决策

把 purchase_order.status 从 pending 改成 approved，技术上很简单。

一行 SQL，一个接口，甚至让 Agent 拼一段 JSON，都能做到。

但在企业里，"采购例外已批准"从来不只是一个字段变了。

谁批的？当时订单金额多少？供应商是否在限制名单里？批准人的额度够不够？要不要通知采购员？ERP 里是否也需要放行？出了问题还能不能撤回？

如果系统只记住最后的 approved，那它记录的是结果，不是这次决定。

这就是 Action 出现的理由。

前面几篇讲了 Object、Property 和 Link：订单、供应商、库存、风险事件，以及它们的属性和关系。

这些都是业务世界里的"名词"。

名词能告诉我们现在有什么、它们处于什么状态、彼此怎样相关。真正的运营工作还要回答另一类问题：

• 批准还是拒绝？
• 分配给谁？
• 是否释放这批库存？
• 要不要关闭告警？
• 哪一组飞机和机组应该被重新排班？

这些是动词。

Palantir 在文档里把 Action 定义为一次事务：根据用户定义的逻辑，修改一个或多个对象的属性、链接，并可以带上通知或 Webhook 等副作用。Action type 则是这类动作的可复用定义。

按钮只是界面。Action 才是按钮背后那份稳定的业务契约。

一个 Action，至少要说清五件事

把 Action 理解成"带权限的写接口"，还是太薄了。一个能长期复用的业务动作，通常包含五层：

1. Parameters：这次决定需要哪些输入

输入不只是字符串。它可以是某个 PurchaseOrder 对象、一个原因代码、批准金额，也可以是系统自动带入的当前用户和时间。Parameter 是应用、表单和 Action 内部规则之间的稳定接口。

2. Submission criteria：此时此人能不能提交

它可以同时看当前用户、组织归属、参数和对象当前状态。条件不满足时，用户会看到具体失败原因，而不是一句含糊的"无权操作"。

3. Rules 或 Function：提交后世界怎样变

简单场景可以用 Rules 创建、修改、删除对象或链接。如果要读取多个关联对象、做复杂计算、一次改多种对象，就可以由上一篇讲的 Function 承载编程逻辑。

4. Side effects：还要通知谁、连接哪个外部系统

例如给采购员发通知，或通过 Webhook 请求 ERP 放行订单。这里要注意一条边界：官方文档明确提到，通知失败时，Ontology 编辑仍可能成功。不要把"执行了 Action"想象成跨所有外部系统的神奇原子事务。

5. Action log：这次决定如何变成可分析的数据

Action log 不只记"哪个字段改了"。它还可以保留 Action 类型及版本、提交时间、用户、被编辑对象，以及可选的参数和背景属性。决定本身也进入了 Ontology，后面才能追问：哪类例外最多？哪个环节最慢？哪些批准最终变成了损失？

一个采购例外，到底应该改多少东西

假设某笔采购订单超出了常规阈值，系统生成一个 ProcurementException 对象，等待业务负责人处理。

最省事的做法，是建一个 Modify Exception Status Action，让用户从下拉框里选 Approved。

这个名字已经暴露了问题：它描述了系统怎样存数据，没有描述用户在做什么。

更好的动作可以叫 Approve Procurement Exception（批准采购例外）。

它的参数是业务语言：待审例外、批准金额、原因代码和补充说明。

它的提交条件也很明确：

• 当前例外仍处于 Awaiting Review；
• 供应商不在禁止合作名单；
• 批准金额不超过提交人的授权额度；
• 提交人属于对应审批组。

提交后，它可以在一次业务操作里更新例外状态，写入审批人和审批时间，将相关 PurchaseOrder 转入可释放状态，通知采购员，必要时再调用 ERP 的对外接口。

这个例子是本文为了说明设计方法做的综合示例，不是 Palantir 客户案例。

Function 算得出，Action 才能正式落笔

上一篇讲完 Function，很容易跟 Action 混在一起。

可以用两句话先分开：

• Function 回答"怎样计算"；
• Action 回答"这次变更能否被提交，以什么业务身份被记录"。

例如，calculateExceptionExposure(order) 可以计算某笔订单的资金暴露和供应风险。Approve Procurement Exception 则收集决定所需参数，检查是否可提交，再完成受控写回。

简单编辑用 Rules 就够了。复杂多对象逻辑可以放进 Function-backed Action。这样做不是为了多套一层，而是把"复杂计算"和"受控决定"分别建模。

Agent 最需要的，是稳定的动词

到了Agent 场景，Action 的价值反而更容易看见。

一个 Agent 当然可以拿到数据库写权限，然后自己想办法改几个字段。这种设计也许很快，但它把业务规则、权限判断和审计责任都丢给了 Prompt 和调用代码。

更可控的方式，是把设计好的 Action type 暴露为可调用工具：

1. Agent 读取对象和关系，理解当前情况；
2. Function 计算风险、影响或建议值；
3. Agent 选择业务动作，补齐所需参数；
4. Action 在提交时重新检查权限和条件；
5. 变更、操作人、时间和决定背景进入记录。

这里有一部分是基于 Palantir Action 机制做的架构推论：官方 Action 文档说明了参数、规则、提交条件、权限和日志；把它当作 Agent 的受控工具，是本系列对这些能力的工程化解读，不是说只要建了 Action，Agent 就自动变得安全。

Action 设计得过于宽泛，Agent 照样可以把错误更快地执行出去。

有了 Action，也不等于自动安全

官方文档把几类权限问题分开处理：谁能看 Action type，谁能修改它，谁能带着某组参数真正提交。用户还需要看得到被编辑的对象和链接，并通过这个 Action 自己的 submission criteria。

这几层不能简化成一个 can_edit=true。

另一个容易被忽略的问题是撤回。Palantir 当前的 Action revert 有明确边界：它只适用于 Object Storage v2 上符合条件的编辑；目前只能由原提交人撤回；如果对象后面又被改过，原 Action 可能无法撤回。更重要的是，撤回对象编辑不会自动撤回通知和 Webhook 等副作用。

因此，真正高风险的动作需要的不只是 Undo，还可能包括人工复核、幂等设计、补偿操作和外部系统对账。

设计 Action 时，先问这 9 个问题

1. 名字是业务动词，还是数据库操作？

Approve Procurement Exception 通常比 Update Status 更稳定。

2. 它代表一个完整意图，还是一串只有工程师看得懂的字段修改？

3. 参数是否使用真实对象和业务语义？

4. 提交条件是否同时考虑人、对象状态和输入值？

5. 权限检查覆盖了哪些对象、关系和底层数据？

6. 简单 Rules 是否已经足够？

如果只是修改一个对象，别急着上 Function。

7. 副作用失败后，主编辑是否仍可接受？

8. Action log 里要保留哪些决定背景？

9. 需要撤回、补偿，还是二次审批？

这 9 个问题里，有一半答不清楚，就先不要把 Action 交给 Agent。

分界线不在界面，而在写回的那一刻

分析系统也能做出很好看的按钮，聊天机器人也能回答"建议批准"。

真正的分界线，出现在建议要变成真实改变的那一刻。

此时，系统必须知道用户想做什么，用什么参数，是否有权提交，会改动哪些对象，以及如何留下记录。

这也是 Action 让 Ontology 从一张业务名词表，走向企业运营系统的一步。

下一篇，我们会继续拆最容易被低估的那一层：企业 AI 的权限不是一个开关。

---

参考来源

1. Palantir 文档：Action types overview: https://www.palantir.com/docs/foundry/action-types/overview/
2. Palantir 文档：Rules: https://www.palantir.com/docs/foundry/action-types/rules/
3. Palantir 文档：Parameters: https://www.palantir.com/docs/foundry/action-types/parameter-overview/
4. Palantir 文档：Submission criteria: https://www.palantir.com/docs/foundry/action-types/submission-criteria/
5. Palantir 文档：Permissions: https://www.palantir.com/docs/foundry/action-types/permissions/
6. Palantir 文档：Function-backed actions: https://www.palantir.com/docs/foundry/action-types/function-actions-overview/
7. Palantir 文档：Side effects: https://www.palantir.com/docs/foundry/action-types/side-effects-overview/
8. Palantir 文档：Action log: https://www.palantir.com/docs/foundry/action-types/action-log/
9. Palantir 文档：Revert or undo actions: https://www.palantir.com/docs/foundry/action-types/action-reverts/