自主迴圈技能
相容性說明 (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 "檢閱所有更改是否有安全性問題、競爭條件和邊界情況..."
搭配環境上下文：
# 透過檔案傳遞上下文，而不是提示長度
"專注領域：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 個 |
| 無限 | 每批 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，修復任何失敗"
# 透過工作目錄並行
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 驅動、多智能體管道，用於在大型、平行化功能工作上進行協作。由 Ralphpinho 開發（致謝：@ralphipinho）。
架構：RFC 驅動
flowchart TD
A[RFC 規格] --> B[解析/驗證 RFC]
B --> C[分解為任務]
C --> D{依賴圖}
D --> E[任務批次 1]
D --> F[任務批次 2]
E --> G[智能體 A]
E --> H[智能體 B]
F --> I[智能體 C]
G --> J[合併閘道]
H --> J
I --> J
J --> K[最終檢閱/整合]
K --> L[PR]
運作方式
- RFC 規格 — 一個規範性文件，定義要建構的內容，包括 API 合同、資料模型和接受標準
- 解析/驗證 — 系統讀取 RFC，驗證其結構，並識別缺失的細節
- 任務分解 — RFC 被分解為具有明確依賴關係的獨立任務
- DAG 建構 — 建構一個有向無環圖（DAG），其中任務是節點，依賴關係是邊
- 平行執行 — 在 DAG 上執行拓撲排序。獨立的任務批次可以平行運行
- 合併閘道 — 一個專用智能體將來自不同分支的平行工作整合，解決衝突
- 最終檢閱 — 全面檢閱所有合併後的更改
依賴關係
| 需求 | 原因 |
|---|---|
| RFC 規格文件 | 嚴格定義所需內容，無模糊空間 |
| 合併佇列或工作流程 | 避免衝突，特別是在多個 PR 平行進行時 |
| 強制程式碼所有權 | 將智能體分配到他們具有專業知識的領域 |
核心運作
此模式嚴重依賴於 RFC 流程。關鍵步驟是建立一個詳盡的 RFC 文件，詳細說明規格，使其無需進一步澄清即可操作。然後將其分解為具有追蹤依賴關係的任務。最後，一個合併閘道智能體協調將所有內容整合在一起。
相關指令存在於原始儲存庫中，但核心模式保持不變。
選擇您的模式
以下是快速決策指南：
| 如果您需要... | 使用這個... |
|---|---|
| 快速、一次性自動化 | 順序管道 (claude -p) |
| 互動式探索與持久性 | NanoClaw REPL |
| 平行內容生成 | 無限智能體迴圈 |
| 持續開發與 CI 閘道 | 持續 Claude PR 迴圈 |
| 更整潔的實作（避免冗餘） | 去蕪存菁模式（附加） |
| 大型功能，多個團隊/智能體 | RFC 驅動 DAG 編排 |
最終建議： 從最簡單的起點開始。只有在需求要求時才增加複雜性。
claude -p管道在您的設置中有很長的路要走。