TencentDB Agent Memory:构建团队可治理的Agent长期记忆系统

当前的智能代理(Agent)虽然能够完成越来越复杂的任务,但普遍存在“完成即遗忘”的问题:切换对话会话后需要重新复述项目背景,更换代理时又要重新阅读全部文档,哪怕已经验证过的排障方法,下次执行时仍可能重复摸索。这款名为Agent Memory的开源工具,正是为了解决这类重复投入的上下文成本问题而设计的。
截至2026年8月8日,该项目的GitHub仓库已经获得了18009个Star和1613个Fork,当前默认开发分支为feat/server_team,主线版本正在推进Team Memory的测试版更新。这意味着它不仅仅是一个简单的聊天记忆插件,更准确的定位是面向Agent团队的记忆中枢(Memory Hub),能够将对话、任务、文档和代码沉淀为可治理、可共享、可配装的记忆资产。
这款工具的设计不仅仅关注“存储了哪些内容”,更着重解决三个更具挑战性的问题:如何筛选有价值的信息而非将全部上下文塞入提示词、如何划分使用权限确保敏感内容不被随意访问、如何让后续任务快速获取必要信息同时避免记忆占用过多上下文窗口。
核心资产体系:从零散记录到团队资产
它通过Memory Asset(记忆资产)模型统一管理这些问题,目前支持四类核心资产:
- 对话记忆(Chat Memory):来源于历史对话与交互,用于记录用户偏好、事实信息、约束条件、决策过程和长期用户画像
- 技能库(Skill):来源于已完成的任务与工具调用流程,能够将可复用的操作沉淀为带有边界说明、执行步骤和验证规则的标准化技能
- 知识库(LLM-Wiki):来源于产品文档、设计方案和运维资料,可生成结构化页面与链接图谱,方便快速搜索和深度下钻
- 代码图谱(CodeGraph):来源于代码仓库,能够索引文件、符号、调用关系和影响路径
与传统记忆系统只关注向量检索不同,这套体系的关键变化在于:记忆不再只是某次对话附带的一段文本,而是带有归属者、版本、状态、可见性和绑定关系的团队共享资产。
对话记忆:分层提炼而非原样保存
对话原文虽然重要,但直接保存全部对话并不等于真正可用:几十轮的完整对话会快速消耗上下文窗口,还容易让旧信息与当前任务产生干扰。因此项目将对话记忆分为四层处理:
- L0 Conversation:保存原始对话与完整上下文,用于核对原话、时间和信息来源
- L1 Atom:存储事实、偏好、约束与具体事件,用于精准召回可直接使用的信息
- L2 Scenario:围绕特定项目或场景组织的知识块,用于快速恢复工作场景
- L3 Core / Persona:记录长期画像、稳定模式与高层认知,帮助代理快速融入用户与团队语境
在召回记忆时,系统会结合BM25算法、向量检索和倒数排名融合(RRF)多种方式,同时通过条数限制、字符预算和超时机制避免记忆过载影响任务执行。日常工作中优先使用L2和L3层快速恢复语境,需要具体事实证据时再回溯L1和L0层的原始数据。
技能库:将单次成功转化为团队复用经验
与对话记忆记录“发生过什么”不同,技能库回答的是“这件事应该怎么做”。当代理完成排障、代码评审、上线检查等复杂任务后,可以从对话和工具调用记录中提炼出Skill。这类技能不仅仅是一段提示词,还可以包含版本信息、关联资源文件、触发边界条件、详细执行步骤和验证规则。
个人创建的Skill默认仅自己可见,经过审核后可以分享给团队,再配装给其他代理使用,这让“某个代理偶然完成的一次成功任务”能够转化为团队全体都可以稳定复用的标准化操作。这里有一个实用的划分边界:偏好、事实、决策和历史交互适合存入Chat Memory,而已验证的操作路径、检查清单和执行标准则适合存入Skill,不应将所有经验都压缩为一条模糊的长期记忆。
知识库与代码图谱:按需加载而非全量导入
当代理面对新项目时,最耗时的操作之一就是从目录和长文档的第一页开始重新阅读。这款工具通过两种资产缩短这一准备过程:
LLM-Wiki会将文档整理为结构化页面和链接图谱,代理可以先搜索相关主题,再沿页面关系逐步下钻,无需将整份知识库一次性加载到上下文窗口中;CodeGraph则针对代码结构建立索引,覆盖文件、符号、调用关系和影响路径,不仅能回答“代码在哪里”,还能支持调用者、被调用者分析和变更影响分析。
在工具调用层面,代理可以先通过相关接口发现可用能力,再读取对应的页面、源码或影响路径。文档和代码平时作为可查询的静态资产,只有在任务真正需要时才会被加载到上下文窗口中。
Memory Hub:从有记忆到能治理
四类记忆资产最终都会汇总到Memory Hub中,这里既是管理面板也是团队记忆的控制界面。在Hub中可以创建团队和代理,管理记忆资产的归属者、版本、状态、可见性、使用次数,并将资产与代理进行绑定。
权限主要分为三种语义:私有(仅资产所有者可读,团队管理员也无法直接访问)、团队可见(团队成员均可读取,由所有者或管理员管理)、受限授权(通过用户、角色或代理ACL进行精确权限控制)。系统的角色分为两层:全局系统管理员负责用户与团队的整体管理,团队内部再分为管理员和普通成员,处理团队内的协作与权限分配。资产的所有者标记会自动赋予对应的管理权限。
项目通过固定绑定加ACL的方式为代理配置专属的记忆配装(Loadout):先通过团队、用户、代理和可见性范围缩小可访问的资产池,再结合当前任务需求进行精准召回。不同的代理可以携带不同的“记忆背包”工作,例如市场调研代理可以获取市场研究Wiki、访谈记忆和竞品分析Skill,开发代理可以获取产品Wiki、项目CodeGraph和交付Skill,评审代理则可以获取事故记录、CodeGraph和发布检查Skill。
共享经验不等于共享全部上下文,优秀的记忆系统需要同时做到会记录、会筛选、会分配。
完整循环:从沉淀到复用的全流程
从单次任务到后续复用,完整的记忆循环可以分为六个步骤:
- 代理完成对话或任务,生成原始交互、执行结果和工具调用记录
- 对话通过异步流水线从L0层向L1、L2、L3层进行分层提炼
- 已验证的可行方法被整理为Skill,文档和代码分别构建LLM-Wiki和CodeGraph
- 团队成员在Memory Hub中审核资产,设置归属者、版本、状态和可见性
- 通过绑定和ACL为不同代理配置专属的记忆配装
- 新任务启动时,代理根据身份和任务需求检索必要资产,并将新的有效经验继续沉淀到记忆系统中
这套记忆系统的核心价值并非替代理执行任务,而是让下一轮任务能够继承上一轮的成果。没有记忆的循环只是更快地重复劳动,能够继承经验的循环才能让每一次任务都有所提升。
技术架构:三个组件与四层体系
项目提供一键部署的三个核心组件:memory-core负责承载记忆资产、处理流水线、检索功能和工具接口等核心能力;memory-hub提供团队、代理、资产、绑定关系、权限和处理状态的可视化操作界面;proxy作为接入链路的一部分,配合不同的代理与模型配置工作。
从整体架构来看,系统可以分为四层:
- 接入层:负责对接OpenClaw、Hermes、Claude Code、CodeBuddy等工具与SDK
- 资产生产层:负责对话分层沉淀、Skill提炼、Wiki导入和CodeGraph同步
- 治理层:负责记忆资产、所有者、版本、状态、可见性、绑定关系和ACL权限管理
- 消费层:则根据代理身份和任务需求进行检索、工具调用和上下文装配
这套架构的核心并非存储所有信息,而是建立一条可治理的经验供应链,确保信息来源可追溯、资产可审核、权限可收紧、代理可按需取用。
冷启动:从已有资产快速搭建团队记忆
项目支持从已有资源快速启动团队记忆:可以导入代码仓库,由CodeGraph建立符号、文件和调用关系索引;可以导入文档和文件,由LLM-Wiki生成结构化页面与链接关系;还可以导入过往的Agent对话会话,提取Chat Memory和可复用的Skill。这对于长期项目尤其有价值,团队无需等待新代理通过多轮对话重新熟悉项目,而是可以直接为其配置经过筛选的资产,再开始执行任务。
基准测试与效果参考
项目公布的PersonaMem基准测试结果显示,未启用记忆系统时的准确率为48%,启用后提升至76%,相对提升幅度达到59%。PersonaMem用于检验代理在长期交互后能否正确理解并运用用户信息,这一结果说明分层记忆与召回机制具有显著潜力,但需要注意的是这只是项目方公布的测试结果,实际生产环境中的效果会受到模型性能、数据质量、记忆质量、召回预算和任务类型的影响,建议使用自有会话和任务进行回归验证。
适用场景与限制条件
这款工具更适合以下场景:多个代理围绕同一项目长期协作的团队;拥有大量文档、代码和历史对话需要复用的团队;需要对经验进行审核、版本管理和权限隔离的团队;希望跨代理或跨框架迁移记忆资产的团队;哪怕是单人团队,也可以为不同角色的代理配置专属的记忆配装。
如果只是一次性问答、短周期任务,或者没有可复用的经验,完整Memory Hub的部署和治理成本可能并不划算,此时更轻量的会话记忆或项目说明文件会更加简单。
当前的测试版还存在一些限制:Wiki和CodeGraph为异步构建,需要等待处理状态变为ready;CodeGraph目前优先支持公开HTTPS仓库,私有仓库和SSH凭证的支持仍在完善;Hub目前仅支持人工绑定,自动记忆路由功能仍在迭代;目前仅支持OpenClaw、Hermes、Claude Code、CodeBuddy和SDK接入,更广泛的跨框架迁移仍在 roadmap中;默认开发分支处于快速迭代阶段,部署到关键环境前应固定版本,并为资产和配置准备备份。
快速安装指南
项目要求Node.js版本不低于22.16。一键部署会拉起memory-core、memory-hub和proxy三个组件,具体步骤如下:
git clone https://github.com/Tencent/TencentDB-Agent-Memory.git cd TencentDB-Agent-Memory/deploy/global-images cp .env.example .env $EDITOR .env ./start-all.sh
需要在.env文件中配置memory与proxy两组LLM参数。启动完成后,访问http://localhost:8125即可进入管理面板。如果已有v1.x或v0.x版本的数据,需要先按照项目提供的v2到v3迁移工具说明处理存量数据。
结语
这款Agent Memory最值得关注的价值,并非只是多了一个向量库接口,而是它将Agent记忆从“模型附属能力”提升到了“团队基础设施”的位置。当对话可以分层沉淀、操作可以转化为标准化技能、文档和代码可以按需查询、资产带有清晰的归属、版本和权限信息并可以配装到代理中时,Agent才真正拥有了接近组织经验的长期记忆。
虽然目前仍处于测试阶段,自动路由、私有仓库接入和跨框架迁移等功能还在完善中,但方向已经十分明确:未来Agent之间的差异,不仅仅在于模型和工具的选择,更在于它能够继承多少经过验证、权限清晰、随时可用的团队经验。

