（OpenClaw 前置知识）解释「短期记忆」和「长期记忆」在 Agent 系统中的区别，分别适合怎么存储和检索？
- 标签：AI、OpenClaw、大模型应用开发、AI应用开发、Agent开发
🏛 业务架构师
短期记忆和长期记忆的区分，本质是"工作台"与"档案柜"的区别：
短期记忆（会话内）：当前对话的消息历史，随会话结束而消失。存储：就是上下文窗口内的消息列表，持久化用 Redis/DB 存会话（便于断线重连），管理动作是裁剪——保留最近 N 轮+系统提示，更早的做摘要压缩。适合：多轮对话的指代消解（"它多少钱"）、任务中间状态。
长期记忆（跨会话）：用户偏好、关键事实、历史事件，服务未来的交互。存储与检索三种主流方案：
- 向量库：历史要点向量化，按当前话题语义检索注入——模糊匹配、通用性强；
- 结构化档案：LLM 定期抽取字段（偏好、等级、重要事件）进 Profile 表——精确可控，检索就是查表；
- 图记忆：实体关系图谱，支持关联推理，成本较高。
搭配范式：长期记忆在会话开始时"按需召回"进入短期记忆，会话中的关键信息在结束时"提炼归档"进长期记忆——两级存储各司其职。
业务设计要点：记什么由场景定——私人助理记偏好、客户 Agent 记交易史，任务型 Agent 甚至可以不要长期记忆；合规上，敏感信息不入长期记忆、给用户查询与删除入口，这是 2026 年产品设计的基本义务，不是加分项。
🏗 系统架构师
短期/长期记忆的区别我按存储介质、生命周期、访问模式三维对比，这是典型的存储层次结构设计（类比 CPU 缓存 vs 磁盘）：
短期记忆（Working Memory）：
- 载体：上下文窗口本身——对话历史、当前任务中间产物；
- 生命周期：会话级（任务结束即失效）；
- 访问：全量驻留，模型 attention 直接可见，零检索延迟；
- 存储：本质在推理请求里（服务端无状态，客户端/会话服务维护消息列表，KV Cache 是它的物理加速层）。
长期记忆（Persistent Memory）：
- 载体：外部存储——结构化事实库（Postgres：用户属性、偏好、承诺）+ 语义情节库（向量库：历史任务、对话事件摘要）+ 热缓存（Redis）；
- 生命周期：跨会话持久，按 TTL/置信度衰减治理；
- 访问：检索式——query 相关性召回 Top-K 注入上下文（个人 RAG），增加 50~100ms 延迟与 token 预算。
分工设计：会话中实时指代消解靠短期；"用户上次说要简化报告格式"跨周生效靠长期。写入路径：会话结束异步抽取（LLM 判断什么值得记），读取路径：任务开始按需注入。
生产坑：记忆污染（错误事实长期生效）要有置信度与覆盖合并机制；短期记忆的压缩（摘要）是有损的，关键决策要在压缩前固化到长期记忆。
💻 全栈开发专家
两种记忆的区别在生命周期和容量模型：
- 短期记忆：当前任务的对话历史，生命周期=会话，容量=上下文窗口（几 k~几百 k token），读写就是消息列表操作。适合：当前任务的上下文延续（「把它改成红色」的「它」）。
- 长期记忆：跨会话持久的事实与偏好，生命周期=永久，容量=外部存储（无限），需要显式的写入/检索机制。适合：用户画像、历史结论、学到的操作偏好。
短期记忆实现：消息列表 + 窗口管理。最近 N 轮保原文，更早的滚动摘要；工具结果大对象转引用。LangGraph 里就是 State 的 messages 字段（配 add reducer）+ trim/summarize 策略。
长期记忆实现：外置存储 + 检索：
python
# 写：对话后异步抽取
memories = llm_extract_facts(session) # LLM 判断值得记的事实
store.put(("user", uid), key, {"text": m, "ts": now(), "kind": "preference"})
# 读：每轮任务前检索注入
hits = store.search(("user", uid), query=current_task, limit=3)载体选择：向量库（情景记忆，模糊召回）、KV/关系库（确定事实，精确可控）、图库（关系网络）。成品方案 Mem0/Zep 值得先试。
我的分配原则：短期解决「连贯」，长期解决「懂你」；检索注入的长期记忆要限 3~5 条并标注来源（「用户此前偏好：……」），和当前任务混在一起不分隔会污染指令遵循。