审批一直没人处理，Workflow 怎么做超时升级？

内容上线前需要负责人确认，流程已经发出提醒，但两天后仍没有结果。继续发送同样的消息，只会制造更多通知；直接跳过审批，又会让风险落到执行人员身上。

超时升级（Timeout Escalation）需要定义等待状态何时结束，单纯"多催几次"解决不了停滞。流程需要知道任务从什么时候开始等待、谁正在处理、提醒过几次、超过哪个阈值后交给谁。每次动作都写入状态，后续节点才能判断该继续等待、升级还是终止。

在 ZGI 的 Agent Runtime 中，可以用 Workflow 组织状态、条件、技能和通知工具，让模型只负责整理审批材料或生成提醒草稿。截止时间、升级路径和最终决定应由业务规则控制，不能交给模型临时判断。

一篇帮助文档准备上线，需要产品负责人确认事实、运营负责人确认表述。流程可以设置一个主负责人和一个备用处理人，并规定 24 小时提醒、48 小时升级。具体配置如下：

流程至少需要 started_at、deadline_at、owner、backup_owner、reminder_count 和 status。时间比较应使用固定时区和统一格式，避免跨地区团队在日期边界上重复触发。通知工具执行前先检查任务状态，已经完成的任务不再提醒。

每次通知还要带幂等键，可以由任务 ID、提醒阶段和日期组成。同一阶段再次触发时，先查询是否已有发送回执。升级动作同样要保存记录，避免两个定时检查同时把任务转给不同负责人。

提醒内容只放完成决策所需的信息：任务链接、待确认项、截止时间和可选动作。长背景由知识或附件承载，不把整篇材料塞进消息。涉及对外发布、数据权限或不可逆操作时，最大等待时间到达后应暂停，不允许自动通过。

上线前用几组脱敏样例覆盖按时批准、按时拒绝、首次超时、重复触发、负责人缺失和最终暂停。检查每次运行的状态、提醒次数、升级对象和发送回执是否一致。如果任务完成后仍收到提醒，先检查状态更新顺序；如果同一提醒出现两次，检查幂等键和定时任务并发。

这个方法适合内容审批、资料确认、内部工单和需要人工把关的任务。没有明确负责人或升级关系的流程，先补齐组织规则，再配置自动化。Workflow 可以稳定执行规则，却不能替团队决定谁为超时任务负责。