autonomous-loops

name	autonomous-loops
description	自主 Claude Code 循环的模式和架构 —— 从简单的顺序管道到 RFC 驱动的多代理 DAG 系统。
origin	ECC

自主循环技能

兼容性说明 (v1.8.0)：autonomous-loops 保留一个版本。 规范的技能名称现在是 continuous-agent-loop。新的循环指导 应该在那里编写，而此技能仍然可用以避免 破坏现有工作流。

用于自主运行 Claude Code 的模式、架构和参考实现。涵盖从简单的 claude -p 管道到完整的 RFC 驱动多代理 DAG 编排的所有内容。

何时使用

• 设置无人为干预运行的自主开发工作流
• 为您的问题选择正确的循环架构（简单 vs 复杂）
• 构建 CI/CD 风格的连续开发管道
• 运行带有合并协调的并行代理
• 实现跨循环迭代的上下文持久性
• 为自主工作流添加质量门和清理传递

循环模式谱系

从最简单到最复杂：

模式	复杂度	最适合
顺序管道	低	日常开发步骤、脚本化工作流
NanoClaw REPL	低	交互式持久会话
无限代理循环	中	并行内容生成、规范驱动工作
连续 Claude PR 循环	中	具有 CI 门控的多天迭代项目
去反 slop 模式	附加	任何实现者步骤后的质量清理
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：去反 slop（清理传递）
claude -p "审查上次提交更改的所有文件。删除任何不必要的类型测试、过度防御性检查或语言功能测试（例如，测试 TypeScript 泛型是否工作）。保留真正的业务逻辑测试。清理后运行测试套件。"

# 步骤 3：验证
claude -p "运行完整构建、lint、类型检查和测试套件。修复任何故障。不要添加新功能。"

# 步骤 4：提交
claude -p "为所有暂存更改创建约定式提交。使用 'feat: add OAuth2 login flow' 作为消息。"

关键设计原则

1. 每个步骤都是隔离的 — 每个 claude -p 调用都有新的上下文窗口，意味着步骤之间没有上下文泄漏。
2. 顺序很重要 — 步骤按顺序执行。每个步骤都建立在前一个步骤留下的文件系统状态上。
3. 否定指令是危险的 — 不要说"不要测试类型系统"。相反，添加单独的清理步骤（见去反 slop 模式）。
4. 退出码传播 — set -e 在失败时停止管道。

---

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

如何工作

1. 从 ~/.claude/claw/{session}.md 加载对话历史
2. 每个用户消息都作为上下文发送到 claude -p
3. 响应附加到会话文件（Markdown 作为数据库）
4. 会话跨重启持久化

---

3. 无限代理循环

双提示系统，编排用于规范驱动生成的并行子代理。由 disler 开发（致谢：@disler）。

架构：双提示系统

提示 1（编排器）              提示 2（子代理）
┌─────────────────────┐             ┌──────────────────────┐
│ 解析规范文件          │             │ 接收完整上下文       │
│ 扫描输出目录          │  deploys   │ 阅读分配的编号       │
│ 规划迭代              │────────────│ 严格遵循规范         │
│ 分配创意方向          │  N agents  │ 生成唯一输出         │
│ 管理波次              │             │ 保存到输出目录       │
└─────────────────────┘             └──────────────────────┘

---

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 检查（poll gh pr checks）               │
│  7. CI 故障？→ 自动修复传递 (claude -p)             │
│  8. 合并 PR（squash/merge/rebase）                  │
│  9. 返回主分支 → 重复                               │
│                                                     │
│  限制：--max-runs N | --max-cost $X                 │
│            --max-duration 2h | 完成信号               │
└─────────────────────────────────────────────────────┘

---

5. 去反 Slop 模式

任何循环的附加模式。 在每个实现者步骤之后添加专用的清理/重构步骤。

问题

当您要求 LLM 使用 TDD 实现时，它会过于字面地理解"编写测试"：

• 测试 TypeScript 类型系统是否工作（测试 typeof x === 'string'）
• 类型系统已保证事物的过度防御性运行时检查
• 框架行为的测试而不是业务逻辑
• 遮盖实际代码的过度错误处理

解决方案：单独传递

不要限制实现者，让它彻底。然后添加一个专注的清理代理：

# 步骤 1：实现（让它彻底）
claude -p "使用完整 TDD 实现功能。彻底测试。"

# 步骤 2：去反 slop（单独上下文、专注清理）
claude -p "审查工作树中的所有更改。删除：
- 验证语言/框架行为而不是业务逻辑的测试
- 类型系统已经强制执行的冗余类型检查
- 针对不可能状态的过度防御性错误处理
- Console.log 语句
- 注释掉的代码

保留所有业务逻辑测试。清理后运行测试套件以确保没有任何损坏。"

---

6. Ralphinho / RFC 驱动 DAG 编排

