努力学习，勤奋工作，让青春更加光彩。——王光美

当 AI 团队终于开始“长记性”：TencentDB Agent Memory 想解决的，其实不是聊天，而是经验流失

很多人用 Agent 的第一感受都很相似：它聪明、反应快、执行力强，但也有一个让人哭笑不得的问题——总像是刚刚失忆过一次。

上一个会话里刚讲清楚的项目背景，下一次还要再说一遍；已经读过的文档，换个 Agent 又得从头看；好不容易总结出的处理套路，往往还没来得及沉淀，就又散落在一轮轮对话里。于是你会发现，重复劳动并不是因为 Agent 不努力，而是因为它的经验没有真正留下来。

TencentDB Agent Memory 想做的，正是把这件事掰正。

它把 conversations、docs 和 code 变成四类可复用的 memory assets：Chat Memory、Skill、LLM-Wiki、Code-Graph。这些资产不是零散地漂浮着，而是可以被治理、共享、分配给不同 Agent 与框架使用。换句话说，它不只是让 Agent “记住一点东西”，而是试图为一个 Agent 团队准备一套可以长期积累的记忆系统。

项目地址：https://github.com/TencentCloud/TencentDB-Agent-Memory

它想回答的，不是“怎么聊天更顺”，而是“怎么少走回头路”

TencentDB Agent Memory 在 README 里提出了一个非常直接的问题：

当你在使用 Agents 时，如何减少重复工作？

这个问题其实点得很准。很多场景里，真正昂贵的并不是一次推理本身，而是上下文反复重建的成本。项目背景讲过了，却没有继承；文档读过了，却没有沉淀；代码结构探索过了，却没有形成团队资产。于是每一次新会话，都像把人和 Agent 一起送回起跑线。

它给出的思路也很清晰：凡是能帮助下一个 Agent 不再“重新发明轮子”的信息，都应该被保存、组织、复用。

README 里甚至把这条逻辑压缩成了一条非常朴素的链路：

1
Existing information → Reusable memory assets → Fewer turns → Less rework → More stable results and higher efficiency

这句话读起来像一句产品口号，但落到实际使用里，其实是在重新定义“记忆”这件事。记忆不再只是保存聊天记录，而是把已经付出的理解成本、沟通成本和试错成本，变成下一次还能继续使用的资产。

它不是一个聊天记录仓库，而是一套“团队记忆中枢”

TencentDB Agent Memory 把自己的定位说得很明确：这是一个 team-level memory hub for AI Agents。

这个“team-level”很重要。

因为它关注的，不是某一个单点 Agent 的临时上下文，而是一个团队在持续协作中的经验循环。工作产生资产，资产在团队里流转，新的成员或者新的 Agent 再接过这些成果继续推进。它更像是在为 Agent 团队维护一份“集体存档”。

README 中给出的核心路径包括三件事：

  1. 自动提取资产
    从 conversations 和 tasks 中提取 Chat Memory 和 Skills，把 documents 与 code 转成 Wiki 和 CodeGraph，再统一管理、审核和路由。

  2. 可移植、兼容多 Agent
    memory assets 与具体 Agent frameworks 解耦，可以跨框架移动，也可以被多个 Agents 和团队成员共享维护。

  3. 对冷启动友好
    已有的文档、代码库、Agent conversation sessions 都可以导入。新的 Agent 团队不需要从零学习，而是直接从既有经验出发。

如果把这三点放在一起看，它试图构建的就不是“更长的上下文”，而是更可继承的上下文。

四类记忆资产，各自扮演不同角色

TencentDB Agent Memory 把经验拆成了四种资产。这个拆法很有意思，因为它不是把所有信息塞进一个大桶里，而是按用途和语义分层。

1. Chat Memory：记住人、记住背景、记住那些不该每次都重讲的事

README 对 Chat Memory 的描述非常直观：

  • 保留 preferences、facts、decisions 和 interaction history
  • 每个 Agent 创建时都会自动拥有自己的 memory
  • 从 L0 Conversation 到 L1 Atom，再到 L2 Scenario、L3 Persona，原始对话会被逐层提炼

这意味着，对话不会只是静静躺在日志里。它会被逐步蒸馏，变成可以被调用的、更高密度的信息结构。

README 里有一句很有画面感的话：

“Don’t refactor the old auth module — mobile is still using it.”

像这样的上下文，如果每次都靠人反复提醒，代价非常高。Chat Memory 想做的，就是把这种“说过一次就该留下”的信息真正留下来。

2. Skill：把做成过的事，变成还能再做的能力

Skill 的定位不是 prompt 片段，而是更完整的可复用经验单元。

