## 管理例会行动项跟踪 {.case data-case-id="077"}

| 字段 | 值 |
| --- | --- |
| 案例编号 | `077` |
| 行业 / 部门 | 制造 / 管理 |
| 角色 | 总裁办 |
| 难度 | `入门` |
| 调用来源 | `manual`（每次例会后由秘书发起一次手动调用，带入会议纪要行动项清单） |

<!-- slot: 目标 -->
管理例会决议一板一板地记，下一场会才发现上一场的行动项大半没人认领、逾期没人追。目标：每次例会后由秘书发起一次手动调用，让获授权 Agent 对带入的纪要行动项清单逐项跟踪——调用输入严格是四个业务字段（行动项编号、Owner 角色代号、当前状态、截止区间）加两个平台签发元数据（`status_version`、`as_of_at`）；两个元数据跨 Run 重放时原样复用，Agent 不生成。行动项内容原文始终留在会议系统，不进入 Agent 消息、回执与运行记录；有逾期通知 Owner 与其经理，无逾期发进度回执，清单不完整告警新开调用。

<!-- slot: 边界 -->
- **覆盖**：手动调用逐项跟踪四个业务字段（编号/Owner 角色代号/状态/截止区间）及平台签发的 `status_version` / `as_of_at`、三路分流、全部关闭发完成回执、内容原文全程不进入工作流。
- **不覆盖**：自动判定行动项完成、自动改行动项或截止日、代替 Owner 执行行动、对会议决议本身重新下结论、把行动项内容原文带入工作流。
- **假设**：有一个经授权能读取行动项状态与截止时间的 Agent（通过 App/Extension）；清单输入含四个业务字段，平台另签发 `status_version` 与 `as_of_at`，原请求跨 Run 重放时两者保持不变且 Agent 只能原样回传；行动项内容与敏感议题原文仅保存在会议系统；通知接收人由平台侧按 Owner 角色代号解析。

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

```text
帮我创建一个 Workflow：管理例会结束后由秘书发起一次手动调用，让获授权的跟踪 Agent 经 App/Extension 读取行动项状态，对带入的纪要行动项清单逐项跟踪。调用输入白名单固定为“四个业务字段 + 两个签发元数据”：行动项编号、Owner 角色代号、当前状态、截止区间 + 平台签发的 `status_version`、`as_of_at`；原请求跨 Run 重放仍复用同一对签发值，Agent 不生成或按执行时间重算。行动项内容原文与敏感议题表述始终留在会议系统。回传 JSON：{status_version: 平台签发令牌（取自调用输入并原样回传）, as_of_at: 平台签发基准时刻（取自调用输入并原样回传）, items: [{item_ref: 行动项编号, owner_role: 角色代号, status: 枚举(未开始|进行中|已关闭), due_window: 截止区间}], checklist_complete: 布尔, fields_missing: [枚举(行动项状态数据源|Owner 角色代号|截止区间)], source_ok: 布尔, audit_ts: 时间戳}。状态矩阵：source_ok、checklist_complete、audit_ts 始终必填；source_ok=false 时 fields_missing 必为 [行动项状态数据源]，status_version、as_of_at、items 禁止出现且 checklist_complete 必为 false；source_ok=true 且 checklist_complete=false 时 fields_missing 必非空且只含 Owner 角色代号或截止区间，status_version、as_of_at 必填而 items 禁止出现；source_ok=true 且 checklist_complete=true 时 fields_missing 必为空，status_version、as_of_at、items 必填，items 每个元素严格只有 item_ref、owner_role、status、due_window 四个业务字段且逐项必填。成功态两个签发值必须与调用输入逐字相同；逾期由工作流按 `status!=已关闭 && as_of_at 已超过 due_window` 计算，不接受 Agent 另传 overdue 或 updated_at。仅接受这些组合，其余 callback 一律拒绝并保持原 Effect awaiting。逾期通知的接收人由平台侧按 Owner 角色代号解析。
触发：手动发起调用，带入四个业务字段（编号、Owner 角色代号、状态、截止区间）+ 平台签发的 `status_version` / `as_of_at`，以及总裁办频道、跟踪 Agent和值班频道；同一业务请求跨 Run 重放复用两个签发值。
结果分三类处理：
  有逾期：逐项通知 Owner 与其经理（接收人由平台侧按 Owner 角色代号解析，解析不到标"待确认"），通知只附编号、截止区间与当前状态，留审计时间戳。
  无逾期：发进度回执，每项只附编号、Owner 角色代号、截止区间与当前状态，留审计时间戳。
  行动项清单不完整（缺 Owner 角色代号或截止区间）：告警并留审计时间戳，通知调用方补全后新开一次调用，本次不重试、不猜测缺失字段。
另设两类边界结果：
  本期无行动项（查询成功但带入清单为空）：发一条"本期无行动项"汇总回执并留时间戳，不静默结束。
  取数失败（行动项状态数据源不可达、数据陈旧）：告警失败、留审计时间戳，按重试上限重试，仍失败则升级到值班频道（作为调用输入提供）；不当作"本期无行动项"，也不当作无逾期。
清单全部行动项均关闭后，发一条完成回执（含关闭项数与最后关闭时间戳）并留审计时间戳。
审批：不涉及审批，例会行动项跟踪是低风险信息，直接触达。
异常：跟踪 Agent 回传不合结构就停在等待点等它重新提交，不自动重跑；通知发送失败按重试上限重试，仍失败则升级到值班频道并保留待发内容供人工补发。
完成：逾期通知、进度回执、清单不完整告警、零结果回执、取数失败升级、全部关闭回执，各自留审计时间戳后结束。
```

