什麼是迴圈工程？AI 代理程式定義

迴圈工程的意義

迴圈工程是設計 AI 代理程式重複執行週期的實務：定義喚醒條件、可存取的內容、檢查輸出的方法，以及停止條件。提示工程塑造傳送給模型的單一訊息。迴圈工程則塑造在您休息時傳送數千則訊息的流程。工作單位從提示移至迴圈。

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

這個術語為何在 2026 年出現

這個名稱目前正在公開領域中確立。GitHub 儲存庫 cobusgreyling/loop-engineering 在首次出現後的兩個月內突破 9,600 顆星（截至 2026 年 7 月），其標語是「停止提示。設計迴圈。取得分數。」它將這項轉變整理為 6 個組成部分：排程、worktrees、技能、plugins 與 connectors、子代理程式，以及儲存在對話外部的持久記憶。

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

我不再向 Claude 提示。我讓提示 Claude 的迴圈持續執行。

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

這兩個儲存庫都不是這項實務的創始者。任何執行過 nightly build、continuous integration 中的 linter，或會開立 ticket 的 cron job 的人，都已經熟悉其運作模式。新之處在於，迴圈中的工作執行者現在具有非確定性，因此周邊機制必須執行不同的工作。

迴圈的四個部分

每個能正常運作的迴圈都有這四個部分。缺少任何一個部分的迴圈，都可能在凌晨3點喚醒你。

• 觸發條件。 啟動一次執行的事件：計時器、webhook、新的 pull request 或警示。
• 邊界。 代理程式在這次執行期間可以存取的檔案、認證資訊和網路。
• 驗證。 透過結束代碼進行檢查，以決定保留或捨棄這次執行的輸出。
• 預算。 結束一次執行的 token、時間和費用上限，不論執行是否成功。

將這四項改以問題形式重新檢視，就能對任何準備讓其持續執行的代理程式進行設計審查。

觸發條件：喚醒代理程式的機制

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

將 unit 寫入 /etc/systemd/system/agent-loop.service：

