## 内容发布日历到期提醒 {.case data-case-id="021"}

| 字段 | 值 |
| --- | --- |
| 案例编号 | `021` |
| 行业 / 部门 | 互联网 / 市场 |
| 角色 | 市场负责人 |
| 难度 | `入门` |
| 调用来源 | `schedule`（定时由获授权 Agent 经 App/Extension 读取共享内容日历） |

<!-- slot: 目标 -->
内容排期写在共享日历里，到期没人盯就悄悄溜走，公众号断更、物料跳票。目标：定时让获授权 Agent 读取共享内容日历，找出未来 3 天内到期的内容任务，按四类结果分别给出可见回执，命中时通知对应负责人。指标：有截止日期的内容任务 100% 在到期前 3 天被通知到；缺截止日期的条目 100% 单列为"待确认"，不混入"无到期"、也不被猜成"已到期"。

<!-- slot: 边界 -->
- **覆盖**：定时读取共享内容日历、按四类结果出回执、有到期时通知对应负责人并留审计时间戳。
- **不覆盖**：自动改排期、自动创建或编辑内容、自动催稿追踪完成度。
- **假设**：有一个经授权能读取共享内容日历的 Agent（通过 App/Extension）；条目含标题、截止日期、负责人；缺失字段会被如实标为"待确认"。

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

```text
帮我创建一个 Workflow：每日定时由获授权的日历 Agent 经 App/Extension 读取共享内容日历，找出未来 3 天内到期的内容任务（含标题、截止日期、负责人）。
触发：定时（计划）发起调用，调用时带入团队频道、日历 Agent 和提醒窗口（默认 3 天）。
结果分四类处理（缺截止日期的条目单列，不混入"无到期"）：
  有到期任务：通知对应负责人，附标题、截止日期与剩余天数，并留审计时间戳；负责人只用日历记录携带的负责人受控令牌，缺失就标"待确认"，不要从标题或渠道反查或猜测负责人。
  本期无到期：所有条目都有有效截止日期且都不在提醒窗口内，发一条"本期无到期任务"汇总回执并留时间戳，不要静默结束——此回执只含真正不在窗口内的条目，不含缺截止日期的。
  缺截止日期·待确认：截止日期缺失的条目无法判定是否到期（既不是"无到期"也不是"已到期"），单独发一条"缺截止日期·待确认"清单并留时间戳，由人补全日期后下一轮再判定。
  取数失败（日历不可达或数据陈旧）：告警失败、留审计时间戳，按重试上限重试，仍失败则升级到值班频道。
审批：不涉及审批，日历提醒是低风险信息，直接触达。
异常：日历 Agent 回传不合结构就停在等待点等它重新提交，不自动重跑；通知发送失败按重试上限重试，仍失败则升级到值班频道并保留待发内容供人工补发；缺截止日期的条目不要猜成"未到期"或"已到期"，一律单列为"缺截止日期·待确认"，不并入"本期无到期"。
完成：四类结果各自出回执后结束。
```

