燒掉數萬億 Token、數百 Agent 連跑一周：Cursor“從零寫瀏覽器”，結果是拼裝人類代碼？

整理 | Tina

現在，大模型可以獨立寫完整整一個瀏覽器了？

Cursor CEO Michael Truell 最近分享了一項頗為吸睛的實驗：他們用 GPT-5.2 讓系統連續不間斷運行一周，從零構建出一個“可用”的 Web 瀏覽器。按他的描述，產出規模達到：超過 300 萬行代碼、橫跨數千個文件，全部通過這套 AI 驅動的編程平臺生成。

數百個Agent “從零”

寫了一個瀏覽器？

按照他的說法，這個項目并沒有依賴現成的渲染引擎，而是用 Rust 從零實現了一整套渲染引擎，其中包括 HTML 解析、CSS 級聯規則、布局計算、文本排版（text shaping）、繪制（paint）流程，甚至還實現了一個自定義的 JavaScript 虛擬機。

Truell 也坦言，這個瀏覽器目前只是“勉強能用”，距離 WebKit 或 Chromium 等成熟引擎還有很大差距；但團隊依然“感到震驚”，因為簡單網站在它上面渲染得很快，而且整體效果在很大程度上是正確的。

與此同時，Cursor 還發布了一篇博客文章，題為《Scaling long-running autonomous coding》（擴展長時間運行的自主編程）。文章回顧了一系列實驗：讓“編程 agent 連續自主運行數周”，目標是“理解在那些通常需要人類團隊耗費數月完成的項目中，agentic coding 的能力邊界究竟可以被推進到什么程度”。

在這篇文章里，他們重點講的是多 Agent 如何協同：如何在單個項目上同時運行數百個并發 Agent、如何協調它們的工作，并觀察它們寫出超過一百萬行代碼和數萬億個 token 的過程與經驗。

Cursor 先承認了單個 Agent 的局限：任務規模一大、依賴一復雜，推進速度就會明顯變慢。并行化看似順理成章，但他們很快發現，難點不在并發，而在協同。

“學習如何協同：我們最初的方法是讓所有 agent 具有同等地位，并通過一個共享文件自行協同。每個 agent 會檢查其他 agent 在做什么、認領一個任務并更新自己的狀態。為防止兩個 agent 搶占同一項任務，我們使用了鎖機制。

這一方案在一些有趣的方面失敗了：

agent 會持有鎖太久，或者干脆忘記釋放鎖。即使鎖機制正常工作，它也會成為瓶頸。二十個 agent 的速度會下降到相當于兩三個 agent 的有效吞吐量，大部分時間都花在等待上。

系統非常脆弱：agent 可能在持有鎖的情況下失敗、嘗試獲取自己已經持有的鎖，或者在完全沒有獲取鎖的情況下更新協調文件。

我們嘗試用樂觀并發控制來替代鎖。agent 可以自由讀取狀態，但如果自上次讀取后狀態已經發生變化，則寫入會失敗。這種方式更簡單、也更健壯，但更深層的問題依然存在。

在沒有層級結構的情況下，agent 變得非常規避風險。它們會回避困難任務，轉而做一些小而安全的修改。沒有任何一個 agent 承擔起解決難題或端到端實現的責任。結果就是工作長時間在空轉，卻沒有實質性進展。”

為了解決這一問題，Cursor 最終引入了更明確的角色分工，搭建一條職責清晰的流水線：將 Agent 分為規劃者和執行者。

“規劃者（Planners） 持續探索代碼庫并創建任務。他們可以針對特定區域派生子規劃者，使規劃過程本身也可以并行且遞歸地展開。

執行者（Workers） 領取任務并專注于把任務完成到底。他們不會與其他執行者協調，也不關心整體大局，只是全力處理自己被分配的任務，完成后再提交變更。

