## 周度考勤异常汇总确认 {.case data-case-id="034"}

| 字段 | 值 |
| --- | --- |
| 案例编号 | `034` |
| 行业 / 部门 | 制造 / 人力 |
| 角色 | HR 专员 |
| 难度 | `进阶` |
| 调用来源 | `schedule`（定时由获授权 Agent 经 App/Extension 读取考勤系统） |

<!-- slot: 目标 -->
周一早上 HR 从考勤机后台手工导出上千条缺卡、迟到、加班未审批记录，逐条对补卡单与审批流，既慢又漏。目标：每周定时让获授权 Agent 读取本周考勤异常记录，逐条核对是否已有对应的补卡或审批记录，自动归档已处理的，把未处理的整理成清单交 HR 确认后通知员工本人与直属经理；记录冲突的一律标"待确认"由人裁决。员工个人信息最小披露：Agent 侧清单只带考勤记录令牌（或部门聚合口径）与异常类型，不带姓名与工号；收件人与称呼由考勤 App 在发送侧按令牌解析回填。指标：未处理异常从读取到员工收到通知的中位数 < 1 个工作日；冲突记录 0 例被自动判定。

<!-- slot: 边界 -->
- **覆盖**：定时读取考勤异常、逐条核对补卡与审批记录、未处理清单经 HR 确认后通知员工本人与直属经理、冲突记录单列由人裁决。
- **不覆盖**：自动审批补卡、自动修正考勤记录、自动扣减或折算薪酬、自动写回考勤系统。
- **假设**：有一个经授权能读取考勤系统异常记录及补卡、审批记录的 Agent（通过 App/Extension），读取侧完成令牌化；直属经理以经理角色代号表示，缺失标"待确认"，收件人由考勤 App 发送时按令牌解析。

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

```text
帮我创建一个 Workflow：每周定时（每周一早上）由获授权的核对 Agent 经 App/Extension 读取考勤系统本周的考勤异常记录（缺卡、迟到、加班未审批），App/Extension 在读取侧即完成令牌化与聚合——Agent 只接收考勤记录令牌、部门、日期、异常类型、核对结论、经理角色代号等白名单字段，不接收姓名、工号、薪酬、联系方式等任何可回溯到个人的原始字段，并逐条核对是否已有对应的补卡或审批记录，返回每条的考勤记录令牌、异常类型、核对结论。员工个人信息最小披露：清单与通知不带姓名与工号，只带考勤记录令牌或部门聚合口径；通知员工本人与直属经理时，由考勤 App 按令牌解析收件人并回填称呼。
触发：定时（计划）发起调用，调用时带入 HR 频道、核对 Agent 和审批人（HR 专员）。
结果分三类处理（先判冲突，再判是否已处理）：
  已处理（异常已有匹配的补卡或审批记录）：自动汇总归档，发汇总回执并留审计时间戳，不打扰任何人。
  未处理（异常没有对应补卡或审批记录）：生成待处理清单（考勤记录令牌+异常类型）交 HR 专员确认，确认后通知员工本人与直属经理——收件人由考勤 App 按令牌解析，经理角色代号缺失标"待确认"，不从姓名猜，并留审计时间戳。
  记录冲突（如同一时段既有缺卡又有补卡待审批）：标"待确认"单列一份冲突清单交 HR 专员裁决，不自动判定哪条有效，也不并入已处理或未处理，并留审计时间戳。
  另：本期无异常（查询成功但异常记录为空）：发一条"本期无异常"汇总回执并留时间戳，不静默结束，也不当作取数失败。
审批：未处理清单必须经 HR 专员确认后才通知员工本人与直属经理，审批不设自动超时，无默认通过/否决；驳回则清单退回不通知；已处理与冲突单列路径不经审批。
取数失败（考勤系统不可达或数据陈旧）：告警失败、留审计时间戳，按重试上限重试，仍失败则升级到值班频道；与"本期无异常"分开处理，不互相顶替。
异常：核对 Agent 回传不合结构就停在等待点等它重新提交，不自动重跑；通知发送失败按重试上限重试，仍失败则升级到值班频道并保留待发内容供人工补发；归档失败按重试上限重试，仍失败则升级到值班频道并保留待归档内容供人工补归档。
完成：归档、通知、冲突单列、零结果回执各自留审计时间戳后结束。
```