最复杂的模式。 RFC 驱动的多代理管道，将规范分解为依赖 DAG，通过分层质量管道运行每个单元，并通过代理驱动的合并队列进行落地。由 enitrat 创建（致谢：@enitrat）。

架构概览

RFC/PRD 文档
       │
       ▼
  分解（AI）
  将 RFC 分解为具有依赖 DAG 的工作单元
       │
       ▼
┌──────────────────────────────────────────────────────┐
│  RALPH 循环（最多 3 遍）                            │
│                                                      │
│  对于每个 DAG 层（按依赖顺序）：                       │
│                                                      │
│  ┌── 质量管道（每个单元并行）──────────────────────┐  │
│  │  每个单元在自己的工作树中：                        │  │
│  │  研究 → 计划 → 实现 → 测试 → 审查              │  │
│  │  （深度因复杂性层而异）                          │  │
│  └──────────────────────────────────────────────────┘  │
│                                                      │
│  ┌── 合并队列─────────────────────────────────────┐  │
│  │  变基到主分支 → 运行测试 → 落地或驱逐          │  │
│  │  驱逐的单元带着冲突上下文重新进入                │  │
│  └──────────────────────────────────────────────────┘  │
│                                                      │
└──────────────────────────────────────────────────────┘

复杂性层级

不同层级获得不同的管道深度：

层级	管道阶段
trivial	implement → test
small	implement → test → code-review
medium	research → plan → implement → test → PRD-review + code-review → review-fix
large	research → plan → implement → test → PRD-review + code-review → review-fix → final-review

---

选择正确的模式

决策矩阵

任务是单个专注的更改吗？
├─ 是 → 顺序管道或 NanoClaw
└─ 否 → 是否有书面规范/RFC？
         ├─ 是 → 需要并行实现吗？
         │        ├─ 是 → Ralphinho（DAG 编排）
         │        └─ 否 → Continuous Claude（迭代 PR 循环）
         └─ 否 → 需要同一事物的许多变体吗？
                  ├─ 是 → 无限代理循环（规范驱动生成）
                  └─ 否 → 带去反 slop 的顺序管道

---

name: autonomous-loops description: "自主 Claude Code 循环的模式和架构 —— 从简单的顺序管道到 RFC 驱动的多代理 DAG 系统。" origin: ECC

自主循环技能

兼容性说明 (v1.8.0)：autonomous-loops 保留一个版本。 规范的技能名称现在是 continuous-agent-loop。新的循环指导 应该在那里编写，而此技能仍然可用以避免 破坏现有工作流。

用于自主运行 Claude Code 的模式、架构和参考实现。涵盖从简单的 claude -p 管道到完整的 RFC 驱动多代理 DAG 编排的所有内容。

何时使用

• 设置无人为干预运行的自主开发工作流
• 为您的问题选择正确的循环架构（简单 vs 复杂）
• 构建 CI/CD 风格的连续开发管道
• 运行带有合并协调的并行代理
• 实现跨循环迭代的上下文持久性
• 为自主工作流添加质量门和清理传递

循环模式谱系

从最简单到最复杂：

模式	复杂度	最适合
顺序管道	低	日常开发步骤、脚本化工作流
NanoClaw REPL	低	交互式持久会话
无限代理循环	中	并行内容生成、规范驱动工作
连续 Claude PR 循环	中	具有 CI 门控的多天迭代项目
去反 slop 模式	附加	任何实现者步骤后的质量清理
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：去反 slop（清理传递）
claude -p "审查上次提交更改的所有文件。删除任何不必要的类型测试、过度防御性检查或语言功能测试（例如，测试 TypeScript 泛型是否工作）。保留真正的业务逻辑测试。清理后运行测试套件。"

# 步骤 3：验证
claude -p "运行完整构建、lint、类型检查和测试套件。修复任何故障。不要添加新功能。"

# 步骤 4：提交
claude -p "为所有暂存更改创建约定式提交。使用 'feat: add OAuth2 login flow' 作为消息。"

关键设计原则

1. 每个步骤都是隔离的 — 每个 claude -p 调用都有新的上下文窗口，意味着步骤之间没有上下文泄漏。
2. 顺序很重要 — 步骤按顺序执行。每个步骤都建立在前一个步骤留下的文件系统状态上。
3. 否定指令是危险的 — 不要说"不要测试类型系统"。相反，添加单独的清理步骤（见去反 slop 模式）。
4. 退出码传播 — set -e 在失败时停止管道。

---

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

如何工作

1. 从 ~/.claude/claw/{session}.md 加载对话历史
2. 每个用户消息都作为上下文发送到 claude -p
3. 响应附加到会话文件（Markdown 作为数据库）
4. 会话跨重启持久化

---

3. 无限代理循环

