多轮/多代理长任务需要持久状态与可靠恢复时…

当任务跨多轮、多会话、需交接给子代理或后台作业、或中断后必须可靠恢复时，用持久状态文件协调执行。

适用场景

解决思路

1. 为每个真正的长任务维护唯一一份持久状态文件，聊天历史不可作为可靠状态存储；状态文件至少记录：目标、成功标准、当前状态、当前步骤、已完成工作、下一步动作、下一个检查点、阻塞项、当前负责人或执行者。
2. 仅在需要时拆分角色，使用适配任务的最小角色模型：Origin 负责目标与验收标准，Coordinator 负责状态、排序与恢复，Worker 执行有界子工作，Watchdog 只检查存活与恢复；简单任务可合并为一个代理，长任务或委派任务应显式拆分。
3. 每一轮协调都按固定顺序执行：READ -> RECOVER -> DECIDE -> PERSIST -> REPORT -> END；在状态文件更新之前不得报告结论。
4. 把 awaiting-result 视为合法状态：只要 worker 或后台作业已成功派发，结果未返回并不代表任务失败；合法状态转换包括 running -> awaiting-result、awaiting-result -> running、running -> paused、running -> complete。
5. 非终态轮次必须产生真实进展，至少满足其一：派发有界工作、消费新结果、更新当前阶段或决策、持久化新的下一步或检查点、执行显式恢复；若什么都没变，不要假装任务已推进。
6. 把恢复与领域工作分开：恢复回答执行是否偏离已保存状态、预期 worker 结果是否仍待返回、是否需要等待/重试/重新派发；领域工作回答下一步该构建、分析或交付什么；先恢复，再继续领域工作。
7. 判断任务是否需要协调：当任务将超出当前轮次、将交接给其他执行单元、需要检查点/轮询/定时跟进、或状态丢失代价足够高时，使用本技能。
8. 创建或加载状态文件，优先使用易于重新发现的路径，如 docs/<topic>-execution-plan.md、docs/<topic>-state.md、worklog/<topic>-state.md；若尚无持久状态，按 references/workflow.md 创建。
9. 每轮开始时先恢复再行动：读取状态文件、检查记录的下一步是否仍然合理、确认是否有委派工作返回、在采取新动作前修复过时假设。
10. 先持久化再报告：决定下一步动作后，先更新状态文件，记录新状态、负责人、阻塞项与检查点，然后再向用户或调用方报告进展。
11. 诚实地结束每一轮，以 running、awaiting-result、paused、blocked、complete 之一收尾；报告的状态必须与持久化的状态完全一致。
12. 输出更新必须基于已保存状态：当前任务处于什么状态、本轮发生了什么变化、接下来预期什么、什么能解除阻塞或完成任务。
13. 验收标准：可预测路径下存在持久状态文件、保存状态与真实任务状态一致、已完成工作/下一步动作/阻塞项被显式记录、任何委派工作都有具名负责人与返回条件、最终报告源自持久化状态而非临时推理；若任务未真正完成，以 running、awaiting-result、paused 或 blocked 收尾，不要假装完成。

适用边界 · 注意事项

• 小型、单轮任务不要使用本技能。
• 当简单规划已足够、恢复逻辑不是主要关注点时，改用 planning-with-files。
• 不要从记忆重建进展、不要在保存前报告结论、不要把等待标记为失败、不要以无新动作且无状态变化结束一轮、不要在同一步中混淆恢复检查与领域决策。