當 AI Agent 打爆你的 CI/CD：Cursor 的吞吐量革命

本文整理自 Latent Space Podcast 2026 年 3 月播出的單集。

{{< youtube tMflcZHo2zI >}}

{{< spotify "episode/06rnTA2QtPDdY2XeAFeQ9Q" >}}

{{< apple-podcast "tw/podcast/cursors-third-era-cloud-agents/id1674008350?i=1000753497435" >}}

---

Cursor 最近做了一個內部實驗：用超過 100 個並行 Agent 打造一個瀏覽器。每個 Agent 跑在獨立的虛擬機器裡，同時推送程式碼、觸發 CI。結果？他們自己的 GitHub Actions 被打爆了。

Jonas 在 Latent Space Podcast 裡描述這個場景時，語氣裡帶著一種「踩到自己的坑」的興奮感：「我們最近搞掛了自己的 GitHub Actions，因為太多 Agent 同時在產生和推送程式碼，CI/CD 直接過載。」他接著說了一句更值得思考的話：「等於我們的有效人力瞬間增加了十倍。」這不是一個 Bug 報告，而是一個信號。它告訴我們，軟體開發正在從一個「延遲優化」的世界，走向一個「吞吐量並行化」的世界。而大部分團隊的基礎設施還停留在前一個世界。

為什麼需要 100 個獨立的 VM

要理解為什麼 100 個 Agent 會打爆 CI/CD，得先理解 Cursor 雲端 Agent 的架構。

在過去，AI 編程助手跑在你的本地機器上。Agent 佔用你的 CPU、記憶體和磁碟空間，你同一時間頂多跑一兩個。更重要的限制是，所有 Agent 共享同一個開發環境，它們修改的是同一組檔案。這就像讓十個廚師共用同一個砧板，動作快了，但搶資源的衝突也多了。兩個 Agent 同時改同一個檔案，結果就是 merge conflict。

Cursor 的解法是給每個 Agent 一台獨立的雲端虛擬機器。每個 VM 有完整的作業系統、開發環境、瀏覽器、終端機和 Git。Agent 在自己的 VM 裡自由操作，不會影響到其他 Agent。修改完的程式碼推送到自己的分支，交出一個獨立的 PR。這個架構徹底去除了 Agent 之間的耦合。你可以同時跑十個 Agent 處理十個不同的功能，它們不會互相干擾，因為每個都在自己的沙箱裡工作。

但這個架構有一個「副作用」，Cursor 自己踩了進去：當十個 Agent 完成工作後會同時觸發 CI/CD Pipeline。如果你的 CI 系統是為「一個團隊一天合併十幾個 PR」設計的，突然湧入幾十個甚至上百個 PR，它就撐不住了。在打造內部瀏覽器的實驗中，工程師 Wilson 同時啟動了超過 100 個 Agent，每秒產生數千個 token 的程式碼。這些 Agent 各自完成工作後，推送了大量的 commit 到 GitHub，GitHub Actions 的並行執行佇列瞬間爆滿。Cursor 被迫回頭重新設計自己的 CI/CD 架構，讓它能承受「十倍有效人力」的負載。

Latency vs Throughput：心智模型的根本轉變

Jonas 提出了一個思考框架，我覺得值得每個開發團隊認真消化。他把軟體開發的效率拆成兩個維度：延遲（Latency）和吞吐量（Throughput）。

過去幾年，AI 編程工具的重點是降低延遲。讓一個人寫程式寫得更快：更好的自動補全、更聰明的 Agent、更準確的一次性完成。這是一個「單管道」的思維，把精力花在讓那根管子流得更快。每次模型升級，大家比較的都是「這個 Agent 一次能完成多少」「正確率提高了幾個百分比」。重點始終是「一個人配一個 Agent 能做多少事」。

但 Jonas 認為，接下來真正的突破不是讓管子流得更快，而是讓管子變得更寬，同時讓更多管子並行。他用了一個水管的比喻：想像你面前有一個水池要裝滿。過去的做法是加大水壓，讓同一根水管出水更快。現在的做法是同時接十根水管，每根獨立運作。單根水管的流速可能差不多，但十根並行的總產出量是原來的十倍。

這個心智模型的轉變對開發者有幾個實際的意義。第一，你花時間的方式會改變。過去你花 80% 的時間寫程式碼，20% 的時間審核和規劃。未來可能翻過來：80% 的時間在審核 Agent 的產出、拆解任務、分配工作，只有 20% 的時間自己動手寫。第二，瓶頸會從「寫程式的速度」轉移到「人類審核的速度」。Agent 可以 24 小時不停跑，但你不行。如何高效地審核十個 Agent 同時產出的結果，會成為一項新的核心技能。第三，基礎設施需要重新設計。CI/CD、Code Review 流程、分支管理策略，這些原本為「十幾個人的團隊」設計的系統，突然要承受百倍的負載。Cursor 的 CI/CD 被打爆就是最好的例子。

Grind Mode：長跑前先花三小時對齊

Cursor 從瀏覽器實驗中學到的最重要教訓，和技術無關，而是關於溝通。

Grind Mode 是 Cursor 的長時間自主執行功能，讓 Agent 連續工作數小時甚至數天，中間不需要人類介入。聽起來很美好，但 Jonas 指出一個關鍵原則：如果 Agent 要跑三天，你最好在開跑前花幾個小時確認你們對任務的理解完全一致。這不是一句客氣話，而是血淋淋的教訓。想像你啟動了一個 Agent 去重構一個模組，三天後回來發現它把整個架構改成了你完全不想要的方向。三天的運算資源浪費了，你還得花更多時間把它改回來。

