Cursor實驗多代理協作自動寫程式，一周從零打造瀏覽器程式碼庫破百萬行

AI程式開發工具Cursor公開一項長期實驗成果，團隊嘗試讓多個程式開發代理程式在同一專案上連續運作數周，以並行方式推進原本需要人類團隊數個月的工程規模。研究團隊在單一專案同時執行數百個代理程式，累積寫出超過100萬行程式碼，並投入數十億以上Token。在協調架構上，團隊改採分工設計，將系統推進到能以星期為單位的運作規模。

Cursor在文中先交代多代理協作的主要障礙不在於能不能同時跑很多代理程式，而在於如何避免彼此卡住與重複勞動。

研究團隊把角色拆成規畫者與執行者，改用工作管線式分工取代扁平結構。規畫者持續逐一走訪程式碼庫並產生任務，必要時可再衍生子規畫者，讓規畫本身也能平行化，執行者則只專注完成被指派任務，完成後推送變更，不必同時兼顧全局協調。每輪迭代結束後，由裁判代理程式判斷是否繼續。

開發團隊以從零打造網頁瀏覽器作為壓力測試，讓多代理程式連續運作接近一周，累積產出超過100萬行程式碼、約1,000個檔案，並將程式碼公開在GitHub供外界檢視。團隊也把同樣方法用在自家程式碼庫的工程任務上，例如在不改變既有專案基礎的前提下，將前端框架Solid搬遷到React，歷時超過3周，產生數十萬行等級的新增與刪除變更，目前已啟動測試並評估具備合併可行性。

研究人員特別提到，模型選擇會直接影響長時間自主任務的穩定度。GPT-5.2系列在長期運作時更能遵循指令、維持焦點、避免漂移，且能更完整精準地收尾實作，相較之下，Opus 4.5較容易提早停下或採取捷徑，將控制權交回使用者，研究人員也指出，不同模型適合不同角色，例如GPT-5.2在規畫者任務上表現優於GPT-5.1-codex，因此團隊已改採依角色挑選模型，而非單一模型包辦全部工作。

不過，研究人員坦言，多代理協調仍是難題，目前方法雖可運作，但距離最佳化仍有落差，例如規畫者需要在任務完成時被喚醒以接續安排，避免等待空窗。部分代理程式也可能運行過久，需要更好的節奏控制。此外，系統仍仰賴定期重啟以對抗漂移，且避免陷入局部最佳化，忘記整體目標。