个人主页 for_ever_love__ 欢迎各位大佬莅临其他栏目: 大模型开发从0到1 其他栏目: iOS项目总结大全 其他栏目: 我想学python了 其他栏目: iOS UI 文章目录多轮对话用持久化记住历史一、核心就三步二、为什么不用手动拼历史三、常见坑四、和生产接上多轮对话用持久化记住历史聊天机器人最基础的能力是「记得刚才聊到哪」。在 LangGraph 里这件事不是靠把历史消息传来传去而是靠Checkpointer MessagesState 同一个 thread_id三者配合自动完成的。一、核心就三步fromlanggraph.graphimportMessagesState,START,ENDfromlanggraph.checkpoint.memoryimportMemorySaverfromlangchain_core.messagesimportHumanMessage,AIMessagedefbot(state:MessagesState):# 真实场景这里调用大模型读取 state[messages] 全部历史return{messages:[AIMessage(content已收到)]}graphStateGraph(MessagesState)graph.add_node(bot,bot)graph.add_edge(START,bot)graph.add_edge(bot,END)appgraph.compile(checkpointerMemorySaver())cfg{configurable:{thread_id:u-1}}之后每一次对话都用同一个 cfg去 invokeapp.invoke({messages:[HumanMessage(content你好)]},cfg)app.invoke({messages:[HumanMessage(content你叫什么)]},cfg)注意每次传入的只是一条新消息但框架会把它追加到该 thread_id 下已有的 messages 后面。模型看到的始终是完整历史。二、为什么不用手动拼历史没有持久化时你得自己维护一个 list每次把过去 N 轮塞进 prompt。问题很多历史会无限变长、跨进程就丢、多个用户要分桶管理。用了 Checkpointer历史由框架按 thread_id 自动累积add_messagesreducer不同用户天然隔离各用各的 thread_id想截断/总结历史只需读取app.get_state(cfg).values[messages]再做处理。三、常见坑忘了带 thread_id每次都传新的/空的 config图就「失忆」每轮都是第一次对话thread_id 复用混乱把不同用户的对话混到同一个 thread_id会串台历史爆长度长期会话 messages 无限增长需要在节点里加「超长则摘要压缩」的逻辑而不是无脑全传。四、和生产接上本地用 MemorySaver 调试没问题但服务一重启记忆就清空。真正上线要把 Checkpointer 换成 Postgres/Redis 后端这样即使进程重启用户的历史仍在。多轮对话的「记忆」本质上就是被持久化下来的那份 messages。
个人主页 for_ever_love__ 欢迎各位大佬莅临其他栏目: 大模型开发从0到1 其他栏目: iOS项目总结大全 其他栏目: 我想学python了 其他栏目: iOS UI 文章目录多轮对话用持久化记住历史一、核心就三步二、为什么不用手动拼历史三、常见坑四、和生产接上多轮对话用持久化记住历史聊天机器人最基础的能力是「记得刚才聊到哪」。在 LangGraph 里这件事不是靠把历史消息传来传去而是靠Checkpointer MessagesState 同一个 thread_id三者配合自动完成的。一、核心就三步fromlanggraph.graphimportMessagesState,START,ENDfromlanggraph.checkpoint.memoryimportMemorySaverfromlangchain_core.messagesimportHumanMessage,AIMessagedefbot(state:MessagesState):# 真实场景这里调用大模型读取 state[messages] 全部历史return{messages:[AIMessage(content已收到)]}graphStateGraph(MessagesState)graph.add_node(bot,bot)graph.add_edge(START,bot)graph.add_edge(bot,END)appgraph.compile(checkpointerMemorySaver())cfg{configurable:{thread_id:u-1}}之后每一次对话都用同一个 cfg去 invokeapp.invoke({messages:[HumanMessage(content你好)]},cfg)app.invoke({messages:[HumanMessage(content你叫什么)]},cfg)注意每次传入的只是一条新消息但框架会把它追加到该 thread_id 下已有的 messages 后面。模型看到的始终是完整历史。二、为什么不用手动拼历史没有持久化时你得自己维护一个 list每次把过去 N 轮塞进 prompt。问题很多历史会无限变长、跨进程就丢、多个用户要分桶管理。用了 Checkpointer历史由框架按 thread_id 自动累积add_messagesreducer不同用户天然隔离各用各的 thread_id想截断/总结历史只需读取app.get_state(cfg).values[messages]再做处理。三、常见坑忘了带 thread_id每次都传新的/空的 config图就「失忆」每轮都是第一次对话thread_id 复用混乱把不同用户的对话混到同一个 thread_id会串台历史爆长度长期会话 messages 无限增长需要在节点里加「超长则摘要压缩」的逻辑而不是无脑全传。四、和生产接上本地用 MemorySaver 调试没问题但服务一重启记忆就清空。真正上线要把 Checkpointer 换成 Postgres/Redis 后端这样即使进程重启用户的历史仍在。多轮对话的「记忆」本质上就是被持久化下来的那份 messages。
平方复杂度无法被常规优化消除｜TaoToken 统一 Key 通道实测)
