Agent持久化记忆不同方案与生产最佳实践以及langchain1.0中的最佳实践

type

Post

status

Published

date

Jan 17, 2026

slug

summary

1) 基础实现：Redis 持久化 + Tool Calling Agent • 使用 RedisChatMessageHistory 把对话历史存到 Redis，实现跨进程、可恢复的会话记忆。 • 用 ConversationBufferMemory 直接把历史消息注入 Agent。 2) 记忆管理的三种方案（解决长对话 token 问题） 1. ConversationBufferMemory（原始全量） ◦ 优点：信息不丢。 ◦ 缺点：对话长了 token 成本高，容易超上下文窗口。 2. Trim Messages（消息修剪） ◦ 思路：只保留最近 N 条或最近一定 token 的消息（trim_messages）。 ◦ 优点：简单、可控。 ◦ 缺点：早期信息会被直接丢弃，可能导致“忘记关键信息”。 3. Summarize Messages（消息摘要，推荐） ◦ 思路：把旧消息压缩成摘要，保留“摘要 + 最近消息”。 ◦ 文中强调 ConversationSummaryBufferMemory 的优势：自动监测、自动摘要、滚动更新、对 Agent 透明。 3) 非 OpenAI 模型的兼容性坑与解决思路 • 文中指出：像 qwen-plus 这类非 OpenAI 模型在 ConversationSummaryBufferMemory 上可能因为缺少 get_num_tokens_from_messages() 而报错。 • 解决方向：自定义 token 计数 / 自定义摘要逻辑，绕开对模型内置 token 统计的依赖。 4) 生产环境最佳实践建议 • 推荐组合：Redis 持久化存储 + SummaryBuffer（或等价摘要机制）。 • 给出 ttl、max_token_limit 的配置建议，并按不同模型上下文窗口列出大致调参范围。 • 提供面向场景（如在线客服）的封装示例：用用户/工单拼接 session_id，并设置更适合长对话的 token 阈值。 5) LangChain 1.0 / LangGraph 的生产级做法 • 展示了更“工程化”的实现：自定义 RedisCheckpointerWithSummary，在保存时判断消息数或 token 数是否超阈值： ◦ 超了就把旧消息生成摘要存 Redis。 ◦ 仅保留最近若干条消息继续存储。 • 还介绍了 LangChain 1.0 的新方式：SummarizationMiddleware，用“中间件”声明式接入自动摘要，代码更简洁、自动化程度更高。

Function call Agent 持久化记忆

查看Redis中存储的对话历史

记忆管理

方案一：Trim Messages（消息修剪）

当对话历史过长时，只保留最近的N条消息，避免token超限。

早期信息会完全丢失，可能丢失重要上下文

方案二：Summarize Messages（消息摘要）

使用LLM对历史消息进行总结，用摘要替代旧消息，既保留了关键信息又节省了token。

ConversationSummaryBufferMemory 的智能之处：

自动监测: 每次对话后自动计算token数

智能摘要: 超过限制时自动调用LLM生成摘要

保留最近: 最近的消息始终完整保留

滚动更新: 摘要会基于之前的摘要继续累积

透明使用: 对Agent来说，就像在使用普通的对话历史

这就是为什么它是最佳实践：你只需要设置一个 max_token_limit 参数，它会自动处理所有复杂的摘要逻辑！

⚠️ 重要：非 OpenAI 模型的兼容性问题

如果使用非 OpenAI 模型（如 qwen-plus），ConversationSummaryBufferMemory 会报错：

原因：ConversationSummaryBufferMemory 依赖模型的 get_num_tokens_from_messages() 方法来计算 token，但非 OpenAI 模型没有实现这个方法。

解决方案：我们需要自定义 token 计数逻辑

消息摘要方法1：ConversationSummaryMemory - 只保留摘要

消息摘要方法2：ConversationSummaryBufferMemory - 摘要+最近消息（推荐）

三种记忆管理方案对比

