autonomous-loops

自主循环技能

兼容性说明（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 个
infinite	每波 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（squash/merge/rebase）                   │
│  9. 回到 main → 重复                                │
│                                                     │
│  限制条件：--max-runs N | --max-cost $X             │
│            --max-duration 2h | 完成信号              │
└─────────────────────────────────────────────────────┘

安装

警告： 从仓库审查代码后安装 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，修复所有失败"

# 通过工作树并行
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] 修复 token 刷新中的边界情况（迭代 2）
- [ ] 仍需：速率限制测试、错误边界测试

## 下一步
- 接下来关注速率限制模块
- tests/helpers.ts 中的 mock 设置可以重用

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 "修复问题跟踪器中的所有 bug" \
  --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 工作树并行执行
`--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 "运行构建 + lint + 测试。修复所有失败。"

  # 提交
  claude -p "提交消息：feat: add $feature"
done

关键见解

与其添加对下游质量产生负面影响的负面指令，不如添加一个单独的去冗余步骤。两个聚焦的智能体优于一个受约束的智能体。

6. Ralphinho / 基于 RFC 的 DAG 编排

最复杂的模式。 一个基于 RFC 的多智能体流水线，将规范分解为依赖 DAG，通过分层质量流水线运行每个单元，并通过智能体驱动的合并队列落地。由 enitrat 创建（致谢：@enitrat）。

架构概览

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

RFC 分解

AI 读取 RFC 并生成工作单元：

interface WorkUnit {
  id: string;              // kebab-case 标识符
  name: string;            // 人类可读名称
  rfcSections: string[];   // 此单元处理的 RFC 章节
  description: string;     // 详细描述
  deps: string[];          // 依赖（其他单元 ID）
  acceptance: string[];    // 具体的验收标准
  tier: "trivial" | "small" | "medium" | "large";
}

分解规则：

优先选择更少、内聚的单元（最小化合并风险）
最小化跨单元文件重叠（避免冲突）
测试与实现保持在一起（永远不要分离“实现 X”+“测试 X”）
仅在存在真实代码依赖时添加依赖

依赖 DAG 决定执行顺序：

层 0: [unit-a, unit-b]     ← 无依赖，并行运行
层 1: [unit-c]             ← 依赖 unit-a
层 2: [unit-d, unit-e]     ← 依赖 unit-c

复杂度层级

不同层级获得不同的流水线深度：

层级	流水线阶段
trivial	实现 → 测试
small	实现 → 测试 → 代码审查
medium	研究 → 计划 → 实现 → 测试 → PRD 审查 + 代码审查 → 审查修复
large	研究 → 计划 → 实现 → 测试 → PRD 审查 + 代码审查 → 审查修复 → 最终审查

这防止了对简单更改进行昂贵操作，同时确保架构更改得到彻底审查。

分离的上下文窗口（消除作者偏见）

每个阶段在自己的智能体进程中运行，拥有自己的上下文窗口：

阶段	模型	用途
研究	Sonnet	读取代码库 + RFC，生成上下文文档
计划	Opus	设计实现步骤
实现	Codex	按照计划编写代码
测试	Sonnet	运行构建 + 测试套件
PRD 审查	Sonnet	规范合规性检查
代码审查	Opus	质量 + 安全检查
审查修复	Codex	处理审查问题
最终审查	Opus	质量门控（仅 large 层级）

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

带驱逐的合并队列

质量流水线完成后，单元进入合并队列：

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

文件重叠智能：

不重叠的单元投机性地并行落地
重叠的单元逐个落地，每次变基

驱逐恢复：
当被驱逐时，捕获完整上下文（冲突文件、差异、测试输出）并在下一次 Ralph 轮次中反馈给实现者：

## 合并冲突 — 在下次落地前解决

你之前的实现与另一个先落地的单元冲突。
重构你的更改以避免下面冲突的文件/行。

{包含差异的完整驱逐上下文}

阶段间的数据流

research.contextFilePath ──────────────────→ plan
plan.implementationSteps ──────────────────→ implement
implement.{filesCreated, whatWasDone} ─────→ test, reviews
test.failingSummary ───────────────────────→ reviews, implement（下一轮）
reviews.{feedback, issues} ────────────────→ review-fix → implement（下一轮）
final-review.reasoning ────────────────────→ implement（下一轮）
evictionContext ───────────────────────────→ implement（合并冲突后）

工作树隔离

每个单元在隔离的工作树中运行（使用 jj/Jujutsu，而非 git）：

/tmp/workflow-wt-{unit-id}/

同一单元的流水线阶段共享一个工作树，在研究 → 计划 → 实现 → 测试 → 审查过程中保持状态（上下文文件、计划文件、代码更改）。

关键设计原则

确定性执行 — 预先分解锁定并行性和顺序
在杠杆点进行人工审查 — 工作计划是单一最高杠杆的干预点
关注点分离 — 每个阶段在单独的上下文窗口中，使用单独的智能体
带上下文的冲突恢复 — 完整的驱逐上下文支持智能重运行，而非盲目重试
层级驱动深度 — 琐碎更改跳过研究/审查；大型更改获得最大审查
可恢复工作流 — 完整状态持久化到 SQLite；可从任何点恢复

何时使用 Ralphinho vs 更简单的模式

信号	使用 Ralphinho	使用更简单的模式
多个相互依赖的工作单元	是	否
需要并行实现	是	否
合并冲突可能	是	否（顺序即可）
单文件更改	否	是（顺序流水线）
多日项目	是	可能（continuous-claude）
规范/RFC 已编写	是	可能
快速迭代单一事物	否	是（NanoClaw 或流水线）

选择合适的模式

决策矩阵

任务是单个聚焦的更改吗？
├─ 是 → 顺序流水线或 NanoClaw
└─ 否 → 是否有书面的规范/RFC？
         ├─ 是 → 是否需要并行实现？
         │        ├─ 是 → Ralphinho（DAG 编排）
         │        └─ 否 → Continuous Claude（迭代 PR 循环）
         └─ 否 → 是否需要同一事物的多种变体？
                  ├─ 是 → 无限智能体循环（规范驱动生成）
                  └─ 否 → 带去冗余的顺序流水线

组合模式

这些模式可以很好地组合：

顺序流水线 + 去冗余 — 最常见的组合。每个实现步骤都有一个清理步骤。
Continuous Claude + 去冗余 — 每次迭代添加带有去冗余指令的 --review-prompt。
任何循环 + 验证 — 在提交前使用 ECC 的 /verify 命令或 verification-loop 技能作为门控。

Ralphinho 的分层方法用于更简单的循环 — 即使在顺序流水线中，你也可以将简单任务路由到 Haiku，复杂任务路由到 Opus：

# 简单的格式化修复
claude -p --model haiku "修复 src/utils.ts 中的导入顺序"

# 复杂的架构更改
claude -p --model opus "重构 auth 模块以使用策略模式"

反模式

常见错误

没有退出条件的无限循环 — 始终设置 max-runs、max-cost、max-duration 或完成信号。
迭代间没有上下文桥接 — 每次 claude -p 调用都是全新的。使用 SHARED_TASK_NOTES.md 或文件系统状态来桥接上下文。
重试相同的失败 — 如果一次迭代失败，不要只是重试。捕获错误上下文并将其输入下一次尝试。
使用负面指令而非清理步骤 — 不要说“不要做 X”。添加一个单独的步骤来移除 X。
所有智能体在同一个上下文窗口中 — 对于复杂工作流，将关注点分离到不同的智能体进程中。审查者永远不应是作者。
忽略并行工作中的文件重叠 — 如果两个并行智能体可能编辑同一个文件，你需要一个合并策略（顺序落地、变基或冲突解决）。

参考

项目	作者	链接
Ralphinho	enitrat	致谢：@enitrat
无限智能体循环	disler	致谢：@disler
Continuous Claude	AnandChowdhary	致谢：@AnandChowdhary
NanoClaw	ECC	此仓库中的 `/claw` 命令
验证循环	ECC	此仓库中的 `skills/verification-loop/`

你可能还喜欢

ponytail-help

84Kagent-workflows

Quick-reference card for all ponytail modes, skills, and commands. One-shot display, not a persistent mode. Trigger: /ponytail-help, "ponytail help", "what ponytail commands", "how do I use ponytail".

dietrichgebert

获取

changelog-generator

68Kagent-workflows

Automatically creates user-facing changelogs from git commits by analyzing commit history, categorizing changes, and transforming technical commits into clear, customer-friendly release notes. Turns hours of manual changelog writing into minutes of automated generation.

composiohq

获取

planning-with-files-zht

25Kagent-workflows

基於 Manus 風格的檔案規劃系統，用於組織和追蹤複雜任務的進度。建立 task_plan.md、findings.md 和 progress.md 三個檔案。當使用者要求規劃、拆解或組織多步驟專案、研究任務或需要超過5次工具呼叫的工作時使用。支援 /clear 後的自動會話恢復。觸發詞：任務規劃、專案計畫、制定計畫、分解任務、多步驟規劃、進度追蹤、檔案規劃、幫我規劃、拆解專案

othmanadi

获取

继续探索

浏览 agent-workflows 热门 Skills 最近更新

autonomous-loops

相关 Skills

自主循环技能

何时使用

循环模式谱系

1. 顺序流水线 (claude -p)

核心见解

关键设计原则

变体

2. NanoClaw REPL

工作原理

NanoClaw vs 顺序流水线

3. 无限智能体循环

架构：双提示系统

模式

通过 Claude Code 命令实现

批处理策略

关键见解：通过分配实现唯一性

4. 持续 Claude PR 循环

核心循环

安装

用法

跨迭代上下文：SHARED_TASK_NOTES.md

CI 失败恢复

完成信号

关键配置

5. 去冗余模式

问题

为什么不用负面指令？

解决方案：分离步骤

在循环上下文中

关键见解

6. Ralphinho / 基于 RFC 的 DAG 编排

架构概览

RFC 分解

复杂度层级

分离的上下文窗口（消除作者偏见）

带驱逐的合并队列

阶段间的数据流

工作树隔离

关键设计原则

何时使用 Ralphinho vs 更简单的模式

选择合适的模式

决策矩阵

组合模式

反模式

常见错误

参考

你可能还喜欢

ponytail-help

changelog-generator

planning-with-files-zht

继续探索

1. 顺序流水线 (`claude -p`)