README 提到，一个 Skill 可以包含：

  • versions
  • resource files
  • trigger boundaries
  • execution steps
  • validation rules

而且，复杂工作完成之后，Agent 可以从 conversations 和 tool calls 中提取并管理这些 Skills，再在需要时导入到指定 Agent 的上下文里。

这就让 Skill 不再只是“写过一段提示词”，而更像是一套已经走通过的工作方法。故障排查、代码评审、发布检查清单，这些 once learned、team reusable 的东西，在这里都被当成可以积累的资产看待。

3. LLM-Wiki：让文档不只是被存放，而是被整理成结构化知识

在这个系统里，Wiki 会把 product docs、design specs、ops runbooks 转成 structured pages，并形成 link graph。

MemoryKnowledge 的 README 进一步补充了这部分能力：

  • 上传或拉取文档
  • 通过 LLM 抽取结构化页面
  • 支持 FTS5 全文检索和知识图谱

于是文档不再只是一个个静态文件，而是开始具备结构、关系与可探索性。Agent 不必每次都从文件列表一页页扫过去，它可以沿着知识图谱去理解和检索。

4. Code-Graph：代码不只是文本，更是关系网络

CodeGraph 的目标也非常明确：索引 code symbols、files、call relationships 和 impact paths。

MemoryKnowledge README 中对这条链路描述得很实在：

  • git clone 仓库
  • CodeGraph 建索引
  • 支持符号、调用关系、文件树的探索查询

在主 README 中，它强调的则是 Agent 能做的事：

  • search
  • read
  • inspect callers / callees
  • impact analysis before modifying code

这件事的价值不在于“告诉你代码在哪”，而在于“提醒你改这里可能会牵动哪里”。对于需要在复杂代码库里行动的 Agent 来说，这种结构化的代码理解能力，本身就是非常重要的记忆资产。

它关心的不只是“记住”，还关心“谁能用、怎么用”

很多记忆系统只解决一半问题：能不能存下来。

TencentDB Agent Memory 还在追问另一半：谁可以使用这些记忆、哪一个版本有效、该分配给哪个 Agent。

README 里专门把它和普通聊天历史、标准 RAG 做了区分。它强调自己不只是回答“能不能找到”，还要回答：

  • 谁能用
  • 哪个版本有效
  • 该给哪个 Agent

这就是 Memory Assets 的概念。Chat Memory、Skills、Wiki、CodeGraph 都被统一注册成资产，而不是散乱内容。于是它们开始具备：

  • ownership
  • version
  • status
  • visibility
  • usage counts
  • Agent bindings

这让整个系统更像一个控制面板，而不是展示面板。

Memory Hub：它像一个控制台，而不是一个陈列柜

README 对 Memory Hub 的态度很鲜明：它不是 display board，而是 control panel。

在这个 Hub 里，用户可以做的事情包括：

  • 创建 teams 和 Agents
  • 审核、分享、装备 memory assets
  • 管理 ownership、versions、status、visibility、usage counts、Agent bindings
  • 切换 private、team、restricted 等可见性策略

它甚至定义了两层角色：

  • global System Admin：管理 users 和 teams，也可使用 Wiki、CodeGraph、Skill 等资产管理能力
  • Team-level roles：在团队层面参与协作和资产使用

这背后体现出的产品思路很明确：团队记忆不是一股脑共享出去，而是要被精细治理。

共享经验，不等于共享隐私

这是 README 里非常值得注意的一点。

TencentDB Agent Memory 明确说明：

  • 新的 Chat Memory 和 Skills 默认是 private
  • sharing 是显式动作，不是默认泄露

它支持的可见性语义包括：

  • private：只有 Owner 可读，连 team admins 也不能读
  • team：团队成员可读，Owner / Admin 可管理
  • restricted：通过 User / Role / Agent ACL 精细授权
  • agent：用于同一团队内对特定 Agent 的定向装备

这意味着，“团队可以复用经验”这件事，并不是建立在“所有信息都透明暴露”的前提上。它试图把共享与边界同时保留下来。

冷启动这件事，它想直接帮你跳过“重新学习”

README 中有一个很形象的说法：Load the Save File, Then Get to Work。

这几乎把它的冷启动思路说透了。多数 Agent 的第一个任务，其实是重新学习你的项目；而 TencentDB Agent Memory 希望把你已经付出过的学习成本，变成一份“存档”。

它可以导入并自动处理的既有资产包括：

  • Codebases：导入现有仓库，CodeGraph 自动索引符号、文件、调用关系、影响路径
  • Documents & files：导入相关文档和文件，Wiki 自动生成结构化页面与 link graph
  • Conversation sessions：导入过往 Agent 会话，Skills 和 Chat Memory 会被自动提取为可复用资产

