Cloudflare 的 AI 沙箱跑超快

Cloudflare 最近丟出一個很狠的數字。AI 產生的程式，幾毫秒就能啟動。記憶體只吃幾 MB。跟容器常見的幾百毫秒、幾百 MB 相比，差很多。

講白了，這不是小優化。這會直接影響 agent 體驗。啟動快，使用者就覺得順。啟動慢，整個流程就像卡在半路。

這次主角是 Dynamic Worker Loader。它是 Cloudflare Workers 的 open beta 功能。它讓應用在執行時建立新 Worker，塞進 AI 生成的 JavaScript，然後把它關在 isolate 裡。

Cloudflare 想解的，不只是速度

Cloudflare 這篇文章，其實是在延續去年 9 月的 Code Mode。它的想法很直接。agent 不一定要一直做 tool call。很多時候，直接寫一小段程式更有效率。

為什麼？因為程式可以批次處理。可以在本地過濾資料。也可以少吃 Token。Cloudflare 提到一個例子，把 MCP server 轉成 TypeScript API，Token 用量少了 81%。另一個案例，只用 2 個工具，就把 Cloudflare API 暴露出來，而且不到 1,000 tokens。

這種設計很像在說：別再把 agent 當成按鈕機器。讓它寫 code，反而更像真的開發流程。對 LLM 來說，JavaScript 也很友善。對 Web 來說，JavaScript 更是原生語言。

• Code Mode 節省了 81% Token 用量。
• Cloudflare API 只用 2 個工具。
• 整個介面不到 1,000 tokens。
• Dynamic Worker Loader 現在是 open beta。

我覺得這裡的重點，不是「AI 會寫 code」這件事。那大家早就知道了。重點是，Cloudflare 把這件事變成一個可部署的 runtime。不是 demo。不是概念圖。是能放進產品流程的基礎設施。

Isolate 為什麼比容器快

核心技術是 isolate。它是 V8 的執行環境。沒錯，就是 Google Chrome 用的那套 JavaScript 引擎。Cloudflare 說，isolate 啟動只要幾毫秒，記憶體只要幾 MB。

這跟容器很不一樣。容器不是不能用。只是它比較重。你要啟動映像檔，要分配資源，要處理更多系統層開銷。短任務一多，這些成本就會冒出來。

Cloudflare 的說法很直接。大概是 100x 更快，記憶體效率也高出 10x 到 100x。這種差距，對 agent 服務很要命。因為 agent 常常是短任務、高頻率、低延遲需求。

“An isolate takes a few milliseconds to start and uses a few megabytes of memory. That’s around 100x faster and 10x-100x more memory efficient than a typical container.” — Cloudflare blog post, “Sandboxing AI agents, 100x faster”

這句話很有份量。因為它直接點出一件事。容器不是萬能解。尤其是 AI agent 這種常常跑一下就結束的工作，容器的暖機成本很容易變成浪費。

Cloudflare 也提到，Dynamic Workers 可以在全球數百個據點跑。甚至可能跟建立它的 Worker 在同一台機器、同一條 thread 上執行。這對延遲很有幫助。對帳單也有幫助。

TypeScript 比 OpenAPI 更像 agent 的語言

Cloudflare 另一個很明確的立場，是偏愛 TypeScript。它拿 TypeScript 跟 OpenAPI 做對比。理由很簡單。agent 要寫 code，不是只會填表單。

如果你要讓 agent 操作聊天室 API，TypeScript 只要幾行介面就夠了。history、subscribe、post message，這些功能可以很緊湊地描述。OpenAPI 也能做，但檔案會拉很長。paths、schemas、request body、response、streaming，全都要寫。

對人來說，OpenAPI 很正式。對 LLM 來說，OpenAPI 常常太肥。每多一層格式，Token 就多一點。每多一點上下文，模型就多一點出錯機會。

• TypeScript 介面很短，LLM 也比較好生成。
• OpenAPI 能力完整，但描述成本高。
• Cloudflare 用 MCP 處理平面工具。
• 更複雜的 API，改走 TypeScript。

這裡還有一個很實際的好處。你可以只暴露你想讓 agent 用的能力。不是整包 HTTP endpoint 全開。對安全性來說，這比較乾淨。對維護來說，也比較不會失控。

Cloudflare 的做法，其實是在把「工具」升級成「程式介面」。這差很多。工具是按鈕。程式介面是語言。agent 真的要做事，語言通常比按鈕好用。

HTTP、權限、秘密資料怎麼管

