为什么 Agent 记忆不是简单的 RAG：Context 管理的三个层次

很多人第一次接触 Agent 记忆时，会问一个合理的问题："这不就是 RAG 吗？"

表面上看确实像：都是存信息、检索信息、把结果放进上下文。但一旦深入使用，差异就显现了。本文从 Context 管理的角度，说清楚两者的本质区别。

RAG 回答什么问题

RAG 的核心流程：文档分块 → 向量化 → 用户提问时检索相关块 → 拼入提示词。

它回答一个问题："能找到什么信息？"

找到之后，信息以原文块的形式进入上下文。RAG 不关心：

• 这条信息归谁所有
• 它是第几版
• 谁有权看到它
• 它是否可被复用为工作流
• 下次任务还需不需要它

换句话说，RAG 是"检索增强生成"，不是"记忆管理"。

Agent 记忆需要回答什么问题

Agent 记忆系统不止要回答"能找到什么"，还要回答三个 RAG 不处理的问题：

Context 管理的三个层次

层次一：信息检索（RAG 所在的层次）

把文档切块、向量化、按问题检索。信息来源是静态文档，检索结果是原文块。

适用场景：知识库问答、文档搜索。

局限：无法处理动态生成的对话信息，没有所有权概念，结果无版本管理。

层次二：对话记忆（Mem0 / Letta 所在的层次）

把对话摘要存储，按语义相似度检索。信息来源是对话，检索结果是摘要。

适用场景：单 Agent 跨会话保留上下文。

局限：记忆类型单一（只有对话摘要），不支持可执行工作流，无团队级共享和权限管控。

层次三：结构化记忆资产（TencentDB Agent Memory 所在的层次）

记忆不是一个列表，而是一个资产库，包含四种不同类型：

这意味着什么？Agent 不仅能"找到信息"，还能：

• 复用经验：Skill 让"踩过的坑"变成可执行流程，团队共享
• 理解结构：Wiki 让 Agent 知道文档之间的关系，CodeGraph 让它知道改代码的影响
• 控制权限：private 默认，显式共享，ACL 精确授权

具体场景对比

场景：Agent 需要知道用户的代码风格偏好

场景：新 Agent 加入团队，需要快速了解项目

集成方式

TencentDB Agent Memory 通过 Proxy 代理集成，Agent 的 base URL 指向 Proxy 即可，无需插件、Hook 或 MCP Server。

支持：DeepSeek Harness · Claude Code · Codex · CodeBuddy · WorkBuddy · Hermes · OpenClaw

MIT 协议。PersonaMem 基准：48% → 76%（+59%）。

git clone https://github.com/TencentCloud/TencentDB-Agent-Memory.git
cd TencentDB-Agent-Memory/deploy/global-images
./start-all.sh

仓库地址：https://github.com/TencentCloud/TencentDB-Agent-Memory