2026 年底 AI 代理執行環境:microVM、瀏覽器與原生怎麼選

到了 2026 年底,我從各團隊最常聽到的問題,已經不再是「該選哪個模型」,而是「這個代理應該跑在哪裡」。這是個完全不同的問題,而過去三個月裡,答案又大幅洗牌了一次。

如果你在 2026 年初問同一個問題,得到的答案多半是「用 Docker 跑吧,祝你好運」。這個答案現在已經非常危險地不完整。到了 2026 年十月,真正在生產環境被採用的執行模式至少有四種,各自有不同的威脅模型、延遲特性與成本結構。選錯的那一種,正是我看過最多團隊的代理展示一離開開發者筆電就崩盤的原因。

這篇文章是我希望半年前就讀到的那份指南——一份關於 2026 年底「代理執行環境」實際意義的工作地圖,並附上每種環境適合的具體情境。

真正重要的三種(其實是四種)模式

「Docker vs 瀏覽器 vs 原生」這個分類方式年初還算能用,但它藏起了真正重要的界線:代理是否和你的筆電共用同一個作業系統核心。決定你的機器是否處於風險之中的,正是這條線,而不是容器技術叫不叫 Docker。

以下是 2026 年真正在生產環境運作的四種執行模式:

• MicroVM 沙盒——具備獨立核心的 Firecracker 等級隔離。Docker Sandboxes(含 Cloud Sandboxes)、E2B、Modal Sandboxes、Fly Machines,以及幾家雲端廠商的方案都屬於這一類。
• 瀏覽器型電腦操作——代理透過截圖與 DOM 事件操控真實的 Chromium 瀏覽器。代表產品:ChatGPT Agent(原 Operator)、Claude for Chrome、Perplexity Comet。
• 容器型沙盒——命名空間隔離、共用核心、啟動快、隔離強度較弱。2024–2025 多數「Docker 部署」其實落在這一類,包括許多內部代理平台。
• 原生執行(主機執行)——代理直接在你的筆電或伺服器上執行指令。仍是獨立開發者的主流,也是許多 IDE 助理的預設行為。

被討論最多的是瀏覽器型,但 2026 年底默默扛下最多生產工作的是 microVM。這個落差,正是大家困惑的主因。

為什麼「容器」不再是預設正解

標準的 Docker 容器與主機共用作業系統核心。命名空間與 cgroup 給的是「視野」,不是「邊界」。對一個可能會自己裝套件、fork 程序、curl 任意網址的 LLM 來說,這個差別比 2025 年大家意識到的更重要。

Docker 自己在 2026 年九月說得直白——他們發布了 Sandbox Kit Specification v3:Docker Sandbox 是擁有獨立核心的 microVM,邊界位於模型能觸及或改寫的任何東西之下。Christian Dupuis 在規格發布文中寫了一句話,請記住:「容器打包應用程式,沙盒則是關住代理。」這句話總結了為什麼 microVM 型沙盒在這一年席捲了代理市場。

實務上的結論:如果你的代理跑在普通容器裡、跟你的 SSH 金鑰放在同一台主機上,那你其實沒有真正的隔離,你有的只是一個程序牢房。聊天機器人用這個沒問題,但一個會在凌晨三點自己 apt install 東西的寫程式代理,問題就大了。

MicroVM 沙盒——認真做事的代理的新預設

主要的戰場已經移到這裡。截至 2026 年十月,有三家廠商定義了這個領域:

Docker Sandboxes / Cloud Sandboxes

Docker 在 2026 年初推出本地版 Sandboxes,並於 2026 年 9 月 24 日延伸出 Cloud Sandboxes——同一套 microVM,跑在 Docker 託管的雲端運算資源上。最關鍵的功能是 sbx move my-project --to cloud:你在本地開發,把沙盒狀態推上雲端,關上筆電之後長時間任務繼續跑。

