自主循環技能
相容性說明 (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 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 檢查 (poll 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，修復任何失敗"
# 透過工作樹平行執行
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 - 使用 CI 修復上下文產生新的
claude -p - 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 "執行建置 + Lint + 測試。修復任何失敗。"
# 提交
claude -p "提交，訊息為：feat: add $feature"
done
關鍵洞見
與其加入對下游品質有影響的負面指令，不如加入一個獨立的抗拖沓環節。兩個專注的代理勝過一個受限的代理。
6. Ralphinho / RFC 驅動 DAG 編排
最複雜的模式。 一個由 RFC 驅動、多代理的管道，
…
[為翻譯而截斷]