編輯：蛋醬
程式設計智慧體，幾乎成為了 2025 年最熱門的話題之一。不管是學術機構還是工業界，都在尋找更高效的落地路徑。
機器學習領域的歷史經驗表明，手工設計的解決方案最終會被學習到的解決方案所取代。我們好奇一個問題：智慧體本身是否可以透過發現新的提示方案或工具，無需人工設計和實施，就自主修改和改進自己的程式碼？
2024 年，《Automated Design of Agentic Systems》(Hu et al., 2024) 一文率先嚐試了使用元智慧體來最佳化智慧體實現，將智慧體系統自動設計（ADAS）這一領域往前推了一步。不過，該研究並未探索「自我改進」，因為其中有兩個獨立的智慧體：執行任務的目標智慧體和改進目標智慧體的元智慧體。
而來自布里斯托大學和 iGent AI 的研究者認為，完全自我參照式的元智慧體程式設計方式在今天是可實現的，並提供了一種合理的替代方案。
-
論文標題：A SELF-IMPROVING CODING AGENT
-
論文連結：https://arxiv.org/pdf/2504.15228
-
程式碼地址：https://github.com/MaximeRobeyns/self_improving_
具體來說，這項研究貢獻如下：
-
自我改進編碼智慧體（SICA）消除了元智慧體和目標智慧體之間的區別，能夠編輯自己的程式碼庫，在成本、速度和基準效能方面進行自我改進。
-
自我參照智慧體可有效改進自身的實現。研究者發現，即使考慮到安全限制和資源效率，在 SWE Bench 驗證的隨機子集上，效能也能提高 17% 到 53%。
-
研究者與社群分享了自我改進編碼智慧體（SICA）的實現。SICA 是用標準 Python 實現的，沒有特定領域的語言，它為構建新的 SICA 系統提供了一個參考智慧體框架，也為那些尋求在工具使用和其他智慧體任務方面對 LLM 進行後訓練的人提供了一個參考智慧體框架。
方法概覽
SICA 的主要執行迴圈類似於 Hu et al. (2024) 的 ADAS 迴圈。特別是，SICA 和 ADAS 都保留了以前智慧體的檔案及其基準結果。
第一步，SICA 從存檔中選取到目前為止表現最好的智慧體作為元智慧體，指示元智慧體檢視存檔，確定改進方案並加以實施。
演算法 1 展示了這一高階方案：
請注意，這與 ADAS 不同，ADAS 有一個固定的元智慧體，因此不會從檔案中選擇元智慧體（ADAS 中的檔案是目標智慧體檔案，而不是元智慧體檔案）。
其次，ADAS 和 SICA 都會在一組評估基準上對新智慧體進行評估，並存儲評估結果。
研究者用一個效用函式來定義效能「最佳」的智慧體，該函式包含了一個優秀智慧體的共同期望值：標準化基準效能分數 p_score ∈ [0，1]、以秒為單位的掛鐘時間 p_time，以及美元成本 p_cost。基本效用的計算公式為
其中，研究者將係數設為 w_score = 0.5、w_cost = 0.25 和 w_time = 0.25。此處將每個問題的最差成本設定為 10 美元，並規定 300 秒的超時時間，超時後將取消智慧體。為了對超時前所做的工作給予部分獎勵，按以下方法計算最終效用，超時懲罰為 τ = 0.5：
需要注意的是，由於不進行任何權重更新，這個數字分數只用於挑選下一個元智慧體以及下一次迭代的基礎智慧體。
首先介紹初始編碼智慧體，然後介紹基準執行框架，以及該框架如何自然而然地允許我們建立一個自我參照任務（即改進編碼智慧體）。
智慧體上下文的結構至關重要，它包含開啟的檔案內容等，而不僅僅是提示。在初始編碼智慧體中，上下文結構如圖 3 所示。
首先呈現的是包含智慧體定義的系統提示，列出了智慧體可用工具的定義以及可呼叫的子智慧體。系統提示的最後是系統資訊，例如如何跳出智慧體迴圈並返回呼叫流程的說明。
接下來是「核心提示」，它被設定為聊天模板格式中的第一條使用者資訊，包含呼叫者指定的要處理的問題陳述（呼叫者可能是呼叫智慧體的使用者，也可能是呼叫子智慧體的智慧體）。在這裡，研究者還插入了智慧體已開啟檔案的檢視以及當前工作目錄的表示。
最後，LLM 智慧體上下文的其餘部分是執行助理資訊。其中包含對問題的一連串推理、工具呼叫及其響應、子智慧體呼叫及其響應，以及來自非同步監督系統的任何通知或評論。
LLM 上下文以這種方式佈局，允許新增新內容，從而保留 KV 快取，以減少工具呼叫之間的延遲和成本。對於基礎智慧體，此處採用了一種簡單的方案，即檔案編輯內容以差異形式新增，並在累積到一定數量後定期重新合併到陳舊檔案檢視中。智慧體可以編寫更復雜的 KV 快取儲存方案，以降低成本。
實驗結果
研究者首先展示了在基準集中包含相對長週期任務的執行，選取了 SWE Bench Verified，包括測試問題分解、程式碼導航以及快速高效的檔案編輯，研究者從中選擇了 50 個問題的固定隨機子集；他們還從 LiveCodeBench 中隨機抽取了 50 個問題，這些問題類似於競技程式設計，通常包含更多理論推理。此外，研究者還選取了兩個「合成」基準任務示例，它們完全是在智慧體的程式碼庫中定義和策劃的。
大多數智慧體中使用 Sonnet 3.5 (v2) (Anthropic) 執行智慧體系統，只有一個「推理智慧體」使用 o3 mini。結果如圖 3 所示，更詳細的迭代級效能資料見表 1。
結果資料顯示了令人鼓舞的進展。在檔案編輯基準測試中，智慧體最初只具備覆蓋檔案的能力，這不僅速度慢，而且 token 效率低下，但它很快就實現了基於差異和範圍的自稱「智慧」的編輯工具；在符號導航任務中，智慧體在第 9 次迭代時實施了基於 AST 的簡單符號定位器（也許是利用了基準測試主要基於 Python 的事實），取得了良好的改進，這也反映在其他任務中。LiveCodeBench 的得分也有細微提高，但不如其他一些基準測試明顯。
研究者還評估了自我參照智慧體系統在提高推理能力較強的領域的任務效能方面的有效性。他們使用基準集中的兩個問題解答任務進行了另一項實驗： 圖 4 顯示了實驗結果。這裡的結果顯示改進較少，並突出了基礎模型和「腳手架系統」之間的重要相互作用。
圖 4 中迭代 0 的基礎智慧體系統使用 Sonnet 3.5，「推理」子智慧體使用 o3-mini。o3-mini 模型本身在 AIME 和 GPQA Diamond 上的得分分別為 87% 和 79%，具有「高」推理能力，而整個智慧體系統在這兩個基準測試中的平均得分為 76%。
透過觀察軌跡，研究者發現，在許多執行中，主智慧體只是將問題委託給基於 o3-mini 的推理智慧體，並沒有充分利用智慧體系統的全部能力。對於 o1、o3-mini 或 DeepSeek-R1 等「推理模型」，研究者懷疑加入旨在誘導推理行為的粗糙元件（如圖 4 中迭代 4 和 6 中的元件）實際上可能會打斷在智慧體系統之外訓練的推理模型的推理思維鏈，從而導致效能下降。
更多研究細節，可參考原論文。
© THE END
轉載請聯絡本公眾號獲得授權
投稿或尋求報道：[email protected]