上一篇恒川工业用 Decision-back Canvas 从 Outcome 和缺料决定反推出一个关键动词供应链经理要批准方案AP-2048。现在经理在处置应用里点击“批准”。按钮变绿页面提示成功。十分钟后WMS 没有调拨任务ERP 没有执行记录缺料事件SD-260808-01却已经显示“已完成”。按钮完成了交互业务没有完成操作。这正是传统功能需求最容易遗漏的地方它写清用户点什么、页面显示什么却没有完整定义这次操作作用于谁、什么条件下允许发生、改变什么状态、谁有权执行、失败后怎么办以及如何证明它真的发生过。本篇要解决的问题Action 不是给按钮换一个高级名字。本篇要回答Action 在 Ontology 和 Palantir 架构中处于什么位置Action Type、一次 Action submission、Function、Automation、side effect 和 Writeback 各自负责什么BA 怎样把一句用户故事升级为可配置、可测试、可审计的业务操作契约。一句话定义Action 是在 Ontology 中按照明确目标、参数、规则、权限和审计要求改变业务对象状态的一次受控事务Action Type 则是这类业务操作可复用的定义。先把 Action 放回 OntologyPalantir Ontology 用 Object、Property 与 Link 表达企业世界中的“名词”用 Action Type 表达用户可以怎样改变这个世界。官方把 Action 描述为基于用户定义逻辑、改变一个或多个对象属性的一次事务Action Type 定义可一并进行的 Object、Property value 与 Link 编辑以及提交时的 side effects。PalantirAction types overview从概念类型看Action Type 属于OntologyLanguage 的操作构件配置后由 Ontology Engine 执行并受安全机制约束。它建立在 Object Type、Property、Link、规则或 Function 之上再被 Workshop、Object Explorer、自定义应用、Automate 或受控 Agent 等入口调用。Foundry / Palantir 架构 └─ Ontology System ├─ 语义目标Object、Property、Link ├─ 操作定义Action Type │ ├─ Parameters │ ├─ Submission criteria │ ├─ Rules 或 backing Function │ ├─ Permissions / authorizations │ ├─ Edits 与 side effects │ └─ Action log / monitoring └─ 一次运行Action submission └─ 由人、应用、Automate 或受控 Agent 发起在产品中建设者通常在 Ontology Manager 中配置 Action Type 的目标、参数、规则、条件与 side effects。运营用户不会直接编辑这份定义而是在 Workshop 等应用中填写参数并提交同一个 Action Type 也可以被其他受支持入口复用。因此Action 的上级是 Ontology System其基础是业务对象、逻辑和权限其下游消费者是应用、自动化与 Agent。它不是 Foundry 的平级平台也不是外部系统 API 的别名。七个相邻词一次分清最有效的辨析方式是让这些词处理同一个恒川动作“批准AP-2048中 520 EA 的跨仓调拨”。520 EA 为本篇教学场景假设因超过恒川 500 EA 阈值必须由 Supply Chain Manager 复核。名词类型负责回答什么在AP-2048中的形态Button / Form界面入口用户从哪里发起Workshop 的“批准方案”按钮与参数表单Action TypeOntology Language 构件允许执行哪一类业务操作Approve Allocation Proposal的目标、参数、校验、权限和效果定义Action submission运行事件/一次事务谁在何时用什么参数执行某经理在 10:32 对AP-2048提交批准Function逻辑单元怎样计算、判断或生成复杂编辑计算受影响订单或生成多对象状态更新API / Webhook集成机制数据怎样送到外部系统把调拨请求送往 WMS 或 ERPside effectAction 提交的附加效果Ontology 编辑之外还触发什么通知仓储负责人或调用 WebhookAutomate业务自动化应用/资源何时自动检查条件并触发效果检测高风险缺料后创建任务不改写 Action 契约Writeback本系列的问题域/实施术语批准后的状态到底写到哪里、如何对账Ontology edit、WMS/ERP 写入、失败重试和人工复核的整体设计几个边界必须守住。按钮不是 Action。按钮可以改版、迁移或被 Agent 工具替代Action Type 的业务语义仍应稳定。Function 不是 Action。Function 可以计算建议也可以支撑复杂对象编辑但“算出 520 EA”不等于“有权批准 520 EA”。Automate 不是 Action。Automate 定义何时自动检查条件并执行效果其中一种效果是提交 Action它不会因此取代 Action 的目标、校验和授权。PalantirAutomate overviewWebhook 不是完整 Writeback。Webhook 只是向外发送请求的一种机制。System of Record、幂等、并发、补偿、重试、对账和人工退出仍需另行设计。从用户故事走向状态契约普通用户故事可能这样写作为供应链经理我希望批准调拨方案以便降低客户订单延期影响。它说明了角色、意图和价值却不足以进入生产。BA 应先写状态变化再展开契约字段。先写状态机不要先画表单对恒川缺料处置统一状态应是Supply Disruption / Allocation Proposal Detected → Assessed → Options Prepared → Pending Approval ├→ Rejected └→ Approved ↓ Writeback In Progress ↓ Executed / Partially Failed / Failed ↓ Reconciled → Closed本篇 Action 的直接职责是把满足条件的AP-2048从Pending Approval推到Approved并保存批准上下文、创建或触发后续执行请求。它不能在外部系统尚未确认时直接把事件写成Executed。Approved ≠ Executed。前者是业务决定通过后者是目标系统已经完成并经对账确认。两种状态合并是运营应用最危险也最常见的假成功之一。这个状态机迫使团队回答谁能推动哪次迁移迁移前必须满足什么Ontology 编辑与外部执行如何区分部分失败后能否恢复。Action Contract 的十三项核心内容1. Name 与 Owner操作叫什么谁拥有定义名称要用业务动词加对象例如“批准调拨方案”而不是submitButton2或“调用 ERP 接口”。Owner 要对业务含义、规则和变更负责不只是页面负责人。2. Target这次操作作用于什么目标对象是Allocation Proposal AP-2048与关联的Supply Disruption SD-260808-01。若 Action 还修改多个订单、库存分配或执行请求要逐项写明不能用“更新相关数据”代替。3. Parameters提交者必须提供什么恒川参数包括来源仓WH-S02、目标仓WH-E01、数量 520 EA、生效时间和批准理由。参数不是页面字段清单每项还要定义类型、单位、是否必填、可选范围和来源。4. Submission criteria什么时候允许提交Submission criteria 是决定一次 Action 能否提交的条件可结合当前用户、参数、对象与关系信息表达业务限制。它与谁能编辑 Action Type 定义的权限相互独立。PalantirSubmission criteria恒川至少检查方案仍为Pending Approval缺料事件未关闭排产未冻结数量不超过当前可用量来源仓与目标仓不同当数量超过 500 EA 时当前用户满足经理复核条件。这些不是浏览器里的表单提示。无论 Action 从 Workshop、API、Automate 还是受控 Agent 入口提交都应遵守同一业务约束。5. Permission 与 authorization谁能看、配、提、批、做官方权限文档区分谁能查看 Action Type、谁能编辑定义以及谁能用一组参数 Apply Action。提交者还要能访问被编辑的 Object/Link 及相应 datasource并通过 submission criteriaread/write authorizations 还会约束标记数据的读取与写入。PalantirAction permissions恒川不能只写“供应链团队可操作”。至少拆成Supply Planner 可准备并提交方案Supply Chain Manager 复核超过 500 EA 的高影响调拨Warehouse Coordinator 处理仓储执行Agent 默认只能解释和建议不能自行绕过审批。6. Rule / Function状态怎样改变简单 Action 可用 rules 创建、修改、删除 Object 或 Link。若要读取多对象、执行复杂计算或同时创建多类对象可以使用 Function-backed Action它仍受 Action 与 Function 的执行限制。PalantirFunction-backed actionsAP-2048获批时规则或 backing Function 至少要更新方案状态、保存批准人和时间、关联决策上下文并按恒川实现创建WR-2048-*执行跟踪对象。Writeback Request是本系列实施性对象不是 Palantir 固定对象模型。7. Transaction boundary哪些编辑必须一起成功Action 在 Ontology 内是一次事务但跨 Ontology、WMS 与 ERP 的端到端过程不应被想当然地视为单一原子事务。BA 要明确哪些对象编辑必须共同成功哪些外部效果可以异步失败时状态落在哪里。8. Side effectsOntology 之外还发生什么Action Type 可配置 notification 和 Webhook 等 side effects把数据送出 Foundry并连接既有流程。官方把外部系统仍是 source of truth 时的这种模式称为 decision orchestration。PalantirSide effectsSide effect 与 Ontology 编辑并不天然同成同败。官方权限页明确指出通知失败时 edits 仍可能成功。因此契约必须定义Ontology 已批准但通知或 WMS 请求失败显示Partially Failed、Failed还是等待重试谁收到告警何时转人工。9. System of Record哪个系统拥有哪个事实恒川的方案审批和处置运行状态可以由 Ontology 承载ERP 仍拥有订单与采购承诺WMS 仍拥有仓储执行事实。Action 不会自动替企业决定谁是权威账本。10. Failure、retry 与 compensation失败怎样恢复用户参数错误、库存已被他人占用、权限不足、WMS 超时与 WMS 明确拒绝是不同失败。每一类都要有错误状态、用户提示、Owner、重试条件、重复请求处理和人工退出路径。本篇不展开 Writeback 技术方案但 Action Contract 至少要保存幂等标识、外部关联号和补偿责任避免重试生成重复调拨任务。11. Audit怎样重建当时的决定Action log 可把每次 submission 建模为可分析的对象并连接被编辑对象。官方文档列出的默认信息包括 submission RID、Action Type RID 与版本、时间、提交用户、被编辑对象主键以及可选摘要和参数值还可以保存相关决策上下文。PalantirAction logBA 应定义未来复盘要回答什么谁基于哪版AP-2048批准看到的库存更新时间是什么为什么覆盖系统建议最终影响哪些订单。Edit history 可以回答更广泛的对象编辑历史但不替代一项决定需要保存的业务理由。12. Outcome技术成功后业务有没有改善“Action submission 成功”只能证明一次操作被接受。处置时长是否缩短、重点订单延期影响是否下降、部分失败率是否可控才说明业务 Outcome 是否改变。13. Acceptance怎样证明整份契约成立正常路径只是起点。验收必须覆盖越权、条件失效、并发变化、部分失败、重复请求和审计复盘。BA 工作台恒川 Action Contract契约项Approve Allocation Proposal填写样例Business name / Owner批准调拨方案Supply Chain ManagerTrigger / callerPlanner 提交后由 Manager 复核高影响方案不可由 Agent 自动批准TargetAP-2048、SD-260808-01ParametersWH-S02 → WH-E01、520 EA、生效时间、批准理由State transitionPending Approval → Approved外部执行另进Writeback In ProgressSubmission criteria方案待审批、事件未关闭、未过冻结点、数量未超可用量、500 EA 经理复核Permission / authorizationPlanner 提交Manager 批准Warehouse 执行读取和写入遵守对象、datasource 与标记数据授权Rules / Function更新审批状态记录批准上下文按实施设计创建WR-2048-*Transaction boundary方案状态与批准记录共同成功外部 WMS/ERP 执行单独跟踪Side effects通知仓储通过受控 Webhook/API 请求外部执行System of RecordOntology决定与运行状态WMS仓储执行ERP订单和采购承诺Failure / recovery外部失败不伪装成功幂等重试超限或拒绝转人工复核AuditAction 版本、参数、用户、时间、方案版本、库存时间点、受影响对象Outcome决策耗时、执行成功率、订单延期影响、人工返工率Action Contract是本系列面向 BA 的实施模板不是 Palantir 官方固定表单。它的作用是让业务、BA、Ontology、应用与集成团队对同一个操作给出同一答案。把契约直接变成验收场景场景前置条件操作预期结果正常批准AP-2048待审批520 EA 可用排产未冻结Manager 批准状态进入Approved保存日志并发起后续执行不提前显示Executed越权提交Planner 只有提交权Planner 尝试批准阻断操作说明所需权限不产生 edits 或 side effects条件失效页面打开后库存被占用或排产冻结提交旧方案criteria 失败提示重新评估不执行旧参数部分失败Ontology 审批已成功WMS 请求失败接收失败回执进入可识别的失败状态保留原因、外部关联号与责任人重复请求同一方案和幂等标识已有结果再次提交不重复生成外部任务返回已有结果或明确阻断审计复盘处置已对账查询记录可还原谁、何时、用哪版方案和证据、影响哪些对象若团队无法写出某一行的预期结果问题通常不在测试脚本而在 Action 的业务契约还没有达成共识。三条生产边界事务边界。一个按钮不代表多个企业系统天然属于一个原子事务。先定义 Ontology 内必须共同成功的编辑再定义外部执行与恢复。授权边界。能看到对象、能运行 Function、能提交建议、能批准和能执行是不同权力。尤其 Agent 参与时工具可见不等于自动获得高影响操作权。记录边界。当前状态可以继续变化但当时的参数、版本、批准理由与执行结果不能被后续覆盖成一条模糊的“已完成”。回到开头Action 为什么是操作契约如果需求只写“点击批准后提示成功”它描述的是交互。只有当 Target、Parameters、criteria、权限、状态迁移、事务、side effects、System of Record、失败、审计和 Outcome 都能被共同解释和验收时它才描述了一项业务操作。Action Type 把这份稳定语义放进 Ontology一次 Action submission 则让具体的人、对象、参数与时间进入运行和审计。页面可以变化调用入口可以增加外部系统也可能替换但业务操作的核心契约仍然清楚。本文依据 Palantir 公开资料与实施研究整理与 Palantir Technologies 无官方关联。恒川工业及其编号和数据均为虚构教学案例Action Contract、Writeback Request和本篇状态机不是 Palantir 官方固定产品模型或模板。产品能力与授权模型可能变化请以官方文档和具体环境为准。