先亮明核心判断：AI智能体想要真正"记住你"，不能只靠LLM自身。这个话题，值得展开聊聊。
为何需要记忆？
LLM 本身是无状态的——每次调用都是全新的开始。Agent 要想维持连贯的对话、记住用户的偏好，甚至在跨会话的场景中积累知识，就必须在外部管理记忆。说白了，记忆模块就是在回答一个核心问题："哪些信息应该被放进下一次 LLM 调用的 context 里？"
注意，这里必须区分两个概念：memory 和 data。它们是两码事。memory 不是数据库里存储的所有聊天记录，这个边界一定要拎清。
短期记忆（Short-term Memory）
短期记忆其实就是当前 session 的对话历史，直接拼进 prompt 的 messages 数组里。
核心挑战在哪儿？Context Window 有限，通常是 8k～128k tokens，必须做管理。常用的方法有这么几种：
- Sliding Window（滑动窗口）：每次只保留最后 x 条数据，简单粗暴，但早期信息会丢失。
- Token 精确裁剪：按照模型限制的 token 数量直接裁切，同样会丢失早期信息。
- Summarization（摘要压缩）：当对话太长时，不是粗暴丢弃，而是把老消息压缩成摘要、保留语义。这是更智能的做法。
下面是一个典型的 SummaryMemory 实现，代码本身不难理解：
class SummaryMemory {
constructor(client, summaryThreshold = 10) {
this.client = client; // Anthropic client
this.summaryThreshold = summaryThreshold;
this.summary = ""; // 历史摘要
this.recentMessages = []; // 近期完整消息
}
async add(role, content) {
this.recentMessages.push({ role, content });
if (this.recentMessages.length >= this.summaryThreshold) {
await this._compress();
}
}
async _compress() {
const historyText = this.recentMessages.map((m) => `${m.role}: ${m.content}`).join("\n");
const prompt = this.summary
? `已有摘要：${this.summary}\n\n新增对话：\n${historyText}\n\n请更新并合并为一段新摘要，保留关键信息。`
: `请将以下对话压缩为简洁摘要，保留关键事实和用户意图：\n\n${historyText}`;
const res = await this.client.messages.create({
model: "claude-opus-4-6",
max_tokens: 500,
messages: [{ role: "user", content: prompt }],
});
this.summary = res.content[0].text;
this.recentMessages = []; // 清空，等待新消息积累
}
getMessages() {
const messages = [];
// 把摘要作为 system-level 的上下文注入
if (this.summary) {
messages.push({
role: "user",
content: `[对话历史摘要]: ${this.summary}`,
});
messages.push({
role: "assistant",
content: "好的，我已了解之前的对话背景。",
});
}
return [...messages, ...this.recentMessages];
}
}长期记忆（Long-term Memory）
长期记忆是跨越会话存在的，需要持久化存储。它主要分为两个层次：用户画像（结构化）和语义记忆（向量化）。
用户画像
把用户的偏好、基本信息等结构化数据存进数据库，PostgreSQL 或 MongoDB 都行。每次对话开始时，读取并注入 system prompt：
// 用 PostgreSQL / MongoDB 均可，这里示意结构
class UserProfileMemory {
constructor(db) {
this.db = db;
}
async updateProfile(userId, newFacts) {
// newFacts 来自 LLM 对对话的信息抽取
await this.db.collection("profiles").updateOne(
{ userId },
{ $set: { ...newFacts, updatedAt: new Date() } },
{ upsert: true }
);
}
async getSystemPrompt(userId) {
const profile = await this.db.collection("profiles").findOne({ userId });
if (!profile) return "";
return `用户基本信息：
- 姓名：${profile.name || "未知"}
- 职业：${profile.occupation || "未知"}
- 偏好语言：${profile.preferredLang || "中文"}
- 已知背景：${profile.background || "无"}`.trim();
}
// 让 LLM 从对话中自动抽取用户信息
async extractAndSa ve(userId, conversation, client) {
const res = await client.messages.create({
model: "claude-opus-4-6",
max_tokens: 300,
messages: [{
role: "user",
content: `从以下对话中抽取用户的个人信息和偏好，以 JSON 格式返回（只返回 JSON）：
对话：${conversation}
可抽取字段：name, occupation, background, preferredLang, interests 等`
}]
});
try {
const facts = JSON.parse(res.content[0].text);
await this.updateProfile(userId, facts);
} catch (e) {
console.log("抽取失败，跳过");
}
}
}语义记忆
这是长期记忆的核心。把历史对话、知识片段 embedding 成向量存储，对话时用当前 query 做相似度检索，把最相关的记忆片段注入 context。
写入流程：文本 → Embedding API → 向量 → 存入 VectorDB（附带原文 metadata）
读取流程：当前 query → Embedding → 相似度搜索 → 取 Top-K 原文 → 注入 prompt
这里有一个很现实的问题：需要存储的并不是所有的对话记录，而是"值得被记住"的信息。但这个概念本身就很模糊，怎么判断哪些值得被记忆？
实际执行时，有一种比较好实现的解决方案：在每轮对话结束时，让 LLM 总结本轮对话的概述，然后记录在 Vector DB 里。每轮结束就是这样：直接存（或先压缩成摘要再存），检索时用相似度阈值过滤，只有真正相关的才会被召回。
另外，如何识别一轮对话结束？并不是浏览器关闭了就是对话结束——浏览器不关闭，对话也可能自动终止（比如用户长久无响应）。实际更常用的触发时机有两种：
方式一：Redis TTL 过期时触发。 会话 30 分钟无活动自动过期，在 key 过期的回调里执行总结和存储。Redis 有 keyspace notification 机制可以监听过期事件。缺点是需要额外配置，稍复杂。
方式二：每隔 N 轮自动触发（更常用）。 不依赖退出事件，每累积 10 轮对话就自动总结一次存入 Vector DB，滚动进行：第 10 轮结束 → 总结前 10 轮 → 存 Vector DB；第 20 轮结束 → 总结 11-20 轮 → 存 Vector DB……
这样，即使用户直接关掉页面，已经发生的对话也不会丢失，最多丢最近不足 N 轮的部分。
短期记忆 + 长期记忆 结合
生产环境里，两者是结合使用的：
每次对话请求，走这样一条链路：
- 1. 读取用户画像 → 注入 system prompt 头部
- 2. 向量召回相关历史记忆 → 注入 system prompt 中部
- 3. 取近期对话窗口 → 作为 messages 数组
- 然后调用 LLM → 返回结果
- 之后：存入向量DB（长期记忆写入） + 更新对话窗口（短期记忆更新）
组装示例：
async function buildContext(userId, currentMessage) {
const [profile, recalled, recentMsgs] = await Promise.all([
profileMemory.getSystemPrompt(userId),
recallMemory(userId, currentMessage, 3),
shortTermMemory.getMessages(),
]);
const recalledText = recalled.map(r => `[记忆] ${r.content}`).join("\n");
const system = [profile, recalledText].filter(Boolean).join("\n\n");
return { system, messages: recentMsgs };
}详细流程图
LLM 永远是无状态的。你感觉它"记得你"，其实完全是每次请求前，你在外部把记忆拼进 payload 造成的。流程图里的③构建 Context 就是这个核心步骤。
读取是并行的，写入是异步的。三路读取用 Promise.all 同时发起，压缩到约 30ms；写回不阻塞用户响应，在 setImmediate 或消息队列里处理。
Redis 的 TTL 是短期记忆的"自然死亡"机制——每次用户发消息都 RESET TTL，30 分钟无活动自动销毁，不需要写任何清理代码。
最后提一个容易被忽略的点：摘要压缩是有损的，它牺牲细节换取空间。所以重要的信息（用户偏好、关键事实）应该在写回时单独抽取存进 PostgreSQL，而不是只靠摘要保留。
根据流程图提取的时序图：
记忆，从来不是"存下来"那么简单。怎么存、存什么、什么时候丢，才是真正考验架构设计的地方。
