什麼是迴圈工程？AI agent 定義與 4 大要素

迴圈工程的意義

迴圈工程是設計 AI agent 執行之重複週期的實務：決定什麼會喚醒它、它可以存取哪些內容、如何檢查輸出，以及什麼條件會停止它。提示工程塑造傳送給模型的單一訊息；迴圈工程則塑造一個在你休息時傳送數千則訊息的流程。工作的單位從提示轉移到迴圈。

簡而言之，你不再只是撰寫指示，而是開始撰寫控制系統。agent 仍需要良好的指示，但指示會成為週期中的一個元件。這個週期依排程執行，在隔離的程式碼副本中運作，透過測試證明自身結果，並在預算用盡時停止。

此名稱在 2026 年出現的原因

這個名稱目前正在公開討論中定型。GitHub 儲存庫 cobusgreyling/loop-engineering 首次出現後不到兩個月，星數就突破 9,600（截至 2026 年 7 月）；在 2026-10-27 約有 11,600 顆星，並以「不要再撰寫提示。設計迴圈。取得分數。」為標語。2026 年 7 月時，其 README 將這項轉變整理為 6 個構成要素：排程、worktree、技能、外掛與連接器、子代理程式，以及儲存在對話之外的持久記憶。目前的 README 已不再列出這份清單（於 2026-10-27 檢查），但仍將迴圈狀態保存在對話之外的檔案中。

該儲存庫將 Anthropic Claude Code 負責人 Boris Cherny 列為靈感來源之一。他廣為報導的一句話是：

我不再向 Claude 撰寫提示。我讓迴圈持續執行，替我向 Claude 撰寫提示。

另一個儲存庫 AI-Builder-Club/skills 目前約有 1,300 顆星（截至 2026-10-27），並直接說明這兩種角色：「codebase harness」讓代理程式能在安全的儲存庫環境中執行測試與部署；「loop engineer」則建立工作流程，讓流程在觸發條件出現時喚醒、執行工作，並將學到的內容寫入共用檔案，供下一個迴圈讀取。

這兩個儲存庫都不是這種實務的發明者。任何執行過夜間建置、持續整合中的 linter，或會建立 ticket 的 cron job 的人，都已經熟悉這種結構。新的地方在於，迴圈中的工作者現在具有非決定性，因此周邊機制必須執行的工作也隨之改變。

迴圈的 4 個部分

每個可正常運作的迴圈都包含以下 4 個部分。缺少其中任何一個部分，都可能讓迴圈在凌晨 3 點喚醒你。

• 觸發條件。 啟動一次執行的事件，例如計時器、webhook、新的 pull request 或警示。
• 邊界。 代理程式在該次執行期間可存取的檔案、憑證與網路範圍。
• 驗證。 透過結束碼判斷該次執行的輸出應予保留或捨棄的檢查。
• 預算。 限制 token、時間與費用的上限。無論執行是否成功，達到上限後都會結束該次執行。

將這 4 個部分改寫成問題後逐一檢視，就能對即將持續執行的任何代理程式進行設計審查。

觸發條件：什麼會喚醒代理程式

計時器是最簡單的觸發方式。在 Linux 伺服器上，systemd timer 比 cron 更適合，因為它會記錄日誌、可依你的設定重試，而且不會啟動仍在執行中的 unit 的第二個副本。最後這項特性可避免代理程式迴圈最常見的重疊錯誤：兩次執行同時編輯相同的分支。

先為代理程式建立專用使用者。該使用者是隔離邊界的一部分，因此只擁有 /srv/agent：

sudo useradd --system --home-dir /srv/agent --shell /usr/sbin/nologin agent
sudo chown -R agent:agent /srv/agent

接著在 /etc/systemd/system/agent-loop.service 建立 unit：

[Unit]
Description=Agent loop: triage open issues
After=network-online.target
Wants=network-online.target

[Service]
Type=oneshot
User=agent
WorkingDirectory=/srv/agent/repo
ExecStart=/srv/agent/bin/loop.sh
TimeoutStartSec=1800

