需求拆解

用户目标分析

核心需求：解决 AI 自动化中断恢复问题

用户当前使用 OpenCode + GLM4.7 + OpenSpec 模式运行自动化研究报告生成项目，但面临一个关键问题：模型在运行过程中可能被强制终止或陷入卡死状态，导致无法继续执行。用户希望调研 Ralph-Loop 方案的可行性，并了解如何在实际项目中实施该方案来解决上述中断恢复问题。

业务场景特征

根据用户提供的信息，可以推断其业务场景具有以下特征：

1. 长时间运行任务：研究报告生成通常需要多次迭代、文献检索、数据分析、文档编写等多个步骤，整个过程可能持续数小时甚至更长时间
2. 多步骤依赖：每个研究报告可能包含多个章节或模块，不同步骤之间存在依赖关系，某些步骤的失败会影响后续任务
3. 成本敏感：使用 GLM4.7 API 意味着需要合理控制 Token 消耗和 API 调用次数
4. 需要状态持久化：中断后需要能够从断点继续，而不是重新开始整个任务

预期改进效果

用户期望通过 Ralph-Loop 方案实现：

1. 自动中断恢复：当模型运行被中断或卡死时，系统能够自动检测并恢复执行
2. 进度保留：已经完成的工作成果不丢失，能够基于最新状态继续
3. 智能退出检测：避免无限循环或重复执行已完成的任务
4. 资源管理：合理控制 API 调用次数和超时设置

关键技术挑战

挑战一：中断检测机制

问题描述： 如何准确判断 AI 任务是否"被终止或卡住"？这涉及到多种可能的中断场景：

• 网络/连接问题导致的 API 调用失败
• 模型响应超时
• 系统级进程被强制终止（Ctrl+C 或系统 kill）
• 模型陷入重复模式（例如输出相同错误信息）
• Token 限制导致响应截断

影响分析： 如果不能准确检测中断，就无法及时触发恢复机制。错误的检测可能导致：

• 将正常的长耗时任务误判为卡死而提前终止
• 未能及时检测到真正的中断，导致资源浪费

为什么这很重要： 中断检测是整个自动化恢复系统的基础，它决定了系统能否可靠地响应各种异常情况。

挑战二：状态持久化与恢复

问题描述： 中断后需要保存哪些状态信息，以及如何从这些状态恢复执行？状态管理涉及：

• 任务进度跟踪（已完成/进行中/待办任务列表）
• 对话上下文（Chat History）
• 文件系统变更（已创建/修改的文件）
• API 调用记录和消耗统计

影响分析： 不完整的状态持久化会导致：

• 恢复时遗漏已完成的工作
• 重复执行已完成的任务，浪费资源
• 对话上下文丢失导致模型"遗忘"之前的决策

为什么这很重要： 状态管理直接关系到系统的可靠性和成本效率。良好的状态管理可以避免重复工作，最大化已投入资源的价值。

挑战三：智能退出条件判断

问题描述： 如何判断任务真正"完成"？研究报告生成是一个相对主观的目标，难以用明确的指标量化。

影响分析：

• 退出条件过于严格可能导致无限循环
• 退出条件过于宽松可能导致报告质量不达标
• 缺乏智能判断会导致模型重复执行相同任务或过早终止

为什么这很重要： 退出判断是 Ralph-Loop 的核心机制之一，它直接决定了自动化的效果和成本。

挑战四：与现有技术栈的集成

问题描述： Ralph-Loop 最初是为 Claude Code 设计的，用户使用的是 GLM4.7 + OpenCode，两者在以下方面存在差异：

• CLI 接口差异（命令行参数、输出格式）
• 模型能力差异（Claude Opus 4.5 vs GLM4.7）
• Stop Hook 机制兼容性
• 会话管理机制差异

影响分析： 如果集成不当，可能导致：

• Ralph-Loop 的核心功能无法正常工作
• 需要进行大量定制化开发
• 无法利用 Ralph-Loop 的现有功能和社区经验

为什么这很重要： 集成难度决定了方案的实施成本和风险。高集成难度可能意味着方案不可行或需要大量额外开发工作。

成功标准

功能性标准

1. 中断恢复成功率 ≥ 95%

   • 在各种中断场景下（网络错误、超时、手动中断等），系统应该能够成功恢复执行
   • 恢复后能够准确识别已完成和未完成的任务

2. 状态保留完整性

   • 所有已创建的文件和修改在恢复后都应保留
   • 对话上下文应能够跨中断保持连续性
   • 任务进度应准确反映实际完成情况

3. 智能退出准确率

   • 能够识别真正的完成状态
   • 避免过早退出（未完成任务就停止）
   • 避免无限循环（无法识别完成状态）

非功能性标准

1. 资源效率

   • API 调用次数增加不超过 20%（相比不使用 Ralph-Loop）
   • 恢复时间 ≤ 1 分钟
   • 额外存储开销 ≤ 项目文件总大小的 10%

2. 可靠性

   • 系统可用性 ≥ 99%
   • 单点故障不影响整体恢复能力
   • 能够处理至少 5 次连续中断

3. 可操作性

   • 安装配置时间 ≤ 30 分钟
   • 文档完整且易于理解
   • 提供清晰的监控和调试界面

参考资料

• frankbria/ralph-claude-code - GitHub - Ralph for Claude Code 官方实现
• The Ralph Wiggum Technique: Run Claude Code Autonomously for Hours - Ralph Wiggum 技术详解
• Ralph Wiggum：Claude Code 官方插件实现自主 AI 开发循环 - 中文技术分析
• OpenCode GitHub Issue #9218 - OpenCode 自动中断问题讨论