批量客户操作控制面：Dry-run 快照、双人审批与效果对账

运营人员筛选“试用到期且没有付款方式的客户”，准备批量撤销高级权益。Dry-run 显示 812 个账号，十分钟后点击执行时查询却重新求值，已有 37 个客户完成付款；另一个 worker 在第三方系统更新成功后超时，重试又发了一次降级通知。问题不在按钮有没有二次确认，而在批准的对象和实际产生效果的对象不是同一份事实。

Agent 人工审批门讨论模型动作何时交给人，审批防重放把一次授权绑定到 Agent 执行，高风险 AI 人工 Override则记录人如何改变机器建议。本篇面对的是运营人员主动发起的多客户变更：重点是冻结目标集合、逐项验证状态，并在部分成功后重建净效果。财务金额仍由 AI 用量计量账本等专用账本处理，不能把本控制面当成会计系统。

Dry-run 必须产出不可变计划

创建 bulkOperationPlan.v1 时，在一致性快照内解析筛选条件，记录 query revision、租户范围、操作者权限快照和每个目标的 resourceVersion。计划包含操作 schema、规范化参数、目标清单的 Merkle root、预计影响、不可逆项、速率上限及过期时间。界面展示的计数从这份清单读取；执行器不得再次跑原筛选 SQL。

{
  "schema": "bulkOperationPlan.v1",
  "planId": "bop_01K...",
  "operation": "entitlement.revoke@3",
  "targetSetRoot": "sha256:91c...",
  "targetCount": 812,
  "snapshotWatermark": "pg:00016/B374D848",
  "authorizationGeneration": 44,
  "expiresAt": "2026-07-19T12:30:00Z",
  "maxEffectsPerMinute": 50
}

Dry-run 对每个目标执行与真实路径相同的 schema、授权、前置条件和政策判断，只把 effect adapter 换成 PLAN_ONLY。结果区分 ELIGIBLE、WOULD_SKIP_STALE、WOULD_DENY 与 UNKNOWN_DEPENDENCY，不能把未知算入可执行成功。计划一旦 FROZEN 便不允许改参数或增删目标；任何修改产生新 plan ID 和摘要，原审批自动失效。PostgreSQL 事务隔离能提供读取一致性，但业务版本仍须逐项保存，避免批准后资源变化。

审批记录绑定 plan digest、风险摘要、目标数、操作版本、截止时间和审批人角色。高风险操作要求发起者与批准者分离，符合 NIST 控制中的职责分离原则。批准页面必须抽样展示真实目标、各原因桶和最坏影响，而不是只显示“812 项”。审批过期、权限撤销或政策 generation 变化都把状态退回 REVIEW_REQUIRED。

每个目标只有一个效果身份

计划状态沿 DRAFT -> FROZEN -> APPROVED -> EXECUTING -> RECONCILING 推进，审批失效进入 REVIEW_REQUIRED，暂停走 EXECUTING -> PAUSING -> PAUSED，最后才是 COMPLETED、PARTIAL 或 ABORTED。每个 item 保存 targetId、expected resource version、effectKey = H(planId,targetId,operationRevision)、attempt、adapter receipt 和 observed result。外部 I/O 前以 PREPARED -> DISPATCHING CAS 同时匹配 plan digest、审批与授权 generation、execution epoch 和目标版本；暂停或撤权提升同一 gate，只能与 dispatch 一方成功。已付款客户得到 SKIPPED_PRECONDITION，而不是先撤销再补回来。

数据库内变更把业务写入和 item receipt 放在同一事务。第三方调用优先传稳定 idempotency key 和条件版本；HTTP 方法的通用幂等语义来自 RFC 9110，但产品仍要确认供应商的键作用域与保留期。若对方成功后连接断开，item 进入 UNKNOWN_EFFECT。只有 provider operation 的权威终态，或已达到该 operation watermark 的一致读，才能证明 APPLIED/NOT_APPLIED；过期副本、超时和越过幂等保留期的 NOT_FOUND 都保持 UNKNOWN。禁止换键或再次调用。

多 Agent Task Claim防止迟到 worker 提交，但它不证明第三方是否已生效；所以协调所有权与业务效果必须分别记录。暂停只阻止尚未开始的 item，不能把已应用项改名为取消。需要恢复时创建显式 compensation plan，列出可逆范围、逆操作版本和新的审批，禁止用数据库 UPDATE 抹掉原结果。

故障套件与量化门禁

注入目标在审批后改变、同一批准按钮连点、两个 executor 抢同一 item、批准期间权限被撤销、第三方 200 后丢响应、429 跨过幂等窗口、执行到 40% 时暂停、补偿只成功一半，以及对账读到过期副本。系统必须保持目标数不增、旧版本不执行，并按 provider attempt/effect 证明每个 effect key 最多一个真实效果；确认缺失时保持 UNKNOWN_EFFECT，不能只靠本地 receipt 自证去重。

发布门要求：plan root 在审批与执行入口匹配率 100%；dispatch CAS 覆盖率 100%；一万次重复投递产生的 provider 重复 attempt/effect 为 0；未知项不得被计入成功率；暂停 gate 提升后新 dispatch 为 0；逐项 receipt 汇总与计划终态计数差为 0。高风险批次先限制最多 50 个目标，连续 20 批无未解释差异后才能提高上限。

上线先 shadow 生成计划并与人工脚本目标集合比较，再启用只读通知类操作，最后才开放权益变更。若 stale skip 超过 2%、未知效果超过 0.5% 或对账不守恒，提升 execution epoch、停止新 item 并把入口切回旧工具；旧流程也必须消费同一 dispatch registry，只接管明确未开始项。回滚控制面不是回滚客户事实，任何已发生效果都必须通过对账和补偿闭环。