再在 /etc/systemd/system/agent-loop.timer 建立 timer：

[Unit]
Description=Run the triage loop every 30 minutes

[Timer]
OnBootSec=5min
OnUnitActiveSec=30min
Unit=agent-loop.service

[Install]
WantedBy=timers.target

sudo systemctl daemon-reload
sudo systemctl enable --now agent-loop.timer
systemctl list-timers agent-loop.timer

systemctl list-timers 應顯示含有未來時間的 NEXT 欄，以及倒數計時的 LEFT 欄。結果為空表示 timer 未啟用，因為 enable 不搭配 --now 時，只會安排在下一次開機執行。TimeoutStartSec=1800 的重要性超乎表面。Type=oneshot 服務會持續被視為啟動中，直到其指令碼結束；systemd 預設會停用 oneshot unit 的啟動逾時。因此若沒有這一行，代理程式在等待輸入時卡住，unit 會永遠停留在 activating 狀態，而之後每次 timer 觸發時都會發現它仍在執行，因而不會啟動任何工作。加入這一行後，systemd 會在 30 分鐘後終止此次執行，並將其標記為失敗。若日後將 unit 改為預設的 Type=simple，TimeoutStartSec 就不再涵蓋實際執行時間，此時負責限制執行時間的是 RuntimeMaxSec=。使用 journalctl -u agent-loop.service -n 50 檢視一次執行。

若改用 cron 驅動迴圈，請自行加入防止重疊的機制，因為 cron 會直接啟動第二個副本：

*/30 * * * * /usr/bin/flock -n /tmp/agent-loop.lock /srv/agent/bin/loop.sh

持有鎖定時，flock -n 會立即以狀態 1 結束，因此第二次執行會安靜地消失，不會與第一次執行發生競爭。同樣的 systemd 服務與計時器設定 也適用於主機上的任何長時間執行工作，不論是否為代理程式。

邊界：為每次執行建立獨立副本

會修改工作樹的代理程式可能會遺失尚未提交的工作。Git worktree 能以低成本解決這個問題：每次執行都有自己的目錄和分支，但共用同一個物件儲存區。

cd /srv/agent/repo
git worktree add -b loop/triage-01 /srv/agent/work/triage-01 origin/main
git worktree list

git worktree list 會逐行輸出每個樹狀工作區的路徑、提交與分支。執行結束時，git worktree remove /srv/agent/work/triage-01 會移除 worktree，但只會移除乾淨的 worktree。如果樹狀工作區包含未追蹤檔案、已修改的追蹤檔案或子模組，Git 會拒絕移除，除非加入 --force；因此，下方的閘道腳本只會在要捨棄該次執行的路徑上強制移除。git worktree prune 會清除目錄已消失的項目。此時，平行迴圈就能安全執行，因為兩個代理程式分別在兩個分支和兩個目錄中工作，不會互相覆寫。

這個邊界也涵蓋憑證。無人值守的迴圈會持有長效 token，而每次執行都有可能將 token 洩漏到日誌、提交或模型上下文中。將 token 的權限限定在迴圈會操作的單一 repository；在可行的情況下，避免讓代理程式自己的 shell 看到該 token 所在的環境變數；在授予迴圈正式環境存取權前，請先閱讀 如何避免 AI 代理程式接觸機密。若需要更嚴格的隔離，可將整個迴圈放在 每次執行後都能銷毀的一次性 VM 中。你執行的工具也會在撰寫任何內容前決定部分隔離邊界，因此在決定要自行建立多少隔離措施前，值得先閱讀 Cowork 的受管沙箱與在自己電腦上執行的 Claude Code 有何差異。

驗證：讓迴圈安全運作的關卡

這部分是迴圈與只會執行命令的 cron job 之間的差異。agent 的輸出只是提案。關卡負責決定是否接受。

#!/usr/bin/env bash
set -euo pipefail

repo=/srv/agent/repo
branch="loop/$(date -u +%Y%m%dT%H%M%SZ)"
tree="/srv/agent/work/$(basename "$branch")"