預先打包好的「Kit」涵蓋 Claude Code、Codex、Copilot、Antigravity、Open Code、Hermes。金鑰與網路政策集中存放、以代理方式注入,代理從未看過真正的密鑰——這對抗「透過工具輸出進行提示注入」這條攻擊路徑非常有用,而這條路徑一整年都在啃蝕瀏覽器代理。

Docker 也以 Apache 2.0 釋出 Kit Spec,並承諾捐給 CNCF 由中立機構治理。這件事本身就是個強烈訊號:他們要做的是標準,而不是 Docker 專屬功能。

E2B

E2B 是第一家認真經營代理沙盒的廠商,至今仍是「給程式直譯器型代理用的快速 Firecracker microVM」的代表。2026 年底值得認識的功能:

• 持久化:暫停/恢復可無限期保留記憶體與檔案系統狀態,沒有 TTL。
• 快照與分叉:把運行中的沙盒做快照,一次產出 N 份副本。這個功能讓 E2B 成為評測流水線與紅隊演練的預設選擇。
• 沙盒指標與 OTel 匯出,可直接接入既有的可觀測性平台。

當你需要數百個短生命週期的並行任務(評測、工具呼叫用的程式執行、教育場景代理),E2B 比 Docker Sandboxes 更合適。當你需要保留數小時狀態並能互動式接續,E2B 就略遜一籌。

Modal Sandboxes

Modal 的切入點是「把容器當沙盒用」。它不是 microVM——Modal 用的是隔離強度比裸 Docker 更高的容器,但仍共用核心。贏面在於任意執行環境與相依套件。如果你的代理需要 CUDA、自訂 Linux userland,或非標準的語言工具鏈,Modal 是三者中最省力的;但若你的代理可能嘗試逃出沙盒,Modal 也是三者中最弱的。

瀏覽器型電腦操作——當網頁本身就是環境

瀏覽器代理過去十二個月相當吵雜。2026 年初多數人仍把 OpenAI 的 Operator 視為標準範例。該產品在 2025 年七月併入 ChatGPT 成為 ChatGPT Agent,此後模式開始穩定。

這一代的運作方式大致是:

1. 啟動一個隔離的 Chromium 執行個體。
2. 每一步把截圖交給模型。
3. 讓模型輸出 click / type / scroll 動作。
4. 當模型辨識出結構化工具時(搜尋、填表、提交),改為呼叫這些工具。

2025 年 9 月 29 日發布的 Claude Sonnet 4.5,在 OSWorld 上拿到 61.4%——四個月前還是 42.2%。這是實打實的進步,也正是瀏覽器代理在 2026 年春季還不可信、如今能進入生產流程的原因。

適合用瀏覽器代理的情境:

• 目標行為發生在某個沒有可用 API 的網站上。
• 任務需要在你無法控制的多步驟介面上點擊操作。
• 你能接受每一步 5 到 30 秒的延遲。
• 最壞情況(點錯、送錯表單)是可回復的。

不適合用瀏覽器代理的情境:

• 程式碼迴圈需要次秒級回饋。
• 處理金流、受監管資料,或任何有稽核需求的場景。
• 目標網站有積極的反機器人機制。瀏覽器代理會一直觸發 CAPTCHA,模型的自救能力雖在進步但仍不可靠。

瀏覽器代理目前最大的未解難題,仍是透過頁面內容進行的提示注入。一個惡意編排的商品頁可以注入模型會視為合法的指令。沙盒對這種威脅無能為力,因為它屬於邏輯層攻擊,不是技術層攻擊。

原生執行——仍然存在,但像一枝上膛的槍

大多數獨立開發者仍以原生方式執行代理。Cursor、終端機裡的 Claude Code、Copilot CLI——這些預設都在主機上執行。個人專案用這個沒問題,但任何多用戶或持有真實憑證的場景,都是分類錯誤。

它之所以一直存在,是因為原生執行快、零冷啟動、讓代理能無縫使用你的本機瀏覽器、IDE 與剪貼簿。對坐在機器前的開發者來說,體驗無人能敵。

