## 开源许可合规季度扫描 {.case data-case-id="050"} | 字段 | 值 | | --- | --- | | 案例编号 | `050` | | 行业 / 部门 | 互联网 / 合规 | | 角色 | 合规负责人 | | 难度 | `进阶` | | 调用来源 | `schedule`（定时由获授权 Agent 经 App/Extension 读取依赖清单与许可库） | 强传染性开源许可混进了产品，发布前夜才发现，要么换库要么重写。目标：每季度定时让获授权 Agent 读取依赖清单与许可库，逐依赖核对许可类型；无风险项自动发合规回执并留证据，出现风险许可（如强传染性许可）必须人工确认后才通知技术 Owner 处置。为防"风险许可被当成无风险项随回执滑过去"，设一条最高优先级红线：命中风险许可时，无论其他检查结果如何一律强制进入合规负责人人工确认，绝不自动放行，也绝不自动下架。指标：基准为风险许可的依赖 100% 进入人工确认，自动放行 0 例；每条判定 100% 附许可名与依赖版本。 - **覆盖**：定时读取依赖清单与许可库、逐依赖核对许可类型、无风险项发合规回执留证据（本期无新依赖时在回执中注明）、风险许可经人工确认后通知技术 Owner 处置。 - **不覆盖**：自动替换或下架依赖、自动改许可证、自动向开源社区提交贡献协议、自动生成法律意见。 - **假设**：有一个经授权能读取依赖清单与许可库的 Agent（通过 App/Extension）；技术 Owner 仅用系统记录，缺失标"待确认"，不从库名或历史记录猜。 把下面这段发给 Loop，它会在后台帮你创建这个 Workflow： ```text 帮我创建一个 Workflow：每季度定时由获授权的扫描 Agent 经 App/Extension 读取各服务的依赖清单与许可库，逐依赖核对许可类型并返回（依赖名、版本、许可名、是否风险许可）。合规证据留痕是硬要求：每条判定都附许可名与依赖版本，无论结果如何都可回溯。 触发：定时（计划）发起调用，调用时带入团队频道、扫描 Agent 和审批人。 结果分流（风险许可是最高优先级红线，先判红线再判其他）： 有风险许可（如强传染性许可）：无论其他检查结果如何，一律强制进入合规负责人人工确认，绝不自动放行、也绝不自动下架——命中即短路，不会落到"无风险项"路径；确认后通知技术 Owner 处置（Owner 仅用系统记录，缺失标"待确认"），附依赖名、版本、许可名，并留审计时间戳；驳回则本次失败结束、留审计，不自动改判。 无风险项（含本期无新依赖）：发合规回执并留审计，每条判定附许可名与依赖版本（证据留痕），不打扰合规负责人；本期无新依赖时在回执中注明，仍发回执不静默结束，也不当作取数失败。 许可库或依赖清单不可达、数据陈旧：任一数据源（依赖清单或许可库）不可达或陈旧即取数失败，告警失败、留审计时间戳，按重试上限重试，仍失败则升级到值班频道；绝不当作"无风险项"，也不发合规回执——查不到就判不了，不判无风险。 依赖清单作为调用输入不完整：告警并留审计时间戳，通知调用方补全后新开一次调用，本流程不重试、不拿不完整清单开跑。 审批：风险许可必须经合规负责人确认后才通知技术 Owner 处置；审批为二值确认或驳回，不设自动超时，无默认通过/否决；驳回即本次失败、留审计，不自动改判，也不自动下架。 异常：扫描 Agent 回传不合结构就停在等待点等它重新提交，不自动重跑；通知发送失败按重试上限重试，仍失败则升级到值班频道并保留待发内容供人工补发。 完成：合规回执、处置通知、取数失败升级各自留审计时间戳后结束。 ``` ![案例 050 开源许可合规季度扫描：定时让获授权 Agent 经 App/Extension 读取依赖清单与许可库逐依赖核对；命中风险许可（如强传染性许可）无论其他检查结果强制进入合规负责人人工确认、绝不自动放行或自动下架，确认后通知技术 Owner 处置（Owner 缺失标待确认），无风险项（含本期无新依赖，在回执中注明）发合规回执并附许可名与依赖版本留证据，许可库不可达按取数失败告警留审计重试升级、绝不当作无风险项；回传不合结构停在原等待点，驳回则失败结束](../../../media/cases/fig-case-050-01-flow.svg){#fig-case-050-01 width=92%} 如上图所示，正常路径、人工决策与异常同时可见： 1. **定时触发**：计划到点（每季度）发起一次调用，带入团队频道、扫描 Agent 与审批人。 2. **逐依赖核对**：获授权 Agent 经 App/Extension 读取各服务的依赖清单与许可库，逐依赖核对许可类型并回传（依赖名、版本、许可名、是否风险许可），每条判定附许可名与依赖版本；回传结构不合要求时停在原等待点，等其重新提交，不自动重跑。 3. **三路分流（先判红线）**： - **有风险许可（红线）**：如强传染性许可，无论其他检查结果如何，强制进入合规负责人人工确认，绝不自动放行、也绝不自动下架；确认后通知技术 Owner 处置（Owner 仅用系统记录，缺失标"待确认"）并留审计时间戳；驳回则本次失败结束、留审计，不自动改判。 - **无风险项（含本期无新依赖）**：发合规回执并留审计，每条判定附许可名与依赖版本（证据留痕），不打扰合规负责人；本期无新依赖时在回执中注明，不静默结束，也不当作取数失败。 - **许可库或依赖清单不可达**：任一数据源不可达或数据陈旧即取数失败，告警失败、留审计时间戳，按重试上限重试，仍失败则升级到值班频道；绝不当作"无风险项"，也不发合规回执。依赖清单作为调用输入不完整时，告警留审计并通知调用方补全后新开一次调用，本流程不重试。 你不需要手写代码或配置。把上面的提示词发给 Loop，AI 会在后台帮你画出这个"定时扫描 + 红线强制人工 + 三路分流"流程——它知道"核对依赖"需要一个发消息并等待回调的 Agent 环节、"先判红线再分流"需要一个条件路由且红线优先级最高、"人工确认"需要一个审批环节、"回执与处置通知"各需要一个发消息环节。AI 还会在后台校验流程结构是否完整，你不必关心这些技术细节。 - **风险许可被漏判或被自动放行**：这是最危险的失败。靠两层兜底——把风险许可设为永远强制人工确认的红线，命中即短路，绝不自动放行；合规回执逐条附许可名与依赖版本，事后抽查可回溯，发现漏判即人工补升级并留审计。 - **许可库或依赖清单不可达、数据陈旧**：任一数据源不可达或陈旧即取数失败，不当作"无风险项"或静默结束，而是告警失败、留审计时间戳，按重试上限重试；仍失败则升级到值班频道由人工确认。宁可本期没有结论，也不能让"查不到"变相放行。依赖清单作为调用输入不完整时同样告警留审计、通知调用方补全后新开一次调用，本流程不重试。 - **技术 Owner 缺失**：不从库名或历史记录猜 Owner，通知中该字段标"待确认"，由合规负责人确认时补全或指定。 - **负责人驳回升级**：本次失败结束并留审计；要重新升级就再发起一次确认，没有"AI 自动改判"，也没有自动下架。 - **通知发送失败**：按重试上限重试投递；超过上限则升级到值班频道，并保留待发内容供人工补发。 - **本期无新依赖（结果为 0）**：仍发合规回执并在回执中注明，留时间戳，让"没消息"变成可核验的记录。 - **扫描 Agent 回传不合结构**：本次完成请求被拒绝，停在等待点等其修正后重新提交，不自动重跑。 - **长时间无人审批**：审批本身不设自动超时，流程停在等待状态。若业务需要响应时限，由另一条定时检查的 Workflow（或值班人员）扫出超时项并通知合规负责人。 风险许可必须经合规负责人确认后才通知技术 Owner 处置，无风险项不打扰任何人。确认时负责人能看到依赖名、版本、许可名与命中理由，所以是"有依据的快速决策"而非盲目拍板。审批为二值确认或驳回，不设自动超时，无默认通过/否决；驳回即本次失败、留审计，没有"AI 自动改判"，也不自动下架——下架与否是技术 Owner 的处置决策，不是合规扫描的决策。若要更严（如风险许可必须加签法务），在提示词里写明，AI 会在流程里多加一个审批环节。 本工作流对依赖清单与许可库的读取由获授权 Agent 通过 App/Extension 完成，工作流本身不直接调用外部系统。团队频道作为调用输入提供；许可库的访问凭据用 `` 占位，由 Agent 运行时从密钥引用。任一数据源（依赖清单或许可库）不可达或数据陈旧属于取数失败，走失败回执与升级，绝不当作"无风险项"；依赖清单作为调用输入不完整时告警留审计、通知调用方补全后新开一次调用，不重试。每条判定附许可名与依赖版本，证据留痕贯穿全程；Owner 展示名由合规 App 发送侧按内部标识回填。进入 Agent 消息、Run/Activation/Effect 记录与 App/Extension 工具日志的字段以白名单为准（仅许可名、版本等核对必需字段，原值不进入以上任何一层），并按 10% 抽查四层实际记录。 - **回放集与基准**：取最近 4 个季度 80 个依赖快照（含合规、风险许可、许可信息缺失样本）回放，人工基准答案为既定合规结论；合规判定与基准一致率 ≥ 95%。 - **红线防线**：基准为风险许可的依赖 100% 进入人工确认，自动放行 0 例、自动下架 0 例。 - **证据留痕**：每条判定 100% 附许可名与依赖版本，抽查 10 条核对许可名与版本和许可库一致，判定可回溯。 - **Owner 字段**：系统记录提供 Owner 时 100% 原样带出；缺失时 100% 标"待确认"，不出现猜测的 Owner。 - **源头脱敏**：进入 Agent 消息、Run/Activation/Effect 记录与 App/Extension 工具日志的字段 100% 在白名单内（仅许可名、版本等核对必需字段，原值不进入以上任何一层），按 10% 抽查四层实际记录。 - **结果可见**：合规回执（含本期无新依赖注明）、处置通知、取数失败三类结果 100% 各有可见回执，不出现静默成功；许可库或依赖清单任一数据源不可达被当作"无风险项"0 例，依赖清单不完整被开跑 0 例。 - **分母与口径**：一致率分母为回放依赖总数；每次运行记录核对与通知时间戳。 ### 复用与变体 - **同构迁移**：安全漏洞依赖季度扫描、第三方组件黑名单核对、内网镜像源合规巡检。 - **双审红线**：对强传染性许可命中加签法务，在提示词里写明。 - **写回依赖台账**：处置结论默认只做只读分析或仅留 Loop 回执，不写依赖台账——合规扫描的产物是结论与证据，台账留档交由人在台账系统内执行更安全；确需写回时须是获授权 Agent 经 App/Extension 的幂等动作（幂等键=依赖名+版本+季度），响应未知先查后写、按重试上限有限重试、失败升级值班并置"待处理"保留补偿，全程留审计。