这个设计很有意思，因为它没有要求“从今天开始规范使用系统，你以后才会变聪明”。相反，它试图让历史材料也能参与记忆建设。对已经有沉淀的团队来说，这种方式更现实。

它描绘了一种很具体的 Agent 团队协作方式

README 里给了一个非常生动的场景：为一个 one-person company 组建一个不断成长的 Agent team。

结构大致像这样：

1
2
3
4
5
6
Tiny but Serious Inc.
├── 👤 You · Set goals / Make decisions
├── 🔭 Scout · Research / Find opportunities
├── 🛠 Builder · Write code / Build products
├── 🧪 Reviewer · Test / Find issues
└── 🧠 Agent Memory · Preserve the team's experience

这段示例很能说明它的产品想象：你不是在打开四个互不相干的聊天窗口，而是在组建一个有分工、有继承关系的小队。

而且，不同角色会被分配不同的“记忆装备”：

1
2
3
4
5
6
7
8
9
10
11
12
13
14
🔭 Scout
   ├── User interview Chat Memory
   ├── Market research Wiki
   └── Competitive analysis Skill

🛠 Builder
   ├── Product Wiki
   ├── Project CodeGraph
   └── Feature Delivery Skill

🧪 Reviewer
   ├── Historical incident Chat Memory
   ├── Project CodeGraph
   └── Release Checklist Skill

这个“loadout”概念很关键。不是把所有记忆一股脑塞给每个 Agent，而是按角色分配真正有用的资产，减少噪声，让各自带着合适的经验上场。

技术实现上，它也在强调“分层”和“按需调用”

TencentDB Agent Memory 在技术实现部分讲得很清楚：它不打算“把一切都存下来”这么简单，而是试图解决三个问题：

  • 什么值得保存
  • 谁可以使用
  • 下次如何尽量少取、但取对

1. 记忆是分层生长的，不是扁平记录

对话会先以 L0 保存，再通过异步流水线提炼为更高层级的信息：

  • L0 Conversation：完整原始对话
  • L1 Atom：从对话中提取 facts、preferences、constraints、events
  • L2 Scenario：围绕项目或场景组织起来的知识块
  • L3 Core / Persona：长期画像、稳定模式和高层认知

README 还提到，生成和检索也是分层的。通常由 L2/L3 提供快速上下文启动；需要具体事实时，再通过 BM25、vector retrieval 和 RRF 回落到 L1/L0。

这种设计的味道很明确：既想保留原始依据，也想让高层抽象真正可用。

2. 记忆不是全局 prompt，而是 Agent 的 loadout

四类 memory assets 会被统一登记，而 Memory Hub 通过 Fixed Binding + ACL 来决定某个 Agent 可以用哪些资产。

这意味着，记忆不会粗暴地注入给所有 Agent；它会先按照权限和绑定关系缩小范围，再进入具体使用环节。这样做的直接结果是，团队经验可以共享，但不必牺牲私密边界。

3. 文档与代码不会被整包塞进上下文，而是按需调用

README 中强调，文档会组织为可搜索的 Wiki 页面，代码库会索引成包含 files、symbols、call relationships 的 CodeGraph 资产。Agent 会先搜索、再下钻，只在真正需要时把相关内容带入上下文。

这是一种很克制的设计。它不追求“什么都带上”，而是在强调：只有真正需要的东西，才进入当前工作现场。

从仓库结构看，它不是一个单体概念，而是一组明确分工的组件

仓库本身是一个 monorepo。仅从 README 可以看到，至少有两个关键部分：

MemoryCore

MemoryCore 被定义为 TencentDB Agent Memory 的 memory and metadata core。

它统一处理三类数据：

  • Memory：L0 conversations、L1 atomic memories、L2 scenarios、L3 profiles
  • Knowledge metadata：Wiki、Code Graph 等知识源的 identifiers、types、status、associations、service locations
  • Asset management metadata：users、teams、Agents、tasks、Skills、knowledge assets、memberships、ownership、access relationships

它通过一个 HTTP Gateway 暴露能力，OpenClaw、Hermes 和 custom applications 可以通过轻量 adapter 或 SDK 接入。

在运行形态上，MemoryCore 是 standalone runtime，适用于 local development、single-node deployment 和 Agent sidecars。README 给出的运行特征包括：

  • 默认监听 127.0.0.1:8420
  • 使用 SQLite、local files 和 in-process state
  • 除了 LLM API 外不依赖外部服务
  • 默认关闭 remote embeddings，使用 BM25 retrieval
  • 默认数据目录为 ~/.memory-tencentdb/memory-tdai

