我們開發 Composer 的一個顯著特點，是會利用較早版本的模型來改進後續版本的訓練流程。

這類自舉最明確的機會之一，就是環境設定。RL 訓練需要可執行的環境；如果環境一開始就是壞的，模型就會把 token 浪費在除錯環境設定上，而不是學習如何解決問題。最糟的情況下，不良環境甚至會讓問題完全無解，白白消耗運算資源，卻得不到任何獎勵訊號。

為了解決這個問題，我們打造了 Composer autoinstall：這套系統會利用較早期的 Composer 模型，從尚未設定的儲存庫結帳內容自動建立可正常運作的 RL 環境。在訓練模型最新版本 Composer 2 時，我們使用它的前一代 Composer 1.5 來處理這個流程。我們發現，現代程式碼模型不只會照著逐步指示執行，還會想方設法完成設定、模擬專案相依套件，並驗證環境是否已成功設好。

#更好的環境，意味著更好的訓練訊號

和我們模型開發的許多環節一樣，autoinstall 的靈感來自 Cursor 在正式環境中的系統。在 Cursor 的雲端代理中，我們有一項功能會自動為使用者設定雲端環境，讓他們的代理能在模擬環境中處理專案。從 git checkout 開始，代理會安裝套件、設定參數，並執行基本檢查，以確保程式碼能正常執行且維持穩定。這樣一來，後續的請求就能從正確的設定開始。

對 RL 訓練而言，這個問題更加關鍵，但也更具挑戰性。從一個儲存庫開始，autoinstall 的目標是建立一個可執行的程式碼庫模擬基底版本，用來解決未來尚未出現的程式設計問題。這個基礎環境至關重要，因為 Composer 是在完整工具集下接受訓練的，其中包括程式語言的 lint 指令、搜尋，以及在沙箱中使用 shell。若無法正確設定環境，訓練不僅會變得低效率，還可能白白浪費運算資源，卻得不到任何獎勵訊號。

#一個代理定義成功，下一個則嘗試達成

Autoinstall 分為兩個階段。在第一個「目標設定」階段中，我們會將處於固定 結帳 狀態的程式碼庫交給 Cursor 代理，並要求它提出 10 個指令，以及在環境正確設定完成後，這些指令執行時應產生什麼輸出的高層次說明。

代理會查看環境中的任何 README 或 Makefile，也會嘗試常見的語言特定指令，例如 uv 這類專案管理工具，或 clippy 這類 linter。代理的工作通常包括設定指令、可使用時的測試，以及啟動可執行檔的指令。

在第二個階段中，我們會向另一個 Composer 代理提供環境的初始狀態，以及從先前提出的 10 個指令中選出的三個目標指令。接著，代理會探索程式碼庫，透過工具呼叫完成環境設定，讓這些指令可以執行。之後，我們會測試這三個指令是否都能執行，且輸出是否符合第一個代理提供的目標說明。如果不符合，我們就會重新啟動第二階段。如果在重複此流程五次後，代理仍無法將環境設定到令人滿意的程度，我們就會捨棄該環境。

透過 autoinstall，Composer 的目標是盡可能完整且正確地完成環境設定。為了達成這一點，它會模擬缺失的檔案、建立佔位圖片，甚至建立假的資料庫資料表。有些專案需要安裝執行測試所需的額外元件，例如 S3 資料夾或缺少的 sidecar 容器。Composer 也經常會模擬這些項目，建立 MinIO 設定或 Docker 容器來讓它們運作。為了支援長時間執行的行程，我們允許 autoinstall 建立啟動 script，在 RL 用量開始時啟動這些行程。

#真實世界專案的 Autoinstall

為了說明 autoinstall 流程，我們來看一個實際進行過的實驗：我們使用 autoinstall 來設定一個複雜的真實世界專案。這個專案是 Celo，實作於 celo-org/celo-monorepo，是一個大型區塊鏈專案，具有數個主要相依套件。這個專案很適合作為 autoinstall 的測試案例，因為它不僅需要管理大量安裝所需的相依套件，還得為測試模擬驗證流程。

在 autoinstall 的第一個階段中，我們觀察到代理會查閱專案的文件與程式碼，以找出關鍵的安裝指令。不過，這個專案內含的文件相對有限，因此它也使用 Web 指令搜尋該專案的文件網站，以取得更多設定指令。找到的大多數指令都與安裝或測試有關，但其中也包含一個來自文件、用來操作該軟體的基本最小化應用程式。

在第二個階段中，代理的任務是實際讓這些指令跑起來。雖然這組任務很明確，但模型事先並不知道會遇到哪些問題。就這個特定案例而言，它發現還需要安裝其他幾個相依套件，例如相關儲存庫 Foundry。它使用 Web 搜尋來讀取這個必要專案的文件。它也被要求在這個環境中執行一個最小化應用程式。在這個階段的第一次迭代中，它未能成功執行這個測試應用程式；但到了第二次迭代時，它發現可以建立一個模擬使用者，在本機啟動該應用程式並滿足這項要求。

#為下一代自舉。

Autoinstall 是一個很有意思的例子，展示如何以先前的模型為 RL 流程自舉。值得注意的是，Composer 2 在 Terminal-Bench 上的分數如今明顯更高 (61.7%，而 Composer 1.5 為 47.9%) ；這項基準測試涵蓋模型設定開發者環境能力的測試。這表示 Composer 2 將為 autoinstall 提供更好的基礎。我們預期在未來的訓練輪次中，先前的 Composer 實例將在訓練流程的許多其他面向扮演重要角色，包括輪次管理、資料前處理與架構調校。

深入了解 Composer 2