## 服务故障公告草拟与发布确认 {.case data-case-id="031"} | 字段 | 值 | | --- | --- | | 案例编号 | `031` | | 行业 / 部门 | SaaS / 客服 | | 角色 | 值班经理 | | 难度 | `进阶` | | 调用来源 | `manual`（故障宣告后由值班经理发起一次手动调用，带入故障单要点的安全引用与影响面） | 故障发生后对外公告发慢了客户炸群，发快了又容易把没确认的原因写出去、事后被打脸。目标：故障宣告后由值班经理发起一次手动调用，带入故障单要点的安全引用（令牌）与影响面，让 Agent 草拟对外公告——只陈述故障单中的已确认事实，未确认的原因与恢复时间一律写"待确认"，不编造；值班经理与公关负责人确认后发布到状态频道并留审计。指标：从调用到公告发布（确认后）中位数 < 20 分钟；抽查已发布公告 100% 无未确认原因被当作事实陈述。 - **覆盖**：一次手动调用带入故障令牌、公告类型、平台分配的公告版本、发布目标与故障单要点的安全引用（令牌）、Agent 草拟公告、双角色确认或驳回、发布到状态频道并留审计。 - **不覆盖**：故障处置与恢复本身、内部通报、多轮进展更新（每次更新重新发起一次调用）、自动监测故障。 - **假设**：故障令牌、公告类型、平台分配的公告版本与发布目标由调用方在启动时作为可信输入提供；故障单要点以安全引用（令牌）与影响面由值班经理在调用时作为输入提供，事实与未确认项在输入里分列；状态频道与公关负责人作为调用输入提供。 把下面这段发给 Loop，它会在后台帮你创建这个 Workflow： ```text 帮我创建一个 Workflow：故障宣告后由值班经理发起一次手动调用，调用时带入故障令牌、公告类型、平台分配的公告版本、发布目标（以上均为可信调用输入，不取自 Agent 输出）、故障单要点的安全引用（令牌——原始故障单留在工单系统，App/Extension 凭引用在进入工作流前抽取已确认事实、未确认项等白名单字段）与影响面、状态频道、公关负责人和草拟 Agent，由 Agent 草拟对外公告并返回（公告草稿、引用的故障单要点、未确认项列表）。 触发：由值班经理手动发起一次调用，"故障宣告"本身就是这次手动调用的起点，不是事件自动触发；故障令牌、公告类型、平台分配的公告版本与发布目标由调用方在启动时提供（首次公告与恢复公告的公告类型不同，恢复公告类型为"恢复"，不会与首次公告互相覆盖）。 结果分流： 草稿就绪：进入人工确认，值班经理与公关负责人确认后发布到状态频道并留审计时间戳；公告只陈述输入中列为已确认的事实，未确认的原因与恢复时间一律写"待确认"，不编造、不推断。 驳回：本次失败结束、不发公告，留审计时间戳；修改输入或口径后新开一次调用，不在原调用上反复改稿重试。 输入要点不完整（缺影响面或事实与未确认项混列）：不重试——同一调用的不完整输入不会因重跑补齐；告警失败、留审计时间戳，并通知调用方（值班经理）更正后新开一次调用。 时间线不完整（要点齐备但故障时间线缺关键节点）：与输入要点不完整分开处理——告警留审计时间戳，通知值班经理补全时间线后新开一次调用，不据此编造时间线。 审批：公告必须经值班经理与公关负责人双确认后才发布，只有确认或驳回两种结果，审批本身不设自动超时、无默认通过或否决，驳回不发公告。 发布（外部写入）：发布到状态页由获授权 Agent 经 App/Extension 完成，可信目标仅限调用时指定的状态频道/状态页与本次故障公告业务维度；以故障令牌+公告类型（期望变化）+平台分配的公告版本+发布目标为稳定幂等键（全部取自调用方带入的可信输入，不以 Agent 草稿输出充当键）——同键只发布一版公告，恢复公告类型为"恢复"、与首次公告不同键不冲突，响应未知（如超时）先查状态页已发布的版本再决定重发或跳过，配有限重试；超过上限升级到值班频道并保留待发公告人工补发，全程留审计时间戳。 异常：草拟 Agent 回传不合结构就停在等待点等它重新提交，不自动重跑；状态页系统不可达（取数/发布通路失败）按告警失败处理、留审计时间戳，按重试上限重试，仍失败则升级到值班频道并保留待发公告供人工补发，与时间线不完整是两类不同的失败。 取消：取消只停止尚未调度的后续图，不召回已发消息或外部结果、不自动补偿；保留 Effect 与外部 receipt，恢复时按完整业务键“故障令牌 + 公告类型（期望变化）+ 平台分配的公告版本 + 发布目标”查询权威状态，由恢复 Owner 决定保留结果、另建补偿行动卡或升级。 完成：公告发布成功或各失败回执发出后结束，均留审计时间戳。 ``` ![案例 031 服务故障公告草拟与发布确认：值班经理故障宣告后手动发起一次调用带入故障单要点安全引用（令牌）与影响面，Agent 草拟公告只陈述已确认事实、未确认写待确认；双角色确认后发布状态频道留审计，驳回失败结束不发公告；输入要点不完整不重试、告警留审计并通知调用方更正后新开调用，时间线不完整单独告警由人补全后新开调用，状态页不可达按发布失败重试升级；回传不合结构停在原等待点](../../../media/cases/fig-case-031-01-flow.svg){#fig-case-031-01 width=92%} 如上图所示，正常路径、人工决策与异常同时可见： 1. **手动发起调用**：故障宣告后，值班经理发起一次手动调用，带入故障令牌、公告类型、平台分配的公告版本、发布目标等可信输入，以及故障单要点安全引用（令牌，抽取后的已确认事实与未确认项白名单字段）、影响面、状态频道、公关负责人与草拟 Agent。 2. **草拟公告**：获授权 Agent 起草对外公告并回传（公告草稿、引用的故障单要点、未确认项列表）；只陈述输入中列为已确认的事实，未确认的原因与恢复时间一律写"待确认"，不编造、不推断。回传结构不合要求时停在原等待点，等其重新提交，不自动重跑。 3. **人工双确认**：值班经理与公关负责人确认后，公告发布到状态频道并留审计时间戳；任一驳回则本次失败结束、不发公告，改输入后新开一次调用。 4. **输入要点不完整**：缺影响面或事实与未确认项混列时不重试——同一调用的不完整输入不会因重跑补齐；告警失败、留审计时间戳，通知调用方（值班经理）更正后新开一次调用。 5. **时间线不完整**：要点齐备但故障时间线缺关键节点时单独告警留审计，通知值班经理补全时间线后新开一次调用，不编造时间线；与状态页系统不可达（发布通路失败，按告警失败重试升级）是两类不同的失败。 你不需要手写代码或配置。把上面的提示词发给 Loop，AI 会理解意图、在后台画出这个"手动调用带入要点引用 + 草拟 + 双确认发布"流程——它知道"草拟公告"需要一个发消息并等待回调的 Agent 环节、"双确认"需要一个审批环节（可拆两步）、"发布"需要一个发消息环节、"要点不完整"需要一个直接失败的输入校验分支，并把它们连起来。AI 还会在后台校验流程结构是否完整，你不必关心这些技术细节。 - **输入要点不完整**：缺影响面或事实与未确认项混列，不重试（重跑补不齐缺失输入），告警失败并留审计时间戳，通知调用方（值班经理）更正后新开一次调用。 - **时间线不完整（与要点不完整、系统不可达分开）**：要点齐备但故障时间线缺关键节点时，单独告警留审计时间戳并通知值班经理补全后新开一次调用——不编造时间线，也不与"系统不可达"混为一谈；状态页不可达属于发布通路失败，按公告发布失败的重试上限与升级处理。 - **未确认信息被写进公告**：草拟规则限定只陈述已确认事实，未确认的原因与恢复时间一律"待确认"；双确认时值班经理与公关负责人各看一遍，仍是最后防线。 - **草拟 Agent 回传不合结构**：本次完成请求被拒绝，停在等待点等其修正后重新提交，不自动重跑，也不把残缺草稿送去审批。 - **公告发布失败**：按重试上限重试投递；超过上限则升级到值班频道，并保留待发公告供人工补发。 - **取消后的外部结果**：取消不召回已发消息或外部结果，也不自动补偿；保留 receipt，恢复时按“故障令牌 + 公告类型（期望变化）+ 平台分配的公告版本 + 发布目标”查询权威状态，由恢复 Owner 决定保留、另建补偿行动卡或升级。 - **任一角色驳回**：本次失败结束、不发公告并留审计；修改输入或口径后新开一次调用，没有"AI 自动改稿再发"。 - **长时间无人审批**：审批本身不设自动超时，流程停在等待状态。故障期间若久拖未决，由值班经理在值班频道口头催办，不走自动升级。 公告必须经值班经理与公关负责人双确认后才发布——对外声明风险高，宁可慢一分钟也不能单点拍板。确认时两位能看到公告草稿、引用的故障单要点与未确认项列表，逐条核对"待确认"没有被写成事实。审批只有确认或驳回两种结果，驳回即本次失败、不发公告，没有"AI 自动改稿再发"。若某类低风险维护公告想单人确认，在提示词里写明，AI 会把双审合并为一个审批环节。 状态频道的公告发布由获授权 Agent 通过 App/Extension 完成，工作流本身不直接调用外部系统、不直接发 HTTP 请求。进入 Agent 消息、Run/Activation/Effect 记录与 App/Extension 工具日志仅记录白名单/令牌化字段，原值不进入以上任何一层，并按 10% 抽查四层实际记录。访问凭据用 `` 占位，由 Agent 运行时从密钥引用。发布带幂等与查后写闭环：幂等键由调用时带入的故障令牌、作为期望变化的公告类型、平台分配的公告版本与发布目标组合派生（全部为可信输入，Agent 输出不参与组键），同键只发布一版公告，恢复公告类型为"恢复"、不与首次公告互相覆盖；响应未知（如超时）先查状态页是否已存在同幂等键的公告再决定补发或跳过，对方已接收则不再重写，配合有限重试→升级→待处理与审计。故障单要点与影响面不是从监控系统拉的，而是值班经理发起调用时以安全引用（令牌）带入的输入——原始故障单留在工单系统，本流程不依赖也不猜测监控数据。若将来想定时汇总状态页更新，另起一条 schedule 工作流，不与本流程混用。 取消只停止尚未调度的后续图；App/Extension 保留外部 receipt，并允许恢复 Owner 按“故障令牌 + 公告类型（期望变化）+ 平台分配的公告版本 + 发布目标”读取权威状态后决定保留、补偿或升级。 - **回放集与基准**：取最近 20 次真实故障的故障单要点与最终对外公告，人工基准答案为"应陈述事实/应标待确认"的逐条清单；草稿事实陈述与基准一致率 ≥ 95%。 - **不编造**：基准为未确认的项（原因、恢复时间）100% 写"待确认"，零编造；抽查已发布公告无未确认原因被当作事实。 - **双确认**：已发布公告 100% 留有值班经理与公关负责人两人的确认记录与审计时间戳；驳回 100% 未发公告。 - **发布幂等**：同一"故障令牌+公告类型（期望变化）+版本+发布目标"在状态页只存在一版公告（含响应未知经查后写补发的场景，键全部取自可信调用输入）；重放回放中无一例重复发布，首次公告与恢复公告互不覆盖。 - **输入校验**：要点不完整的调用 100% 失败告警并留审计、提示新开调用，零次进入草拟环节；时间线不完整 100% 走单独告警分支，零次编造时间线。 - **分母与口径**：一致率分母为回放条目总数；每次回放记录调用、草拟、确认与发布时间戳。 - **源头脱敏**：进入 Agent 消息、Run/Activation/Effect 记录与 App/Extension 工具日志的字段 100% 在白名单/令牌化范围内（仅故障单要点、影响面、公告草稿与未确认项，原值不进入以上任何一层），按 10% 抽查四层实际记录。 - **取消恢复**：在外部请求已发出后取消的回放中，已发结果 0 次被召回或自动补偿，receipt 保留率 100%；恢复 Owner 100% 按“故障令牌 + 公告类型（期望变化）+ 平台分配的公告版本 + 发布目标”查权威状态，并明确选择保留、另建补偿行动卡或升级。 - **时效**：从调用到公告发布（确认后）的中位数 < 20 分钟。 ### 复用与变体 - **同构迁移**：数据事件对外通报草拟、维护窗口公告、安全漏洞披露草拟、价格变更客户通知。 - **进展更新版**：故障恢复后新开一次调用带入"已恢复"要点并把公告类型改为"恢复"（新分配版本号），复用同一流程发布恢复公告，不与首次公告互相覆盖。 - **单人确认版**：低风险维护公告改为仅值班经理单确认，在提示词里写明。