TencentDB Agent Memory 架构详解：权限、分层记忆与多 Agent 共享

摘要：TencentDB Agent Memory 面向持续运行的 AI Agent 团队，将 Agent Memory 从单纯的 RAG 检索，扩展为可分层、可授权、可装配的团队资产。本文从四类记忆资产、L0—L3 分层、权限与 Loadout、Token 控制等角度，说明它解决的问题、适用场景与当前限制，并解释 Wiki、Skill、CodeGraph 在多 Agent 协作中的职责。

关键词：TencentDB Agent Memory, Agent Memory, RAG, CodeGraph, 多 Agent

项目解决什么问题：多 Agent 为什么不能只共用一个向量库？

一个 Agent 记住用户偏好并不难：把对话切片、生成 Embedding、再做一次 RAG 检索即可。但项目持续数月、同时有调研 Agent、开发 Agent、评审 Agent 时，问题会立刻变样。

例如，开发 Agent 已经确认旧鉴权模块仍被移动端兼容接口依赖；评审 Agent 若没有这条约束，仍可能建议删除它。调研 Agent 收集的用户访谈，也不应默认被所有角色搜索到。把所有资料放进一个大向量库，看似共享，结果往往是重复学习、召回噪音与权限越界同时出现。

TencentDB Agent Memory 的核心判断是：多 Agent Memory 的难点不在“存得更多”，而在把经验变成可治理、可授权、可装配的资产。它的基本链路可以概括为：

对话、任务、文档、代码
        ↓
Chat Memory、Skill、Wiki、CodeGraph
        ↓
统一管理资产的 Owner、状态、版本与可见性
        ↓
为不同 Agent 配置 Loadout
        ↓
按当前任务检索，并按需注入上下文

这和传统 RAG 的差别不在于是否检索，而在于检索前先回答：这是什么资产、归谁、是否仍有效、当前 Agent 能否使用、应当以什么粒度进入上下文。

四类记忆资产：Chat Memory、Skill、Wiki 与 CodeGraph

Chat Memory：保存发生过什么

Chat Memory 记录事实、偏好、约束、决定与交互历史。例如“某接口只能在低峰期迁移”“这项评审已决定保留兼容层”。它的职责是让 Agent 换 Session 或换人接手后，仍能恢复必要的工作上下文。

完整聊天记录不适合每轮进入 Prompt；应提炼可复用信息，同时保留原始证据。

Skill：沉淀这件事怎样做成

Skill 不是一段孤立的提示词，而是可复用的执行经验。按照项目说明，它可以包含版本、资源文件、触发边界、执行步骤和验证规则。

以发布为例，一个 Skill 可以定义先检查迁移、再运行回归、核对监控和回滚条件，最后才允许发布。这样团队留下的不只是一次聊天结论，而是一套以后仍能执行的 SOP。

Wiki：解释为什么这样设计

产品文档、架构方案、运维手册适合组织为 Wiki。Agent 可以先找到相关页面，再沿链接了解上下游背景，而不是每次把整个文档库重新读一遍。Wiki 解决的是“设计理由在哪里”的问题。

CodeGraph：定位代码在哪里、改动影响谁

普通文本检索能找出关键词文件，却未必说明调用关系。CodeGraph 关注文件、符号、调用与影响路径，帮助 Coding Agent 修改前查询 callers、callees 与影响范围。

四类资产分别回答四个问题：Chat Memory 是“发生过什么”，Skill 是“怎样做成”，Wiki 是“为什么这样设计”，CodeGraph 是“代码在哪里、影响谁”。全部切成无差别文本块，会丢失这些结构。

L0—L3：为什么 Chat Memory 还要分层？

TencentDB Agent Memory 将 Chat Memory 组织为 L0—L3。分层的目标是同时保留证据、恢复场景与控制上下文开销。

• L0 Conversation：保留原始对话，是核对“当时到底怎么说”的证据来源。
• L1 Atom：从对话中提取可直接执行的事实、约束或决定，便于精确召回。
• L2 Scenario：按项目或工作场景组织目标、风险、阶段结论与导航信息。
• L3 Core / Persona：保存用户偏好、团队工作方式等相对稳定的长期认知。

举例说，“旧鉴权模块仍被移动端依赖，未经影响分析不得删除”适合成为 L1；“支付系统改造”的目标、风险和结论可以成为 L2；长期偏好则应进入 L3。L0 留作证据，而不是默认注入。

