用户说“还是按上次那个地址寄”系统怎样知道“上次那个地址”指什么这是聊天应用开始变得像助手的时刻也是状态管理真正变麻烦的时刻。第 6 章集中讨论 Memory。读这一章前我容易把记忆理解成“把历史对话都塞回 Prompt”读完以后最大的变化是开始区分原始记录、当前上下文和长期事实。版本说明LangChain 的记忆与 Agent 状态接口已经历多次演进。这里讨论的是记忆设计问题不建议直接照搬书中的旧类名。模型本身不会记住上一轮一次模型调用通常只看到本次请求提供的内容。所谓“记得”其实是应用在调用前读取状态、把相关信息放进上下文并在调用后保存新状态。可以把它拆成三类类型示例保存方式会话历史用户和助手的原始消息按会话持久化工作记忆本轮回答需要的最近消息或摘要动态选择后放入上下文长期记忆用户偏好、地址、任务进度结构化存储并按需读取三者混成一个无限增长的消息列表会同时带来成本、噪声、隐私和一致性问题。常见策略各自牺牲了什么完整缓冲保留全部消息最容易实现也最忠实。但对话越长token 成本越高早期关键信息还可能被大量闲聊淹没。窗口记忆只保留最近若干轮成本可控却可能把前面已经确认的重要约束丢掉。摘要记忆把旧对话压缩成摘要。它节省上下文但摘要也是模型生成的可能遗漏数字、否定条件和用户态度。摘要最好保留版本并允许回查原始消息。实体或结构化记忆抽取姓名、偏好、地址和任务状态查询效率高但需要处理更新、冲突和删除。例如用户说“以后不要寄到公司”系统不能只新增一条偏好而要正确替换旧状态。一个预约助手该怎样记假设用户先说“周五下午帮我约牙医”几轮后又说“改到下周一上午”。如果只保存聊天文本模型每次都要从长记录里重新推断最终时间。更稳妥的做法是同时维护结构化状态{service:牙医,date:下周一,period:上午,confirmed:false}模型负责从自然语言中提取候选修改程序负责日期解析、字段校验和最终写入。真正提交预约前还要把明确日期和时间展示给用户确认。这个例子也说明Memory 不只是“聊天体验功能”它已经接近业务状态管理。记忆最难的是冲突不是存储用户可能先说喜欢简洁回答后来又要求某个话题详细解释资料库可能保存旧公司名称当前会话里用户又给出新名称。因此长期记忆至少需要来源、更新时间、作用范围和可信级别。遇到冲突时可以按明确规则选择或者向用户询问而不是让模型默默猜一个。敏感信息还要考虑授权、加密、保留期限和删除能力。能保存不代表应该保存能从历史推断出来也不代表可以长期固化。这章给我的启发记忆模块真正要解决的不是“怎样装下更多聊天记录”而是“此刻哪些信息值得进入上下文”。原始消息负责追溯摘要帮助压缩结构化状态支撑业务长期记忆提供跨会话连续性。把这些职责分开系统才不会一边声称记得用户一边又把过期信息当成事实。
)
