AI Agent 每一次對話都要把整段 context 從資料庫撈回來，一問一答慢個幾百毫秒，長對話累積起來體驗就開始崩。目前多數團隊的作法是把 conversation history、tool call state、embedding vector 塞進 Redis 或 Postgres，agent 端每次接到請求就重新拉回來、重建成物件、丟給下一次推論。這一層跟 LLM 呼叫本身無關的 overhead，其實就是有狀態工作負載被強塞進 stateless 框架的結果。
Cloudflare 在 2020 年推 Durable Objects 給的答案技術上很漂亮：每一個「單元」——一段對話、一份文件、一個房間——各自對應一個 Object，狀態直接活在記憶體，需要時被叫醒、閒置時被睡掉、掉線時從內建 SQLite 復原。問題是 Durable Objects 只能跑在 Cloudflare 的邊緣網路上，程式碼要寫成 Workers Runtime 的模樣，離開 Cloudflare 這條路徑就等於整個模型需要換掉。
Rivet 2026 年 7 月把 v25.7 開源到 GitHub，把同一套 actor 模型用 Rust 從頭寫一次，Apache 2.0 授權，一支 binary 就能在 VPS 上跑起來，每個 actor 掛自己的 SQLite。這篇文章要看的就是這個模型為甚麼值得認真評估，以及自架起來要付出的實際成本是多少。
Actor 模型解決的是狀態貼近運算這件事
傳統的三層架構——無狀態 API 伺服器加共享資料庫——在 CRUD 型服務上跑了 20 年沒有大問題。這個模型的假設是：每個請求都是短的、獨立的、可以被任何一台伺服器接手處理，狀態拿完就丟。放到 AI Agent 上這個假設整個垮掉：一段對話是連續的、狀態越來越大、每次補一輪推論都需要把整段歷史加上工具呼叫結果重新丟回 context window。
Actor 模型的思路是反過來的。每一個 conversation、每一個 tenant、每一份協作文件都對應到一個 actor，這個 actor 是個長時間存活的物件，狀態就掛在自己的記憶體裡；來自這個對話的請求都路由到同一個 actor，讀寫都直接打記憶體，不需要每次都繞資料庫。閒置一段時間之後 actor 被主動 evict 掉、狀態落地到永久儲存；下一次請求進來就把它重新載回來。
這不是新概念。Erlang 從 1980 年代就在這個模型上跑電信交換機，Akka 把它帶進 JVM 世界，Orleans 是微軟在 .NET 上的版本，Cloudflare Durable Objects 是把它塞進 edge computing 的實作。但這些方案分別綁死了語言、Runtime 或平台，一直沒有一套 Apache 2.0 授權、能在自家 VPS 上跑、又直接對準 AI Agent 場景的開源實作。這是 Rivet 填的位置。
每個 Actor 掛一顆 SQLite 這件事的實際意義
Rivet 讓每一個 actor instance 掛自己的一顆 SQLite，官方文件寫的是「millions of isolated databases」，也就是可以直接開幾百萬顆彼此隔離的資料庫，一顆對應一個使用者、一個 workspace、一份文件。這在傳統思維裡聽起來是災難——但這裡的 SQLite 不是各自佔一個檔案的傳統部署，而是嵌在 actor 記憶體、由 Rivet 自己管 lifecycle 的資料結構。
這個設計解決兩個一直難搞的痛點。第一個是多租戶隔離：傳統作法要嘛在共用資料表上加 tenant_id 欄位（隔離弱、效能會被大戶拖垮）、要嘛每個租戶開一個 database（開銷高、schema 變更痛苦）。Rivet 直接讓每個租戶跑在自己的 SQLite 上，資料完全隔離、schema migration 也可以按租戶滾動。第二個是延遲：讀寫都是 in-process 的 SQLite 呼叫，跟走網路的 Postgres 查詢比是兩個數量級的差距。
Rivet 團隊 2026 年 7 月發表的一篇技術文章描述了「Zero-Disk, S3-Tiered Storage Engine for SQLite」——SQLite 的頁面資料不寫本地磁碟，直接分層儲存到 S3 兼容的 object storage。這意味著 actor 可以在任何節點上被喚醒，不需要在原本的機器上找檔案，也不需要跨節點同步。對 self-hosted 部署，這條路徑允許用便宜的 MinIO 或 Garage 撐冷儲存層，熱資料留在 FoundationDB 或 Postgres。
冷啟動與記憶體開銷的實際數字
Rivet 官方公佈的 benchmark 是：actor 冷啟動大約 20 毫秒，記憶體 overhead 大約 0.6 KB。對照組是 Kubernetes Pod 的冷啟動約 6 秒、單一 Pod 的最小記憶體足跡 50 MB 起跳。這兩個差距不是「效能更好」而已，是「使用場景不一樣」的差距。
20 毫秒冷啟動代表可以真的「即時」把閒置的 actor 叫醒——使用者送出訊息、等 SQLite 從冷儲存重建、agent 開始跑推論，整段中間的 wake latency 使用者感覺不出來。相對地，Kubernetes 那 6 秒讓 scale-to-zero 這件事在互動場景幾乎不可用——除非在前面塞一個永遠常駐的 gateway 幫忙擋、再等 Pod 起來，但這樣「scale to zero」的意義就少一半了。
0.6 KB 每個 actor 的開銷讓「每個對話一個 actor」變成算得出成本的事。一臺 32 GB 記憶體的 VPS 理論上可以撐幾千萬個閒置 actor，實際上受限於熱資料量而低於這個數字，但撐十萬到百萬等級的活躍會話在合理配置的機器上完全可行。這個數量級是傳統 microservice 架構開不到的——如果每個對話都要一個 Pod，10 萬個對話等於 10 萬個 Pod，就算 Pod 只吃 50 MB 記憶體，也要 5 TB。
Rivet 跟 Temporal、Hatchet 解決的問題不一樣
因為 Rivet 也常被歸類到「durable execution」這個大類別，很容易跟 Temporal 或 Hatchet 混在一起看，但這三者對準的問題其實不同。
Temporal 對準的是長時間執行的工作流：付款流程、訂單處理、審批流程這種橫跨數小時到數天、需要人工介入、需要可審計事件日誌的場景。它的 SDK 把工作流寫成看起來像同步的程式碼，底層拆解成事件、寫進 event history，任何一步失敗都能從中斷點接回。這種能力代價是複雜的部署——Cassandra 或 PostgreSQL、Elasticsearch、多個獨立服務——閒置記憶體輕鬆破 4 GB。
Hatchet 對準的是背景任務：從 Celery 那個位置往上走一階，用 Postgres 做儲存層，把 durable execution 的核心概念做成小團隊部署得起的樣子。適合的場景是「Web 請求觸發、丟到 queue、worker 撿來跑、失敗會 retry」這種傳統背景任務加上工作流編排。
Rivet 對準的是有狀態的即時互動：AI Agent 的對話狀態、多人協作文件的即時同步、遊戲房間的玩家列表、聊天室的即時訊息廣播。工作流編排 Rivet 也做（Gasoline 這個模組），但它的核心價值在於狀態貼近運算加上 actor 生命週期管理，這在其他兩者的模型裡都不是重點。
實務上的選擇：如果需求是背景任務加上偶爾出現的多步驟工作流，Hatchet 是最直接的答案。如果需求橫跨數天、需要嚴格的 audit trail 加上 SDK 幫忙處理狀態機，Temporal 值得付出部署成本。如果核心負載是 AI Agent 或即時協作、狀態需要貼近運算才能有合理延遲，Rivet 才是這個位置。
自架起來實際需要甚麼
Rivet 提供三種部署模式。最輕的是 library 模式，直接 npm install，開發階段跟一般 Node.js 應用一樣跑，狀態存在本地檔案系統。第二種是單一 Docker 容器加上一個 Postgres，適合中小規模生產環境；官方文件寫的是這個組合已經 production-ready，適合 light-to-moderate workload。第三種是多節點 cluster，儲存層可以選 FoundationDB（性能最好但運維較重）或 Postgres（相對容易）。
對臺灣的中小團隊來說，實際的部署路徑通常是這樣：一臺 4 核 8 GB 的 VPS 跑 Rivet server 加上內建 SQLite storage backend，前面接 Caddy 做 reverse proxy 跟自動 HTTPS，狀態量長大之後把儲存層換成獨立一臺 Postgres——這一臺可能本來就有，多接一個 schema 就好。整體資源占用比起同等規模的 Temporal 部署少一個數量級。
需要注意的坑主要有兩個。第一個是語言支援：Rivet 主要對準 TypeScript 跟 Bun，Rust 跟 Python 的 client 都還在實驗性階段，如果技術棧是 Go 或 Ruby 需要自己包 HTTP 呼叫。第二個是 SDK 心智模型：actor 程式碼不能隨便呼叫外部 API 而不處理 idempotency，因為 actor 有可能在任何一步被 evict 掉、後來被重新載入，如果外部呼叫沒有冪等保護，重放時就會重複執行。這一點跟 Temporal 的 activity 模型一樣，習慣了會變成第二天性，但一開始寫起來要小心。
結論
有狀態工作負載的基礎設施這個位置，長期以來被 Cloudflare Durable Objects 這種綁在特定平台的方案跟 Temporal 這種重量級 orchestration 系統夾在中間，中小團隊要嘛接受廠商鎖定、要嘛負擔不了部署成本。Rivet 用 Apache 2.0 授權、Rust 單一 binary、每個 actor 一顆 SQLite 的組合，把這個空缺補上，特別適合 2026 年開始把 AI Agent 從 demo 推進生產環境的團隊。
NCSE Network 提供的臺灣是方電訊機房 VPS，Intel Gold CPU 加上 NVMe SSD 的組合，把 Rivet 跟 Postgres 一起跑起來的延遲跟穩定度都能維持在合理範圍，適合作為有狀態 AI Agent 或即時協作服務的自架環境；如果之後需要多節點 cluster，也可以透過內部私網把幾臺機器串起來擴充。歡迎到 ncse.tw 了解更多方案細節。