项目当前支持将关键词与 Embedding 检索结合，并使用 RRF 合并结果。分层并不保证自动得到正确答案，却能避免把短期事件、长期偏好与原始聊天混在同一个召回池里。

权限与 Loadout：共享之前，先确定谁有权使用

多 Agent 共享最容易被忽略的不是召回效果，而是访问边界。项目为资产设置 Owner、版本、状态、可见性和 Agent 绑定关系。母文中列出的边界包括：

• private：仅 Owner 可访问，团队管理员不应默认读取；
• team：团队成员可读，由 Owner 或管理员管理；
• restricted：按 User、Role 或 Agent ACL 精确授权；
• agent：只装配给同团队内指定 Agent。

因此，正确顺序应是先确认身份与权限，再判断角色可使用的资产，最后基于问题检索。若先从全库检索、再过滤结果，不仅浪费排序成本，也可能暴露不应出现的元数据。

Loadout 可以理解为 Agent 上岗时领取的记忆装备。Scout 可以装配用户访谈 Chat Memory、市场研究 Wiki 与竞品分析 Skill；Builder 可以装配产品 Wiki、项目 CodeGraph 与交付 Skill；Reviewer 则更需要历史事故、CodeGraph 和发布检查清单。共享不是复制全量上下文，而是按最小必要原则分发。

Token 控制：先给地图，再按需读正文

Agent Memory 很容易反过来占满模型上下文。TencentDB Agent Memory 的设计重点之一，是让不同资产以不同方式暴露：与问题密切相关的 L1 可以动态召回；L2 先给场景索引；L3 作为相对稳定的信息使用；L0 仅在核对证据时读取；Wiki 与 CodeGraph 先提供工具入口，需要时再查询具体内容。

这是一条很实用的 Token 控制原则：先给地图，再给入口，最后读取正文。实现层面仍需设置召回条数、字符与超时预算，并观测命中率、延迟和无效上下文比例。

适用场景：哪些团队值得试？

第一类是持续时间较长的软件项目。架构决策、代码影响关系和事故经验分散在文档、仓库与工单里，换 Agent 就会重复学习。此时可分别沉淀为 Wiki、CodeGraph、Chat Memory 与 Skill。

第二类是 Scout、Builder、Reviewer 等角色协作：上一环节的结论作为审核后的资产交给下一角色。第三类是个人使用多个研究、开发、测试或运营 Agent，减少重复解释背景。

如果只是短对话机器人，部署完整 Hub 未必划算；如果计划进入生产环境，则应先从一个团队、一类资产和少量 Agent 的隔离试用开始，优先验证权限、审计、过期与回滚。

限制：热度不等于生产成熟度

项目近期在 GitHub 上获得较高关注，但热度只说明关注度，不能替代工程验证。以下边界尤其需要注意：

• Team Memory 在 README 中仍标为 Beta，项目处于快速迭代中；
• Wiki 与 CodeGraph 需要异步构建，CodeGraph 当前优先支持公开 HTTPS 仓库，私有仓库和 SSH 凭证接入仍在完善；
• Hub 支持人工绑定资产，但自动记忆路由仍在迭代；
• 更多框架接入方向已列入 Roadmap，不能当作现有能力；
• PersonaMem 指标为项目方公布，本文未独立复现：约从五成提升到约四分之三，不能据此推导真实业务效果。

本文没有完成生产部署或复跑 PersonaMem；长期成本、冲突率、权限审计与延迟仍需在真实项目中评估，不应称为“生产可用”或“已经验证稳定”。

安装命令与官方参考资料

以下命令来自项目方 README，本文未独立复现；使用 canonical 仓库地址：

git clone https://github.com/TencentCloud/TencentDB-Agent-Memory.git
cd TencentDB-Agent-Memory/deploy/global-images
cp .env.example .env
$EDITOR .env
./start-all.sh

其中 .env 需按项目说明填写 Memory 与 Proxy 的 LLM 参数。可交叉查阅官方 README_CN、INSTALL_CN 与 仓库主页。

总结

TencentDB Agent Memory 的重点不是扩充历史窗口，而是把经验纳入资产、权限、生命周期与 Loadout 管理。落地时先用小范围隔离试用验证权限、撤回与上下文质量，再扩大规模。

母文链接：《GitHub周榜前三，一周涨星6000+：腾讯把多Agent记忆做成了基础设施》。