它的設計目標包括：

• 讓 Agent 記住使用者偏好與歷史操作
• 在長任務中保持任務狀態
• 減少需要塞入模型 prompt 的原始資料量

系統同時支援兩種記憶能力：

• 長期記憶（Long‑term memory）：跨 session 保存經驗與使用者資訊
• 短期記憶壓縮（Short‑term compression）：在任務執行過程中降低上下文負擔

這意味著 Agent 不必每次都重新處理所有資訊，而是能逐步累積可重用的知識。

四層長期記憶架構

TencentDB Agent Memory 的長期記憶設計採用 四層遞進式架構，將原始對話逐步轉化為結構化知識。

L0：Raw Dialogue Layer（原始對話層）
完整保存所有對話與任務互動紀錄。

L1：Atomic Memory Layer（原子記憶層）
從對話中抽取事實，例如使用者偏好、限制條件或任務結論。

L2：Scenario Summary Layer（場景摘要層）
把與同一任務或情境相關的記憶整理成可重用的工作模式。

L3：User Profile Layer（使用者画像層）
提煉長期行為模式與偏好，形成簡化的使用者檔案。

透過這種分層方式，原本零散的對話資料會逐漸轉化為可重用的知識結構，使 Agent 能從歷史經驗中學習。

核心機制：Context Offloading + Mermaid 任務畫布

在長任務場景中，真正造成 Token 爆炸的往往是工具輸出與日誌。騰訊的解法主要包含兩個機制。

Context Offloading（上下文卸載）

當 Agent 呼叫工具（例如抓取網頁或執行程式）後：

• 完整輸出會存到外部儲存
• prompt 中只留下簡短摘要或引用

因此大量原始資料不再佔據上下文空間。

Mermaid 任務畫布

另一個關鍵設計是 Mermaid Task Canvas。

Mermaid 是一種文字式流程圖語言，常見於 GitHub 技術文件。騰訊利用它來建立 任務流程圖。

在這張畫布中：

• 節點代表任務步驟
• 邊表示依賴關係
• 每個節點只保留摘要或狀態

模型不需要閱讀完整歷史對話，而是透過這張「任務地圖」了解目前進度與下一步方向。

騰訊用一個簡單比喻說明差異：

日誌適合記錄一切，但導航需要的是地圖。

Mermaid 任務畫布就扮演這張地圖的角色。

根據上下文「水位」動態壓縮

TencentDB Agent Memory 會持續監控 prompt 使用量，並在不同水位觸發不同壓縮策略。

常見策略包括：

• L1 即時摘要：工具執行後立即生成高密度摘要
• L2 任務畫布更新：異步更新 Mermaid 任務圖
• L3 深度壓縮：當上下文使用量約達 80% 時壓縮或移除舊訊息

如果接近 95% 的臨界值，系統會觸發緊急壓縮，快速降低上下文負載。

騰訊公布的測試結果

騰訊在多個 benchmark 中報告了性能提升。不過這些數據來自廠商測試，尚未被廣泛獨立驗證。

WideSearch

• 通過率：33% → 50%
• Token 使用：221.31M → 85.64M（下降 61.38%）

SWE‑bench

• 成功率：58.4% → 64.2%
• Token 使用下降約 33%

AA‑LCR

• 成功率：44.0% → 47.5%
• Token 使用下降約 31%

PersonaMem

• 準確率約從 48% 提升至 76%。

騰訊也表示，在涵蓋 1540 個任務 的測試中（包括程式生成、搜尋與文件分析），任務完成率提升 12%–35%，Token 使用下降 33%–64%。

4 月發布與 5 月開源版本的差異

TencentDB Agent Memory 在 2026 年其實經歷了兩個階段。

4 月版本

• 推出長期記憶服務
• 引入四層記憶架構
• 主要解決跨 session 記憶問題

5 月 14 日開源版本

• 完整技術棧以 MIT License 開源
• 新增短期記憶壓縮機制
• 重點介紹 Context Offloading + Mermaid Task Canvas 架構

換句話說，早期版本重點在「記住過去」，而開源版本更強調「讓長任務不塞爆上下文」。

已支援的 Agent 框架

騰訊表示該系統已可整合到多個 Agent 架構中，例如：

• OpenClaw（可作為記憶插件）
• Hermes Gateway / Hermes Agent，支援 Docker 部署

這讓開發者能在現有 Agent 系統中加入記憶與壓縮能力，而不必重新設計整個架構。

為何這對 AI Agent 發展重要

隨著 AI Agent 從展示型 demo 走向實際應用，例如：

• 程式開發助理
• 研究與資訊搜尋
• 企業流程自動化

上下文成本（context economics） 正成為一個關鍵瓶頸。

每一次工具呼叫產生的內容，都可能讓 prompt 成本增加並干擾推理。

騰訊的做法試圖同時解決兩件事：

• 成本問題：減少 Token 使用量
• 可靠性問題：用結構化任務圖維持推理方向

如果這些效果在更多實際環境中得到驗證，像 TencentDB Agent Memory 這樣的記憶層，可能會成為未來 AI Agent 基礎架構的一部分。

目前來看，相關性能提升仍主要來自騰訊官方測試；未來是否能在不同模型與 Agent 框架中普遍成立，仍有待更多第三方實驗驗證。

