腾讯云Agent Memory实测：AI终于有记忆了

liuyuyan6100

291人浏览 · 2026-08-23 16:04:19

liuyuyan6100 · 2026-08-23 16:04:19 发布

title: “腾讯云 Agent Memory 实测：给 AI 装上长期记忆”
author: “Aiclaw”
tags: [Agent Memory, 腾讯云, 知识库, AI Agent, MemoryCore, 学习总结]
source_url: “https://blog.aiclawonline.website”
digest: “腾讯云 Agent Memory 实测：给 AI 装上长期记忆”

最近在跟一个开源项目：腾讯云的 TencentDB Agent Memory（仓库 TencentCloud/tencentdb-agent-memory）。它解决的问题很朴素，但之前一直没人做成工程化的系统——怎么让 AI Agent 别每次都从零开始。

这篇文章是我边读源码边记的学习总结，不是软文。我会把它的定位、架构、记忆是怎么一层层"长"出来的、怎么检索和治理、以及本地怎么跑起来，都讲清楚。最后再聊聊我作为同时做嵌入式和 Agent 的人，为什么觉得这个项目有意思。

一、它到底解决什么问题

用 Agent 写代码、做运维的人多少都遇到过：同一个项目，换一轮对话就得重新解释背景；同一份文档，每个 Agent 都要重新读一遍；某个工作流踩过的坑，下一个 Agent 照样再踩一遍。

重复解释上下文、重复读文档、重复发现工作流——这三件"重复"，就是 Agent Memory 想消灭的。

它的定位是原话：team-level memory hub for AI Agents——把对话、文档、代码转化成四种可复用的记忆资产（Chat Memory / Skill / LLM-Wiki / Code-Graph），然后在 Agent 和框架之间做治理、共享、装备。

注意一个区分，项目自己反复强调的：它不是聊天记录仓库。RAG 只回答"能不能找到"，而 Team Memory 还要回答"谁能⽤、哪版有效、该给哪个 Agent"。前者是检索，后者是治理。

口号很直白：Agents remember. Humans innovate.

二、四大模块怎么拆

整个仓库拆成四块，职责边界很清晰：

模块	干什么	我读到的一点细节
MemoryCore	记忆与元数据核心	存 L0–L3 记忆、资产元数据；通过 HTTP Gateway（默认 `:8420`）对外；SQLite + 本地文件，默认 BM25 召回
MemoryKnowledge	知识解析/索引/检索	只存元信息，不存知识内容本身；Wiki 解析、CodeGraph 构建、索引检索都在这里
MemoryPanel	团队记忆面板（前端）	人类可控的控制台：Team Up / Asset Library / Agent Loadout / Knowledge Workshop / Access Control
MemoryProxy	代理层	用不变的协议做零代码集成，Agent 通过 `/v3/tools/list` 发现能力、用 `/v3/tools/call` 读取页面/源码/影响路径

一个容易绕晕的点：MemoryCore 不存知识内容。比如你导入一份产品文档，MemoryCore 只登记"这是哪个知识源、什么类型、状态、关联关系、服务地址"，真正的解析和检索交给 MemoryKnowledge。这种"元数据与内容分离"的切分，后面做权限和迁移都会轻松很多。

三、记忆是怎么"长"出来的：L0–L3

这是整个项目我最想弄懂的部分。它把记忆分成四层，对话先落 L0，再由异步流水线精炼成更上层的资产：

L0 Conversation：原始对话，带完整上下文、时间戳、来源。用来核验原话。
L1 Atom：从对话里抽出的事实、偏好、约束、事件。精确召回可执行信息。
L2 Scenario：围绕项目/场景组织的知识块。快速恢复工作环境。
L3 Core / Persona：长期画像、稳定模式、高层认知。让 Agent 一上来就进入用户/团队上下文。

精炼是异步的——不是每轮对话实时蒸馏，而是流水线在后台慢慢把 L0 往上聚合。文档和代码走另一条路：文档 → Wiki 页（带链接图，可以下钻）；代码 → CodeGraph（索引符号、文件、调用关系、影响路径）。

闭环是这个设计的精髓。项目里有句话我抄在笔记里：“无记忆的循环只是更快地重复；有继承记忆的循环，每次迭代都可能优于上次。” 有价值的交互存成 Chat Memory → 验证过的工作流蒸馏成 Skill → 文档/代码变更触发 Wiki ingest 和 CodeGraph sync。

四、检索与治理：比"能找到"多做一步

检索上它不偏科：常规用 L2/L3 快速 bootstrap，需要具体事实时回退 L1/L0，底层是 BM25 + 向量检索 + RRF（倒数排名融合）。结果还受 item count、字符预算、timeout 三重限制，防止上下文被一次塞爆——这个细节很务实，RAG 翻车往往就翻在把太多东西一股脑塞进 prompt。

