Palantir 生产级编排：Function-backed Action 与多分支 Automate

在基础配置骨架之上，生产环境往往需要更复杂的场景：Action 内部依赖外部函数决策、Automate 规则有多条分支路由、失败时需要重试和回退。本篇覆盖这三类进阶主题。

重要说明：Palantir 官方并没有把 Automate 规则公开成”手写 JSON 配置文件”；UI 里是 Condition → Effects，AIP Logic 里是 Blocks（Conditionals / Loop）。下文 JSON 均为教学骨架，用于表达平台内部概念的结构，帮助理解各字段语义。

前置阅读：

Palantir 自动化机制概述

工厂 IoT 告警自动分派实战

Action 与 Automate 配置参考

一、Function-backed Action：让决策和写操作分离

基础示例里 Action 的 edits 直接操作属性。生产场景中，优先级、处理组等决策由外部函数计算，Action 只负责把结果写回 Ontology。

场景：TriageAlert（告警定级 + 分派 + 外部通知）

        
      
{
  "apiName": "triage-alert",
  "displayName": "Triage Alert",
  "description": "根据温度/区域/历史，计算优先级并分派处理组",

  "parameters": {
    "alert": {
      "type": "objectType:Alert",
      "required": true
    },
    "overrideGroup": {
      "type": "objectType:Group",
      "required": false,
      "description": "人工覆盖处理组（可选）"
    }
  },

  "backingLogic": {
    "type": "function",
    "functionRid": "ri.function.main.triage-alert-fn",
    "inputMapping": {
      "alert": "$parameter.alert"
    },
    "outputs": {
      "priority": "string",
      "group": "objectType:Group",
      "needsHumanReview": "boolean",
      "reason": "string"
    }
  },

  "submissionCriteria": [
    {
      "condition": "alert.status == 'OPEN'",
      "message": "只能处理 OPEN 状态告警"
    },
    {
      "condition": "currentUser.inGroup('sre-oncall') || currentUser.inGroup('alert-admin')",
      "message": "需要 SRE 值班或告警管理员角色"
    }
  ],

  "edits": [
    {
      "modifyObject": "alert",
      "set": {
        "priority": "$output.priority",
        "triageReason": "$output.reason",
        "status": "TRIAGED"
      }
    },
    {
      "createLink": {
        "from": "alert",
        "link": "Alert.assignedTo.Group",
        "to": "$output.group"
      }
    }
  ],

  "sideEffects": {
    "notifications": [
      {
        "to": "linked:Alert.assignedTo.Group.hasMembers.Person",
        "title": "告警已分派: ${alert.id}",
        "body": "优先级=${output.priority}, 原因=${output.reason}"
      }
    ],
    "webhooks": [
      {
        "name": "notify-pager",
        "url": "https://hooks.internal/alert",
        "method": "POST",
        "body": {
          "alertId": "${alert.id}",
          "priority": "${output.priority}",
          "group": "${output.group.name}"
        }
      }
    ]
  },

  "governance": {
    "autoApproveIf": "output.needsHumanReview == false",
    "requireHumanApprovalIf": "output.needsHumanReview == true",
    "idempotency": "UPSERT_BY_ALERT"
  }
}

关键设计原则

原则	说明
Function 只管决策	算 priority、group、needsHumanReview，不做任何写操作
Edits 才是事务写	写回 Ontology 的唯一入口是 edits 数组
Submission Criteria 永远跟着 Action	人 / Automate / Agent 调用都过同一道门，不重复定义
Governance 控制审批流	`autoApproveIf` 低风险自动通过，`requireHumanApprovalIf` 高风险弹确认卡

二、Automate 多分支编排：三种做法

当触发后需要根据条件走不同路径时，有三种常见做法。

做法 A：拆成多个 Automate（最推荐）

按对象属性分路由，每个优先级单独一个 Automation。

Trigger: Alert 对象被创建 / 状态变 OPEN
  │
  ├── Automation-1  filter: temperature >= 90    → CRITICAL 分支
  ├── Automation-2  filter: 80 <= temp < 90      → HIGH 分支
  ├── Automation-3  filter: 60 <= temp < 80      → MEDIUM 分支
  └── Automation-4  filter: temp < 60            → LOW / 仅记录

每个 Automation 内部结构简单：

        
      