它的設計目標包括：

• 讓 Agent 記住使用者偏好與歷史操作
• 在長任務中保持任務狀態
• 減少需要塞入模型 prompt 的原始資料量

系統同時支援兩種記憶能力：

• 長期記憶（Long‑term memory）：跨 session 保存經驗與使用者資訊
• 短期記憶壓縮（Short‑term compression）：在任務執行過程中降低上下文負擔

這意味著 Agent 不必每次都重新處理所有資訊，而是能逐步累積可重用的知識。

四層長期記憶架構

TencentDB Agent Memory 的長期記憶設計採用 四層遞進式架構，將原始對話逐步轉化為結構化知識。

L0：Raw Dialogue Layer（原始對話層）
完整保存所有對話與任務互動紀錄。

L1：Atomic Memory Layer（原子記憶層）
從對話中抽取事實，例如使用者偏好、限制條件或任務結論。

L2：Scenario Summary Layer（場景摘要層）
把與同一任務或情境相關的記憶整理成可重用的工作模式。

L3：User Profile Layer（使用者画像層）
提煉長期行為模式與偏好，形成簡化的使用者檔案。

透過這種分層方式，原本零散的對話資料會逐漸轉化為可重用的知識結構，使 Agent 能從歷史經驗中學習。

核心機制：Context Offloading + Mermaid 任務畫布

在長任務場景中，真正造成 Token 爆炸的往往是工具輸出與日誌。騰訊的解法主要包含兩個機制。

Context Offloading（上下文卸載）

當 Agent 呼叫工具（例如抓取網頁或執行程式）後：

• 完整輸出會存到外部儲存
• prompt 中只留下簡短摘要或引用

因此大量原始資料不再佔據上下文空間。

Mermaid 任務畫布

另一個關鍵設計是 Mermaid Task Canvas。

Mermaid 是一種文字式流程圖語言，常見於 GitHub 技術文件。騰訊利用它來建立 任務流程圖。

在這張畫布中：

• 節點代表任務步驟
• 邊表示依賴關係
• 每個節點只保留摘要或狀態

模型不需要閱讀完整歷史對話，而是透過這張「任務地圖」了解目前進度與下一步方向。

騰訊用一個簡單比喻說明差異：

日誌適合記錄一切，但導航需要的是地圖。

Mermaid 任務畫布就扮演這張地圖的角色。

根據上下文「水位」動態壓縮

TencentDB Agent Memory 會持續監控 prompt 使用量，並在不同水位觸發不同壓縮策略。

常見策略包括：

• L1 即時摘要：工具執行後立即生成高密度摘要
• L2 任務畫布更新：異步更新 Mermaid 任務圖
• L3 深度壓縮：當上下文使用量約達 80% 時壓縮或移除舊訊息

如果接近 95% 的臨界值，系統會觸發緊急壓縮，快速降低上下文負載。

騰訊公布的測試結果

騰訊在多個 benchmark 中報告了性能提升。不過這些數據來自廠商測試，尚未被廣泛獨立驗證。

WideSearch

• 通過率：33% → 50%
• Token 使用：221.31M → 85.64M（下降 61.38%）

SWE‑bench

• 成功率：58.4% → 64.2%
• Token 使用下降約 33%

AA‑LCR

• 成功率：44.0% → 47.5%
• Token 使用下降約 31%

PersonaMem

• 準確率約從 48% 提升至 76%。

騰訊也表示，在涵蓋 1540 個任務 的測試中（包括程式生成、搜尋與文件分析），任務完成率提升 12%–35%，Token 使用下降 33%–64%。

4 月發布與 5 月開源版本的差異

TencentDB Agent Memory 在 2026 年其實經歷了兩個階段。

4 月版本

• 推出長期記憶服務
• 引入四層記憶架構
• 主要解決跨 session 記憶問題

5 月 14 日開源版本

• 完整技術棧以 MIT License 開源
• 新增短期記憶壓縮機制
• 重點介紹 Context Offloading + Mermaid Task Canvas 架構

換句話說，早期版本重點在「記住過去」，而開源版本更強調「讓長任務不塞爆上下文」。

已支援的 Agent 框架

騰訊表示該系統已可整合到多個 Agent 架構中，例如：

• OpenClaw（可作為記憶插件）
• Hermes Gateway / Hermes Agent，支援 Docker 部署

這讓開發者能在現有 Agent 系統中加入記憶與壓縮能力，而不必重新設計整個架構。

為何這對 AI Agent 發展重要

隨著 AI Agent 從展示型 demo 走向實際應用，例如：

• 程式開發助理
• 研究與資訊搜尋
• 企業流程自動化

上下文成本（context economics） 正成為一個關鍵瓶頸。

每一次工具呼叫產生的內容，都可能讓 prompt 成本增加並干擾推理。

騰訊的做法試圖同時解決兩件事：

• 成本問題：減少 Token 使用量
• 可靠性問題：用結構化任務圖維持推理方向

如果這些效果在更多實際環境中得到驗證，像 TencentDB Agent Memory 這樣的記憶層，可能會成為未來 AI Agent 基礎架構的一部分。

目前來看，相關性能提升仍主要來自騰訊官方測試；未來是否能在不同模型與 Agent 框架中普遍成立，仍有待更多第三方實驗驗證。