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

迴圈工程的意義

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

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

這個術語在 2026 年出現的原因

這個名稱目前正在公開討論中逐漸定型。GitHub 儲存庫 cobusgreyling/loop-engineering 在首次出現後不到兩個月內就突破 9,600 顆星（截至 2026 年 7 月），並以「不要再撰寫提示。設計迴圈。取得分數。」為標語。它將這項轉變歸納為 6 個構成要素：排程、worktree、技能、外掛程式與連接器、子代理程式，以及儲存在對話外部的持久記憶。

其中引用了 Anthropic Claude Code 負責人 Boris Cherny 的話：

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

另一個儲存庫 AI-Builder-Club/skills 擁有近 1,100 顆星（截至 2026 年 7 月），並直接說明這兩種角色：一種是「程式碼庫 harness」，負責讓代理程式能在安全的環境中對儲存庫執行測試與部署；另一種是「迴圈工程師」，負責建立會因觸發條件而啟動、執行工作，並將學到的內容寫入共用檔案，讓下一個迴圈讀取的工作流程。

這兩個儲存庫都不是這種實務的發明者。凡是執行過 nightly build、持續整合中的 linter，或會建立 ticket 的 cron job，都已經熟悉這種結構。新之處在於，迴圈中的工作者現在具有非決定性，因此周邊機制必須承擔不同的工作。

迴圈的 4 個部分

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

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

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

觸發方式：喚醒 agent 的機制

計時器是最簡單的觸發方式。在 Linux 伺服器上，systemd timer 比 cron 更適合此用途，因為它會記錄日誌、可依照你的設定重試，而且不會啟動仍在執行中的 unit 的第二個副本。最後這項特性可避免 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 的重要性超出表面：如果 agent 因等待輸入而卡住，unit 會一直保持 active，timer 也永遠不會再次觸發。使用 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 service 與 timer 設定 也適用於伺服器上的任何長時間執行工作，無論是否為 agent。

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

代理程式若會編輯你的工作樹，就可能覆寫尚未提交的工作。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 會刪除目錄，而 git worktree prune 會清除目錄已消失的項目。此時，平行迴圈便能安全執行，因為位於不同目錄、使用不同分支的兩個代理程式不會互相覆寫。

界線也涵蓋憑證。無人值守的迴圈會長時間持有 token，而每次執行都可能將 token 洩漏至日誌、提交內容或模型上下文。請將 token 權限限制在迴圈會存取的單一儲存庫；在可行時，避免讓代理程式自己的 shell 看見該 token 所在的環境。將迴圈授予正式環境存取權之前，請先閱讀 如何避免 AI 代理程式接觸機密。若需要更強的隔離，請將整個迴圈放在 每次執行後都能銷毀的一次性 VM 中。你使用的工具也會在撰寫任何程式碼之前決定部分隔離邊界，因此在決定需要自行建立多少隔離措施前，值得先閱讀 Cowork 的受管理 sandbox 與自行在電腦上執行 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 會對錯誤路徑執行，而不是明確失敗。

if ! npm test 區塊就是整個概念。由你已信任的檢查、測試套件或型別檢查器的結束狀態碼，決定要推送或刪除該分支。沒有閘門的迴圈會產生沒有人有時間審查的工作，這比不產生工作更糟。具有閘門的迴圈會產生一個已通過與人工貢獻者分支相同標準的分支。閘門顯示成功，不代表 agent 為此修改了多少程式碼。因此，最好搭配一項持續適用的指示，例如 要求 agent 採用可行的最小變更的規則，讓差異維持在足夠小的範圍內，使審查成本保持低廉。

請選擇能如實失敗的閘門。在空白差異上仍會通過的測試套件，會讓迴圈認為什麼都不做就是成功。測試薄弱的儲存庫會產生薄弱的迴圈，因此熱門儲存庫會先提出「讓程式碼庫適合 agent」，再提出「撰寫迴圈」。如果你想知道測試套件是否真的能捕捉回歸問題，而不只是執行相關程式碼，mutation testing 就是能回答這個問題的檢查；而 交回可重新執行的證據報告、而不是要求你閱讀差異的 agent，則能讓你自行確認結果。

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

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

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

熱門儲存庫所整理的模式

loop-engineering 儲存庫列出 7 種適用於正式環境的模式。與其把它們當成宣言，不如把它們視為可選用的工作清單。每日分類處理。監看程式碼審查留言並回覆的 pull request 監督器。接手失敗建置的持續整合清理器。相依性清理器。變更記錄草稿產生器。合併後清理。議題分類處理。

這些模式的共同點，是工作範圍狹窄，且有明確的通過條件。「修正失敗的建置」具備機器可讀的完成條件。「改善程式碼基礎」則沒有，因此永遠不會成為 loop。它只會變成排定時程的混亂工作。

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

迴圈失效的原因

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

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

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

從不熟悉術語開始

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

FAQ

Prompt engineering 和 loop engineering 有何不同？

Prompt engineering 最適合單一訊息：文字措辭、範例與輸出格式。Loop engineering 最適合圍繞訊息建立的循環：啟動一次執行的觸發條件、執行所在的 sandbox、接受或拒絕輸出的檢查，以及結束循環的預算。循環內仍需要良好的 prompt。prompt 不再是日常調整的主要對象，因為 gate 與 trigger 對結果的影響更大。

建立 agent loop 需要 framework 嗎？

不需要。每次執行使用一個 git worktree、以 systemd timer 啟動、以測試命令結束的 shell script，以及 provider 帳戶上的支出上限，就涵蓋了這項定義的所有部分。Framework 會加入排程介面、共用記憶體格式與多 agent 路由；當你執行多個 loop 時，這些功能很實用。但它們不是建立第一個 loop 的必要條件。

什麼是 codebase harness？

它是一組讓 agent 能在沒有人工介入的情況下處理 repository 的機制：單一命令的設定流程、可在非互動模式執行且會明確失敗的測試、linter，以及部署或預覽變更的方法。這個詞源自 2026 年同一波 repository 社群所形成的 loop engineering。實際判斷很簡單：如果新的人工貢獻者無法透過一個命令，從 clone repository 一路執行到測試通過，agent 也無法做到。

如何避免 agent loop 產生高額費用？

在 3 個位置設定上限。在 systemd unit 上設定 TimeoutStartSec，讓失控的執行能被終止。在 script 內限制重試次數，不要持續重試直到成功。在 API 帳戶上設定硬性支出上限，因為這是 agent 無法透過說服來突破的唯一上限。接著記錄每次執行的成本，因為成本加倍的 loop 通常代表其範圍在未察覺的情況下擴大。

哪些工作最適合優先改成 loop？

選擇具備機器可讀通過條件且影響範圍較小的工作。修正失敗的 build、更新 dependency 及重新產生 changelog 都符合，因為測試套件或 diff 可以證明結果。重構或設計等開放式工作目前不適合，因為沒有可供 gate 檢查的條件；沒有 gate 的 loop，只會以高昂成本累積待審查的變更。