Dynamic Worker Loader 不只支援 RPC。它也支援 HTTP。做法是用 globalOutbound hook。這個 hook 可以檢查、改寫、阻擋，甚至直接回應外送請求。

這點很重要。因為實務上的 agent，幾乎都要碰外部服務。你可能要打資料庫 API。可能要連 SaaS。也可能要查內部系統。但你不想把 secret 直接丟給模型。

Cloudflare 的思路是，把秘密留在 host。讓生成的 code 看不到完整憑證。需要 auth 的時候，由 host 在 outbound 階段補上。這樣 agent 有能力做事，但沒辦法亂拿鑰匙。

• Cloudflare Workers bindings 可提供受控能力。
• fetch 攔截 可在送出前處理請求。
• Secret 可以留在 host，不必暴露給 agent。
• TypeScript wrapper 也比較容易做權限收斂。

講白了，這就是在做最小權限原則。不是把整個網路世界都開給 LLM。是只給它剛好能完成任務的能力。這種設計，對企業環境特別重要。

我覺得這部分比速度還值錢。因為很多 agent 專案死掉，不是因為模型不夠聰明。是因為權限亂掉。資料外洩一次，大家就會開始縮手。

跟容器、MCP、其他平台比起來呢

如果拿 Cloudflare 的方案跟容器比，差異很清楚。容器適合完整環境。你要 Python、Linux 套件、系統工具，容器很方便。但它重。啟動慢。記憶體也吃得多。

如果拿它跟一般 MCP 工具列比，Cloudflare 的方案更偏向「讓 agent 寫程式」。MCP 很適合簡單工具。像查資料、列清單、叫一個 API。可是一旦流程複雜，工具列就會變得很長。

Cloudflare 這次的賭注，是 JavaScript + isolate + typed API。這組合很適合短命任務。也很適合 Web 原生服務。你可以把它想成一種更輕的執行層。

• 容器：彈性高，但啟動和記憶體成本高。
• MCP：適合平面工具，但複雜流程會變長。
• Dynamic Workers：幾毫秒啟動，適合短任務。
• JavaScript-first：對 Web 服務整合很順。

這也解釋了為什麼 Cloudflare 不急著把所有語言都包進來。它先鎖定一個最常見的場景。AI 生成 glue code。這種 code 不一定要跑完整 OS。只要能快速、安全地執行就夠了。

如果你是平台工程師，這裡的訊號很明白。未來的 agent runtime，可能會分成兩條路。一條是重型容器。一條是輕型 isolate。兩者都會存在，但用法會很不一樣。

這背後其實是雲端成本戰

Cloudflare 不是只在做產品。它也在打成本戰。因為 AI agent 的成本，不只在模型推理。還有 sandbox、記憶體、啟動時間、全球部署、冷啟動等待。

如果一個使用者問一句話，就要起一個容器。那成本會很難看。尤其當 agent 變成高頻功能時，這些 overhead 會很快放大。Cloudflare 想做的，是把短任務的執行成本壓下來。

這也跟它原本的網路邊緣定位有關。Cloudflare 本來就擅長把東西放到離使用者更近的地方。現在它把這個邏輯延伸到 AI code execution。你不需要把每個任務都送進遠端資料中心。

對開發者來說，這件事很現實。你最後還是要看延遲、記憶體、每次執行的單價。不是每個產品都需要大而全的容器。很多產品只是要快。要便宜。要穩。

如果你正在做 agent 產品，我會建議你先問三個問題。第一，任務是不是短命。第二，需不需要完整 OS。第三，能不能用 typed API 收斂權限。三題如果都偏向輕量，那 isolate 很值得試。

接下來該怎麼看

我的判斷很直接。Cloudflare 這次不是在秀一個 demo 而已。它是在把「AI 產生程式」變成一個可重複使用的執行模型。這對很多團隊會很有吸引力，尤其是做資料處理、API 串接、聊天機器人、內部自動化的人。

但它也不是萬用解。你如果要跑重 Python 套件、要碰系統層工具、要做長時間工作負載，容器還是比較合適。Cloudflare 的方向，比較像是把短小、頻繁、需要隔離的任務先吃下來。

接下來 6 到 12 個月，我會看兩件事。第一，其他雲平台會不會跟進 isolate 型 sandbox。第二，開發者會不會真的把 agent 迴圈放到這種 runtime 上。這兩件事如果成立，agent 基礎設施的寫法就會慢慢變。

如果你現在就在做 agent，我的建議很簡單。先挑一個 1 到 3 秒內能完成的小任務。把它搬到輕量 sandbox。量一次延遲、一次記憶體、一次成本。數字會比感覺誠實很多。