{
  "apiName": "alert-critical-branch",
  "trigger": {
    "type": "objectsModifiedInSet",
    "objectType": "Alert",
    "filter": "temperature >= 90 && status == 'OPEN'"
  },
  "effects": [
    {
      "type": "action",
      "actionApiName": "triage-alert",
      "input": { "alert": "$trigger.object" },
      "retry": { "maxAttempts": 3, "backoff": "EXPONENTIAL" }
    },
    {
      "type": "notification",
      "to": ["user:incident-commander"],
      "title": "CRITICAL 告警"
    }
  ]
}

✅ 优点：分支之间互不污染，权限/审计清晰，Palantir 官方对象集条件就是这样设计的。

做法 B：单个 Automation + AIP Logic Conditionals

Automate 只做触发，分支逻辑放 AIP Logic Blocks。

        
      
{
  "apiName": "alert-triage-orchestrator",
  "trigger": {
    "type": "objectsAddedToSet",
    "objectType": "Alert",
    "filter": "status == 'OPEN'"
  },
  "effects": [
    {
      "type": "logic",
      "logicRid": "ri.logic.main.alert-router",
      "input": { "alert": "$trigger.object" }
    }
  ]
}

AIP Logic 里的 Conditionals Block：

Input: alert

routeAlert(alert):
  ├─ if alert.temperature >= 90
  │     → run triage-alert(alert)
  │     → notify incident-commander
  │     → return path = "critical"
  │
  ├─ else if alert.temperature >= 80
  │     → run triage-alert(alert)
  │     → notify sre-oncall
  │     → return path = "high"
  │
  ├─ else if alert.temperature >= 60
  │     → set alert.priority = MEDIUM
  │     → return path = "medium"
  │
  └─ else
        → set alert.priority = LOW
        → log only
        → return path = "low"

AIP Logic Conditionals 约束：

每个分支返回”同一类输出”
必须有 else / default 分支
若某分支返回 Ontology edits，其他分支要么也编辑、要么显式 “take no action”

做法 C：Function 先算路由，再驱动不同 Action

适合分支很多、规则常变的场景。

        
      
{
  "apiName": "alert-smart-router",
  "trigger": {
    "type": "objectsModifiedInSet",
    "objectType": "Alert",
    "filter": "status == 'OPEN'"
  },
  "effects": [
    {
      "type": "function",
      "functionRid": "ri.function.main.compute-alert-route",
      "input": { "alert": "$trigger.object" },
      "outputVar": "route"
    },
    {
      "type": "action",
      "if": "route.decision == 'AUTO_ASSIGN'",
      "actionApiName": "triage-alert",
      "input": { "alert": "$trigger.object" }
    },
    {
      "type": "action",
      "if": "route.decision == 'ESCALATE'",
      "actionApiName": "escalate-alert",
      "input": {
        "alert": "$trigger.object",
        "reason": "$route.reason"
      },
      "retry": { "maxAttempts": 2 }
    },
    {
      "type": "action",
      "if": "route.decision == 'HUMAN_REVIEW'",
      "actionApiName": "create-review-task",
      "input": { "alert": "$trigger.object" }
    },
    {
      "type": "notification",
      "if": "route.decision == 'SUPPRESS'",
      "to": ["user:noise-owner"],
      "title": "抑制告警 ${trigger.object.id}"
    }
  ]
}

注：上方 JSON 中 if 是概念层表达。真实产品里通常用以下三种方式实现：

Logic Block 做 if

不同对象集条件拆成多个 Automation

Function 输出变量驱动下一个 Action 的参数

三种做法对比

维度	做法 A（拆多 Automation）	做法 B（AIP Logic）	做法 C（Function 路由）
适用场景	分支数少且固定（2~4 个）	分支多且有 nested 逻辑	分支动态、规则频繁变化
复杂度	低	中	中
维护成本	每个 Automation 独立维护	集中在 Logic Block	集中在 Function
推荐度	⭐⭐⭐ 最稳	⭐⭐⭐ 适合复杂判断	⭐⭐ 适合动态规则

三、多分支 + 重试 + 回退：生产骨架

        
      