治理是它和单纯向量库拉开差距的地方：

可见性语义：private（仅 Owner）、team（团队可读）、restricted（按 User/Role/Agent 做 ACL 精确授权）、agent（团队内定向装备）。
Fixed Binding + ACL：先按 Team/User/Agent/visibility 把资产权限收窄，再按 query 检索。某 Agent 到底能用哪些资产，是这套机制决定的。
生成溯源：L1/L2/L3 实际用的 Prompt ID、版本、来源、内容 SHA-256 都会记下来，能按 Memory ID 精确定位生成日志。但不存 Prompt 正文快照——既保证可溯源，又避免把策略本身当数据囤积。

五、冷启动与团队玩法

"冷启动友好"不是口号。它可以导入已有代码库（CodeGraph 自动索引）、文档（Wiki 自动生成）、历史会话（自动抽取 Skill 和 Chat Memory）——项目里管这叫 “加载存档（load the save file）”。新接手的 Agent 团队不用从空白开始，直接继承已有经验。

团队玩法的例子也讲得挺实在：一个叫 “Tiny but Serious Inc.” 的小团队，成员有 You / Scout / Builder / Reviewer，加上 Agent Memory。不同角色装备不同资产——Scout 带用户访谈的 Chat Memory 和市场 Wiki，Builder 带产品 Wiki 和 CodeGraph。同一套记忆底座，按角色切出不同视图。

六、怎么跑起来（本地实操）

我就在 feat/server_team 分支上跟的，本地起 MemoryCore 很轻：

# MemoryCore 以 Standalone Runtime 开源
cd MemoryCore
npm install
npm run build

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

Gateway 默认监听 127.0.0.1:8420，用 SQLite、本地文件、进程内状态，除 LLM API 外没有必需的外部服务，默认还关闭远程 Embedding、走 BM25——这对本地单机很友好。数据默认写在 ~/.memory-tencentdb/memory-tdai。

想一把起全套（memory-core + memory-hub + proxy 三服务），用仓库里的部署脚本：

cd deploy/global-images
cp .env.example .env      # 填两组 LLM 参数（memory group + proxy group）
./start-all.sh            # 启动后打印一行可贴进 Claude/CodeBuddy 的命令

面板地址是 http://localhost:8125。

接 Agent 的 Adapter 只需要做三件事，项目文档写得很克制：会话结束或每轮完成后写 L0；构造 Prompt 前召回 L1/L2/L3；把召回结果以有边界、可识别的上下文注入 Agent。 接 OpenClaw 有现成的 openclaw-plugin/，接 Hermes 有 hermes-plugin/，自定义 Runtime 直接用 sdk/memory-core/ 下的 TS/Python SDK。已适配的 Agent 列表里能看到 DeepSeek Harness、Claude Code、Codex、CodeBuddy、WorkBuddy、Hermes、OpenClaw，没列到的也给了 Generic 接入指南。

七、我记下的几个坑和判断

边读边踩（或者说边读边预判）的几个点：

Wiki / CodeGraph 是异步构建的，导入后得等它 ready，不是马上能查。做自动化流水线要把这个延迟算进去。
CodeGraph 当前优先公开 HTTPS 仓库，私有 / SSH 支持还在完善。内网代码库要接得再等等。
v2 → v3 数据迁移要先跑脚本，而且文档明确说"迁移前务必备份整个数据目录"。数据格式从 v2 升到 v3，启动新版 Gateway 前先 python scripts/migrate-v2-to-v3/v2-to-v3-migrate.py <数据目录> --dry-run 探一下。
安全上，非回环地址监听必须设 TDAI_GATEWAY_API_KEY，CORS 默认关闭别用 *，Secret 全走环境变量。这些是底线。
有个基准数据挺能说明价值：PersonaMem 基准上相对提升 +59%（48% → 76%），也就是长期画像记忆让 Agent 跨会话理解明显变好。

为什么我会盯着这个项目？我自己一半精力在 ESP32 这类嵌入式上，另一半在 Agent。嵌入式侧我在研究 ESP-Claw——一个把 Agent Runtime 烧进芯片、让设备本地决策的框架。云端 Agent 和边缘 Agent 看起来两头，但记忆底座可以是同一套：开发时用 Agent 写固件、把踩过的坑存成 Skill；设备上 Agent 通过 MCP 连了传感器后，也能回中心侧记忆做上下文。TencentDB Agent Memory 这套"记忆与执行分离、治理跨框架"的思路，正好是这个图景里缺的那块拼图。