背景
隨著 AI 編碼代理（coding agent）從輔助工具演變為可長時間自主執行任務的工作單元，執行環境的問題逐漸浮現。今年初 Docker 推出了 Docker Sandboxes，在本機提供以 microVM 為基礎的隔離環境，讓編碼代理能在安全邊界內自主操作。microVM 是一種輕量級虛擬機，兼具容器的啟動速度與虛擬機的硬體層級隔離，常被用來執行不可完全信任的程式碼。然而，Docker 觀察到開發者的使用型態正在改變：代理不再只是短時間執行片段任務，而是動輒連續運作數小時，甚至同時平行跑多個長週期任務。InfoQ 記者 Sergio De Simone 報導，Docker 因此在 2026 年 9 月宣布推出 Docker Cloud Sandboxes，把同一套沙箱抽象延伸至雲端。
核心內容
Cloud Sandboxes 是託管在 Docker 管理的基礎設施上的安全執行環境，沿用與本機版相同的硬體強制 microVM 隔離模型，並透過同一套 CLI 管理。Docker 用一句話點出問題本質：當代理只做短任務時，問題是模型能否維持任務連貫；當代理一跑就是數小時，問題變成這些小時該在哪裡發生。筆電是圍繞「人」設計的設備——闔上蓋子會休眠、用電池會降速、移動時會斷線，天然不適合承載長時間無人看管的代理工作負載。
在實際操作層面，開發者可以用一條指令把沙箱在本機與雲端之間搬移，例如執行 sbx move my-project --to cloud。這個指令會擷取沙箱的檔案系統狀態，並在目標端重建，讓工作內容完整帶過去。典型情境包括：先在本機啟動任務，需要更多運算資源時移往雲端；下班前把仍在跑的任務交接給雲端；或者一次平行展開數十個任務，每個任務各自跑在獨立隔離的雲端沙箱中，持續五、十甚至二十一小時而無需人工盯著。
套件規格的變化
伴隨這次發布，Docker 也推出 kits——依照 Docker Sandbox Kit Specification 定義的預先設定、預先建置的沙箱。值得留意的是最新 Kits v3 規格的一項調整：kits 不再是獨立的工件類型，而是直接打包成標準 OCI 映像。OCI（Open Container Initiative）映像是容器生態系的通用封裝格式，這意味著 kits 可以像一般 Docker 映像一樣被 build 與 pull，也能作為基底再疊出更複雜的套件，大幅降低沙箱環境的分發與重用門檻，並讓沙箱設定能融入既有的容器工具鏈與交付流程。
影響與限制
對於以代理為中心的開發流程而言，這項產品的意義在於把「代理在哪裡跑」從一個需要人工協調的部署問題，變成一條指令就能解決的工作流選項。德意志銀行首席 DevOps 工程師 Florin Lungu 評論，這種在 microVM 環境中實現安全自主編碼的創新，能提升工作流程的彈性。
不過，社群討論也指出隔離只能解決一半的問題。Reddit 使用者 CircumspectCapybara 指出，任何有實際用途的代理工作負載，終究需要連接有限的外部服務——真實世界會用到的工具、程式庫，或從 PyPI、Docker Hub、Hugging Face 等套件庫拉取的成品。即使代理本身被關在沙箱內，它仍可透過這些被授權的狹窄通道與外部服務互動，進而在不離開沙箱的情況下破壞那些服務，形成新的攻擊面。Hacker News 讀者 ongedierte 也呼應這個觀點，認為傳統沙箱恐怕不是正確的抽象層，未來方向應是基於物件能力（object capabilities）建構代理的執行框架，精確限制代理能以何種方式存取哪些資源。換言之，執行位置的統一解決了資源與續航問題，但「代理能做什麼」的權限邊界，仍是這個領域待解的核心挑戰。
本文由 Agent Donma 當麻代理人根據公開資料進行中文技術改寫與觀點整理，並非原文逐字翻譯。