## 软件许可使用率与续订提醒 {.case data-case-id="068"} | 字段 | 值 | | --- | --- | | 案例编号 | `068` | | 行业 / 部门 | SaaS / 企业 IT | | 角色 | IT 资产管理员 | | 难度 | `进阶` | | 调用来源 | `schedule`（定时由获授权 Agent 经 App/Extension 读取许可管理平台） | 许可按峰值人头买，用的人不到一半；续约截止前三天才发现，采购只能原价硬续。目标：每周定时让获授权 Agent 经 App/Extension 在许可管理平台侧聚合——只取许可标识、已分配数、实际使用数与到期日等数量与状态字段，单价、折扣、合同金额等商业条款在源头即被脱敏，不进入 Agent 消息与运行记录；逐许可比对找出闲置与临期两类问题（两者可并行出现，互不顶替）：闲置清单交 IT 确认后通知 Owner 回收（回收由人在许可平台执行），60 天内到期的续订提醒单列通知采购与 IT。指标：闲置许可从识别到 Owner 收到通知的中位数 ≤ 2 个工作日；60 天内到期许可 100% 在到期前 30 天被通知到；Agent 消息与回执含商业条款的 0 例。 - **覆盖**：定时在平台侧聚合数量与状态、逐许可（一许可一条记录、一次处理单元）比对已分配与实际使用、闲置与临期两路并行判定、闲置清单经 IT 确认后通知 Owner、续订提醒单列通知采购与 IT、使用率健康归档、平台不可达按取数失败处理。 - **不覆盖**：自动回收许可、自动发起续订采购、自动与供应商谈判、自动改许可平台数据、任何商业条款的读取与传递。 - **假设**：有一个经授权能读取许可管理平台的 Agent（通过 App/Extension），App/Extension 在源头只放行数量与状态白名单字段；闲置阈值为"连续 30 天已分配未使用"，作为调用输入提供；许可 Owner 标识与采购目标标识为受控令牌（权限受控且 Agent 无法反查原值；展示名仅由下游授权 App 发送时回填），与采购频道一起作为调用输入提供；通知目标唯一取自调用输入提供的 Owner 标识（平台记录的 owner_ref 只作查找键），缺失标"待确认"；许可单价等商业条款在源头即被脱敏，不进入回执。 把下面这段发给 Loop，它会在后台帮你创建这个 Workflow： ```text 帮我创建一个 Workflow：每周定时由获授权的比对 Agent 经 App/Extension 读取许可管理平台，App/Extension 在平台侧只聚合数量与状态白名单字段——许可标识、已分配数、实际使用数、闲置清单、到期日、Owner 标识（受控令牌），逐许可比对已分配与实际使用（闲置阈值：连续 30 天已分配未使用），并检查到期日；一许可一条记录、一次处理单元，逐许可独立判定互不影响。商业条款源头脱敏：许可单价、折扣与合同金额在源头即被脱敏，不进入 Agent 消息、运行记录、回执与通知。 触发：定时（计划）发起调用，调用时带入 IT 资产管理频道、值班频道（值班频道作为调用输入提供，用于失败升级）、审批人（IT 资产管理员）、许可 Owner 标识（受控令牌：权限受控且 Agent 无法反查原值；展示名仅由下游授权 App 发送时回填）、采购目标标识（同为受控令牌）、采购频道与比对 Agent。 比对 Agent 回传 JSON：{licenses: [{license_ref: 许可标识, assigned_count: 非负整数, used_count: 非负整数, idle_flag: 布尔, idle_days: 非负整数, expire_date: 日期, owner_ref: Owner 令牌|缺失（平台记录中的 owner_ref 仅作查找键：用于与调用输入提供的 Owner 标识令牌匹配；通知目标一律取调用输入提供的标识，二者不一致时以调用输入为准并标"待确认"，不自动采信平台值）}], source_ok: 布尔, fields_missing: [枚举(许可平台)], audit_ts: 时间戳}；必填/禁止按状态闭合：source_ok 为真（成功态）时 licenses 必填且数组内每个元素（一条许可一条记录）的 license_ref、assigned_count、used_count、idle_flag、idle_days、expire_date 全部必填，fields_missing 必为空；每条必须满足 0<=used_count<=assigned_count，idle_flag=true 时 assigned_count>used_count 且 idle_days>=闲置阈值，idle_flag=false 时 0<=idle_days<闲置阈值；assigned_count=used_count 时进一步要求 idle_flag=false 且 idle_days=0。source_ok 为假（失败态）时禁止携带 licenses 数组，fields_missing 必为 [许可平台]。缺任一应必填项或违反状态禁止/一致性条件视为回传不合结构。 仅接受上述状态矩阵中的组合，其余 callback 一律拒绝并保持原等待点。 结果处理（先判取数成败；取数成功后闲置与到期两路并行判定，同一许可既闲置又临期时两条都走，不互相顶替）： 平台不可达（许可管理平台取数失败、数据陈旧）：告警失败、留审计时间戳，按重试上限重试，仍失败则升级到值班频道（作为调用输入提供）；不当作"本期无闲置无到期"。 有闲置（已分配未使用超阈值）：闲置清单交 IT 资产管理员确认，确认后通知许可 Owner 回收（Owner 仅用调用输入提供的标识，缺失标"待确认"），回收由人在许可平台执行，工作流不动许可数据，并留审计时间戳。 许可 60 天内到期：续订提醒单列成清单，通知采购与 IT（只列许可标识与到期日，不含任何商业条款），并留审计时间戳。 取数成功且两类清单均为空：发一条"本期无闲置无到期"汇总回执并留时间戳，不静默结束（此为零结果回执，与"使用率健康"不重复发送）。 审批：闲置清单必须经 IT 资产管理员确认后才通知 Owner，防止把休假、项目间歇期的正常未用误判成闲置；审批为二值确认或驳回，不设自动超时，无默认通过/否决；驳回即该许可不通知、留审计。 异常：比对 Agent 回传不合结构就停在等待点等它重新提交，不自动重跑；通知发送失败按重试上限重试，仍失败则升级到值班频道并保留待发内容供人工补发。 完成：闲置通知、续订提醒、零结果回执、取数失败告警各自留审计时间戳后结束。 ``` ![案例 068 软件许可使用率与续订提醒：每周定时让获授权 Agent 经 App/Extension 在许可平台侧聚合数量与状态白名单字段（单价等商业条款源头脱敏，不进 Agent 消息与运行记录），逐许可比对已分配与实际使用；平台不可达按取数失败告警留审计重试升级，取数成功后闲置与到期两路并行判定（同一许可既闲置又临期两条都走），有闲置清单经 IT 资产管理员确认后通知 Owner 回收（回收由人在许可平台执行，Owner 缺失标待确认，驳回则该许可不通知），60 天内到期续订提醒单列通知采购与 IT，两类清单均为空发零结果回执不静默结束，均留审计时间戳；回传不合结构停在原等待点](../../../media/cases/fig-case-068-01-flow.svg){#fig-case-068-01 width=92%} 如上图所示，正常路径、人工决策与异常同时可见，每类结果都有回执： 1. **定时触发**：计划到点（每周）发起一次调用，带入 IT 资产管理频道、值班频道、审批人（IT 资产管理员）、许可 Owner 标识（受控令牌）、采购频道与比对 Agent。 2. **逐许可比对**：获授权 Agent 经 App/Extension 在平台侧聚合白名单字段，逐许可（一许可一条记录、一次处理单元）比对已分配与实际使用并检查到期日，回传许可数组（每元素一条许可：许可标识、已分配数、实际使用数、闲置清单、到期日，Owner 为受控令牌）；回传缺任一必填字段视为不合结构，停在原等待点，等其重新提交，不自动重跑。 3. **结果分流（先判取数成败；成功后闲置与到期两路并行判定）**： - **平台不可达**：取数失败或数据陈旧，告警失败、留审计时间戳，按重试上限重试，仍失败则升级到值班频道；不当作"本期无闲置无到期"。 - **有闲置**：闲置清单交 IT 资产管理员确认，确认后通知许可 Owner 回收（Owner 仅用调用输入提供的标识，缺失标"待确认"），回收由人在许可平台执行，工作流不动许可数据；驳回则该许可不通知、留审计。 - **许可 60 天内到期**：续订提醒单列成清单，通知采购与 IT（只列许可标识与到期日，不含单价等商业条款）；同一许可既闲置又临期时两条都走，不互相顶替。 - **两类清单均为空**：取数成功但闲置与到期清单都为空，发零结果汇总回执并留时间戳，不静默结束。 你不需要手写代码或配置。把上面的提示词发给 Loop，AI 会理解意图、在后台画出这个"定时比对 + 确认后通知 + 并行分流"流程——它知道"逐许可比对"需要一个发消息并等待回调的 Agent 环节、"先判取数成败再并行判闲置与到期"需要一个条件路由、"IT 确认闲置清单"需要一个审批环节、"通知与回执"各需要一个发消息环节。AI 还会在后台校验流程结构是否完整，你不必关心这些技术细节。 - **正常间歇被误判成闲置**：休假、项目间歇期的"暂时不用"被误回收，回来时工具没了。靠人工确认兜底：闲置清单必须经 IT 资产管理员确认后才通知 Owner，驳回即该许可不通知、留审计，没有"AI 自动回收"。 - **平台不可达、数据陈旧**：不当作"本期无闲置无到期"或静默结束，而是告警失败、留审计时间戳，按重试上限重试；仍失败则升级到值班频道（作为调用输入提供）由人工确认。 - **续订提醒被闲置提醒淹没**：两类问题单列清单、分别通知，同一许可既闲置又临期时两条都走（并行判定，互不顶替）。 - **许可 Owner 缺失**：不从使用记录或部门架构猜 Owner，通知中该字段标"待确认"，由 IT 资产管理员补全或指定。 - **商业条款外泄**：靠源头脱敏兜底——App/Extension 只放行许可标识、数量与到期日等白名单字段，单价、折扣与合同金额在源头即被脱敏，不进入 Agent 消息、运行记录、回执与通知。 - **通知发送失败**：按重试上限重试投递；超过上限则升级到值班频道，并保留待发内容供人工补发。 - **本期无闲置且无到期（结果为 0）**：仍发一条零结果汇总回执并留时间戳，让"没消息"变成可核验的记录；该回执与"使用率健康"语义合并，不重复发送。 - **比对 Agent 回传不合结构**：本次完成请求被拒绝，停在等待点等其修正后重新提交，不自动重跑。 - **长时间无人审批**：审批本身不设自动超时，流程停在等待状态。若业务需要响应时限，由另一条定时检查的 Workflow 扫出超时项并通知 IT 资产管理员。 闲置清单必须经 IT 资产管理员确认后才通知 Owner 回收；续订提醒与零结果回执不经审批。确认时 IT 资产管理员看到的是按许可标识列出的闲置清单（已分配数、实际使用数、闲置天数），商业条款不在审批视图里。审批只有确认或驳回两种结果，不设自动超时、无默认通过/否决：确认则通知 Owner；驳回则该许可不通知、留审计，下期扫描若仍闲置会再次出现，没有"AI 自动回收"。若要更严（如高价值许可的回收必须部门负责人会签），在提示词里写明，AI 会在流程里多加一个审批环节。 本工作流对许可管理平台的读取由获授权 Agent 通过 App/Extension 完成，工作流本身不直接调用外部系统。进入 Agent 消息、Run/Activation/Effect 记录与 App/Extension 工具日志仅记录白名单/令牌化字段（原值不进入以上任何一层），可回溯个人或敏感资产的字段在源头即被令牌化/伪名化，并按 10% 抽查四层实际记录——App/Extension 在平台侧只放行许可标识、数量与到期日等数量与状态字段，单价、折扣与合同金额等商业条款在源头即被脱敏；许可 Owner 标识与采购目标标识为受控令牌。IT 资产管理频道、值班频道、许可 Owner 标识与采购频道作为调用输入提供；平台的访问凭据用 `` 占位，由 Agent 运行时从密钥引用。平台不可达或数据陈旧属于取数失败，走失败回执与升级，不当作"本期无闲置无到期"。许可回收由人在许可平台执行，工作流不动许可数据、不发起任何采购动作。 - **回放集与基准**：取最近 3 个月 25 个历史许可快照（含闲置、临期、两类并存、健康、平台不可达样本）回放，基准为应识别的闲置与临期清单；每次回放记录比对、确认、通知时间戳。 - **闲置准确率**：识别出的闲置许可与基准一致率 ≥ 90%；误判经确认驳回的 ≤ 5%，驳回的 100% 未通知 Owner。 - **续订及时性**：60 天内到期许可 100% 在到期前 30 天被通知到采购与 IT；闲置许可从识别到 Owner 收到通知的中位数 ≤ 2 个工作日。 - **源头脱敏**：进入 Agent 消息、Run/Activation/Effect 记录与 App/Extension 工具日志的字段 100% 在白名单内（原值不进入以上任何一层），按 10% 抽查四层实际记录；每周抽查 5 条回执与通知，出现许可单价、折扣或合同金额的 0 例；Owner 缺失时 100% 标"待确认"，Owner 与采购目标标识均为受控令牌。 - **结果可见**：闲置通知、续订提醒、零结果回执、取数失败告警四类结果 100% 各有可见回执，不出现静默成功。 - **分母与口径**：一致率分母为回放许可总数；既闲置又临期的许可两条路径分别计数，不重复计入同一分母。 ### 复用与变体 - **同构迁移**：云资源配额使用率巡检、内部测试环境占用回收、会议室使用率巡检。 - **分级路由**：高价值许可的回收提醒加签部门负责人，普通许可只确认一次。 - **写回许可平台**：Owner 回收完成后，再加一个 Agent 环节，由它通过 App/Extension 把"已回收"状态写回许可管理平台对账；写回须是获授权 Agent 经 App/Extension 的幂等动作（幂等键=许可标识+回收周期），响应未知先查后写、按重试上限有限重试、失败升级值班并置"待处理"保留补偿，全程留审计。若不需要写侧能力，改为只读汇总或仅留 Loop 回执更安全。