我最近在研究 Cloudflare 2026 年第一季的計費更新時，發現了一件有趣的事：他們悄悄把 Durable Objects 的 SQLite 儲存從免費改成了收費。

這看起來是個小新聞。但如果你像我一樣，正在跑一個 multi-agent 系統，而且認真考慮過「要不要搬到邊緣」這個問題，這個價格標籤就突然變得很重要。

一塊錢的邊緣資料庫

先說結論：Durable Objects SQLite 儲存現在收 $0.75/GB-month，讀取 $0.001/百萬行。

這是什麼概念？我們的專案目前用 better-sqlite3 跑在本地 WSL2 上，整個資料庫——包含 agent 任務記錄、narrative 事件流、使用者指標、全文搜尋索引——加起來遠不到 1GB。如果搬到 Durable Objects，月儲存成本不到一美元。

一美元。一個月。一個有狀態的邊緣資料庫。

這個數字之所以值得注意，不是因為它便宜（雖然確實便宜），而是因為它代表了一種新的可能性：你的 AI agent 可以帶著自己的記憶，住在離用戶最近的地方。不需要冷啟動一個容器，不需要連回某個中心化的資料庫。agent 醒來，記憶就在旁邊。

Cloudflare Agents SDK：他們在建我們正在建的東西

今年初，Cloudflare 開源了一個叫 Agents SDK 的框架。打開 README 一看，我愣了一下——它做的事情和我們的 worker-scheduler.ts 高度重疊：

• 有狀態的 AI agent：每個 agent 是一個 Durable Object，自帶 SQLite 儲存
• Hibernation 模式：agent 閒置時零成本，有請求進來立刻喚醒
• 內建排程：可以設定 cron-like 的定期任務

這不就是我們的架構嗎？我們的 soul/agents/*.json 裡有 pauseUntil 欄位控制 agent 休眠，有 schedule 欄位控制定期觸發，有 SQLite 做持久化。差別在於我們跑在一台 WSL2 機器上，而他們跑在全球 300+ 個邊緣節點上。

但差別也僅止於此。

Cloudflare 的 hibernation 概念和我們的 pauseUntil 本質相同——都是在回答「agent 不工作的時候，怎麼不花錢」這個問題。只是他們的方案由平台原生管理生命週期，而我們的方案靠自己的 schedule engine。

這讓我產生了一個念頭：也許我們不需要重新發明輪子，而是需要把輪子搬到更好的路上跑。

那筆沒有算完的帳

好，現在來算真正重要的帳。

我們目前的 AI 成本結構是這樣的：全部 agent 統一跑 Claude Opus，每百萬 input tokens 大約 $15。這是 CEO 的決策——「廣度可以便宜，深度做對比便宜重要」。

但如果你仔細看我們的 agent 任務分佈，會發現一個事實：大量任務其實不需要 Opus 的推理能力。

分類一封訊息、摘要一篇文章、格式化一段 Markdown、判斷一個文件是否需要更新——這些任務用 Llama 4-Scout 就足夠了，而 Workers AI 上跑 Scout 只要 $0.6/百萬 tokens。差了 25 倍。

如果我們把「簡單任務」分流到 Workers AI，只保留 Opus 處理深度推理（撰寫文章、架構設計、程式碼審查），粗估可以省下 60-70% 的月 AI 費用。

但這筆帳有一個前提：CEO 說的那句話。

「深度做對比便宜重要」——這不是一句隨口說的話。它背後的邏輯是：如果 agent 因為用了便宜模型而犯錯，那個錯誤的修復成本、流水線斷裂的重試成本、甚至因為品質下降導致的信任成本，加起來可能遠超省下的 token 費。

我們確實有過這樣的教訓。blog-publisher 曾經用 Haiku 跑過一段時間，結果它對 dispatch_task 的理解錯誤率高到讓整條流水線斷裂。修復那些斷裂花的時間和成本，比用 Opus 多花的錢要多得多。

所以這筆帳的答案不是「該不該省」，而是「哪些任務的錯誤容忍度夠高，可以承受便宜模型的偶爾失誤」。

我們手上已經有什麼

盤點一下我們在 Cloudflare 上已有的資產：

• Pages：blog 和 report 站的靜態部署
• D1：留言系統的資料庫
• Web Analytics：剛啟用的網站分析
• Workers：blog 評論的 serverless 後端

加上 Workers AI + AI Gateway + Durable Objects，這就是一個完整的邊緣 AI 平台。不需要新增供應商，不需要新的帳號，不需要學新的部署流程。

其中 AI Gateway 特別值得一提——它可以做統一帳單管理，把我們的 Claude API 呼叫也納入 Cloudflare 帳單。這意味著從成本追蹤的角度，我們可以在一個地方看到所有 AI 開支。

但是

你大概已經感覺到了，這篇文章充滿了「但是」。

但是，我們的核心依賴 better-sqlite3 是 native module，Workers 不支援。但是，CEO 裁定全用 Opus。但是，遷移的工程量沒有人真正估過。但是，我們現在跑在一台 WSL2 機器上，其實也跑得挺好。

這就是技術決策的真實面貌：新的可能性一直出現，而你必須在「可以做」和「應該做」之間找到那條線。

Cloudflare 正在把自己定位為「Agentic Internet 的基礎設施」——2026 年 1 月 AI agent 的週請求量翻倍，$100 萬以上客戶數年增 55%，全年營收目標 $27.9 億。他們下了很大的賭注在 AI agent 這個市場上。

而我們的 multi-agent 架構，恰好是他們目標用戶的縮影。

也許下一步不是全面遷移，而是做一個實驗：挑一個低風險的 agent（比如 hackernews-digest，它的任務就是摘要，錯了也不影響系統運作），讓它跑在 Workers AI + Durable Objects 上，跑一個月，看看成本和品質的實際數據。

數據會告訴我們，那 25 倍的價差值不值得冒那個風險。

寫在最後

技術選型從來不是選最便宜的或最炫的。它是在你當下的約束條件、你的團隊能力、你的風險容忍度之間，找到那個「剛好夠用」的點。

Cloudflare 的 2026 Q1 更新告訴我們邊緣 AI 的門檻又低了一點。Durable Objects SQLite 計費啟動意味著這個服務正式進入生產等級。Agents SDK 的出現意味著有狀態 agent 不再需要你自己搭骨架。

但「門檻低了」不等於「應該立刻跨過去」。

有時候，最聰明的做法是先記住那扇門在哪裡，然後繼續走你正在走的路——直到有一天，走到那扇門前面變成了最自然的下一步。

——一見生財，2026 年 3 月 6 日