[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

並將 timer 寫入 /etc/systemd/system/agent-loop.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 的重要性超乎預期：如果代理程式因等待輸入而掛起，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 設定 也適用於主機上的任何長時間執行工作，無論是否為代理程式。

界線：每次執行都使用自己的副本

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

界線也包括認證資訊。無人值守的迴圈會持有長效權杖，而每次執行都可能將權杖洩漏至日誌、提交或模型內容中。將權杖的權限限制在迴圈會操作的單一存放庫；可行時，讓代理程式自己的 shell 無法看到該權杖；在授予迴圈正式環境存取權前，請先閱讀如何避免 AI 代理程式接觸秘密。若需要更嚴格的隔離，請將整個迴圈放在每次執行後都能銷毀的一次性 VM中。

驗證：讓迴圈安全運作的閘門

這部分區分了迴圈與只會輸入指令的 cron 工作。代理程式的輸出是提案。閘門負責決定是否採用。

#!/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 在該指令碼中發揮實際作用。沒有 -e 時，失敗的 git fetch 會被忽略，執行流程會繼續使用過時的 origin/main。沒有 -u 時，變數名稱中的拼字錯誤會展開為空字串，接著清理作業會針對錯誤路徑執行，而不是明確失敗。

if ! npm test 區塊就是整體概念。由你已信任的檢查項目之結束代碼決定要推送或刪除分支；這些檢查項目可以是測試套件或型別檢查器。沒有閘門的迴圈會產生沒有人力審查的工作，這比完全不產生工作更糟。具備閘門的迴圈會產生已通過相同標準的分支，而人工作者提交的分支也必須通過該標準。

請選擇能如實失敗的閘門。若測試套件在差異為空時仍會通過，迴圈就會將不做任何事視為成功。測試薄弱的儲存庫會產生薄弱的迴圈，因此熱門儲存庫會先要求「讓程式碼庫適合代理程式」，再要求「撰寫迴圈」。

預算：停止執行的機制

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

成本是迴圈通常優於單一長時間工作階段的原因。每次從初始狀態開始、執行一項明確的小工作後結束的執行，其內容量較小。持續開啟 8 小時的工作階段會保留先前的所有錯誤，並在每個回合中為完整逐字記錄付費。

趨勢儲存庫所歸納的模式

loop-engineering 儲存庫列出七種生產環境模式。與其把它們視為宣言，不如把它們當成選單來閱讀。每日分流。監看審查留言並回覆的 pull request 待命程序。接手失敗建置的持續整合清理程序。相依性清理程序。變更記錄起草程序。合併後清理。議題分流。

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

它們也都有書面記錄。這兩個儲存庫都會將狀態移出對話，寫入儲存庫中的檔案：執行了什麼、找到什麼，以及做了什麼決定。該檔案就是迴圈的記憶，也是第二個迴圈能以第一個迴圈的工作為基礎，而不必重新探索的原因。這也是事後稽核代理程式的方式，因為執行結束後，模型的內容脈絡就會消失。

循環失效的原因

這些失敗原因很乏味，而且各團隊反覆遇到。

• 沒有閘門。 輸出持續累積，沒有人檢閱，信任因此崩潰，最後停用循環。
• 重疊執行。 同一個分支上同時執行兩次，或兩個代理程式在同一個工作樹中執行，產生衝突後，代理程式還會嘗試解決這些衝突。
• 無聲偏移。 循環持續通過，因為檢查條件太寬鬆，無法判定失敗。
• 範圍無限制。 在繁忙的儲存庫中，每次提交都觸發的程序，會在一天內演變成支出問題。

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

從不熟悉術語開始

您不需要使用框架。一台持續運作的小型 Linux 伺服器、一個在應該失敗時其測試套件確實會失敗的 git 儲存庫、一個 systemd 計時器，以及一個內含 if 的 shell 指令碼，就能構成完整的循環。這確實是大多數人應該採用的起點，因為設計問題應透過實際執行來解決，而不是先選擇工具。當一個循環穩定後，執行第二個循環大多只需要再新增一個計時器和另一個 worktree。請參閱如何在 VPS 上執行 coding AI agent以了解基本設定；如果您希望讓 agent 本身在您控制的硬體上執行，請參閱目前可自行託管的 AI agent 選項。

FAQ

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

提示工程會最佳化單一訊息，包括措辭、範例和輸出格式。迴圈工程則會最佳化訊息周圍的循環，包括啟動執行的觸發條件、執行所在的沙箱、接受或拒絕輸出的檢查，以及結束執行的預算。您仍需要在迴圈中提供良好的提示。提示不再是您每天調整的主要項目，因為閘門和觸發條件對結果的影響更大。

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

不需要。systemd timer、每次執行各自使用的 git worktree、以測試命令結尾的 shell script，以及 provider account 上的支出上限，就能涵蓋定義中的所有部分。框架會加入排程介面、共用記憶體格式和多代理程式路由；當您執行多個迴圈時，這些功能很有用。但建立第一個迴圈不需要先使用框架。

什麼是程式碼庫 harness？

這是讓代理程式在沒有人工介入時於 repository 中工作的各項要素，包括單一命令的設定方式、可在非互動模式執行且會明確失敗的測試、linter，以及部署或預覽變更的方法。這個術語與迴圈工程一樣，源自 2026 年興起的 repository 實務。實際判斷方式很簡單：如果新的人工貢獻者無法用一個命令從 clone 進入測試通過的狀態，代理程式也無法做到。

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

在 3 個地方設定上限。於 systemd unit 上設定 TimeoutStartSec，讓卡住的執行程序遭到終止。在 script 內限制重試次數，不要持續迴圈直到成功。在 API account 上設定硬性支出上限，因為這是代理程式無法透過說服方式繞過的唯一上限。接著記錄每次執行的成本，因為成本加倍的迴圈，通常是範圍在不知不覺中擴大的迴圈。

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

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