记忆程序是Agent主要的“大脑”，但往往被误认为只需要“存进去”。真正的痛点在于：该忘的忘、该留的留、该用的用否则Agent会因信息过载而失效，甚至误导使用者。

工作记忆这方面。LLM的“弹性边界”

工作记忆是Agent当前正在思考的内容，直接映射到LLM输入窗口。其容量有限，但实际占用常常很快爆满。

• 典型痛点: 使用者在对话中多次提问，导致上下文塞满；结果LLM无法区分关键信息，出现“胡说八道”。
• 操作三要素
  1. 压缩: 将长对话摘要为几句话。如“使用者想查北京→上海机票，直飞预算2000”。
  2. 注入: 按需从短期/长期记忆检索相关片段，只塞最有用的信息。
  3. 清理: 移除已结束话题或无关历史消息。
• 案例演示: 某客服Agent在第9轮问题时把第3个问题答案套上去。通过压缩+清理后上下文从12K降至4K，推理准确率从67%提高到89%。
• : 上下文越长。“Lost in Middle”现象越明显，即使大窗口也不代表着能完整保留所有细节。

如何合理使用大？

即使模型支持1M token，也不等于可以全塞进去。正确做法是这方面，

• 再看结构化注入。不要把全部历史平铺，而是按主题/任务分块。
• 至于按需加载。动态对话放在后缀，仅在需要时插入。
• 至于摘要压缩。长期对话先压缩为简洁摘要，再注入。
• Caching策略：把稳定内容放前缀缓存；动态内容放后缀不缓存，以减少成本和延迟。

再看短期记忆。会话状态管理的“去留抉择”

短期记忆记录本次会话中的主要信息，如使用者偏好、任务进度、临时结果等。存储介质一般是内存或Redis，其生命周期仅限一次会话。

• Pain Point #1: “我刚换了收货地址。 却没有被记录”，导致后续订单生成错误地址。Pain Point #2: “我说改城市。但Agent下一轮就忘了”，出现跨轮推断错误。

说到三大操作流程，

1. 写入： 每轮结束后提取关键信息写入。例如“我要改成上海出发”。非必要回复如“嗯”“好的”不写入。
2. 读取： 每轮推理前从会话状态中读取相关数据并注入工作记忆。
3. 筛选： 会话结束时评估哪些信息值得转移到长期记忆，其余丢弃或归档。

   # ❌ 错误示例
   session_state = {
   "user_said_1": "我要查机票","tool_result_1": "...3KB JSON...",...
   }# ✅ 正确示例
   session_state = {
   "user_profile": {"departure":"北京","budget":2000,"preference":"直飞"}。"task_progress": {"step":"comparing","checked_suppliers":},"key_facts":,"pending_actions":
   }
   

   至于长期记忆，跨会话知识库与检索挑战

   长期记忆负责保存所有跨会话可复用的信息，例如使用者特点、成功推理策略、领域知识等。不过，它通常存储在向量数据库或知识图谱中。并具备无限生命周期与容量上限理论上无限大。

   • Pain Point #3:"我三个月前说喜欢晴天却在今天询问天气时得到错误建议" —— 长期记忆检索到过时偏好影响当前决策。

   从四项关键操作来看，

   1. writting: 会话结束时从短期记忆挑选关键信息写入长期。说起来，附加标签如时间戳、关键性评分、类型、来源ID.
   2. tagged retrieval: 检索时不仅靠向量相似度。还混合关键词匹配、时间衰减和关键性过滤.
   3. update: 当使用者纠正信息时要更新原有条目而不是新增冲突条目.
   4. forgetting: 主动删除过时、错误或低价值记录—这是最易被忽视却最关键的步骤.

   **如果你只是把所有对话都塞进向量数据库，没有过滤和更新机制，那么你是在建一个无差别垃圾场**——这就是最常见的遗忘机制缺陷，也是导致代理频繁误导使用者的原因之一之一！**永远不要让旧偏好污染新决策！** ​​ ​​ ​ ​​​​​​ ​​​​​​​ ​​​​​​​​​​​​​​​​​​​​​​​​​​

   RAG 在 Agent 中正确使用方式

   至于**错误做法，** 每次推理前全量检索 top‑20 并塞进 Prompt，会引发噪声与空间浪费.

   # ❌ 全量检索塞进 Prompt
   async def agent_with_rag:
   memories = await vector_db.search
   memory_text = "
   ".join
   prompt = f"

   **改进方案这方面。** 按需检索 + 多维过滤 + 压缩 + 阈值筛选 → 精准且高效.

   # ✅ 正确 RAG 使用
   async def agent_with_smart_rag:
   candidates = await vector_db.search
   scored =
   for m in candidates:
   time_decay = compute_time_decay
   importance = m.metadata.get
   relevance = m.score * time_decay * importance
   scored.append)
   scored.sort
   # 阈值过滤
   top_memories=
   # 压缩为简洁摘要
   memory_summary = await compress_memories
   prompt=f"相关记忆:{memory_summary}
   当前问题这方面，{user_query}"
   response=await llm.complete
   return response
   

   何时需要检索？何时不需要，按理说，

   'Yes' 'No' 'Yes' 'No' 'Yes'

   场景描述 / 痛点实例	是否需要检索?	原因 / 使用者痛点说明
   ① 使用者提到个人偏好并可能存在冲突	确认是否有冲突记录；若冲突则优先采信最新，否则忽略旧偏好以避免误导。'
   ② 简单事实查询	仅靠当前上下文即可回答。无需拉取过去记录，否则可能产生噪声。'
   ③ 使用者说 “上次那个…” 或 “上一次，” 指代过去事件	必须回溯过去语义以确定指代对象，否则导致回答完全脱离语境。'
   ④ 新的话题开始	新任务无关联历史，可直接使用工作/短期内已有状态进行推理。'
   ⑤ 使用者纠正 Agent 的错误	应定位导致错误推理的旧记录并标记为待验证，以免 固化同一错误。'