## 新制度发布确认签署跟踪 {.case data-case-id="051"} | 字段 | 值 | | --- | --- | | 案例编号 | `051` | | 行业 / 部门 | 制造 / 合规 | | 角色 | 合规负责人 | | 难度 | `进阶` | | 调用来源 | `manual`（制度发布后由合规发起一次手动调用，带入制度文档与确认对象名单） | 新制度发布后"全员已知"只是合规的想象：没有签署记录，审计时拿不出证据。目标：制度发布后由合规负责人发起一次手动调用，带入制度文档与确认对象名单（经读取侧聚合与伪名化，只带白名单字段），逐人跟踪确认签署；全员签署发完成回执留证据，有未签署则汇总通知本人与直属经理，周期结束仍未清零则升级合规负责人。审计纪律是核心：每条签署记录留时间戳，制度内容本身不外带，通知只含签署状态与链接。指标：周期结束未签署清零率 100%；每条签署记录 100% 有可核验时间戳。 - **覆盖**：手动发起一次性签署跟踪、逐人核对签署状态、全员签署发完成回执留证据、有未签署通知本人与直属经理、周期结束未清零升级合规负责人、确认名单为空的零结果回执与签署系统不可达的取数失败回执分开处理。 - **不覆盖**：自动替人签署、自动催办日程安排、自动统计培训考试成绩、制度内容的解释或答疑。 - **假设**：确认对象名单（含签署记录令牌、部门、直属经理角色代号）在调用时作为输入提供，App/Extension 在读取侧完成聚合与伪名化，Agent 只接收白名单字段；名单信息缺失标"待确认"，不从组织架构或历史记录猜；签署动作发生在既有签署系统里，本工作流只跟踪不代办。 把下面这段发给 Loop，它会在后台帮你创建这个 Workflow： ```text 帮我创建一个 Workflow：制度发布后由合规负责人发起一次手动调用，带入制度文档与确认对象名单（含签署记录令牌、直属经理角色代号、签署链接），逐人跟踪确认签署并返回（签署记录令牌、部门、签署状态、签署时间）。源头脱敏：App/Extension 在读取侧即完成聚合与伪名化，Agent 只接收签署记录令牌、部门、签署状态等白名单字段，不接收姓名、工号等可回溯到个人的原始字段——个人与令牌的映射由平台侧保持，需要点名的通知由平台侧解析后发出；进入 Agent 消息与运行记录的字段以白名单为准。最小披露：通知与回执只含签署状态、时间戳与制度链接，制度内容本身不外带。 触发：手动发起一次调用，调用时带入制度文档与确认对象名单（令牌化）、团队频道、确认周期（如 10 个工作日）。 结果分流： 全员签署：发完成回执留审计，每条签署记录留时间戳（证据留痕），不静默结束。 有未签署：汇总未签署名单，逐人通知本人与直属经理（通知由平台侧按伪名化映射解析后发出），名单信息缺失标"待确认"；确认周期结束时仍未清零，升级到合规负责人并留审计时间戳。 确认名单为空：这是零结果而非失败，发一条"确认名单为空"汇总回执并留时间戳，不静默结束，也不当作取数失败。 签署系统不可达：取数失败，告警失败、留审计时间戳，按重试上限重试，仍失败则升级到值班频道；不当作"全员签署"，也不当作名单为空。 输入名单或制度链接不完整：告警并留审计时间戳，通知调用方补全后新开一次调用，本流程不重试、不拿不完整名单开跑。 审批：不涉及审批，签署本身是每个员工的确认动作，跟踪流程只汇总事实，不做裁决。 异常：跟踪 Agent 回传不合结构就停在等待点等它重新提交，不自动重跑；通知发送失败按重试上限重试，仍失败则升级到值班频道并保留待发内容供人工补发；签署状态只认签署系统记录，缺失标"待确认"，不把"已读"或"已送达"当作已签署；确认名单为空与签署系统不可达分开处理，不互相顶替。 完成：完成回执、升级回执、零结果回执与输入不完整告警各自留审计时间戳后结束。 ``` ![案例 051 新制度发布确认签署跟踪：制度发布后手动发起一次调用带入制度文档与确认对象名单（App 在读取侧聚合与伪名化，Agent 只接收白名单字段，点名通知由平台侧解析），逐人跟踪确认签署；全员签署发完成回执留审计（每条签署记录留时间戳），有未签署汇总通知本人与直属经理（名单信息缺失标待确认），周期结束未清零升级合规负责人，确认名单为空发零结果回执，签署系统不可达按取数失败告警留审计重试升级不当作全员签署，输入名单或制度链接不完整则告警留审计通知调用方补全后新开调用不重试；签署状态只认系统记录，制度内容不外带](../../../media/cases/fig-case-051-01-flow.svg){#fig-case-051-01 width=92%} 如上图所示，正常路径与异常同时可见： 1. **手动触发**：制度发布后由合规负责人发起一次调用，带入制度文档与确认对象名单、团队频道与确认周期（如 10 个工作日）。 2. **逐人跟踪签署**：App/Extension 在读取侧完成聚合与伪名化，Agent 只接收签署记录令牌、部门、签署状态等白名单字段，逐人核对签署系统记录并回传（签署记录令牌、部门、签署状态、签署时间）；回传结构不合要求时停在原等待点，等其重新提交，不自动重跑。签署状态只认签署系统记录，"已读"或"已送达"不算已签署。 3. **五路分流**： - **全员签署**：发完成回执留审计，每条签署记录留时间戳（证据留痕），让"全员已知"变成可核验的记录。 - **有未签署**：汇总未签署名单，逐人通知本人与直属经理（名单信息缺失标"待确认"）；确认周期结束时仍未清零，升级到合规负责人并留审计时间戳。 - **确认名单为空**：查询成功但名单为空，发一条零结果汇总回执并留时间戳，不静默结束，也不当作取数失败。 - **签署系统不可达**：取数失败，告警失败、留审计时间戳，按重试上限重试，仍失败则升级到值班频道；不当作"全员签署"，也不当作名单为空。 - **输入不完整**：名单或制度链接缺失时告警、留审计时间戳，通知调用方补全后新开一次调用；本流程不重试、不拿不完整名单开跑——因为拿残缺名单跑出的"全员签署"是假清零。 你不需要手写代码或配置。把上面的提示词发给 Loop，AI 会理解意图、在后台帮你画出这个"手动调用 + 逐人跟踪 + 五路分流"流程——它知道"逐人核对签署"需要一个发消息并等待回调的 Agent 环节、"按结果分流"需要一个条件路由、"周期结束判定与升级"需要一个定时检查加升级通知、"回执与催办通知"各需要一个发消息环节。AI 还会在后台校验流程结构是否完整，你不必关心这些技术细节。 - **输入名单或制度链接不完整**：告警、留审计时间戳，通知调用方补全后新开一次调用，本流程不重试——缺失名单会造成"漏掉的人永远不被跟踪"，而残缺名单跑出的"全员签署"是假清零，宁可不开跑。 - **签署状态缺失**：只认签署系统记录，缺失标"待确认"单列，不把"已读"或"已送达"当作已签署，也不猜。 - **直属经理信息缺失**：不从组织架构或历史记录猜，通知中该字段标"待确认"，由合规负责人补全或指定。 - **确认周期结束仍未清零**：升级到合规负责人并留审计时间戳，由人决定下一步（延长周期、当面沟通或按制度问责），不自动反复催办。 - **通知发送失败**：按重试上限重试投递；超过上限则升级到值班频道，并保留待发内容供人工补发。 - **确认名单为空（结果为 0）**：发零结果汇总回执并留时间戳，让"没名单"也是可核验的记录，不静默结束，也不当作取数失败。 - **签署系统不可达**：告警失败、留审计时间戳，按重试上限重试，仍失败则升级到值班频道；不当作"全员签署"，也不当作名单为空——系统查不到人，与根本没有人要查，是两件事。 - **全员签署（提前清零）**：仍发完成回执并留审计，让"提前完成"也是可核验的记录，而不是无声结束。 - **跟踪 Agent 回传不合结构**：本次完成请求被拒绝，停在等待点等其修正后重新提交，不自动重跑。 本案例不涉及审批。签署确认本身是每个员工在签署系统里的动作，本工作流只逐人跟踪与汇总事实，不做裁决；唯一升级点是确认周期结束仍未清零时通知合规负责人，这是信息升级而非审批环节，因此不设 `request_approval`，各路结果直接出回执。若要在升级后强制合规负责人逐条批复处理意见，在提示词里写明，AI 会在升级之后加一个审批环节。 本工作流的签署状态核对由获授权 Agent 通过 App/Extension 读取签署系统完成，工作流本身不直接调用外部系统。制度文档与确认对象名单作为调用输入提供；签署系统的访问凭据用 `` 占位，由 Agent 运行时从密钥引用。签署系统不可达按取数失败处理：告警、留审计时间戳，按重试上限重试，仍失败则升级到值班频道，不当作"全员签署"。通知与回执遵循最小披露：只含签署状态、时间戳与制度链接，制度内容本身不外带；需要点名的通知由平台侧按伪名化映射解析后发出。进入 Agent 消息、Run/Activation/Effect 记录与 App/Extension 工具日志的字段以白名单为准（签署记录令牌、部门、签署状态，仅令牌化/白名单字段，原值不进入以上任何一层），姓名与工号等原始字段在源头即被聚合/伪名化，并按 10% 抽查四层实际记录。 - **回放集与基准**：取 3 次历史制度发布（各含 40–60 人名单、已签署与未签署样本）回放，人工基准答案为签署系统导出的最终状态；跟踪结果与基准一致率 100%。 - **证据留痕**：每条签署记录 100% 留时间戳，抽查 10 条与签署系统记录一致；周期结束未签署清零率 100%，升级时留审计时间戳。 - **口径纪律**："已读"或"已送达"被当作已签署 0 例；签署状态缺失 100% 标"待确认"单列；直属经理缺失 100% 标"待确认"，不出现猜测的经理。 - **最小披露**：通知与回执 100% 不含制度正文，按 10% 抽样核对只含签署状态、时间戳与链接。 - **输入不完整**：名单或制度链接缺失时 100% 告警留审计并要求新开调用，拿残缺名单开跑 0 例。 - **零结果与失败分开**：确认名单为空 100% 出零结果回执、签署系统不可达 100% 按取数失败处理，两者被互相顶替 0 例。 - **源头脱敏**：进入 Agent 消息、Run/Activation/Effect 记录与 App/Extension 工具日志的字段 100% 在白名单内（签署记录令牌、部门、签署状态，仅令牌化/白名单字段，原值不进入以上任何一层），姓名与工号原文出现 0 次，按 10% 抽查四层实际记录。 - **分母与口径**：一致率分母为回放名单总人数；每次运行记录跟踪、通知与升级时间戳。 ### 复用与变体 - **同构迁移**：安全承诺书签署跟踪、年度合规培训确认跟踪、保密协议新员工签署跟踪。 - **分级催办**：直属经理收到汇总后仍未清零的，第二次升级附带未签署清单到部门负责人，在提示词里写明。 - **写回签署台账**：周期结束后再加一个 Agent 环节，由它通过 App/Extension 把最终签署状态写回合规台账；写回须是获授权 Agent 经 App/Extension 的幂等动作（幂等键=制度编号+签署记录令牌），响应未知先查后写、按重试上限有限重试、失败升级值班并置"待处理"保留补偿，全程留审计。若不需要写侧能力，改为只读汇总或仅留 Loop 回执更安全。