自主循环技能
兼容性说明（v1.8.0）：
autonomous-loops保留一个版本。 规范的技能名称现在是continuous-agent-loop。新的循环指导 应在那份技能文档中编写，而本技能文档保留下来以避免 破坏现有工作流程。
用于自主运行 Claude Code 的模式、架构和参考实现。涵盖从简单的 claude -p 管道到完整的基于 RFC 的多代理 DAG 编排。
何时使用
- 设置无需人工干预即可运行的自主开发工作流程
- 为你的问题选择正确的循环架构（简单 vs 复杂）
- 构建 CI/CD 风格的无间断开发管道
- 运行具有合并协调功能的并行代理
- 在循环迭代之间实现上下文持久化
- 在自主工作流程中添加质量门控和清理步骤
循环模式谱系
从最简单到最复杂：
| 模式 | 复杂度 | 最佳用途 |
|---|---|---|
| 顺序管道 | 低 | 日常开发步骤，脚本化工作流 |
| NanoClaw REPL | 低 | 交互式持久会话 |
| 无限代理循环 | 中 | 并行内容生成，规范驱动的工作 |
| 持续 Claude PR 循环 | 中 | 带 CI 门控的多日迭代项目 |
| 去冗余模式 | 附加 | 任何实现步骤后的质量清理 |
| Ralphinho / 基于 RFC 的 DAG | 高 | 大型功能，带合并队列的并行多单元工作 |
1. 顺序管道 (claude -p)
最简单的循环。 将日常开发分解为一系列非交互式的 claude -p 调用。每个调用都是一个专注的步骤，带有清晰的提示。
核心洞察
如果你连这样的循环都搞不定，那就意味着你甚至无法在交互模式下驱动 LLM 来修复你的代码。
claude -p 标志非交互式地运行 Claude Code，并附带一个提示，完成后退出。链接调用以构建管道：
#!/bin/bash
# daily-dev.sh — 功能分支的顺序管道
set -e
# 步骤 1：实现功能
claude -p "读取 docs/auth-spec.md 中的规范。在 src/auth/ 中实现 OAuth2 登录。先写测试（TDD）。不要创建任何新的文档文件。"
# 步骤 2：去冗余（清理步骤）
claude -p "检查上一个提交更改的所有文件。删除任何不必要的类型测试、过度防御性检查或针对语言特性的测试（例如，测试 TypeScript 泛型是否工作）。保留真正的业务逻辑测试。清理后运行测试套件。"
# 步骤 3：验证
claude -p "运行完整的构建、lint、类型检查和测试套件。修复所有失败。不要添加新功能。"
# 步骤 4：提交
claude -p "为所有暂存的更改创建一个常规提交。使用 'feat: add OAuth2 login flow' 作为提交信息。"
关键设计原则
- 每个步骤都是独立的 — 每次
claude -p调用都有一个新的上下文窗口，因此步骤之间没有上下文泄漏。 - 顺序很重要 — 步骤顺序执行。每一步都建立在上一步留下的文件系统状态之上。
- 负面指令很危险 — 不要说“不要测试类型系统”。相反，添加一个单独的清理步骤（参见去冗余模式）。
- 退出码会传播 —
set -e会在失败时停止管道。
变体
使用模型路由：
# 使用 Opus 进行研究（深度推理）
claude -p --model opus "分析代码库架构并编写添加缓存的计划..."
# 使用 Sonnet 实现（快速，能力强）
claude -p "根据 docs/caching-plan.md 中的计划实现缓存层..."
# 使用 Opus 审查（彻底）
claude -p --model opus "审查所有更改是否存在安全问题、竞态条件和边缘情况..."
使用环境上下文：
# 通过文件传递上下文，而非提示长度
echo "重点关注领域：auth 模块，API 速率限制" > .claude-context.md
claude -p "读取 .claude-context.md 中的优先级。按顺序处理它们。"
rm .claude-context.md
使用 --allowedTools 限制：
# 只读分析步骤
claude -p --allowedTools "Read,Grep,Glob" "审计该代码库是否存在安全漏洞..."
# 只写实现步骤
claude -p --allowedTools "Read,Write,Edit,Bash" "实现 security-audit.md 中的修复..."
2. NanoClaw REPL
ECC 内置的持久化循环。 一个会话感知的 REPL，使用完整的对话历史同步调用 claude -p。
# 启动默认会话
node scripts/claw.js
# 具有技能上下文的命名会话
CLAW_SESSION=my-project CLAW_SKILLS=tdd-workflow,security-review node scripts/claw.js
工作原理
- 从
~/.claude/claw/{session}.md加载对话历史 - 每条用户消息都与完整历史一起发送给
claude -p作为上下文 - 响应被追加到会话文件中（将 Markdown 作为数据库）
- 会话在重启后持续存在
NanoClaw vs 顺序管道
| 用例 | NanoClaw | 顺序管道 |
|---|---|---|
| 交互式探索 | 是 | 否 |
| 脚本化自动化 | 否 | 是 |
| 会话持久化 | 内置 | 手动 |
| 上下文累积 | 每次轮次增长 | 每步全新 |
| CI/CD 集成 | 差 | 优秀 |
有关完整详细信息，请参阅 /claw 命令文档。
3. 无限代理循环
一个双提示系统，用于编排并行子代理以进行规范驱动的生成。由 disler 开发（鸣谢：@disler）。
架构：双提示系统
提示 1（编排器） 提示 2（子代理）
┌─────────────────────┐ ┌──────────────────────┐
│ 解析规范文件 │ │ 接收完整上下文 │
│ 扫描输出目录 │ 部署 │ 读取分配的数字 │
│ 规划迭代 │────────────│ 严格遵循规范 │
│ 分配创意方向 │ N 个代理 │ 生成独特输出 │
│ 管理批次 │ │ 保存到输出目录 │
└─────────────────────┘ └──────────────────────┘
模式
- 规范分析 — 编排器读取定义要生成内容的规范文件（Markdown）
- 目录侦察 — 扫描现有输出以找到最高的迭代编号
- 并行部署 — 启动 N 个子代理，每个子代理获得：
- 完整规范
- 独特的创意方向
- 特定的迭代编号（无冲突）
- 现有迭代的快照（用于确保唯一性）
- 批次管理 — 对于无限模式，部署 3-5 个代理的批次，直到上下文耗尽
通过 Claude Code 命令实现
创建 .claude/commands/infinite.md：
从 $ARGUMENTS 解析以下参数：
1. spec_file — 规范 markdown 的路径
2. output_dir — 保存迭代的位置
3. count — 整数 1-N 或 "infinite"
阶段 1：阅读并深入理解规范。
阶段 2：列出 output_dir，找到最高的迭代编号。从 N+1 开始。
阶段 3：规划创意方向——每个代理获得不同的主题/方法。
阶段 4：并行部署子代理（Task 工具）。每个子代理接收：
- 完整规范文本
- 当前目录快照
- 分配给它们的迭代编号
- 它们独特的创意方向
阶段 5（无限模式）：以 3-5 个为一组循环，直到上下文不足。
调用：
/project:infinite specs/component-spec.md src/ 5
/project:infinite specs/component-spec.md src/ infinite
批处理策略
| 数量 | 策略 |
|---|---|
| 1-5 | 所有代理同时运行 |
| 6-20 | 每批 5 个 |
| 无限 | 每批 3-5 个，渐进式复杂化 |
关键见解：通过分配实现唯一性
不要依赖代理自行区分。编排器为每个代理分配一个特定的创意方向和迭代编号。这可以防止并行代理之间出现重复概念。
4. 持续 Claude PR 循环
一个生产级 shell 脚本，在一个持续循环中运行 Claude Code，创建 PR，等待 CI，并自动合并。由 AnandChowdhary 创建（鸣谢：@AnandChowdhary）。
核心循环
┌─────────────────────────────────────────────────────┐
│ 持续 CLAUDE 迭代 │
│ │
│ 1. 创建分支（continuous-claude/iteration-N） │
│ 2. 运行 claude -p 并附带增强提示 │
│ 3. （可选）审查步骤 — 单独的 claude -p │
│ 4. 提交更改（claude 生成提交信息） │
│ 5. 推送 + 创建 PR（gh pr create） │
│ 6. 等待 CI 检查（轮询 gh pr checks） │
│ 7. CI 失败？→ 自动修复步骤（claude -p） │
│ 8. 合并 PR（压缩/合并/变基） │
│ 9. 返回主分支 → 重复 │
│ │
│ 通过以下方式限制：--max-runs N | --max-cost $X │
│ --max-duration 2h | completion signal │
└─────────────────────────────────────────────────────┘
安装
警告： 在审查代码后从其仓库安装 continuous-claude。不要直接将外部脚本通过管道传给 bash。
用法
# 基本：10 次迭代
continuous-claude --prompt "为所有未测试的函数添加单元测试" --max-runs 10
# 成本限制
continuous-claude --prompt "修复所有 linter 错误" --max-cost 5.00
# 时间限制
continuous-claude --prompt "提高测试覆盖率" --max-duration 8h
# 带代码审查步骤
continuous-claude \
--prompt "添加身份验证功能" \
--max-runs 10 \
--review-prompt "运行 npm test && npm run lint，修复所有失败"
# 通过 worktrees 并行执行
continuous-claude --prompt "添加测试" --max-runs 5 --worktree tests-worker &
continuous-claude --prompt "重构代码" --max-runs 5 --worktree refactor-worker &
wait
跨迭代上下文：SHARED_TASK_NOTES.md
关键创新：一个 SHARED_TASK_NOTES.md 文件在迭代之间持续存在：
## 进度
- [x] 为 auth 模块添加了测试（迭代 1）
- [x] 修复了令牌刷新中的边缘情况（迭代 2）
- [ ] 仍然需要：速率限制测试，错误边界测试
## 后续步骤
- 接下来关注速率限制模块
- tests/helpers.ts 中的模拟设置可以重用
Claude 在每次迭代开始时读取此文件，并在迭代结束时更新它。这桥接了独立 claude -p 调用之间的上下文差距。
CI 失败恢复
当 PR 检查失败时，Continuous Claude 自动：
- 通过
gh run list获取失败的运行 ID - 生成一个新的
claude -p，附带 CI 修复上下文 - Claude 通过
gh run view检查日志，修复代码，提交，推送 - 重新等待检查（最多
--ci-retry-max次尝试）
完成信号
Claude 可以通过输出一个魔法短语来发出“我完成了”的信号：
continuous-claude \
--prompt "修复问题跟踪器中所有错误" \
--completion-signal "CONTINUOUS_CLAUDE_PROJECT_COMPLETE" \
--completion-threshold 3 # 在连续 3 个信号后停止
连续三次迭代发出完成信号会停止循环，防止在已完成的工作上浪费运行。
关键配置
| 标志 | 用途 |
|---|---|
--max-runs N | 在 N 次成功迭代后停止 |
--max-cost $X | 在花费 $X 后停止 |
--max-duration 2h | 在时间过去后停止 |
--merge-strategy squash | squash、merge 或 rebase |
--worktree <name> | 通过 git worktrees 并行执行 |
--disable-commits | 试运行模式（无 git 操作） |
--review-prompt "..." | 每次迭代添加审查步骤 |
--ci-retry-max N | 自动修复 CI 失败（默认：1） |
5. 去冗余模式
任何循环的附加模式。 在每个实现步骤之后添加一个专门的清理/重构步骤。
问题
当你要求 LLM 使用 TDD 实现时，它会过于字面地理解“编写测试”：
- 验证 TypeScript 类型系统是否工作的测试（测试
typeof x === 'string'） - 对类型系统已保证的内容进行过于防御性的运行时检查
- 测试框架行为而非业务逻辑的测试
- 掩盖实际代码的过度错误处理
为什么不用负面指令？
在实现提示中添加“不要测试类型系统”或“不要添加不必要的检查”会产生下游影响：
- 模型对所有测试变得犹豫不决
- 它会跳过合法的边缘情况测试
- 质量会不可预测地下降
解决方案：单独步骤
不要约束实现者，而是让它彻底。然后添加一个专注的清理代理：
# 步骤 1：实现（让它彻底）
claude -p "使用完整的 TDD 实现该功能。彻底编写测试。"
# 步骤 2：去冗余（单独的上下文，专注的清理）
claude -p "检查工作树中的所有更改。删除：
- 测试语言/框架行为而非业务逻辑的测试
- 类型系统已强制执行的冗余类型检查
- 针对不可能状态的过度防御性错误处理
- Console.log 语句
- 注释掉的代码
保留所有业务逻辑测试。清理后运行测试套件以确保没有破坏。"
在循环上下文中
for feature in "${features[@]}"; do
# 实现
claude -p "使用 TDD 实现 $feature。"
# 去冗余
claude -p "清理步骤：检查更改，移除测试/代码冗余，运行测试。"
# 验证
claude -p "运行 build + lint + tests。修复所有失败。"
# 提交
claude -p "提交信息：feat: add $feature"
done
关键见解
与其添加具有下游质量影响的负面指令，不如添加一个单独的去冗余步骤。两个专注的代理优于一个受约束的代理。
6. Ralphinho / 基于 RFC 的 DAG 编排
最复杂的模式。 一个基于 RFC 的多代理管道，用于大规模并行功能开发。该模式使用一个主架构师代理编写详细的 RFC，然后部署多个实现代理并行工作，最后通过专门的整合代理进行合并。
架构
┌──────────────────────────────────────────────────────────┐
│ Ralphinho DAG 编排 │
│ │
│ 阶段 1：架构师代理 │
│ ┌────────────────────────────────────┐ │
│ │ 读取规范 + 代码库 │ │
│ │ 编写 RFC（docs/rfc.md） │ │
│ │ 将功能分解为工作单元（unit-1..N） │ │
│ │ 为每个单元指定文件 │ │
│ └────────────────────────────────────┘ │
│ │ │
│ ▼ │
│ 阶段 2：并行实现代理 │
│ ┌────────────────────────────────────┐ │
│ │ unit-1 代理 │ unit-2 代理 │ unit-3 │ │
│ │ 读取 RFC │ 读取 RFC │ 读取 │ │
│ │ 实现功能 │ 实现功能 │ 实现 │ │
│ │ 编写测试 │ 编写测试 │ 编写 │ │
│ └─────────────┴─────────────┴─────────┘ │
│ │ │ │ │
│ ▼ ▼ ▼ │
│ 阶段 3：整合代理 │
│ ┌────────────────────────────────────┐ │
│ │ 创建一个大的合并 PR │ │
│ │ 解决冲突（git merge） │ │
│ │ 运行完整测试套件 │ │
│ │ 修复回归问题 │ │
│ │ 创建最终 PR │ │
│ └────────────────────────────────────┘ │
└──────────────────────────────────────────────────────────┘
工作流程
-
架构师代理创建 RFC — 架构师阅读功能规范和代码库，然后编写一份详细的设计文档（
docs/rfc.md），其中包含：- 实现的概述
- 分解为独立工作单元（每个单元指定将更改哪些文件）
- 每个单元的测试策略和验收标准
- 依赖关系顺序（如果某个单元依赖于另一个单元，则它们必须按顺序实现）
-
并行实现代理 — 每个工作单元对应一个代理。并行启动，每个代理读取完整的 RFC 以了解上下文，但只实现其分配的工作单元。每个代理：
- 创建一个功能分支（
unit-1、unit-2等） - 实现代码
- 编写测试
- 推送分支
- 创建一个功能分支（
-
整合代理 — 所有实现分支就绪后，整合代理介入：
- 创建一个整合分支
- 合并所有单元分支
- 使用
git merge而不是变基来解决真正的冲突 - 运行完整的构建和测试套件
- 修复所有回归问题
- 创建最终的 PR 到主分支
何时使用
- 大型功能，多个不重叠的文件需要更改
- 可以基于规范的明确部分并行化的工作
- 需要严格设计审查（RFC 过程）的项目
- 任何单个
claude -p会话无法在单一上下文窗口中处理的功能
关键成功因素
- 好的 RFC 是基础 — 架构师代理必须仔细指定责任边界，以避免冲突
- 文件隔离 — 如果两个代理更改同一文件的同一部分，则几乎可以肯定会发生冲突。设计工作单元时最大限度地减少重叠。
- 依赖顺序很重要 — 如果单元 2 依赖于单元 1 的输出，则它们不能并行运行。要么按顺序运行它们，要么设计更小的接口边界。
- 测试是安全网 — 每个单元都应该有自己的测试，并且整合步骤运行完整的测试套件以确保整体工作正常。
实现注意事项
该模式可以使用 Claude Code 的 Task 工具或脚本编排器（例如，包含三个阶段的 shell 脚本）来实现。关键细节：
# 阶段 1：架构师产生 RFC
claude -p "阅读 specs/my-feature.md。分析代码库。在 docs/rfc.md 中编写一个详细的 RFC，将工作分解为 3-5 个逻辑单元。明确指定每个单元要更改哪些文件。"
# 阶段 2：并行启动实现代理（使用 Task 工具或工作树）
claude -p --task "基于 docs/rfc.md 实现工作单元 1：..." &
claude -p --task "基于 docs/rfc.md 实现工作单元 2：..." &
claude -p --task "基于 docs/rfc.md 实现工作单元 3：..." &
# 阶段 3：整合（等待所有并行任务完成后）
claude -p "读取 docs/rfc.md。创建一个整合分支，合并所有单元分支（unit-1、unit-2、unit-3）。解决所有合并冲突。运行完整的测试套件。修复所有回归问题。创建一个指向主分支的最终 PR。"
权衡
| 方面 | 优点 | 缺点 |
|---|---|---|
| 速度 | 并行执行比顺序模式快得多 | 设置开销高 |
| 质量 | RFC 审查提供了严格的架构 | 实施者可能偏离 RFC |
| 冲突管理 | 文件隔离最小化冲突 | 真正的冲突需要手动解决 |
| 复杂性 | 适合大型功能 | 对于小任务来说过度设计 |
| 上下文使用 | 每个代理只看到一部分 | 跨代理没有共享的 TODO 跟踪 |