雲端 AI Agent 的真正挑戰：不只是模型遠端化，而是沙盒、狀態與隔離的基礎設施難題

將 AI Agent 搬上雲端，遠不只是把模型或運算移到遠端伺服器這麼簡單。真正的挑戰與成本，在於建構一個可靠、安全且能維持長期運作的基礎設施。開發工具 Cursor 在打造雲端編碼 Agent 一年後分享的經驗，清楚揭示了沙盒（sandbox）的隔離性、本地與雲端之間的狀態同步（state sync）、以及跨會話的連續性（session continuity），才是決定一個雲端 Agent 系統成敗的關鍵。這不僅是技術選擇，更是架構思維的根本轉變。

過去一年，我們看到許多 AI Agent 的應用從本地端走向雲端，試圖解決本地運算資源不足、環境配置複雜等問題。以編碼助理聞名的 Cursor 推出的「Cloud Agent」（或稱 Background Agent），就是一個典型的例子。它允許開發者在本地的編輯器中下達一個複雜的任務（例如「實作一個新的 API 端點並撰寫測試」），然後將這個任務交給雲端虛擬機（VM）中運行的 Agent 自律執行。開發者甚至可以關掉電腦，等待任務完成後再回來檢視結果。這個願景固然美好，但從本地遷移到雲端的過程，卻踩了許多意想不到的坑。

為什麼本地 Agent 無法直接上雲？

一個普遍的誤解是，雲端化只是把本地執行的 Python script 放到遠端的 VM 裡跑。然而，一旦 Agent 開始與真實世界的檔案系統、網路、終端機互動，問題就變得非常棘手。根據 Cursor 創辦人 Josh Ma 的分享，他們很快就發現，一個穩定可靠的雲端 Agent 系統，其核心難點根本不在於模型本身，而在於如何處理執行環境、狀態同步與生命週期管理這三大基礎設施問題。

本地 Agent 享有許多「理所當然」的特權：它能直接存取你的檔案、看到你的環境變數、使用你已經登入的各種 CLI 工具。但在雲端，這些都必須被重新設計。你不能讓一個 Agent 在一個共享的雲端環境中隨意讀寫檔案或執行指令，這會帶來巨大的安全風險。當你在本地修改了一個檔案，雲端的 Agent 要如何即時知道？如果你的網路斷線了，那個正在執行長達數小時任務的 Agent 該何去何從？這些都不是單純的模型呼叫能解決的問題。

正如 Cursor 團隊所說：「我們很快意識到，把 Agent 搬到雲上並不是把模型遠端化，而是重新處理沙盒、狀態同步、會話連續性與執行隔離，這些才是可靠雲端 Agent 的真成本。」這句話點出了關鍵：雲端 Agent 的挑戰，本質上是經典的分散式系統工程問題。

如何設計可靠的沙盒與執行環境？

雲端 Agent 的首要之務，就是為每一次任務提供一個乾淨、隔離且安全的執行環境。Agent 需要安裝依賴、執行程式碼、讀寫檔案，這些操作都必須被嚴格限制在一個「沙盒」內，以防止惡意行為或意外操作破壞系統。這不僅是多租戶（multi-tenancy）架構下的基本要求，也是確保系統穩定性的關鍵。

Cursor 的選擇是使用輕量級虛擬化技術 Firecracker，這是由 AWS 開發用於 Lambda 和 Fargate 的技術。它能在極短時間內（Cursor 提到約 150 毫秒）啟動一個極簡的 microVM，提供強大的核心層級隔離，遠比傳統容器技術如 Docker 安全。每個 Agent 任務都在自己專屬的 microVM 中執行，任務結束後整個環境即刻銷毀，確保了環境的純淨與安全。另一個類似的選擇是 Google 的 gVisor，它在使用者空間實現了一個應用核心，同樣提供了比一般容器更強的隔離性。

選擇哪種沙盒技術，取捨點通常在於隔離性、啟動速度與資源開銷。對於需要執行不受信任程式碼的 Agent 來說，強隔離是不可妥協的底線。

狀態同步：雲端與本地的雙向難題

當執行環境被搬到雲端沙盒後，下一個挑戰就是如何讓這個遠端環境與開發者的本地工作區保持同步。這遠比單純的 git push 或 scp 複雜，它需要一個低延遲、雙向且能處理衝突的同步機制。需要同步的「狀態」至少包含以下幾個層面：

• 檔案系統：本地的程式碼變更需要即時反映到雲端，反之，Agent 在雲端生成或修改的檔案也需要同步回本地。
• 終端機 I/O：Agent 執行指令的輸出（stdout/stderr）需要即時串流回本地，讓開發者能監控進度。
• 環境變數與配置：雲端環境需要能存取本地的特定配置（例如 .env 檔案），同時又要避免敏感資訊外洩。
• Agent 的內部狀態：Agent 的思考過程、計畫步驟、記憶等，也需要被記錄並在必要時同步。

Cursor 為此開發了一套客製化的檔案同步系統，確保兩邊的狀態一致。這類系統的設計複雜度很高，需要處理網路不穩、檔案衝突、大量小檔案傳輸效率等問題。這也解釋了為什麼許多雲端開發環境（Cloud Development Environment）如 Gitpod 或 GitHub Codespaces 投入大量資源在檔案同步與網路協定優化上。

當連線中斷，Agent 如何存活？

雲端 Agent 的一大賣點，就是能執行需要長時間運行的「背景任務」。但這也帶來了「會話連續性」（Session Continuity）的挑戰。如果開發者的筆電關機或網路斷線，遠端的 Agent 必須能繼續執行，並在使用者重新連線後，無縫接軌地恢復互動介面與狀態顯示。

這意味著系統必須將「會話狀態」與「網路連線」解耦。Agent 的生命週期不應該依附於一個短暫的 WebSocket 或 HTTP 連線。這需要一個持久化的會話管理器，負責追蹤每個 Agent 的狀態、處理離線期間的事件，並在使用者重連時，將所有累積的更新推送給前端。Cursor 的作法是在 Agent 非活躍超過 10 分鐘後自動關閉 microVM 以節省成本，同時也確保了任務狀態被妥善保存。

從 Cursor 的經驗中，我們看到一個清晰的趨勢：打造一個真正有用的雲端 AI Agent，重點已從提示工程（prompt engineering）或模型微調，轉移到更底層、更經典的軟體工程與分散式系統設計上。沙盒的安全性、狀態同步的即時性、會話管理的可靠性，這些看似「無聊」的基礎設施，才是一個 Agent 系統能否從有趣的玩具（toy）變成可靠的工具（tool）的真正分野。

延伸閱讀

• What we've learned building cloud agents (Cursor 官方部落格)
• Cursorがクラウドエージェントを1年間運用して得た知見 (Zenn.dev 上的日文摘要)
• Firecracker MicroVMs 官方網站

我是江中喬，專注於 AI Agent Architecture、Memory Governance 與 Cognitive Diversity，持續研究如何打造能夠長期協作、可信任且可治理的 AI 系統。