TencentDB Agent Memory：符号化短期记忆+分层式长期记忆¶

Ch06.009 TencentDB Agent Memory：符号化短期记忆+分层式长期记忆¶

📊 Level ⭐⭐ | 17.8KB | entities/tencentdb-agent-memory-hierarchical.md

TencentDB Agent Memory：符号化短期记忆+分层式长期记忆¶

摘要¶

腾讯开源的 TencentDB Agent Memory，解决长程 Agent 的记忆管理问题。核心设计：短期记忆用压缩索引结构（非简单摘要）卸载工具日志，长期记忆用 L0-L3 语义金字塔（Conversation→Atom→Scenario→Persona）实现跨会话用户理解。WideSearch 成功率 +17pp，Token 降 61%。

现有方案的不足¶

传统 Agent Memory 方案普遍将历史对话切片后丢进向量库，靠相似度召回。这种方案能跑 Demo，但在长任务场景中暴露致命问题：

• 工具调用日志随着任务推进越来越长，上下文窗口迅速膨胀
• 搜索结果不断累积，形成信息泥潭
• 模型在大量过程性噪声中难以定位关键信息
• 多会话场景中，跨会话的记忆碎片化严重，无法形成连贯的用户理解

这些问题的根源在于：向量相似度检索只解决了"找什么"，但没有解决"记住什么"和"忘记什么"。Agent 记忆不仅仅是存储和检索，更关键的是遗忘策略——决定哪些信息值得长期保留，哪些可以丢弃。

短期记忆：压缩索引而非简单摘要¶

非简单摘要：简单摘要省 Token 但同时也丢失了关键证据。TencentDB 的设计是压缩索引（Compressed Index）结构：

• 厚重工具日志卸载到外部文件，不在上下文窗口中保留原始内容
• 中间层保留步骤摘要（JSONL 格式），以结构化方式记录关键操作
• 最高层只给 Agent 一张轻量任务图（Task Graph），用 DAG 表示任务进度
• Agent 平时只看任务结构，需要核对细节时再通过 ID 索引回到原始文件
• 高层保留结构，底层保留证据，中间靠唯一 ID 打通

关键区别：传统摘要压缩的是语义（Transform 到更短的表达），而压缩索引压缩的是访问路径（用指针替代内容）。前者可能导致信息失真（LLM 摘要可能遗漏关键细节），后者保留了完全的证据链，只是将其移出了立即关注的窗口。

这种设计在工程上相当于在 Token 消耗和证据保留之间找到了帕累托最优——在保证 Agent 可追证的前提下，将活跃 Token 消耗降低 50-70%。

长期记忆：L0-L3 语义金字塔¶

设计理念：所有历史平铺成向量碎片 → 语义金字塔。平时用 L3 理解用户，需要具体事实时回溯到 L1/L0。

这个金字塔结构解决的核心问题是 记忆的层次化访问：不是每次都需要全量记忆，而是根据任务需求从不同抽象层级获取信息。这与人类记忆系统的工作原理高度相似——我们不会在工作记忆中保留所有生活细节，而是根据当前任务提取最相关的记忆层级。

Benchmark 结果¶

数据分析：

• WideSearch（+17pp）：最需要记忆的 Benchmark，提升最大，说明分层结构对需要大量搜索和引用的场景帮助显著
• SWE-bench（+5.8pp）：提升较温和，因为代码修改任务对短期工作记忆的需求高于长期记忆
• PersonaMem（+28pp）：提升最显著，验证了 L3 Persona 层的有效性——分层结构使得用户画像记忆准确率大幅提升

值得注意的是，Token 消耗的大幅降低（-32% 到 -61%）是在同时提升成功率的前提下实现的——这是 Agent 记忆系统领域罕见的"帕累托改进"。

系统类比¶

TencentDB Agent Memory 更像一套分层文件系统：

• 上层：画像和任务图（类似文件系统的目录树）
• 中层：场景、步骤和索引（类似文件系统的 inode 表）
• 底层：原始证据（类似文件系统的数据块）
• 平时压缩，必要时展开
• 平时抽象，出问题时追证

深度分析¶

符号化 vs 向量化的权衡¶

TencentDB Agent Memory 的核心设计选择是符号化（Symbolic）记忆而非纯向量化内存。向量化记忆（如 Mem0、MemGPT）将所有信息转化为 embedding 后语义检索，优点是灵活（无需预定义结构），缺点是检索精度受 embedding 质量影响大，且难以支持精确事实查找。

