編程智能體，幾乎成為了 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 中的組件）實際上可能會打斷在智能體系統之外訓練的推理模型的推理思維鏈，從而導致性能下降。
