摘要： Cloudflare 在 2026 年 4 月推出 Project Think，把 agent 的讀檔、寫碼、執行與記憶放進 Durable Objects 的 serverless 模型，提供休眠零成本、可恢復執行、codemode 與權限階梯。這套設計想解決一對一 agent 的規模化成本，但目前仍是 API 會持續變動的實驗性 preview。
Cloudflare 在 2026 年 4 月把 Project Think 端上檯面，將它擺在 Agents SDK 下一代演進的位置。它要處理的命題並不是把模型做得更強，而是把 coding agent 身上早已驗證過的四項能力——讀檔、寫碼、執行、記憶——裝進 serverless 這套成本模型裡：agent 能長時間存在、能進休眠、崩潰後能回復，而且不做事的時候不產生費用。對正在挑選 agent 基礎設施的團隊來說，接下來會依序拆解它的機制、可量化的錨點，以及現階段的限制。
一對一的 agent，讓規模化的數學行不通
Pi、OpenClaw、Claude Code 與 Codex 這一輪工具已經說明了一件事：當 LLM 能讀檔、寫碼、執行，並且把學到的東西記下來，它產出的就不只是開發者工具，而是一個通用助理——行事曆管理、資料分析，連報稅都有人交給它。可是 Cloudflare 團隊自己每天在用這些工具，也每天卡在同一批痛點上：它們只能待在筆電或價格不低的 VPS、閒著照樣收費、相依套件與密鑰全得靠人手打理。
更根本的結構問題是：一般應用用一個實例服務一大群使用者，agent 卻得一個配一個。一億名知識工作者就算只有低度併發，也會需要數千萬個同時存在的 session；用目前每個容器的成本去算，這條路在數學上根本走不通。
用 actor 模型打底：休眠時成本歸零的長駐架構
Project Think 端出的是 Durable Objects 的 actor 模型：agent 在這個模型裡是一個能被定址的實體，並自帶一份 SQLite 資料庫。休眠期間運算成本是零；一旦有事件進來——HTTP 請求、WebSocket 訊息、排程鬧鐘或入站 email——平台會負責叫醒它、把狀態載回來，處理完再讓它睡回去。
數字一比就很清楚：10,000 個各自只有 1% 時間活躍的 agent，在容器世界得開 10,000 個 always-on 實例；換到 Durable Objects，任一時刻只有約 100 個還活著。新開一個 agent 的邊際成本趨近零，架構的重心也因此從「每個重度使用者配一個昂貴 agent」，轉向「每個客戶、每個任務都能有自己的 agent」。
| VM / 容器 | Durable Objects | |
|---|---|---|
| 閒置成本 | 永遠開著，全額計費 | 休眠時為零 |
| 狀態 | 需外接資料庫 | 內建 SQLite |
| 喚醒與恢復 | 自行建構（程序管理、健康檢查） | 事件喚醒，平台重啟狀態保留 |
| 規模化單位 | 預先配置容量 | 每 agent 一個，邊際成本趨近零 |
持久執行：fibers 把崩潰降級成一段可恢復的插曲
一次 LLM 呼叫可能就要 30 秒，多輪的 agent 迴圈還會更久，而在這段期間裡，部署、平台重啟或資源限制隨時都可能插進來。runFiber() 的做法是把函式呼叫轉成持久操作：開始執行前先註冊進 SQLite，過程中隨時能用 stash() 打檢查點，重啟之後交給 onFiberRecovered 接手還原；keepAlive() 和 keepAliveWhile() 則確保正在活躍的工作不會被驅逐。若任務長度是以小時計，正確的作法是把工作啟動起來、把 job ID 持久化、進入休眠，等回呼來了再醒過來。
子代理、樹狀 session，以及能跨休眠的記憶
子代理是以 Facets 與 parent 共置的子 Durable Objects：每一個都有自己的 SQLite 與執行環境，彼此之間沒有隱式的資料共享；RPC 是 typed 的，誤用會在編譯期就被抓出來，orchestrator 也能用 Promise.all 同時平行驅動多個子代理。
對話本身交給實驗性的 Session API 打理：訊息以樹狀保存，每一則都帶 parent_id，所以可以 forking 去探索替代路徑、能做非破壞性的 compaction，也能用 FTS5 對整段歷史做全文搜尋；Think base class 的儲存層也由它擔綱。
長期記憶則靠 context blocks 落地：模型眼前會有一個標著使用率與預算的記憶區塊，可以透過 set_context 主動改寫內容，內容跨休眠依然留存，還能搭配 withCachedPrompt() 把重複產生的成本壓低。
MEMORY [42%, 462/1100 tokens]
偏好：回覆使用繁體中文，程式碼附最小可執行範例
專案：部署目標 Cloudflare Workers，測試以 Bun 執行codemode：要 agent 動手寫程式，別再逐個玩工具呼叫
傳統工具呼叫的形狀相當浪費：模型叫一個工具、把結果拉回上下文視窗、再叫下一個，工具數量一多就是線性膨脹。codemode 看到的關鍵是，模型其實更擅長「寫一支程式去操作系統」——讓 LLM 產生單一程式，在沙盒中一次把整個任務跑完。Cloudflare API 的 MCP server 因此只暴露 search() 與 execute() 這兩個工具，用大約 1,000 個 token 就能描述整套 API；相對於傳統每個端點配一個工具、約需 117 萬個 token 的做法，等於少了 99.9%。
capability model 與五層執行階梯
模型既然要寫碼，就得先回答「碼在哪裡跑」。答案落在 Dynamic Workers：V8 isolate 毫秒級就能啟動、只吃數 MB 記憶體，官方數據是約比容器快 100 倍，記憶體效率最高也可達 100 倍。安全設計採用 capability model：起點是幾乎沒有任何環境權限（globalOutbound: null、無網路），再經由 bindings 一項一項明確授權——問題於是從「怎麼擋住它」，翻轉成「你到底要它能做什麼」。
執行階梯就是這樣一層層疊上去的：最底層 Tier 0 給的是 SQLite 加 R2 的 workspace（@cloudflare/shell，光是單獨使用就已具備生產力）；往上一階 Tier 1 換成無網路的 Dynamic Worker（codemode）；Tier 2 再把 npm 加進來（@cloudflare/worker-bundler 以 esbuild 打包）；Tier 3 輪到 headless browser；最頂的 Tier 4 是完整 Sandbox，足以跑 git clone、npm test、cargo build。能力一層層累加，風險也一層層加上管控。
繼承 Think base class，讓 extensions 自己長出來
要自己從原語一磚一瓦拼裝太累的人，直接繼承 Think 就好：子類最小可以只覆寫 getModel()，npx wrangler deploy 一跑，就有一個能串流的聊天 agent 可以用——官方部落格挑的範例模型是 Moonshot 的 Kimi K2.5。底層協定和既有的 AIChatAgent 是同一套，角色卻不一樣：想走既有路線，得自己接上約 15 行的 AIChatAdapter protocol adapter，模型呼叫也自己打理；Think 走的是 opinionated framework 這條路，樹狀 session、非破壞性操作、子代理 RPC 全都內建。它能當頂層 agent，也能被 parent 以 chat() 叫起來當子代理。
更值得注意的一塊，是執行期自己寫出來的 extensions：agent 以沙盒裡的 TypeScript 造出新工具、宣告它要用的 network 與 workspace 權限，再經由 ExtensionManager 打包、載入 Dynamic Worker，最後註冊成可用工具——這些工具住在 DO storage，跨休眠也還在。所謂自我改進，是靠程式碼達成的，而不是 fine-tuning。
現況與限制：還在 preview，離承諾很遠
官方文件給 Project Think 的標籤是實驗性 preview：概念當下就能用，API surface 眼下算穩定，但會一直演進，整體也還不到能當成凍結 production contract 的程度。npm 上的套件名為 @cloudflare/think；它底下那層 Agents SDK 早已撐起數千個 production agents。引用時還有一個坑：版本有落差——Think 文件頁的範例已經換成 Kimi K2.6，部落格範例則還是 Kimi K2.5，兩者各自以出處為準。builder 真正該帶走的是它那套經濟學與安全設計；API 本身不妨等它從 preview 畢業之後再押注。