夜雨聆风你的 Agent，每次都在从零认识你
用过 AI Agent 跑长任务的人，大概都经历过这种崩溃：
你跟 Agent 聊了三个小时，它帮你查了十几个文件，跑了二十几条命令，中间状态全记在上下文里。然后——上下文窗口满了。
要么对话被截断，Agent 忘掉前面做了什么；要么 token 烧到飞起，一个任务跑下来花费惊人。
更痛的场景是跨会话。今天你跟 Agent 说了"我习惯用 TypeScript，项目部署在 AWS，日志走 CloudWatch"，明天新开一个会话，它又问你一遍。
Agent 的记忆问题，已经从"能不能用"变成了"用多久就崩"。
腾讯最近开源的 TencentDB-Agent-Memory，就是冲着这个痛点来的。
▲ @BTCqzy1 在 X 上发帖介绍 TencentDB-Agent-Memory，获得 3.1 万次浏览
这个项目到底做了什么
TencentDB-Agent-Memory 的 GitHub README 开头有一句定位：
"TencentDB Agent Memory = symbolic short-term memory + layered long-term memory."
「TencentDB Agent Memory = 符号化短期记忆 + 分层长期记忆。」
翻译成大白话：它把 Agent 的记忆拆成两条链路——
短期链路，解决"长任务跑着跑着上下文就爆了"的问题。
长期链路，解决"换个会话 Agent 就失忆"的问题。
▲ Tencent/TencentDB-Agent-Memory GitHub 仓库，目前 2,600+ stars
这两条链路的技术思路完全不同，拆开讲。
短期记忆：把 verbose logs 卸载出去，上下文只留地图
Agent 跑长任务时，token 消耗最大的部分往往来自中间产物——搜索结果、代码文件、错误堆栈、API 返回值。这些东西占满上下文之后，Agent 的推理质量会快速下降。
TencentDB-Agent-Memory 的做法叫context offloading（上下文卸载）：
1. 完整的 tool logs 写入外部文件（`refs/*.md` 或 jsonl） 2. 上下文里只保留一张Mermaid 任务画布，标记每个任务节点的状态 3. Agent 需要回看细节时，通过 `node_id` / `result_ref` 定位到原始文件
关键在于：这套压缩可以反向展开。从顶层的 Mermaid 符号，到中间层的索引，再到底层的原始文本，每一步都有确定性路径。
README 原话：
"The biggest risk in compression is saving tokens at the cost of losing the evidence."
「压缩最大的风险，是为了省 token 而丢掉证据。」
所以整个短期记忆的设计原则是：压缩可以做，但必须能追溯回原始数据。
长期记忆：L0 → L1 → L2 → L3，从对话到用户画像
长期记忆部分才是项目名字里"四层"的由来。
传统的 Agent 记忆系统怎么做？多数是把历史对话切成碎片，扔进向量数据库，检索时做相似度搜索。README 对此的评价相当直接：
"Traditional memory systems shred data into fragments and dump them into a flat vector store."
「传统记忆系统把数据切碎，扔进扁平的向量存储。」
TencentDB-Agent-Memory 用了一个四层金字塔结构：
- L0 Conversation
：原始对话记录，完整保留 - L1 Atom
：从对话中提取的原子事实（比如"用户偏好 TypeScript""项目用 AWS 部署"） - L2 Scenario
：把相关的原子事实聚合成场景块（比如"用户的后端开发环境配置"） - L3 Persona
：长期用户画像，包括偏好、习惯、目标
"Lower layers preserve evidence; upper layers preserve structure."
「下层保存证据，上层保存结构。」
实际使用时，Agent 查询日常偏好和长期目标，优先看 L3 Persona 和 L2 Scenario；需要具体事实、日期、项目细节时，再 drill down 到 L1 Atom 和 L0 Conversation。
这个设计的好处在于：Agent 按需取用不同粒度的记忆，而不用每次都把全部历史塞回 prompt。
▲ README 中的 Highlights 区域和 benchmark 指标表
数据怎么样？项目方给了三组 benchmark
先看前提——这些数据来自项目方 README，在连续长任务会话中测得。
README 特别标注：
"These results are measured over continuous long-horizon sessions, not isolated turns."
「这些结果在连续长任务会话中测得，不针对单轮问答。」
三组 benchmark 的核心数据：
WideSearch（OpenClaw 集成）：token 从 221.31M 降到 85.64M，降幅 61.38%；任务成功率从 33% 到 50%，相对提升 51.52%。
SWE-bench：token 从 3,474.1M 降到 2,375.4M，降幅 33.09%；成功率从 58.4% 到 64.2%，提升 9.93%。SWE-bench 的测试设置是每个 session 连续跑 50 个任务，模拟上下文堆积压力。
AA-LCR：token 从 112.0M 降到 77.3M，降幅 30.98%；成功率从 44.0% 到 47.5%。
此外还有一个PersonaMem准确率测试：从 48% 提升到 76%，衡量的是跨会话记住用户偏好的能力。
要注意的是：最高的 61.38% 降幅来自 WideSearch 这一个 benchmark，其他场景的降幅在 30%~33% 之间。标题里说的"直降 61%"指的是特定条件下的最优值。
怎么装？OpenClaw 一行命令，Hermes 走 Docker
项目目前提供两条集成路径：
OpenClaw：直接装插件——
``` openclaw plugins install @tencentdb-agent-memory/memory-tencentdb ```
默认后端是本地SQLite + sqlite-vec，不需要外部数据库。短期记忆的 compression/offload 功能需要 ≥ 0.3.4 版本。
Hermes：提供 `Dockerfile.hermes`，构建后运行 memory-enabled Hermes Gateway。默认模型配置示例指向 Tencent Cloud LKE / DeepSeek-V3.2，也支持 OpenAI 兼容的自定义 provider。
npm 包名 `@tencentdb-agent-memory/memory-tencentdb`，当前最新版本 0.3.5，MIT 协议。
▲ npm 上的包页面，版本 0.3.5，MIT 协议
社区怎么看？有肯定，也有真问题
X 上有开发者问"长任务场景下 token 省得明显吗"，原帖作者回复"具体数据官方那边的比较更准确一点"——社交帖里的"61%"更多是 headline 数字，具体效果要看场景和任务类型。
也有用户提出信息私密性的担忧。原帖作者承认"这个担心很合理"。TencentDB-Agent-Memory 虽然支持本地部署、零外部 API 依赖，但记忆系统天然涉及长期偏好、历史经验、工作习惯的存储——隐私治理仍然取决于具体的部署方式、数据目录策略和权限边界。
GitHub Issues 里的反馈更直接。开发者报告了 offload model parsing、sanitizeText 对 non-BMP/CJK/emoji 字符的处理问题、L1 memory search scope 的边界 bug。30 个 open issues 说明项目处于活跃迭代中，能用，但离"开箱即用的生产基础设施"还有距离。
但更深层的问题在于：四层结构提供了组织方式，可模型凭什么决定哪些对话升格成 L1？记忆抽取的阈值怎么定、重复信息怎么去重、矛盾记忆怎么处理、召回策略怎么平衡精度和开销——这些才是决定实际效果的关键变量。
▲ CnTechPost 报道：Tencent open-sources Agent Memory to cut AI token consumption by 61%
还差什么？Roadmap 里有几个大项
翻一下 README 的 Roadmap，几个明确还没做完的事：
- Portable memory
：跨 Agent / 跨框架 / 跨设备的记忆导入导出和实时迁移 - Automatic skill generation
：从记忆中自动生成 Agent 技能 - Visual debugging / observability dashboard
：可视化调试面板
目前 TencentDB-Agent-Memory 的适用范围主要在 OpenClaw 和 Hermes 生态。如果你用的是 LangChain、AutoGen 或其他框架，短期内还没有官方适配。
回到这件事本身
Agent 的记忆问题，过去一年里从"nice to have"变成了必须解决的工程瓶颈。Agent 越来越多地被用于长任务——连续几十个 SWE-bench 问题、多步骤代码重构、跨天项目管理——上下文窗口和跨会话记忆已经变成实打实的成本和质量问题。
TencentDB-Agent-Memory 给出的方案是：把 Agent 记忆拆成可追溯的两条链路。短期用符号化画布 + 上下文卸载，压缩中间产物但保留回溯路径；长期用 L0→L3 四层金字塔，把碎片化对话蒸馏成可检索的结构化知识。
项目方在 WideSearch 上给出了 61.38% 的 token 降幅，在 SWE-bench 上是 33%，PersonaMem 准确率从 48% 到 76%。前提是连续长任务会话，单轮场景下收益会小得多。
GitHub 上 2,600+ stars，npm 版本 0.3.5，MIT 协议，本地 SQLite 部署。项目还在早期——30 个 open issues、roadmap 里的跨框架迁移和可视化面板都还没做——但作为把 Agent 记忆从"聊天记录仓库"推向"可审计状态层"的一个工程实践，已经值得长任务场景的开发者试一试了。
GitHub 仓库：https://github.com/Tencent/TencentDB-Agent-Memory
— END —
