為什麼 Docker 的 microVM 沙盒才是 AI 代理的正解

Docker 的 microVM 沙盒才適合自主 AI 代理，因為容器對 root 級執行權限來說邊界太弱。

Docker 把自主 AI 代理移進 microVM 沙盒，是正確方向，因為這類工具不再只是讀程式碼或產生 diff，而是能以 root 執行指令、安裝套件、改檔案、再啟動更多程序。當你把這麼多權限交給代理，容器那層「夠用了」的安全感就不成立了。

現在的 coding agents 已經會做出超出傳統開發工具範圍的事。像 Claude Code、Codex 這類工具可以跑腳本、拉依賴、碰本機檔案系統，甚至再開容器。容器共享宿主機 kernel，microVM 不共享。對會主動擴張行為面的軟體來說，這不是細節差異，而是單一沙盒內出事，還是整台機器一起承擔風險的差別。

第一個論點：容器從來不是正確的信任邊界

容器的設計目標是打包與部署，不是關住半受信任、甚至不受信任的自主行為。Namespaces 和 cgroups 能隔離行程，但它們沒有給你一個獨立 kernel。只要代理能碰到 kernel 漏洞，宿主機就一起暴露。這對一般 app 工作負載也許可接受，對能隨時執行任意命令的代理就不行。

實務上，團隊早就把代理接到本機 repo、套件管理器和 shell 指令上，因為這才有生產力。可是一旦這樣做，代理就不再是輔助工具，而是高權限操作員。microVM 為每個沙盒提供自己的 kernel 實例，這才是這類工作負載的最低合理邊界。Docker 不是過度設計，而是在補上威脅模型。

第二個論點：跨平台支援決定產品是否真能落地

這次發佈真正重要的地方，不只是用了 microVM，而是 Docker 選擇自建 VMM，而不是直接綁定 Firecracker，讓功能能在 macOS、Windows 與 Linux 上都可用。這不是實作細節，而是決定它會變成小眾基礎設施技巧，還是開發者真的能在日常筆電上使用的工具。

Firecracker 很適合伺服器端隔離，但它明顯偏 Linux。現實是，多數開發者不是整天待在 Linux-only 環境，他們在 MacBook 和 Windows 上工作，並希望本機沙盒有一致行為。Docker 自建 VMM 等於明確下注：可攜性比純粹性更重要。對開發工具而言，這是對的選擇。若安全邊界只在資料中心有效，卻無法覆蓋代理真正開始執行的桌面端，那就不算完整。

反方可能怎麼說

最強的反對意見是，microVM 會帶來額外成本、複雜度和操作摩擦。容器啟動快、資源占用少，也和既有工具鏈自然相容。若一個團隊要跑大量短生命週期沙盒，microVM 可能拖慢迭代、增加記憶體壓力，還讓除錯變麻煩。這個批評是合理的；如果工作負載風險低、邊界清楚，容器確實更便宜。

另一個合理擔憂是，隔離更強不代表真的更安全。若團隊隨便注入憑證、放寬網路存取、把沙盒當成可以亂跑的免責區，邊界本身並不能解決根本問題。安全仍然取決於政策、秘密管理與最小權限。microVM 不會自動修好治理失敗。

但這些理由不足以推翻 Docker 的方向。自主 AI 代理的沙盒重點不是追求最低成本執行，而是約束一個能做決策、能執行程式、還會擴大自身行為面的系統。這正是值得多付一些成本的工作負載。是的，團隊仍要做好憑證與網路控制；但那是要求更好的設定，不是接受更弱的隔離。

你能做什麼

如果你是工程師，別再把代理執行當成一般 dev script，應該把它視為不受信任工作負載管理。把自主代理放進更強的邊界，透過宣告式設定定義它能用的工具與憑證，並嚴格審核它能碰到的網路範圍。如果你是 PM 或創辦人，從第一天就把可重現性與可撤銷性設計進產品。最後贏的，不會是讓代理做最多事的平台，而是讓團隊最能信任代理行為的平台。