Deuz SDK 評測：把記憶、壓縮與可續跑執行收進同一個零依賴套件
Zero-dependency TypeScript framework for production AI agents: durable execution, long-term memory, hybrid RAG, MCP tool calling, human-in-the-loop approval, planning and CodeAct sandboxes. One streaming API for Claude, GPT, Gemini, Grok, Mistral and DeepSeek — Node, Bun, Deno, serverless and edge.
秒懂
- 它是什麼？
- Deuz SDK 是一套 TypeScript 代理執行環境，主打長期記憶、上下文壓縮、檢查點續跑與 MCP 工具串接。對已經被狀態管理與崩潰復原磨過一輪的團隊來說，它的取捨值得逐項檢查。
- 適合誰用？
- 如果你已經在用 TypeScript 寫代理，而且痛點明確落在跨 session 記憶、第四十輪的上下文爆掉、或行程中途死亡後要續跑，Deuz SDK 值得排進評估清單；反之，如果你只需要單次 generateText、不想引入任何狀態層，或團隊不接受把記憶與檢查點綁進自己的資料庫，那它帶來的抽象成本會大於收益。動手前先確認三件事：Node 版本是否 ≥ 22、記憶後端要用哪一種（向量庫、Postgres 或 Obsidian vault）、以及 repo 中 docs 目錄下的 what's-new-2-0.mdx 是否把 2.0 的破壞性變更交代完整。
- 可以商用嗎？
- 可以。MIT 是寬鬆授權：你可以使用、修改並販售以它為基礎的軟體，只需保留著作權與授權聲明。
- 還在維護嗎？
- 有在維護。儲存庫最近一次提交在 33 天前。
- 用什麼語言寫的？
- 主要是 TypeScript（依據 GitHub 的語言統計）。
以上回答依據專案的 GitHub 資料（最近同步於 2026年9月15日）與我們的分析，不構成法律意見。
開源專案深度解析
它想解的不是呼叫模型，而是呼叫完之後的那四十分鐘
README 開頭把問題講得很直白：呼叫模型已經是解決過的事，沒解決的是周邊。跨 session 記住一個使用者、第四十輪還待在上下文視窗內、在不可逆動作前問人、行程跑到一半死掉後續跑、接上工具伺服器而不用自己手刻 OAuth。這五件事在多數 SDK 裡是空的，開發者通常得自己補，而且補兩次。
目標讀者因此不是剛開始玩 LLM 的人。會需要長期記憶與檢查點續跑的，通常是已經上線、被狀態同步與崩潰復原磨過一輪的團隊。README 自己也劃了界線，說不宣稱要造 ASI，只把自己定位成那條路上的載具。這種自我定位在代理框架裡少見，至少它沒有把 durable execution 講成魔法。
零依賴不是省套件，是把環境全部注入
專案標榜 runtime dependencies 為 0，但真正值得注意的是它怎麼做到。README 的說法是「nothing ambient」：時鐘、隨機數、fetch、金鑰與日誌全部由外部注入。這件事的實際後果是同一份程式碼可以跑在 Node、Bun、Deno 與 edge，測試也維持確定性。
代價是呼叫端要自己接線。你需要處理環境注入的地方比一般 SDK 多，換來的是執行環境不被綁死。這筆交易划不划算取決於部署形態：如果你的服務只跑在單一 Node 環境，注入帶來的樣板會顯得多餘；如果你同時要出 edge 版本，這層抽象就是省下分支的關鍵。
安裝指令在 README 裡是 npm install @deuz-sdk/core，React 相關的 useChat 與 useObject 另外裝 @deuz-sdk/react。執行環境要求 Node ≥ 22，或任何具備 fetch 的 edge runtime。選用型 peer 只在真的用到時才需要：zod 或任何 Standard Schema 相容庫、@modelcontextprotocol/sdk、react、pg 或 redis、unpdf 與 mammoth 與 xlsx、playwright、@opentelemetry/api。
記憶是一條管線，不是一個訊息陣列
README 特別強調記憶不是 message array，而是一條管線：從對話中抽取持久事實、與已知內容對帳、依重要性評分、設定到期、下一次呼叫時把相關的拉回來。對帳動詞寫得很清楚，是 add、update、delete，而不是盲目附加。這一點是設計上的分水嶺，因為盲目附加正是多數自製記憶最後變成噪音的原因。
設定方式是在 generateText 裡掛上 memory 物件。seams 放 store、embedder 與 llm；scope 指定 userId；recall 控制 topK、maxChars 與 expandLinks；writePolicy 在範例中設為 each-turn。儲存後端可以是向量庫、Postgres 資料表或 Obsidian vault。
這裡有兩個需要自己驗證的點。第一，writePolicy 設為 each-turn 意味著每一輪都要跑抽取與對帳，成本會隨對話長度上升，README 沒有給出這條路徑的延遲數字。第二，抽取品質取決於你指定的 llm，也就是說記憶的正確性被綁在另一個模型呼叫上。若你的對話量大，這條管線的 token 帳單需要先算過。
壓縮的關鍵是那一塊會被更新的摘要，以及被拒絕後的重試
上下文填滿時，compaction 會做三件事：剪掉過期的工具輸出、丟棄舊的推理內容、把最早的幾輪折成單一滾動摘要。README 用了一句很精準的描述，說那是一塊會被更新的區塊，不是會一直長高的堆疊。這個區別在長跑代理裡很實際，因為堆疊式摘要在第三十輪之後通常已經沒有可讀性。
更值得記下的是失敗路徑：當供應商仍然以請求過長為由拒絕時，迴圈會強制壓縮並重試該步驟，而不是讓整個 run 失敗。這是把壓縮當成執行期機制而非前置設定的做法。啟用方式是在 generateText 傳入 compaction: 'auto'，範例同時給了 maxSteps: 30。
限制在於，強制壓縮代表你放棄了對那一步上下文的控制權。如果某個步驟的成敗取決於特定早期內容仍在視窗內，自動壓縮可能把它折進摘要而改變行為。這是設計取捨，不是缺陷，但需要在你的場景裡實測。
檢查點寫在你的資料庫，這是它與工作流廠商最大的分歧
README 把 durable execution 描述成步驟檢查點存在你自己的資料庫，之後用 resumeFromCheckpoint 接回來，並且明講不需要 workflow vendor。這個選擇把復原能力從外部服務拉回應用層，好處是沒有第二套執行環境要維運，代價是你得自己確保那個資料庫的可用性與一致性。
同一個 seams 概念延伸到其他狀態：SQLite、Redis 與 Postgres 都有對應的 pack，放在 memory、chat、session 與 run 這幾個接縫後面。範例中用 createPostgresStores 取得 stores，再分別以 chat 與 session 帶入 chatId、runId 與 scope。runtimeContext 則承載 tenantId 與 db，跟著呼叫走，而不是靠每次請求的閉包。
human-in-the-loop 也走同一條路。needsApproval 可以出現在任意深度，搭配 HMAC 簽章的到期 token，而且缺少裁決時一律視為拒絕。最後這條預設值是安全上的正確選擇，但也意味著審批流程中斷時，run 會停住而不是繼續，維運上要有對應的處理。
MCP 與多供應商：一行設定換掉手刻 OAuth
工具伺服器的接法在範例裡就是 mcp: [{ url: 'https://mcp.example.com/mcp' }]，README 說是連接、命名空間隔離與關閉都幫你處理好，另外支援 OAuth 2.0、重連、sampling 與 roots。對照之下，自行接 MCP 通常要處理授權流程與連線生命週期，這一行設定的價值就在這裡。
模型面則是 28 個 chat provider 分佈在四種 wire 上，另有 embeddings、images、speech、transcription 與 video。README 提到一個核心設計規則：先把供應商位元組正規化成標準化的 delta 串流，之後 retry、failover、resume、budgets、sub-agents 與型別化的 UI 事件才能共用同一種語言。這條規則解釋了為什麼它敢把這麼多能力放進一個套件。
串流 API 的行為值得單獨注意。streamChat 是同步回傳且不會拋出例外，失敗會以型別化的 stream part 抵達。範例中先迭代 res.textStream，再 await res.usage 取得用量。把錯誤變成資料而不是例外，對伺服器端是好事，但對習慣 try/catch 的團隊需要調整寫法。
Agent Skills 的驗證方式，比多數專案的文件可信
README 提到可以執行 npx skills add Deuz-AI/Deuz-SDK 安裝兩份 Agent Skills，一份是涵蓋整體介面的建構指南，一份是從 ai 與 @ai-sdk/* 逐名對照的遷移指南。真正有意思的是它怎麼防止代理亂編 API：每一份文件裡的 @deuz-sdk 符號都會在每次 commit 時對照真實的 export table 解析，每個程式範例都會對建置後的套件編譯，版本或鎖定的 API 契約一變就讓新鮮度檢查失敗。
README 也給了動機數字：在沒有 skill 的情況下把九個建置任務交給代理，九個答案裡有八個出現虛構匯入，共 19 個。這個做法值得其他框架參考，因為代理讀文件時最常見的失敗就是發明不存在的函式。
要注意的是，這套機制保證的是文件與匯出表一致，不保證行為符合你的預期。符號存在與語意正確是兩件事。
什麼情況下不該用它，以及該先驗證什麼
最明顯的不適用場景是單次呼叫。如果你只需要 generateText 一次、不需要記憶、不需要續跑，那 memory、session、compaction 這些接縫只會增加抽象層，直接呼叫供應商官方 SDK 更短。
第二種是團隊不願意把記憶與檢查點寫進自己的資料庫。這個框架的核心承諾建立在「檢查點存在你的資料庫」之上，若你的組織政策要求狀態留在託管服務，這個前提就不成立，durable execution 的優勢也一併消失。
第三種是對第三方依賴極度保守的環境。雖然 runtime dependencies 是 0，選用型 peer 清單卻很長，包括 zod、@modelcontextprotocol/sdk、pg 或 redis、unpdf 與 mammoth 與 xlsx、playwright、@opentelemetry/api。用到哪一項就承擔哪一項的維護。
授權是 MIT，README 的 badge 也指向 LICENSE 檔案。這對商業使用通常寬鬆，但授權解讀不是本文能給的建議，實際條款仍以倉庫中的 LICENSE 為準。
版本節奏方面，近期發布包含 v2.0.0、v1.9.0 與 v1.8.0，其中 v1.8.0 標題為 Autonomous Agent Runtime，v2.0.0 有專門的 what's-new-2-0.mdx 與從 Vercel AI SDK 遷移的文件。主版本跳動代表升級需要讀變更說明，不能只看 patch。
要動手前，先確認 Node 版本是否 ≥ 22、決定記憶後端（向量庫、Postgres 或 Obsidian vault）、並讀完 docs 目錄下的 what's-new-2-0.mdx。這三件事會決定你的整合成本，比任何功能列表都實際。
編輯結論
如果你已經在用 TypeScript 寫代理，而且痛點明確落在跨 session 記憶、第四十輪的上下文爆掉、或行程中途死亡後要續跑，Deuz SDK 值得排進評估清單；反之，如果你只需要單次 generateText、不想引入任何狀態層，或團隊不接受把記憶與檢查點綁進自己的資料庫，那它帶來的抽象成本會大於收益。動手前先確認三件事：Node 版本是否 ≥ 22、記憶後端要用哪一種（向量庫、Postgres 或 Obsidian vault）、以及 repo 中 docs 目錄下的 what's-new-2-0.mdx 是否把 2.0 的破壞性變更交代完整。這三項決定之後，再決定要不要跑 npm install @deuz-sdk/core。
社群筆記