MemoryKnowledge

MemoryKnowledge 是 monorepo 中的 Knowledge Service，负责用户侧 Wiki 与 Code-Graph 引擎。

README 明确写到：

  • 默认端口 8421
  • API 前缀 /v3

它提供的能力包括：

  • LLM-Wiki
  • Code-Graph
  • Auto-Sync
  • Tools
  • 状态回调

其中 Auto-Sync 是可选的，默认关闭；它会定时扫描 code-graph，并通过 FIFO 队列和 worker pool 自动拉取 git 更新并重建索引。

这两个模块放在一起看，角色分工其实很清楚：一个偏记忆与元数据核心，一个偏文档与代码知识服务。

安装方式很直接，读起来就像“先把三件套拉起来”

README 给出的主安装方式是一次启动三个服务：memory-core、memory-hub、proxy。

1
2
3
4
5
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

仓库说明里提到，执行完成后会打印一条 one-liner，可以直接粘贴到 Claude 中。面板默认打开地址是：

1
http://localhost:8125

如果你只看这段安装说明，会感受到这个项目很想把“先跑起来”这件事做得简单一点：先把三项核心服务一口气拉起，再进入后续探索。

MemoryCore 的快速启动路径，也写得相当清楚

如果视角下沉到 MemoryCore，README 给出的 quick start 也很直接。

先安装并构建：

1
2
3
cd MemoryCore
npm install
npm run build

然后设置环境变量并启动 Standalone Gateway：

1
2
3
4
5
6
export TDAI_GATEWAY_CONFIG="$PWD/tdai-gateway.standalone.yaml"
export TDAI_LLM_API_KEY="your-api-key"
export TDAI_LLM_BASE_URL="https://api.openai.com/v1"
export TDAI_LLM_MODEL="gpt-4o-mini"

node --import tsx src/gateway/server.ts

启动之后，可以这样检查健康状态：

1
curl http://127.0.0.1:8420/health

如果需要从其他机器或容器接收流量，README 还给出了绑定地址与认证方式：

1
2
export TDAI_GATEWAY_HOST="0.0.0.0"
export TDAI_GATEWAY_API_KEY="replace-with-a-strong-random-token"

并说明启用认证后，除 /health 和 CORS preflight 外，其余 endpoint 都需要：

1
2
Authorization: Bearer <TDAI_GATEWAY_API_KEY>
x-tdai-service-id: <memory-instance-id>

这部分信息虽然是部署层面的，但也能看出项目在设计上对访问边界、实例标识和服务暴露方式是有明确约束的。

MemoryKnowledge 也给出了本地启动方法

MemoryKnowledge 的 README 同样给出了本地开发方式：

1
2
3
4
cd MemoryKnowledge
pnpm install --ignore-workspace
cp .env.example .env
pnpm dev

健康检查与文档地址是：

1
curl -s http://127.0.0.1:8421/health
1
Swagger: http://127.0.0.1:8421/docs

如果需要与 Panel 联调，README 还给出了最少环境变量示例：

1
2
3
4
5
6
7
8
PORT=8421
API_PREFIX=/v3
KNOWLEDGE_DATA_DIR=./data
KNOWLEDGE_DB_PATH=./data/knowledge.db
KNOWLEDGE_PUBLIC_BASE_URL=http://127.0.0.1:8421/v3
TMC_CALLBACK_URL=http://127.0.0.1:8123
LLM_MODE=proxy
LLM_MODEL=Memory-Model

Panel 侧则需要：

1
KNOWLEDGE_SERVICE_URL=http://127.0.0.1:8421

这些内容让项目的边界更加具体了：MemoryKnowledge 不是一个抽象名词，而是一个清晰可运行、可联调的知识服务。

它对 Agent 集成并不含糊

MemoryCore README 中列出了三类集成方式：

OpenClaw

通过 openclaw-plugin/ 下的 lightweight client adapter 接入，连接现有 MemoryCore Gateway，不会在 OpenClaw 进程中再跑第二套 memory pipeline。

安装脚本是：

1
bash MemoryCore/scripts/install-openclaw-plugin.sh

常见连接配置包括：

1
2
3
TDAI_MEMORY_ENDPOINT=http://127.0.0.1:8420
TDAI_MEMORY_API_KEY=<the same API key configured on the Gateway>
TDAI_MEMORY_INSTANCE_ID=default

Hermes

hermes-plugin/ 提供 Hermes Memory Provider，沿用同样的 adapter 模式，通过 Gateway 完成 conversation capture 和 memory recall。

