让团队走过的路，成为下一个 Agent 的起点

模型越来越强，Agent 写代码、查资料、执行任务的速度也越来越快。

但真正使用一段时间后，人们往往会遇到另一种瓶颈：每打开一个新 Session，就要重新解释项目背景；换一个 Agent，又要重讲团队约定；一份文档明明已经读过，下一位 Agent 仍然从第一页开始；一套排障流程已经验证成功，下次遇到相似问题，团队却又摸索一遍。

如果经验不能留下来，Agent Loop 可能只是在更快地重复。

TencentDB Agent Memory 从一个实际问题出发：怎样让 Agent 完成的工作不只产生一次结果，还能为下一次工作留下可以继承的经验？

我们的答案不是保存更多聊天记录，也不是把所有资料永久塞进 Prompt，而是把团队已经拥有的信息转化为可复用、可管理、可装配的记忆资产。

Memory 不只是“记住聊过什么”

一次对话中可能同时出现四种有长期价值的信息。

第一种是关于人和项目的事实。例如用户偏好、产品约束、历史决定，以及“为什么旧鉴权模块现在不能改”这类代码里找不到的背景。

第二种是已经跑通的做法。例如如何排查某类故障、怎样完成代码 Review、发布前需要检查哪些步骤。

第三种是文档知识。产品说明、架构设计和运维手册之间存在目录、主题和引用关系，并不是一袋彼此无关的文本块。

第四种是代码结构。文件、符号、调用方、被调用方和影响路径，决定了一次修改可能波及哪里。

TencentDB Agent Memory 将这些信息组织成四种资产：

• Chat Memory：保留偏好、事实、决定和交互历史；
• Skill：把完成任务的经验沉淀为包含版本、资源、触发边界、执行步骤与验证规则的可复用流程；
• Wiki：把文档整理成结构化页面和链接图谱；
• CodeGraph：索引代码文件、符号、调用关系与影响路径。

它们分别承载人、经验、文档与代码。四种资产共同解决的，不是“怎样存下更多”，而是“怎样让下一位 Agent 少走弯路”。

从原始对话到可以工作的长期语境

聊天记录是重要证据，但不是最方便使用的记忆形态。

如果 Agent 每次都重读全部历史，不仅成本高，也很难从大量对话中快速找到真正关键的限制条件。为此，TencentDB Agent Memory 将对话逐层沉淀：

• L0 Conversation 保存原始对话、时间和完整上下文；
• L1 Atom 提取事实、偏好、约束与事件；
• L2 Scenario 围绕项目或工作场景组织知识；
• L3 Core / Persona 保存长期画像与稳定模式。

当 Agent 进入一个项目时，L2/L3 可以帮助它快速恢复工作语境；当它需要核对某个决定的原话和来源时，再通过检索回到 L1/L0。

高层记忆负责快速进入状态，底层记录负责准确与追溯。

记忆应该属于项目，而不是某个工具

今天的开发者可能同时使用 Claude Code、Codex、CodeBuddy、WorkBuddy、Hermes、OpenClaw 或其他 Agent。工具可以切换，但项目经验不应该随聊天窗口一起消失。

TencentDB Agent Memory 提供一套 Memory Proxy。客户端通过调整 base URL 接入，在不修改 Agent 源码的情况下，通过原有协议使用团队记忆。仓库目前提供多种客户端的配置说明，也保留通用接入路径。

上午向一个 Agent 解释过的业务规则，下午换另一个 Agent 时仍然可以被团队继承。记忆从客户端的附属品，变成项目基础设施的一部分。

新 Agent 应该从团队的存档开始

多数新 Agent 接手项目后的第一件事，是重新学习：扫描目录、阅读文档、询问背景，再猜测团队习惯。

这些学习成本往往已经由人或其他 Agent 支付过。

TencentDB Agent Memory 支持把已有资产作为冷启动材料：导入代码库后构建 CodeGraph；导入文档后生成 Wiki；导入过去的 Agent 会话后，从中提取 Chat Memory 与 Skill。

新成员、新 Agent 或新的工作框架，不再只能面对一张白纸，而可以先加载团队的存档，再开始工作。

不把整座仓库塞进 Context

拥有记忆，不意味着每次推理都加载全部记忆。

更多 Context 可能带来更多噪音、成本和冲突。过时规则与当前决定一起出现时，模型甚至更难判断哪一条有效。

TencentDB Agent Memory 采用分层和按需方式：平时用 L2/L3 恢复场景，需要具体事实时结合 BM25、向量检索与 RRF 回到 L1/L0；召回结果还受到条数、字符预算和超时限制。Wiki 与 CodeGraph 则保持为可调用工具，只有真正需要的页面、源码或影响路径才进入上下文。

目标不是拿得最多，而是少拿、拿对。

共享经验，不等于共享全部信息

团队记忆只有在边界清楚时才真正可用。

TencentDB Agent Memory 中，新产生的 Chat Memory 和 Skill 默认保持私有。资产可以是仅 Owner 可读的 private，也可以面向团队的 team，通过 restricted 精确授权给用户、角色或 Agent，还可以用 agent 定向装配。

Memory Hub 统一管理 Owner、版本、状态、可见性、使用情况和 Agent 绑定。团队可以把发布 Skill 配给 Release Agent，把架构 Wiki 配给开发 Agent，把 CodeGraph 配给 Coder 与 Reviewer，而不是让所有 Agent 看到所有内容。

记忆不是一个无边界的全局 Prompt，而是每个 Agent 的 Loadout。

人仍然掌握最后的控制权

自动抽取不会永远正确。事实会过期，结论会被推翻，流程也会升级。因此，团队需要能够审核、编辑、分享、绑定或撤回记忆资产，并在必要时回到原始来源。

当前项目也有明确边界：Wiki 和 CodeGraph 需要异步构建；CodeGraph 目前优先支持公开 HTTPS 仓库，私有仓库与 SSH 凭证仍在完善；人工资产绑定已经可用，全自动记忆路由仍在迭代；MongoDB 后端属于可选实验能力。

我们愿意把这些边界写清楚，因为 Agent Memory 仍然没有标准答案。真实使用、Benchmark、Bug、文档改进和新的框架接入，都会帮助它继续成长。

我们不期待 Agent 记住一切。

我们更关心三个问题：什么值得留下，谁可以使用，下一次怎样少拿但拿对。

团队可以很小，经验可以持续复利。

让团队走过的路，成为下一个 Agent 的起点。

体验与参与：https://github.com/TencentCloud/TencentDB-Agent-Memory