<!-- slot: 流程 -->
![案例 021 内容发布日历到期提醒：定时让获授权 Agent 读取共享内容日历；取数失败留审计并重试升级，本期无到期发汇总回执，缺截止日期单独发待确认清单，有到期任务通知负责人并留审计时间戳，负责人缺失标待确认](../../../media/cases/fig-case-021-01-flow.svg){#fig-case-021-01 width=92%}

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

1. **定时触发**：计划到点（每日）发起一次调用，带入团队频道、日历 Agent 与提醒窗口（默认 3 天）。
2. **查询内容日历**：获授权 Agent 经 App/Extension 读取共享内容日历中未来 3 天到期的内容任务并回传；回传结构不合要求时停在原等待点，等其重新提交，不自动重跑。
3. **四类结果分流（缺截止日期单列）**：
   - **有到期任务**：通知对应负责人，附标题、截止日期与剩余天数，并留审计时间戳；负责人仅使用日历记录携带的负责人受控令牌，缺失则标"待确认"，不猜测。
   - **本期无到期**：所有条目都有有效截止日期且不在窗口内，发一条汇总回执并留时间戳，不静默结束（不含缺截止日期的条目）。
   - **缺截止日期·待确认**：截止日期缺失、无法判定的条目单独成清单并留时间戳，由人补全日期后下一轮再判定，既不并入"无到期"也不猜成"已到期"。
   - **取数失败**：日历不可达或数据陈旧，告警失败并留审计时间戳，按重试上限重试，仍失败则升级到值班频道。

<!-- slot: 配置 -->
你不需要手写代码或配置。把上面的提示词发给 Loop，AI 会理解意图、在后台画出这个"定时查询 + 四路分流"流程——它知道"查内容日历"需要一个发消息并等待回调的 Agent 环节、"分四类结果"需要一个条件路由、"通知与回执"各需要一个发消息环节，并把它们连起来。AI 还会在后台校验流程结构是否完整，你不必关心这些技术细节。

<!-- slot: 异常 -->
- **日历不可达或数据陈旧**：不当作"本期无到期"或静默结束，而是告警失败、留审计时间戳，按重试上限重试；仍失败则升级到值班频道由人工确认。
- **通知发送失败**：按重试上限重试投递；超过上限则升级，并保留待发内容供人工补发。
- **本期无到期（结果为 0）**：仍发一条汇总回执并留时间戳，让"没消息"变成可核验的记录；此回执只含真正不在窗口内的条目，不含缺截止日期的。
- **缺截止日期·待确认（不猜不混）**：截止日期缺失的条目无法判定是否到期，单独成"缺截止日期·待确认"清单，由人补全日期后下一轮再判定。
- **负责人字段缺失或已失效**：Agent 不从标题或渠道猜负责人，直接标"待确认"，随通知一并发出，由人补全令牌后下一轮再处理。
- **日历 Agent 回传不合结构**：本次完成请求被拒绝，停在等待点等其修正后重新提交，不自动重跑。

<!-- slot: 审批 -->
本案例不涉及审批。日历到期提醒是低风险、可撤回的通知，应第一时间触达负责人；因此不设 `request_approval` 环节，四类结果直接出回执。

<!-- slot: 外部系统 -->
本工作流对共享内容日历的读取由获授权 Agent 通过 App/Extension 完成，工作流本身不直接调用外部系统。进入 Agent 消息、Run/Activation/Effect 记录与 App/Extension 工具日志仅记录白名单/令牌化字段，原值不进入以上任何一层，并按 10% 抽查四层实际记录。团队频道作为调用输入提供；日历的访问凭据用 `<token>` 占位，由 Agent 运行时从密钥引用。日历不可达或条目数据陈旧属于取数失败，走上面的失败回执与升级，不当作"本期无到期"。

<!-- slot: 验收 -->
- **回放集与基准**：取最近 50 条内容日历条目（含到期、未到期、缺截止日期三类）回放，人工基准答案为按截止日期排序的应通知清单；到期判定一致率 ≥ 90%，缺截止日期的条目 100% 归入"待确认"清单，误判为"未到期"或"已到期"的比例为 0。
- **负责人字段**：日历记录提供负责人受控令牌时 100% 原样带出；缺失时 100% 标"待确认"，不出现猜测的负责人。
- **结果可见**：四类结果 100% 各有可见回执，不出现静默成功；按 10% 抽样核对通知内容与日历条目一致。
- **分母与口径**：一致率分母为回放总数；每轮查询记录查询与通知时间戳，连续运行 4 周。
- **时效**：从本次查询启动到回执或通知发出的中位数 < 10 分钟；有截止日期的任务 100% 在到期前 3 天被通知到。
- **源头脱敏**：进入 Agent 消息、Run/Activation/Effect 记录与 App/Extension 工具日志的字段 100% 在白名单内（仅令牌化/白名单字段，原值不进入以上任何一层），并按 10% 抽查四层实际记录。

### 复用与变体
- **同构迁移**：营销活动物料截止提醒、社媒排期提醒、设计交付截止提醒。
- **按渠道路由**：不同内容渠道（公众号、视频号、官网）的到期任务分别通知各渠道子群，而不是统一发到一个频道。
- **写回日历**：在通知后再加一个 Agent 环节，由获授权 Agent 经 App/Extension 把"已提醒"标记写回可信的日历条目（仅提醒标记这一业务维度），以条目标识加提醒日期为稳定幂等键、响应未知先查后写，配有限重试、升级、待处理与审计。

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