AI生成代碼的執(zhí)行速度，現(xiàn)在和本地硬盤讀寫一樣快了。

Cloudflare兩周前發(fā)布的Dynamic Workers，讓AI代理寫的代碼能直接在隔離沙箱里跑。隔離體（isolate）比容器輕100倍，啟動(dòng)快100倍，內(nèi)存只要1/10。用完即拋，像帶安全鎖的eval()。

但有個(gè)場(chǎng)景他們沒細(xì)說：如果AI生成的不是一次性腳本，而是帶UI的小應(yīng)用呢？如果用戶想明天再打開這個(gè)應(yīng)用，數(shù)據(jù)還在嗎？

Cloudflare的解法是把Durable Objects塞進(jìn)Dynamic Workers——讓每個(gè)AI應(yīng)用自帶一個(gè)SQLite數(shù)據(jù)庫(kù)，物理上跑在同一臺(tái)機(jī)器的本地磁盤。

存儲(chǔ)延遲從"毫秒級(jí)"打到"零"

傳統(tǒng)云數(shù)據(jù)庫(kù)的瓶頸不在帶寬，在距離。

哪怕是最快的分布式數(shù)據(jù)庫(kù)，請(qǐng)求也要跨網(wǎng)絡(luò)。Durable Objects反著來：一個(gè)名字對(duì)應(yīng)一個(gè)實(shí)例，全球唯一，SQLite文件就躺在實(shí)例所在機(jī)器的硬盤上。讀寫的物理距離是零，延遲也是零。

這對(duì)AI生成的小應(yīng)用是剛需。一個(gè)AI給用戶做的記賬工具、待辦列表或小游戲，不需要高并發(fā)，但需要狀態(tài)持久化。以前你得讓Dynamic Worker去連遠(yuǎn)程數(shù)據(jù)庫(kù)，現(xiàn)在數(shù)據(jù)庫(kù)和應(yīng)用焊死在同一個(gè)隔離體里。

但技術(shù)債來了。Durable Objects的正常用法很"重"：寫類、繼承、導(dǎo)出、在Wrangler配置里聲明命名空間、綁定時(shí)還要指向?qū)崿F(xiàn)類。Dynamic Workers的核心賣點(diǎn)是"不用碰Cloudflare API就能跑動(dòng)態(tài)代碼"，這兩套系統(tǒng)天生八字不合。

動(dòng)態(tài)代碼怎么認(rèn)領(lǐng)靜態(tài)存儲(chǔ)

Cloudflare的工程師卡在這：Durable Object的存儲(chǔ)必須通過API預(yù)置，命名空間要指向一個(gè)具體的類實(shí)現(xiàn)。Dynamic Worker的代碼是運(yùn)行時(shí)生成的，根本不存在于任何配置文件中。

他們的解法是把Durable Object拆成兩半。

一半叫"存儲(chǔ)端"——提前部署好的標(biāo)準(zhǔn)Durable Object，只負(fù)責(zé)托管SQLite文件，暴露原始存儲(chǔ)接口。另一半是"計(jì)算端"——AI生成的Dynamic Worker代碼，通過特殊綁定直接掛載到這個(gè)存儲(chǔ)端。

關(guān)鍵設(shè)計(jì)：存儲(chǔ)端不碰業(yè)務(wù)邏輯，計(jì)算端不碰存儲(chǔ)配置。兩者通過命名約定配對(duì)，像租房時(shí)鑰匙和門牌號(hào)的分離。

這意味著你可以讓AI生成1000個(gè)不同的小應(yīng)用，每個(gè)應(yīng)用代碼完全不同，但共享同一套存儲(chǔ)基礎(chǔ)設(shè)施。用戶打開應(yīng)用A，Dynamic Worker加載A的代碼，掛載到A的Durable Object；五分鐘后打開應(yīng)用B，同一個(gè)隔離體環(huán)境換一套代碼，換一塊硬盤。

AI應(yīng)用開發(fā)者的算盤

這個(gè)組合解決了一個(gè)真實(shí)痛點(diǎn)：AI生成的代碼不可信，但用戶數(shù)據(jù)必須可信。

以前的做法是給AI應(yīng)用配一個(gè)共享數(shù)據(jù)庫(kù)，通過權(quán)限系統(tǒng)隔離。問題是AI寫代碼時(shí)可能搞錯(cuò)表名、漏掉WHERE條件，一個(gè)應(yīng)用的bug能波及所有用戶?，F(xiàn)在每個(gè)應(yīng)用有自己的SQLite文件，搞砸了最多刪自己。

