Lynkr

揭露：我維護 Lynkr，這是一個帶有迴圈防護中介軟體的開源 LLM 閘道，因此我對此有立場。請將本文視為一篇挑戰性的論述，而非中立的調查。

代理人（Agent）相關討論已從提示詞轉向迴圈：持續運行的「讀取—行動—觀察」循環，直到模型決定結束。我持反對立場，認為大多數所謂的迴圈工程正在最佳化錯誤的變數。更長、更豐富的迴圈通常只是收斂失敗披上了外衣。 設計良好的迴圈是知道何時停止的短迴圈。

我所反對的共識

當代理人失敗時，預設的做法是給迴圈更多：

  • 更多次數才放棄。
  • 更多內容塞進視窗。
  • 更多支架：規劃器、評論者、反思步驟、子代理衍生更多子代理。
  • 更多重試與更多回饋。

隱含的理論很簡單：智能會在迭代中累積，因此更多輪次應帶來更多收斂。有時這會奏效。但在大多數真實流量上並非如此——即使有效，成本結構也相當嚴峻。

以程式碼代理人為具體例子：給一個能力不足的模型一個全倉庫重構任務，它通常不會「更長時間推理」而成功。它可能誤讀某個依賴、鎖定錯誤的檔案，接著花接下來十幾輪繼續擴充這個錯誤。迴圈並沒有拯救模型，而是資助了失敗。

為什麼更長的迴圈會累積錯誤

有兩件事會在迴圈中累積，而兩者都不是智能。

1. 迴圈成本快速成長。 每一次回合都會重新傳送累積的上下文。一個 20 回合的會話不只是連續 20 次單獨呼叫；後續回合會把先前 token 再次送進模型。在許多代理工作負載中，迴圈成為服務預算中最昂貴的項目，而「增加更多回合」則是最昂貴的旋鈕。

2. 可靠性會在依賴步驟中崩壞。 即使單步可靠性樂觀，多步鏈條也會快速衰減。長迴圈不會平均化錯誤，而是增加停留在正確軌道的難度。所謂「只需要更多回合」的代理人，通常是帶著更多確信走進錯誤分支，因為每一回合都把先前的錯誤視為事實。

我們先前討論過，塞滿上下文視窗可能讓代理人變得更糟而非更聰明：注意力被稀釋、檢索會鎖定錯誤的區塊、訊號被掩埋。迴圈長度是同樣的失敗，只不過發生在時間軸上。更多不等於更好。

長迴圈真正代表的訊號

當一個代理人需要 30 回合才能完成某件事，通常不是因為工具很聰明，而是以下兩種失敗之一的訊號：

  1. 任務被分配給無法勝任的模型。 迴圈只是該模型在空轉。支架很少能修復模型能力不足的決策；它通常只會讓失敗變得更複雜且更昂貴。
  2. 任務確實有很多步驟。 在這種情況下，工程問題不是「如何允許更多回合」，而是「如何以低成本驗證每一步，讓錯誤分支在第 3 回合就被發現，而不是累積到第 30 回合？」

兩者都指向同一個方向：要嘛把步驟分配給更好的模型，要嘛在繼續前驗證該步驟。兩者都沒有說：增加回合然後祈禱。

迴圈工程真正應該做的

如果迴圈是成本與錯誤累積的地方，那麼好的迴圈工程應該最小化累積，而不是最大化每回合的能力。

1. 硬性限制迴圈。 每個迴圈都需要一個回合上限與工具呼叫上限，絕對不能超過。這不是緊急備援，而是第一級設計限制。一個可以永遠運行的迴圈，在某些輸入下會讓你花大錢產生垃圾。

2. 以低成本驗證每一步。 迴圈中最高槓桿的增強通常不是另一個推理階段，而是對步驟輸出進行快速、確定性的檢查，捕捉你實際看到的失敗模式：截斷、格式錯誤的工具呼叫、空回應、退化迴圈、重複回音。偵測勝過預測，因為你已經拿到輸出。

3. 升級失敗的步驟，而非整個會話。 當某一步驗證失敗時，重新執行那一步，並改用更好的層級。不要給整個迴圈更多回合去掙扎。升級是針對性的；增加回合則是空白支票。

我們也吃過的虧

我們也不例外。在 Lynkr 中，我們推出了一個簡潔模式，目的是透過讓模型產生更短的答案來節省輸出 token。我們的驗證器卻把某些短答案誤判為低努力失敗，並把簡單的請求升級到更昂貴的層級。

修正只是一個謂詞。但更廣泛的教訓並非如此。迴圈中的檢查本身就是迴圈成本與失敗面的一部分。「加入驗證」並非免費的美德；一個糟糕的驗證器可能會像天真的重試一樣延長迴圈。驗證必須以與其他回合相同的懷疑態度來設計。

直接陳述論點

許多流行的迴圈工程在最佳化每回合能力時，把回合數視為免費。這是本末倒置。在真實流量中，回合數通常是主要成本，也是累積錯誤的重要來源。

如果任務需要更多智能，就為該步驟購買更多智能。如果任務需要更多可靠性，就驗證該步驟。如果迴圈持續增長，就視其為失敗訊號，而非複雜度的標誌。

讓迴圈更短。讓它停止。這才是工程。

Lynkr 採用 Apache-2.0 授權並可自託管。本文背後的迴圈防護中介軟體與步驟層級升級概念已收錄在儲存庫中：github.com/Fast-Editor/Lynkr。如果你曾見過迴圈執行過久並知道原因，我很樂意聽聽你的戰場故事。