{
  "apiName": "alert-escalation-flow",
  "trigger": {
    "type": "objectsModifiedInSet",
    "objectType": "Alert",
    "filter": "priority == 'CRITICAL' && status == 'OPEN'"
  },
  "effects": [
    {
      "type": "action",
      "name": "primary-assign",
      "actionApiName": "triage-alert",
      "input": { "alert": "$trigger.object" },
      "execution": "SEQUENTIAL",
      "retry": {
        "maxAttempts": 3,
        "initialDelayMs": 1000,
        "multiplier": 2.0
      },
      "fallback": {
        "type": "action",
        "actionApiName": "create-unassigned-incident",
        "input": {
          "alert": "$trigger.object",
          "note": "自动分派失败，转入未分派事故队列"
        }
      }
    },
    {
      "type": "logic",
      "name": "post-triage-ai-summary",
      "logicRid": "ri.logic.main.alert-summary",
      "input": { "alert": "$trigger.object" },
      "dependsOn": "primary-assign"
    },
    {
      "type": "notification",
      "name": "notify-ic",
      "to": ["group:incident-responders"],
      "title": "CRITICAL 已处理: ${trigger.object.id}",
      "dependsOn": ["primary-assign", "post-triage-ai-summary"]
    }
  ],
  "executionSettings": {
    "effectOrder": "SEQUENTIAL",
    "queueEvents": true,
    "stopOnEffectFailure": true
  }
}

关键语义

概念	语义
`SEQUENTIAL`	前一个 Effect 失败，后续 Effect 不执行
`retry`（Effect 级别）	单个 Effect 自身失败时的自动重试（指数退避）
`fallback`	主 Effect 用尽重试次数后仍失败才走备流
`dependsOn`	声明式依赖，Effect 只有在指定名称的 Effect 成功后才执行
`queueEvents`	不同事件排队处理，避免并发修改同一对象
`stopOnEffectFailure`	任意 Effect 失败后立即终止整个 Automation

执行时序示意

Effect[0]: primary-assign (triage-alert Action)
  ├─ 成功 → Effect[1] 触发
  └─ 失败（3次重试后）→ fallback: create-unassigned-incident → Effect[1] 仍触发

Effect[1]: post-triage-ai-summary (AIP Logic)
  └─ dependsOn: primary-assign（含 fallback 完成后）

Effect[2]: notify-ic
  └─ dependsOn: [primary-assign, post-triage-ai-summary]

四、”多分支”需求 → 正确落点速查表

你想做的事	推荐落点
按对象属性分路由（如温度区间）	多个 Automate 对象集条件（做法 A）
复杂 if/else if/else 嵌套	AIP Logic Conditionals Block（做法 B）
算路由结果再决定调哪个 Action	Function 输出变量 + 多个带 if 的 Effect（做法 C）
主流程失败换备用流程	Effect 级别 `fallback`
单个 Action 内业务校验	Action 的 `submissionCriteria`
AI 建议但人拍板	Action `governance.humanInTheLoop`

五、端到端多分支流程（文字版）

Alert 创建
  │
  ▼
Automate: objectsAddedToSet(Alert.status=OPEN)
  │
  ▼
AIP Logic: routeAlert
  ├─ temp >= 90       → triage-alert + 通知 IC          （CRITICAL）
  ├─ temp 80~90       → triage-alert + 通知 SRE         （HIGH）
  ├─ temp 60~80       → 仅改 priority = MEDIUM          （MEDIUM）
  ├─ 命中抑制规则     → SUPPRESS + 噪声 owner 通知
  └─ 其他             → LOW + 写审计日志
  │
  ▼
triage-alert Action（Function-backed）
  ├─ backingLogic 函数算 priority / group / needsHumanReview
  ├─ submissionCriteria 拦截（仅 OPEN、需 SRE 角色）
  ├─ edits 事务写回 Ontology（priority、triageReason、status、Link）
  ├─ sideEffects：站内通知 + Webhook
  └─ governance：低风险自动通过，高风险弹人工确认卡
  │
  ▼
（若 Action 失败）→ Automate Effect fallback → create-unassigned-incident

六、下一步建议

以上骨架可直接套用到其他业务场景：

供应链缺料调拨：triage-alert → resolve-material-shortage，分支增加”自动调拨 / 人工审批 / 升级 ERP”
风控案件分派：分支改为”自动阻断 / 人工复核 / 上报合规”
运维事件升级：用 dependsOn + fallback 实现 S1→S2→S3 的逐级升级链

如需针对某个场景展开完整配置，或深入了解 AIP Logic Conditionals Block 的变量设计，可以继续阅读后续文档或提问。

阅读 — · 全站 —