在每個周期結束時，會有一個評審 Agent 判斷是否繼續，然后下一輪迭代會從干凈的初始狀態重新開始。這樣基本解決了我們的協同問題，并且讓我們可以擴展到非常大的項目，而不會讓任何單個 Agent 陷入視野過于狹窄的狀態。”

在此基礎上，Cursor 把這套系統指向一個更具挑戰性的目標：從零構建一個瀏覽器。他們表示，Agent 持續運行了將近一周，在 1,000 個文件中寫出了超過 100 萬行代碼（原文如此，跟 Michael Truell 說的 300 萬行不同），并將源碼發布在 GitHub 上供外界瀏覽。

Cursor 進一步宣稱：即便代碼庫規模已經很大，新啟動的 agent 仍然能夠理解它并取得實質性進展；同時，成百上千個 worker 并發運行，向同一個分支推送代碼，而且幾乎沒有沖突。

一場“全民打假”的開始？

這次實驗之所以引發強烈反應，很大程度上是因為：Web 瀏覽器本身就是軟件工程里公認的“地獄級”項目。

它難的不只是“寫代碼”，而是工作量的量級、模塊之間的高耦合，以及兼容性這條幾乎看不到盡頭的長尾。

在 Hacker News 上，有人順手拋了一個問題：“開發一個瀏覽器最難的地方是什么？”很快就有人給出一個類比：“說句真心話，這個問題幾乎等同于：開發一個操作系統最難的地方是什么？”

因為現代瀏覽器是千萬級代碼量的系統，能夠運行非常復雜的應用。它包含網絡棧、多種解析器、frame 構建與回流（reflow）模塊、合成（composite）、渲染（render）與繪制（paint）組件、前端 UI 組件、可擴展框架等等。這里面每一個模塊，都必須同時做到：既支持 30 年前的舊內容，也支持復雜得離譜的當代 Web 應用。同時，它還得在高性能、高安全前提下盡可能少占用系統資源，并且往往要跨 Mac、Windows、Linux、Android、iOS 等多個平臺運行。

還有人提到，最難的是那張超長的任務清單。瀏覽器里包含多個高復雜度模塊，每一個單拎出來都可能要做很久；更麻煩的是，它們之間還要通過一套相當“啰嗦”的 API 連接起來——很多接口你必須實現，至少也得先把殼子（stub）搭出來，否則系統就會崩。

Cursor 在博客中配了一段視頻，并寫道：“雖然這看起來像是一張簡單的屏幕截圖，但從頭開始構建一個瀏覽器是非常困難的。”

然而如果外界自己去嘗試編譯這個項目，會很快意識到：它離“功能齊全的瀏覽器”還差得很遠，甚至看起來在公開代碼狀態下，連最基本的構建都很難穩定通過。

從倉庫公開信息來看，近期 main 分支的多次 GitHub Actions 運行結果顯示失敗（其中還包括工作流文件本身的錯誤）；不少開發者的獨立構建嘗試也報告了數十個編譯錯誤。與此同時，最近的一些 PR 雖然被合并，但 CI 仍處于失敗狀態。

更有開發者表示自己回溯 Git 歷史，往前翻了約 100 個提交后表示，依然沒能找到一個可以“干凈編譯通過”的版本。

這也引出了一個問題：這些被 Cursor 描述為在代碼庫中長期并發運行的“agent”，在工程鏈路上到底做到哪一步？至少從當前公開狀態看，它們似乎并沒有把“能編譯、能檢查”當成最基礎的收斂目標——因為無論是 cargo build 還是 cargo check，都會立刻暴露出成片的編譯錯誤和大量警告。

而 Cursor 的博客文章除了提供代碼倉庫鏈接外，既沒有提供可復現的演示，也沒有提供任何已知的有效版本（標簽 / 發布 / 提交）來驗證截圖。無論如何，這文章本身給人一種原型功能完備的錯覺，卻忽略了此類聲明應有的基本可復現性特征。

