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 "為所有暫存變更建立 conventional commit。使用 '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 與序列化管線的比較

使用情境	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，並在安裝前檢視程式碼。不要直接將外部腳本 pipe 到 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，修復任何失敗"

# 透過 worktree 平行執行
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 "修復問題追蹤器中的所有錯誤" \
  --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 worktree 平行執行
`--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 層（依序，按依賴關係）：                │
│                                                      │
│  ┌── 品質管線（每個單元平行） ─────────────────────┐  │
│  │  每個單元在自己的 worktree 中：                  │  │
│  │  研究 → 規劃 → 實作 → 測試 → 審查               │  │
│  │  （深度依複雜度層級而異）                        │  │
│  └────────────────────────────────────────────────┘  │
│                                                      │
│  ┌── 合併佇列 ─────────────────────────────────────┐  │
│  │  基於 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 (合併衝突後)

Worktree 隔離

每個單元在隔離的 worktree 中執行（使用 jj/Jujutsu，而非 git）：

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

同一單元的管線階段共享一個 worktree，在研究 → 規劃 → 實作 → 測試 → 審查之間保留狀態（上下文檔案、計畫檔案、程式碼變更）。

關鍵設計原則

確定性執行 — 預先分解鎖定了平行性與順序
在槓桿點進行人工審查 — 工作計畫是單一最高槓桿的干預點
關注點分離 — 每個階段在獨立的上下文視窗中，使用獨立的代理
附帶上下文的衝突復原 — 完整的驅逐上下文能實現智慧重跑，而非盲目重試
層級驅動的深度 — 瑣碎變更跳過研究/審查；大型變更獲得最大程度的審查
可恢復的工作流程 — 完整狀態持久化到 SQLite；可從任何點恢復

何時使用 Ralphinho 與更簡單的模式

訊號	使用 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

相關技能

自主循環技能

使用時機

循環模式光譜

1. 序列化管線 (claude -p)

核心見解

關鍵設計原則

變體

2. NanoClaw REPL

運作方式

NanoClaw 與序列化管線的比較

3. 無限代理循環

架構：雙提示系統

模式

透過 Claude Code 指令實作

批次策略

關鍵見解：透過指派確保獨特性

4. 持續 Claude PR 循環

核心循環

安裝

使用方式

跨迭代上下文：SHARED_TASK_NOTES.md

CI 失敗復原

完成訊號

關鍵設定

5. 去鬆散模式

問題

為什麼不使用負面指令？

解決方案：獨立環節

在循環中的應用

關鍵見解

6. Ralphinho / RFC 驅動 DAG 編排

架構概覽

RFC 分解

複雜度層級

獨立上下文視窗（消除作者偏誤）

具有驅逐機制的合併佇列

階段間的資料流

Worktree 隔離

關鍵設計原則

何時使用 Ralphinho 與更簡單的模式

選擇正確的模式

決策矩陣

組合模式

反模式

常見錯誤

參考資料

您可能也喜歡

ponytail-help

changelog-generator

planning-with-files-zht

繼續探索

1. 序列化管線 (`claude -p`)