
Cloudflare Computer 將 AI 代理檔案同運算拆開,簡單工作先交俾 Worker
持久工作區留住檔案,要完整 Linux 功能先啟動 container
Cloudflare 開源咗 @cloudflare/computer 早期預覽版,想畀 coding agent 一個可以長期保留檔案、又唔使全程霸住 Linux container 嘅工作區。iThome 報道,代理做整理檔案、處理文字或者簡單指令時,可以先用啟動較快嘅 Worker isolate;撞到原生 binary、完整 shell、安裝套件或者網上連線等工作,先叫起 container。呢個分工幾合理,但真正值得拆嘅地方,係 Cloudflare 點樣將「檔案留喺邊」同「指令喺邊度跑」分開。
檔案跟工作區走,運算環境隨時換
Computer 以 Durable Object 做每個工作區嘅固定入口,檔案權威版本存喺 SQLite。代理停低、重新啟動,甚至轉用另一種執行環境,之前寫落嘅內容仍然保留。Worker isolate 會直接經 Workers RPC 存取工作區;container 就由 computerd 將同一批資料掛成 FUSE 檔案系統,改動再經 RPC 寫返去。換句話講,開發者唔使自己砌一套 Worker、container 同物件儲存之間嘅同步邏輯,代理亦可以用同一個 workspace.runtime 介面揀 backend。
套件而家有三種 backend:用 just-bash 嘅 isolate shell、執行 ECMAScript module 嘅 isolate JavaScript,同完整 Linux container。前兩種適合讀寫檔案、跑受控 JavaScript 同處理基本指令,container 就留俾 pandoc、原生工具、測試環境或者較複雜嘅 NPM 安裝。開發者可以替 backend 寫用途描述,再交俾模型選擇;亦可以由程式直接指定。正式系統最好保留明確規則同權限限制,如果完全信模型自行判斷,成本、網上存取權同執行結果都會多一層不確定性。

圖片:Cloudflare
慳到 container,成本就搬咗去其他層
每個代理長期保留一個 container,概念最直白:檔案、套件快取同執行環境全部擺埋一齊,除錯亦較容易。不過代理好多時間只係等模型回覆或者等下一個任務,預留 RAM、磁碟同 instance 容量未必抵。如果代理數量多、任務間歇出現,而且工作量有輕有重,Computer 呢種混合方案會較啱用。簡單操作留喺 isolate,真係用到 Linux 先付 container 資源。代價係整套 app 同時踩中 Dynamic Workers、Durable Objects、Workers RPC、Containers 同檔案掛載,監察、權限同帳單都複雜咗。
Cloudflare Containers 本身已經可以休眠同 scale to zero,計費亦會喺收到工作或者手動啟動後先開始,instance 睡眠後停止。所以「每個代理一個 container」唔一定等於二十四小時燒錢,Computer 解決得較好嘅其實係避免頻繁叫醒完整 Linux 環境,同時保留一個獨立於 container 生命週期嘅工作目錄。另一邊,Dynamic Workers 只喺 Workers Paid plan 提供,仲會按每日建立嘅獨立 Worker、請求同 CPU 時間計費;Durable Object 儲存同 container 資源亦各有帳。呢套設計係重新分配成本,唔係免費午餐。
持久檔案層有實在嘅 I/O 代價
Cloudflare 公開嘅自家測試用 standard-2 container,規格為 1 vCPU、6 GiB RAM 同 12 GB 磁碟,安裝包含 854 個套件、36,675 個檔案嘅 cloudflare/sandbox-sdk。FUSE 工作區需時 124.7 秒,container 本機 ext4 磁碟係 63.9 秒,慢接近一倍;64 MiB 連續讀寫差距仲大。另一方面,部分目錄掃描、刪檔同 Git metadata 操作就快過測試中嘅 ext4。呢批數字全部出自 Cloudflare,未有獨立驗證,測試亦只涵蓋一款 instance;不過已足夠提醒大家,大型 monorepo、密集 build output 同反覆安裝依賴未必係呢個虛擬檔案層最舒服嘅工作。
Preview 夠試概念,未夠膽接正式工作
@cloudflare/computer 而家版本係 0.1.1,以 MIT 授權開源,但 README 已經寫明 API 未穩定、設計會改,暫時只適合實驗同 prototype。底層 Containers 同 Sandbox SDK 已經 GA,Computer 呢層整合仍然好早;文件入面部分規格仲只代表方向,未必係現有程式碼做到嘅功能。想試多代理 coding workflow、文件產生或者短任務自動化,呢套架構幾有參考價值。要處理大型 codebase 或穩定 production 工作,現階段用長壽命 container、Sandbox snapshot 或自己管理物件儲存,行為會較容易預計。下一步要睇 Cloudflare 點樣穩定 API、收窄權限邊界,同改善大量檔案 I/O。
參考來源
- iThome — Cloudflare開源Computer代理工作區,按任務切換Workers與容器 — original report
- Cloudflare Blog:Introducing Cloudflare Computer — 官方產品介紹、設計動機同使用方式
- Cloudflare Computer GitHub — 核對三種 backend、持久檔案架構、preview 狀態同 MIT 授權
- Cloudflare Computer 效能測試 — 官方測試條件、FUSE 工作區同本機磁碟差距
- Cloudflare Containers 收費文件 — 核對 container 啟動、休眠、資源同流量計費方式
- Cloudflare Dynamic Workers 收費文件 — 核對 Paid plan 限制、建立數量、請求同 CPU 計費
- Cloudflare Durable Objects 限制 — 核對 SQLite 工作區每個 Durable Object 嘅儲存上限
本文根據原文及公開資料整理;資料有出入時,以原文及官方資料為準。







