## 客服工单高峰排队告警 {.case data-case-id="025"}

| 字段 | 值 |
| --- | --- |
| 案例编号 | `025` |
| 行业 / 部门 | 互联网 / 客服 |
| 角色 | 客服主管 |
| 难度 | `入门` |
| 调用来源 | `schedule`（定时由获授权 Agent 经 App/Extension 读取工单系统队列统计） |

<!-- slot: 目标 -->
大促或突发故障时工单瞬间涌进来，等客服主管自己刷后台看到排队爆了，客户已经等得不耐烦。目标：定时让获授权 Agent 经 App/Extension 读取工单系统的当前排队量与最长等待时长，按"取数失败、未超阈值、超阈值"三种结果分别给出可见回执，超过阈值时立刻告警并通知客服主管与值班组长、留审计时间戳。指标：高峰从形成到被告知的中位数 < 5 分钟；告警内容与工单系统实时数值一致率 100%；取数失败零静默。

<!-- slot: 边界 -->
- **覆盖**：定时读取排队量与等待时长、与阈值比较后按三种结果出回执、超阈值时告警并通知客服主管与值班组长、留审计时间戳。
- **不覆盖**：自动扩容客服人力、自动分派或改派工单、自动回复客户、预测未来的工单量。
- **假设**：有一个经授权能读取工单系统队列统计的 Agent（通过 App/Extension）；阈值（排队量上限、等待时长上限）在每次调用时作为输入提供，不由工作流自己定。

<!-- slot: 提示词 -->
把下面这段发给 Loop，它会在后台帮你创建这个 Workflow：

```text
帮我创建一个 Workflow：定时由获授权的统计 Agent 经 App/Extension 读取工单系统的当前排队量与最长等待时长，与阈值比较后决定是否告警。
触发：定时（计划）发起调用，调用时带入客服主管、值班组长、统计 Agent 与阈值（排队量上限、等待时长上限）。
结果分三类处理：
  超过阈值：立即告警并通知客服主管与值班组长，附当前排队量、最长等待时长与超出幅度，并留审计时间戳。
  未超阈值：发一条"当前无高峰"汇总回执并留时间戳，不要静默结束——这条回执写明本轮读到的排队量与等待时长，让"没告警"可以被核验。
  取数失败（工单系统不可达或队列统计数据陈旧）：告警失败、留审计时间戳，按重试上限重试，仍失败则升级到值班频道——绝不把取不到数据当作"无高峰"。
审批：不涉及审批，高峰告警是时效优先的低风险通知，直接触达。
异常：统计 Agent 回传不合结构就停在等待点等它重新提交，不自动重跑；通知发送失败按重试上限重试，仍失败则升级到值班频道并保留待发内容供人工补发。
完成：三类结果各自出回执后结束。
```

