在 AI Agent 开发中，长期记忆一直是个绕不开的问题。上下文窗口有限，对话越长，模型越容易“忘事”。常见做法是直接截断历史消息，但这种粗暴删除往往会把关键信息一并丢掉。掘金上一篇关于 Agent Memory 的实践文章给出的思路是：让 LLM 先阅读旧对话，再把核心内容压缩成摘要，用“浓缩过去”替代“忘掉过去”。
截断与摘要压缩：两种记忆管理思路的分野
文章首先回顾了此前讨论过的三种 Memory 处理方式：消息数量截断、Token 数量截断，以及总结压缩。前两种本质上都是“无差别丢弃”——超过阈值后，旧消息不管是否重要，都会被移除；总结压缩则不同，它会把旧对话交给模型处理，提炼成一段较短但保留关键信息的摘要。
作者给出的核心流程相对清晰：先判断是否超限，再将消息拆分为“旧消息”和“最近消息”，随后由 LLM 生成摘要，清空原有历史，最后用“最近消息 + 摘要”重建上下文。文章将其类比为 Claude Code 的 /compact 命令：当对话过长时，把旧内容压缩成摘要，释放上下文窗口，同时尽量保留关键信息。
从条数到 Token：触发机制如何影响摘要质量
素材中给出了两种落地方式。第一种是按消息数量触发，例如当历史消息超过 6 条时，保留最近 2 条，将更早的 6 条交给模型总结。这种方式实现简单，适合快速验证思路，但问题也很明显：不同消息的长度差异很大，按条数控制并不能准确反映真实上下文占用。
因此，作者更推荐第二种按 Token 数量触发的方案。由于 LLM 的上下文窗口按 token 计算，而不是按消息条数计算，生产环境中以 token 作为阈值更贴近模型实际限制。示例中使用 js-tiktoken 的 cl100k_base 编码器统计消息占用，并设置总 token 上限为 200、最近消息的 token 预算为 80。这样可以在保留近期上下文的同时，把超出部分交给摘要机制处理。
- 按消息条数触发：实现简单，但难以准确匹配上下文窗口限制。
- 按 Token 触发：更贴近 LLM 真实成本与窗口约束，适合生产环境。
- 两者共同点：都需要先拆分“旧消息”与“最近消息”，再重建历史。
工程细节：摘要生成、角色选择与历史重建
在实现层面，文章使用了 LangChain.js、OpenAI 与 js-tiktoken。为了让模型理解历史内容，代码先用 getBufferString 将消息对象数组转换为可读文本，例如把 HumanMessage 与 AIMessage 转成“用户”“助手”开头的对话记录。作者指出，LLM 并不认识 LangChain 的消息对象，只认识纯文本，因此这一步是摘要生成的前提。
另一个细节是：总结任务使用 SystemMessage，而不是 HumanMessage。原因是摘要属于单轮任务调用，SystemMessage 更适合表达“任务指令”，模型输出也更干净；如果使用 HumanMessage，模型可能会加入类似“好的，我来帮你总结”的回应。作者将这一经验概括为：任务指令用 SystemMessage，对话用 HumanMessage。
在消息拆分上，示例通过负数索引完成。以保留最近 2 条为例，slice(-2) 得到最近消息，slice(0, -2) 得到需要总结的旧消息。生成摘要后，系统会清空原有历史，再重新写入最近消息，并把摘要作为最后一条 AI 消息。这样，模型后续看到的不再是完整旧对话，而是一段压缩后的上下文。
对 Agent 开发的启示：记忆管理正在走向工程化
从素材来看，这篇文章并没有追求复杂的长期记忆架构，而是聚焦一个很实际的问题：当上下文变长时，如何在不丢失关键信息的前提下降低窗口压力。相比简单截断，摘要压缩更贴近“记忆”的本意；而相比把所有历史都塞进上下文，它又更符合成本与窗口限制。
对 Agent 开发来说，这种方案的价值在于可落地。无论是聊天机器人、编程助手，还是带工具调用的智能体，都会面临历史内容持续累积的问题。素材虽未展开工具调用记忆设计，但从其“保留最近消息 + 压缩旧消息”的结构看，这种思路也可以为后续更复杂的记忆系统提供基础：先把“必须记住的信息”和“可以压缩的信息”区分开，再决定哪些内容进入模型上下文。
在 Agent 逐渐从演示走向生产的阶段，记忆管理不再只是 prompt 技巧，而正在变成一项需要精细设计的工程能力。用 LLM 总结压缩上下文，未必是最终答案，但至少提供了一条比直接截断更平滑、也更符合实际使用场景的路径。
原创文章，作者：点点，如若转载，请注明出处：https://www.dian8dian.com/agent-ji-yi-ru-he-gao-bie-jin-yu-shi-yi-wang-yong-llm-ya
