真正難的不是把 Agent 搬上雲端，而是重建它需要的整個世界
先把時間拉回一年前。Josh Ma 在 2026 年 6 月 2 日的 Cursor 工程部落格裡回顧，當時團隊推出雲端代理（cloud agent）時，心裡想的大概只是把本地端代理搬到伺服器上跑。一年後，他們的體會完全不同：這項工作愈來愈不像「移植」，反而更像在代理外面包一層作業系統級的基礎設施。
為什麼差距這麼大？因為雲端代理如今是在獨立的虛擬機器上運作，擁有自己的環境、依賴套件和網路存取能力。它們可以平行工作、無人值守，也能接手本地端筆電承擔不了的長時間任務。這些能力聽起來很美好，但背後藏著三個本地端代理不太需要面對的難題：開發環境、可靠性，以及任務編排。
開發環境本身就是產品，不是附加設定
Josh 在文章裡點出一個很有趣的觀察：雲端代理輸出品質最大的單一影響因素，不是模型強弱，而是「它有沒有拿到一個完整的開發環境」。
這件事在本地端理所當然，因為代理直接繼承你筆電上的 shell、套件、環境變數，什麼都不用重建。但到了雲端，一切都得從零打造。更棘手的是，環境不完整的時候，系統通常不會報錯，也不會 crash——它只會讓代理的輸出品質悄悄下滑。開發者很容易誤以為是模型能力不足，但 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 儲存機制，將對話更新串流給網頁和桌面用戶端。這一層會自行處理重試：如果代理迴圈的某個步驟在串流出部分輸出後失敗並重試，用戶端可以偵測到這個狀況、倒帶串流，並顯示新資料而非舊的。
知道什麼時候該把手放開
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 雲端代理的價值在於，團隊可以直接運用這整片不斷擴張的能力表面，而不用自己建造或維護底層的基礎設施。對產品開發者來說，這裡最值得帶走的一課或許是：當你開始認真把代理當成團隊成員來看待，你才會發現它需要的不是更聰明的模型，而是一個它能真正工作的世界。
參考來源
本文由 AI 協助自上述來源整理，經人工審核後發布。