名称: 恢复 描述: 工作流恢复协议,用于在上下文丢失、会话中断或错误后恢复工作流。处理状态重建、工件恢复和无需中断的工作流继续。 版本: 1.0.0 模型: sonnet 调用者: both 用户可调用: true 工具: [Read, Write, Edit, Bash, Glob, Grep] 错误处理: 优雅 流式支持: 是 已验证: false 最后验证时间: 2026-02-19T05:29:09.098Z
恢复技能
<身份> 恢复技能 - 工作流恢复协议,用于在上下文丢失、会话中断或错误后恢复工作流。处理状态重建、工件恢复和无需中断的工作流继续。 </身份>
<能力>
- 在上下文窗口耗尽后恢复工作流
- 从会话中断中恢复
- 从工件和门文件中重建工作流状态
- 识别并继续最后一个完成的步骤
- 防止恢复期间的重复工作 </能力>
<指令> <执行过程>
何时使用
- 上下文窗口在工作流中途耗尽
- 会话中断或丢失
- 需要从最后一个完成的步骤恢复
- 工作流状态需要重建
步骤 1: 识别最后一个完成的步骤
-
检查门文件以获取最后成功的验证:
- 位置:
.claude/context/history/gates/{workflow_id}/ - 找到验证状态为“pass”的最高步骤号
- 这是最后一个成功完成的步骤
- 位置:
-
回顾推理文件以获取进展:
- 位置:
.claude/context/history/reasoning/{workflow_id}/ - 读取推理文件直至最后一个完成的步骤
- 提取上下文和做出的决策
- 位置:
-
识别创建的工件:
- 检查工件注册表:
.claude/context/artifacts/registry-{workflow_id}.json - 列出直至最后一步的所有工件
- 验证工件文件是否存在
- 检查工件注册表:
步骤 2: 加载计划文档
-
读取计划文档(无状态):
- 从工件注册表加载
plan-{workflow_id}.json - 提取当前工作流状态
- 识别已完成与待处理任务
- 从工件注册表加载
-
加载相关阶段计划(如果多阶段):
- 检查项目是否多阶段(超过 phase_size_max_lines 阈值)
- 加载活动阶段计划:
plan-{workflow_id}-phase-{n}.json - 理解阶段边界和依赖关系
-
理解当前状态:
- 映射已完成任务到计划
- 识别后续步骤
- 检查依赖关系
步骤 3: 上下文恢复
-
加载最后一个完成步骤的工件:
- 读取工件注册表
- 加载所有验证状态为“pass”的工件
- 验证工件完整性
-
读取推理文件以获取上下文:
- 加载已完成步骤的推理文件
- 提取关键决策和上下文
- 理解工作流进展
-
重建工作流状态:
- 结合计划、工件和推理
- 创建恢复状态文档
- 验证状态一致性
步骤 4: 恢复执行
-
从下一步继续:
- 识别最后一个完成后的下一步
- 从计划加载步骤要求
- 准备下一步输入
-
计划器更新计划状态(无状态):
- 更新 plan-{workflow_id}.json 以反映当前状态
- 标记已完成的步骤
- 更新进度跟踪
-
协调器协调下一个代理:
- 传递恢复的工件到下一步
- 恢复工作流执行
- 监控额外中断
</执行过程>
失败分类
任务失败时,分类失败类型:
| 失败类型 | 指标 | 恢复行动 |
|---|---|---|
| BROKEN_BUILD | 构建错误、语法错误、模块未找到 | ROLLBACK + 修复 |
| VERIFICATION_FAILED | 测试失败、验证错误、断言错误 | 重试修复(最多 3 次) |
| CIRCULAR_FIX | 相同错误 3+ 次、类似方法重复 | 跳过或升级 |
| CONTEXT_EXHAUSTED | 令牌限制达到、最大长度超限 | 压缩上下文、继续 |
| UNKNOWN | 无模式匹配 | 重试一次,然后升级 |
循环修复检测
铁律:如果相同方法尝试 3+ 次未成功,则停止。
检测到循环修复时:
- 立即停止当前方法
- 记录尝试内容(方法、错误、文件)
- 尝试根本不同的方法(不同库、不同模式、更简单实现)
- 如果仍然失败,升级到人工干预
检测算法:
- 从当前方法提取关键词(排除停用词)
- 与最近 3 次尝试的关键词比较
- 如果 Jaccard 相似度 > 30% 对于 2+ 次尝试,标记为循环
示例:
尝试 1: "使用异步等待获取数据"
尝试 2: "使用异步/等待与 try-catch"
尝试 3: "再次尝试异步等待模式"
=> 检测到循环修复 - 停止并尝试回调模式
尝试次数阈值
| 失败类型 | 最大尝试次数 | 然后行动 |
|---|---|---|
| VERIFICATION_FAILED | 3 | 跳过 + 升级 |
| UNKNOWN | 2 | 升级 |
| BROKEN_BUILD | 1 | 回滚(如果有良好提交) |
| CIRCULAR_FIX | 0 | 立即跳过 |
参考
参见 references/ 以获取详细模式:
failure-types.md- 失败分类详情和指标recovery-actions.md- 恢复行动决策树和执行merge-strategies.md- 多代理场景的文件合并策略
<最佳实践>
恢复验证清单
- [ ] 最后一个完成的步骤正确识别
- [ ] 计划文档加载并验证
- [ ] 已完成步骤的所有工件可用
- [ ] 推理文件已回顾以获取上下文
- [ ] 工作流状态准确重建
- [ ] 不会执行重复工作
- [ ] 下一步输入已准备
- [ ] 恢复已记录在推理文件
</最佳实践>
<错误处理>
错误处理
- 缺失计划文档:请求计划器从需求重新创建计划
- 缺失工件:请求源代理重新创建工件
- 损坏工件:请求带验证的工件重新创建
- 不完整推理:使用工件注册表和门文件重建状态
</错误处理> </指令>
<示例> <使用示例> 上下文丢失后恢复:
# 1. 检查门文件以获取最后一个完成的步骤
ls .claude/context/history/gates/{workflow_id}/
# 2. 加载计划文档
cat .claude/context/artifacts/plan-{workflow_id}.json
# 3. 回顾推理文件
cat .claude/context/history/reasoning/{workflow_id}/*.json
# 4. 从下一步恢复
</使用示例>
<使用示例> 自然语言调用:
"从我们中断的地方恢复工作流"
"恢复工作流状态并继续"
"最后一个完成的步骤是什么?"
</使用示例> </示例>
相关
- 计划代理:
.claude/agents/core/planner.md - 内存文件:
.claude/context/memory/
内存协议(强制)
开始前:
cat .claude/context/memory/learnings.md
完成后:
- 新模式 ->
.claude/context/memory/learnings.md - 发现问题 ->
.claude/context/memory/issues.md - 决策 ->
.claude/context/memory/decisions.md
假设中断:您的上下文可能会重置。如果不在内存中,则未发生。