cd "$repo"
git fetch --quiet origin
git worktree add -b "$branch" "$tree" origin/main
cd "$tree"

# the agent's own command runs here, in non-interactive mode

if ! npm test; then
  echo "gate failed: discarding $branch" >&2
  cd "$repo"
  git worktree remove --force "$tree"
  exit 1
fi

git push origin "$branch"
cd "$repo"
git worktree remove "$tree"

set -euo pipefail 在該 script 中負責實際工作。沒有 -e 時，失敗的 git fetch 會被忽略，執行流程會繼續使用過時的 origin/main。沒有 -u 時，變數名稱的拼字錯誤會展開成空字串，接著 cleanup 會對錯誤路徑執行，而不是明確失敗。最後一行刻意不使用 --force：如果這次執行在工作樹中留下未追蹤或未提交的檔案，git 會拒絕移除該檔案，而 -e 會在 push 完成後以錯誤結束執行流程，不會靜默刪除任何人尚未提交的工作。

if ! npm test 區塊就是整個概念。由你信任的檢查結果，例如測試套件或型別檢查器的 exit code，決定是否推送或銷毀該分支。沒有關卡的迴圈會產生沒有人力審查的工作，這比完全不產生工作更糟。具備關卡的迴圈會產生已通過與人工貢獻者分支相同標準的分支。關卡顯示綠燈，並不代表 agent 為此修改了多少程式碼，因此值得搭配一項固定指示，例如 要求 agent 採用可行的最小變更的規則，讓 diff 維持足夠精簡，使審查成本保持在可接受範圍。

請選擇能如實失敗的關卡。在空 diff 上也會通過的測試套件，會讓迴圈認為不做任何事也是成功。測試薄弱的 repository 會產生薄弱的迴圈，因此熱門 repository 會先要求「讓程式碼庫適合 agent 使用」，再要求「撰寫迴圈」。如果你想知道測試套件是否真的能偵測 regression，而不只是執行相關程式碼，mutation testing 就是能回答這個問題的檢查；而 交付可重新執行的證據報告、而不是要求你閱讀 diff 的 agent，能讓你自行確認這項結果。

預算：什麼因素會停止執行

無限重試的代理程式，會產生無上限的費用。為每個迴圈設定實際時間上限，並由上方的 TimeoutStartSec 強制執行；在指令碼中設定重試次數；再由供應商帳戶設定支出上限。接著記錄每次執行的費用，這樣就能在帳單反映之前，發現迴圈是否逐漸偏離預期。永遠運作的代理程式 VPS 成本控管說明帳務管理，管理代理程式在回合之間保留的內容說明如何控制每次執行的最大單一成本因素，因為每 30 分鐘重新讀取相同儲存庫的迴圈，每 30 分鐘都會為此付費。

成本是迴圈通常優於單次長時間工作階段的原因。每次執行都從空白狀態開始，完成一項範圍狹窄的工作後結束，可以維持較小的上下文。持續開啟 8 小時的工作階段，會在歷史記錄中保留先前的每個錯誤，並在每個回合為完整逐字記錄付費。

熱門儲存庫整理出的模式

截至 2026-10-27，loop-engineering 儲存庫列出 8 種正式環境模式。與其把它們當成宣言，不如視為可選用的清單。每日分類。一個以 GitHub Action 執行且不保留狀態檔案的精簡迴圈。持續監看審查留言並回覆的 pull request 維護程式。接手失敗建置的持續整合清理程式。相依性清理程式。變更日誌草稿產生器。合併後清理。Issue 分類。

這些模式的共同點，是工作範圍狹窄，且有明確的閘門。「修正失敗的建置」具有機器可以讀取的通過條件。「改善程式碼庫」則沒有，因此永遠不會成為迴圈。它只會變成一個依排程執行的混亂工作。

