## OKR 周会进展提醒 {.case data-case-id="074"} | 字段 | 值 | | --- | --- | | 案例编号 | `074` | | 行业 / 部门 | SaaS / 管理 | | 角色 | OKR 负责人 | | 难度 | `入门` | | 调用来源 | `schedule`（定时由获授权 Agent 经 App/Extension 读取 OKR 平台） | 周会前才发现一半 Objective 这周没更新，OKR 变成了月底突击补填的表格。目标：每周定时让获授权 Agent 读取 OKR 平台各 Objective 本周更新状态，有未更新的把提醒名单交 OKR 负责人确认后通知对应 Owner 与经理；全部已更新发汇总回执；本期无活跃 OKR 发零结果回执。进展数值只到信心指数档位，不外带经营明细。指标：周会前未更新项 100% 被提醒到；从平台读取到提醒送达 Owner 的中位时间 < 15 分钟。 - **覆盖**：定时读取各 Objective 本周更新状态、四类结果各有回执、有未更新时经负责人确认后通知 Owner 与经理。 - **不覆盖**：自动代填进展、自动调整目标或信心指数、自动考核评分。 - **假设**：有经授权能读取 OKR 平台本周更新状态的 Agent（通过 App/Extension）；Owner 与经理标识为受控令牌（权限受控且 Agent 无法反查原值；展示名仅由下游授权 App 发送时回填），仅用调用输入提供的字段，缺失标"待确认"；进展数值只到信心指数档位；业务最近更新时间（OKR 平台记录的 last_updated_at）作为输入/抽取字段随白名单带入，未更新天数只按该时间计算。 把下面这段发给 Loop，它会在后台帮你创建这个 Workflow： ```text 帮我创建一个 Workflow：每周定时由获授权的读取 Agent 经 App/Extension 读取 OKR 平台上各 Objective 的本周更新状态，App/Extension 在平台侧只放行白名单字段——目标代号、Owner 内部标识（受控令牌：权限受控且 Agent 无法反查原值；展示名仅由下游授权 App 发送时回填）、是否已更新、信心指数档位、业务最近更新时间与可信基准时刻 as_of_at（调度器签发；last_updated_at 由 OKR 平台记录原样带出，作为白名单抽取字段，未更新天数按本次基准时刻减该时间计算，不由 Agent 估算；进展的经营明细在源头即被过滤，目标名称以代号呈现）。 读取 Agent 回传 JSON：{week_key: 周次, as_of_at: 时间戳（可信基准时刻：由平台/调度器在发起本次读取时签发，作为调用输入带入并原样回传，不由 Agent 生成）, objectives: [{okr_ref: 目标代号, owner_ref: Owner 令牌|缺失, updated: 布尔, last_updated_at: 时间戳（该 Objective 在 OKR 平台记录的业务最近更新时间——不是本次抽取时间；由平台记录原样带出，不由 Agent 估算）, stale_days: 整数（=floor((as_of_at − last_updated_at) / 一天)，仅按此公式计算）, confidence_band: 枚举(档位)|缺失}], source_ok: 布尔, fields_missing: [枚举(OKR 平台)], audit_ts: 时间戳}；必填/禁止按状态闭合：source_ok 为真时 week_key、as_of_at 与 objectives 必填且 fields_missing 必为空（成功却声明平台缺失即矛盾，不合结构），数组内每个元素的 okr_ref、updated、last_updated_at 三项必填（逐元素必填，缺失即无法区分全部已更新/有未更新，视为回传不合结构）；updated 为假时该元素 stale_days 必填，updated 为真时 stale_days 必为缺失（已更新却带未更新天数即矛盾，不合结构）。source_ok 为假（失败态）时禁止携带 objectives 数组，fields_missing 必填且至少列出 OKR 平台项。缺任一应必填项或违反状态禁止条件视为回传不合结构。 仅接受上述状态矩阵中的组合，其余 callback 一律拒绝并保持原等待点。 触发：定时（计划）发起调用，调用时带入团队频道、读取 Agent、审批人、Owner 与经理标识映射（受控令牌）、平台/调度器签发的基准时刻 as_of_at 和值班频道（值班频道作为调用输入提供，用于失败升级）。 结果分四类处理（先判取数成败）： 有未更新：整理提醒名单（目标代号、Owner 标识（受控令牌）、未更新天数——按业务最近更新时间（OKR 平台记录的 last_updated_at）计算）交 OKR 负责人审批，确认后通知对应 Owner 与经理（标识取自调用输入的受控令牌，缺失标"待确认"），并留审计时间戳。 全部已更新：发一条汇总回执并留时间戳，不静默结束。 本期无活跃 OKR（读取成功但平台无活跃目标）：发一条零结果回执并留时间戳，不静默结束，也不当作取数失败。 取数失败（OKR 平台不可达或数据陈旧）：告警失败、留审计时间戳，按重试上限重试，仍失败则升级到值班频道（作为调用输入提供）。 审批：提醒名单必须经 OKR 负责人确认后才发出；审批为二值确认或驳回，不设自动超时，无默认通过/否决；驳回则本次失败结束并留审计，退回修改后重新发起，不自动发送。 异常：读取 Agent 回传不合结构就停在等待点等它重新提交，不自动重跑；通知发送失败按重试上限重试，仍失败则升级到值班频道并保留待发内容供人工补发。本期无活跃 OKR（读取成功但平台无活跃目标）发一条零结果回执并留时间戳，不静默结束，也不当作取数失败。 完成：提醒、汇总回执、零结果回执、取数失败告警、审批驳回失败结束五类结果各自留审计时间戳后结束。 ``` ![案例 074 OKR 周会进展提醒：定时让获授权 Agent 读取 OKR 平台各 Objective 本周更新状态（带调度器签发的基准时刻 as_of_at，未更新天数按 floor((as_of_at−last_updated_at)/一天) 计算）；有未更新整理提醒名单经 OKR 负责人确认后通知 Owner 与经理（Owner 缺失标待确认，进展数值只到信心指数档位），驳回退回修改重新提交；全部已更新发汇总回执；本期无活跃 OKR 发零结果回执；平台不可达按取数失败告警留审计重试升级；回传不合结构停在原等待点](../../../media/cases/fig-case-074-01-flow.svg){#fig-case-074-01 width=92%} 如上图所示，正常路径、人工决策与异常同时可见： 1. **定时触发**：计划到点（每周）发起一次调用，带入团队频道、读取 Agent、审批人、Owner 与经理标识映射（受控令牌）、平台/调度器签发的基准时刻 as_of_at 及值班频道。 2. **读取更新状态**：获授权 Agent 经 App/Extension 在平台侧白名单化读取各 Objective 本周更新状态并回传（目标代号、Owner 标识（受控令牌）、是否已更新、信心指数档位、业务最近更新时间（OKR 平台记录的 last_updated_at）、基准时刻 as_of_at 原样回传）；回传缺任一必填字段视为不合结构，停在原等待点，等其重新提交，不自动重跑。 3. **四类结果分流（先判取数成败）**： - **有未更新**：整理提醒名单交 OKR 负责人审批，确认后通知对应 Owner 与经理（标识取自调用输入，缺失标"待确认"）并留审计时间戳；驳回则失败结束，退回修改后重新发起。 - **全部已更新**：发一条汇总回执并留时间戳，不静默结束。 - **本期无活跃 OKR**：读取成功但平台无活跃目标，发零结果回执并留时间戳，不当作取数失败。 - **取数失败**：OKR 平台不可达或数据陈旧，告警失败、留审计时间戳，按重试上限重试，仍失败则升级到值班频道。 你不需要手写代码或配置。把上面的提示词发给 Loop，AI 会理解意图、在后台画出这个"定时读取 + 人工确认 + 四路分流"流程——它知道"读取更新状态"需要一个发消息并等待回调的 Agent 环节、"确认后才提醒"需要一个审批环节、"分四类结果"需要一个条件路由、"提醒与回执"各需要一个发消息环节，并把它们连起来。AI 还会在后台校验流程结构是否完整，你不必关心这些技术细节。 - **OKR 平台不可达或数据陈旧**：不当作"本期无活跃 OKR"或静默结束，而是告警失败、留审计时间戳，按重试上限重试；仍失败则升级到值班频道由人工确认。 - **Owner 字段缺失**：Agent 不从成员列表或历史记录猜 Owner，提醒名单中该字段标"待确认"，由 OKR 负责人确认时补全或指定。 - **本期无活跃 OKR（结果为 0）**：仍发一条零结果回执并留时间戳，让"没消息"变成可核验的记录，而不是无声结束。 - **负责人驳回名单**：本次失败结束并留审计，退回修改后由负责人重新发起确认，没有"AI 自动改名单后直接发送"；提醒对象由人把关。 - **通知发送失败**：按重试上限重试投递；超过上限则升级到值班频道，并保留待发内容供人工补发。 - **读取 Agent 回传不合结构**：本次完成请求被拒绝，停在等待点等其修正后重新提交，不自动重跑。 - **长时间无人审批**：审批本身不设自动超时，流程停在等待状态。若业务需要响应时限，由另一条定时检查的 Workflow（或值班人员）扫出超时项并通知负责人。 提醒名单必须经 OKR 负责人确认后才发出：确认时能看到目标代号、Owner 标识（受控令牌）与未更新天数（按 floor((as_of_at − last_updated_at) / 一天) 计算，as_of_at 为调度器签发的可信基准时刻），所以是"有依据的快速决策"而非盲目群发。审批只有确认或驳回两种结果，不设自动超时、无默认通过/否决，驳回即本次失败结束并留审计，退回修改后重新发起。工作流只汇总与提醒，不替管理者做决定——是否催、催到什么程度，由负责人在确认时把握。 本工作流对 OKR 平台的读取由获授权 Agent 通过 App/Extension 完成，工作流本身不直接调用外部系统。进入 Agent 消息、Run/Activation/Effect 记录与 App/Extension 工具日志仅记录白名单/令牌化字段（原值不进入以上任何一层），可回溯个人或敏感资产的字段在源头即被令牌化/伪名化，并按 10% 抽查四层实际记录——App/Extension 在平台侧只放行目标代号、Owner 内部标识（受控令牌）、是否已更新、信心指数档位、业务最近更新时间（平台记录的 last_updated_at，作为输入/抽取字段）与基准时刻 as_of_at（平台/调度器签发，调用输入带入并原样回传，不由 Agent 生成），经营明细一律过滤；Owner 与经理标识映射同为受控令牌。团队频道、Owner 与经理标识映射、平台/调度器签发的基准时刻 as_of_at 及值班频道作为调用输入提供；平台的访问凭据用 `` 占位，由 Agent 运行时从密钥引用。平台不可达或数据陈旧属于取数失败，走失败回执与升级，不当作"本期无活跃 OKR"。 - **回放集与基准**：取最近 8 周 OKR 平台快照（含已更新、未更新、无活跃目标样本）回放，人工基准答案为按更新状态整理的提醒名单；名单与基准一致率 100%。 - **提醒时效**：周会前未更新项 100% 被提醒到；从平台读取到提醒送达 Owner 的中位时间 < 15 分钟。 - **基准时刻口径**：as_of_at 100% 来自平台/调度器签发的调用输入并原样回传（不由 Agent 生成）；同一 as_of_at 与 last_updated_at 输入下，回传 stale_days 与 floor((as_of_at−last_updated_at)/一天) 的可回放一致率 100%（按 10% 抽样核对）。 - **Owner 字段**：调用输入提供 Owner 时 100% 原样带出；缺失时 100% 标"待确认"，不出现猜测的 Owner。 - **源头脱敏**：进入 Agent 消息、Run/Activation/Effect 记录与 App/Extension 工具日志的字段 100% 在白名单内（原值不进入以上任何一层），并按 10% 抽查四层实际记录；提醒与回执内容 100% 不含经营明细，只到信心指数档位。 - **结果可见**：有未更新、全部已更新、本期无活跃 OKR、取数失败、审批驳回失败结束五类结果 100% 各有可见回执，不出现静默成功。 - **审批把关**：提醒 100% 发生在负责人确认之后，驳回后 100% 退回重新提交；每次运行记录读取、确认与提醒时间戳。 ### 复用与变体 - **同构迁移**：战略举措双周对齐提醒、部门 KPI 月度填报提醒、预算执行填报提醒。 - **分级提醒**：连续两周未更新的项单独标注并抄送更高层负责人，在提示词里写明分层规则。 - **写回平台**：确认后再加一个 Agent 环节，由它通过 App/Extension 把"已提醒"标记写回 OKR 平台；写回须是获授权 Agent 经 App/Extension 的幂等动作（幂等键=目标代号+提醒周期），响应未知先查后写、按重试上限有限重试、失败升级值班并置"待处理"保留补偿，全程留审计。