8 月 3 日，Cloudflare 丟出一句話，直接跟整個 AI 基建圈唱反調：你的 agent 需要一台電腦，不是一個容器。理由不是容器慢，是不夠用。
一句話結論：Cloudflare computer 是一套開源 agent 執行環境，用 SQLite 撐起虛擬檔案系統，讓模型逐條指令自己選要用輕量 isolate 還是完整 Linux 容器，目標是把容器的使用率壓到一成以下。目前是預覽版，不能上正式環境。
這篇拆三件事：Cloudflare 到底開源了什麼、他們的賭注是什麼、以及哪些話目前還沒有證據。最後一段特別重要，因為這是一個預覽版專案，而網路上已經有人在寫得像它明天就能上線。
（資料截至 2026 年 8 月 6 日。GitHub 星數為當日實時值。）
Cloudflare 到底開源了什麼？
開源的是 @cloudflare/computer，一個 MIT 授權的 agent 執行環境（agent runtime）。8 月 3 日發布，到 8 月 6 日已經 2,860 顆星，光是當天就進帳 891 顆，衝上 GitHub 全語言日榜。
先講清楚兩個容易混淆的詞。Agent 框架管的是「怎麼想」，也就是推理迴圈；agent 執行環境管的是「在哪跑」，也就是程式碼實際落地的地方。這次的東西是後者。
它的核心叫 workspace，是一個由 SQLite 撐起來的虛擬檔案系統，住在 Durable Object 裡面。你可以從雲端儲存、原始碼倉庫、或任何檔案來填充它。agent 能讀寫改檔案、跑 shell 指令、操作 Git 倉庫，而且每一個動作都會被閘控、稽核、記錄。
真正的設計重點在後面：同一套檔案，兩個可以互換的執行後端。
- Isolate 後端：用
just-bash把 shell 指令翻譯成 JavaScript，在 Dynamic Worker 裡跑，檔案系統直接透過 worker 綁定拿到。快、便宜、可以橫向長。 - 容器後端：走 Cloudflare Containers 開一個完整 Linux 環境，檔案系統用 FUSE 掛載進去，改動再同步回來。需要原生執行檔、套件管理器、完整 userland 的時候用這個。
兩邊操作的是同一批檔案。所以在兩者之間切換不是「搬家」，是換一支手。
為什麼 Cloudflare 說容器是死路？
因為算力不夠。這是產能問題，不是效能問題，而且 Cloudflare 講得毫不客氣。
「橫跨所有雲、所有超大規模業者，全世界的算力遠遠不夠讓每一間公司給旗下每一個使用者的 agent 各配一個容器化運算環境。」
Cloudflare 部落格〈Your agent needs a computer, not a container〉，2026-08-03
接著他們補了一句更值得記住的話：這就是為什麼業界對 CPU 算力有近乎恐慌的需求，不只是 GPU。
這個角度我覺得是整篇公告最有價值的地方。過去一年講 AI 算力荒，鏡頭幾乎全對著 GPU。Cloudflare 在說，真正會先撞牆的是 CPU 那一側——因為每多一個 agent，你就要多開一個環境，而那個環境不需要顯卡，需要的是一顆一直醒著的 CPU 跟一塊硬碟。
順帶一提，這個立場對 Cloudflare 來說不是新的。他們 2017 年推 Workers、2020 年推 Durable Objects，容器要到 2025 年 6 月才進公測。押 isolate 這件事，他們已經押了快十年。
那個「一成以下」的數字是什麼意思？
Cloudflare 給自己設的目標是：讓容器只在 agent 不到 10% 的工作裡被用到。他們列出來認為 isolate 就能處理的事情包括寫程式、音訊與影片處理、文件生成。
這個數字是整個賭注壓縮成的一個指標，也是唯一可以被證偽的部分。差別很實際：
- 如果真實工作量裡容器只需要不到一成，那每個 agent 的成本曲線會被整條壓下來。
- 如果實際是四成，那這套東西就只是一層包裝，你還是在付重量級隔離的錢。
注意時態。這是目標，不是量測結果。Cloudflare 沒有公布目前的實際數字。
跟 E2B、Modal、Vercel 比，差在哪？
差在隔離的基本單位，以及誰在什麼時候做選擇。這個市場沒有等 Cloudflare，其他人早就在跑了。
| 方案 | 隔離基本單位 | 狀態 |
|---|---|---|
| Cloudflare computer | V8 isolate 與 容器，共用檔案系統 | 預覽版、開源，2026-08-03 發布 |
| Cloudflare Sandboxes | 容器 | 2026 年 4 月首次 Agents Week 期間 GA |
| Vercel Sandbox | Firecracker 微型虛擬機 | 2026-01-30 GA，v0、Blackbox AI、RooCode 在用 |
| E2B | Firecracker 微型虛擬機 | 成熟供應商 |
| Modal | gVisor | 綜合 AI 基建平台 |
方向很清楚：其他人都往更強的核心級隔離走，因為模型生成的程式碼本質上是不可信輸入，共用核心的容器是個弱邊界。
Cloudflare 主張的是另一件事：大多數 agent 指令其實只是改檔案、處理資料、跑 git，從頭到尾不需要一個屬於自己的核心。所以強隔離應該是例外，不是預設。
還有一個常被誇大的點要講白。「可插拔的執行後端」本身不新鮮，agent 框架早就有。真正的新意窄很多，但確實存在：在多數設計裡是開發者在設定階段挑後端，這裡是模型在執行階段、逐條指令挑，而且兩個後端背後是同一份持續同步的檔案。工具描述被寫成會引導模型做這個選擇。
這對不寫程式的人有什麼影響？
短期沒有直接影響，你不會因為這個更新而少付訂閱費。但有兩件事值得記著。
第一，你用的 AI 產品要漲價還是降價，很大程度取決於這一層的成本結構。現在市面上很多 agent 型服務之所以貴、之所以有用量上限，就是因為背後真的在幫你開一個完整環境。這層成本如果被砍掉，前台的定價遲早會反映。
第二，安全性是有取捨的，不要只看省錢。V8 isolate 是語言層的邊界，不是硬體層。Firecracker 和 gVisor 之所以存在，就是因為業界刻意往硬體級隔離走。isolate 優先的預設能省錢，但爆炸半徑收得沒有微型虛擬機那麼緊。
你的 agent 到底需不需要容器？
Cloudflare 這篇公告最有用的部分，其實不是產品，是它逼你回答的問題：你的 agent 實際的指令組合裡，有多少比例真的需要完整 Linux？多數團隊從來沒量過。他們挑了一家沙箱供應商，給每個 agent 配一整套環境，然後把帳單吞下去。
30 秒自測：勾選你的 agent 平常真的會做的事
僅為粗略分流，不構成架構建議。實際請以自己的工作負載量測為準。
哪些話目前還沒有證據？
這段是我認為最該讀的一段，因為它決定你現在要不要動。
- 「一成以下」是目標，不是實測。沒有公開的實際容器使用率數字。
- 「前沿模型很會自己選後端」是 Cloudflare 自己的測試說法。沒有附上可驗證的 benchmark，也沒有第三方評測。
- 整個東西是早期預覽。倉庫 README 寫得很直白：僅供回饋用途，API 不穩定，設計可能改，適合實驗與原型，目前不適合正式環境。而且
docs/底下的規格是前瞻性的，描述的是意圖而不是現在的程式碼。 - 「給你的 agent 一台電腦」這句話不是這次才有的。Cloudflare 自己 4 月宣布 Sandboxes GA 的文章標題就是這個意思，Vercel 1 月 Sandbox GA 時也用了幾乎一樣的說法。
所以我的判斷是：這是一個論證漂亮的賭注，不是一個已經成立的結論。接下來一季值得盯兩個數字——真實工作負載上的容器使用率，以及任何一份獨立的、關於模型選後端準不準的評測。這兩個沒出來之前，它就還是一個賭注。
現在想試，要怎麼開始？
前提：你要用得上 Cloudflare Workers 跟 Durable Objects。不是這個生態的人，這次可以先跳過。
- 安裝套件：
npm install @cloudflare/computer - 在 Durable Object 裡開一個 workspace，把
this.ctx.storage傳進去當儲存，agent 就同時拿到檔案系統跟執行環境。 - 選後端：
workspace.runtime.exec(source, { backend })是唯一的執行入口。選哪個後端，決定了source是一條 shell 指令還是一個 ES module。後端第一次被用到時才會連線。 - 接工具：官方提供相容 AI SDK 的工具組，含
read、write、edit、ls、exec。 - 照著範例跑一次：倉庫
examples/裡有可直接執行的例子，包括容器版、worker shell 版、以及一個把同一個任務同時丟給容器與 worker 跑、並排比較的網頁介面。想快速有感就從並排比較那個開始。
官方文件裡的示範跑在 @cf/zai-org/glm-5.2（Workers AI 上的 Z.ai agentic coding 模型），搭配 @cloudflare/think。
如果不想綁 Cloudflare，有什麼替代方案？
有，而且成熟度都比這個高。
- E2B：Firecracker 微型虛擬機，專做 AI 程式碼執行沙箱，生態最完整。
- Vercel Sandbox：一樣 Firecracker，2026 年 1 月已 GA，適合本來就在 Vercel 上的人。
- Modal：gVisor 隔離，本身是更廣的 AI 基建平台，不只沙箱。
- Cloudflare Sandboxes：如果你要的是 Cloudflare 生態但要穩定，這個 4 月就 GA 了，走純容器路線，不是預覽版。
簡單分流：要穩就選已 GA 的；要安全邊界硬一點就選微型虛擬機那派；想省錢而且工作負載真的很輕，才輪到這次的預覽版。
常見問題
Cloudflare computer 可以用在正式環境嗎？
不行。官方 README 明確標示為 PREVIEW ONLY，只適合實驗、探索與原型，API 不穩定且設計可能變動。
它會取代 Cloudflare Sandboxes 嗎？
目前不是取代關係。Sandboxes 是 2026 年 4 月已經 GA 的純容器方案；computer 是預覽階段的新抽象層，把 isolate 跟容器包在同一套檔案系統底下。要穩定就用前者。
Isolate 的安全性等同微型虛擬機嗎？
不等同。V8 isolate 是語言層邊界，Firecracker 與 gVisor 提供的是更接近硬體與核心層的邊界。跑不受信任的模型生成程式碼時，這個差異要納入評估。
「容器只佔一成」這個數字可信嗎？
那是 Cloudflare 設定的目標，不是量測結果，官方沒有公布目前的實際比例。要驗證得看之後有沒有真實工作負載上的容器使用率數據。
Agent 執行環境跟 agent 框架差在哪？
執行環境負責程式碼實際在哪裡跑、怎麼隔離、狀態怎麼保存；框架負責推理迴圈怎麼走。執行環境在框架底下那一層。
結論
Cloudflare 這次的標題是挑釁，但底下的論證是一個產能主張：世界上沒有足夠算力讓十億個同時運作的 agent 各拿一個容器，所以預設值一定要有東西讓步。
他們的答案是讓容器變成例外，並且把「什麼時候需要容器」這個判斷交給模型。這是一個真實的架構立場，而且跟 E2B、Modal、Vercel 的方向正面相反。
缺的是證據。所以現在該做的不是搬家，是先量一件事：你的 agent 上一週跑過的指令裡，有多少真的需要一個完整的 Linux？答案如果遠低於一半，你確實在用微型虛擬機的價錢跑 cat 跟 grep。這個問題不需要等 Cloudflare 給你答案。
本文為技術與產業資訊整理，不構成任何投資建議或架構採用建議。文中數據截至 2026 年 8 月 6 日，開源專案狀態變動快速，實際請以官方倉庫與文件為準。
發表迴響