Custom Agents

仓库里还包含 TypeScript 和 Python SDK：

  • sdk/memory-core/typescript/
  • sdk/memory-core/python/

README 还总结了一个 adapter 通常需要承担的三项职责：

  1. 把完成的 turns 或 sessions 写入 L0
  2. 在构造下一个 prompt 之前召回 L1/L2/L3
  3. 将召回结果以有边界、明确标注的上下文形式注入 Agent

这几句话非常关键，因为它并没有只停留在“支持某某框架”，而是把接入思路写成了行为模型。

API 面看得出，它已经把功能拆成了稳定层级

MemoryCore README 给出了一张 API surface 表。仅从这张表就能读出项目的成熟取向。

包括：

  • /capture, /recall, /search/*：兼容性接口
  • /v2/conversation/*：L0 写入、查询、搜索、删除、计数
  • /v2/atomic/*：L1 查询、搜索、更新、删除、计数
  • /v2/scenario/*, /v2/core/*：L2/L3 读写
  • /v3/conversation/*, /v3/atomic/*, /v3/scenario/*, /v3/core/*：更强隔离的数据平面，推荐新集成使用
  • /v3/skill/*：Skill 管理、搜索、版本、资源和提取
  • /v3/meta/*：User、Team、Agent、Task、Asset 与访问关系管理
  • /v3/knowledge/*：Knowledge asset metadata registration
  • /health：健康检查

其中一个很值得注意的细节是：v3 memory data plane 需要 team_id、agent_id、user_id，session_id 是可选项。这个细节说明它在设计新的数据平面时，已经把隔离维度作为默认前提。

它对“本地优先”和“少依赖外部服务”也有明显倾向

从仓库 description 到 README，再到 MemoryCore 的运行说明，可以看到一个比较一致的倾向：它强调 local-first，也强调尽量减少额外外部依赖。

MemoryCore README 中明确提到：

  • 使用 SQLite
  • 使用 local files
  • 除了 LLM API 外不要求外部服务
  • BM25 在没有 embedding provider 的情况下也可以工作

这种设计风格会给人一种“先把系统立起来”的实在感。不是先堆一串必备中间件，而是尽量用更轻的形态把记忆核心跑起来。

它还给出了一个基准结果，但很克制

README 的 Benchmark 部分只给出了一项结果：

Benchmark Without TencentDB Agent Memory With it enabled Relative improvement
PersonaMem 48% 76% +59%

并说明 PersonaMem 用来测试 Agent 在长时间交互后，是否能够正确理解并应用用户信息。

这个部分写得并不喧闹，没有铺开一长串对比，只给出一个相对单点的指标。它更像是在说明：至少在“持续理解和应用用户信息”这件事上，系统希望交出更稳定的结果。

README 里那些“尚在演进中”的部分，也很坦诚

项目没有把自己包装成一台已经定型的完美机器。README 的 Notes 里直接列出了一些当前状态：

  • Wiki 和 CodeGraph 是异步构建的，需要等待处理达到 ready
  • CodeGraph 当前优先支持 public HTTPS repositories
  • private repositories 与 SSH credentials 支持仍在完善
  • Hub 支持手动 asset binding，fully automated memory routing 仍在迭代
  • 当前支持 OpenClaw、Hermes、Claude Code、CodeBuddy 和 SDK integration，更广泛的 cross-framework migration 在 roadmap 上

这几条信息很有价值，因为它们让人更容易理解项目的边界：哪些能力已经明确具备，哪些还在继续打磨。

如果把它的气质总结成一句话，大概是：让团队走过的路，成为下一个 Agent 的起点

README 最后的那句总结非常漂亮：

Let the path the team has walked become the next Agent’s starting line.

这几乎就是 TencentDB Agent Memory 的精神内核。

它不只是想延长会话，不只是想让知识可检索，也不只是给 Agent 多配几个检索工具。它真正试图组织起来的，是一套可以跨会话、跨角色、跨 Agent 流动的经验系统。

在这套系统里：

  • 对话不只是日志，而是可提炼的记忆
  • 工作流不只是一次性操作，而是可复用的 Skill
  • 文档不只是文件夹内容，而是可探索的 Wiki
  • 代码不只是文本集合，而是可分析的 CodeGraph
  • 团队经验不只是“谁脑子里记得”，而是可以被治理、共享、装备和继承的资产

如果说很多 Agent 工具关注的是“这一轮怎么更聪明”，那么 TencentDB Agent Memory 更像是在问：

下一轮，能不能不用从头再来。

而这，恰恰是 Agent 真正走向团队协作、走向持续积累时，最不该被忽视的一步。