## 变更冻结期冲突检查 {.case data-case-id="070"} | 字段 | 值 | | --- | --- | | 案例编号 | `070` | | 行业 / 部门 | 金融 / 运维 | | 角色 | 变更经理 | | 难度 | `进阶` | | 调用来源 | `manual`（变更提交后由变更经理发起一次手动调用，带入变更单与冻结期日历） | 财报期、大促、节假日各有一张冻结期日历，变更单一多就有人忘了核对，冻结期里执行了变更就是生产事故。目标：每次变更提交后，由变更经理发起一次手动调用，让工作流比对变更窗口与冻结期日历（财报期/大促/节假日）与受影响系统清单，无冲突经变更经理确认后放行进入正常变更流程，有冲突强制升级变更委员会（CAB）人工裁决。设一条最高优先级红线：落在冻结期或影响冻结系统的变更，无论其他检查结果如何一律强制升级 CAB，绝不自动放行。指标：冲突变更被自动放行的为 0 例；检查结论 100% 留审计时间戳与依据。 - **覆盖**：变更窗口与冻结期日历比对、受影响系统与冻结系统清单比对、三类结果分流、检查结论留审计时间戳与依据。 - **不覆盖**：变更的审批与执行（在变更系统完成，工作流只做冲突检查与编排）、冻结期日历的维护、变更单内容的修改。 - **假设**：变更单由 App/Extension 在调用源头白名单化为变更编号、变更窗口与受影响系统代号；冻结期日历（财报期/大促/节假日）、冻结系统清单与 CAB 标识在调用时作为输入提供；系统名一律脱敏为代号，代号映射由平台侧持有，不进入本工作流。 把下面这段发给 Loop，它会在后台帮你创建这个 Workflow： ```text 帮我创建一个 Workflow：变更提交后由变更经理发起一次手动调用，App/Extension 先在源头把变更单与冻结期日历白名单化——只放行变更编号、变更窗口、受影响系统代号、冻结期日历（财报期/大促/节假日）与冻结系统代号，真实系统名与内部资产标识在源头即被伪名化（代号映射由平台侧持有，不进入本工作流），检查 Agent 也用代号标识。逐项比对是否冲突并返回（变更编号、有无冲突、命中依据）；CAB 升级目标（CAB 标识）作为调用输入提供，不由 Agent 输出或自行查找。 触发：手动发起一次调用，不监听任何事件；调用时带入 CAB 标识（作为调用输入提供，用于红线升级）。 检查 Agent 回传 JSON：{change_ref: 变更编号, conflict_flag: 布尔, hit_basis: [非空字符串], input_complete: 布尔, fields_missing: [枚举(变更窗口|受影响系统|日历)], audit_ts: 时间戳}。状态矩阵：change_ref、input_complete、audit_ts 始终必填；input_complete=false 当且仅当 fields_missing 非空，此时 conflict_flag 与 hit_basis 禁止出现；input_complete=true 当且仅当 fields_missing 为空，此时 conflict_flag 必填，conflict_flag=true 时 hit_basis 必为非空且逐项非空，conflict_flag=false 时 hit_basis 必为空数组。仅接受这些组合；其余 callback 一律拒绝，原 Effect 保持 awaiting。 结果分三类处理（先判数据有效性，再按优先级判红线与其余）： 输入不完整（变更单缺变更窗口或受影响系统、日历缺失）：告警并留审计时间戳，通知调用方补全后新开一次调用，不重试、不猜测、不当作无冲突——数据无效优先拦截，不进入冲突判定。 有冲突（红线）：变更窗口落在冻结期内、或受影响系统命中冻结系统清单——无论其他检查结果如何，一律强制升级变更委员会（CAB）人工裁决，绝不自动放行，并留审计时间戳与命中依据；这是最高优先级，命中即短路。 无冲突：经变更经理确认后放行，进入正常变更流程并留审计时间戳与检查依据——审批与执行仍在变更系统完成，本工作流只做冲突检查与编排，不直接执行任何变更。 审批：无冲突放行前必须经变更经理确认，确认时能看到比对结果与依据（系统以代号呈现）；审批为二值确认或驳回，不设自动超时，无默认通过/否决；驳回则本次失败结束并留审计，不自动改判。有冲突走 CAB 人工裁决，不经本工作流放行。 异常：检查 Agent 回传不合结构就停在等待点等它重新提交，不自动重跑；通知发送失败按重试上限重试，仍失败则升级到值班频道（值班频道作为调用输入提供）并保留待发内容供人工补发。 完成：放行、CAB 升级、输入不完整告警各自留审计时间戳与依据后结束。 ``` ![案例 070 变更冻结期冲突检查：变更提交后由变更经理手动发起一次调用，比对变更窗口与冻结期日历及冻结系统清单；有冲突（落在冻结期或影响冻结系统）无论其他检查结果一律强制升级 CAB 人工裁决绝不自动放行，无冲突经变更经理确认后放行进入正常变更流程（审批与执行在变更系统），输入变更单或日历不完整告警留审计通知调用方补全后新开调用不重试；检查结论留审计时间戳与依据，回传不合结构停在原等待点，驳回则失败结束](../../../media/cases/fig-case-070-01-flow.svg){#fig-case-070-01 width=92%} 如上图所示，正常路径、人工决策与异常同时可见，三类结果都有可见回执： 1. **手动触发**：变更经理在变更提交后发起一次调用，App/Extension 在源头把变更单白名单化为变更编号、变更窗口与受影响系统代号，连同冻结期日历与冻结系统清单带入。 2. **比对冻结冲突**：检查 Agent 用代号逐项比对变更窗口与冻结期、受影响系统与冻结系统清单并回传（变更编号、有无冲突、命中依据）；CAB 升级目标取自调用输入提供的 CAB 标识，不由 Agent 输出。回传缺任一必填字段视为不合结构，停在原等待点，等其重新提交，不自动重跑。 3. **三类结果分流（先判数据有效性，再判红线）**： - **输入不完整**：变更单缺变更窗口或受影响系统、日历缺失时告警留审计时间戳，通知调用方补全后新开一次调用，不重试、不猜测——数据无效优先拦截，不进入冲突判定。 - **有冲突（红线）**：变更窗口落在冻结期内或影响冻结系统，无论其他检查结果，强制升级 CAB 人工裁决，绝不自动放行，留审计时间戳与命中依据。 - **无冲突**：经变更经理确认后放行进入正常变更流程，审批与执行在变更系统完成，工作流只做冲突检查与编排，留审计时间戳与检查依据。 你不需要手写代码或配置。把上面的提示词发给 Loop，AI 会理解意图、在后台画出这个"手动调用 + 红线强制升级 + 三路分流"流程——它知道"比对冻结冲突"需要一个发消息并等待回调的 Agent 环节、"先判红线再分流"需要一个条件路由且红线优先级最高、"放行前确认"需要一个审批环节、"升级与告警"各需要一个发消息环节，并把它们连起来。AI 还会在后台校验流程结构是否完整，你不必关心这些技术细节。 - **冲突变更被当作无冲突放行**：这是最危险的漏判。靠红线兜底——只要变更窗口落在冻结期内或受影响系统命中冻结系统清单，无论其他检查结果如何一律强制升级 CAB，绝不自动放行。 - **变更单或冻结期日历不完整**：告警留审计时间戳，通知调用方补全后新开一次调用；不重试、不猜测、不把输入缺失当作无冲突放行。 - **变更经理驳回放行**：本次失败结束并留审计；要放行就再发起一次确认，没有"AI 自动改判"。 - **通知发送失败**：按重试上限重试投递；超过上限则升级到值班频道，并保留待发内容供人工补发。 - **检查 Agent 回传不合结构**：本次完成请求被拒绝，停在等待点等其修正后重新提交，不自动重跑。 - **长时间无人审批**：审批本身不设自动超时，流程停在等待状态。若业务需要响应时限，由另一条定时检查的 Workflow（或值班人员）扫出超时项并通知变更经理。 - **变更在检查后被改期**：本工作流只对本次调用的变更单快照负责；改期后的变更由变更经理再发起一次调用重新检查，旧结论不自动沿用。 无冲突放行前必须经变更经理确认。确认时变更经理能看到比对结果与命中依据（系统名已脱敏为代号），所以是"有依据的快速决策"而非盲目拍板。审批只有确认或驳回两种结果，不设自动超时、无默认通过/否决，驳回即本次失败结束并留审计，没有"AI 自动改判"。有冲突的变更不经本工作流放行，一律由 CAB 人工裁决。若要更严（如接近冻结期边界的变更也加签系统 Owner），在提示词里写明，AI 会在流程里多加一个审批环节。 本工作流对冻结期日历与冻结系统清单的比对由获授权检查 Agent 通过 App/Extension 完成，工作流本身不直接调用外部系统。变更单由 App/Extension 在调用源头白名单化为变更编号、变更窗口与受影响系统代号，与冻结期日历、冻结系统清单及 CAB 标识（红线升级目标取自调用输入，不由 Agent 输出或查找）一起作为调用输入提供；进入 Agent 消息、Run/Activation/Effect 记录与 App/Extension 工具日志仅记录白名单/令牌化字段（原值不进入以上任何一层），可回溯个人或敏感资产的字段在源头即被令牌化/伪名化（代号映射由平台侧持有），并按 10% 抽查四层实际记录。变更系统的访问凭据用 `` 占位，由 Agent 运行时从密钥引用。变更的审批与执行仍在变更系统完成，本工作流只做冲突检查与编排，不直接执行任何变更。比对与回执遵循最小披露：系统名一律用代号，不外带真实系统名与配置细节。 - **回放集与基准**：取最近 3 个月 40 张变更单快照（含无冲突、冻结期内、影响冻结系统、输入缺失样本）回放，人工基准答案为按日历与清单算出的冲突清单；检查判定与基准一致率 ≥ 95%。 - **红线防线**：基准为有冲突的变更 100% 强制升级 CAB，被自动放行的为 0 例。 - **输入缺失**：变更单或日历不完整的调用 100% 出告警回执并留审计时间戳，被当作无冲突放行的为 0 例，不出现猜测补全的窗口或系统。 - **源头脱敏**：进入 Agent 消息、Run/Activation/Effect 记录与 App/Extension 工具日志的字段 100% 在白名单内（原值不进入以上任何一层），按 10% 抽查四层实际记录，回执内容 100% 用系统代号，不含真实系统名与配置细节。 - **结果可见**：放行、CAB 升级、输入不完整告警三类结果 100% 各有可见回执并留审计时间戳与依据，不出现静默成功。 - **分母与口径**：一致率分母为回放变更总数；每次运行记录比对与结论时间戳。 ### 复用与变体 - **同构迁移**：监管报送期变更检查、预算冻结期采购检查、财年结账期权限变更检查。 - **分级路由**：核心系统变更无论有无冲突一律加签系统 Owner 双审，普通系统只在有冲突时升级 CAB。 - **写回系统**：CAB 裁决后再加一个 Agent 环节，由它通过 App/Extension 把裁决结论写回变更单；写回须是获授权 Agent 经 App/Extension 的幂等动作（幂等键=变更编号+裁决轮次），响应未知先查后写、按重试上限有限重试、失败升级值班并置"待处理"保留补偿，全程留审计。