人工智慧模型如何知道它的工作何時完成？
人類又是如何知道工作完成的呢？
程式設計師會等測試全部通過或團隊的程式碼審查完成。設計師會調整構圖，暫時放下，再回來決定剩餘的瑕疵不再重要。作家會在截止日期到來或編輯接受稿件時提交草稿，而非因為文字已達到某種客觀的最終狀態。
「完成」很少是工作本身的屬性，而是由工作周圍的系統所做出的判斷。人類沒有通用的「完成」偵測器，我們依賴一系列信號，如測試、規格、先例、批准、截止期限、風險，以及找到報酬遞減的點。每種情況下，完成都是來自工作之外。
人工智慧模型幾乎總能產生另一個答案。
它可以再次修訂段落，可以嘗試另一種實作，可以生成更多細節、不同光線和更強構圖的圖像。它不會感到疲倦，也不會注意到，除非我們給它某種方式去察覺，過去三次修訂使結果不同，但不一定更好。
這正是近期「迴圈工程」概念如此吸引人的部分。與其由人類提示模型、檢查結果、描述錯誤並再次提示，不如讓系統自行執行整個循環。人不必參與每一次迭代。代理人發現工作，交給模型，檢查結果，決定下一步。
然而，撰寫迴圈的微妙之處在於，迴圈的品質取決於每一步的驗證者。早在談論迴圈工程之前，所有流程本質上都是迴圈，只是人類手動提示並擔任驗證者，成本極高。當人類被移除時，設計每步驟應驗證的內容成為推進迴圈狀態的關鍵，而事實上，讓它們運作非常困難。
以標準的程式碼代理迴圈為例：持續工作直到測試通過。聽起來幾乎完美可驗證。但測試只是任務的代理指標。在SpecBench中，先進代理經常通過可見測試，卻在隱藏測試中失敗，這些測試同時檢驗相同功能。一個代理產生了2900行的「編譯器」，只是記憶測試輸入。迴圈收斂了，但只是針對驗證者，而非用戶意圖。
驗證者不僅是停止條件，也定義迴圈視為進展的標準。如果信號不完整，迴圈可能在通過檢查上變得更好，但任務本身並未改善。
迴圈工程不是讓代理重試的做法，而是讓每個循環都縮短當前狀態與期望狀態的距離。迴圈尚未形成方向。
最早成功的迴圈是程式碼迴圈，這並非偶然。程式碼既可編輯又可執行。代理能修改一個函數，執行程式，讀取測試失敗訊息，再嘗試。環境回傳相對明確的錯誤訊號。迴圈既有精確的行動方式，也有能衡量進展的驗證者。
我曾在視覺程式碼生成中描述類似模式。SVG不只是圖像，它包含路徑、形狀、文字、漸層和佈局。Blender場景不只是渲染，它包含幾何、材質、攝影機、關節和約束。這些表示法讓代理能局部檢查和編輯。如果曲線錯誤，改變路徑；物件位置錯誤，移動物件。工件可在多次迭代中改進，而非每次重生成。
但可編輯性只是問題一半。在開放式圖像生成中，另一輪迭代往往意味著生成另一個樣本並選擇最佳。反饋是全局的，很難將「這看起來更差」映射到精確的編輯。SVG和Blender迴圈能在目標可表達為參考、幾何、約束或功能行為時收斂，但當目標只是「讓它更好、更有品味，但不能詢問人類」時，則難以驗證。視覺迴圈不是不可能，但通常極難驗證。
如果驗證者給迴圈方向，迴圈需要什麼才能收斂？
根據與多領域工程師和研究人員的多次對話，我認為有四項要素。
系統需要對「完成」的定義表示。對程式碼來說，可能是測試套件、規格或性能限制。對SVG，可能是參考圖像、尺寸、顏色和佈局規則。「讓它更好」不是目標狀態，而是另一個提示。
系統需要檢查現有狀態，可能是檔案、差異、測試結果、追蹤、DOM樹、SVG結構或Blender場景圖。僅有渲染輸出往往不足，系統還需看到底層結構以識別錯誤來源。
代理需要改變錯誤所在部分，而非重生產全部。改一個函數勝過重寫整個程式庫。編輯一條SVG路徑勝過生成新圖像。調整Blender場景中一個物件勝過重建整個場景。編輯越局部，迴圈越可能保留已正常運作部分。
實務上，這是人們最難掌握的部分。幾乎所有研究者都說，當他們找到合適的工具呼叫和中間提示時，迴圈才開始運作。如何發現能推進迴圈的工具？目前沒人能預先知道，主要靠試錯。
這帶來一個不舒服的結論：迴圈是針對其技術棧調整的。使一個程式碼庫迴圈收斂的工具呼叫，包含對該程式碼庫的假設，這些假設在其他地方不一定成立。別人的迴圈是起點，不是保證。定制迴圈不會自動泛化。這也是為何有人找到神奇迴圈有效，但使用公開迴圈時卻完全失效。
系統需要停止條件，該條件來自生成器外部：測試通過、限制滿足、分數達標或審查者批准。停止條件也需考慮成本——迴圈在500次嘗試後找到正確答案，技術上收斂但經濟上不合理。
一種有用的思考方式是從兩個軸向看：工件的可編輯性與結果的可驗證性。
程式碼通常位於右上角，易編輯且驗證強。開放式圖像生成多位於左下角，系統能生成另一張圖，但難以修正特定決策或驗證結果是否更接近用戶意圖。
圖表的一個重要特性是任務位置可因重新定義問題而移動。軸描述的是表示法，不是任務本身。開放式圖像難編輯，但同一圖像若以SVG路徑或Blender場景表示，則變得可編輯——任務往上移。給予參考圖像或限制檢查，進展可驗證，任務往右移。這是迴圈工程的另一種描述：不是讓代理多次重試，而是不斷重新表示任務，直到它落在迴圈能收斂的象限。
我訪談了來自不同領域的程式設計師，他們都在做某種迴圈工程——從軟體工程到視覺創作再到影片剪輯。我問他們同一問題：你怎麼知道迴圈會收斂並逐步改進？
答案是，今天找到有效迴圈的過程充滿試錯。可能是提供正確的工具呼叫；或讓迴圈運行數小時，看是否比之前好（且改善曲線有希望）；可能是深入特定工作流程並精確複製。
但找到能普遍適用的迴圈很難，幾乎像是要把人類知識編碼進迴圈本身；我們必須先深刻理解迴圈運作原理，或找到創新驗證層，才能嘗試自動化。
然而，找到迴圈只是前期成本。執行迴圈才是每個開發週期的主要成本。
假設試錯成功，找到有效迴圈。最簡單版本是 /goal [條件]，持續執行直到條件達成，迴圈最終會到達目標。
「最終」是問題。你會執行20次還是500次？老實說，迴圈不知道，人類開啟迴圈時也不知道，這使得迴圈經濟學變得複雜。
我們知道的是曲線形狀。幾乎所有測試時計算研究都顯示報酬呈對數遞減：每增加一點品質，成本呈指數增加。一項網頁代理基準發現，從1個樣本增加到10個，成功率從38.8%提升到43.2%。再加倍到20，分數只多0.2，但代幣成本翻倍。超過平台後，邊際迭代甚至可能負成長：推理模型在更大預算下開始放棄已正確答案。更多迭代不僅無益，還會有害。
我測試了Anthropic在迴圈工程文章中最受歡迎的迴圈範例：
發現增量代幣花費對結果影響遠低於迴圈運行時間暗示。
在一個故意破損的頁面（Lighthouse分數35）上，Claude Code第一次嘗試就達98分，花費0.35美元，迴圈未如預期啟動。於是我讓目標無法達成：同一頁面，但加上2.2秒人工延遲，分數上限約89，目標100。
前1.40美元將分數從26提升到89，剩餘2.84美元（總花費67%）卻毫無分數提升：反覆壓縮HTML並重新執行Lighthouse，代理無法改變瓶頸，每輪成本越來越高（文字紀錄增長，Haiku評估器默默累積0.67美元）。更糟的是，迴圈逃脫機制不可靠：Claude在第5次嘗試時正確判斷延遲限制並宣告目標不可能，但評估模型仍14次拒絕終止。
教訓不是迴圈無效，而是它們不知道何時停止。在此案例中，價值集中在前三分之一花費，但迴圈持續燃燒代幣於不可能任務，回報微乎其微。
良好停止不是能透過提示產生，而是需要基礎設施：計量花費、衡量進展、擁有足夠資訊切斷迴圈。迴圈工程有其基礎架構層，以下是各層面。
當迴圈成為工程單位，模型與開發者需要每層基礎設施：代理行動環境、長期狀態保存、工作驗證或迴圈閉合，以及人類介入介面。每類別已有相應堆疊形成。
另一視角是推理時間與訓練時間。
推理時間，迴圈改變工作而非模型。代理撰寫程式碼、執行驗證、讀取結果、再嘗試。權重固定，系統在單一任務中利用測試時計算尋找更佳答案。
訓練時間，過程類似強化學習，執行多條路徑、評分結果、更新模型，使獎勵行為更可能出現。兩者規則相同：迴圈品質取決於驗證者。代理迴圈中驗證者可能是測試套件，強化學習中是獎勵信號，有時兩者相同。
兩種迴圈最終可相互影響。推理時間產生成功與失敗的軌跡，這些可成為訓練資料、偏好對或獎勵，讓模型學習先前需昂貴搜尋才能發現的行為。但並非所有失敗都應透過訓練解決。更高槓桿的修正往往在權重之外：更好的工具、更清晰的狀態、更精確的行動空間或更強的驗證者。
目前大多數代理基礎設施與框架能協助我們執行迴圈。更難的是找到值得執行的迴圈，以及找到任務報酬遞減前的點。
從觀察這些迴圈運作，我認為兩件事明確：
第一，經濟學必須明確化。現在我們執行迴圈就像過去開啟卻忘關的雲端實例。代理按代幣計費，代幣無論推動分數還是重複壓縮HTML都同價。在我的Lighthouse測試中，三分之二花費毫無效益，迴圈和我都不知道，直到事後看文字紀錄。缺少的部分是枯燥卻必要的：每次迭代成本、每美元進展，以及迴圈運行時可見的曲線。
第二，對於已收斂的迴圈，有趣的基礎設施工作已移出迴圈本身。迴圈只是while語句，讓它收斂的元素存在其周圍：代理行動環境、長期狀態、決定計數的驗證者、人類介入介面。每個成功迴圈都建立在這樣的堆疊上，差異化就在這裡。
那麼，人工智慧模型如何知道工作完成？目前，它不知道。它在預算用盡或我們設計的檢查通過時停止，這兩者都需建立。重要的系統不是能持續運作的，因為它們都能，而是那些建造者事先精確決定完成成本與意義的系統。
如果你正在研究迴圈工程問題，或對此領域有想法，歡迎聯繫 [email protected]。