审批意图与恢复执行

BailingHub 的审批是“工具调用审批意图”，不是替代企业 OA 或业务系统审批。中枢负责暂停调用、冻结参数并接收决定；业务系统负责谁能审、审批流程和恢复前的最终授权。

审批意图

{
  "kind": "tool_approval_request",
  "approval_id": 123,
  "job_id": "job_...",
  "route": "inventory_ops",
  "provider": "erp",
  "tool": "inventory.adjust",
  "scope": "inventory.write",
  "risk": "high",
  "on_behalf_of": "tenant_1:user_1001",
  "args": { "store_id": 8, "sku_id": 10086, "delta": -20 },
  "args_hash": "sha256:..."
}

回传决定

POST /approvals/{approval_id}/decision

{
  "kind": "tool_approval_decision",
  "schema_version": "bailing.approval-decision.v1",
  "approval_id": 123,
  "job_id": "job_...",
  "request_id": "req_...",
  "args_hash": "sha256:...",
  "decision_id": "oa:approval:9001",
  "decision": "approved",
  "approver": "user_2002",
  "comment": "OA 审批已通过"
}

只接受 approved 或 denied。decision_id 是业务审批系统的幂等键；args_hash 必须与被冻结的调用一致。

0.9.2：已保存决策的补续

外部回调和控制台在同一事务保存审批决策与不可变的补续坐标。审计或排队失败后沿原 decision_id 重试，后台维护也会检查未完成补续。已保存决策但补续失败时返回 503 与 decision_recorded=true / continuation_pending=true，不要另造审批。

原任务入队与独立决策标记原子写入，并在入队临界区重新检查审批是否已消费。确认丢失、进程重开或新一轮任务完成后，同一决策不会重复排队；原任务仍在途时等待后续维护。拒绝只补审计，已消费或没有新补续记录的历史决策不被自动回填。审计确认丢失可出现带同一 detail.continuation_id 的重复观察，入队去重不保证跨系统业务恰好执行一次。

Agent 直调仍由原本地 Agent 以原 invocation_id 显式续执行，批准不启动中枢模型循环。升级须应用 066，并配套 state/config 补续接口；自定义仓储未实现时新决策明确不可用。参见 0.9.2 升级指南和可靠性机制与回退边界。

批准后仍要成立的条件

可信主体没有变化或失效；
route、工具源和精确 operation 仍被允许；
批准的规范化参数没有漂移；
审批仍在有效期且尚未被消费；
业务系统在写入前再次通过租户、权限和状态校验。

超时不代表工具没有成功。对未知终态先用同一业务幂等键向业务系统核账，不要盲目重放写操作。