## 全员改进提案月度汇总 {.case data-case-id="080"} | 字段 | 值 | | --- | --- | | 案例编号 | `080` | | 行业 / 部门 | 制造 / 管理 | | 角色 | 精益负责人 | | 难度 | `入门` | | 调用来源 | `schedule`（每月定时由获授权 Agent 经 App/Extension 读取提案平台） | 一线的改进提案散落在平台上，月度评比靠人肉翻记录，好点子被埋没，也说不清哪类问题提得最多。目标：每月 1 日定时让获授权 Agent 经 App/Extension 在提案平台侧聚合——统计窗口固定为半开区间的上一完整自然月 [上月 1 日 00:00, 本月 1 日 00:00)（时区作为调用输入提供、钉死不漂移），汇总上月新提案的分类、计数与高票项，只统计不评级，评级由评审会人工做。月报草稿经精益负责人确认后公示；提案人做周期伪名化——工号在月内可重新识别本人，公示稿只带提案编号，提案人与提案编号的映射由平台侧保持，不进入工作流；月份键幂等，同月重复调用去重、不重复汇总。本工作流对提案平台只读不写：确认、公示与回执都只是 Loop 内的发消息与回执动作，不向提案平台写回任何状态。指标：每月 1 日产出月报草稿；重复统计 0 例；公示稿含工号或姓名的 0 例；三类结果各有回执。 - **覆盖**：定时在平台侧聚合上月新提案（分类/计数/高票项，统计窗口为半开区间的上一完整自然月 [上月 1 日 00:00, 本月 1 日 00:00)、时区作为输入钉死）、月报草稿经确认后公示、提案人周期伪名化（公示稿只带提案编号）、月份键幂等去重、零结果与取数失败回执。 - **不覆盖**：对提案评级或打分、自动决定采纳与立项、代替评审会排序、自动联系提案人、向提案平台写回任何状态（工作流对平台只读）。 - **假设**：有一个经授权能读取提案平台的 Agent（通过 App/Extension），App/Extension 在平台侧只放行提案编号、分类、投票数与提交时间等白名单字段；分类与计数只用平台字段，不猜分类；时区作为调用输入提供。 把下面这段发给 Loop，它会在后台帮你创建这个 Workflow： ```text 帮我创建一个 Workflow：每月 1 日定时由获授权的汇总 Agent 经 App/Extension 读取提案平台，统计窗口固定为半开区间的上一完整自然月 [上月 1 日 00:00, 本月 1 日 00:00)——时区作为调用输入提供并钉死，不跨月、不取当天（本月 1 日 00:00 整提交的提案归下月）。App/Extension 在平台侧只放行提案编号、分类、投票数与提交时间等白名单字段，提案人姓名与工号在源头即被周期伪名化——公示稿只带提案编号，提案人与提案编号的映射由平台侧保持，不进入本工作流。按平台自带分类汇总计数与高票项（只统计不评级，评级由评审会人工做）。 汇总 Agent 回传 JSON：{month_key: 平台调度器签发的月份令牌（取自调用输入并原样回传，不由 Agent 生成）, categories: [{cat_name: 非空分类, count: 非负整数}], top_items: [{idea_ref: 提案编号, cat_name: 非空分类, votes: 非负整数}], total: 非负整数, source_ok: 布尔, fields_missing: [枚举(提案平台)], audit_ts: 时间戳}。状态矩阵：source_ok 与 audit_ts 始终必填；source_ok=false 时 fields_missing 必为 [提案平台]，month_key、categories、top_items、total 禁止出现；source_ok=true 时 fields_missing 必为空，month_key、categories、top_items、total 全部必填，categories 与 top_items 每个元素逐字段必填，categories 的 count 之和必须等于 total，每个 top_items.cat_name 必存在于 categories；total=0 当且仅当 categories 与 top_items 均为空，total>0 时 categories 必非空。仅接受这些组合；其余 callback 一律拒绝，原 Effect 保持 awaiting。 幂等与顺序：以平台调度器签发并作为调用输入带入的 month_key（如 2026-07）为稳定业务键组成部分，Agent 只能原样回传——同月内重复调用时，若该月已成功汇总并公示则幂等跳过并发回执说明，不重复汇总、不重复公示；同月多次调用按提交时间先后串行处理，不并发汇总。工作流对提案平台只读不写：确认、公示与各类回执都是 Loop 内的发消息与回执动作，不写回平台状态。 触发：定时（计划）发起调用，平台调度器按输入时区签发 month_key 并作为调用输入带入，同时带入精益频道、审批人、评审人标识、统计时区与汇总 Agent、值班频道（值班频道作为调用输入提供，用于失败升级）。 结果分三类处理： 有提案：生成上月提案月报草稿（分类计数、高票项、总数），交精益负责人确认后公示到精益频道并留审计时间戳；公示稿只带提案编号，不含姓名与工号。 上月无提案：发一条"上月无新提案"零结果回执并留时间戳，不静默结束。 提案平台不可达：告警失败、留审计时间戳，按重试上限重试，仍失败则升级到值班频道（作为调用输入提供）；不当作"上月无新提案"，也不发空月报。 审批：月报草稿必须经精益负责人确认后才公示，审批为二值确认或驳回，不设自动超时，无默认通过/否决；公示稿只含分类计数与高票项等统计信息；驳回则失败结束留审计、不公示。 异常：汇总 Agent 回传不合结构就停在等待点等它重新提交，不自动重跑；通知发送失败按重试上限重试，仍失败则升级到值班频道（作为调用输入提供）并保留待发内容供人工补发。 完成：公示、零结果回执、取数失败升级，各自留审计时间戳后结束。 ``` ![案例 080 全员改进提案月度汇总：每月 1 日定时让获授权 Agent 经 App/Extension 在提案平台侧聚合上一完整自然月（半开区间 上月 1 日 00:00 至 本月 1 日 00:00，时区作为输入钉死）的新提案（分类/计数/高票项，只统计不评级），提案人姓名与工号在源头周期伪名化，公示稿只带提案编号（映射由平台侧保持）；有提案生成月报草稿交精益负责人确认后公示（Loop 回执，不写回平台），驳回则留审计不公示，上月无提案发零结果回执，平台不可达按取数失败告警留审计重试升级；月份键幂等同月重复调用去重不重复汇总；回传不合结构停在原等待点](../../../media/cases/fig-case-080-01-flow.svg){#fig-case-080-01 width=92%} 如上图所示，正常路径、人工决策与异常同时可见，三类结果都有可见回执： 1. **定时触发**：计划到点（每月 1 日）发起一次调用，带入精益频道、审批人、评审人标识、统计时区与汇总 Agent；统计窗口固定为半开区间的上一完整自然月 [上月 1 日 00:00, 本月 1 日 00:00)，时区作为输入钉死；同月已成功汇总过则按月份键幂等跳过，不重复汇总。 2. **汇总提案**：获授权 Agent 经 App/Extension 在平台侧白名单化读取提案平台，取上月新提案，按平台分类回传计数与高票项（只统计不评级）；回传缺任一必填字段视为不合结构，停在原等待点，等其重新提交，不自动重跑。 3. **三路分流**： - **有提案**：生成月报草稿，交精益负责人确认后公示到精益频道并留审计时间戳；公示稿只带提案编号，不含姓名与工号。 - **上月无提案**：发一条零结果汇总回执并留时间戳，不静默结束。 - **提案平台不可达**：告警失败、留审计时间戳，按重试上限重试，仍失败则升级到值班频道，不当作"上月无新提案"。 你不需要手写代码或配置。把上面的提示词发给 Loop，AI 会理解意图、在后台画出这个"定时汇总 + 确认公示 + 三路分流"流程——它知道"汇总提案"需要一个发消息并等待回调的 Agent 环节、"按有无提案分流"需要一个条件路由、"确认公示"需要一个审批环节、"月报与回执"各需要一个发消息环节，并用月份键做幂等去重。AI 还会在后台校验流程结构是否完整，你不必关心这些技术细节。 - **提案平台不可达、数据陈旧**：不当作"本月无新提案"或静默结束，更不发空月报，而是告警失败、留审计时间戳，按重试上限重试；仍失败则升级到值班频道由人工确认。 - **重复调用导致重复统计**：同月内再次成功调用时按月份键做幂等去重，已汇总过就跳过并回执说明，不重复汇总、不重复公示；同月多次调用按提交时间先后串行处理，不并发汇总。 - **负责人驳回草稿**：本次失败结束并留审计，草稿不公示；精益负责人改完后可重新发起一次汇总调用，没有"AI 自动公示"。 - **公示发送失败**：按重试上限重试投递；超过上限则升级到值班频道，并保留待发内容供人工补发。 - **本月无提案（结果为 0）**：仍发一条零结果汇总回执并留时间戳，让"没消息"变成可核验的记录，而不是无声结束。 - **汇总 Agent 回传不合结构**：本次完成请求被拒绝，停在等待点等其修正后重新提交，不自动重跑。 - **长时间无人确认公示**：审批本身不设自动超时，流程停在等待状态。若业务需要响应时限，由另一条定时检查的 Workflow（或值班人员）扫出超时项并通知精益负责人。 月报草稿必须经精益负责人确认后才公示。确认时负责人能看到分类计数、高票项与总数（提案人已周期伪名化，只呈现提案编号），所以是"有依据的快速确认"而非盲目拍板。审批只有确认或驳回两种结果，不设自动超时、无默认通过/否决，驳回则失败结束留审计。评级始终留给评审会人工做（评审人标识作为调用输入提供），工作流只统计不评级。公示与驳回都只是 Loop 内的发消息与回执动作——本流程对提案平台只读，月度汇总是回执式收口，不写回任何平台状态。若要更严（如公示前须部门经理会签涉本部门的提案数），在提示词里写明，AI 会在流程里多加一个审批环节。 本工作流对提案平台的读取由获授权 Agent 通过 App/Extension 完成，工作流本身不直接调用外部系统，且对提案平台只读不写——确认、公示、驳回、零结果与取数失败回执全部是 Loop 内的发消息与回执动作，不向平台写回任何状态。进入 Agent 消息、Run/Activation/Effect 记录与 App/Extension 工具日志仅记录白名单/令牌化字段（原值不进入以上任何一层），可回溯个人或敏感资产的字段在源头即被令牌化/伪名化，并按 10% 抽查四层实际记录——App/Extension 在平台侧把提案人做周期伪名化，公示稿只带提案编号，工号与姓名不进入 Agent 消息，提案人与编号的映射由平台侧保持。精益频道、审批人、评审人标识、统计时区与值班频道作为调用输入提供；提案平台的访问凭据用 `` 占位，由 Agent 运行时从密钥引用。平台不可达或数据陈旧属于取数失败，走失败回执与升级，不当作"上月无新提案"。 - **回放集与基准**：取最近 6 个月的 120 条提案（含跨月边界提交、高票、零票、平台故障日样本）回放，基准为按"半开区间上一完整自然月、时区作为输入钉死"口径的月度分类计数与高票清单。 - **窗口口径**：跨月边界提交的提案 100% 计入正确月份（本月 1 日 00:00 整提交的归下月），统计窗口偏离半开自然月区间的 0 例。 - **统计准确**：分类计数与高票项和基准一致率 ≥ 95%；同月重复调用重复统计 0 例，幂等跳过 100% 出回执。 - **源头脱敏**：进入 Agent 消息、Run/Activation/Effect 记录与 App/Extension 工具日志的字段 100% 在白名单内（原值不进入以上任何一层），并按 10% 抽查四层实际记录；公示稿中提案人姓名与工号出现 0 次，呈现 100% 为提案编号。 - **人工把关与只读边界**：公示的月报 100% 经精益负责人确认，自动公示 0 例；驳回 100% 留审计且不公示；运行记录中向提案平台写入状态的 0 例（月度汇总为回执式收口）。 - **结果可见**：三类结果 100% 各有可见回执留审计，不出现静默成功；月报草稿在每月 1 日产出。 - **分母与口径**：计数分母为上一自然月（半开区间）新提交且平台分类有效的提案；每次运行记录读取与公示时间戳。 ### 复用与变体 - **同构迁移**：合理化建议季度汇总、客户反馈月度分类汇总、内训课程评价期汇总。 - **分级公示**：高票项公示到全员工厂频道，完整月报只发精益频道，在提示词里写明。 - **写回平台**：公示后再加一个 Agent 环节，由它通过 App/Extension 把"已纳入月报"状态写回提案平台；写回须是获授权 Agent 经 App/Extension 的幂等动作（业务键=调用输入中的平台签发 month_key+提案编号+期望状态"已纳入月报"+目标平台），Agent 不能自造月份；响应未知先查后写、按重试上限有限重试、失败升级值班并置"待处理"保留补偿，全程留审计。若不需要写侧能力，公示后在 Loop 内留回执更安全。