<!-- slot: 流程 -->
![案例 025 客服工单高峰排队告警：定时让获授权 Agent 读取工单系统排队量与等待时长；取数失败留审计并重试升级且绝不当作无高峰，未超阈值发当前无高峰回执留时间戳，超阈值告警并通知客服主管与值班组长留审计时间戳](../../../media/cases/fig-case-025-01-flow.svg){#fig-case-025-01 width=92%}

如上图所示，正常路径与异常同时可见，三种结果都有可见回执：

1. **定时触发**：计划到点发起一次调用，带入客服主管、值班组长、统计 Agent 与阈值（排队量上限、等待时长上限）。
2. **读取队列统计**：获授权 Agent 经 App/Extension 读取工单系统当前的排队量与最长等待时长并回传；回传结构不合要求时停在原等待点，等其重新提交，不自动重跑。
3. **三种结果分流**：
   - **取数失败**：工单系统不可达或队列统计数据陈旧，告警失败并留审计时间戳，按重试上限重试，仍失败则升级到值班频道——绝不当作"无高峰"。
   - **未超阈值**：发一条"当前无高峰"汇总回执并留时间戳，写明本轮读到的排队量与等待时长，不静默结束。
   - **超阈值**：立即告警并通知客服主管与值班组长，附排队量、最长等待时长与超出幅度，并留审计时间戳。

<!-- slot: 配置 -->
你不需要手写代码或配置。把上面的提示词发给 Loop，AI 会理解意图、在后台画出这个"定时读取 + 三路分流"流程——它知道"读队列统计"需要一个发消息并等待回调的 Agent 环节、"分三种结果"需要一个条件路由、"告警与回执"各需要一个发消息环节。阈值不用写死在流程里，每次调用时作为输入传入即可。AI 还会在后台校验流程结构是否完整，你不必关心这些技术细节。

<!-- slot: 异常 -->
- **工单系统不可达或数据陈旧**：不落入"未超阈值"或静默结束，而是告警失败、留审计时间戳，按重试上限重试；仍失败则升级到值班频道由人工确认——"读不到数"和"没有高峰"是两回事。
- **告警或通知发送失败**：按重试上限重试投递；超过上限则升级，并保留待发内容供人工补发。
- **未超阈值（结果为 0 告警）**：仍发一条"当前无高峰"汇总回执并留时间戳，写明本轮读到的数值，让"没消息"变成可核验的记录，而不是无声结束。
- **统计 Agent 回传不合结构**：本次完成请求被拒绝，停在等待点等其修正后重新提交，不自动重跑，也不会基于残缺数据判断"无高峰"。
- **阈值波动频繁**：大促前后阈值往往要调。阈值是调用输入而不是流程常量，改阈值不用重建工作流，下一次调用带入新值即可。

<!-- slot: 审批 -->
本案例不涉及审批。高峰告警是时效优先、低风险的内部通知，从读数到触达每多一分钟就多一批客户多等一分钟；因此不设 `request_approval` 环节，三种结果直接出回执。要不要调人力、开应急通道，是主管收到告警之后的人工决策，本流程不替他做。

<!-- slot: 外部系统 -->
本工作流的队列统计读取由获授权 Agent 通过 App/Extension 完成，工作流本身不直接调用外部系统，也不直接向工单系统发请求。进入 Agent 消息、Run/Activation/Effect 记录与 App/Extension 工具日志仅记录白名单/令牌化字段，原值不进入以上任何一层，并按 10% 抽查四层实际记录。工单系统的访问凭据用 `<token>` 占位，由 Agent 运行时从密钥引用。告警里只含排队量、等待时长等聚合统计，不含客户姓名、联系方式等个人信息，无须额外脱敏即可发到内部频道。工单系统不可达或统计数据陈旧属于取数失败，走上面的失败回执与升级，不当作"无高峰"。

<!-- slot: 验收 -->
- **回放集与基准**：取最近 8 周队列统计（含已知高峰、平稳期与系统抖动时段），人工基准答案为按阈值划分的应告警时段清单；回放并记录读取、告警时间戳。
- **分母与口径**：告警准确率分母为回放时段总数；取数失败时段单独计数，不计入"未超阈值"。
- **指标**：高峰从形成（首次超阈值）到被告知的中位数 < 5 分钟；告警中的排队量与等待时长和工单系统实时数值一致率 100%；取数失败 100% 出回执并升级，零静默。
- **抽样**：每周抽查 3 条"当前无高峰"回执，核对回执里的数值与同一时刻工单系统数值一致。
- **源头脱敏**：进入 Agent 消息、Run/Activation/Effect 记录与 App/Extension 工具日志的字段 100% 在白名单内（仅令牌化/白名单字段，原值不进入以上任何一层），并按 10% 抽查四层实际记录。

### 复用与变体
- **同构迁移**：在线客服会话排队告警、配送站运力积压告警、审核队列积压告警。
- **分级路由**：排队量超阈值 2 倍以上时额外抄送客服负责人，普通高峰只通知主管与值班组长。
- **加密频次**：平稳期改为每 30 分钟一次，大促日通过更密的计划调用提高检查频率。

<!-- slot: 媒体槽位 -->
<!-- media: fig-case-025-01-flow.svg -->