RuFlo Self-Healing 工作流实战基于 Claude Code Hooks 的自动化错误检测、自愈恢复与失败经验沉淀【免费下载链接】ruflo The original agent meta-harness. Deploy intelligent multi-player swarms, coordinate autonomous workflows, and build conversational AI systems. Features adaptive memory, self-learning intelligence, RAG integration, and native Claude Code / Codex / Hermes and many more Integrated项目地址: https://gitcode.com/GitHub_Trending/cl/ruflo本文以仓库根目录下 Claude Code 命令文档 .claude/commands/automation/self-healing.md 为核心蓝本结合 RuFlo / claude-flow 的 Hooks 自动化体系.claude/commands/hooks/overview.md、MCP 工具协调规范与记忆/神经模式训练能力系统讲解如何为开发流程构建出错即检测、检测即修复、修复即沉淀的自愈闭环。读完本文你将掌握自愈系统监测的四大错误类别、缺依赖/语法错误/测试失败三类典型故障的自动恢复路径、如何把失败模式写入知识库并驱动神经模式分析以及如何通过PostToolUseHook 配置与mcp__claude-flow__*系列工具完成多 Agent 自愈编排。1. 自愈工作流是什么让 Agent 流程不再被错误打断在 Agent 驱动的开发管线中任意一个环节失败——命令退出码非零、代码语法错误、依赖缺失、测试用例挂掉——都可能中断整条自动化流把控制权交还给人类。RuFlo 仓库内定义的 Self-Healing自愈模式见 self-healing.md给出的思路是把错误检测、恢复决策、修复执行与经验回写全部交给系统自动完成从而保证detect and recover from errors without interrupting your flow。其运行载体是 Claude Code 的 Hooks 机制Hook 在工具调用前后自动触发配合 claude-flow 的 MCP 服务器暴露的 swarm / memory / neural 工具形成一条完整的检测—恢复—学习链路。从源码结构看仓库当前的 Hooks 事件被路由到本地 helper 脚本统一分发例如.claude/settings.jsonsettings.json中Bash工具的PreToolUse触发hook-handler.cjs pre-bash、Write|Edit|MultiEdit的PostToolUse触发hook-handler.cjs post-edit、Stop事件触发记忆同步——这意味着自愈能力并不是孤立的命令而是被挂在每个真实开发事件上的守卫。2. 第一环错误检测覆盖哪四类故障自愈流程的第一阶段是探测。原文档列出的监测范围如下错误类别典型信号说明失败的命令Failed commandsBash 工具返回非零exitCode由PostToolUse中匹配Bash的 Hook 捕获语法错误Syntax errors解析器报 Unexpected token 等依赖错误定位与修复建议缺失依赖Missing dependenciesCannot find module xxx需要包管理器介入自动补齐损坏的测试Broken tests测试断言失败需要 debugger 类 Agent 定位并修复从检测能力的实现侧看post-bash类 Hook 专门负责记录执行、更新指标、存储结果、检测错误模式见 hooks-automation 技能文档 .claude/skills/hooks-automation/SKILL.md。也就是说命令执行本身已经携带了自我审计能力日志被记录、结果被落库失败特征随之进入错误模式库为后续的自动恢复提供判断依据。在实际部署中检测 Hook 应挂在PreToolUse/PostToolUse等高频事件上仓库自带配置将其挂在 Bash、Write/Edit、Session 生命周期等多个事件上保证覆盖面。3. 第二环三类典型故障的自动恢复路径检测到错误之后自愈系统依据错误类型选择恢复策略。原文档给出了三个标准化的恢复路径模板均遵循修复→确认→重试原命令的闭环。3.1 缺失依赖自动安装并重试Error: Cannot find module express → Automatically runs: npm install express → Retries original command这是最机械、也最安全的一类恢复当错误模式匹配到Cannot find module时系统直接推断缺失的包名执行安装命令npm install pkg随后自动重试原始命令。它的可行性来自错误消息本身就是结构化信息——模块名可以直接从报错中提取无需额外的语义猜测。3.2 语法错误定位 → 分析 → 确认后修复Error: Unexpected token → Analyzes error location → Suggests fix through analyzer agent → Applies fix with confirmation与依赖缺失不同语法错误的修复会改变源码因此流程加入了分析 Agent 给出修复建议 人工/主 Agent 确认后再应用的安全闸门。其中analyzer agent对应 RuFlo 仓库中的分析型 Agent 命令族例如 .claude/commands/sparc/analyzer.md 所描述的分析角色——自愈流程可以委派这类专门 Agent 去理解错误上下文、产出最小修复补丁再决定是否落盘。该路径的价值在于诊断与执行分离避免修复动作本身引入新的破坏。3.3 测试失败派发调试 Agent 完成分析、修复与复跑Test failed: user authentication → Spawns debugger agent → Analyzes failure cause → Implements fix → Re-runs tests测试失败的自愈是最复杂的场景因为它往往不是单点语法问题而是行为不符合预期。原文档的路径是按需派生spawn一个 debugger agent由其完成分析失败原因 → 实现修复 → 重新运行测试的完整子任务直到测试通过才把控制权交还主流程。这与仓库中命令文档反复出现的派生式协作模式如mcp__claude-flow__agent_spawn调用一致主 Agent 只负责编排实际诊断与修复下沉到被派生出的子 Agent。4. 第三环从失败中学习——错误模式的存储与分析自愈系统区别于普通重试机制的核心在于每一次恢复都会反哺未来的预防。原文档明确列出三点收益失败模式被保存进知识库、相似错误被主动预防、恢复策略不断被优化。4.1 用 memory_usage 持久化错误模式错误发生时系统把结构化错误数据写入带命名空间与 TTL 的记忆存储// Store error patterns mcp__claude-flow__memory_usage({ action: store, key: error-pattern- Date.now(), value: JSON.stringify(errorData), namespace: error-patterns, ttl: 2592000 // 30 days }) // Analyze patterns mcp__claude-flow__neural_patterns({ action: analyze, operation: error-recovery, outcome: success })这里有几个值得注意的设计细节命名空间隔离错误模式被写入独立的error-patternsnamespace与日常任务记忆、会话记忆隔离开避免噪声污染正常的记忆检索仓库内多数协作型记忆写入都使用coordination等专属 namespace逻辑与此一致。TTL 策略模式条目设置 30 天有效期ttl: 2592000保证记忆库只保留近期活跃的失败经验过期数据自动淘汰防止无界增长。key 的单调性error-pattern- Date.now()确保每次错误都作为独立条目落库可追溯、可回放。4.2 用 neural_patterns 分析恢复效果第二段调用neural_patterns的analyze动作把一次operationerror-recovery、outcomesuccess的恢复事件送入神经模式分析。可以理解为成功恢复的错误模式会被标记为正样本供训练/调优环节使用从而让系统学习哪些策略对哪类错误有效。这一机制与仓库中trainPatternsOnComplete一类配置见 settings.json背后的理念相同完成即学习经验流向集中式的模式训练与跨会话记忆。配合 .claude/commands/automation/session-memory.md 这类会话记忆命令错误模式还能在会话重启后继续生效实现跨会话的不二过。5. MCP 工具协调用 Swarm 编排一次自愈任务当单 Agent 的自我修复不足以应对复杂故障时自愈流程会升级为多 Agent 编排。原文档给出的 MCP 调用序列展示了一套标准的初始化 swarm → 派生监控 Agent → 编排恢复任务流程// Initialize self-healing swarm mcp__claude-flow__swarm_init({ topology: star, maxAgents: 4, strategy: adaptive }) // Spawn recovery agents mcp__claude-flow__agent_spawn({ type: monitor, name: Error Monitor, capabilities: [error-detection, recovery] }) // Orchestrate recovery mcp__claude-flow__task_orchestrate({ task: recover from error, strategy: sequential, priority: critical })逐参数解读这套编排的语义swarm_init先建立一个专门服务于自愈的 Agent 群体。topology: star表示以单一协调者为中心的星型拓扑适合任务分发集中、子 Agent 平级的恢复场景maxAgents: 4限制并发 Agent 数避免故障风暴下无节制扩增strategy: adaptive表示恢复策略可根据错误类型动态切换。仓库的真实 swarm 配置同样支持拓扑与容量声明例如 settings.json 中的swarm.topology与swarm.maxAgents字段二者结构相互印证。agent_spawn派生一个常驻型monitorAgentError Monitor其能力清单capabilities显式声明了error-detection与recovery——这既是对该 Agent 的能力约束也是调度器分配任务时的依据。task_orchestrate把从错误中恢复作为一个关键优先级的整体任务采用串行策略strategy: sequential下发给 swarm。串行而非并行是为了让修复步骤之间保持因果顺序先装依赖、再修语法、最后跑测试避免并发修复互相踩踏。需要说明的是mcp__claude-flow__*是 claude-flow MCP 服务器暴露给 Claude Code 的命名前缀工具。RuFlo 仓库大量命令文档都以该前缀调用 swarm 与记忆类工具例如 memory 写入、swarm 状态查询等均以相同调用范式出现可确认这套工具协调语法是仓库内跨命令文件通用的标准调用方式。6. Fallback Hook把自愈挂在 Bash 命令的失败出口上要让上述编排真正随命令失败而触发需要把自愈逻辑挂在 Claude Code 的 Hook 事件上。原文档给出的最简配置是一个兜底fallback形式的PostToolUseHook一旦 Bash 工具执行完毕即检查退出码非零则进入自动恢复{ PostToolUse: [{ matcher: ^Bash$, command: npx claude-flow hook post-bash --exit-code ${tool.result.exitCode} --auto-recover }] }配置语义拆解事件与匹配PostToolUse 正则matcher: ^Bash$精确命中 Bash 工具的调用结果Write/Edit等非命令类工具不受影响。退出码注入${tool.result.exitCode}是 Claude Code 注入的模板变量把本次命令的真实退出码传给post-bashHook——自愈判定的第一步就是exitCode 是否为 0。自动恢复开关--auto-recover显式开启恢复动作不带该参数时 Hook 只做记录logging/metrics这为仅观察、不自动动手的保守模式留了余地。需要注意Claude Code 的 Hook 配置存在两种书写形态。仓库当前生效的 .claude/settings.json 使用的是嵌套hooks数组的新式结构type: command 超时等字段其 Bash 相关的PreToolUse配置为{ PreToolUse: [ { matcher: Bash, hooks: [ { type: command, command: node \$CLAUDE_PROJECT_DIR/.claude/helpers/hook-handler.cjs\ pre-bash, timeout: 5000 } ] } ] }两种形态可类比理解简化形态适合快速试验npx claude-flow全局 CLI 的自愈命令完整形态hooks-automation 技能文档中 SKILL.md 亦给出全套 Pre/Post/Session Hook 的完整 schema适合正式工程配置可叠加timeout、continueOnError、async等执行控制字段。仓库已落地的 hook-handler 分发架构一个统一 handler 按事件名路由到pre-bash/post-edit/session-end/post-task等处理器正是把上述能力集中管理的最佳实践你只需在 matcher 上登记事件逻辑处理都在 handler 内收敛。6.1 组合成一条完整的自愈 Hook 链把原文档的 fallback 思想扩展为覆盖全生命周期的可用配置兼容嵌套形态可按如下模式组织{ hooks: { PreToolUse: [ { matcher: Bash, hooks: [{ type: command, command: npx claude-flow hook pre-bash --command ${tool.params.command} --check-safety }] } ], PostToolUse: [ { matcher: ^Bash$, hooks: [{ type: command, command: npx claude-flow hook post-bash --command ${tool.params.command} --exit-code ${tool.result.exitCode} --auto-recover --update-metrics --store-result }] } ] } }pre-bash在命令执行前做安全检查危险命令拦截、资源预估可参考 SKILL.md 中的--check-safety等参数post-bash在命令执行后同时承担**检测exitCode、恢复--auto-recover、度量--update-metrics、沉淀--store-result**四重职责正是本文第 2、3、4 章所述三环合一的落点。7. 收益与落地建议原文档最后以四点概括自愈体系的业务价值️ 弹性工作流Resilient workflows——故障被就地消化而非打断整条流水线 自动恢复Automatic recovery——依赖安装、语法修复、测试复跑无需人工介入 从错误中学习Learns from errors——每个失败都是知识库的新样本与策略调优的输入⏱️ 节省调试时间Saves debugging time——人只需介入策略层而非逐条排查。落地到 RuFlo 仓库环境的实践建议从观察模式起步先只启用post-bash的记录与错误模式落库不开--auto-recover运行一段时间积累真实的error-patterns语料再逐步放开自动恢复降低误修复风险。按错误类型分级授权依赖缺失可完全自动语法错误保留确认闸门沿用原文档的 Applies fix with confirmation测试失败则委派独立 debugger Agent 并设定重试上限防止无限修复循环。让经验流向下游确保neural_patterns的 analyze 调用随成功恢复发生并把error-patternsnamespace 纳入会话记忆的恢复范围参考 session-memory.md实现跨会话预防。沉淀为可复用命令可将本文梳理的恢复路径整理为自动化命令如 .claude/commands/automation/ 目录下的命令一样让自愈逻辑不仅挂在 Hook 上也可按需手动触发。完整的原命令定义与配套 Hook 文档可在仓库内进一步查阅self-healing.md、Hooks 总览、Hooks 配置技能 以及生效中的 settings.json。【免费下载链接】ruflo The original agent meta-harness. Deploy intelligent multi-player swarms, coordinate autonomous workflows, and build conversational AI systems. Features adaptive memory, self-learning intelligence, RAG integration, and native Claude Code / Codex / Hermes and many more Integrated项目地址: https://gitcode.com/GitHub_Trending/cl/ruflo创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考
RuFlo Self-Healing 工作流实战：基于 Claude Code Hooks 的自动化错误检测、自愈恢复与失败经验沉淀
RuFlo Self-Healing 工作流实战基于 Claude Code Hooks 的自动化错误检测、自愈恢复与失败经验沉淀【免费下载链接】ruflo The original agent meta-harness. Deploy intelligent multi-player swarms, coordinate autonomous workflows, and build conversational AI systems. Features adaptive memory, self-learning intelligence, RAG integration, and native Claude Code / Codex / Hermes and many more Integrated项目地址: https://gitcode.com/GitHub_Trending/cl/ruflo本文以仓库根目录下 Claude Code 命令文档 .claude/commands/automation/self-healing.md 为核心蓝本结合 RuFlo / claude-flow 的 Hooks 自动化体系.claude/commands/hooks/overview.md、MCP 工具协调规范与记忆/神经模式训练能力系统讲解如何为开发流程构建出错即检测、检测即修复、修复即沉淀的自愈闭环。读完本文你将掌握自愈系统监测的四大错误类别、缺依赖/语法错误/测试失败三类典型故障的自动恢复路径、如何把失败模式写入知识库并驱动神经模式分析以及如何通过PostToolUseHook 配置与mcp__claude-flow__*系列工具完成多 Agent 自愈编排。1. 自愈工作流是什么让 Agent 流程不再被错误打断在 Agent 驱动的开发管线中任意一个环节失败——命令退出码非零、代码语法错误、依赖缺失、测试用例挂掉——都可能中断整条自动化流把控制权交还给人类。RuFlo 仓库内定义的 Self-Healing自愈模式见 self-healing.md给出的思路是把错误检测、恢复决策、修复执行与经验回写全部交给系统自动完成从而保证detect and recover from errors without interrupting your flow。其运行载体是 Claude Code 的 Hooks 机制Hook 在工具调用前后自动触发配合 claude-flow 的 MCP 服务器暴露的 swarm / memory / neural 工具形成一条完整的检测—恢复—学习链路。从源码结构看仓库当前的 Hooks 事件被路由到本地 helper 脚本统一分发例如.claude/settings.jsonsettings.json中Bash工具的PreToolUse触发hook-handler.cjs pre-bash、Write|Edit|MultiEdit的PostToolUse触发hook-handler.cjs post-edit、Stop事件触发记忆同步——这意味着自愈能力并不是孤立的命令而是被挂在每个真实开发事件上的守卫。2. 第一环错误检测覆盖哪四类故障自愈流程的第一阶段是探测。原文档列出的监测范围如下错误类别典型信号说明失败的命令Failed commandsBash 工具返回非零exitCode由PostToolUse中匹配Bash的 Hook 捕获语法错误Syntax errors解析器报 Unexpected token 等依赖错误定位与修复建议缺失依赖Missing dependenciesCannot find module xxx需要包管理器介入自动补齐损坏的测试Broken tests测试断言失败需要 debugger 类 Agent 定位并修复从检测能力的实现侧看post-bash类 Hook 专门负责记录执行、更新指标、存储结果、检测错误模式见 hooks-automation 技能文档 .claude/skills/hooks-automation/SKILL.md。也就是说命令执行本身已经携带了自我审计能力日志被记录、结果被落库失败特征随之进入错误模式库为后续的自动恢复提供判断依据。在实际部署中检测 Hook 应挂在PreToolUse/PostToolUse等高频事件上仓库自带配置将其挂在 Bash、Write/Edit、Session 生命周期等多个事件上保证覆盖面。3. 第二环三类典型故障的自动恢复路径检测到错误之后自愈系统依据错误类型选择恢复策略。原文档给出了三个标准化的恢复路径模板均遵循修复→确认→重试原命令的闭环。3.1 缺失依赖自动安装并重试Error: Cannot find module express → Automatically runs: npm install express → Retries original command这是最机械、也最安全的一类恢复当错误模式匹配到Cannot find module时系统直接推断缺失的包名执行安装命令npm install pkg随后自动重试原始命令。它的可行性来自错误消息本身就是结构化信息——模块名可以直接从报错中提取无需额外的语义猜测。3.2 语法错误定位 → 分析 → 确认后修复Error: Unexpected token → Analyzes error location → Suggests fix through analyzer agent → Applies fix with confirmation与依赖缺失不同语法错误的修复会改变源码因此流程加入了分析 Agent 给出修复建议 人工/主 Agent 确认后再应用的安全闸门。其中analyzer agent对应 RuFlo 仓库中的分析型 Agent 命令族例如 .claude/commands/sparc/analyzer.md 所描述的分析角色——自愈流程可以委派这类专门 Agent 去理解错误上下文、产出最小修复补丁再决定是否落盘。该路径的价值在于诊断与执行分离避免修复动作本身引入新的破坏。3.3 测试失败派发调试 Agent 完成分析、修复与复跑Test failed: user authentication → Spawns debugger agent → Analyzes failure cause → Implements fix → Re-runs tests测试失败的自愈是最复杂的场景因为它往往不是单点语法问题而是行为不符合预期。原文档的路径是按需派生spawn一个 debugger agent由其完成分析失败原因 → 实现修复 → 重新运行测试的完整子任务直到测试通过才把控制权交还主流程。这与仓库中命令文档反复出现的派生式协作模式如mcp__claude-flow__agent_spawn调用一致主 Agent 只负责编排实际诊断与修复下沉到被派生出的子 Agent。4. 第三环从失败中学习——错误模式的存储与分析自愈系统区别于普通重试机制的核心在于每一次恢复都会反哺未来的预防。原文档明确列出三点收益失败模式被保存进知识库、相似错误被主动预防、恢复策略不断被优化。4.1 用 memory_usage 持久化错误模式错误发生时系统把结构化错误数据写入带命名空间与 TTL 的记忆存储// Store error patterns mcp__claude-flow__memory_usage({ action: store, key: error-pattern- Date.now(), value: JSON.stringify(errorData), namespace: error-patterns, ttl: 2592000 // 30 days }) // Analyze patterns mcp__claude-flow__neural_patterns({ action: analyze, operation: error-recovery, outcome: success })这里有几个值得注意的设计细节命名空间隔离错误模式被写入独立的error-patternsnamespace与日常任务记忆、会话记忆隔离开避免噪声污染正常的记忆检索仓库内多数协作型记忆写入都使用coordination等专属 namespace逻辑与此一致。TTL 策略模式条目设置 30 天有效期ttl: 2592000保证记忆库只保留近期活跃的失败经验过期数据自动淘汰防止无界增长。key 的单调性error-pattern- Date.now()确保每次错误都作为独立条目落库可追溯、可回放。4.2 用 neural_patterns 分析恢复效果第二段调用neural_patterns的analyze动作把一次operationerror-recovery、outcomesuccess的恢复事件送入神经模式分析。可以理解为成功恢复的错误模式会被标记为正样本供训练/调优环节使用从而让系统学习哪些策略对哪类错误有效。这一机制与仓库中trainPatternsOnComplete一类配置见 settings.json背后的理念相同完成即学习经验流向集中式的模式训练与跨会话记忆。配合 .claude/commands/automation/session-memory.md 这类会话记忆命令错误模式还能在会话重启后继续生效实现跨会话的不二过。5. MCP 工具协调用 Swarm 编排一次自愈任务当单 Agent 的自我修复不足以应对复杂故障时自愈流程会升级为多 Agent 编排。原文档给出的 MCP 调用序列展示了一套标准的初始化 swarm → 派生监控 Agent → 编排恢复任务流程// Initialize self-healing swarm mcp__claude-flow__swarm_init({ topology: star, maxAgents: 4, strategy: adaptive }) // Spawn recovery agents mcp__claude-flow__agent_spawn({ type: monitor, name: Error Monitor, capabilities: [error-detection, recovery] }) // Orchestrate recovery mcp__claude-flow__task_orchestrate({ task: recover from error, strategy: sequential, priority: critical })逐参数解读这套编排的语义swarm_init先建立一个专门服务于自愈的 Agent 群体。topology: star表示以单一协调者为中心的星型拓扑适合任务分发集中、子 Agent 平级的恢复场景maxAgents: 4限制并发 Agent 数避免故障风暴下无节制扩增strategy: adaptive表示恢复策略可根据错误类型动态切换。仓库的真实 swarm 配置同样支持拓扑与容量声明例如 settings.json 中的swarm.topology与swarm.maxAgents字段二者结构相互印证。agent_spawn派生一个常驻型monitorAgentError Monitor其能力清单capabilities显式声明了error-detection与recovery——这既是对该 Agent 的能力约束也是调度器分配任务时的依据。task_orchestrate把从错误中恢复作为一个关键优先级的整体任务采用串行策略strategy: sequential下发给 swarm。串行而非并行是为了让修复步骤之间保持因果顺序先装依赖、再修语法、最后跑测试避免并发修复互相踩踏。需要说明的是mcp__claude-flow__*是 claude-flow MCP 服务器暴露给 Claude Code 的命名前缀工具。RuFlo 仓库大量命令文档都以该前缀调用 swarm 与记忆类工具例如 memory 写入、swarm 状态查询等均以相同调用范式出现可确认这套工具协调语法是仓库内跨命令文件通用的标准调用方式。6. Fallback Hook把自愈挂在 Bash 命令的失败出口上要让上述编排真正随命令失败而触发需要把自愈逻辑挂在 Claude Code 的 Hook 事件上。原文档给出的最简配置是一个兜底fallback形式的PostToolUseHook一旦 Bash 工具执行完毕即检查退出码非零则进入自动恢复{ PostToolUse: [{ matcher: ^Bash$, command: npx claude-flow hook post-bash --exit-code ${tool.result.exitCode} --auto-recover }] }配置语义拆解事件与匹配PostToolUse 正则matcher: ^Bash$精确命中 Bash 工具的调用结果Write/Edit等非命令类工具不受影响。退出码注入${tool.result.exitCode}是 Claude Code 注入的模板变量把本次命令的真实退出码传给post-bashHook——自愈判定的第一步就是exitCode 是否为 0。自动恢复开关--auto-recover显式开启恢复动作不带该参数时 Hook 只做记录logging/metrics这为仅观察、不自动动手的保守模式留了余地。需要注意Claude Code 的 Hook 配置存在两种书写形态。仓库当前生效的 .claude/settings.json 使用的是嵌套hooks数组的新式结构type: command 超时等字段其 Bash 相关的PreToolUse配置为{ PreToolUse: [ { matcher: Bash, hooks: [ { type: command, command: node \$CLAUDE_PROJECT_DIR/.claude/helpers/hook-handler.cjs\ pre-bash, timeout: 5000 } ] } ] }两种形态可类比理解简化形态适合快速试验npx claude-flow全局 CLI 的自愈命令完整形态hooks-automation 技能文档中 SKILL.md 亦给出全套 Pre/Post/Session Hook 的完整 schema适合正式工程配置可叠加timeout、continueOnError、async等执行控制字段。仓库已落地的 hook-handler 分发架构一个统一 handler 按事件名路由到pre-bash/post-edit/session-end/post-task等处理器正是把上述能力集中管理的最佳实践你只需在 matcher 上登记事件逻辑处理都在 handler 内收敛。6.1 组合成一条完整的自愈 Hook 链把原文档的 fallback 思想扩展为覆盖全生命周期的可用配置兼容嵌套形态可按如下模式组织{ hooks: { PreToolUse: [ { matcher: Bash, hooks: [{ type: command, command: npx claude-flow hook pre-bash --command ${tool.params.command} --check-safety }] } ], PostToolUse: [ { matcher: ^Bash$, hooks: [{ type: command, command: npx claude-flow hook post-bash --command ${tool.params.command} --exit-code ${tool.result.exitCode} --auto-recover --update-metrics --store-result }] } ] } }pre-bash在命令执行前做安全检查危险命令拦截、资源预估可参考 SKILL.md 中的--check-safety等参数post-bash在命令执行后同时承担**检测exitCode、恢复--auto-recover、度量--update-metrics、沉淀--store-result**四重职责正是本文第 2、3、4 章所述三环合一的落点。7. 收益与落地建议原文档最后以四点概括自愈体系的业务价值️ 弹性工作流Resilient workflows——故障被就地消化而非打断整条流水线 自动恢复Automatic recovery——依赖安装、语法修复、测试复跑无需人工介入 从错误中学习Learns from errors——每个失败都是知识库的新样本与策略调优的输入⏱️ 节省调试时间Saves debugging time——人只需介入策略层而非逐条排查。落地到 RuFlo 仓库环境的实践建议从观察模式起步先只启用post-bash的记录与错误模式落库不开--auto-recover运行一段时间积累真实的error-patterns语料再逐步放开自动恢复降低误修复风险。按错误类型分级授权依赖缺失可完全自动语法错误保留确认闸门沿用原文档的 Applies fix with confirmation测试失败则委派独立 debugger Agent 并设定重试上限防止无限修复循环。让经验流向下游确保neural_patterns的 analyze 调用随成功恢复发生并把error-patternsnamespace 纳入会话记忆的恢复范围参考 session-memory.md实现跨会话预防。沉淀为可复用命令可将本文梳理的恢复路径整理为自动化命令如 .claude/commands/automation/ 目录下的命令一样让自愈逻辑不仅挂在 Hook 上也可按需手动触发。完整的原命令定义与配套 Hook 文档可在仓库内进一步查阅self-healing.md、Hooks 总览、Hooks 配置技能 以及生效中的 settings.json。【免费下载链接】ruflo The original agent meta-harness. Deploy intelligent multi-player swarms, coordinate autonomous workflows, and build conversational AI systems. Features adaptive memory, self-learning intelligence, RAG integration, and native Claude Code / Codex / Hermes and many more Integrated项目地址: https://gitcode.com/GitHub_Trending/cl/ruflo创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考
