過去幾週，我們一直在實驗讓程式開發代理連續自主運行數週。

我們的目標是理解，在那些通常需要人類團隊花上數月才能完成的專案上，我們能在代理式程式開發方面把邊界推進到什麼程度。

這篇文章說明，我們從在單一專案上並行運行數百個代理、協調它們的工作，並觀察它們寫出超過一百萬行程式碼與數兆個 token 的過程中所學到的內容。

#單一代理的侷限

現在的代理在處理明確、集中的任務時表現不錯，但在面對複雜專案時就顯得緩慢。自然的下一步，就是讓多個代理並行運作，不過要想清楚如何協調它們則相當具有挑戰性。

我們一開始的直覺是，事先規劃會太過僵化。在大型專案中的推進路徑本身就不明確，而在一開始也很難看出應該如何正確切分工作。因此我們先從動態協調著手，讓代理根據其他代理當前正在做的事情來決定自己要做什麼。

#學會協同運作

我們最初的方法是讓各個代理享有同等地位，並透過一個共享檔案自行協調運作。每個代理會檢查其他代理在做什麼、認領一個任務，然後更新自己的狀態。為了避免兩個代理同時搶到同一個任務，我們使用了鎖定機制。

這種做法以一些出乎意料的方式失敗了：

1. 代理會持有鎖太久，甚至完全忘記釋放。即使鎖定機制運作正確，它也會成為瓶頸。二十個代理的速度會被拖慢到等同兩三個代理的有效吞吐量，大部分時間都花在等待上。

2. 系統非常脆弱：代理可能在持有鎖時失敗、嘗試取得自己已經持有的鎖，或是在根本沒有取得鎖的情況下就更新協調檔案。

我們嘗試用樂觀併發控制取代鎖。代理可以自由讀取狀態，但如果自上次讀取後狀態已變更，寫入就會失敗。這樣更簡單也更穩健，但仍然存在更深層的問題。

在沒有階層的情況下，代理變得更趨於保守、規避風險。他們會避免困難的任務，改為進行小而安全的修改。沒有任何代理會對困難問題或端到端實作負起責任。結果工作長時間在原地打轉，卻沒有實質進展。

#規劃者與執行者

我們接下來的做法是拆分角色。與其採用每個代理都做所有事情的扁平式架構，我們改為建立一條具備明確職責分工的管線（pipeline）。

• 規劃者（Planners） 會持續探索整個程式碼庫並建立任務。他們可以為特定區域衍生出子規劃者，讓規劃本身也能並行且遞迴地進行。

• 執行者（Workers） 負責領取任務並專注在完成它們。他們不會與其他執行者協調，也不必擔心整體全貌，只是一心一意埋頭處理分配給自己的任務直到完成，然後推送他們的變更。

在每一輪循環結束時，一個裁決代理會決定是否繼續，接著下一次迭代會從乾淨的狀態重新開始。這解決了我們大部分的協調問題，並讓我們能擴展到非常大型的專案，而不會有任何單一代理陷入視野過窄的情況。

#運行數週

為了測試這個系統，我們給了它一個雄心勃勃的目標：從零開始打造一個網頁瀏覽器。這些代理持續運行了將近一週，在 1,000 個檔案中寫出了超過 100 萬行程式碼。你可以在 GitHub 上瀏覽原始碼。

即使程式碼庫規模這麼大，新代理仍然能理解它，並持續推動實質進展。數百個 worker 會同時並行執行，在幾乎沒有衝突的情況下推送到同一個分支。

雖然看起來可能只是一張簡單的螢幕截圖，但要從零開始打造一個瀏覽器其實極度困難。

另一個實驗是在 Cursor 程式碼庫中，直接就地將 Solid 遷移到 React。這花了超過 3 週時間，產生了 +266K/-193K 的修改。隨著我們開始測試這些變更，我們確實相信有可能把這個變更合併。

另一個實驗是改善一個即將推出的產品。一個長時間執行的代理，透過高效的 Rust 版本，讓影片渲染速度提升了 25 倍。它還新增了支援縮放與平移的流暢操作，搭配自然的彈簧過渡與動態模糊，並能跟隨游標移動。這段程式碼已經合併，並很快就會上線到正式環境。

我們還有一些其他有趣的範例仍在運行中：

• Java LSP：7.4K commits，550K LoC
• Windows 7 模擬器：14.6K commits，1.2M LoC
• Excel：12K commits，1.6M LoC

#我們學到了什麼

我們已經在這些代理上投入了數十億個 tokens，只為達成單一目標。這個系統雖然稱不上完全高效，但效果遠超出我們的預期。

對於執行時間極長的任務，模型選擇格外關鍵。我們發現 GPT-5.2 模型在長時間的自主工作上表現好得多：更能遵循指示、保持專注、避免偏移，並精準且完整地落實需求。

Opus 4.5 則傾向在方便時提早停止、走捷徑，很快就將控制權交還。我們也發現，不同模型在不同角色上各有所長。即使 GPT-5.1-codex 是專門為寫程式訓練的，GPT-5.2 仍然是更好的規劃者。我們現在會依各個角色選用最合適的模型，而不是只依賴單一通用模型。

我們的許多改進，其實來自「減少」而不是「增加」複雜度。一開始，我們為了品質控管與衝突解決建立了一個整合者角色，但後來發現它製造的瓶頸比解決的還多。工作代理本身就已經能夠處理衝突。

實務上，最好的系統往往比你想像得更簡單。一開始我們嘗試套用分散式運算與組織設計中的系統模型，但並不是所有這些模型都適用於代理。

合適的結構程度通常介於兩端之間：結構太少，代理之間會互相衝突、重複工作、並且偏離目標；結構太多，又會讓系統變得脆弱。

系統中有相當大一部分的行為，其實取決於我們如何為這些代理設計提示（prompt）。要讓它們彼此良好協調、避免病態行為，並在長時間內維持專注，需要大量實驗。執行框架與模型固然重要，但提示本身更關鍵。

#接下來會怎麼發展

多代理協調依然是個棘手的問題。我們目前的系統雖然可行，但距離最佳狀態還很遠。規劃器應該在其任務完成時被喚醒，以規劃下一步。代理有時會執行得過久。我們仍然需要定期重新啟動，以對抗偏移與過度聚焦的問題。

不過，核心問題「我們能不能透過投入更多代理來擴展自動化程式開發的能力？」有一個比我們預期更樂觀的答案。數百個代理可以在同一個程式碼庫上協作數週，為雄心勃勃的專案帶來實質進展。

我們在這裡開發的技術，最終將用來強化 Cursor 的 Agent 能力。如果你有興趣挑戰 AI（人工智慧）輔助軟體開發中最困難的問題，歡迎透過 hiring@cursor.com 與我們聯絡。