有人在 Michael Truell 的 LinkedIn 上直接把結果拋了回去：“構建直接失敗，報了 32 個錯誤，代碼本身就是壞的；沒有任何 release、沒有 tag，CI 也在持續失敗，我們甚至連這個所謂‘可用的瀏覽器’都沒法編譯、沒法試跑。這更像是一場營銷活動，而不是一次真正的 agentic 實驗。”Michael Truell 至今沒有回復。

目前唯一一個在社交平臺上明確分享“復現成功”的人，是前瀏覽器開發者 Oliver Medhurst。他表示自己花了大約兩個小時修復編譯錯誤和漏洞，才把項目跑起來。至于性能，他的評價也很直接：有些頁面加載要整整一分鐘，“不算好”。

還有一個更敏感的追問也隨之出現：“所以這真的是從零開始寫的嗎？”他給出的回應更像一句反轉預告：“劇透：不是。”

更多網友通過翻看倉庫依賴發現，這個項目直接引入了 Servo （一個最初由 Mozilla 開發的基于 Rust 的瀏覽器）項目的 HTML 與 CSS 解析器（html parser、css parser），以及 QuickJS 的 Rust 綁定（rquickjs），并非所有關鍵組件都是自行實現。

再加上 selectors、resvg、wgpu、tiny-skia 等一系列成熟庫，這個“瀏覽器實驗”更像是直接調用了人類編寫的代碼，而不是“從零開始”的一整套渲染與執行引擎。

更搞笑的是，Cursor 這里用的還是一個發布于 2023 年 6 月的 wgpu 0.17 這種非常舊的老版本，而當前最新版本已經是 28（發布于 2025 年 12 月）。大概因為大模型寫代碼時往往會直接改版本管理文件（如 package.json、Cargo.toml），而不是通過 npm add、cargo add 這類構建工具來引入依賴。

這也不怪網友罵他們：

“這簡直是胡扯。應用根本跑不起來，功能也缺得厲害。LLM 更像是在把它訓練過的現成代碼拼起來做個瀏覽器——畢竟 Chromium 本來就是開源的。最后堆出了 300 萬行‘看起來很多’但沒有價值的代碼，結果還不能用，更談不上什么新產品。折騰到最后，你還是得讓開發者花大量時間去調試、排查安全漏洞，才能把它打磨得像一個早就存在的成熟產品。”

“兩周時間、數百個 agent，V8 和 Blink 又都是開源的。說到底，這就是在浪費 GPU 和電力。”

最后值得一提的是，這個實驗還暴露出一個不容忽視的問題：成本。

有人翻回 Cursor 的原帖指出，他們還在跑類似實驗，比如一個 Excel 克隆項目（https://github.com/wilson-anysphere/formula）。GitHub Actions 的概覽數據很夸張：累計觸發了 16 萬多次 workflow 運行，但成功的只有 247 次——失敗的主要原因不是代碼本身，而是超出了支出上限。

當然，Agent 并不在乎預算；但在真實的軟件工程里，可復現的構建、可持續的成本、可驗證的產出，才決定一個系統最終能不能被信任、被維護、被繼續推進。

https://cursor.com/cn/blog/scaling-agents

https://news.ycombinator.com/item?id=46646777

https://www.reddit.com/r/singularity/comments/1qd541a/ceo_of_cursor_said_they_coordinated_hundreds_of/

https://www.linkedin.com/posts/activity-7417328860045959169-PFuT/

https://xcancel.com/CanadaHonk

聲明：本文為 InfoQ 整理，不代表平臺觀點，未經許可禁止轉載。

會議推薦

InfoQ 2026 全年會議規劃已上線！從 AI Infra 到 Agentic AI，從 AI 工程化到產業落地，從技術前沿到行業應用，全面覆蓋 AI 與軟件開發核心賽道！集結全球技術先鋒，拆解真實生產案例、深挖技術與產業落地痛點，探索前沿領域、聚焦產業賦能，獲取實戰落地方案與前瞻產業洞察，高效實現技術價值轉化。把握行業變革關鍵節點，搶占 2026 智能升級發展先機！