你有没有发现，AI Agent 用得越多，重复工作反而越明显？
换一个 Session，要重新解释项目背景；换一个 Agent，要再讲一遍团队约定；一套排障流程已经跑通，下次遇到相似问题，Agent 还是从零试错；代码仓库刚读明白，窗口一关，又得重新扫描。
我们一直在让 Agent 更强，却很少认真解决一个问题：上一位 Agent 付过的学习成本，怎样留给下一位？
腾讯最近更新的开源项目 TencentDB Agent Memory v2.0.0，给出了一套很有意思的答案。
它不再只做“聊天记忆”，而是把 Agent 工作中产生的内容整理成四类可复用资产：
Chat Memory：记住事实、偏好、决策和历史；
Skill：把跑通的做法沉淀成可执行 SOP；
Wiki：把文档变成结构化知识与链接图谱；
CodeGraph：索引代码符号、调用关系和影响路径。
然后再用一个 Memory Hub 管理这些资产属于谁、哪个版本有效、谁能看、应该装配给哪个 Agent。
截至 2026 年 8 月 7 日，该项目在 GitHub 已超过 1.6 万 Star，v2.0.0 发布于 8 月 3 日，采用 MIT License。
但它真正值得关注的，不是 Star 数，也不只是“腾讯开源”。
我更看重的是：它开始把 Agent Memory 从个人聊天记录，推向团队可以治理、共享和装配的经验资产。
它不是聊天记录仓库
很多 Agent Memory 项目解决的是“跨会话记住用户”。
比如你喜欢什么技术栈、项目有哪些约束、上次做到了哪一步。这当然有价值，但对一个长期工作的 Agent 团队来说还不够。
真正能减少返工的内容，至少有四种。
| 资产 | 保存什么 | 下次怎样复用 |
|---|---|---|
| Chat Memory | 对话、事实、偏好、决策 | 让 Agent 快速恢复人与项目的背景 |
| Skill | 跑通的方法、步骤、资源和验证规则 | 让相似任务不再从头摸索 |
| Wiki | 产品文档、设计方案、运维手册 | 按结构搜索与沿链接下钻 |
| CodeGraph | 文件、符号、调用关系、影响路径 | 改代码前先做影响分析 |
这四类资产对应了四种经常被浪费的成本：解释过的背景、跑通过的经验、读过的文档和理解过的代码。
所以项目对 Memory 的定义比“记住聊天”更宽：凡是能让下一个 Agent 少走弯路的信息，都应该被保存、组织并复用。
举个例子。
Builder Agent 修好一次线上鉴权问题后，系统可以把关键决策留在 Chat Memory，把排障过程提炼成 Skill，把运维说明整理进 Wiki，再让 CodeGraph 保存相关模块和调用路径。
之后 Reviewer Agent 接手，不需要把几百轮对话全部重读。它拿到的是和自己角色匹配的一组“装备”。
Chat Memory 不是一坨向量，而是四层生长
TencentDB Agent Memory 的对话记忆分成 L0 到 L3 四层：
| 层级 | 内容 | 用途 |
|---|---|---|
| L0 Conversation | 原始对话与完整上下文 | 回查原话、时间与来源 |
| L1 Atom | 事实、偏好、约束、事件 | 精确召回可以直接执行的信息 |
| L2 Scenario | 围绕项目或场景组织的知识块 | 快速恢复一个工作场景 |
| L3 Core / Persona | 长期画像、稳定模式与高层认知 | 进入用户与团队的长期语境 |
这个分层解决了两种极端。
一种是把全部历史塞回上下文，信息完整，但 Token 和噪音都会膨胀；另一种是只保留一份不可追溯的总结，虽然很短，却可能把关键细节压没。
项目平时优先用 L2、L3 恢复语境，需要核对具体事实时，再通过 BM25、向量检索和 RRF 回到 L1、L0。召回结果还会受到条数、字符预算与超时限制，避免“记忆”反过来占满上下文。
这套设计最重要的不是层数，而是保留了一条从高层判断回到原始证据的路。
Skill 才是团队经验真正开始复利的地方
如果 Chat Memory 解决“记住发生过什么”，Skill 解决的就是“下次应该怎么做”。
项目里的 Skill 不只是一段 Prompt。官方文档描述的 Skill 包括版本、资源文件、触发边界、执行步骤和验证规则。
这意味着一套成功流程可以被维护，而不是散落在某个聊天窗口里。
例如：
一次线上故障排查，沉淀成“服务异常诊断 Skill”；
一次发布流程，沉淀成“上线前检查 Skill”；
一次代码审查，沉淀成“安全 Review Skill”；
一次内容生产，沉淀成“公众号发布 Skill”。
个人 Skill 默认私有，审核后可以分享给团队，再绑定给特定 Agent。v2.0.0 还增加了 Skill 强制归档，目的是让关键经验不会因为会话结束而漏掉。
这里的变化很像公司从“口口相传”走向“有版本、有边界、可验证的操作手册”。
只是执行者从人变成了 Agent。
Wiki 和 CodeGraph，让文档与代码也成为记忆
普通 RAG 往往把文件切成片段，然后做相似度检索。
TencentDB Agent Memory 想再向前一步。
Wiki 会把文档整理成结构化页面和链接图谱；CodeGraph 则索引代码仓库里的文件、符号、调用关系和影响路径。
Agent 不需要每次把整份文档或整个仓库重新读一遍，而是先发现可用工具，再按需搜索页面、读取源码、查 callers / callees，或者在改代码前做 impact analysis。
它们平时不必全部进入上下文，只有真正需要的部分才被取出。
对于 Coding Agent，这个思路比“给它更长的上下文窗口”更实际。窗口再长，也不代表每次都应该把整个仓库塞进去。
不过要注意，Wiki 和 CodeGraph 都是异步构建，导入后要等待处理完成；官方注意事项还说明，CodeGraph 当前首先支持公开 HTTPS 仓库，私有仓库和 SSH 凭证接入仍在完善。
Memory Hub 解决的不是搜索，而是“谁能用”
到了团队场景，Memory 最难的问题往往不再是“能不能搜到”，而是：
这条记忆属于谁？
哪个版本才有效？
可以给整个团队，还是只能给某个 Agent？
项目隐私会不会被其他成员看见？
一条过时的 Skill 能不能被收回？
Memory Hub 用 Team、User、Agent、Owner、版本、状态和可见性来管理资产。
项目当前提供四种装配语义：
| 可见性 | 含义 |
|---|---|
private | 只有 Owner 可以读取 |
team | 团队成员可读取 |
restricted | 按 User、Role 或 Agent ACL 授权 |
agent | 定向装配给同团队里的 Agent |
然后通过 Agent Loadout，让 Scout、Builder、Reviewer 等不同角色只带走与任务相关的资产。
这点很关键。共享记忆不应该等于共享全部信息。
一个调研 Agent 需要市场 Wiki 和访谈记忆，却未必需要生产环境密钥；一个 Reviewer 需要事故记录与 CodeGraph，却不一定要看到用户隐私。
它怎样接到 Claude Code 这类 Agent 上？
v2.0.0 提供 Memory Core、Memory Hub 和 Memory Proxy 三个主要组件。
Memory Core：负责记忆读写、鉴权以及 Skill/RAG 数据面；
Memory Hub：提供团队资产管理面板，并包含 Knowledge Service；
Memory Proxy：接收 Anthropic 或 OpenAI 协议请求，把匹配到的记忆、Skill、Wiki 与 CodeGraph 信息注入上下文，再转发给上游模型。
Claude Code 接到 Proxy 后，第一次会话会选择 Team、Agent 与 Task。后续请求根据身份和当前任务获得相应资产。
官方推荐用 Docker 一次拉起三件套：
面板默认打开在：
但这里不要被“一键启动”四个字误导。
安装前至少要准备两组模型参数：一组给 Memory 和 Knowledge 内部做提取、总结与 Wiki 构建，另一组给 Proxy 转发 Agent 的正常请求。两组可以用相同模型，也可以分开配置。
所以它不是一个零成本、纯离线的记忆插件。数据可以由你自部署，但记忆提取、知识处理和 Agent 推理仍需要 LLM，是否离线取决于你接入的模型。
部署时有一个安全配置必须看
官方 v2.0.0 的 .env.example 里，MEMORY_CORE_GATEWAY_API_KEY 默认留空。
这代表 Memory Core 的 Bearer Gate 默认关闭，主要是为了本地零配置体验；模板同时说明，当前 Proxy 还不会发送这一层 Header，如果直接填入非空 Key，Proxy 的认证和 Session 初始化会失败。
这对本机试用可以理解，但如果准备把端口暴露到局域网、公网或生产环境，就不能照搬默认配置。
你至少需要：
限制 8420、8125、8424、8096 等端口的网络访问范围；
妥善保管自动生成的
.admin-key，不要提交到仓库或日志；普通业务尽量使用 normal 用户，不直接长期使用 admin key；
在反向代理或基础设施层补充 TLS、认证、访问控制和日志审计；
先确认 Proxy 与 Gateway 鉴权的当前兼容方式，再决定生产配置。
“开源可自部署”只是控制权的开始，不是安全配置自动完成。
Benchmark 怎么看？
项目 README 当前只展示了 PersonaMem 一项结果：无 TencentDB Agent Memory 时为 48%，启用后为 76%，项目方标注相对提升 59%。
PersonaMem 用来检验 Agent 在长期交互后能否正确理解和使用用户信息。
这个数字可以说明项目团队的设计目标，但不能直接外推到你的代码质量、任务成功率或 Token 成本。
本文没有在本地复现该 Benchmark，也没有看到第三方独立评测，因此更稳妥的表述是：这是项目 README 报告的实验结果，不是本文实测结论。
真正决定效果的，还包括模型能力、记忆抽取质量、资产是否及时更新、召回预算、权限配置，以及错误记忆能不能被发现和纠正。
谁适合用？
比较适合：
长期使用 Claude Code、CodeBuddy、OpenClaw、Hermes 等 Agent；
同一项目需要多个 Agent 或多名成员协作；
经常重复解释业务背景、代码约束和操作流程；
有大量文档、代码与历史会话，希望作为团队资产复用；
愿意自部署 Docker 服务，并管理模型、权限、备份和升级。
不太适合：
只是偶尔开一个聊天窗口，跨会话记忆需求很弱；
希望下载一个插件后完全零配置；
不愿意把内部文档与代码交给配置的 LLM 处理；
没有能力维护多服务部署、鉴权与数据备份；
需要成熟 SLA、完整审计和已经充分验证的企业生产方案。
项目目前仍在快速迭代。官方明确写着，全自动记忆路由、更广泛的跨框架迁移、私有代码仓库接入等能力仍在完善。
我的判断
TencentDB Agent Memory v2.0.0 最有价值的地方，不是又增加了一种向量检索方案。
它提出了一个更完整的 Agent 团队问题：
经验从哪里产生，怎样变成资产，谁可以使用，又怎样装配给下一位 Agent？
Chat Memory 负责保留人与事，Skill 负责沉淀跑通的方法，Wiki 负责组织文档，CodeGraph 负责理解代码；Memory Hub 再把 Owner、版本、状态和权限补上。
这已经不只是“让 AI 记性更好”，而是在尝试给 Agent 团队建立组织记忆。
但现在的它更适合愿意折腾的开发者和小团队先试，而不是不做评估就接入核心生产系统。
我的建议是：先在一个非敏感项目里部署，用一支小型 Agent 队伍验证三件事——它提取的记忆是否准确、Skill 是否真的减少返工、权限与删除机制是否足够可控。
如果这三件事成立，Agent 才真正开始从“一次性工具”变成“会继承经验的队友”。