## 重大事件指挥战报草拟 {.case data-case-id="076"} | 字段 | 值 | | --- | --- | | 案例编号 | `076` | | 行业 / 部门 | 互联网 / 跨部门 | | 角色 | 事件指挥官 | | 难度 | `复杂` | | 调用来源 | `manual`（重大事件响应中由指挥官发起一次手动调用，带入时间线安全引用（令牌），原始时间线记录留在事件系统） | 重大事件进行中，指挥官一边决策一边被"每 30 分钟要一份战报"拖住：手写战报慢、口径容易前后不一，写快了又容易把未确认的猜测写成事实发出去。目标：由指挥官手动发起一次调用，调用输入只带时间线安全引用（令牌），原始时间线记录留在事件系统；App/Extension 凭引用在源头抽取并脱敏——系统与客户名伪名化为代号（映射由平台侧持有，不进入本工作流），只放行已确认事实条目（时间、动作、负责人、当前状态）给获授权的草拟 Agent，时间线原文与其余字段不进入工作流；未确认的影响面与根因一律标"待确认"不编造；流程按串行收口——指挥官确认（第一道二值）后生成并分发内部战报到内部频道，分发范围含对外口径时再提交公关负责人会签（第二道独立二值）确认后对外发布、驳回退回修改，任一道驳回都退回修改重新提交，每次确认都只有一个通过出口。每次战报留版本与时间戳，证据留痕。指标：从发起调用到战报草稿就绪 < 5 分钟；发出的战报中事实性错误 0 例、未确认信息未标注 0 例。 - **覆盖**：手动调用凭时间线安全引用（令牌）抽取已确认事实并草拟战报、只陈述已确认事实、指挥官确认后生成并分发内部战报、对外口径经公关会签后对外发布、每次留版本与时间戳、时间线数据源不可达单列处理。 - **不覆盖**：自动对外发布、自动判定根因、自动执行处置动作、自动回复客户、把事件时间线原文带入工作流。 - **假设**：有经授权能凭时间线安全引用（令牌）经 App/Extension 抽取事件时间线已确认事实条目的草拟 Agent，App/Extension 在源头完成伪名化，原始时间线记录留在事件系统不进入工作流与日志；分发范围（内部/对外）、内部频道与对外发布目标都在调用时作为输入提供；客户与系统信息以代号呈现。 把下面这段发给 Loop，它会在后台帮你创建这个 Workflow： ```text 帮我创建一个 Workflow：重大事件响应中由事件指挥官手动发起一次调用，调用输入只带时间线安全引用（令牌）——原始时间线记录留在事件系统，不进入工作流；App/Extension 凭引用在源头抽取并脱敏——系统名与客户名伪名化为代号（代号映射由平台侧持有，不进入本工作流），只放行已确认事实条目（时间、动作、负责人、当前状态）给获授权的草拟 Agent；未确认的影响面与根因一律标"待确认"，不编造、不推断。 触发：手动发起调用，调用时带入时间线安全引用（令牌）、分发范围、内部频道、对外发布目标、草拟 Agent、审批人（事件指挥官）、会签人（公关负责人）、恢复 Owner 令牌和值班频道（内部频道、对外发布目标与值班频道均作为调用输入提供）。 草拟 Agent 回传 JSON：{incident_ref: 事件令牌（取自调用输入，不由 Agent 生成）, timeline_complete: 布尔, facts: [{ts: 时间, action: 动作, owner_code: 负责人代号, state: 当前状态}], pending_items: [枚举(影响面|根因)], source_ok: 布尔, fields_missing: [枚举(时间线)], version: 平台版本令牌（由平台在草拟请求登记时签发，Agent 回传只引用该令牌，不得自造版本号）, audit_ts: 时间戳}。状态矩阵：incident_ref、source_ok、timeline_complete、audit_ts 始终必填；source_ok=false 时 timeline_complete 必为 false、fields_missing 必为 [时间线]，facts、pending_items、version 禁止出现；source_ok=true 且 timeline_complete=false 时 fields_missing 必为 [时间线]，facts、pending_items、version 禁止出现；source_ok=true 且 timeline_complete=true 时 fields_missing 必为空，facts、pending_items、version 必填，facts 必为非空数组且每个元素的 ts、action、owner_code、state 逐项必填。取数成功但 facts=[] 只能回传 timeline_complete=false，不能进入完整态。仅接受这些组合；其余 callback 一律拒绝，原 Effect 保持 awaiting。 结果分流（先判取数成败，再判完整性）： 时间线数据源不可达（取数失败或数据陈旧）：告警失败、留审计时间戳，按重试上限重试，仍失败则升级到值班频道（作为调用输入提供）；不当作"时间线不完整"，也不基于残缺数据草拟。 时间线不完整（取数成功但记录缺关键段落）：告警、留审计时间戳，提示指挥官补全时间线后新开一次调用，不重试、不基于残缺时间线草拟——告警新开调用，不重试。 时间线完整：facts 非空且每项字段完整时，按脱敏时间线草拟战报并进入串行两道审批。第一道指挥官审批（二值）：确认则生成内部战报并分发到内部频道（作为调用输入提供），驳回则退回修改重新提交。第二道公关会签（二值，仅分发范围含对外口径时发生）：确认后由授权 Agent 把战报发布到对外发布目标（作为调用输入提供），驳回则退回修改重新提交。每道审批只有一个通过出口，确认后不回流重审。 审批：两道串行、各自独立、均为二值（确认或驳回，不设自动超时，无默认通过/否决）：第一道事件指挥官确认事实与内部口径，唯一后继是"生成并分发内部战报"；第二道公关负责人会签对外口径，确认后唯一后继是"对外发布"，任一道驳回则退回修改重新提交——指挥官确认不等于对外放行，两层确认缺一不可。 异常：草拟 Agent 回传不合结构就停在等待点等它重新提交，不自动重跑；对外发布经授权 Agent 与 App/Extension 完成并以幂等键=事件令牌+平台版本令牌+期望变化（发布该版战报）+发布目标——事件令牌与发布目标是可信调用输入，战报版本用平台在草拟请求登记时签发的版本令牌（Agent 回传只引用该令牌，不自造版本号），同一事件同一版本对同一发布目标只发布一次，不同事件或不同发布目标互不顶替，重复调用不重复发布，重试复用同一幂等键；发布响应未知（对方已接收但本地超时）时先查后写——按该幂等键查询已发布记录，再决定补发或标记，不盲目重发。取消只停止后续 Workflow 图，不召回已送达消息、不自动补偿已发布内容；必须保留外部 receipt，并由恢复 Owner 按同一幂等键读取权威状态后决定保留、另建补偿行动卡或升级。通知发送失败按重试上限重试，仍失败则升级到值班频道并保留待发内容供人工补发；时间线为空按时间线不完整处理，不当作零结果。 完成：内部战报分发、对外发布、驳回重提、时间线不完整告警、取数失败告警各自留审计时间戳与版本号后结束。 ``` ![案例 076 重大事件指挥战报草拟：指挥官手动发起调用，输入只带时间线安全引用，App/Extension 在源头抽取并脱敏；完整态 facts 必须非空且逐项含时间、动作、负责人、当前状态，取数成功但 facts 为空统一按时间线不完整，不能进入审批。数据源不可达走取数失败，时间线不完整告警新开调用；非空完整时间线串行经指挥官审批与按需公关会签后分发，对外发布使用事件令牌+平台版本令牌+期望变化+目标的幂等键并先查后写；回传不合结构停在原等待点](../../../media/cases/fig-case-076-01-flow.svg){#fig-case-076-01 width=92%} 如上图所示，正常路径、人工决策与异常同时可见： 1. **手动触发**：重大事件响应中由指挥官发起一次调用，带入时间线安全引用（令牌）、分发范围、内部频道、对外发布目标、草拟 Agent、审批人、会签人与值班频道；原始时间线记录留在事件系统。 2. **草拟战报**：获授权 Agent 经 App/Extension 凭时间线安全引用抽取源头脱敏后的已确认事实条目，按记录草拟战报——只陈述已确认事实（时间、动作、负责人、当前状态），未确认的影响面与根因标"待确认"不编造；系统与客户名以代号呈现。回传缺任一必填字段视为不合结构，停在原等待点，等其重新提交，不自动重跑。 3. **结果分流（先判取数成败，再判完整性，两者互不混入）**： - **时间线数据源不可达**：取数失败或数据陈旧，走自己的告警路线，告警失败、留审计时间戳，按重试上限重试，仍失败则升级到值班频道；不当作"时间线不完整"。 - **时间线不完整**：取数成功但记录缺关键段落，告警、留审计时间戳，提示指挥官补全时间线后新开一次调用（告警新开调用，不重试），不基于残缺时间线草拟。 - **时间线完整**：`facts` 非空且逐项字段完整才进入串行两道审批。第一道指挥官审批（二值）：确认的唯一后继是生成内部战报并分发到内部频道，驳回则退回修改重新提交。第二道公关会签（二值，仅分发范围含对外口径时发生）：确认的唯一后继是由授权 Agent 把战报发布到对外发布目标，驳回则退回修改重新提交。每道只有一个通过出口，对外发布以幂等键=事件令牌+平台版本令牌+期望变化（发布该版战报）+发布目标，响应未知时先按该幂等键查已发布记录再补发或标记。 你不需要手写代码或配置。把上面的提示词发给 Loop，AI 会在后台帮你画出这个"手动触发 + 双层确认 + 两路分流"流程——它知道"草拟战报"需要一个发消息并等待回调的 Agent 环节、"指挥官确认 + 公关会签"需要审批环节、"分两类结果"需要一个条件路由、"发出与告警"各需要一个发消息环节，并把它们连起来。AI 还会在后台校验流程结构是否完整，你不必关心这些技术细节。 - **未确认的猜测被写进战报**：这是战报最危险的错误，会带着指挥官的署名传遍全公司甚至客户。靠结构兜底——App/Extension 在源头只放行已确认事实，草拟只允许陈述时间线记录中的已确认事实，未确认的影响面与根因一律标"待确认"，指挥官内部确认与公关会签两道人工关卡都在发出之前。 - **时间线数据源不可达或数据陈旧**：与"时间线不完整"分开处理——按取数失败告警、留审计时间戳，按重试上限重试，仍失败则升级到值班频道由人工确认；不基于残缺数据草拟，也不误报为"时间线不完整"。 - **时间线不完整或为空**：取数成功但缺关键段落，不当作零结果、不静默结束，也不基于残缺时间线草拟，而是告警、留审计时间戳，提示指挥官补全后新开一次调用；本流程不重试，因为时间线要人来补，重试没有意义。 - **空 facts 被标为完整**：`source_ok=true && timeline_complete=true` 时 facts 必须非空；空数组只能回传 timeline_complete=false 并走不完整告警。任何 facts=[] 的完整态 callback 都被拒绝，原 Effect 保持 awaiting。 - **对外发布"对方已接收但本地超时"**：发布经授权 Agent 与 App/Extension 完成，以幂等键=事件令牌+平台版本令牌+期望变化（发布该版战报）+发布目标——事件令牌与发布目标是可信调用输入，战报版本用平台在草拟请求登记时签发的版本令牌（Agent 回传只引用，不自造版本号）；同一事件同一版本对同一发布目标只发布一次，不同事件或不同发布目标互不顶替，重复调用不重复发布，重试复用同一幂等键；响应未知时先查后写——按该幂等键查询已发布记录，再决定补发或标记，不盲目重发造成重复对外口径。 - **取消时发布可能已经发生**：取消只停止后续 Workflow 图，不召回消息，也不自动撤回或补偿外部内容；保留 receipt，由恢复 Owner 按事件令牌+平台版本令牌+期望变化（发布该版战报）+发布目标查询权威状态，再决定保留、另建补偿行动卡或升级，不能因 Run 已取消就假定外部结果不存在。 - **通知发送失败**：按重试上限重试投递；超过上限则升级到值班频道（作为调用输入提供），并保留待发内容供人工补发——战报发不出去和发错内容一样致命，待发内容必须留底。 - **指挥官或公关负责人驳回**：退回修改重新提交，没有"AI 自动改口径后直接发出"；对外口径由公关把关，这是会签环节存在的意义。 - **草拟 Agent 回传不合结构**：本次完成请求被拒绝，停在等待点等其修正后重新提交，不自动重跑。 - **长时间无人审批**：审批本身不设自动超时，流程停在等待状态。重大事件中若指挥官失联，由现场升级机制（值班频道）人工接管，不走自动发布。 战报有两道串行且各自独立的审批，各为二值（确认或驳回，不设自动超时，无默认通过/否决），且每道只有一个通过出口、一个确认动作只有一个后继。第一道是事件指挥官内部确认：确认事实与内部口径，确认的唯一后继是生成内部战报并分发到内部频道（作为调用输入提供），驳回则退回修改重新提交。第二道是公关负责人会签：只在分发范围含对外口径时发生，确认对外表述与合规边界，确认的唯一后继是对外发布（发布目标作为调用输入提供），驳回则退回修改重新提交——指挥官确认不等于对外放行，两道确认缺一不可，没有"指挥官批了就直接对外"。没有超时自动发布——重大事件的对外信息宁可慢一分钟，不可错一句。工作流只草拟与留痕，不替指挥官决定说什么、对谁说。每次战报留版本号与审计时间戳，证据留痕，事后复盘时可逐版核对口径演变。 本工作流对事件时间线的读取由获授权 Agent 凭时间线安全引用（令牌）经 App/Extension 完成，工作流本身不直接调用外部系统；调用输入只带安全引用，原始时间线记录留在事件系统，不进入工作流与日志。进入 Agent 消息、Run/Activation/Effect 记录与 App/Extension 工具日志仅记录白名单/令牌化字段（原值不进入以上任何一层），可回溯个人或敏感资产的字段在源头即被令牌化/伪名化，并按 10% 抽查四层实际记录——App/Extension 在源头把系统名与客户名伪名化为代号，映射由平台侧持有，只放行已确认事实条目。分发范围、内部频道、对外发布目标、恢复 Owner 与值班频道均作为调用输入提供——所有可信投递目标都来自调用输入，不由 Agent 自行查找；时间线系统的访问凭据用 `` 占位，由 Agent 运行时从密钥引用。对外发布由授权 Agent 经 App/Extension 完成，以幂等键=事件令牌+平台版本令牌+期望变化（发布该版战报）+发布目标（事件令牌与发布目标为可信调用输入，版本用平台在草拟请求登记时签发的版本令牌；同一事件同一版本对同一发布目标只发布一次，重试复用同一幂等键），发布响应未知（对方已接收但本地超时）时先按该幂等键查已发布记录再写，不盲目重发。取消后仍保留 receipt 并按同一键核验权威状态，由恢复 Owner 决定保留、补偿或升级；取消本身不撤回外部内容。时间线为空或数据源不可达分别按时间线不完整与取数失败告警处理，不当作零结果、不进入草拟路径。 - **回放集与基准**：取最近 10 次重大事件的时间线记录回放，人工基准答案为按时间线整理的已确认事实清单；草稿事实条目与基准一致率 100%，事实性错误 0 例。 - **非空完整态**：完整时间线样本 100% 含至少一条 facts 且逐项字段完整；取数成功但 facts=[] 的样本 100% 走 timeline incomplete，进入审批或发布的 0 例。 - **待确认标注**：未确认的影响面与根因 100% 标"待确认"，不出现编造或推断内容（逐份核对）；进入 Agent 消息、Run/Activation/Effect 记录与 App/Extension 工具日志的字段 100% 在白名单内（仅令牌化/白名单字段，时间线原文与原值不进入以上任何一层），并按 10% 抽查四层实际记录，客户与系统信息 100% 以代号呈现。 - **时效**：从发起调用到战报草稿就绪的中位时间 < 5 分钟。 - **双层确认**：内部战报 100% 在指挥官确认后生成并分发到调用输入提供的内部频道，含对外口径的 100% 另经公关会签后发布到调用输入提供的对外发布目标；每个确认动作只有一个后继，两道驳回后 100% 退回重新提交，无自动发布 0 例外。 - **取数失败（技术路径）**：时间线数据源不可达或数据陈旧的样本 100% 按取数失败处理——告警回执、留审计、按重试上限重试、仍失败升级值班频道；被误报为"时间线不完整"的 0 例，不基于残缺数据草拟 0 例外。 - **时间线不完整（业务缺项）**：取数成功但缺关键段落的样本 100% 按时间线不完整处理——告警回执、留审计、提示补全后新开调用且不重试（业务缺项由人补，重试无意义）；被误报为取数失败或当作零结果的 0 例。 - **先查后写与幂等**：模拟"对方已接收但本地超时"的对外发布 5 次，同一幂等键（事件令牌+平台版本令牌+期望变化（发布该版战报）+发布目标）重复发布 0 例，每次均按该幂等键查证已发布记录后闭环；跨事件同版本令牌互不顶替（不同事件各自的 v1 均能正常发布）。 - **取消后恢复**：模拟发布前取消、已发布后取消和结果不明后取消各 3 次；取消均只停止后续图且保留 receipt，自动召回或自动补偿 0 次，恢复 Owner 100% 按同一幂等键取得权威状态并记录保留、补偿或升级决定。 - **留痕**：每次战报 100% 留版本号与审计时间戳，按 10% 抽样核对版本连续性。 ### 复用与变体 - **同构迁移**：安全事件通报草拟、监管事件报告初稿、重大变更失败对外说明。 - **定期战报**：长事件中改为 schedule 每 30 分钟自动草拟一版，确认流程不变。 - **写回系统**：发出后再加一个 Agent 环节，由它通过 App/Extension 把战报版本归档到事件档案并关联工单；写入须是获授权 Agent 经 App/Extension 的幂等动作（幂等键=可信事件令牌+平台签发版本令牌+期望变化（归档该版战报）+目标事件档案），响应未知先查后写、按重试上限有限重试、失败升级值班并置"待处理"保留补偿，全程留审计。