它們也都有書面紀錄。兩個儲存庫都將狀態移出對話，寫入儲存庫中的檔案：執行了什麼、找到什麼、決定了什麼。該檔案就是迴圈的記憶，也是第二個迴圈能以第一個迴圈的工作為基礎，而不必重新探索的原因。這也是事後稽核代理程式的方式，因為執行結束後，模型的上下文就會消失。即時協調是另一個通道；同一台主機上的一個 Claude Code 工作階段可以將工作交給另一個工作階段，即使兩者仍在執行也是如此。但這項交換中的任何內容都無法在任一工作階段結束後保留，因此檔案仍是日後可回頭讀取的部分。

迴圈失效的原因

這些失敗原因很普通，而且會在不同團隊中反覆出現。

• 沒有閘門。 輸出持續累積，沒有人檢視，信任逐漸崩解，最後停用迴圈。
• 重疊執行。 同一個分支同時執行兩個工作，或兩個代理程式在同一個工作樹中執行，產生衝突後，代理程式還會嘗試自行解決。
• 無聲漂移。 檢查條件過於寬鬆，即使應該失敗，迴圈仍持續通過。
• 範圍無限制。 在忙碌的儲存庫中，每次提交都觸發的工作，可能在一天內變成成本問題。

每種情況都有相同的修正方式：縮小工作範圍、明確化檢查條件，並記錄每次執行。如果無法用一句話描述通過條件，就表示這項工作尚未準備好自動化。

從不熟悉術語開始

你不需要框架。一台持續運作的小型 Linux 伺服器、一個測試套件應在適當時失敗的 git repository、一個 systemd timer，以及一個包含 if 的 shell script，就能組成完整的迴圈。這確實是多數人應採用的起點，因為設計問題應透過實際執行來解決，而不是先選定工具。當一個迴圈穩定後，執行第二個迴圈主要只需再建立一個 timer 和另一個 worktree。請參閱如何在 VPS 上執行 coding AI agent以完成基本設定；如果你希望讓 agent 本身在你能控制的硬體上執行，請參閱目前的 self-hosted AI agent 選項。

FAQ

迴圈工程與提示工程不同嗎？

提示工程最佳化的是單一訊息：措辭、範例與輸出格式。迴圈工程最佳化的是訊息周邊的週期：啟動一次執行的觸發條件、執行所處的沙箱、接受或拒絕輸出的檢查，以及結束執行的預算。迴圈內仍需要良好的提示。只是提示不再是日常調整的主要項目，因為閘門與觸發條件對結果的影響更大。

建立代理程式迴圈需要使用 framework 嗎？

不需要。systemd timer、每次執行各自使用的 git worktree、以測試指令結尾的 shell script，以及 provider account 上的支出上限，已涵蓋這項定義的所有部分。Framework 會加入排程介面、共享記憶體格式與多代理程式路由；當你執行多個迴圈時，這些功能很有用。但它們不是建立第一個迴圈的必要條件。

什麼是 codebase harness？

它是讓代理程式能在沒有人工介入的情況下處理 repository 的一組工具與設定：一個指令即可完成的設定流程、可非互動執行且會明確失敗的測試、linter，以及部署或預覽變更的方法。這個術語與迴圈工程一樣，源自 2026 年同一波 repository 發展。實際判斷很簡單：如果新的人工貢獻者無法用一個指令從 clone 進入測試通過的狀態，代理程式也無法做到。

如何避免代理程式迴圈產生高額費用？

在 3 個地方設定上限。對上方的 Type=oneshot systemd unit 設定 TimeoutStartSec，讓卡住的執行程序能被終止（對 Type=simple service，對應設定是 RuntimeMaxSec）。在 script 內限制重試次數，不要持續迴圈直到成功。在 API account 上設定硬性支出上限，因為這是代理程式無法透過說服來突破的唯一上限。接著記錄每次執行的費用，因為成本加倍的迴圈，通常代表其範圍在不知不覺間擴大。

哪些工作適合優先轉成迴圈？

選擇具備機器可讀的通過條件，且影響範圍較小的工作。修復失敗的 build、更新相依套件，以及重新產生 changelog 都符合，因為測試套件或 diff 可以驗證結果。重構或設計等開放式工作目前不適合，因為沒有可供閘門檢查的內容；沒有閘門的迴圈，只會以高昂成本製造更多待審查工作。