1. ConversationBufferMemory（原始方案）

✅ 优点：保留完整对话历史，信息不丢失

❌ 缺点：对话过长时token消耗巨大，可能超出模型限制

💡 适用场景：短对话、调试阶段

2. Trim Messages（消息修剪）

✅ 优点：精确控制token数量，实现简单

❌ 缺点：早期信息会完全丢失，可能丢失重要上下文

💡 适用场景：只需要记住最近对话的场景

3. ConversationSummaryBufferMemory（推荐）

✅ 优点：既保留最近对话，又通过摘要保留早期信息，平衡性最好

⚠️ 注意：需要额外的LLM调用来生成摘要（有成本）

💡 适用场景：生产环境首选，适合长对话场景

生产环境最佳实践

参数调优建议

模型	上下文窗口	推荐max_token_limit	说明
GPT-3.5	4K	1000-1500	留出空间给prompt和输出
GPT-4	8K	2000-3000	可以保留更多历史
GPT-4-32K	32K	8000-10000	长对话场景
Claude-3	200K	20000-50000	超长对话支持
Qwen-Plus	32K	5000-8000	根据实际测试调整

LangChain 1.0 完整的生产级实现

在 LangChain 1.0 中，推荐使用模块化的方式来实现 Redis + ConversationSummaryBufferMemory

🆕 LangChain 1.0 新特性：SummarizationMiddleware

在 LangChain 1.0/LangGraph 中，可以使用 SummarizationMiddleware 中间件来实现更优雅的消息摘要功能。

优势：

✅ 声明式配置，代码更简洁

✅ 自动集成到 LangGraph 的消息流中

✅ 支持自定义摘要策略

✅ 与 Redis Checkpointer 无缝配合

总结

基础实现：Redis 持久化 + Tool Calling Agent • 使用 RedisChatMessageHistory 把对话历史存到 Redis，实现跨进程、可恢复的会话记忆。 • 用 ConversationBufferMemory 直接把历史消息注入 Agent。

记忆管理的三种方案（解决长对话 token 问题）

ConversationBufferMemory（原始全量） ◦ 优点：信息不丢。 ◦ 缺点：对话长了 token 成本高，容易超上下文窗口。

Trim Messages（消息修剪） ◦ 思路：只保留最近 N 条或最近一定 token 的消息（trim_messages）。 ◦ 优点：简单、可控。 ◦ 缺点：早期信息会被直接丢弃，可能导致“忘记关键信息”。

Summarize Messages（消息摘要，推荐） ◦ 思路：把旧消息压缩成摘要，保留“摘要 + 最近消息”。 ◦ 文中强调 ConversationSummaryBufferMemory 的优势：自动监测、自动摘要、滚动更新、对 Agent 透明。

非 OpenAI 模型的兼容性坑与解决思路 • 文中指出：像 qwen-plus 这类非 OpenAI 模型在 ConversationSummaryBufferMemory 上可能因为缺少 get_num_tokens_from_messages() 而报错。 • 解决方向：自定义 token 计数 / 自定义摘要逻辑，绕开对模型内置 token 统计的依赖。

生产环境最佳实践建议 • 推荐组合：Redis 持久化存储 + SummaryBuffer（或等价摘要机制）。 • 给出 ttl、max_token_limit 的配置建议，并按不同模型上下文窗口列出大致调参范围。 • 提供面向场景（如在线客服）的封装示例：用用户/工单拼接 session_id，并设置更适合长对话的 token 阈值。

LangChain 1.0 / LangGraph 的生产级做法 • 展示了更“工程化”的实现：自定义 RedisCheckpointerWithSummary，在保存时判断消息数或 token 数是否超阈值：

◦ 超了就把旧消息生成摘要存 Redis。 ◦ 仅保留最近若干条消息继续存储。 • 还介绍了 LangChain 1.0 的新方式：SummarizationMiddleware，用“中间件”声明式接入自动摘要，代码更简洁、自动化程度更高。