TencentDB 选择了符号化路径：短期记忆用 JSONL 结构，长期记忆用金字塔层次，Persona 用结构化 Profile。符号化设计的优势在于： 1. 精确性：L1 Atom 是结构化事实，可以用精确查询而非语义近似检索 2. 可解释性：Each 记忆层级的结构和内容是可审计的，不像 embedding 碎片那样是黑盒 3. 组合性：不同层级的记忆可以基于 ID 组合和关联，形成更丰富的上下文

这种权衡使得 TencentDB 在需要精确记忆的场景（如 PersonaMem +28pp）上表现突出，但在高度语义化、非结构化的记忆场景中可能不如纯向量方案灵活。

"遗忘"作为记忆系统的一等公民¶

大多数 Agent 记忆系统只关注"如何记住"，而 TencentDB 通过分层结构巧妙地处理了"如何遗忘"：L0 数据随着时间自然沉降，不再被主动加载，而是退化到底层存储；L3 Persona 只有显著性信息才能持续存在。这种渐进式遗忘（Gradual Forgetting）机制使得 Agent 不会被长期运行的噪声信息淹没，同时保留了追证能力。

这与认知科学中的记忆固化（Memory Consolidation）理论高度一致：短期记忆中的信息通过反复激活，逐渐固化到长期记忆中，而不重要的细节被自然遗忘。TencentDB 的压缩索引结构在工程上实现了类似的机制。

Agent 记忆系统的三层评估框架¶

TencentDB 的 Benchmark 结果启示了一个 Agent 记忆系统的三层评估框架：

1. 效率层（Token 消耗）：记忆系统不能比无记忆系统消耗更多 token。TencentDB 的 -32% 到 -61% 通过了这一层。
2. 效果层（任务成功率）：记忆系统必须提升 Agent 的实际任务完成率。WideSearch +17pp、SWE-bench +5.8pp 通过了这一层。
3. 体验层（用户感知）：记忆系统必须让用户感觉 Agent 在"记住我"。PersonaMem +28pp 通过了这一层。

大多数 Agent 记忆方案只评估第一层和第二层，忽略了第三层的用户体验维度。PersonaMem 的大幅提升表明，TencentDB 的分层设计在用户体验上的价值可能被低估了。

实践启示¶

1. 优先采用压缩索引而非简单摘要：如果 Agent 的记忆面临 token 膨胀问题，不要简单地用 LLM 摘要来压缩历史。采用指针+索引的模式（将详细日志外存化，仅保留结构化的访问路径），可以在降低 token 消耗的同时保留完整的证据链。

2. 为 Agent 设计 Persona 层：大多数 Agent 记忆方案忽略了用户画像的持续学习。为 Agent 添加一个结构化用户 Profile（L3 Persona）并定期更新，可以显著提升用户体验。建议在每次会话结束后，提取用户的使用偏好、常见指令模式和工作方式，写入 Persona 层。

3. 用 Benchmark 分层验证记忆系统的有效性：不要只看总体的 Task Success Rate。分别测试记忆系统在搜索密集型任务（WideSearch）、代码修改任务（SWE-bench）、复杂指令遵循（AA-LCR）和用户画像记忆（PersonaMem）上的表现。不同任务类型对记忆系统的需求完全不同。

4. ID 打通是分层记忆的骨架：压缩索引和语义金字塔能否真正工作，关键在于各层之间的 ID 关联是否完整。确保每个记忆片段都有唯一 ID，且低层记录都被高层索引正确引用。没有 ID 链的分层记忆只是多个独立的存储桶。

5. 考虑 TencentDB Agent Memory 在生产中的适用性：如果你的 Agent 系统面临以下挑战，推荐评估 TencentDB Agent Memory：(1) 长程 Agent 任务（> 10 轮工具调用）(2) 多会话场景中需要跨会话用户理解 (3) Token 成本成为瓶颈。如果 Agent 任务主要为短对话（< 5 轮），则简单的上下文缓存可能已经足够。

治理框架：三路径、四对象与晋升边界（若飞拆解 2026-08）¶

若飞对 TencentDB Agent Memory 的架构级拆解，提供了 Datawhale 实测文未覆盖的独立治理框架（v=8/c=6/v×c=48 SUPP）：

三条路径速度分离¶

记忆系统的三个职责不在同一条时间线上，速度与失败方式各异：写入把当轮结果变成可追溯的候选记忆（原始证据先落盘，提炼异步晚完成）；读取按当前任务缩小范围、排序并控制注入（设延迟与上下文预算，拿不到时任务照常继续）；治理最慢，处理来源、冲突、权限与晋升。很多记忆系统的问题出在把三条路径揉成一次模型调用——写入返回成功 ≠ 结构化记忆已可查，召回一条相似记录 ≠ 它是当前有效值。

四种对象分类¶

「Agent 记忆」实际混着四类对象，不该共用一套写入/召回/修改规则：

