# 策展 · X (Twitter) 🔥🔥 > 📖 本站完整內容索引（documentation index）：[llms.txt](/llms.txt) > 作者：Rahul (@sairahul1) · 平台：X (Twitter) · 日期：2026-06-10 > 原始來源：https://x.com/sairahul1/status/2064277888216555684 ## 中文摘要 # 迴圈：2026 年每位 AI 工程師都必須知道的事 ![Peter Steinberger 在 X 上分享觀點，認為開發者應從「提示工程」轉向「設計自動化循環」來驅動 AI 程式代理。](https://pub-75d4fe1e4e80421b9ecb1245a7ae0d1a.r2.dev/curated/1781062891731-iaHKTAqe3aMAE9yagjpg.jpg)
展開畫面重點
圖片為一則來自 X（原 Twitter）的推文截圖，發文者為 Peter Steinberger (@steipete)。 推文內容如下： 「Here's your monthly reminder that you shouldn't be prompting coding agents anymore. You should be designing loops that prompt your agents.」 （這是給您的每月提醒：您不應該再手動提示程式編寫代理了。您應該設計能自動提示代理的循環。） 推文下方顯示互動數據：444 則回覆、5.4K 個喜歡，發布時間為 2026 年 6 月 8 日凌晨 12:28。
Peter Steinberger 是 OpenClaw 的創辦人，目前任職於 OpenAI。 昨天他發布了這則貼文： > 「你不該再對程式開發 Agent 下 Prompt 了。你應該設計能驅動 Agent 的迴圈。」 接著，Anthropic 旗下 Claude Code 的負責人 Boris Cherny 也表達了類似的觀點，只是說法不同： > 「我不再對 Claude 下 Prompt 了。我讓迴圈執行，由迴圈來對 Claude 下 Prompt 並決定該做什麼。我的工作是撰寫迴圈。」 兩位當今頂尖的 AI 工程師，傳達了相同的訊息。 大多數人讀到這裡會想：這到底是什麼意思？ 我深入研究了這個概念。 以下是所有內容的簡化拆解。 沒有術語堆砌，只有你需要的思維模型。 收藏起來，這將改變你對 AI 的看法。 --- ## 但首先：為什麼大多數人從不建立迴圈 > 迴圈聽起來很棒，直到你看到帳單。 ![圖表指出循環運行（Loops）會快速消耗大量 Token 並導致預算枯竭，而 DeepSeek 透過其極低的定價（如 deepseek-v4-flash 的快取命中輸入每百萬 Token 僅需 $0.0028）提供了最便宜的循環解決方案。](https://pub-75d4fe1e4e80421b9ecb1245a7ae0d1a.r2.dev/curated/1781062891725-iaHKW9OcNboAA4Iqljpg.jpg)
展開數據表（1）The Token Problem
項目數值
One loop run50K-200K tokens
Fleet loopup to 2M tokens
Schedule running dailymillions/week
展開數據表（2）DeepSeek Pricing
MODELCONTEXT LENGTHMAX OUTPUT1M INPUT TOKENS (CACHE HIT)1M INPUT TOKENS (CACHE MISS)1M OUTPUT TOKENSConcurrency Limit(2)
deepseek-v4-flash(1)1MMAXIMUM: 384K$0.0028$0.14$0.282500
deepseek-v4-pro1MMAXIMUM: 384K$0.003625$0.435$0.87500
這是沒人會事先告訴你的真相。 一個針對中等程式開發任務的單一 Agent 迴圈：消耗 50,000 到 200,000 個 token。 一個包含排程器（Orchestrator）與 3 個專家的艦隊（Fleet）迴圈：消耗 500,000 到 2,000,000 個 token。 一個每天早上按排程執行的迴圈：每週消耗數百萬個 token。 以標準的 API 定價來看，一週認真的迴圈工程成本，比大多數人整個月的 AI 預算還要高。 這就是為什麼 Peter Steinberger 的回覆區充滿了這種聲音： > 「你當然說得輕鬆——你有無限的 OpenAI 使用權。」 他們沒說錯。 在一般預算下進行迴圈工程，很快就會破產。 每一次重試都要錢。每一次自我修正都要錢。每一個子 Agent 都要錢。每一次驗證過程都要錢。 那種自由探索的開放式迴圈？消耗 token 的速度會讓你看到帳單時目瞪口呆。 這是沒人談論的隱藏阻礙。 迴圈並不難設計。 難的是負擔不起。 而這正是中國的大型語言模型所解決的問題。 像 DeepSeek、Kimi 和 MiniMax 這樣的模型，讓 Agent 迴圈在經濟上變得可行。 自主 Agent 最大的問題不在於智慧。 而在於 token 的消耗。 迴圈消耗 token 的速度非常快。 單次執行很容易就會燒掉 50K 到 200K 個 token。 如果你同時執行多個 Agent、每天排程迴圈，或是處理大型程式庫——成本會迅速失控。 這就是 DeepSeek 改變賽局的地方。 DeepSeek V4 目前是執行大規模迴圈最便宜的頂尖模型之一。 你將獲得： → 1M 的 context window — 專為大型專案與長時間執行的工作流程而生 → 384K 的最大輸出 — 處理更龐大的生成任務而不崩潰 → DeepSeek V4 Flash + Pro 模型 → 極低的 token 定價 → 支援 Tool calls 與 JSON 輸出，適合 Agent 工作流程 → 高併發（Flash 模型支援高達 2500 次請求） 為什麼 1M 的 context window 很重要： 迴圈需要記憶。 一個在大型專案上運作的程式開發迴圈，需要同時將以下內容保留在記憶中： — 先前的執行紀錄 — 當前的錯誤資訊 — 架構文件 — 測試結果 — 程式庫的上下文 大多數模型會在過程中丟失上下文。 你的迴圈會開始忘記之前發生過什麼事。 DeepSeek 能容納顯著更多的上下文，因此長時間運行的迴圈能保持邏輯連貫。 而且因為價格極低： 迴圈不再會讓你破產。 --- ## 第一部分：舊方法 vs. 新方法 過去兩年，我們一次只對 Agent 下一個任務的 Prompt。 ![這張圖表對比了傳統「提示工程（Prompting）」與未來「自動化循環（Looping）」的工作模式差異。](https://pub-75d4fe1e4e80421b9ecb1245a7ae0d1a.r2.dev/curated/1781062891713-iaHKTISKSboAA2OUNjpg.jpg)
展開畫面重點
圖片分為上下兩個區塊，展示了從人工介入到系統自動化的演進： 1. 上方區塊（紅色框，標題為「Prompting」）： - 流程：人類輸入提示（types prompt）給 AI 代理（Agent） -> 產生輸出（Output） -> 人類手動審核（Human reviews manually） -> 人類進行修正（Human fixes）。 - 核心問題：人類必須親自參與循環（You are the loop），導致人類感到疲憊與壓力。 2. 中間過渡：標註為「The 2026 upgrade」。 3. 下方區塊（綠色框，標題為「Looping」）： - 流程：人類設定目標（sets goal） -> AI 代理自動進行循環運作（Agent cycles automatically） -> 產生驗證後的結果（Verified result）。 - 核心優勢：系統本身即是循環（The system is the loop），人類可以輕鬆休息。
你輸入 Prompt，Agent 回應，你審核，你修正錯誤，你再輸入 Prompt。你就是那個迴圈。 這種模式正在改變。 與其要求 Agent 建立一個登陸頁面，然後由你親自驅動每一個步驟，你現在可以設定一個迴圈，由它負責探索、規劃、執行、檢查與迭代——直到達成目標。 差別在於： 舊方法（Prompting）： 你 → Prompt → Agent → 輸出 → 你審核 → 你修正 → 重複 新方法（Looping）： 你設定目標 → 迴圈執行 → Agent 探索 → 規劃 → 執行 → 驗證 → 迭代 → 完成 你不再需要為每個步驟下 Prompt。 Agent 會為你重複整個週期。 Prompt 給予 Agent 指令。 迴圈給予 Agent 一份工作。 --- ## 第二部分：迴圈工程的本質 ![這是一張展示五階段循環工作流程（Discover, Plan, Execute, Verify, Iterate）的示意圖，強調目標設定與自動化循環的概念。](https://pub-75d4fe1e4e80421b9ecb1245a7ae0d1a.r2.dev/curated/1781062891889-iaHKTIO2caMAEvMoSjpg.jpg)
展開畫面重點
圖片展示了一個五步驟的循環流程，左側有一位火柴人，旁邊文字寫著：「You set the goal. Loop runs itself.」。流程步驟如下： 1. DISCOVER (放大鏡圖示)：Figure out what's needed 2. PLAN (清單圖示)：Break into clear steps 3. EXECUTE (閃電圖示)：Do the work, produce output - 若通過 (PASS)，則進入「Ship ✓」階段。 4. VERIFY (燒瓶圖示)：Check vs goal and standard - 若失敗 (FAIL)，則進入下一步。 5. ITERATE (扳手圖示)：Fix gaps, loop again 畫面呈現手繪風格，強調從發現需求、規劃、執行、驗證到迭代的持續改進循環。
迴圈工程（Loop Engineering）是一種設計可重複回饋週期的實踐，它引導 AI Agent 從嘗試到獲得驗證結果——而無需人類持續介入。 迴圈是你建立的一套機制。 幾乎任何 Agent harness 都能執行它。 這取決於你如何串接它。 最簡單的形式是單一 Agent 自我運作： → 研究 → 草擬 → 根據目標檢查草稿 → 修正弱點 → 重複該週期，直到工作符合要求 每一個迴圈——無論簡單還是複雜——都經歷相同的 5 個階段： 探索（DISCOVER）→ 規劃（PLAN）→ 執行（EXECUTE）→ 驗證（VERIFY）→ 迭代（ITERATE） 通過驗證 → 發布。 驗證失敗 → 再次迴圈。 這就是核心概念。 本文其餘部分只是在說明如何正確建立該週期。 --- ## 第三部分：單一 Agent vs. 艦隊 迴圈有兩種規模： ![這張圖表展示了從單一 AI 代理（Single Agent）到多代理協作系統（Fleet Loop）的擴展架構。](https://pub-75d4fe1e4e80421b9ecb1245a7ae0d1a.r2.dev/curated/1781062892220-diaHKTIWlaoAAenV9jpg.jpg)
展開畫面重點
這張圖表分為左右兩個區塊，說明 AI 代理的運作模式： 1. **左側：Single Agent Loop（單一代理迴圈）** - 核心概念：「One brain, self-improving」（單一大腦，自我優化）。 - 運作流程包含五個步驟的循環： (1) Discover（探索，圖示為放大鏡） (2) Plan（規劃，圖示為清單） (3) Execute（執行，圖示為閃電） (4) Verify（驗證，圖示為勾選） (5) Iterate（迭代，圖示為循環箭頭） 2. **右側：Fleet Loop（代理艦隊迴圈）** - 核心概念：「Scale up when needed」（視需求擴展）。 - 頂層為一個負責「Owns the goal」（掌控目標）的總代理，同樣遵循 Discover、Plan、Execute、Verify、Iterate 的循環。 - 下層分為三個專業領域：Research（研究）、Engineering（工程）、QA（品質保證），每個領域下又可進一步擴展出多個執行具體任務的子代理。 - 底部註解：「Every agent runs the same loop」（每個代理都執行相同的迴圈）。
單一 Agent 迴圈（SINGLE-AGENT LOOP） 一個 Agent 獨自運行整個週期。 想像成一個人重新修改自己的草稿。 它探索需求、規劃工作、執行、驗證品質，並在出錯時進行迭代。 適用於： → 聚焦的任務 → 單純的目標 → 有限的範圍 一個大腦。一個迴圈。自我改進。 ━━━ 艦隊迴圈（FLEET LOOP） 更大規模的是艦隊迴圈。 你給排程器 Agent 一個目標。 它將目標拆解成碎片。 將每個碎片交給專門的 Agent。 這些專家再將更小的任務交給各自的子 Agent。 整個樹狀結構不斷在探索、規劃、執行與驗證中循環——直到達成目標。 想像成整個團隊端到端地執行一個專案。 結構如下： → 排程器負責目標 → 專家負責步驟 → 子 Agent 執行細節工作 → 評估閘門（Eval gates）確保產出品質 範例：「建立一個生產力 App」 > 排程器（負責任務） ↓ ↓ ↓ 研究專家 工程專家 QA 專家 ↓ ↓ ↓ 網頁研究員 + 程式撰寫與除錯 + 錯誤追蹤器 樹狀結構中的每個 Agent 都運行相同的 5 階段迴圈。 探索 → 規劃 → 執行 → 驗證 → 迭代。 重點在於： 單一 Agent 迴圈就像一個人重新修改自己的草稿。 艦隊迴圈則是一個團隊端到端地執行專案。 --- ## 第四部分：開放式迴圈 vs. 封閉式迴圈 這是 2026 年最重要的實務區別： ![這張圖表對比了 AI 代理（AI Agents）運作模式中的「開放迴路（Open Loop）」與「封閉迴路（Closed Loop）」架構及其適用場景。](https://pub-75d4fe1e4e80421b9ecb1245a7ae0d1a.r2.dev/curated/1781062891945-iaHKTIaMEbEAAiGoajpg.jpg)
展開畫面重點
圖表分為左右兩側，分別介紹兩種 AI 運作模式： 左側：OPEN LOOP（開放迴路） - 視覺：機器人周圍有許多隨機指向的虛線箭頭，代表發散的探索。 - 特點： - Wide search space（廣泛的搜尋空間） - Exploratory — tries many paths（探索性 — 嘗試多種路徑） - Exciting and powerful（令人興奮且強大） - Burns massive tokens（消耗大量 Token） - Needs unlimited budget（需要無限預算） - Loose standards = slop machine（標準寬鬆 = 產生垃圾內容的機器） - 適用場景：For: Research, invention（用於：研究、發明） 右側：CLOSED LOOP（封閉迴路） - 視覺：機器人依序執行 Step 1 -> Step 2 -> Step 3 -> Eval（評估）-> Done（完成）的線性流程。 - 特點： - Bounded — human builds path first（有界限 — 由人類先建立路徑） - Clear goal, defined steps（目標明確，步驟定義清晰） - Eval gate at each step（每個步驟都有評估關卡） - Runs on normal budget（在正常預算內執行） - Repeatable and reliable（可重複且可靠） - Gets better every run（每次執行都會變得更好） - 適用場景：For: Real work today（用於：當前的實際工作）
並非所有迴圈都生而平等。 分為兩種類型。 開放式迴圈（OPEN LOOPING） 探索性質。擁有廣闊的活動空間。 你給 Agent 一個目標，讓它自由發揮。 它可以嘗試不同路徑、發現新事物、建立你未完全定義的內容。 這是令人興奮的領域。這正是 Peter Steinberger 等人在 OpenAI 所做的事。 代價是什麼？ 它會消耗驚人的 token 數量。 對於 90% 沒有無限 API 預算的人來說，開放式迴圈目前並不實用。 如果指向標準寬鬆的專案，它會變成一台「垃圾產出機」。 快速、混亂、昂貴。 封閉式迴圈（CLOSED LOOPING） 有邊界。由人類預先設計端到端的路徑。 → 明確的目標 → 定義好的步驟 → 每個步驟都有評估機制 → 設有停止點或交回給你的機制 Agent 依然在迴圈中運作——但是在你建立的框架內。 它在每次執行後都會變得更好，因為每一次通過都會回饋給下一次。 它能在正常預算下執行，因為路徑是嚴謹的。 標準能確保其誠實運作。 沒有品質閘門：AI 會偏離軌道。 有品質閘門：AI 會持續進步。 對於當今大多數實際工作而言，封閉式迴圈才是真正有回報的。 你該使用哪一種？ 從封閉式迴圈開始。 建立一套能可靠運作的嚴謹系統。 一旦有了品質閘門，再考慮開放。 --- ## 第五部分：每個優秀迴圈的 6 個建構模組 每個能穩健運作的迴圈都具備這 6 樣東西： ![這張圖表列出了構建高效自動化循環（Good Loop）的六大核心要素。](https://pub-75d4fe1e4e80421b9ecb1245a7ae0d1a.r2.dev/curated/1781062892100-iaHKV1afKbcAAzTGwjpg.jpg)
展開畫面重點
圖片標題為「The 6 Building Blocks of Every Good Loop」（每個高效循環的 6 個構建模組），詳細內容如下： 1. AUTOMATIONS：The heartbeat — loop runs on schedule, not on you（心跳機制 — 循環按排程執行，而非依賴人工）。 2. WORKTREES：Parallel agents, zero file collisions（平行代理 — 多個代理並行運作，零檔案衝突）。 3. SKILLS：Project knowledge written once, read every loop（專案知識 — 知識寫入一次，每次循環皆可讀取）。 4. PLUGINS & CONNECTORS：Loop touches your real tools (PRs, tickets, Slack)（循環觸及您的實際工具，如 PR、工單、Slack）。 5. SUBAGENTS：Maker and checker are never the same agent（子代理 — 執行者與檢查者絕非同一個代理）。 6. MEMORY：Lives outside the conversation. Loop never forgets.（記憶 — 存在於對話之外，循環永不遺忘）。 底部文字：Both Claude Code and Codex ship all 6 of these now.（Claude Code 和 Codex 現在皆具備這 6 項功能）。
現在進入實務部分。 迴圈在概念上有 5 個階段。 但你實際上要建構什麼來讓它運作？ 6 樣東西。Claude Code 和 Codex 現在都具備這些功能。 以下是它們的內容，以及它們在迴圈內部的實際作用。 1. 自動化（AUTOMATIONS） 這是觸發「探索」並讓迴圈啟動的機制。 迴圈的心跳。 自動化讓迴圈成為真正的迴圈，而不僅僅是你執行過一次的任務。 你定義 Prompt、頻率與目標。 迴圈按排程執行。結果會回報給你。你不需要親自去檢查。 → /loop 按頻率重新執行 → /goal 持續運作，直到你設定的條件達成 給它指令：「確保 test/auth 中的所有測試通過且 lint 檢查乾淨。」 然後你就可以走開了。 2. 工作樹（WORKTREES） 這讓多個「執行」階段能並行運作而不互相干擾。 在沒有混亂的情況下並行化 Agent。 一旦你執行超過一個 Agent，檔案就會開始衝突。 兩個 Agent 寫入同一個檔案，就像兩個工程師在沒溝通的情況下修改同一行程式碼一樣。 Git worktree 讓每個 Agent 在自己的分支上擁有獨立的工作目錄——共享相同的 repo 歷史，但零衝突。 一個 Agent 的編輯內容絕對無法觸及另一個 Agent 的工作區。 3. skill（SKILLS） 這讓「探索」更快——Agent 在開始前就已經了解你的專案。 別再每次執行時都從零開始解釋你的專案。 skill 是一個包含 SKILL.md 的資料夾——記錄專案慣例、建置步驟、「因為那次事故，我們不這樣做」的規則。 寫一次。每次迴圈都讀取。 沒有 skill：迴圈每個週期都從零開始重新推導你的整個專案。 有了 skill：它會累積。Agent 在開始前就了解你的專案。 → VISION.md — 成功的樣貌 → ARCHITECTURE.md — 技術堆疊與資料夾結構 → RULES.md — Agent 絕對禁止做的事 4. plugin 與連接器（PLUGINS AND CONNECTORS） 這讓「執行」變得真實——迴圈在你的實際環境中運作，而不僅僅是檔案系統。 一個只能看到檔案系統的迴圈，格局太小。 連接器（基於 MCP 建構）讓 Agent 可以讀取你的 Issue 追蹤器、查詢資料庫、呼叫 Staging API、在 Slack 發送訊息。 這就是「說出修復方案的 Agent」與「自動開啟 PR、連結 Linear 票證並在 CI 通過後發送通知的迴圈」之間的區別。 5. 子 Agent（SUBAGENTS） 這讓「驗證」變得誠實——檢查者絕對不是製造者本人。 讓製造者遠離檢查者。 寫出程式碼的模型，在評分自己的作業時往往太過寬容。 另一個帶有不同指令的 Agent——有時使用不同的模型——能抓出第一個 Agent 自圓其說的錯誤。 有效的拆分方式： → 一個 Agent 探索 → 一個 Agent 實作 → 一個 Agent 根據規格進行驗證 這也是 /goal 在底層運作的方式。 由一個全新的模型來決定迴圈是否完成——而不是那個負責執行工作的模型。 6. 記憶（MEMORY） 這讓迴圈具有持久性——第 47 次執行的「探索」階段，知道第 1 到 46 次嘗試過什麼。 整個迴圈的脊椎。 一個 Markdown 檔案、一個 Linear 看板，任何存在於單一對話之外的東西。 模型會在執行間忘記一切。 但 Repo 不會。 記憶檔案記錄了：嘗試過什麼、通過了什麼、還有什麼待辦。 明天早上，迴圈會從今天停止的地方繼續。 這聽起來簡單到不值一提。 但每個長時間運行的迴圈都依賴它。 --- ## 第六部分：真實迴圈範例 迴圈在實務上的樣子： ![這張圖表展示了四種可以在背景持續運作的自動化循環流程：程式開發、研究、內容創作與銷售。](https://pub-75d4fe1e4e80421b9ecb1245a7ae0d1a.r2.dev/curated/1781062891995-iaHKV0CkPboAADGHgjpg.jpg)
展開畫面重點
這張圖表名為「4 Loops That Run While You Sleep」（四種在你睡覺時運作的循環），將四個專業領域的工作流程視覺化為循環迴圈： 1. **Coding Loop (程式開發循環)**： - 流程：Read Vision（閱讀願景）→ Plan（規劃）→ Edit Code（編輯程式碼）→ Run Tests（執行測試）→ Fix if failed（若失敗則修正，回到 Plan）→ Done（完成）。 - 特色：強調測試驅動開發，直到程式碼通過測試為止。 2. **Research Loop (研究循環)**： - 流程：Define question（定義問題）→ Search（搜尋）→ Verify（驗證）→ Compare（比較）→ Synthesize（綜合分析）→ Done（完成）。 - 特色：若研究結果未達標，會回到 Search 階段重新搜尋。 3. **Content Loop (內容創作循環)**： - 流程：Topic（主題）→ Draft（草稿）→ Critique（評論）→ Rewrite（重寫）→ Score（評分）→ Publish（發佈）。 - 特色：若評分不理想，會回到 Draft 階段重新撰寫。 4. **Sales Loop (銷售循環)**： - 流程：Define ICP（定義理想客戶畫像）→ Find leads（尋找潛在客戶）→ Enrich（資料豐富化）→ Qualify（資格審核）→ Personalize（個人化）→ Send（發送）。 - 特色：若流程未達標，會回到 Find leads 階段重新尋找潛在客戶。
程式開發迴圈 ```plaintext 讀取 VISION.md + ARCHITECTURE.md ↓ 規劃下一個變更 ↓ 編輯程式碼 ↓ 自動執行測試 ↓ 若測試失敗 → 讀取錯誤 → 修正 → 重測 ↓ 若測試通過 → 總結變更 ↓ 停止 ``` 中間無需人類介入。 Agent 自己撰寫、測試、修正並驗證。 ━━━ 研究迴圈 ```plaintext 定義研究問題 ↓ 搜尋來源 ↓ 總結發現 ↓ 根據來源驗證主張 ↓ 比較衝突資訊 ↓ 綜合最終答案 ↓ 達到信心閾值後停止 ``` ━━━ 內容創作迴圈 ```plaintext 定義主題 + 受眾 + 目標 ↓ 建立草稿 ↓ 評論 Agent 審核草稿 ↓ 根據評論重寫 ↓ 根據成功標準評分 ↓ 若評分通過 → 發布 ↓ 若評分失敗 → 再次重寫 ``` ━━━ 銷售開發迴圈 ```plaintext 定義 ICP（理想客戶畫像） ↓ 尋找符合畫像的潛在客戶 ↓ 以公司資料進行豐富化 ↓ 根據標準進行資格審核 ↓ 個人化訊息 ↓ 品質審核 ↓ 發送或升級給人類處理 ``` 每個迴圈都有相同的骨架： 目標 → 行動 → 檢查 → 修正 → 重複直到完成。 --- ## 第七部分：Prompt 工程師 vs. 迴圈工程師 2026 年即將出現的技能差距： ![這張圖表對比了傳統 AI 方案與 MiniMax M3 在處理複雜任務循環時的成本效益差異。](https://pub-75d4fe1e4e80421b9ecb1245a7ae0d1a.r2.dev/curated/1781062892178-iaHKTKaUab0AAIlU7jpg.jpg)
展開畫面重點
左側（紅色框）：標題為「The Problem」。展示了一個 AI 代理的循環流程（Read VISION -> Plan -> Edit Code -> Run Tests -> Fix if failed -> Done）。圖中顯示「One loop = 50K-200K tokens」，並配有一個指針指向「EMPTY」的儀表板，下方文字說明「Standard plan = empty in one run ☹️」，意指標準方案在執行一次循環後就會耗盡額度。 右側（綠色框）：標題為「MiniMax M3 - $20/month」。展示了一個裝滿代幣的罐子，標示「~1.7 Billion tokens」。同樣的循環流程圖旁，列出了四項優勢： - 1M context window - 3-4 concurrent agents - Image + video input - Text / image / speech / music 右下角有一個指針指向「FULL」的儀表板，強調其資源充裕。中間箭頭文字為「Now you can afford to actually loop」。底部標註「Sponsored」。
Prompt 工程師 → 製作更好的指令 → 語言能力 → 更好的 Prompt → 更好的單次輸出 → 每次執行後仍需手動審核輸出 → 你就是那個回饋迴圈 迴圈工程師 → 設計更好的回饋週期 → 軟體工程技能 → 更好的迴圈 → 可靠的驗證結果 → 系統自動執行、檢查並自我修正 → 系統本身就是回饋迴圈 Prompt 工程師 -> 「幫我寫一個函式」 迴圈工程師 -> 「撰寫 → 測試 → 修正直到通過」 撰寫更好的 Prompt 撰寫 VISION.md 手動審核輸出 自動化測試審核 執行一次 Agent 建立重複運作的系統 按單次輸出付費 為驗證後的結果付費 工具是一樣的。 思維模式完全不同。 Prompt 工程師向 AI 索取輸出。 迴圈工程師設計能產生驗證結果的系統。 2026 年薪資最高的 AI 工程師，不是那些能寫出更好英文句子的人。 他們是在撰寫邏輯，規範 Agent 如何探索、規劃、檢查自己的工作，並知道何時該收工。 ![這張圖表對比了「提示工程師（Prompt Engineer）」與「循環工程師（Loop Engineer）」在 AI 協作模式上的演進差異。](https://pub-75d4fe1e4e80421b9ecb1245a7ae0d1a.r2.dev/curated/1781062892347-iaHKTKkvLbwAAKXPqjpg.jpg)
展開畫面重點
圖表分為左右兩側，中間標示「The 2026 upgrade」。 左側為「Prompt Engineer」： - 畫面顯示一個人對 AI 說：「Write me a function」。 - 相關標籤：Linguistic skill（語言技能）、One output（單一輸出）、You review（你需要審核）。 - 下方顯示該人員拿著放大鏡檢查含有錯誤（Bug）的程式碼，表情困惑。 右側為「Loop Engineer」： - 畫面顯示一個人指導一個 AI 循環流程。 - 循環流程包含：DISCOVER（探索）、PLAN（規劃）、EXECUTE（執行）、VERIFY（驗證）、ITERATE（迭代）。 - 相關標籤：Software skill（軟體技能）、Verified outcome（已驗證的結果）、System reviews（系統審核）。 - 下方展示該循環流程產生了多個已驗證（打勾）的成果。 底部文字：Same AI. Completely different relationship with it.（同樣的 AI，但與其互動的關係截然不同。）
--- ## 結語 這就是迴圈工程。 為你總結一切： 轉變： → 過去兩年我們一次對 Agent 下一個任務 → 現在我們設計驅動整個週期的迴圈 你實際要建構的 6 件事： → 自動化 — 心跳，觸發探索 → 工作樹 — 並行 Agent 零衝突 → skill — 每次執行都會累積的專案知識 → plugin 與連接器 — 讓迴圈在你的真實工具中運作 → 子 Agent — 製造者與檢查者絕非同一 Agent → 記憶 — 迴圈在執行間永不遺忘 兩種規模： → 單一 Agent：一個大腦，自我改進 → 艦隊：排程器 + 專家 + 子 Agent — 每個 Agent 都運行相同的迴圈 兩種類型： → 開放式迴圈：探索性、強大、昂貴，需要無限預算 → 封閉式迴圈：有邊界、可靠、負擔得起，當今最有回報的選擇 每個優秀迴圈的 5 個部分： → 目標 — 精確定義「完成」的意義 → 上下文 — VISION.md, ARCHITECTURE.md, RULES.md → 行動 — 只做 Agent 真正需要的動作 → 回饋 — 測試、型別檢查、Linter、結構化錯誤 → 停止條件 — 當迴圈知道它已完成時 成本問題： → 迴圈消耗 token 很快 → 在 DeepSeek 上花 20 美元比大多數頂尖模型走得更遠 → 這消除了最後一個真正的阻礙 巨大的轉變： → Prompt 工程師向 AI 索取輸出 → 迴圈工程師設計能產生驗證結果的系統 --- Peter Steinberger 說得對： 停止對你的 Agent 下 Prompt。 開始設計迴圈。 因為一個可靠的迴圈，勝過一千個完美的 Prompt。 --- 還有一件事沒人會大聲說出來。 兩個人可以建立完全相同的迴圈，卻得到截然不同的結果。 一個人用它來加速自己深入理解的工作。 另一個人用它來逃避理解工作本身。 迴圈分不出差別。 但你分得出來。 這就是為什麼迴圈設計比 Prompt 工程更難——而不是更容易。 Boris Cherny 的觀點並不是說工作變簡單了。 而是槓桿點轉移了。 去建立迴圈吧。 但建立它的時候，要像個打算持續擔任工程師的人——而不僅僅是那個按下「開始」按鈕的人。 因為一個可靠的迴圈，勝過一千個完美的 Prompt。 而且有了 20 美元 17 億個 token 的額度，你終於負擔得起建立一個了。 --- 如果這篇文章對你有幫助： → 轉發分享給你的網路好友 → 追蹤 @sairahul1 以獲取更多類似的深度解析 → 收藏這篇文章 — 5 部分的框架值得反覆研讀 我撰寫關於 AI、產品開發以及在你睡覺時也能運作的系統。 ## 標籤 Agent, 自動化, 產業趨勢, AI Engineering, Loop