168小時AI狂寫300萬行代碼!Cursor公開數百智能體協作方案

168小時AI狂寫300萬行代碼!Cursor公開數百智能體協作方案

文章圖片

168小時AI狂寫300萬行代碼!Cursor公開數百智能體協作方案

文章圖片

168小時AI狂寫300萬行代碼!Cursor公開數百智能體協作方案

文章圖片


夢晨 發自 凹非寺量子位 | 公眾號 QbitAI
AI寫代碼 , 這次玩大了 。
Cursor創始人宣布一項瘋狂實驗的結果:讓數百個AI智能體連續跑了整整一周 , 從零開始 , 硬生生造出了一個可用的Web瀏覽器 。

項目代號FastRender , 產出超過300萬行代碼 , 核心是一個用Rust從頭寫的渲染引擎 , 甚至還自帶一個定制的JavaScript虛擬機 。
Truell稱這款瀏覽器“勉強能用” , 跟成熟的Chrome內核差得遠 , 但已經能基本正確地渲染谷歌首頁了 。
并且項目全部源碼已公開在GitHub 。

背后的大腦:GPT-5.2-Codex這次實驗能跑通 , 靠的是OpenAI在2025年12月剛發布的GPT-5.2-Codex 。
這個模型被OpenAI定義為“最前沿的智能體編碼模型” , 專門為解決復雜的現實世界軟件工程問題設計 。
它不再是簡單的代碼補全工具 , 而是能像人類工程師一樣自主規劃任務 , 獨立完成新功能開發、代碼重構、漏洞排查這類需要持續數小時甚至數天的長周期工作 。

在技術層面 , GPT-5.2-Codex引入了一項叫“上下文壓縮”(Context Compaction)的技術 , 讓模型在處理需要理解龐大代碼庫的長程任務時 , 能夠保持邏輯一致性 。
在SWE-Bench Pro和Terminal-Bench 2.0等權威軟件工程基準測試中 , 這個模型均拿下了最先進水平的成績 。

OpenAI還稱它是“迄今為止最具網絡安全能力”的模型 , 此前已有研究人員用它的前代版本發現了React框架中的高危漏洞 。
數百個智能體怎么協作?讓一個AI模型寫代碼不難 , 難的是讓幾百個AI智能體同時在一個代碼庫里干活還不打架 。
Cursor為此設計了一套多智能體協作架構 , 但這條路走得并不順 。
最初團隊嘗試了扁平化的協作模式 , 讓所有智能體地位平等 , 通過共享文件和鎖機制來協調 。
結果很快暴露出嚴重問題:
為避免修改沖突設置的鎖定機制導致智能體大量時間用于等待 , 20個智能體的實際吞吐量僅相當于2到3個;
智能體還可能在鎖定時崩潰或忘記釋放鎖 , 直接把系統搞死;
在沒有明確層級的情況下 , 智能體們開始摸魚 , 傾向于挑簡單安全的任務做 , 回避真正困難的核心問題 , 導致項目停滯不前 。
【168小時AI狂寫300萬行代碼!Cursor公開數百智能體協作方案】踩完這些坑后 , Cursor轉向了一種“規劃者-工作者-裁判”的分層架構:
規劃者(Planner)負責宏觀任務 , 持續探索代碼庫并創建具體任務 , 還能遞歸地生成針對特定領域的子規劃者來并行規劃 。
工作者(Worker)是純粹的執行者 , 接收任務后心無旁騖地寫代碼 , 完成后直接推送 , 不需要跟其他工作者協調 。
裁判(Judge)則在每個工作周期結束時評估進展 , 決定是否繼續下一個迭代 , 這個機制允許系統定期從干凈狀態重新開始 , 防止任務跑偏 。
這套清晰的層級結構和責任分離 , 最終讓數百個AI智能體能夠高效地在同一個代碼庫的同一分支上并行工作 , 代碼沖突極少 。
一些反直覺的發現Cursor在這次實驗中積累了不少經驗 , 其中有些結論還有點反直覺 。
比如模型選擇 。
團隊發現 , 對于極長時間的自主任務 , 通用的GPT-5.2模型在規劃能力上甚至優于專門為編碼訓練的GPT-5.1-Codex 。
而Anthropic的Claude Opus 4.5模型則傾向于“走捷徑”并盡早交還控制權 , 更適合與人類協作的交互式場景 , 不太適合持續數周的自主任務 。
另外團隊強調 , 提示詞的設計比模型本身和執行環境更重要 , 如何引導智能體正確協作、避免病態行為并長時間保持專注 , 需要大量試錯 。
這次實驗在業界引發了熱烈討論 。 OpenAI聯合創始人Greg Brockman稱之為“對未來的驚鴻一瞥” 。

Stability AI前CEO Emad Mostaque則估算 , 構建這個瀏覽器可能消耗了約30億個Token 。 但隨著Token成本持續下降 , 軟件開發的邊際成本正在趨近于零 。

當然質疑聲也不少 。
有人指出 , AI模型的訓練數據中本就包含大量開源瀏覽器代碼 , 這種“從零構建”在多大程度上是真正的創造 , 還有待商榷 。
也有人擔心 , 由AI生成的數百萬行代碼 , 人類工程師要怎么調試和維護這個龐大的黑箱 。
Cursor承認目前的多智能體系統遠非完美 , 仍存在規劃者無法及時響應、智能體過度運行等問題 。
但這個實驗至少證明了一件事:通過增加智能體數量來擴展自主編碼能力 , 是可行的 。
團隊正在把實驗中開發的技術逐步整合進商業產品 。 未來軟件開發團隊的結構可能會變成這樣:人類負責架構設計、AI監督和最終驗證 , 具體的編碼實現則大規模交由AI智能體完成 。
GitHub:https://github.com/wilsonzlin/fastrender
參考鏈接:[1
https://cursor.com/blog/scaling-agents[2
https://x.com/mntruell/status/2011562190286045552

    推薦閱讀