Cursor 用強制的計畫對齊機制來解決這個問題。Agent 在開始執行前，必須先產出一份完整的計畫書，詳細描述它打算怎麼做、分幾個步驟、每一步的預期產出是什麼。人類審核計畫、修正方向、確認一致之後，Agent 才會開始執行。投入在對齊上的時間，應該與 Agent 的自主執行時間成正比。如果 Agent 跑十分鐘就好，花三十秒講清楚需求就夠了。但如果 Agent 要跑三天，花三小時把每一個細節都討論清楚是值得的。

這個比例原則聽起來簡單，但在實際操作中很容易被忽略。開發者總覺得「差不多就好，Agent 應該能理解我的意思」。結果往往是 Agent 理解了，但理解的方向和你想的不一樣。這和帶新人其實很像：你交代一個任務，覺得自己講得很清楚了，結果新人做出來的東西和你想的完全不同。差別在於，新人做錯了你可以當面溝通，Agent 做錯了你三天後才發現。

模型選擇：從死忠粉到即時切換

Sam 在 Podcast 裡坦承了一件事：他曾經是 Opus 4.5 的死忠粉，覺得這個模型什麼都好。但當 Codex 5.3 一出來，他直接全面切換了。「以前我是 Opus 4.5 的死忠。Codex 5.3 一出來，直接切過去了，現在只用它。」

這個小故事背後反映的是 AI Agent 領域的現實：模型的領先週期非常短，今天的最佳選擇可能三個月後就被取代。如果你的工作流綁死在某一個模型上，你會錯過新模型帶來的能力提升。Cursor 的解法是「Cursor Auto」，一個自動路由功能，根據每個請求的特性選擇最適合的模型。在桌面版 App 裡已經運作，現在正在擴展到雲端 Agent。

但 Cursor 還做了更激進的實驗：Model Synthesizer Layer（模型綜合層）。他們同時把同一個任務丟給不同的模型供應商，讓每個模型在獨立的 VM 裡執行，然後用一個 Synthesizer Agent 來綜合所有結果，寫出一個融合各家優點的最終版本。這個實驗的發現出乎意料：不同模型供應商產出了互補的結果，即使其中一個模型在基準測試上明顯領先，最終的綜合版本還是比任何單一模型的結果好。這驗證了一個論點：真正的護城河不在於你用了哪個模型，而在於你如何組合、路由、和綜合多個模型。

Sub-Agent：Agent 內部的分工

Agent 的規模擴大之後，一個自然的問題浮現：單一 Agent 會在長時間執行中累積太多的上下文，超出模型的處理能力。你讓一個 Agent 連續工作八小時，它的對話歷史會膨脹到非常長，模型開始忘記前面的指令，或者把不同階段的任務搞混。

Cursor 的解法是 Sub-Agent：讓主 Agent 把特定子任務委派給更小、更專注的 Agent。Cursor 內建了兩種 Sub-Agent。第一種是 Explore Sub-Agent，專門負責閱讀和理解程式碼庫。這種 Agent 會被路由到更快、更便宜的模型上（比如 Composer），因為它不需要寫程式碼，只需要理解和摘要。你可以同時啟動 50 個 Explore Sub-Agent 去掃描程式碼庫的不同部分，然後把摘要匯報給主 Agent。第二種是 Computer Use Sub-Agent，專門負責在瀏覽器或桌面上測試功能。這種 Agent 需要處理大量的截圖，對模型的多模態能力要求更高。

Sub-Agent 解決了兩個問題。第一是上下文管理：主 Agent 不需要把所有細節都記在自己的上下文窗口裡，而是在 Sub-Agent 的邊界做摘要。一個八小時的任務可能包含幾十個 Sub-Agent 的呼叫，但主 Agent 只需要記住每個 Sub-Agent 的摘要結果，不需要記住所有細節。第二是並行化：你可以同時派出幾十個 Sub-Agent 去做獨立的子任務，然後把結果彙整回來。這把「一個 Agent 做一件事」升級成了「一個 Agent 指揮幾十個 Sub-Agent 同時做幾十件事」。

我的觀察：Jevons Paradox 正在軟體開發中上演

經濟學裡有一個叫做 Jevons Paradox（傑文斯悖論）的概念：當技術進步讓某種資源的使用效率提高時，這種資源的消耗量反而會增加而不是減少。十九世紀的蒸汽機效率提高了，煤的消耗量不減反增。原因是效率提升讓更多應用場景變得可行，總消耗量因此暴增。

AI 編程工具正在完美演繹這個悖論。表面上，AI 讓寫程式變得更有效率了，每行程式碼的成本下降了。但 Cursor 的定價演進告訴了我們真正發生的事：開發者花在 AI 上的錢不是減少了，而是從每月 20 美元暴增到可能上萬美元。因為效率提升讓更多任務變得「值得讓 Agent 去做」。以前一個小 Bug 你覺得不值得花時間修，現在丟給 Agent 五分鐘就搞定了，你當然會修。以前你覺得「這個 Feature nice to have 但沒時間做」，現在開一個 Agent 跑一天就有了，你當然會做。

Sam 在 Podcast 裡預測，到 2026 年底會有接近 100% 的程式碼由 Agent 產出。這個預測可能太激進，但方向是對的。問題在於：當 Agent 的邊際成本趨近於零，「要不要做」的決策門檻會大幅降低。結果可能是一堆沒人真正需要的功能被 Agent 生出來，反而增加了維護的負擔。在 Agent 時代，知道什麼不該做，可能比知道怎麼做更值錢。