双提示系统，编排用于规范驱动生成的并行子代理。由 disler 开发（致谢：@disler）。

架构：双提示系统

提示 1（编排器）              提示 2（子代理）
┌─────────────────────┐             ┌──────────────────────┐
│ 解析规范文件          │             │ 接收完整上下文       │
│ 扫描输出目录          │  deploys   │ 阅读分配的编号       │
│ 规划迭代              │────────────│ 严格遵循规范         │
│ 分配创意方向          │  N agents  │ 生成唯一输出         │
│ 管理波次              │             │ 保存到输出目录       │
└─────────────────────┘             └──────────────────────┘

---

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 检查（poll gh pr checks）               │
│  7. CI 故障？→ 自动修复传递 (claude -p)             │
│  8. 合并 PR（squash/merge/rebase）                  │
│  9. 返回主分支 → 重复                               │
│                                                     │
│  限制：--max-runs N | --max-cost $X                 │
│            --max-duration 2h | 完成信号               │
└─────────────────────────────────────────────────────┘

---

5. 去反 Slop 模式

任何循环的附加模式。 在每个实现者步骤之后添加专用的清理/重构步骤。

问题

当您要求 LLM 使用 TDD 实现时，它会过于字面地理解"编写测试"：

• 测试 TypeScript 类型系统是否工作（测试 typeof x === 'string'）
• 类型系统已保证事物的过度防御性运行时检查
• 框架行为的测试而不是业务逻辑
• 遮盖实际代码的过度错误处理

解决方案：单独传递

不要限制实现者，让它彻底。然后添加一个专注的清理代理：

# 步骤 1：实现（让它彻底）
claude -p "使用完整 TDD 实现功能。彻底测试。"

# 步骤 2：去反 slop（单独上下文、专注清理）
claude -p "审查工作树中的所有更改。删除：
- 验证语言/框架行为而不是业务逻辑的测试
- 类型系统已经强制执行的冗余类型检查
- 针对不可能状态的过度防御性错误处理
- Console.log 语句
- 注释掉的代码

保留所有业务逻辑测试。清理后运行测试套件以确保没有任何损坏。"

---

6. Ralphinho / RFC 驱动 DAG 编排

最复杂的模式。 RFC 驱动的多代理管道，将规范分解为依赖 DAG，通过分层质量管道运行每个单元，并通过代理驱动的合并队列进行落地。由 enitrat 创建（致谢：@enitrat）。

架构概览

RFC/PRD 文档
       │
       ▼
  分解（AI）
  将 RFC 分解为具有依赖 DAG 的工作单元
       │
       ▼
┌──────────────────────────────────────────────────────┐
│  RALPH 循环（最多 3 遍）                            │
│                                                      │
│  对于每个 DAG 层（按依赖顺序）：                       │
│                                                      │
│  ┌── 质量管道（每个单元并行）──────────────────────┐  │
│  │  每个单元在自己的工作树中：                        │  │
│  │  研究 → 计划 → 实现 → 测试 → 审查              │  │
│  │  （深度因复杂性层而异）                          │  │
│  └──────────────────────────────────────────────────┘  │
│                                                      │
│  ┌── 合并队列─────────────────────────────────────┐  │
│  │  变基到主分支 → 运行测试 → 落地或驱逐          │  │
│  │  驱逐的单元带着冲突上下文重新进入                │  │
│  └──────────────────────────────────────────────────┘  │
│                                                      │
└──────────────────────────────────────────────────────┘

复杂性层级

不同层级获得不同的管道深度：

层级	管道阶段
trivial	implement → test
small	implement → test → code-review
medium	research → plan → implement → test → PRD-review + code-review → review-fix
large	research → plan → implement → test → PRD-review + code-review → review-fix → final-review

这可以在简单更改上避免昂贵操作，同时确保架构更改获得彻底审查。

独立上下文窗口（消除作者偏见）

每个阶段在自己的代理进程中以自己的上下文窗口运行：

阶段	模型	目的
Research	Sonnet	阅读代码库 + RFC，生成上下文文档
Plan	Opus	设计实现步骤
Implement	Codex	按照计划编写代码
Test	Sonnet	运行构建 + 测试套件
PRD Review	Sonnet	规范合规性检查
Code Review	Opus	质量 + 安全检查
Review Fix	Codex	解决审查问题
Final Review	Opus	质量门（仅大层级）

关键设计： 审查者从未编写其审查的代码。这消除了作者偏见 —— 自我审查中最常见的漏检来源。

合并队列与驱逐

质量管道完成后，单元进入合并队列：

单元分支
    │
    ├─ 变基到主分支
    │   └─ 冲突？→ 驱逐（捕获冲突上下文）
    │
    ├─ 运行构建 + 测试
    │   └─ 失败？→ 驱逐（捕获测试输出）
    │
    └─ 通过 → 快进主分支，推送，删除分支