范围与证据本文引用的事实来自以下可公开核验的来源项目 READMEEnglish / 简体中文与仓库文件结构、提交记录、版本提交信息init 于 2026-04-09截至抓取时 103 次提交、3 个分支、10 个 tag。版本线v0.2.22026-05-13TCVDB 后端 BM25 混合检索、v0.3.32026-05-13Hermes 适配器 上下文卸载、v0.3.52026-05-20、v0.3.62026-05-28短期压缩offload需 ≥0.3.4。近期活跃2026-07-17 合并 Windows 原生支持#151、补充 memory-tencentdb recovery 测试2026-07-19 更新 README#535。测试数据来自 README 的 Highlights 表方法论为连续长程会话测量非孤立单轮SWE-bench 每会话连续 50 个任务。我未引用无法核验的指标如精确 star 数——查不到就不写、不画。长程 Agent 的上下文为什么会失控失控的根源不是记不住而是记太多且不分层。传统记忆系统把数据切成碎片倒进扁平向量库召回退化成在互不相干的碎片里盲搜既没有宏观引导也无法把该记的偏好和该归档的日志区分开。TencentDB Agent Memory 把记忆拆成两根支柱分层记忆layering负责渐进式披露符号化记忆symbolic memory负责用最少符号承载最多语义。二者要解决的是同一个工程问题让 Agent 在长任务里只关注顶层结构出错时再沿确定路径下钻到原始证据。设计支柱一分层记忆拒绝扁平存储分层记忆的核心是形成与召回都分层并配合异构存储。短期上下文分层任务内底层归档原始工具输出refs/*.md中层抽取步骤级摘要jsonl顶层把状态浓缩成一张轻量 Mermaid 画布。Agent 平时只看顶层结构出错时再沿node_id下钻到下层。长期个性化分层跨会话用语义金字塔替代扁平日志——L0 Conversation原始对话→L1 Atom原子事实→L2 Scenario场景块→L3 Persona用户画像。画像层承载日常偏好只在需要细节时才下钻到原子层。技能生成分层动作侧同样按层组织从中层执行轨迹Conversation归纳常见解决模式Scenario顶层再蒸馏成可复用 Skill 或标准 SOPPersona。图 1TencentDB Agent Memory 的分层记忆架构示意图。左侧为长期记忆 L0→L3 语义金字塔右侧为短期上下文三层结构底部为异构存储策略。根据项目 README 整理。这套分层由异构存储 渐进式披露托底底层事实、日志、trace入库支持全文检索顶层画像、场景、画布存为人类可读的 Markdown便于白盒审计。README 用一句话概括设计意图——下层保留证据上层保留结构。压缩因此不等于丢可追溯性从顶层符号Persona / 画布→ 中层索引Scenario / jsonl→ 底层原始文本L0 Conversation / refs存在一条确定性的回钻路径。设计支柱二符号化记忆用 Mermaid 画布承载状态长任务里最吃 token 的不是提示词而是冗长的中间日志。符号化记忆把上下文卸载和符号化组合起来Mermaid 符号图用高密度 Mermaid 语法编码任务状态转移——LLM 能解析人类也能读比散文或扁平 JSON 更紧凑。历史卸载全量工具日志落到外部文件上下文里只留一张轻量任务图。node_id回溯Agent 在符号图上推理要核对某个细节就按node_id取回原始全文。图 2符号化记忆的四步压缩流程示意图卸载全文 → 抽取关系 → 轻量注入 → 按 node_id 回溯。根据项目 README 整理。这个流程的价值在于省 token 但不丢证据上下文从数十万 token 压到几百 token需要时仍能精确取回某一步的原始日志。它针对的是信息过载而非知识遗忘因此和长期记忆分层互补——一个管任务内一个管跨会话。项目方公布的测试数据怎么看README 在 Highlights 给出的一组对比是理解这套设计收益的最直接证据但必须带着方法论去读。下表数字与本文配图、assets/benchmark.json完全一致均为项目方自测OpenClaw 基线 vs 启用插件非本文复现。记忆类型BenchmarkOpenClaw 通过率启用插件相对变化OpenClaw Token启用插件 TokenToken 相对变化短期WideSearch33%50%51.52%221.31M85.64M−61.38%短期SWE-bench58.4%64.2%9.93%3474.1M2375.4M−33.09%短期AA-LCR44.0%47.5%7.95%112.0M77.3M−30.98%长期PersonaMem48%76%59%———图 3项目方公布的测试数据示意图/数据图。左为通过率/准确率右为累计 Token 用量。数据来源项目 README连续长程会话测量非本文独立复现。读这组数据有三个要点。第一token 是累计而非单次例如 SWE-bench 的 3474.1M 是一个连续长程会话的累计消耗不是单次查询所以它衡量的是长程压力下的累积节流不能当成单条请求的提速比。第二收益与任务结构相关WideSearch 的相对提升51.52% 通过率、−61.38% token最显眼但它本身就是上下文爆炸型任务SWE-bench、AA-LCR 的绝对通过率本就更高相对提升空间有限9.93%、7.95%却仍有 30% 上下的 token 节流——这说明符号化卸载在通过率难大涨的任务里主要价值是省预算而非提准确率。第三长期记忆是另一条曲线PersonaMem 从 48% 升到 76%59% 相对但没有 token 列——长期记忆的收益体现在个性化准确度不在短期 token 账上。安装与启用可复现命令以下命令来自 README 的 Quick Start适合在 OpenClaw 或 Hermes 中启用。默认后端是本地的SQLite sqlite-vec零配置即可起步。OpenClaw 插件安装与零配置启用openclaw plugins install tencentdb-agent-memory/memory-tencentdb openclaw gateway restart// ~/.openclaw/openclaw.json { memory-tencentdb: { enabled: true } }启用后插件会自动处理对话捕获、记忆抽取、场景聚合、画像生成与下一轮回前召回。升级建议用 OpenClaw 原生命令避免语义版本范围导致插件被禁用openclaw plugins update tencentdb-agent-memory/memory-tencentdb短期压缩可选需 ≥0.3.4先在配置里注册 contextEngine 插槽再打一次运行时补丁把after-tool-call消息接入卸载与恢复流程。{ memory-tencentdb: { config: { offload: { enabled: true } } }, plugins: { slots: { contextEngine: memory-tencentdb } } }bash scripts/openclaw-after-tool-call-messages.patch.shHermes 一键 Docker≥0.3.4镜像内置hermes-agent与memory_tencentdb提供者Gateway 监听:8420默认走腾讯云 LKE 的 DeepSeek-V3.2。cd docker/opensource docker build -f Dockerfile.hermes -t hermes-memory . docker run -d --name hermes-memory --restart unless-stopped \ -p 8420:8420 \ -e MODEL_API_KEYyour-api-key \ -e MODEL_BASE_URLhttps://api.lkeap.cloud.tencent.com/v1 \ -e MODEL_NAMEdeepseek-v3.2 \ -e MODEL_PROVIDERcustom \ -v hermes_data:/opt/data \ hermes-memory curl http://localhost:8420/health如果已在本机装好hermes-agent、只想加记忆能力则不必用 Docker用 npm 拉插件包到统一目录即可README 的 2.B 小节给出了具体步骤。需要注意Hermes Docker 默认调用云端 DeepSeek-V3.2需要 API Key 且可能产生费用它不是本地模型推理方案。限制与适用边界为避免过度解读把边界说清楚数据非独立复现所有 benchmark 数字都是项目方自测OpenClaw 基线 vs 启用插件我未在本文中独立运行验证不同模型、不同任务分布下结果可能不同。生态绑定插件面向 OpenClaw 与 HermesNousResearch/hermes-agent设计脱离这两个宿主的运行时需要自行适配插件接口。Windows 支持刚落地Windows 原生支持是 2026-07-17 合并的good first issue#151尚属新增使用前建议核对最新状态。短期压缩有额外步骤offload 需 ≥0.3.4 并打一次运行时补丁不是开启即生效升级 OpenClaw 后需重新打补丁。仓库年轻init 于 2026-04-09截至抓取约 103 次提交API 与行为可能调整引用版本号时建议同时记录 commit。token 为累计值表中的 M 级 token 是长程会话累计消耗不能当作单次请求的提速比或成本。结论与项目链接TencentDB Agent Memory 的可迁移思路不在某个具体数字而在两个工程判断其一记忆要分层 异构存储上层保结构、下层保证据压缩与可追溯不必二选一其二长任务里最该符号化的是冗长中间日志用 Mermaid 画布加node_id回溯可以在上下文只留几百 token和随时取回原始全文之间取得平衡。项目方公布的数据显示这种取舍在上下文爆炸型任务上收益最大WideSearch token −61.38%、通过率 51.52% 相对而在通过率本就高的任务上主要省预算。如果你在做长程 Agent 并被上下文体积卡住值得按文中的命令在 OpenClaw 或 Hermes 里试跑再用自己任务的累计 token 与通过率做对照——那会比任何公开榜单都更可信。项目地址github.com/TencentCloud/TencentDB-Agent-Memory。
范围与证据本文引用的事实来自以下可公开核验的来源项目 READMEEnglish / 简体中文与仓库文件结构、提交记录、版本提交信息init 于 2026-04-09截至抓取时 103 次提交、3 个分支、10 个 tag。版本线v0.2.22026-05-13TCVDB 后端 BM25 混合检索、v0.3.32026-05-13Hermes 适配器 上下文卸载、v0.3.52026-05-20、v0.3.62026-05-28短期压缩offload需 ≥0.3.4。近期活跃2026-07-17 合并 Windows 原生支持#151、补充 memory-tencentdb recovery 测试2026-07-19 更新 README#535。测试数据来自 README 的 Highlights 表方法论为连续长程会话测量非孤立单轮SWE-bench 每会话连续 50 个任务。我未引用无法核验的指标如精确 star 数——查不到就不写、不画。长程 Agent 的上下文为什么会失控失控的根源不是记不住而是记太多且不分层。传统记忆系统把数据切成碎片倒进扁平向量库召回退化成在互不相干的碎片里盲搜既没有宏观引导也无法把该记的偏好和该归档的日志区分开。TencentDB Agent Memory 把记忆拆成两根支柱分层记忆layering负责渐进式披露符号化记忆symbolic memory负责用最少符号承载最多语义。二者要解决的是同一个工程问题让 Agent 在长任务里只关注顶层结构出错时再沿确定路径下钻到原始证据。设计支柱一分层记忆拒绝扁平存储分层记忆的核心是形成与召回都分层并配合异构存储。短期上下文分层任务内底层归档原始工具输出refs/*.md中层抽取步骤级摘要jsonl顶层把状态浓缩成一张轻量 Mermaid 画布。Agent 平时只看顶层结构出错时再沿node_id下钻到下层。长期个性化分层跨会话用语义金字塔替代扁平日志——L0 Conversation原始对话→L1 Atom原子事实→L2 Scenario场景块→L3 Persona用户画像。画像层承载日常偏好只在需要细节时才下钻到原子层。技能生成分层动作侧同样按层组织从中层执行轨迹Conversation归纳常见解决模式Scenario顶层再蒸馏成可复用 Skill 或标准 SOPPersona。图 1TencentDB Agent Memory 的分层记忆架构示意图。左侧为长期记忆 L0→L3 语义金字塔右侧为短期上下文三层结构底部为异构存储策略。根据项目 README 整理。这套分层由异构存储 渐进式披露托底底层事实、日志、trace入库支持全文检索顶层画像、场景、画布存为人类可读的 Markdown便于白盒审计。README 用一句话概括设计意图——下层保留证据上层保留结构。压缩因此不等于丢可追溯性从顶层符号Persona / 画布→ 中层索引Scenario / jsonl→ 底层原始文本L0 Conversation / refs存在一条确定性的回钻路径。设计支柱二符号化记忆用 Mermaid 画布承载状态长任务里最吃 token 的不是提示词而是冗长的中间日志。符号化记忆把上下文卸载和符号化组合起来Mermaid 符号图用高密度 Mermaid 语法编码任务状态转移——LLM 能解析人类也能读比散文或扁平 JSON 更紧凑。历史卸载全量工具日志落到外部文件上下文里只留一张轻量任务图。node_id回溯Agent 在符号图上推理要核对某个细节就按node_id取回原始全文。图 2符号化记忆的四步压缩流程示意图卸载全文 → 抽取关系 → 轻量注入 → 按 node_id 回溯。根据项目 README 整理。这个流程的价值在于省 token 但不丢证据上下文从数十万 token 压到几百 token需要时仍能精确取回某一步的原始日志。它针对的是信息过载而非知识遗忘因此和长期记忆分层互补——一个管任务内一个管跨会话。项目方公布的测试数据怎么看README 在 Highlights 给出的一组对比是理解这套设计收益的最直接证据但必须带着方法论去读。下表数字与本文配图、assets/benchmark.json完全一致均为项目方自测OpenClaw 基线 vs 启用插件非本文复现。记忆类型BenchmarkOpenClaw 通过率启用插件相对变化OpenClaw Token启用插件 TokenToken 相对变化短期WideSearch33%50%51.52%221.31M85.64M−61.38%短期SWE-bench58.4%64.2%9.93%3474.1M2375.4M−33.09%短期AA-LCR44.0%47.5%7.95%112.0M77.3M−30.98%长期PersonaMem48%76%59%———图 3项目方公布的测试数据示意图/数据图。左为通过率/准确率右为累计 Token 用量。数据来源项目 README连续长程会话测量非本文独立复现。读这组数据有三个要点。第一token 是累计而非单次例如 SWE-bench 的 3474.1M 是一个连续长程会话的累计消耗不是单次查询所以它衡量的是长程压力下的累积节流不能当成单条请求的提速比。第二收益与任务结构相关WideSearch 的相对提升51.52% 通过率、−61.38% token最显眼但它本身就是上下文爆炸型任务SWE-bench、AA-LCR 的绝对通过率本就更高相对提升空间有限9.93%、7.95%却仍有 30% 上下的 token 节流——这说明符号化卸载在通过率难大涨的任务里主要价值是省预算而非提准确率。第三长期记忆是另一条曲线PersonaMem 从 48% 升到 76%59% 相对但没有 token 列——长期记忆的收益体现在个性化准确度不在短期 token 账上。安装与启用可复现命令以下命令来自 README 的 Quick Start适合在 OpenClaw 或 Hermes 中启用。默认后端是本地的SQLite sqlite-vec零配置即可起步。OpenClaw 插件安装与零配置启用openclaw plugins install tencentdb-agent-memory/memory-tencentdb openclaw gateway restart// ~/.openclaw/openclaw.json { memory-tencentdb: { enabled: true } }启用后插件会自动处理对话捕获、记忆抽取、场景聚合、画像生成与下一轮回前召回。升级建议用 OpenClaw 原生命令避免语义版本范围导致插件被禁用openclaw plugins update tencentdb-agent-memory/memory-tencentdb短期压缩可选需 ≥0.3.4先在配置里注册 contextEngine 插槽再打一次运行时补丁把after-tool-call消息接入卸载与恢复流程。{ memory-tencentdb: { config: { offload: { enabled: true } } }, plugins: { slots: { contextEngine: memory-tencentdb } } }bash scripts/openclaw-after-tool-call-messages.patch.shHermes 一键 Docker≥0.3.4镜像内置hermes-agent与memory_tencentdb提供者Gateway 监听:8420默认走腾讯云 LKE 的 DeepSeek-V3.2。cd docker/opensource docker build -f Dockerfile.hermes -t hermes-memory . docker run -d --name hermes-memory --restart unless-stopped \ -p 8420:8420 \ -e MODEL_API_KEYyour-api-key \ -e MODEL_BASE_URLhttps://api.lkeap.cloud.tencent.com/v1 \ -e MODEL_NAMEdeepseek-v3.2 \ -e MODEL_PROVIDERcustom \ -v hermes_data:/opt/data \ hermes-memory curl http://localhost:8420/health如果已在本机装好hermes-agent、只想加记忆能力则不必用 Docker用 npm 拉插件包到统一目录即可README 的 2.B 小节给出了具体步骤。需要注意Hermes Docker 默认调用云端 DeepSeek-V3.2需要 API Key 且可能产生费用它不是本地模型推理方案。限制与适用边界为避免过度解读把边界说清楚数据非独立复现所有 benchmark 数字都是项目方自测OpenClaw 基线 vs 启用插件我未在本文中独立运行验证不同模型、不同任务分布下结果可能不同。生态绑定插件面向 OpenClaw 与 HermesNousResearch/hermes-agent设计脱离这两个宿主的运行时需要自行适配插件接口。Windows 支持刚落地Windows 原生支持是 2026-07-17 合并的good first issue#151尚属新增使用前建议核对最新状态。短期压缩有额外步骤offload 需 ≥0.3.4 并打一次运行时补丁不是开启即生效升级 OpenClaw 后需重新打补丁。仓库年轻init 于 2026-04-09截至抓取约 103 次提交API 与行为可能调整引用版本号时建议同时记录 commit。token 为累计值表中的 M 级 token 是长程会话累计消耗不能当作单次请求的提速比或成本。结论与项目链接TencentDB Agent Memory 的可迁移思路不在某个具体数字而在两个工程判断其一记忆要分层 异构存储上层保结构、下层保证据压缩与可追溯不必二选一其二长任务里最该符号化的是冗长中间日志用 Mermaid 画布加node_id回溯可以在上下文只留几百 token和随时取回原始全文之间取得平衡。项目方公布的数据显示这种取舍在上下文爆炸型任务上收益最大WideSearch token −61.38%、通过率 51.52% 相对而在通过率本就高的任务上主要省预算。如果你在做长程 Agent 并被上下文体积卡住值得按文中的命令在 OpenClaw 或 Hermes 里试跑再用自己任务的累计 token 与通过率做对照——那会比任何公开榜单都更可信。项目地址github.com/TencentCloud/TencentDB-Agent-Memory。
从空模型到随机斜率的完整实操指南)
