工作流恢复协议Skill recovery

这个技能是一个工作流恢复协议,用于在上下文丢失、会话中断或错误发生后恢复工作流。它处理状态重建、工件恢复和继续执行,确保工作流无缝继续。关键词包括工作流恢复、中断处理、状态管理、错误恢复、DevOps、自动化流程。

DevOps 0 次安装 0 次浏览 更新于 3/10/2026

名称: 恢复 描述: 工作流恢复协议,用于在上下文丢失、会话中断或错误后恢复工作流。处理状态重建、工件恢复和无需中断的工作流继续。 版本: 1.0.0 模型: sonnet 调用者: both 用户可调用: true 工具: [Read, Write, Edit, Bash, Glob, Grep] 错误处理: 优雅 流式支持: 是 已验证: false 最后验证时间: 2026-02-19T05:29:09.098Z

恢复技能

<身份> 恢复技能 - 工作流恢复协议,用于在上下文丢失、会话中断或错误后恢复工作流。处理状态重建、工件恢复和无需中断的工作流继续。 </身份>

<能力>

  • 在上下文窗口耗尽后恢复工作流
  • 从会话中断中恢复
  • 从工件和门文件中重建工作流状态
  • 识别并继续最后一个完成的步骤
  • 防止恢复期间的重复工作 </能力>

<指令> <执行过程>

何时使用

  • 上下文窗口在工作流中途耗尽
  • 会话中断或丢失
  • 需要从最后一个完成的步骤恢复
  • 工作流状态需要重建

步骤 1: 识别最后一个完成的步骤

  1. 检查门文件以获取最后成功的验证:

    • 位置: .claude/context/history/gates/{workflow_id}/
    • 找到验证状态为“pass”的最高步骤号
    • 这是最后一个成功完成的步骤
  2. 回顾推理文件以获取进展:

    • 位置: .claude/context/history/reasoning/{workflow_id}/
    • 读取推理文件直至最后一个完成的步骤
    • 提取上下文和做出的决策
  3. 识别创建的工件

    • 检查工件注册表: .claude/context/artifacts/registry-{workflow_id}.json
    • 列出直至最后一步的所有工件
    • 验证工件文件是否存在

步骤 2: 加载计划文档

  1. 读取计划文档(无状态):

    • 从工件注册表加载 plan-{workflow_id}.json
    • 提取当前工作流状态
    • 识别已完成与待处理任务
  2. 加载相关阶段计划(如果多阶段):

    • 检查项目是否多阶段(超过 phase_size_max_lines 阈值)
    • 加载活动阶段计划: plan-{workflow_id}-phase-{n}.json
    • 理解阶段边界和依赖关系
  3. 理解当前状态

    • 映射已完成任务到计划
    • 识别后续步骤
    • 检查依赖关系

步骤 3: 上下文恢复

  1. 加载最后一个完成步骤的工件

    • 读取工件注册表
    • 加载所有验证状态为“pass”的工件
    • 验证工件完整性
  2. 读取推理文件以获取上下文

    • 加载已完成步骤的推理文件
    • 提取关键决策和上下文
    • 理解工作流进展
  3. 重建工作流状态

    • 结合计划、工件和推理
    • 创建恢复状态文档
    • 验证状态一致性

步骤 4: 恢复执行

  1. 从下一步继续

    • 识别最后一个完成后的下一步
    • 从计划加载步骤要求
    • 准备下一步输入
  2. 计划器更新计划状态(无状态):

    • 更新 plan-{workflow_id}.json 以反映当前状态
    • 标记已完成的步骤
    • 更新进度跟踪
  3. 协调器协调下一个代理

    • 传递恢复的工件到下一步
    • 恢复工作流执行
    • 监控额外中断

</执行过程>

失败分类

任务失败时,分类失败类型:

失败类型 指标 恢复行动
BROKEN_BUILD 构建错误、语法错误、模块未找到 ROLLBACK + 修复
VERIFICATION_FAILED 测试失败、验证错误、断言错误 重试修复(最多 3 次)
CIRCULAR_FIX 相同错误 3+ 次、类似方法重复 跳过或升级
CONTEXT_EXHAUSTED 令牌限制达到、最大长度超限 压缩上下文、继续
UNKNOWN 无模式匹配 重试一次,然后升级

循环修复检测

铁律:如果相同方法尝试 3+ 次未成功,则停止。

检测到循环修复时:

  1. 立即停止当前方法
  2. 记录尝试内容(方法、错误、文件)
  3. 尝试根本不同的方法(不同库、不同模式、更简单实现)
  4. 如果仍然失败,升级到人工干预

检测算法

  • 从当前方法提取关键词(排除停用词)
  • 与最近 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

假设中断:您的上下文可能会重置。如果不在内存中,则未发生。