@omarsar0：從 Prompting Agents 到 Loop Engineering AI 程式開發圈流傳著一個說法：別再對你的程式開發 Agent 下 Promp…

從 Prompting Agents 到 Loop Engineering AI 程式開發圈流傳著一個說法：別再對你的程式開發 Agent 下 Prompt 了，開始設計能替你下 Prompt 的「迴圈（Loop）」吧。就像所有新事物一樣，這類觀點總是被反覆提及，卻鮮少有人解釋清楚。這是一篇實務指南，說明什麼是 Agent 迴圈、為什麼它很重要，以及在生產環境中它長什麼樣子。 以下是我從與學生、技術創辦人、AI 工程師及新創公司進行的實驗、研究與對談中整理出的心得（由 Claude 協助撰寫）。 你也可以將我們最近的直播課程「自主長效型程式開發 Agent（Autonomous Long-Running Coding Agents）」作為切入點，深入了解這些概念。 這個說法的由來 「你不需要再對程式開發 Agent 下 Prompt 了。你應該設計能對 Agent 下 Prompt 的迴圈。」—— Peter Steinberger (@steipete)，2026 年 6 月 7 日。220 萬次觀看。原始推文 Claude Code 的開發者 Boris Cherny 也從另一個角度提出了相同的觀點。 「我不再對 Claude 下 Prompt 了。我執行的是迴圈。是這些迴圈在對 Claude 下 Prompt 並決定該做什麼。我的工作是撰寫迴圈。」—— Boris Cherny (@bcherny)。原始推文 重點並非 Prompt Engineering 已死。透過 Loop Engineering，工作層級向上提升了：從撰寫程式碼轉變為撰寫「負責撰寫程式碼的系統」。在這個領域進展最快的開發者表示，他們曾有數個月的時間，在完全沒開啟 IDE 的情況下發送了數百個 PR，每一行程式碼皆由 Agent 完成。 什麼是迴圈（Loop）？ 迴圈是一個你撰寫的小型程式，它執行四件事： 替你向程式開發 Agent 下 Prompt； 讀取 Agent 的產出； 判斷任務是否完成； 若未完成，則帶著錯誤訊息或下一步指令再次向它下 Prompt。 你不再需要坐在迴圈裡手動輸入 Prompt；你撰寫迴圈，而模型則成為該迴圈呼叫的一個子常式（subroutine）。 展開畫面重點該流程圖由四個主要節點組成，箭頭指示了處理順序： 「goal + state」（目標與狀態）：流程的起點。 「act」（執行）：包含「edit / run / tool」（編輯／執行／工具）功能。 「check」（檢查）：包含「tests / verifier」（測試／驗證器）功能。 「stop + report」（停止與報告）：流程的終點。 流程邏輯說明： 當「check」階段結果為「pass」（通過）時，流程會導向「stop + report」。 當「check」階段失敗時，會透過一條虛線箭頭回饋至「act」階段，標註文字為「fail: feed the error back」（失敗：將錯誤回饋）。 其運作模式始終如一：設定目標、執行、檢查、回饋錯誤，並重複此過程，直到檢查通過或迴圈自行停止。 「迴圈」至少代表五種含義 許多爭論源於人們用同一個詞指代五種不同的概念。以下是從最舊到最新的演進： 展開畫面重點該圖表以階梯狀呈現 AI 代理技術的發展歷程，從左下角的「較舊」技術演進至右上角的「較新」技術，並註明「每一階層都更具自主性」。圖中包含五個階段的節點： ReAct (2022, reason / act / observe) AutoGPT (2023, self-prompting goal) ralph loop (context reset each turn) /loop and /goal (cadence + completion built in) orchestration (one author, many agents) ReAct (2022)：最初的研究模式：推理（Reason）、行動（Act）、觀察（Observe），然後重複。 AutoGPT (2023)：一個自我 Prompt 的目標迴圈，以「不知道何時該停止」而聞名。 ralph 迴圈：在每次迭代之間刻意重置 context，避免 Agent 淹沒在自己的歷史紀錄中。 /loop 與 /goal：將節奏與完成條件內建於 Agent 中，並在不同回合間維持狀態。 Orchestration（編排）：由一個主控端分派多個 Agent，讀取你的 GitHub、Slack 與聊天紀錄，並決定下一步該建構什麼。 你實際組裝的零件 上述演進解釋了人們口中的「迴圈」意指為何；以下是建構迴圈所需的基礎。這六個零件在每次組裝時都會出現，且現在大多數已內建於程式開發工具中，不再需要你自行維護自訂腳本。 展開畫面重點圖片標題為「The six parts you assemble into a loop」（你組裝成迴圈的六個部分），內容包含六個編號項目： Trigger（觸發器）：包含 schedule（排程）、webhook、PR label（PR 標籤）。 Isolation（隔離）：包含 a git worktree per agent（每個代理一個 git 工作樹）。 Written-down context（書面上下文）：包含 conventions it reads each run（每次執行時讀取的慣例）。 Tool access（工具存取）：包含 issue tracker（問題追蹤）、CI、DB（資料庫）、chat（聊天）。 A second agent（第二個代理）：包含 grades the work, held apart（評分工作，並保持分開）。 State on disk（磁碟上的狀態）：包含 markdown、board（看板）、queue（佇列）。 觸發器（Trigger）：無需你手動啟動，就能自動開始迴圈的機制：排程、webhook、檔案變更，或 PR 被貼上標籤。這是區分「真實迴圈」與「手動重複執行」的關鍵。 隔離（Isolation）：每個 Agent 擁有獨立的 checkout（通常是 git worktree），確保同時執行的兩個 Agent 不會覆寫彼此的檔案。一旦你同時執行超過一個 Agent，這就不再是選項，而是必要條件。 書面化的 context：將慣例、建置步驟與專案特定規則存放在 Agent 每次執行時都能讀取的地方。若忽略此點，迴圈會在每次執行時重新推導你的專案，並對缺失的部分進行猜測。 工具存取權（Reach into your tools）：連接到 Issue Tracker、CI、資料庫與聊天軟體，讓迴圈能直接開啟 PR、連結 Ticket 並發布結果，而不是只列印出修正方案，還要等你手動執行後續步驟。 第二個 Agent 檢查：由一個獨立的執行者評估輸出結果，且該執行者必須與產出結果的 Agent 分開，因為模型若審核自己的工作，幾乎所有內容都會通過。 磁碟上的狀態（State on disk）：Markdown 檔案、看板或佇列：任何存在於對話之外、能記錄「已完成」與「下一步」的媒介。模型在執行間會遺忘，但檔案不會。 組裝好這六個零件，你就為 Loop Engineering 打下了良好的基礎。過去你必須手動打造一切；現在大多數功能已作為內建特性提供，這也是為什麼這種模式已從邊緣技術轉變為常見用法。 具體迴圈範例：PR 保姆 一個你今天就能建構的具體範例： 展開畫面重點該圖表描述了一個名為「The PR babysitter, one scheduled run」的自動化工作流程，包含以下步驟與邏輯： 觸發機制：每 15 分鐘（every 15 min）進行一次排程觸發（scheduled trigger）。 篩選對象：針對標記為「agent-watch」的開啟中 PR（open PRs）。 診斷階段：進行診斷（diagnose），檢查 CI 是否失敗（CI red?）或主分支是否有變動（main moved?）。 執行動作：執行單次動作（act once），進行修復或重定基底（fix or rebase）。 停止條件：若 CI 顯示綠燈（CI green）則合併 PR；若預算耗盡（1 次修復、5 分鐘、10 個檔案）則停止並通知人類（stop and ping a human）。 觸發器：每 15 分鐘執行一次。 範圍：標記為 agent-watch 的開放 PR。 行動：若 CI 因為確定性原因失敗，嘗試一次修正。若主分支有更新，執行一次 rebase。 預算：每個 PR 僅限一次修正嘗試、五分鐘時間、變更十個檔案。 停止條件：CI 變為綠燈，或預算耗盡，隨後停止並通知人類。…