<!-- slot: 流程 -->
![案例 077 管理例会行动项跟踪：调用输入统一为四个业务字段（编号、Owner 角色代号、状态、截止区间）加平台签发的 status_version 与 as_of_at，跨 Run 原样复用且 Agent 不生成；内容原文留在会议系统。有逾期通知 Owner 与经理，无逾期发进度回执，清单不完整告警新开调用，本期无行动项发零结果，数据源失败重试升级，全部关闭发完成回执；签发值漂移或回传不合结构停在原等待点](../../../media/cases/fig-case-077-01-flow.svg){#fig-case-077-01 width=92%}

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

1. **手动触发**：例会结束后由秘书发起一次调用，带入四个业务字段 + 平台签发的 `status_version` / `as_of_at`，以及总裁办频道与跟踪 Agent；内容原文留在会议系统，跨 Run 重放仍复用签发值。
2. **跟踪行动项**：获授权 Agent 经 App/Extension 读取状态，逐项只回传四个业务字段并原样回传两个签发值；`overdue` 由工作流按签发的 `as_of_at` 与 `due_window` 计算，Agent 不另传。签发值漂移、额外字段、缺字段或状态矩阵矛盾就停在原等待点。
3. **三路分流**：
   - **有逾期**：逐项通知 Owner 与其经理（接收人由平台侧按 Owner 角色代号解析，解析不到标"待确认"），通知只附编号、截止区间与当前状态，留审计时间戳。
   - **无逾期**：发进度回执，每项只附编号、Owner 角色代号、截止区间与状态，留审计时间戳。
   - **清单不完整**（缺 Owner 角色代号或截止区间）：告警、留审计时间戳，通知调用方补全后新开一次调用，本次不重试。
4. **两类边界与收尾**：本期无行动项发零结果回执留时间戳；状态数据源不可达按取数失败告警留审计，按重试上限重试，仍失败升级值班频道；全部关闭后发完成回执留审计时间戳。

<!-- slot: 配置 -->
你不需要手写代码或配置。把上面的提示词发给 Loop，AI 会理解意图、在后台画出这个"手动调用 + 多路分流 + 全关回执"流程——它知道"跟踪行动项"需要一个发消息并等待回调的 Agent 环节、"按逾期与清单完整性分流"需要一个条件路由、"通知与回执"各需要一个发消息环节。AI 还会在后台校验流程结构是否完整，你不必关心这些技术细节。

<!-- slot: 异常 -->
- **行动项状态数据源不可达、陈旧**：不当作"本期无行动项"或无逾期，而是告警失败、留审计时间戳，按重试上限重试；仍失败则升级到值班频道由人工确认。
- **Owner 角色代号缺失或解析不到接收人**：Agent 不从组织架构或历史记录猜负责人，该字段标"待确认"，由总裁办在下次例会或会下补全；接收人解析一律在平台侧完成。
- **清单不完整（缺 Owner 角色代号或截止区间）**：不猜缺失字段，告警留审计并通知调用方补全后新开一次调用，本次不重试。
- **通知发送失败**：按重试上限重试投递；超过上限则升级到值班频道，并保留待发内容供人工补发。
- **本期无行动项（结果为 0）**：仍发一条零结果汇总回执并留时间戳，让"没消息"变成可核验的记录，而不是无声结束。
- **签发元数据漂移**：`status_version` 与 `as_of_at` 必须逐字等于调用输入；跨 Run 重放复用原值，Agent 自造版本或按新执行时间重算基准时刻时拒绝 callback，原 Effect 保持 awaiting。
- **跟踪 Agent 回传不合结构**：本次完成请求被拒绝，停在等待点等其修正后重新提交，不自动重跑。

<!-- slot: 审批 -->
本案例不涉及审批。例会行动项跟踪是低风险信息，应第一时间触达 Owner 与经理；因此不设审批环节，各类结果直接出回执。全部关闭的完成回执也只做通知，不改变任何人的待办。若后续要把"申报完成"升级为人工确认制（如涉密行动项），在提示词里写明，AI 会在流程里加一个审批环节。

<!-- slot: 外部系统 -->
本工作流对行动项状态的读取由获授权 Agent 通过 App/Extension 完成，工作流本身不直接调用外部系统。调用输入只有四个业务字段 + 平台签发的 `status_version` / `as_of_at`；两个签发值跨 Run 原样复用，Agent 不生成。行动项内容与敏感议题原文只保存在会议系统，任何回执与通知不外带；逾期通知接收人由平台侧按 Owner 角色代号解析。总裁办频道与值班频道作为调用输入提供；数据源凭据用 `<token>` 占位。数据源不可达或陈旧走失败回执与升级，不当作"本期无行动项"。

<!-- slot: 验收 -->
- **回放集与基准**：取最近 6 次例会的 60 条行动项（含无逾期、有逾期、已关闭、缺 Owner 角色代号、缺截止区间样本）回放，基准为既定状态分类与应通知清单。
- **分类准确**：逾期与无逾期判定和基准一致率 ≥ 95%；逾期项 100% 在当日通知到 Owner 与经理（接收人由平台侧解析）。
- **字段纪律**：调用输入 100% 仅含四个业务字段 + `status_version` / `as_of_at`；两个签发值在同一请求跨 Run 重放时 100% 原样复用，Agent 自造或重算 0 例。Owner 角色代号原样带出，解析不到接收人标"待确认"；清单不完整时告警新开调用。
- **源头脱敏**：进入 Agent 消息、Run/Activation/Effect 记录与 App/Extension 工具日志的业务字段 100% 仅为编号、Owner 角色代号、状态、截止区间，另含平台签发的 `status_version` / `as_of_at`；Agent 回传 `overdue`、`updated_at` 或内容原文的 0 例，并按 10% 抽查四层实际记录。
- **结果可见**：六类结果 100% 各有可见回执留审计，不出现静默成功；全部关闭后 100% 发完成回执（含关闭项数与最后关闭时间戳）；每项跟踪 100% 留时间戳。

### 复用与变体
- **同构迁移**：经营分析会行动项跟踪、质量例会整改跟踪、跨部门专项任务跟踪。
- **分级提醒**：逾期 3 天内的只通知 Owner，超过 3 天再通知经理，在提示词里写明即可。
- **写回纪要**：在通知后再加一个 Agent 环节，由它通过 App/Extension 把最新状态写回会议纪要台账；写回须是获授权 Agent 经 App/Extension 的幂等动作（业务键=行动项编号+调用输入中的平台签发 status_version+期望状态+目标台账），Agent 只能原样回传版本令牌；响应未知先查后写、按重试上限有限重试、失败升级值班并置"待处理"保留补偿，全程留审计，且仍只写状态字段、不外带内容原文。

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