## 每日任务状态日报 {.case data-case-id="010"} | 字段 | 值 | | --- | --- | | 案例编号 | `010` | | 行业 / 部门 | 互联网 / 项目管理 | | 角色 | 项目经理 | | 难度 | `入门` | | 调用来源 | `schedule`（定时由获授权 Agent 经 App/Extension 查询任务系统） | 项目经理每天花 30 分钟逐条追问"你做到哪了"再手写状态汇总，既低效又打扰团队。目标：定时让获授权 Agent 经 App/Extension 读取任务系统，把团队当天在岗成员的任务更新自动汇总成一份进度快报（谁在做什么、哪些完成了、哪些卡住了、在岗名单里谁没提交更新），经 PM 确认后发到管理频道。指标：从本次定时触发到管理频道收到快报的端到端中位数 < 5 分钟；汇总分类与 PM 既定基准一致率 ≥ 85%。 - **覆盖**：定时让获授权 Agent 读取任务系统，把在岗成员当天的任务更新汇总成快报，经 PM 确认后发到管理频道。 - **不覆盖**：自动催办延迟任务、多项目管理、工时统计、自动写回任务系统（见"复用与变体"）。 - **假设**：有一个经授权能经 App/Extension 读取任务系统的汇总 Agent；团队在岗名单由调用输入提供。 把下面这段发给 Loop，它会在后台帮你创建这个 Workflow： ```text 帮我创建一个 Workflow：定时让获授权的汇总 Agent 经 App/Extension 读取任务系统，把团队当天在岗成员的任务更新汇总成一份进度快报。App/Extension 在读取侧即完成聚合，Agent 只接收成员内部标识（受控令牌：权限受控且 Agent 无法反查原值）、任务状态与阻塞原因等白名单字段，不带出联系方式等个人字段。 触发：定时（计划）发起调用，调用时带入团队在岗名单的安全引用（令牌化）、管理频道、汇总 Agent 和审批人（PM）。 快报分三类列出：进行中（谁在做什么）、已完成、卡住（标出阻塞原因）；并标出在岗名单中当天未提交更新的成员。 审批：PM 确认后才发到管理频道，审批本身不设自动超时、无默认通过或否决；驳回则本次失败结束，要更正就修改输入后新开一次。 异常：任务系统不可达或数据陈旧视为查询失败，告警失败、留审计时间戳，按重试上限重试，仍失败则升级到值班频道；汇总 Agent 回传不合结构就停在等待点等其重新提交，不自动重跑；若全员无更新，仍出一份"本期全员无更新"的快报供 PM 确认，不静默结束；通知发送失败按重试上限重试，仍失败则升级到值班频道并保留待发内容供人工补发。 完成：快报发到管理频道并留时间戳后成功结束。 ``` ![案例 010 每日任务状态日报：定时触发让获授权 Agent 读任务系统汇总成快报；回传不合结构停在原等待点，查询失败留审计并重试升级；PM 确认后发管理频道并成功结束，驳回则失败结束](../../../media/cases/fig-case-010-01-flow.svg){#fig-case-010-01 width=92%} 如上图所示，正常路径、人工决策与异常同时可见： 1. **定时触发**：计划到点发起一次调用，带入团队在岗名单安全引用（令牌化）、管理频道、汇总 Agent 与审批人（PM）。 2. **汇总**：获授权 Agent 经 App/Extension 读取任务系统，按"进行中/已完成/卡住"分类并标出在岗名单中未更新的成员；回传结构不合要求时停在原等待点，等其修正后重新提交，不自动重跑。 3. **PM 确认**：PM 看到快报，确认继续或驳回。 4. **通知**：确认后把快报发到管理频道并留审计时间戳。 5. **结束**：通知发出即成功；PM 驳回则失败结束、不发快报，要更正就修改输入、新开一次；任务系统不可达或数据陈旧则查询失败、留审计并按重试上限重试，仍失败则升级到值班频道。 你不需要手写代码或配置。把上面的提示词发给 Loop，AI 会理解意图、在后台画出这个"定时查询 + 人工确认 + 通知"流程——它知道"读任务系统汇总"需要一个发消息并等待回调的 Agent 环节、"PM 把关"需要一个审批环节、"发管理频道"需要一个发消息环节，并把它们连起来。AI 还会在后台校验流程结构是否完整（每个环节的输入是否都连好），你不必关心这些技术细节。 - **任务系统不可达或数据陈旧**：视为查询失败，不落入"全员无更新"或静默结束，而是告警失败、留审计时间戳，按重试上限重试；仍失败则升级到值班频道由人工确认。 - **全员无更新（结果为 0）**：仍出一份标注"本期全员无更新"的快报供 PM 确认，确认后发到管理频道；PM 也可驳回并修改输入后重发，让"没消息"变成可核验的记录，而不是无声结束。 - **汇总 Agent 回传不合结构**：本次完成请求被拒绝，流程停在等待点等 Agent 修正后重新提交，不会反复重跑，也不会发出错误快报。 - **PM 驳回**：本次失败结束、不发快报；要更正就修改输入、新开一次调用。 - **通知发送失败**：按重试上限重试投递；超过上限则升级，并保留待发内容供人工补发。 - **长时间无人审批**：审批本身不设自动超时，流程会停在等待状态。若业务需要响应时限，这是运营策略：由另一条定时检查的 Workflow（或值班人员）扫出超过时限的待审批项并通知 PM，而不是依赖本流程自动升级。 每份快报都必须经 PM 确认后才发管理频道，确保管理层收到的是准确的状态汇总，AI 只做初稿、PM 把质量关。审批只有确认或驳回两种结果，驳回即本次失败，没有"AI 自动改"。全员无更新的快报同样要确认，确认后才是可见回执。若要更严（如卡住项超阈值需双审），在提示词里写明，AI 会在流程里多加一个审批环节。 本工作流的任务更新由获授权 Agent 通过 App/Extension 从任务系统读取，工作流本身不直接调用外部系统。团队在岗名单、管理频道、汇总 Agent 与审批人由定时调用带入——在岗名单决定了"谁能被标未更新"。任务系统的访问凭据用 `` 占位，由 Agent 运行时从密钥引用。进入 Agent 消息、Run/Activation/Effect 记录与 App/Extension 工具日志的字段以白名单为准（仅令牌化/白名单字段，原值不进入以上任何一层），可回溯个人的字段（姓名/邮箱/证件/联系方式等）在源头即被令牌化/伪名化，并按 10% 抽查四层实际记录。任务系统不可达或数据陈旧属于查询失败，走上面的失败回执与升级，不当作"全员无更新"。 - **回放集与基准**：取最近 20 个工作日的真实任务更新回放（各日均附在岗名单），人工基准答案为 PM 既定分类（进行中/已完成/卡住、未更新成员）；汇总分类与基准一致率 ≥ 85% 视为通过。 - **分母与口径**：一致率分母为回放快报中的成员条目总数；每次回放记录生成与发送时间戳。 - **结果可见**：正常快报、全员无更新快报、查询失败三类结果 100% 各有可见回执，不出现静默成功。 - **人工确认**：每份快报 100% 经 PM 确认后才发管理频道。 - **时效**：从本次定时触发到管理频道收到快报的端到端中位数 < 5 分钟。 - **源头脱敏**：进入 Agent 消息、Run/Activation/Effect 记录与 App/Extension 工具日志的字段 100% 在白名单内（仅令牌化/白名单字段，原值不进入以上任何一层），并按 10% 抽查四层实际记录。 ### 复用与变体 - **同构迁移**：周度进展简报、跨团队协调日报、冲刺回顾数据准备。 - **写回与催办**：在通知后再加一个 Agent 环节：提醒走 Loop 消息即可；若要把"需帮助"的卡住项写回任务系统，由获授权 Agent 经 App/Extension 写入可信的任务系统（仅卡住状态这一业务维度），以任务编号为稳定幂等键、响应未知先查后写，配有限重试、升级、待处理与审计。