大模型生成原理与Attention机制详解

Openai SDK实现持久化存储生产级实践

技术分享
直接用 OpenAI SDK + Redis 实现“可持久化的对话记忆”，并在对话变长时自动做摘要压缩，同时支持 Function Calling（工具调用）。[1] 核心思路 • 用 Redis 存储每个 session_id 的对话消息，做到进程重启后仍能恢复上下文。 • 当消息数或粗略 token 数超过阈值时，把较早的对话生成一段摘要，摘要单独存 Redis；同时只保留最近几条原始消息，形成“摘要 + 最近消息”的结构。 主要模块 1. OpenAIRedisMemoryManager（记忆管理器） ◦ 负责：存消息、读消息、估算 token、触发摘要、保存摘要、TTL 过期、清空会话等。[1] 2. OpenAIFunctionCallingAgent（Agent 封装） ◦ 负责：加载历史（可包含摘要作为 system message）→ 追加用户输入 → 调 OpenAI Chat Completions → 若模型返回 tool_calls 则执行本地函数并把结果以 tool 角色回写 → 循环直到拿到最终回复 → 最后把消息写回 Redis（可能触发摘要）。[1] 3. 工具定义与映射 ◦ 按 OpenAI Function Calling 格式声明工具（如 search_web、calculate、get_price），并提供对应的本地函数实现与映射表。[1] 文章强调的优点 • 更轻量：不依赖 LangChain。[1] • 更可控：对消息结构、摘要策略、存储键、TTL、保留最近消息数等完全可定制。[1] • 更易调试：流程清晰，组件边界明确。
Openai SDK实现持久化存储生产级实践

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

技术分享
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，用“中间件”声明式接入自动摘要，代码更简洁、自动化程度更高。
Agent持久化记忆不同方案与生产最佳实践以及langchain1.0中的最佳实践

Agent嵌入记忆-reAct与Function call，以及1.0中的实现

技术分享
在 LangChain / LangGraph 的三种常见 Agent 构建方式里，如何“嵌入记忆（memory）”。 1）Function Call（Tool Calling）模式的记忆接入 • 用 create_tool_calling_agent + AgentExecutor 构建支持工具调用的 Agent。 • 记忆采用 ConversationBufferMemory，关键点是： ◦ return_messages=True：记忆以“消息列表”形式保存和返回，更适配聊天式上下文。 ◦ memory_key="chat_history"：让 Agent 在提示词里能读到历史对话。 • 工具侧展示了三种来源： ◦ TavilySearchResults 做实时检索 ◦ load_tools(["llm-math"]) 做数学能力 ◦ @tool 自定义工具（示例：查询价格） • 示例调用是问“今天西安天气怎么样”。 2）ReAct 模式的记忆接入 • 用 create_react_agent 构建 ReAct（思考-行动-观察）风格 Agent。 • 同样用 ConversationBufferMemory(return_messages=True, memory_key="chat_history") 注入对话历史。 • 工具组合以检索和数学为主（TavilySearchResults + llm-math）。 • 文章强调：推荐用 PromptTemplate 方式来构建 ReAct 的模板，更方便控制格式与变量。 3）LangChain 1.0 / LangGraph 的 create_agent（checkpointer）记忆方式 • 用 langchain.agents.create_agent 创建 Agent。 • 记忆不再通过 ConversationBufferMemory，而是通过 checkpoint 机制持久化执行状态： ◦ checkpointer=InMemorySaver() ◦ 通过 {"configurable": {"thread_id": "1"}} 指定同一个线程，从而让多轮对话在同一条“会话线”上延续（达到记忆效果）。 • 调用方式改为传入 messages（role/content）结构。 核心对比（一句话） • 旧式（Function Call / ReAct）：用 ConversationBufferMemory 把历史对话塞回 prompt（或消息列表）里。 • 1.0 / LangGraph 风格：用 checkpointer + thread_id 把会话状态作为“可恢复的执行上下文”保存下来，更偏“运行时状态管理”。
Agent嵌入记忆-reAct与Function call，以及1.0中的实现
123456
guderain
guderain
一个普通的干饭人🍚