24Memory 4 类

"Agent 记忆"是个含糊词,4 类要分清:

1. In-context memory(短期)。当前 context window 里的 messages。session 结束就没。这不是"记忆",更像"工作记忆",受 context 长度限制。

2. External memory(长期,知识)。外部存储——DB / 向量库 / 文件。需要明确的 retrieval 机制(用户查询 → search → 拼到 in-context)。RAG 是典型应用。"客观事实型记忆"。

3. Episodic memory(过去的具体经历)。Trace 库,记录这个用户/agent 在过去某次 session 做过什么——调用了哪些 tool、做了什么决定、用户怎么反馈。"自传体记忆",数据是带时间戳的。

4. Semantic memory(从 episodic 抽出的高层事实)。"该用户喜欢简洁回答"、"该用户的项目用 PostgreSQL"。从大量 episodic 抽出共性,存为 KV,作为"用户画像"或"项目画像"。

实现路径:

In-context:   自动,由 agent loop 管(见 #6)
External:     显式 retrieval pipeline
                = 向量 search(语义)+ 关键词 search(精确)
                + rerank → top-K 拼进 context
Episodic:     每次 session 写 trace log(见 #19 可观测性)
                + 索引(向量 / SQL)便于回查
Semantic:     周期任务(每 N 个 session 一次)
                让模型从 episodic 抽取事实
                存到 KV(user_pref / project_facts)

典型组合用法:用户问问题 → 从 semantic 拉用户偏好(轻量) + 从 external 拉相关文档(RAG) + 从 episodic 拉类似历史 session → 全部塞进 in-context → 模型回答。四类组合不是相互替代。

Cursor 在 2024-2025 公开了它的 memory 设计,4 类全用上:

用户在 Cursor 里说 "add OAuth login"
                ↓
[Semantic memory 拉:用户画像 + 项目画像]
   "user prefers async/await over callbacks"
   "this project uses FastAPI + PostgreSQL"
                ↓
[External memory 拉:相关代码片段]
   向量 search "OAuth login Python" → 拉到 3 段历史代码
                ↓
[Episodic memory 拉:用户过去类似 session]
   "上次用户做 GitHub OAuth,用了 authlib 库"
                ↓
[全部拼进 In-context memory]
   system + 上面三类拉来的内容 + 用户当前 query
                ↓
[模型生成代码]

对比"只用 in-context":用户每次都要重新解释项目结构、技术栈偏好、过去做过的相似事。memory 系统的价值是把跨 session 的隐性知识结构化保留。