做 AI Agent 的人大概都踩过同一个坑——对话越长,Agent 越蠢。不是模型能力不行,是上下文窗口塞满了碎片信息,关键指令被淹没,历史经验每次都要从头再来。腾讯云数据库团队刚开源的 TencentDB Agent Memory,瞄准的就是这个问题:用分层记忆 + 符号化存储,让 Agent 在超长任务中保持清醒,在跨会话场景里复用经验。
项目采用 MIT 协议,开箱即用。下面拆解它的核心思路,再给一个可直接跑的集成示例。
Agent 为什么需要"记忆引擎"
当前主流 Agent 框架对记忆的处理相当粗糙——要么把整个对话历史塞进 prompt,要么只保留最近 N 条消息。两种做法在短任务里勉强够用,一旦遇到以下场景就崩:
- 超长 session:调试一个复杂 bug,对话超过 50 轮,早期关键决策被截断丢失。
- 跨会话协作:昨天做的数据清洗流程,今天要复用,但 Agent 对昨天的事一无所知。
- 多人工作流:不同用户有不同偏好和操作习惯,Agent 无法区分和适配。
根本矛盾是:原始对话文本是低密度信息载体,直接灌进上下文窗口,既浪费 token 又干扰推理。TencentDB Agent Memory 的解法是——把原始信息提炼成符号化记忆,按层级组织,按需检索。
分层记忆:短期缓冲 + 长期沉淀
项目把 Agent 记忆分成至少两个层级(根据开源文档和评测描述推断):
| 层级 | 作用 | 生命周期 | 存储形式 |
|---|---|---|---|
| 工作记忆(Working Memory) | 当前任务的上下文、最近决策 | 单次 session | 符号化摘要,随任务结束可归档 |
| 长期记忆(Long-term Memory) | 跨会话的经验、用户偏好、工作流模板 | 持久化 | 结构化知识条目,支持检索召回 |
关键设计点:
- 符号化而非原文存储——不是把用户说的每句话存下来,而是提取出"用户偏好 JSON 格式输出""上次排查发现根因是端口冲突"这类结构化事实。信息密度高,token 消耗低。
- 按需召回而非全量注入——每次推理只检索与当前任务相关的记忆条目,而不是把所有历史一股脑塞进 prompt。
- 经验可沉淀可复用——一个成功的工作流可以被抽象成模板,下次同类任务直接加载。
评测数据提到"超长 session"场景下 Agent 表现显著提升,逻辑上也站得住:符号化摘要让关键信息不被截断,分层检索让推理始终聚焦。
实战集成:把 Agent Memory 接入你的工作流
项目 MIT 协议开源,可以直接 pip 安装或克隆仓库使用。以下是一个最小可运行示例,展示如何让 Agent 在多轮任务中保持记忆。
安装
pip install tencentdb-agent-memory
# 或克隆源码
git clone https://github.com/Tencent/TencentDB-Agent-Memory.git
cd TencentDB-Agent-Memory
pip install -e .
最小集成示例
以下代码假设你已有 OpenAI 兼容的 LLM 接口,展示 Agent Memory 的核心用法——创建记忆引擎、存储工作记忆、跨会话召回长期记忆:
from tencentdb_agent_memory import MemoryEngine
from openai import OpenAI
# 1. 初始化分层记忆引擎
memory = MemoryEngine(
persist_dir="./agent_memory_store", # 持久化目录,长期记忆落盘
working_capacity=20, # 工作记忆条目上限
)
llm = OpenAI(base_url="https://api.openai.com/v1", api_key="your-key")
def agent_run(session_id: str, user_input: str) -> str:
# 2. 召回与当前任务相关的记忆
recalled = memory.recall(
session_id=session_id,
query=user_input,
top_k=5, # 最多召回 5 条相关记忆
include_long_term=True, # 同时检索长期记忆
)
# 3. 构造带记忆上下文的 prompt
memory_context = ""
if recalled:
memory_context = "\n## 相关记忆\n"
for item in recalled:
memory_context += f"- [{item.layer}] {item.content}\n"
prompt = f"""你是一个数据分析助手。
{memory_context}
## 用户输入
{user_input}
请基于以上记忆和输入给出回答。如果记忆中有相关经验,优先复用。"""
# 4. 调用 LLM
response = llm.chat.completions.create(
model="gpt-4o-mini",
messages=[{"role": "user", "content": prompt}],
)
answer = response.choices[0].message.content
# 5. 将本轮关键信息符号化存入记忆
memory.store(
session_id=session_id,
content=user_input, # 原始输入
summary=answer[:200], # 提取摘要(实际应做结构化提取)
layer="working", # 先存工作记忆
auto_promote=True, # 达到阈值自动提升为长期记忆
)
return answer
# --- 跨会话演示 ---
# 第一轮会话:建立偏好
print("=== Session 1 ===")
print(agent_run("session-001", "我需要分析销售数据,输出格式请用 Markdown 表格。"))
# 第二轮会话:复用偏好(新 session,但长期记忆可召回)
print("\n=== Session 2 (新会话) ===")
print(agent_run("session-002", "帮我分析上周的用户增长数据。"))
# Agent 应自动召回"用户偏好 Markdown 表格"的长期记忆
# 查看记忆状态
print("\n=== 记忆盘点 ===")
stats = memory.stats()
print(f"工作记忆条目: {stats.working_count}")
print(f"长期记忆条目: {stats.long_term_count}")
运行前需要修改的地方:
api_key换成你自己的 OpenAI key,或替换为其他兼容接口。persist_dir可改为任意本地路径,长期记忆会以文件形式持久化。summary字段在实际项目中应做更精细的符号化提取,而非简单截断。
符号化提取的进阶做法
上面的示例用 answer[:200] 做粗略摘要,生产环境应该做结构化提取。一个实用模式:
import json
def extract_facts(user_input: str, answer: str) -> list[str]:
"""让 LLM 自行从对话中提取符号化事实"""
extract_prompt = f"""从以下对话中提取可复用的结构化事实,每条事实一行,格式:
- 偏好类: "用户偏好 X 格式"
- 决策类: "选择方案 Y 因为 Z"
- 发现类: "根因是 W"
用户: {user_input}
助手: {answer}
"""
resp = llm.chat.completions.create(
model="gpt-4o-mini",
messages=[{"role": "user", "content": extract_prompt}],
)
return resp.choices[0].message.content.strip().split("\n")
# 替换 store 调用中的 summary
facts = extract_facts(user_input, answer)
for fact in facts:
memory.store(
session_id=session_id,
content=fact,
summary=fact,
layer="working",
auto_promote=True,
)
这样存入记忆的是"用户偏好 Markdown 表格"而非一大段原文,召回时信息密度高、干扰小。
什么场景值得接入
不是所有 Agent 都需要记忆引擎。判断标准很简单:
| 场景 | 是否需要 | 原因 |
|---|---|---|
| 单轮问答、一次性任务 | ❌ | 无跨会话需求,上下文窗口够用 |
| 多轮调试/排障、对话超 20 轮 | ✅ | 工作记忆防止关键信息被截断 |
| 重复性工作流(定期报表、常规运维) | ✅ | 长期记忆沉淀模板,减少重复指令 |
| 多用户个性化服务 | ✅ | 按用户隔离长期记忆,适配偏好 |
边界与风险
接入前需要留意的几个点:
- 记忆污染——如果 Agent 存了错误结论(比如误判根因),后续会持续召回错误经验。需要设计记忆校验或过期机制,项目当前版本建议定期清理
persist_dir。 - 隐私隔离——多用户场景下,长期记忆必须按用户 ID 隔离存储,避免 A 的偏好被召回给 B。
recall接口应始终带user_id过滤。 - token 成本——符号化记忆降低了注入量,但召回本身需要一次检索计算,加上可能的提取调用,每轮多 1-2 次 LLM 请求。在低成本场景要评估是否划算。
- 项目成熟度——刚开源,API 可能随版本迭代调整。生产接入建议锁定版本号,关注 GitHub 的 release 更新。
上手清单
如果你决定试用,按这个顺序走:
pip install tencentdb-agent-memory,跑通上面的最小示例。- 用真实业务对话替换示例中的
user_input,观察记忆召回效果。 - 实现
extract_facts做符号化提取,对比原始截断和结构化存储的召回质量。 - 在多会话场景测试长期记忆的跨会话复用。
- 评估记忆条目增长速度,设定清理或归档策略。
MIT 协议意味着你可以自由修改和嵌入商业项目。核心价值不在代码量,而在那套分层 + 符号化的记忆组织思路——把 Agent 从"每次从零开始"变成"越用越懂你"。