摘要： Cursor 工程師 Josh Ma 於 2026 年 6 月 2 日回顧，打造雲端代理不是把本地代理搬上伺服器，而是重建開發環境、可靠性與任務編排。文章指出環境完整度比模型選擇更能決定輸出品質，改用 Temporal 後可靠性超過兩個 9。架構上則把代理迴圈、機器狀態與對話狀態拆開治理。
難題從來不在「上雲」，而在重造代理賴以運作的世界
故事得從一年前說起。2026 年 6 月 2 日，Josh Ma 在 Cursor 的工程部落格寫下這段回顧：團隊當初推出雲端代理（cloud agent）時，預設的做法不過是把本地端代理原樣搬上伺服器執行。走過一整年，他們的想法已經徹底改觀——這件事早已偏離「移植」的本質，比較像替代理套上一層近乎作業系統等級的基礎設施。
為什麼前後認知差這麼多？如今的雲端代理各自跑在獨立的虛擬機器裡，環境、依賴套件、網路存取一應俱全。它們能同時並行、在無人盯著的情況下運作，還接得下筆電根本撐不住的長時程任務。但這些能力的背後，站著三個本地端代理幾乎不會碰到的難關：開發環境、可靠性，以及任務編排。
環境給得齊不齊，決定代理輸出的上限
Josh 在文中提出一個反直覺的發現：左右雲端代理輸出品質的最大單一變數，不在模型本身有多強，而在代理手上是不是握有一套完整的開發環境。
在本地端這根本不成問題：代理直接沿用筆電上現成的 shell、套件與環境變數，什麼都不必重造。雲端卻得全部從零搭起。麻煩的是，環境一旦殘缺，系統多半不會跳出錯誤、也不會崩潰——輸出品質只是無聲地往下掉。開發者常把這種退化錯怪到模型頭上，而 Cursor 團隊一次次追查到底，結論幾乎一致：代理手邊缺少執行或驗證工作所需的環境條件。
一年前這個問題還不突出，畢竟當時的模型本來就不太懂得善用環境。模型愈來愈聰明之後，環境完整與否反倒變成代理能否施展實力的瓶頸。為了補上這一塊，Cursor 逐步蓋出一整套基礎設施：幫使用者更準確組出代理環境的工具、讓代理 VM 在對話之間迅速休眠又甦醒的機制、負責 VM 映像檔檢查點與分支的管線，以及一層讓人類與代理都能讀懂並操作環境的整合介面。
這聽起來幾乎是企業 IT 部門的日常，而實際上也真的是。當雲端代理開始要開 PR、抓依賴套件、查資料，Cursor 接著補上了密文遮蔽、網路政策與憑證管理——說穿了，就是替代理架一套企業等級的 IT 治理。
跑得久的代理，得先有撐得住的底座
可靠性是雲端代理的另一道關卡，只是這裡的「不可靠」與本地端毫無相同之處。本地端擔心的是代理吃光筆電資源；雲端代理住在各自隔離的 VM 裡，開發者能同時開好幾個，交辦一跑數小時的任務。
不過 VM 自己也帶來新的斷點來源：推論服務提供者當機、pod 得置換、EC2 節點下線。Cursor 最初的設計是工作竊取架構——worker 節點把代理任務領走，一路跑到收工。Josh 直言這套從本地端照搬過來的做法撐不住場面，beta 早期的雲端代理只有區區一個 9 的可靠性。
團隊後來意識到，自己正在徒手重造 Temporal 早就解決過的那些持久執行原語：重試機制、跨機器排程、撐過節點故障的存活能力。於是他們索性搬去 Temporal。如今代理迴圈扛得住推論服務的短暫中斷，pod 休眠後再恢復也沒事，任務甚至能連跑數天到數週。單是這次遷移，就把可靠性推過了兩個 9。截至文章刊出，Temporal 每天經手超過五千萬次動作，分布於超過七百萬個獨立工作流程；Cursor 內部則有超過四成的 PR 出自雲端代理之手，占比還在上升。
Josh 也交代了他們在 Temporal 工作流程設計上學到的教訓：他們捨棄「永恆」式的單一代理工作流程，改成多條較短的工作流程，各做完一個任務就收尾——版本升級因此輕鬆得多。活動也切得比以往更細，讓 timeout 與重試被更精準地涵蓋；畢竟非同步工具呼叫、子代理、推論服務中斷這些真實世界的狀況，早已推翻當初設計時的假設。
代理、機器、對話狀態：三件事分開管
一旦雲端代理不再是「單一迴圈綁死單一機器」，架構就非改不可。現在 Cursor 的雲端代理可能本體在一台機器上，同時派生出非同步子代理散落到其他機器，也可能先從本地端起跑、再把工作委派給雲端。子代理的壽命可以超過父代理，所在的 pod 類型也可以截然不同。
要讓這套玩法成立，團隊特意把代理迴圈、機器狀態與對話狀態三者拆開。代理迴圈棲身在 Temporal 裡，而不是 VM 上；如此一來 pod 的生命週期能單獨管理，代理也能落在各種 pod 類型上——唯讀 VM、預熱 VM 這類最佳化設計都在此列。
對話這一側同樣獨立處理。儲存與串流層被抽離核心代理工作流程，團隊為此做了一個高效率的 append-only 儲存機制，把對話更新一路串流到網頁與桌面用戶端。這一層自己會接手重試：當代理迴圈的某個步驟在吐出部分輸出後失敗重來，用戶端能察覺這個狀況、把串流倒帶，改呈現新資料而不是舊的。
該握多緊、該放多開：harness 的拿捏
Josh 點出一條貫穿全文的張力線：harness 裡究竟該塞進多少寫死的邏輯，又有多少該留給代理自行判斷？
早期對代理能力沒什麼信心，harness 會在每個任務收尾後再三檢查成果、強制 commit 接著 push。模型強起來之後，這些邏輯開始被搬出 harness，改造成代理可自行操作的工具。一年前，多儲存庫設定還得寫死在 harness 裡；現在只消告訴代理儲存庫的佈局、遞上分支與 PR 的工具，其餘全交給它自己拿主意。
CI Autofix 走過同樣的轉變。舊版 harness 內建抓取 job 失敗紀錄再寫進 VM 的邏輯；如今只發給代理 GitHub CLI 的存取權，並把大量輸出自動寫進代理搜尋得到的檔案。通知代理的訊息跟著精簡許多，Josh 料定這條路還會繼續走下去。
這不代表 harness 會走進歷史，而是它承載的內容會不斷翻新。電腦操作（computer use）就是現成的例子：Cursor 的雲端代理 harness 內建一種專責電腦操作的子代理類型，自帶模型路由、客製化提示詞與螢幕錄影。VNC 和 Chrome 歸屬於環境，由父代理與子代理共用，父代理因此能直接拿它們執行 Playwright 腳本。這些鷹架之所以存在，是因為模型還沒成熟到能獨自處理電腦操作；不過，何時啟用這項能力的決定權仍握在代理手裡。
提示詞這一環，雲端代理也得和本地端有別。團隊刻意推著雲端代理走向更自主，理由是卡住的代價實在太高——本地端你清楚代理何時停手、正等你點頭；雲端裡它可能呆坐好幾個小時，等你回頭查看才發現。
下一步：代理自己抓環境問題，不必等人來救
往前看，Cursor 團隊想跳脫「不是手把手帶著代理，就是完全放手」的二選一。Josh 認為更理想的模式，是發給代理一套認識周遭系統的工具——讓它主動回報少了哪個密文、網路存取被擋在哪裡、環境的什麼毛病讓它走不下去，接著自己動手修復。他最近在另一篇研究部落格提過名為「autoinstall」的方向，正是其中一條可能路徑。
過去幾個月，雲端代理的進步快得驚人，而且改變的速度只會越來越快。Cursor 雲端代理的價值就在這裡：團隊能直接取用這整片不斷變寬的能力表面，不必自己建造、也不必自己維護底層基礎設施。對產品開發者而言，最值得帶走的一課也許是：唯有認真把代理視為團隊的一員，你才會看清——它缺的不是更聰明的模型，而是一個容得下它真正工作的世界。