<!-- slot: 流程 -->
![案例 034 周度考勤异常汇总确认：定时让获授权 Agent 读取考勤系统并逐条核对补卡与审批记录（Agent 只带考勤记录令牌或部门聚合口径与异常类型，收件人由考勤 App 按令牌解析）；考勤系统不可达按取数失败告警留审计重试升级，本期无异常发零结果回执，已处理自动汇总归档，未处理生成清单经 HR 确认后通知员工本人与直属经理（经理缺失标待确认，驳回则退回不通知），记录冲突标待确认单列由人裁决不自动判定，均留审计时间戳；回传不合结构停在原等待点](../../../media/cases/fig-case-034-01-flow.svg){#fig-case-034-01 width=92%}

如上图所示，正常路径、人工决策与异常同时可见：

1. **定时触发**：计划到点（每周一早上）发起一次调用，带入 HR 频道、核对 Agent 与审批人（HR 专员）。
2. **核对异常记录**：获授权 Agent 经 App/Extension 读取本周考勤异常记录，逐条核对是否已有补卡或审批记录并回传核对结论；回传结构不合要求时停在原等待点，等其重新提交，不自动重跑。
3. **分流（先判冲突，再判是否已处理）**：
   - **已处理**：自动汇总归档，发汇总回执并留审计时间戳，不打扰任何人。
   - **未处理**：生成待处理清单（考勤记录令牌+异常类型）交 HR 专员确认；确认后通知员工本人与直属经理（收件人由考勤 App 按令牌解析，经理代号缺失标"待确认"）并留审计时间戳；驳回则清单退回，不通知。
   - **记录冲突**：如同一时段既有缺卡又有补卡待审批，标"待确认"单列冲突清单交 HR 专员裁决，不自动判定，不并入已处理或未处理。
   - **本期无异常**：查询成功但记录为空，发一条零结果汇总回执并留时间戳，不静默结束，也不当作取数失败。

<!-- slot: 配置 -->
你不需要手写代码或配置。把上面的提示词发给 Loop，AI 会理解意图、在后台画出这个"定时核对 + 人工确认 + 多路分流"流程——它知道"核对异常"需要一个发消息并等待回调的 Agent 环节、"先判冲突再判处理状态"需要一个条件路由、"HR 确认"需要一个审批环节、"归档与通知"各需要一个发消息环节。AI 还会在后台校验流程结构是否完整，你不必关心这些技术细节。

<!-- slot: 异常 -->
- **记录冲突被自动判定**：这是最危险的漏判——同一时段既有缺卡又有补卡待审批时，无论判哪边都可能出错。靠红线兜底：冲突一律标"待确认"单列交 HR 专员裁决，流程不自动判定哪条有效。
- **考勤系统不可达或数据陈旧**：不当作"本期无异常"或静默结束，而是告警失败、留审计时间戳，按重试上限重试；仍失败则升级到值班频道由人工确认。
- **直属经理缺失**：Agent 不从员工姓名或历史记录猜经理，通知中该字段标"待确认"，由 HR 专员确认时补全或指定；Agent 侧只见经理角色代号，收件人由考勤 App 发送时解析。
- **HR 专员驳回清单**：清单退回，不通知员工本人与经理；要重新处理就再发起一次调用，没有"AI 自动改判"。
- **通知发送失败**：按重试上限重试投递；超过上限则升级到值班频道，并保留待发内容供人工补发。
- **归档失败**：按重试上限重试；超过上限则升级到值班频道，并保留待归档内容供人工补归档，不当作已归档，也不静默丢弃。
- **本期无异常（结果为 0）**：仍发一条零结果汇总回执并留时间戳，让"没消息"变成可核验的记录。
- **核对 Agent 回传不合结构**：本次完成请求被拒绝，停在等待点等其修正后重新提交，不自动重跑。
- **长时间无人审批**：审批本身不设自动超时，流程停在等待状态。若业务需要响应时限，由另一条定时检查的 Workflow（或值班人员）扫出超时项并通知 HR 专员。

<!-- slot: 审批 -->
未处理清单必须经 HR 专员确认后才通知员工本人与直属经理，已处理与冲突单列路径不经审批。确认时 HR 专员看到的是按考勤记录令牌与异常类型汇总的清单（个人信息最小披露），所以是"有依据的快速决策"而非盲目拍板。审批只有确认或驳回两种结果，驳回即清单退回不通知，没有"AI 自动改判"；审批本身不设自动超时。若要更严（如涉及加班未审批的必须经理加签），在提示词里写明，AI 会在流程里多加一个审批环节。

<!-- slot: 外部系统 -->
本工作流对考勤系统异常记录及补卡、审批记录的读取由获授权 Agent 通过 App/Extension 完成，工作流本身不直接调用外部系统。HR 频道作为调用输入提供；考勤系统的访问凭据用 `<token>` 占位，由 Agent 运行时从密钥引用。考勤系统不可达或数据陈旧属于取数失败，走失败回执与升级，不当作"本期无异常"。清单与通知遵循员工个人信息最小披露：Agent 侧不带姓名与工号，只带考勤记录令牌（或部门聚合口径）与异常类型，收件人与称呼由考勤 App 发送时按令牌解析回填；薪酬折算等敏感处理由 HR 线下完成，不进入本流程。进入 Agent 消息、Run/Activation/Effect 记录与 App/Extension 工具日志的字段以白名单为准（仅令牌化/白名单字段，原值不进入以上任何一层），敏感原始字段在源头即被聚合/区间化/令牌化，并按 10% 抽查四层实际记录。

<!-- slot: 验收 -->
- **回放集与基准**：取最近 8 周 300 条历史异常记录（含已处理、未处理、同时段冲突样本）回放，人工基准答案为逐条核对结论；核对结论与基准一致率 ≥ 95%。
- **冲突防线**：基准为冲突的记录 100% 标"待确认"单列，自动判定为已处理或未处理的 0 例。
- **分母与口径**：一致率分母为回放总条数；冲突样本单独计数，不并入一致率统计；每次运行记录核对、通知时间戳。
- **指标**：未处理异常从读取到员工收到通知的中位数 < 1 个工作日；直属经理缺失时 100% 标"待确认"，不出现猜测的经理。
- **最小披露**：每周抽查 10 条通知，核对 Agent 消息与运行记录仅含考勤记录令牌（或部门聚合口径）与异常类型，姓名、工号等可回溯字段不外带；接收人称呼由考勤 App 发送侧回填。
- **源头脱敏**：进入 Agent 消息、Run/Activation/Effect 记录与 App/Extension 工具日志的字段 100% 在白名单内（仅令牌化/白名单字段，原值不进入以上任何一层），并按 10% 抽查四层实际记录。
- **结果可见**：归档、通知、冲突单列、本期无异常、取数失败五类结果 100% 各有可见回执，不出现静默成功。

### 复用与变体
- **同构迁移**：门店排班缺口周报、产线工时异常汇总、加班时长阈值预警。
- **分级路由**：单人 5 条以上异常的经理单独提醒，其余汇总成一条周报发到人力群。
- **写回考勤系统**：HR 确认后再加一个 Agent 环节，由它通过 App/Extension 把"已通知"状态写回考勤记录；写回须是获授权 Agent 经 App/Extension 的幂等动作（幂等键=考勤记录令牌+通知事项），响应未知先查后写、按重试上限有限重试、失败升级值班并置"待处理"保留补偿，全程留审计。若不需要写侧能力，改为只读汇总或仅留 Loop 回执更安全。

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