1. 从“hindsight”说起为什么我们需要给Agent装上记忆“hindsight”这个词本身很有意思字面意思是“事后的洞察力”也就是我们常说的“后见之明”。放在LLM Agent的语境里它指向一个非常具体且棘手的问题Agent如何记住过去发生过的事情并在后续决策中真正用上这些经验。我接触过不少做Agent项目的团队大家一开始都兴致勃勃地搭ReAct循环、接工具调用跑几个demo觉得效果惊艳。但一旦进入真实业务场景问题就暴露了——Agent像个失忆症患者每次对话都从零开始用户上周提过的偏好、上个月处理过的类似工单、昨天刚纠正过的错误它统统不记得。你可能会说不是有上下文窗口吗但上下文窗口再大也有上限而且把几十轮历史全塞进去token成本飙升不说模型注意力还会被稀释关键信息反而被淹没。这就是“hindsight”要解决的核心矛盾Agent需要一种机制把过去的交互经验沉淀下来在需要的时候精准召回而不是每次都把全部历史重新读一遍。它本质上是一个记忆管理系统涉及存储结构设计、检索策略、遗忘机制、与LLM推理循环的集成等多个层面。适合谁来参考这篇内容如果你正在做LLM Agent开发或者对Agent Memory这个方向感兴趣又或者你只是好奇“为什么我的Agent总是记不住事”那接下来的内容应该能给你一些可直接落地的思路。我会从整体设计讲到具体实现包括存储选型、检索算法、与MCP协议的配合、Docker环境搭建以及我在实际项目中踩过的坑。2. Agent Memory的整体设计与核心思路拆解2.1 为什么传统上下文管理不够用先说说大家最常用的做法把对话历史拼成一个长字符串每次请求都带上。这个方案在早期确实能用但它有三个致命问题。第一是成本问题。假设每轮对话平均500 token50轮就是25000 token。按GPT-4级别的价格算每次请求光历史部分就要花掉不少钱。如果Agent每天处理上千次请求这个成本会迅速失控。第二是注意力稀释。Transformer的注意力机制虽然理论上能处理长序列但实际表现是“中间遗忘”——序列中间部分的信息容易被忽略。你把100轮历史塞进去模型真正能有效利用的可能只有开头和结尾的几轮。第三是信息冗余与冲突。用户可能在不同时间说了矛盾的话比如“我喜欢简洁的回答”和“能不能详细解释一下”。如果没有一个机制去管理这些信息的优先级和时效性模型就会困惑。所以我们需要一个独立的记忆层它负责选择性地存储、组织、检索和遗忘信息让LLM每次只看到最相关的那部分。2.2 记忆的分层结构Working Memory与Long-term Memory参考认知科学的模型我把Agent记忆分成两层Working Memory工作记忆当前会话的短期上下文容量有限通常就是最近N轮对话或当前任务相关的信息。它的特点是访问速度快、生命周期短、随会话结束而清空或归档。Long-term Memory长期记忆跨会话持久化的知识包括用户偏好、历史事件、学到的经验等。它的特点是容量大、生命周期长、需要检索机制来访问。这两层之间的交互是关键。Working Memory中的信息在会话结束时经过筛选和压缩后写入Long-term MemoryLong-term Memory中的相关内容在需要时被召回注入到Working Memory中供LLM使用。2.3 记忆的三种类型Key-Query-Value视角热词里提到一个很有意思的说法“LLM的token三个点key我是谁、query我在找什么、value我能提供什么”。这其实借用了注意力机制的隐喻用来理解记忆检索非常贴切。Key我是谁这条记忆是关于什么的比如“用户偏好”、“项目配置”、“错误解决方案”。它是记忆的标签和索引。Query我在找什么当前情境需要什么信息比如用户问“上次那个bug怎么修的”Query就是“bug修复方案”。Value我能提供什么记忆的实际内容。比如“bug是因为Docker网络配置冲突解决方案是自定义bridge网络”。一个好的记忆系统就是让Key和Query的匹配尽可能精准从而召回最相关的Value。2.4 为什么选择向量数据库结构化存储的混合方案纯向量检索的问题是它只能做语义相似度匹配无法处理精确条件过滤。比如你想找“上周关于Docker的所有记忆”向量检索可能返回一堆语义相关但时间不对的内容。纯结构化存储比如SQL的问题是它无法处理模糊语义查询。用户说“我上次说的那个部署问题”你没法用SQL精确匹配。所以我的方案是混合存储用向量数据库做语义检索用关系型数据库或文档数据库做结构化过滤两者结合。具体来说每条记忆同时存储向量嵌入和结构化元数据时间戳、类型、标签、重要性评分等检索时先做结构化过滤缩小范围再做向量相似度排序。3. 核心细节解析与实操要点3.1 记忆的写入策略什么时候该记什么时候不该记不是所有对话都值得写入长期记忆。如果每句话都存记忆库会迅速膨胀检索质量也会下降。我的策略是基于重要性评分的选择性写入。重要性评分可以从几个维度计算显式标记用户说“记住这个”、“以后都这样”时直接高分。信息密度包含具体事实、偏好、决策的内容比寒暄高分。重复频率同一信息多次出现说明它重要。任务相关性与当前Agent核心任务相关的信息优先。我通常设一个阈值比如0.6分以上才写入长期记忆。低于阈值的只在Working Memory中保留会话结束就丢弃。注意写入时一定要做去重和冲突检测。如果新记忆和已有记忆矛盾要么更新旧记忆要么标记冲突让Agent在检索时知道存在不同版本。3.2 记忆的检索策略多路召回重排序检索是记忆系统最核心的环节。我的做法是多路召回向量语义检索用embedding模型把Query和所有记忆的Key做相似度计算取Top-K。关键词检索用BM25或类似算法做精确词匹配补充向量检索可能漏掉的精确匹配。时间衰减加权越近的记忆权重越高但也不能完全忽略旧记忆。我通常用指数衰减半衰期设7天左右。重要性加权写入时的重要性评分在检索时也参与排序。最后用一个重排序模型可以是cross-encoder也可以简单的加权求和把多路结果融合取最终Top-N注入到LLM上下文。3.3 记忆的遗忘机制不是所有记忆都值得永远保留遗忘不是bug是feature。没有遗忘机制记忆库会变成垃圾场。我的遗忘策略分三种时间衰减超过一定时间未被访问的记忆重要性评分逐渐降低低于阈值后归档或删除。容量限制每个用户或每个Agent的记忆总量设上限超出时淘汰最低分的。主动遗忘用户明确要求删除某条记忆时立即执行。实操心得我建议保留一个“归档”层而不是直接删除。归档的记忆不参与常规检索但在特定情况下比如用户问“很久以前那个事”可以被召回。这样既控制了活跃记忆的规模又不会真正丢失信息。3.4 与MCP协议的集成让记忆成为可插拔的能力MCPModel Context Protocol是当前Agent工具集成的主流协议。把记忆系统做成一个MCP Server好处是解耦——Agent不需要知道记忆的具体实现只需要通过标准协议调用即可。具体来说我会暴露几个MCP工具memory_write写入一条记忆参数包括内容、类型、标签、重要性。memory_search检索记忆参数包括Query、时间范围、类型过滤、返回数量。memory_forget删除或归档记忆。memory_summarize对一段对话做摘要后写入。这样任何支持MCP的Agent框架都能直接接入不需要改代码。3.5 Docker环境下的部署要点用Docker部署记忆系统有几个关键点网络配置如果向量数据库和Agent在不同容器要确保它们在同一个Docker网络中。我习惯创建一个自定义bridge网络而不是用默认的。数据持久化向量数据库和关系型数据库的数据目录必须挂载到宿主机否则容器重启数据就没了。资源限制向量检索是内存密集型操作给容器设合理的内存上限避免OOM。健康检查配置healthcheck确保依赖服务数据库、embedding服务就绪后再启动记忆服务。4. 实操过程与核心环节实现4.1 环境准备Docker与依赖服务先确保Docker环境正常。Windows用户如果遇到“Virtualization support not detected”错误需要在BIOS里开启虚拟化支持然后在Windows功能里启用WSL2或Hyper-V。# 检查Docker是否正常运行 docker --version docker compose version # 创建自定义网络 docker network create agent-memory-net接下来用Docker Compose编排依赖服务。我选Qdrant做向量数据库轻量、性能好、API简洁PostgreSQL做结构化存储Redis做Working Memory的缓存。version: 3.8 services: qdrant: image: qdrant/qdrant:latest ports: - 6333:6333 volumes: - ./data/qdrant:/qdrant/storage networks: - agent-memory-net deploy: resources: limits: memory: 2G postgres: image: postgres:16 environment: POSTGRES_DB: agent_memory POSTGRES_USER: memory_user POSTGRES_PASSWORD: memory_pass ports: - 5432:5432 volumes: - ./data/postgres:/var/lib/postgresql/data networks: - agent-memory-net redis: image: redis:7-alpine ports: - 6379:6379 volumes: - ./data/redis:/data networks: - agent-memory-net networks: agent-memory-net: external: true启动后验证各服务docker compose up -d docker compose ps curl http://localhost:6333/healthz # Qdrant健康检查4.2 记忆数据模型设计在PostgreSQL中建表存储记忆的元数据CREATE TABLE memories ( id UUID PRIMARY KEY DEFAULT gen_random_uuid(), agent_id VARCHAR(64) NOT NULL, user_id VARCHAR(64), content TEXT NOT NULL, memory_type VARCHAR(32) NOT NULL, -- preference, fact, event, skill tags TEXT[], importance FLOAT DEFAULT 0.5, access_count INT DEFAULT 0, created_at TIMESTAMP DEFAULT NOW(), last_accessed_at TIMESTAMP DEFAULT NOW(), archived BOOLEAN DEFAULT FALSE ); CREATE INDEX idx_memories_agent_user ON memories(agent_id, user_id); CREATE INDEX idx_memories_type ON memories(memory_type); CREATE INDEX idx_memories_importance ON memories(importance DESC);Qdrant中存储向量from qdrant_client import QdrantClient from qdrant_client.models import Distance, VectorParams, PointStruct client QdrantClient(hostlocalhost, port6333) client.create_collection( collection_nameagent_memories, vectors_configVectorParams(size1536, distanceDistance.COSINE) )4.3 记忆写入的完整流程写入一条记忆的步骤内容预处理清洗文本提取关键信息。重要性评分用规则小模型打分。生成嵌入调用embedding模型如text-embedding-3-small生成向量。写入PostgreSQL存储元数据和原始内容。写入Qdrant存储向量和ID映射。更新Redis如果是当前会话的Working Memory同步更新缓存。import uuid from datetime import datetime def write_memory(agent_id, user_id, content, memory_type, tags, importance): memory_id str(uuid.uuid4()) # 1. 写入PostgreSQL cursor.execute( INSERT INTO memories (id, agent_id, user_id, content, memory_type, tags, importance) VALUES (%s, %s, %s, %s, %s, %s, %s) , (memory_id, agent_id, user_id, content, memory_type, tags, importance)) # 2. 生成嵌入并写入Qdrant embedding get_embedding(content) client.upsert( collection_nameagent_memories, points[PointStruct( idmemory_id, vectorembedding, payload{ agent_id: agent_id, user_id: user_id, memory_type: memory_type, importance: importance, created_at: datetime.now().isoformat() } )] ) # 3. 更新Redis Working Memory redis_client.lpush(fwm:{agent_id}:{user_id}, memory_id) redis_client.ltrim(fwm:{agent_id}:{user_id}, 0, 49) # 保留最近50条 return memory_id4.4 记忆检索的完整流程检索时我采用多路召回融合排序def search_memories(agent_id, user_id, query, top_k5, time_rangeNone, memory_typeNone): # 1. 向量检索 query_embedding get_embedding(query) vector_results client.search( collection_nameagent_memories, query_vectorquery_embedding, query_filter{ must: [ {key: agent_id, match: {value: agent_id}}, {key: user_id, match: {value: user_id}} ] }, limittop_k * 3 # 多召回一些后续重排序 ) # 2. 结构化过滤时间范围、类型 memory_ids [r.id for r in vector_results] sql SELECT * FROM memories WHERE id ANY(%s) AND archived FALSE params [memory_ids] if time_range: sql AND created_at %s params.append(time_range) if memory_type: sql AND memory_type %s params.append(memory_type) cursor.execute(sql, params) candidates cursor.fetchall() # 3. 重排序向量相似度 * 时间衰减 * 重要性 now datetime.now() scored [] for mem in candidates: vector_score next(r.score for r in vector_results if r.id mem[id]) days_old (now - mem[created_at]).days time_decay 0.5 ** (days_old / 7) # 半衰期7天 final_score vector_score * 0.6 time_decay * 0.2 mem[importance] * 0.2 scored.append((final_score, mem)) scored.sort(keylambda x: x[0], reverseTrue) return [mem for _, mem in scored[:top_k]]4.5 与LLM推理循环的集成在Agent的推理循环中每次调用LLM之前先用当前Query检索相关记忆把结果注入到system prompt或context中def build_context(agent_id, user_id, current_query): # 检索长期记忆 long_term search_memories(agent_id, user_id, current_query, top_k5) # 获取Working Memory wm_ids redis_client.lrange(fwm:{agent_id}:{user_id}, 0, 9) working_memories fetch_memories_by_ids(wm_ids) # 构建上下文 context_parts [] if long_term: context_parts.append(## 相关历史记忆\n \n.join( f- [{m[memory_type]}] {m[content]} for m in long_term )) if working_memories: context_parts.append(## 当前会话上下文\n \n.join( f- {m[content]} for m in working_memories )) return \n\n.join(context_parts)4.6 MCP Server的实现把记忆系统封装成MCP Server暴露标准工具接口from mcp.server import Server, NotificationOptions from mcp.server.models import InitializationOptions import mcp.server.stdio server Server(agent-memory) server.list_tools() async def handle_list_tools(): return [ Tool(namememory_write, description写入一条记忆, inputSchema{...}), Tool(namememory_search, description检索记忆, inputSchema{...}), Tool(namememory_forget, description遗忘记忆, inputSchema{...}), ] server.call_tool() async def handle_call_tool(name, arguments): if name memory_write: memory_id write_memory(**arguments) return [TextContent(typetext, textf已写入记忆 {memory_id})] elif name memory_search: results search_memories(**arguments) return [TextContent(typetext, textformat_results(results))] # ...启动MCP Serverpython -m mcp_server --port 8080在Agent配置中注册这个MCP ServerAgent就能通过标准协议调用记忆能力了。5. 常见问题与排查技巧实录5.1 记忆检索不准确怎么办这是最常见的问题。排查思路先看嵌入模型。不同embedding模型对中文、专业术语的表现差异很大。我试过用通用模型处理医疗领域术语效果很差换成领域微调过的模型后明显改善。再看分块策略。如果一条记忆太长嵌入会丢失细节。我通常把长记忆拆成200-500字的块每块单独嵌入检索时返回块再拼接。最后看重排序权重。向量相似度、时间衰减、重要性的权重需要根据场景调。客服场景时间权重高知识库场景重要性权重高。问题现象可能原因解决方案返回不相关记忆嵌入模型不匹配换领域模型或微调漏掉关键记忆分块太粗或太细调整分块大小旧记忆总是排前面时间衰减权重太低提高时间衰减系数重要记忆被淹没重要性权重太低提高重要性权重5.2 Docker网络不通的排查容器间网络不通是高频问题。我的排查顺序docker network inspect agent-memory-net确认容器都在同一网络。在容器内ping另一个容器名确认DNS解析正常。检查防火墙规则确保端口没有被宿主机防火墙拦截。如果用的是Docker Desktop确认WSL2网络配置正常。实操心得我习惯在compose文件里给每个服务加container_name这样容器间可以直接用名字通信不用记IP。5.3 记忆库膨胀太快怎么控制如果发现记忆数量增长过快检查几个点重要性阈值是不是设太低了提高到0.7试试。是不是把每轮对话都写入了应该只写筛选后的。有没有做去重相似度超过0.95的记忆应该合并。归档策略有没有生效定期跑归档任务。5.4 与Agent框架集成的兼容性问题不同Agent框架对MCP的支持程度不同。如果遇到集成问题确认框架版本支持MCP协议。检查MCP Server的传输方式stdio还是SSE是否匹配。看日志确认工具调用是否成功参数格式是否正确。5.5 性能优化检索延迟太高怎么办向量检索延迟主要来自嵌入计算和向量搜索。优化手段嵌入计算用缓存相同Query不重复计算。向量索引用HNSW比暴力搜索快几个数量级。结构化过滤先执行缩小向量搜索范围。批量检索时用异步并行。6. 记忆系统的扩展方向与个人经验6.1 从被动记忆到主动记忆目前的记忆系统是被动的——用户问什么检索什么。下一步可以做主动记忆Agent在空闲时主动整理记忆发现关联生成更高层的洞察。比如把多条关于“Docker问题”的记忆归纳成一条“Docker常见问题及解决方案”。6.2 记忆的图结构当前是扁平的记忆列表未来可以引入图结构把记忆之间的关联显式建模。比如“用户偏好”和“项目配置”之间可能有关联图结构能让检索沿着关联路径扩散召回更全面。6.3 多Agent共享记忆多个Agent协作时共享记忆层可以让它们互相学习。一个Agent踩过的坑另一个Agent可以直接避开。这需要解决权限控制和冲突合并的问题。6.4 我在实际项目中的几点体会第一不要追求一步到位。我一开始想设计一个完美的记忆系统结果拖了很久没上线。后来先用最简单的向量检索跑起来再逐步加时间衰减、重要性评分、归档机制迭代速度快很多。第二监控比功能更重要。记忆系统的效果很难直观判断必须加监控检索命中率、用户反馈、记忆增长率、检索延迟。没有数据就没法优化。第三遗忘和记忆同样重要。我早期版本没有遗忘机制跑了三个月后记忆库有几十万条检索质量断崖式下降。加上归档和淘汰后效果明显回升。第四测试要覆盖边界情况。比如空记忆库、超长记忆、矛盾记忆、并发写入。这些在demo阶段不会遇到但生产环境一定会碰到。最后分享一个小技巧在记忆的元数据里加一个source字段记录这条记忆来自哪次对话、哪个任务。排查问题时可以追溯也方便做数据清理。这个字段我一开始没加后来补上时发现很多历史记忆已经没法追溯来源了只能全部归档重来。