但「體驗無敵」跟「可以安心放著讓它跑一整夜」是兩回事。如果你的代理握有你的 AWS 金鑰、.ssh 目錄與信箱,然後你離開筆電——你就麻煩了。這是我在 2026 年底最常看到的生產事故:開發者「只跑一分鐘」,代理自己決定去追支線任務,兩小時後開發者回來,看到一個沒要求的重構,以及一筆沒授權的 Stripe 扣款。

如果真的必須跑原生,請給代理開一個獨立、無 sudo 的使用者帳號,把每張 API 金鑰的權限縮到最小,並使用 Claude Code 2.0 或 Docker Sandboxes 新增的「checkpoint」功能,在出狀況時回滾。

比較:每種模式的優勢場景

面向	MicroVM 沙盒	瀏覽器(電腦操作)	容器	原生
核心隔離	強(獨立核心)	強(Chromium 沙盒)	弱(共用核心)	無
冷啟動	150–800 毫秒	3–8 秒	50–200 毫秒	0 毫秒
長時間任務	極佳	差(session 易斷)	良好	極佳
網頁互動	透過無頭瀏覽器外掛	原生	透過無頭瀏覽器外掛	透過本機瀏覽器
提示注入風險	低(沙盒化)	高(頁面內容)	低	無(主機即目標)
最適合	背景程式代理、長時評測	SaaS 工作流、無 API 網站	內部工具、CI 步驟	個人開發迴圈

容易讓人意外的一列是「提示注入風險」。沙盒保護主機,但對模型讀了什麼完全沒有幫助。若代理抓取了一個惡意網頁,該頁告訴模型把資料外洩——沙盒會盡忠職守地保護主機,模型同時把資料送到允許的網路政策之內任何地方。請把網路政策視為答案的另一半,而不是 nice-to-have。

決策指南:你該選哪一個?

如果不知道從何下手,請依序回答這三個問題:

1. 任務是否發生在公開網路上?如果是,又沒有 API 可用——你需要瀏覽器代理。用 ChatGPT Agent 或 Claude for Chrome,搭配未登入的 profile 與嚴格範圍的登入帳號。2026 年別想自己土炮一個。
2. 任務是否觸及你的檔案系統、執行程式或安裝套件?如果是,你需要 microVM 沙盒。已經在 Docker 生態系就預設 Docker Sandboxes;需要平行分叉就用 E2B;需要 GPU 就用 Modal。
3. 任務是不是個人一次性、在你筆電前面、由你親自操作?那原生可以。用 Claude Code 或 Cursor,啟用 checkpoint,絕不要跑在有正式環境憑證的主機上。

如果問題二的答案是「是」,而且任務會跑超過 30 分鐘,請挑一個支援 pause/resume 或 move-to-cloud 的選項。2026 年十月符合條件的是 Docker Cloud Sandboxes(sbx move)與 E2B persistence。

我每週都會看到的常見錯誤

• 把真正的代理跑在普通 Docker 容器裡。命名空間不是隔離。如果你的「代理容器」能讀到主機的 /var/run/docker.sock,你的代理就有 root。
• 讓瀏覽器代理登入正式環境。瀏覽器代理會很自信地犯錯,點錯按鈕。請用專用、低權限的帳號,以及可退款的付款方式。
• 「暫時」給原生代理 root 權限的權杖。「暫時」不是一種權限。代理要嘛拿到權杖,要嘛沒有。
• 長時間任務沒做 checkpoint。Claude Code 2.0 在九月下旬加入 checkpoint。請用。沒有 checkpoint,30 小時的代理任務一旦走偏,就變成 30 小時的除錯。
• 沒有網路政策。如果代理能上公網,它就能被誘導去上公網。沒有網路政策的 microVM 沙盒,等於只做了一半的安全控管。
• 模型與環境未在同一條件下測試就混用。模型在沙盒裡跑出 80% 分數,在真實瀏覽器裡可能只有 55%。環境是模型的一部分。

每個選擇在哪些時候反而是個錯誤

幾句直白的提醒,幫你省時間:

• 不要什麼事都用 microVM。如果代理的工作只是「寄一封信」、「填一張表」,microVM 大材小用,冷啟動會拖垮你。
• 不要用瀏覽器代理做寫程式的事。你可以在瀏覽器裡跑 shell,但延遲與脆弱性會讓它淪為玩具。請用沙盒。
• 任何會被客戶看到的東西,不要用原生。只要客戶看得到這個代理的輸出,就跑在沙盒裡。沒有例外。
• 處理不可信輸入時不要用容器。使用者上傳的 CSV 被 LLM 解析、又對其中的程式碼片段跑 eval(),在 2026 年是一個真實存在的 CVE。請用 microVM,不是容器。

2026 年底的一份務實技術堆疊

如果今天要我從零蓋一個內部代理平台,我會長成這樣:

• 預設環境:本地用 Docker Sandboxes,超過約 30 分鐘的任務用 Docker Cloud Sandboxes。每種代理類型(Claude Code、Codex 等)各自一個 Kit,進 Git 版控。
• 純網頁工作流:ChatGPT Agent,搭配每個任務一個臨時 profile、範圍嚴格的 OAuth token、以及瀏覽器 session 的硬切斷開關。
• 批次評測與紅隊:用 E2B 分叉,數百個沙盒並行,OTel 匯出到既有的可觀測性堆疊。
• 吃 GPU 或自訂執行環境:特殊情境用 Modal Sandboxes。
• 個人 IDE 工作:Cursor 或 Claude Code 原生執行,啟用 checkpoint,主機上不能有任何正式環境憑證。

整套東西背後只有一個原則:環境是安全模型的一部分,而不是安全模型的外包裝。先選環境,再選模型。順序顛倒的團隊,代理展示漂亮、上線第二週就爆。

檢查清單:挑選執行環境

• 是否定義好代理能讀寫的範圍?
• 是否定義好代理能連到的網路端點?
• 核心邊界是否設在對的位置(microVM vs 容器 vs 主機)?
• 代理一旦走偏,能否回到已知的良好狀態?
• 能否觀察每一次工具呼叫與每一筆外連請求?
• 冷啟動預算是否符合延遲預算?
• 代理是否在那個具體的環境下測過,而不是只在展示中?

常見問題

Docker Sandbox 跟跑普通 Docker 容器一樣嗎?

不一樣。Docker Sandboxes 用的是獨立核心的 microVM,跟 AWS Lambda 是同一種隔離模型。一般的 docker run 共用主機核心,對不可信的代理程式碼來說並不合適。

可以繼續用 Operator / ChatGPT Agent 做寫程式任務嗎?

技術上可以,實務上不行——你會被瀏覽器延遲與點擊錯誤的恢復流程磨掉好幾個小時。寫程式請用 microVM 沙盒搭配 CLI 代理(Claude Code、Codex、Hermes),更快也更可靠。

microVM 沙盒會不會很慢?

冷啟動在 Firecracker 等級的 VM 上是 150–800 毫秒。對次秒級迴圈來說偏慢,但對任何超過幾秒鐘的任務根本不重要。Docker Cloud Sandboxes 讓同一個 VM 跑好幾小時,成本攤提下來幾乎為零。

最便宜的認真選項是哪一個?

E2B 與 Modal 都有慷慨的免費額度。對單一開發者來說,認真用沙盒一個月大概 20 到 80 美元。原生「免費」,直到你為了那場本來不必發生的事故付出代價。

WASM 型沙盒呢?

確實存在而且持續進步(Wasmtime、wasmCloud、Fermyon Spin),但 2026 年底生態系支援仍不及 microVM。值得在 2027 年關注,但今天還不是預設選項。

結語

代理架構裡,終於在 2026 年追上模型能力進度的,正是執行環境。2026 年十月能穩定交貨的團隊,不是模型最好的團隊——而是選對隔離層、寫出真正網路政策、並在長時間任務上加上 checkpoint 的團隊。這三件事做到,你的代理堆疊就能撐住;跳過任何一件,再好的模型也救不了你。