成本結(jié)構(gòu)也變了。Durable Objects按請(qǐng)求數(shù)和存儲(chǔ)量計(jì)費(fèi)，不是按實(shí)例常駐收費(fèi)。一個(gè)用戶一周打開兩次的AI生成工具，兩次之間不占資源。這對(duì)長(zhǎng)尾的、低頻的、AI隨手生成的小應(yīng)用是精準(zhǔn)匹配。

Cloudflare沒公布具體數(shù)字，但給了個(gè)參照：隔離體啟動(dòng)時(shí)間在毫秒級(jí)，Durable Object的SQLite讀寫是微秒級(jí)。兩者疊加，一個(gè)冷啟動(dòng)的AI應(yīng)用從代碼加載到讀到第一條數(shù)據(jù)，總延遲能壓進(jìn)兩位數(shù)毫秒。

邊界和待填的坑

方案有硬限制。Durable Objects是單實(shí)例的，不能自動(dòng)水平擴(kuò)展。AI生成的應(yīng)用如果突然 viral，會(huì)被鎖死在單個(gè)實(shí)例的CPU和內(nèi)存里。Cloudflare的建議是"別用來做高并發(fā)服務(wù)"，定位清晰：個(gè)人工具、原型、內(nèi)部腳本。

另一個(gè)坑是代碼更新。Durable Object的SQLite文件綁定到實(shí)例名字，但Dynamic Worker的代碼版本是流動(dòng)的。如果AI給用戶生成了v1的記賬應(yīng)用，存了一堆數(shù)據(jù)，后來升級(jí)到v2，怎么保證數(shù)據(jù)格式兼容？Cloudflare把這個(gè)問題扔給了開發(fā)者——存儲(chǔ)端只提供字節(jié)，schema migration自己想辦法。

還有安全邊界。Dynamic Worker的隔離體防的是代碼逃逸，但Durable Object的存儲(chǔ)綁定一旦建立，代碼對(duì)SQLite有完全訪問權(quán)。AI生成的代碼如果故意或意外執(zhí)行了DROP TABLE，存儲(chǔ)端不會(huì)攔。這和傳統(tǒng)Durable Object不同——那里業(yè)務(wù)代碼是你自己寫的，現(xiàn)在代碼來自不可信的AI。

Cloudflare的文檔里埋了一句："建議對(duì)AI生成的代碼進(jìn)行額外審查或使用受限API子集。"翻譯成人話：別直接跑ChatGPT吐出來的代碼，至少加個(gè)白名單。

為什么是現(xiàn)在

Dynamic Workers + Durable Objects的組合，本質(zhì)是云廠商在搶AI應(yīng)用的托管定義權(quán)。

Vercel的v0生成前端代碼，Replit的Agent生成全棧項(xiàng)目，但跑起來之后的狀態(tài)管理都是各自為政。Cloudflare這套方案把"生成-部署-存儲(chǔ)"焊成一條鏈：AI寫代碼→秒級(jí)啟動(dòng)→自帶數(shù)據(jù)庫(kù)→按請(qǐng)求計(jì)費(fèi)。對(duì)想做AI應(yīng)用平臺(tái)的開發(fā)者，這是現(xiàn)成的基建。

有個(gè)細(xì)節(jié)值得玩味：Cloudflare把Durable Objects的存儲(chǔ)接口設(shè)計(jì)得足夠原始（get/put/sql.exec），而不是封裝成ORM。這故意留出的"粗糙"，反而讓AI生成的代碼更容易對(duì)接——LLM寫原始SQL比寫Prisma schema更不容易出錯(cuò)。

產(chǎn)品文檔里提到，早期測(cè)試者用這套方案做了"個(gè)人知識(shí)庫(kù)工具"和"AI輔助的數(shù)據(jù)看板"。都是單用戶、重狀態(tài)、低并發(fā)的場(chǎng)景，和Cloudflare設(shè)定的邊界吻合。

技術(shù)社區(qū)的反饋分兩極。一派覺得終于不用為AI小應(yīng)用配Postgres了，SQLite夠用且零運(yùn)維；另一派擔(dān)心被鎖進(jìn)Cloudflare的生態(tài)，Durable Objects的API別家沒有，遷移成本隱形。

Cloudflare沒回應(yīng)遷移問題。他們的賭注是：AI生成的應(yīng)用生命周期本來就短，用戶更在乎"現(xiàn)在能跑"而不是"以后能遷"。

這套方案已經(jīng)上線，文檔和示例代碼在Cloudflare的開發(fā)者站點(diǎn)。第一個(gè)用例是AI生成的待辦應(yīng)用，代碼23行，從用戶輸入到數(shù)據(jù)落盤，端到端延遲87毫秒。

下一個(gè)被塞進(jìn)隔離體的會(huì)是什么？電子表格？輕量CRM？還是AI給自己寫的調(diào)試工具？