大多数客服 Agent 只擅长回答眼前这条消息。真正难的是同一个客户一周后再来，Agent 完全不知道之前发生过什么。作者用 Hindsight 构建了一个带持久记忆的客服 Agent，让历史对话不只是聊天记录，而是下一次交互可用的上下文。
传统 LLM 客服流程是「客户 → 客服界面 → LLM → 回复」，单次对话没问题，跨对话就暴露短板：客户要重复信息、之前的决定从上下文消失、偏好和反复出现的问题难以维持、回复变得重复、长对话回传给模型的成本越来越高。
架构上把面向用户的应用、Agent 推理和持久记忆分开。Hindsight 不作为又一个提示词模板，而是充当对话之间的记忆层，提供三个核心操作：retain 把信息处理成结构化记忆，recall 检索这些记忆，reflect 从相关记忆中综合出回复。
保留对话时，把值得留存的内容写入客户自己的记忆库，不需要手动把每句话转成数据库记录，Hindsight 会提取结构化记忆、实体和关系，而不是把整段对话当成一个大文本块塞进向量库。
检索时，recall 会组合语义、关键词、图谱和时间等多种检索方式。客户很少重复上次的原话，比如「我的替换件好了吗」这种问法，单靠关键词搜索往往不够。
最后把当前请求和检索到的记忆拼进提示词，让模型避免追问客户历史里已有的信息。流程从「消息 → LLM → 回答」变成「消息 → 检索相关记忆 → 合并记忆与当前请求 → LLM → 有上下文的回答」。
记忆需要边界。作者不希望系统盲目记住每句问候或临时对话，有用的是能帮到未来交互的信息，比如客户偏好邮件沟通、已完成某步排查、替换件在某日获批；「你好」「谢谢」这类则价值不大。Hindsight 支持 retain mission，可以引导提取时关注问题、偏好、解决方案、承诺和客户上下文。
有了记忆后，系统还能支撑更多工作流：回头客直接调取相关历史而不用重开对话；同一问题反复出现时旧案例成为上下文；跟进时引用之前的承诺和事件；稳定的客户偏好影响后续交互；需要转人工时把相关历史一并提供，而不是让客户重讲一遍。
作者的核心体会是：上下文窗口不等于记忆，往提示词里塞更多历史不会自动变成好的记忆系统；记忆要有目的，检索策略是应用架构的一部分而非实现细节；时间很重要，客服天然带时序，知道「什么在什么之前发生」往往更有用。LLM 负责推理当前请求，记忆层负责在相关时让过往经验可用，两者职责分开，系统更好理解。