一、先搞清楚：AI Agent 为什么需要“记忆”？

从日常场景说起：你是一个“做菜助手”，次再问“需要哪些食材”。不过，如果助手没有记忆就会忘记之前的对话。导致每一次回答都像在和陌生人交流，让使用者感到极度崩溃。

“记忆”的本质是让 AI 能携带过去的聊天记录一起思考，这样就能实现连贯、多轮对话。

关键概念的观点是。

• SystemMessage: 定义 AI 的角色与规则，例如“你是一个友好幽默的做菜助手”。老实说，
• UserMessage: 使用者发出的文字。
• AIMessage: AI 的回复。

完整请求通常为：程序消息 + 历史消息 + 当前使用者消息拼接后发送给模型。可以把它想象成给模型打开一份笔记本，让它看到所有历史记录。

二、记忆放在哪里？三种存放方式

. 内存记忆

src/history-test.mjs 中使用的是内存数组来存放聊天记录。这是一种只在程序运行期间有效、零成本但易失效的方法。再看缺点，

• 短期持久性不足: 程序重启后记录全失。适合临时会话，怎么说呢，
• 无法跨会话共享信息: 每个进程独立。无法服务多使用者，

. 文件记忆

src/history-test2.mjs / src/history-test3.mjs 展示了将聊天记录写入文件。如 /chat_history.json

const history = new FileSystemChatMessageHistory({
filePath,sessionId,});

痛点：文件读写速度慢，当历史条数达到几万条时每次读取整个文件既慢又占用大量内存。

. 向量记忆

痛点：部署向量数据库需要额外资源与运维成本，但这也是最常用且可 的方法。

import { Milvus } from "@langchain/community/vectorstores/milvus";

• 原理：* 将文本转为 embedding 向量；* 用向量相似度检索相关历史；* 给模型仅发送最相关几条，而非全部历史。
• * 高效检索；* 节省 token 与算力成本；* 支持长期持久化与大规模并发。
• * 初始 embedding 与检索配置需手工调优；* 对硬件资源有一定要求。

三、主要难点：与 token 消耗

. 什么是 token？

Ai 模型按 token 而非字/词计数。其实，例如中文约半个字符/词算一个 token。每一次输入输出都消耗 token，直接影响费用与响应速度。

. 什么是？

Ai 模型有固定大小，例如 GPT‑4 的窗口约 32k tokens。若输入超出此限制，则会报错或自动截断前置内容。换个角度即使我们保存了大量历史，对话也只能保留最近可见部分——这正是 Agent 面临的主要瓶颈。

. 截断策略

const trimmedMessages = allMessages.slice;// 按条数截断
const trimmedMessages = await trimMessages(allMessages。{
maxTokens,tokenCounter: async => countTokens,strategy: "latest",});

• 按条数截断： 只保留最近 N 条记录；简单但可能误删关键旧信息。
• 按 token 数量截断： 精确计算每条占用多少 token，只保留最新且总计未超预算的信息；更适合生产环境，不同 LLM 的编码方式不同，需要专门库如 js-tiktoken 来准确计数。

. 三大管理手段综述 – 截断、、检索

• 截断 : 装不下就删掉最旧部分；老实说，最快速但信息损失最大。适用于极限情况，如对话频繁刷新而无必要保留所有细节时。
• : 用模型把远古对话浓缩成一句摘要，再将摘要加入当前上下文；既节省空间又保持主要信息，可配合截断使用。例如在大模型中先调用 “长文本摘要” 接口，接下来把摘要放回上下文里继续推理。
• 检索 : 使用向量数据库基于相似度挑选最相关历史片段，仅送入模型以降低 token 消耗并提高回答质量。这正是现代 Agent 的主流方案，也是上面提到的向量存储实现方式所对应的功能块。

. 实际业务中的痛点与方法

• 数据丢失 & 重启问题： 

: AI Agent 的记忆机制不是单一技术。而是一套综合治理方案，需要权衡速度、持久性、成本和安全等多维度因素。怎么说呢，在设计时请先评估业务场景再选择合适的实现方法。并合理组合截断、及检索等手段，以建立高效可靠且具可维护性的 Agent 程序。