TencentDB Agent Memory 通过一个代理为编程和工作类 Agent 提供共享的分层记忆:聊天记忆、技能、Wiki 和代码图谱。我们阅读了其代码并重新计算了它的基准测试。51.52% 这个亮眼数字只是在一个基准测试上提升了 17 个百分点,而且两个 token 数据与其自己的表格对不上。
作者:ADAM REYES · FDEINTERVIEWS 编辑部 · 更新于 2026 年 10 月 21 日 · 阅读时长 8 分钟
实践练习:Agent 记忆的概念 · 上下文工程取代提示词工程 · RAG 与 Agent 设计面试题 · FDE 必知问题
TencentDB Agent Memory 是一个开源的记忆层,让编程和工作类 Agent 能够跨会话、跨 Agent、跨团队地记住项目上下文、决策和流程。它的工作方式主要是作为一个代理,位于 Agent 与其模型之间,将相关记忆注入每次请求,并把每一轮对话写回一个分层存储。这个设计是合理的,有些地方甚至颇为巧妙,尤其是它坚持让每条摘要都保留一条回溯到原始证据的路径。其基准测试部分则不如 29,700 个 GitHub 星标所暗示的那么强。标题中的"+51.52%"只是一个基准测试从 33% 提升到 50%,没有给出运行次数或所用模型,而且两个 token 节省数据无法从 README 自己的表格中重新计算得出。我们的观点:这个架构值得学习,对于经常向 Agent 重复同样内容的团队来说也值得试点,前提是你要以它本来的面目来审视它——一个会读取工程师发出的每一条提示词的服务。
## 一个名字下的两个产品
该仓库有两个分支,描述的是两个不同的产品,这也解释了为什么它的截图彼此不一致。
The
main
branch
describes an OpenClaw and Hermes plugin built on "symbolic short-term memory plus layered long-term memory". In long tasks it offloads bulky tool output (search results, code, error traces) to files and keeps only a compact Mermaid graph of the task state in context, with node IDs the
agentcan use to fetch the full text. This is the README with the widely shared benchmark table.
The default branch,
feat/server_team
(v2), describes a team memory hub. A proxy fronts the agent's model calls, and four kinds of memory assets are managed in a web panel: Chat Memory (preferences, facts and decisions), Skills (versioned procedures with triggers and validation rules), a Wiki built from documents, and a CodeGraph built from repositories. Assets have owners, versions and visibility levels (
private
,
team
,
restricted
by user, role or agent ACL, and
agent
), and new memories are private by default. Its README keeps only one benchmark row. The changelog and roadmap place the current release around v2.0.x.
两者共享同一个长期理念,因此我们只介绍一次架构。
## 工作原理
架构来源:团队分支的 README,其中描述了该代理和共享记忆服务。
分层。原始对话(L0)保持原样。一个异步流水线将其提炼为原子事实、偏好和约束(L1)、围绕项目的场景块(L2)以及稳定模式的画像(L3)。上层以人类可读的 Markdown 存储,下层存入数据库以支持全文检索。召回默认返回紧凑的上层内容,当需要某个具体事实时,再通过 BM25 加向量搜索向下钻取,并用倒数排名融合进行合并。结果受条目数、每条记忆的字符数、总字符数和超时时间(召回代码中默认为 5 秒)的限制。
可追溯性。每个上层条目都保留一条指向其来源证据的路径。这是我们会复制到任何记忆系统中的部分。无法回溯到来源的摘要只是谣言。当某条画像事实被证明是错误的,你需要找到产生它的那段对话;当客户要求删除某些内容时,你需要从由它派生出的每一层中将其移除。
资产,而不仅仅是聊天。技能从成功的对话和工具调用中提炼而来,带有版本和触发边界。Wiki 页面和 CodeGraph 索引以工具的形式暴露(/v3/tools/list、/v3/tools/call),而不是直接粘贴进上下文,因此只有当 Agent 主动请求时,文档才会进入提示词。致谢部分说明 CodeGraph 模块使用了 colbymchenry 的 codegraph 项目中的代码,Skill 模块则基于 Hermes Agent 构建。
/v3/tools/list
,
/v3/tools/call
) rather than pasted into context, so a document enters the prompt only when the agent asks for it. The acknowledgements say the CodeGraph module uses code from colbymchenry's codegraph project and the Skill module builds on Hermes Agent's.
Symbolic short-term memory (the
main
branch). Instead of keeping fifty tool outputs in
the context window, the agent keeps a small graph of what it did and where each raw result was saved.
Keep the pointer, not the payload.Mermaid is one way to encode that graph; the important design choice is that every node has an ID that retrieves the full text on demand, so compression never destroys information. This is the same principle behind file-based scratchpads in long-running coding agents, and it is a good one.
基准测试,重新计算
The
main
README reports four results "when integrated with OpenClaw". We recomputed every derived number from the table itself.
基准测试来源:主分支 README。这些插件结果与上文描述的较新的团队代理不同。
| 基准测试 | 不使用 | 使用 | 分数 | 相对提升(README) | Token 数(不使用 → 使用) | 重新计算的 Token 变化 | README 所述 |
|---|---|---|---|---|---|---|---|
| WideSearch | 33% | 50% | +17.0 | +51.52% | 221.31M → 85.64M | −61.30% | −61.38% |
| SWE-bench | 58.4% | 64.2% | +5.8 | +9.93% | 3,474.1M → 2,375.4M | −31.63% | −33.09% |
| AA-LCR | 44.0% | 47.5% | +3.5 | +7.95% | 112.0M → 77.3M | −30.98% | −30.98% |
| PersonaMem | 48% | 76% | +28 | +59% | 未报告 |
四点观察。
标题是相对值,来自一个基准测试。“将通过率提升 51.52%”指的是 WideSearch 从 33% 提升到 50%。同一插件在 SWE-bench 上增加了 5.8 个百分点,在 AA-LCR 上增加了 3.5 个百分点。低基数上的相对增益是营销数字;百分点才是工程数字。两者都是真的,但只有一个能告诉你这对你的用户意味着什么变化。
两个 token 数字与其表格不符。WideSearch 的降幅重新计算应为 61.30%,而不是标题中的 61.38%;SWE-bench 的应为 31.63%,而不是 33.09%。这些是小错误,但它们之所以重要,是因为它们表明表格和正文可能来自不同的运行,或者是分开编辑的。当标题数字无法从旁边的表格中重新计算得出时,请相信表格,并追问标题出自哪一次运行。
没有样本量、方差或模型信息。README 没有说明运行了多少个任务、运行了多少次、使用了哪个模型,以及结果的离散程度。AA-LCR 上 3.5 个百分点的提升可能只是噪声。默认分支现在只保留了 PersonaMem 那一行,同样没有说明配置。
SWE-bench 的设置偏向于插件。README 说 SWE-bench“每个会话连续运行 50 个任务,以模拟真实世界长程 Agent 的上下文累积压力”。这是对记忆系统的一种有效压力测试。但它也是一个在单个会话中携带五十个任务历史的基线,很少有生产环境的执行框架在不做压缩的情况下这样做。31.63% 的 token 节省中,有一部分只是插件做了基本的上下文重置策略同样会做的事情。公平的比较对象应该是带有常规压缩机制的基线。
这些都不能说明该系统不工作。它只是意味着已发布的证据无法告诉你它能给你带来多大帮助,你需要自己进行测量。
记忆代理会对你的数据和你的账单造成什么影响
将每一次模型调用都经由记忆代理路由,其后果是 README 中“零代码集成”的说法所低估的。
它会读取一切。代理能看到每一个提示词和响应,包括源代码、堆栈跟踪,以及工程师粘贴的任何机密信息。默认情况下,代理配置启用了注入(将技能、知识工具和记忆块添加到系统提示词中)和提取(将每一轮的用户查询和助手回复写入 L0)。记忆代理是你主动选择的中间人。请像审查中间人一样审查它。
它会将对话发送给第二个模型。部署模板中有两套模型设置:一套用于代理的上游,另一套用于记忆服务自身的摘要和嵌入。它们可以是不同的提供商。你的数据处理审查必须同时覆盖两者。
它改变了提示缓存。召回的记忆被注入到系统提示中,而系统提示通常是提示缓存所依赖的稳定前缀。如果注入的内容每次请求都不同,缓存就会失效,每次调用都要为整个前缀支付全价。该项目自身的配置就警告过,配置不当的多节点部署会导致上游 Anthropic 缓存每次都失效。把稳定的指令放在前面,记忆块放在其后,并在前后分别测量你的缓存命中率。
It pulls
latest
images by default.
The quick-start template uses
:latest
tags from
DockerHub, and the script reuses a local
latest
without checking for updates. Pin versions for anything beyond a laptop trial.
优缺点
| 优点 | 缺点 |
|---|---|
| 分层记忆,从摘要到原始证据有可追溯的路径 | 基准测试缺少任务数量、运行次数、方差和模型信息 |
| 默认私有,显式共享,支持按 Agent 和 ACL 的可见性控制 | 标榜的 token 节省并非全部能从表格中重新计算得出 |
| 文档和代码以工具形式暴露,而不是直接粘贴进上下文 | 代理默认会看到并存储每一次提示和响应 |
| 多个 Agent 可通过一个代理协同工作,无需为每个 Agent 单独安装插件 | 注入的记忆若放在稳定前缀中,可能破坏提示缓存 |
| MIT 许可证,开发活跃,提供版本间迁移工具 | 两个分支描述的是两个产品;很容易用错 |
| 技能具备版本、触发器和验证规则 | CodeGraph 偏好公开的 HTTPS 仓库;私有仓库支持仍在开发中(据 README) |
什么时候值得用
适合的场景。团队中多人及多个 Agent 反复解释相同的架构、约定和决策。代理机构和前沿部署团队在同一个客户代码库中工作数月,每次新会话重新讲解上下文的成本确实很高。需要在跨对话中掌握客户稳定事实的支持和运维 Agent。
不适合的场景。只有一个 Agent 的独立开发者,一份维护良好的 AGENTS.md 或项目笔记文件就能免费完成大部分工作。快速变化的事实,一条被自信注入的过时记忆比没有记忆更糟。受监管的数据,除非已审查过代理、记忆模型提供商及数据保留策略。
AGENTS.md
or project notes file does most of the job for nothing. Fast-changing facts, where a stale memory confidently injected is worse than none. Regulated data, until the proxy, the memory model's provider and retention have been reviewed.
我们会如何试点。在一个团队上运行两周,仅使用私有记忆。测量三件事:每个已完成任务的 token 消耗、有人重新讲解本应由记忆提供的上下文的会话占比,以及注入的记忆错误或过时的频率。记忆只有在有人审核后才提升为团队范围,增加一条能触及每一层的删除路径,并与最便宜的替代方案——一份精心维护的项目笔记文件加上 Agent 内置的压缩功能——进行对比。如果代理不能以明显优势胜出,那就用笔记文件。
对于 FDE 来说,记忆设计如今已成为常见的面试话题:存什么、以什么粒度存、如何检索、如何避免过时以及如何删除。这里的分层模型是一个很好的参考答案。请阅读我们的 Agent 记忆概念、关于上下文工程如何取代提示词工程的文章,并用我们的 RAG 和 Agent 题目进行练习。
把它转化为 offer。练习这些内容所对应的真实面试题和概念:
FAQ
TencentDB Agent Memory 是腾讯云推出的一个采用 MIT 许可证的开源记忆系统,面向 Claude Code、Codex、OpenClaw 和 Hermes 等 AI Agent。其当前版本以代理(proxy)形式运行在 Agent 与其模型之间:它在每次请求中注入相关的记忆、技能和知识工具,并将每一轮对话写回分层记忆存储。它还会构建文档 wiki 和代码图谱,并支持团队共享与访问控制。
原始对话首先被存储(L0),然后在后台被提炼为原子事实和偏好(L1)、场景级摘要(L2)以及长期人格画像(L3)。在请求时,Agent 默认获得紧凑的上层内容,当需要某个具体事实时,再回退到详细的下层内容——检索采用 BM25 与向量搜索并通过倒数排名融合(reciprocal rank fusion)合并。结果按条数、字符数和超时时间进行限制。
这些结果看似合理但证据薄弱。该项目报告了在四个基准上使用和不使用其插件的成功率,但没有给出任务数量、运行次数、方差或所用模型。标题中的 51.52% 提升来自 WideSearch 从 33% 提升到 50%;在 SWE-bench 上的提升是 5.8 个百分点。README 中两个 token 减少的数字与同一表格中的 token 计数对不上。
它可以是安全的,但需要审查。该代理能看到每一个提示词和响应,会向系统提示词添加内容,默认将每一轮对话写入记忆,并将对话发送给另一个模型进行摘要。请像对待任何处理源代码和凭据的服务一样对待它:自行托管、固定镜像版本、慎重选择记忆模型的提供商,并在上线前设置保留和访问规则。
当多个 Agent 或多个用户反复重新解释相同的项目背景、约定和决策,且这些背景变化缓慢时,它最有用。对于一次性任务、只有一个 Agent 的单用户,或者快速变化的事实(此时过时的记忆比没有记忆更糟),它的帮助较小。建议从一小组经过审查的共享记忆开始,而不是捕获所有内容。
讨论(4)
缓存这一点是悄悄烧钱的坑。我们曾有一个记忆层,把召回的事实前置到系统提示词中,结果我们的提示词缓存命中率从几乎全部命中降到几乎为零。把记忆块移到稳定指令之后,一个下午就修复了这个问题。
读者提问:先做团队共享记忆,还是先做每用户记忆?
默认以个人和私有优先,正如本项目的默认设置。在个人审核后,再将个人记忆提升到团队。无人整理的团队记忆一个月内就会变成共享的杂物抽屉,然后每个 Agent 都会继承这些杂物。
治理清单里值得加上一条:删除路径。当客户要求你遗忘某些内容时,你需要将其从 L0 以及从它提炼出的每一层中移除。在需要之前,先问清楚系统如何将某个角色事实追溯到其来源对话。