Policy 要单独放出来：权限、合规、预算和审批属外部约束，Memory 可记录「某条规则在哪里见过」但不负责把临时处理改写成新许可；Policy 可引用 Memory，但不该被 Memory 自动改写。

晋升边界与冲突时间线¶

「一次有效」与「可靠经验」之间是一条晋升路径：影响范围越大，验证和治理责任越重。一次偶然成功（如把 CI 超时 30s 调成 90s 后测试变绿）最多是候选经验，没有复现、日志和回归验证不该自动变成团队默认流程。冲突处理（如 PostgreSQL→MySQL 切换）至少有三种可能（真改选型/不同项目/前后矛盾），仲裁模型只能判断已召回的候选，没被召回的旧记忆在判断里等于不存在。接入时应至少补齐 source、scope、status、valid_from、supersedes、evidence_ref 六个字段，保留旧记录和变更原因比静默覆盖更可审计。

四测试清单与五问框架¶

接入真实工作流前，若飞建议先跑四个测试（个人偏好+非敏感项目约束）：写入延迟（写入成功与可检索差多久）、召回质量（关键词/向量/混合各自的漏召回与误召回）、更新安全（能否区分历史值/当前值/被替代值）、故障降级（embedding 不可用或召回超时时对话是否继续）。另需检查保留策略——capture.l0l1RetentionDays 默认 0，L0/L1 本地文件不自动清理，长期运行会变成磁盘、隐私和合规问题。最后用一个五问清单验收：记忆来自哪里、经过几次提炼验证、为何本轮被召回、冲突时当前有效值是谁且谁有权修改、服务不可用或记错时如何继续与纠正。

安全边界：Gateway 默认无鉴权¶

Hermes 接入场景中，Gateway 把 capture、search、recall 暴露为 HTTP 接口，API Key 鉴权默认没配置——只在本机使用时应保持 loopback；一旦监听到非本机地址就要给服务端和客户端配同一把密钥；允许浏览器跨域访问时再单独收紧 CORS 白名单。「本地能跑」和「可以放进内网」之间还有这道门。

团队记忆维度（腾讯技术工程第一方实践，2026-08）¶

同产品从「个体记忆分层」扩展到「团队记忆治理」：当个体执行能力充裕，瓶颈转向跨成员/Session/分支/权限域的「协作带宽」。团队记忆定义为把真实任务中的背景/知识/代码关系/工作方法转为可检索/可组合/可追溯/可授权/可持续更新的 Agent 资产，后续按需装配；「完整属于资产池，相关属于当前任务」。

四类资产对应四种可继承状态：Chat Memory（背景/约束/决定，恢复任务状态）、Wiki（产品知识/架构/Runbook，稳定事实）、CodeGraph（符号/文件/调用/依赖，仓库结构与影响）、Skill（可复用方法/边界/验证，复用验证过的工作流）。资产跟着 Team 走而非跟着 Agent 走，框架中立从宿主解耦——只有从具体账号/会话/框架解耦，记忆才真正属于团队。

装配是分层过程而非扁平召回：内容分层 L0 Conversation→L1 Atom→L2 Scenario→L3 Core/Persona（高层减阅读量、低层防抽象失真）；路由分层五层（身份作用域→固定绑定→浮动召回→BM25+向量 RRF 融合→按角色/Token 预算装配 Memory Pack）；渐进式暴露让 Prompt 只告知「有什么」、工具调用在需要时取细节。

用「前序 Case 学习、后序 Case 验证」验证经验继承：2600 Session 切分 5081 Task，仅 231 条强关系（42 same_work_item/135 same_problem/54 reusable_sop）其余降为 related_context Shadow（关联≠复用≠可直接执行）；1350 逻辑返工远多于 269 缺少上下文，说明记忆不能只找资料还要保存决策理由/失败路径/适用条件/验证方式。SWE-bench 相关 Case 完成率 60%→80%（+20pp/+33.3%），超长难 50 例通过率 17%→20% 且成本 $887.64→$717.78（-19% turn）。

六条设计原则（继承状态/降低不确定性/抽象与证据并存/原子化按任务装配/生命周期/与框架解耦）+ 多人环境六类工程问题（冲突/新鲜度/权限/溯源/负反馈/成本）。团队记忆本质是治理系统，更像代码仓库需要版本/分支/权限/Review/合并/回滚。

相关实体¶

• Agent 记忆模块化框架
• Agent 夜间任务编排
• 注意力塌陷与上下文管理
• TencentDB Agent Memory 长期记忆金字塔
• Agent Harness 上下文管理工作集

来源¶

→ 原文存档 → 若飞拆解 2026-08 → 团队记忆实践 2026-08