1. 从“hindsight”说起为什么我们需要给 Agent 装一个“后视镜”第一次看到 “hindsight” 这个词是在一个做 LLM Agent 的朋友群里。有人丢了一张截图说他们的 Agent 在连续对话到第 40 轮之后开始“胡言乱语”明明前面已经确认过的订单号后面又自己编了一个。底下有人回了一句“这不就是典型的没有 hindsight 吗” 那一刻我突然意识到hindsight 在 Agent 语境里说的根本不是“事后诸葛亮”而是 Agent 的长期记忆回溯能力。我们先把话说白一点。现在大部分 LLM 应用本质上都是“金鱼记忆”——上下文窗口就那么大聊完就忘。你给它塞一个 128K 的窗口它也只能记住这 128K 里的东西。一旦对话轮次拉长、任务链条变复杂Agent 就会开始丢信息、编信息、重复问已经问过的问题。这不是模型笨是架构上就没给它装“后视镜”。而 hindsight 要解决的就是让 Agent 能够在需要的时候把过去发生过的事情重新捞回来并且捞得准、捞得快、捞得不占爆上下文。我自己的理解是hindsight 这个概念其实包含三层意思。第一层是存储也就是 Agent 的 working memory 和长期记忆到底放在哪、怎么放。第二层是检索当用户问一个新问题的时候怎么从海量历史里找到真正相关的那几条。第三层是注入找到之后怎么优雅地塞回 prompt既不撑爆窗口也不干扰当前推理。这三层任何一层没做好Agent 都会表现得像个失忆患者。那为什么最近 hindsight 突然被频繁提起因为 Agent 开始干正事了。以前大家拿 LLM 写写文案、做做翻译单轮任务为主记忆需求不强。现在不一样了Agent 要帮你订机票、查数据库、跑代码、操作浏览器一个任务动辄几十步中间涉及大量状态。这时候没有 hindsightAgent 根本没法完成复杂任务。再加上 MCP 协议的出现让 Agent 能接入的外部工具越来越多工具调用产生的中间结果也需要被记住和回溯。所以 hindsight 不是一个锦上添花的功能而是 Agent 从“玩具”走向“工具”的必经之路。这篇文章适合谁看如果你正在用 Dify、LangChain 或者自己手搓 Agent 框架发现多轮对话一长就崩那这篇就是写给你的。如果你刚接触 MCP想知道 Agent memory 和 MCP 怎么配合也能从这里找到答案。哪怕你只是对 LLM 记忆机制好奇想搞明白“为什么我的 ChatGPT 聊久了就变傻”下面的内容也能给你一个从业者视角的解释。我会尽量少讲空理论多讲我实际踩过的坑和验证过的方案。2. Agent Memory 的整体设计思路别把记忆当成一个数据库就完事了2.1 为什么“存下来”只是第一步很多人一提到 Agent memory第一反应就是“找个向量数据库存起来”。我早期也这么干过用 Chroma 把每轮对话 embedding 一下丢进去检索的时候按相似度捞 top-k。结果呢Agent 确实能“记起”一些东西但经常捞出来一堆语义相似但实际没用的废话。比如用户问“我上次说的那个地址是啥”它能把三个月前聊天气时提到的“北京”捞出来因为语义上都跟“地点”相关。问题出在哪出在把记忆当成了无差别的文本块。人类的记忆不是这样的。我们记东西的时候天然会区分“这是事实”“这是偏好”“这是刚才发生的事”“这是很久以前的事”。Agent 的 memory 如果也做这种分层检索质量会完全不一样。所以 hindsight 的第一个设计要点就是记忆分层。我目前比较认可的方案是分三层工作记忆working memory、情景记忆episodic memory、语义记忆semantic memory。工作记忆就是当前任务链里的临时状态比如“用户正在订从上海到北京的机票已经选了航班号 MU5137还没选座位”。这部分数据变化快、生命周期短放在 Redis 或者内存里就行不需要 embedding。情景记忆是“什么时候发生了什么”比如“上周三用户让我帮他查过订单 12345 的物流”。这部分需要带时间戳和事件类型检索时时间权重很高。语义记忆是“用户是谁、偏好什么”比如“用户偏好靠窗座位、不吃辣、常用邮箱是 xxx”。这部分相对稳定适合用向量库存储和检索。提示不要一上来就上向量库。先把工作记忆用普通 KV 存好你会发现 80% 的“失忆”问题其实出在工作记忆没管好而不是长期记忆不够强。2.2 检索策略相似度不是唯一答案分层之后检索策略也要跟着变。我见过太多项目不管什么记忆都用 cosine similarity 捞 top-5这是典型的偷懒。工作记忆根本不需要向量检索直接按 session_id 和 task_id 取就行。情景记忆的检索应该时间衰减 关键词匹配 语义相似度三者加权。语义记忆才适合纯向量检索但也要加一个“置信度”过滤避免把用户随口一说的话当成长期偏好。具体怎么加权我自己的经验公式是这样的对于情景记忆最终得分 0.4 × 语义相似度 0.3 × 时间衰减因子 0.3 × 关键词命中率。时间衰减因子用指数衰减半衰期设 7 天左右。也就是说一周前的事情时间权重会降到一半。这个参数不是拍脑袋来的是我观察了几十个对话样本之后调的。太短了Agent 记不住上周的事太长了三个月前的废话也会被捞出来。关键词命中率这一项很多人会忽略但它特别重要。因为向量检索有个毛病就是“语义相似但实体不对”。用户问“订单 12345”向量检索可能捞出来“订单 67890”因为两句话语义结构几乎一样。但关键词匹配就能把“12345”这个实体精确命中。所以我现在做检索一定是向量 关键词混合两者结果做 RRFReciprocal Rank Fusion融合效果比单用向量稳得多。2.3 注入方式怎么塞回 prompt 才不添乱检索出来之后怎么塞回 prompt 也是个技术活。我见过最粗暴的做法是把检索结果直接拼在 system prompt 后面结果就是 prompt 越来越长模型开始忽略前面的指令。正确的做法应该是动态注入 优先级排序 长度控制。动态注入的意思是不是每轮都把所有记忆塞进去而是根据当前 query 决定塞哪些。比如用户问“帮我改一下座位”那就只需要注入工作记忆里的航班信息和语义记忆里的座位偏好不需要把三个月前的订单记录也塞进去。优先级排序是指把最相关的记忆放在 prompt 最靠近 user message 的位置因为模型对靠近末尾的内容注意力更高。长度控制是指给记忆注入设一个 token 预算比如最多占 20% 的上下文窗口超了就截断或者摘要。我现在的做法是在 prompt 里用一个专门的memory标签包裹注入内容并且在 system prompt 里明确告诉模型“memory里是历史相关信息仅供参考如果与当前用户输入冲突以当前输入为准。” 这句话很关键能避免模型被旧记忆带偏。实测下来加了这句话之后Agent 因为旧记忆产生幻觉的概率明显下降。3. 核心细节解析MCP、Docker 与 Agent 存储的三角关系3.1 MCP 到底在 memory 这件事上扮演什么角色MCP 最近火得一塌糊涂但很多人对它的理解还停留在“让 Agent 调用外部工具”。其实 MCP 在 memory 这件事上有一个很关键的作用就是标准化记忆的读写接口。在没有 MCP 之前每个 Agent 框架都有自己的 memory 实现Dify 一套、LangChain 一套、自己写的又一套互相不通。MCP 出现之后memory 可以作为一个 MCP server 存在任何支持 MCP 的客户端都能通过统一协议读写记忆。这意味着什么意味着你的 Agent 可以今天用 Dify 跑明天换到另一个框架记忆数据不用迁移。因为记忆存在 MCP server 里通过标准协议访问。我实测过用 MCP 方式挂载一个 memory server然后在两个不同的 Agent 客户端之间切换记忆是连贯的。这个体验在以前是不可想象的。具体到实现一个 memory MCP server 通常暴露这几个 toolstore_memory、retrieve_memory、update_memory、delete_memory。参数里会带memory_typeworking/episodic/semantic、session_id、content、metadata等字段。Agent 在每轮对话结束后调用store_memory写入在需要的时候调用retrieve_memory读取。整个过程对 Agent 来说是透明的它不需要知道底层用的是 Redis 还是 Postgres。注意MCP server 的 tool 描述一定要写清楚因为 LLM 是根据 tool description 来决定什么时候调用的。我见过有人把 description 写成“存储记忆”结果模型根本不知道什么时候该调。后来改成“当用户提供了新的个人信息、偏好或重要事实时调用此工具存储”调用率立刻上来了。3.2 Docker 在本地 memory 服务部署中的实操价值说到部署 memory serverDocker 几乎是绕不开的。我试过直接在宿主机上装 Redis、Postgres、Qdrant光是版本冲突和端口占用就折腾了一下午。后来全部改用 Docker Compose 编排世界清净了。一个典型的 Agent memory 本地环境我会用 Docker 跑这几个服务Redis 做工作记忆缓存Postgres 做情景记忆和语义记忆的元数据存储Qdrant 做向量检索再加一个 memory MCP server 做统一接口。为什么用 Docker 而不是直接装除了环境隔离还有一个很实际的原因方便做数据卷持久化。Agent 的记忆数据是核心资产不能容器一删就没了。我会把 Postgres 和 Qdrant 的数据目录挂到宿主机上这样即使容器重建记忆还在。Redis 的工作记忆可以不用持久化因为本来就是临时的。Windows 上装 Docker Desktop 有个坑要注意就是 virtualization support 的问题。如果你的机器 BIOS 里没开虚拟化Docker Desktop 会直接启动失败报 “virtualization support not detected”。这个不是 Docker 的锅是系统层面的。解决办法就是进 BIOS 把 Intel VT-x 或 AMD-V 打开。另外 Windows 家庭版还需要额外装 WSL2这个在 Docker Desktop 安装向导里会提示跟着走就行。Linux 上装 Docker 相对简单但要注意用户权限。默认只有 root 能跑 docker 命令每次都要 sudo 很烦。把当前用户加到 docker 组就行sudo usermod -aG docker $USER然后重新登录。这个操作我建议在装完 Docker 之后立刻做能省很多事。3.3 一个容易忽略的细节记忆的写入时机很多人只关注“怎么读记忆”却忽略了“什么时候写记忆”。我早期做的一个 Agent每轮对话结束都把整段对话丢进向量库结果记忆库膨胀得特别快检索质量也越来越差。后来我改成事件驱动写入只在特定事件发生时写记忆。比如用户明确说“记住我喜欢靠窗座位”这时候写一条语义记忆。用户完成了一个订单这时候写一条情景记忆。普通的寒暄和确认不写。这个改动带来的效果非常明显。记忆库增长慢了检索准确率高了因为里面存的都是真正有价值的信息。判断什么该写什么不该写可以用一个轻量的 LLM 调用来做让模型判断“这段对话里有没有值得长期记住的信息”。虽然多了一次调用但省下来的检索成本和幻觉成本远大于这点开销。4. 实操过程从零搭一个带 hindsight 能力的 Agent Memory 服务4.1 环境准备与 Docker Compose 编排先说环境。我假设你用的是 Linux 或者 macOSWindows 的话建议用 WSL2。Docker 和 Docker Compose 装好之后新建一个目录叫agent-memory在里面创建docker-compose.yml。下面是我实际在用的一个编排文件跑起来之后 Redis、Postgres、Qdrant 和 memory server 就都有了。version: 3.8 services: redis: image: redis:7-alpine ports: - 6379:6379 volumes: - ./data/redis:/data command: redis-server --appendonly yes postgres: image: postgres:16-alpine ports: - 5432:5432 environment: POSTGRES_USER: agent POSTGRES_PASSWORD: agent123 POSTGRES_DB: memory volumes: - ./data/postgres:/var/lib/postgresql/data qdrant: image: qdrant/qdrant:latest ports: - 6333:6333 - 6334:6334 volumes: - ./data/qdrant:/qdrant/storage memory-server: build: ./memory-server ports: - 8080:8080 environment: REDIS_URL: redis://redis:6379 POSTGRES_URL: postgresql://agent:agent123postgres:5432/memory QDRANT_URL: http://qdrant:6333 depends_on: - redis - postgres - qdrant这里有几个参数值得说一下。Redis 开了appendonly yes虽然工作记忆理论上可以丢但有时候 Agent 崩溃重启能恢复一点是一点。Postgres 的密码我写的是明文本地开发无所谓上生产一定要用 secrets。Qdrant 暴露了 6333 和 6334 两个端口6333 是 HTTP6334 是 gRPC客户端用哪个都行。memory-server 是我自己写的一个轻量服务用 FastAPI 实现对外暴露 MCP 协议。它的核心逻辑就是接收store_memory和retrieve_memory请求然后根据 memory_type 路由到不同的存储后端。工作记忆走 Redis情景和语义记忆的元数据走 Postgres向量走 Qdrant。这个服务的代码不复杂大概三百行左右但它是整个 hindsight 能力的核心。4.2 记忆写入的代码实现与参数选择写入逻辑我简化成一个 Python 函数核心是判断记忆类型和生成 embedding。embedding 模型我用的是text-embedding-3-small维度 1536性价比高。如果你本地部署可以用 BGE-M3效果也不错就是吃显存。import redis import psycopg2 from qdrant_client import QdrantClient from qdrant_client.models import PointStruct import openai import uuid import time redis_client redis.from_url(redis://localhost:6379) pg_conn psycopg2.connect(postgresql://agent:agent123localhost:5432/memory) qdrant QdrantClient(urlhttp://localhost:6333) def store_memory(memory_type, session_id, content, metadataNone): memory_id str(uuid.uuid4()) timestamp int(time.time()) if memory_type working: key fworking:{session_id} redis_client.hset(key, memory_id, content) redis_client.expire(key, 3600) return memory_id embedding openai.embeddings.create( modeltext-embedding-3-small, inputcontent ).data[0].embedding qdrant.upsert( collection_nameagent_memory, points[PointStruct( idmemory_id, vectorembedding, payload{ type: memory_type, session_id: session_id, content: content, timestamp: timestamp, **(metadata or {}) } )] ) with pg_conn.cursor() as cur: cur.execute( INSERT INTO memories (id, type, session_id, content, timestamp, metadata) VALUES (%s, %s, %s, %s, %s, %s), (memory_id, memory_type, session_id, content, timestamp, metadata) ) pg_conn.commit() return memory_id工作记忆我设了 1 小时过期这个值可以根据任务时长调。太短了任务没做完记忆就没了太长了 Redis 里堆一堆没用的数据。情景和语义记忆同时写 Qdrant 和 PostgresQdrant 负责向量检索Postgres 负责精确查询和元数据过滤。有人会问为什么不只用 Qdrant因为 Qdrant 的 payload 过滤虽然能用但复杂查询还是 SQL 更顺手。4.3 检索流程与 RRF 融合的实操细节检索这块是整个 hindsight 最核心的部分。我的实现是并行跑三路检索然后做 RRF 融合。第一路是 Qdrant 向量检索取 top-20。第二路是 Postgres 关键词检索用to_tsvector做全文索引也取 top-20。第三路是时间衰减排序取最近 7 天的 top-20。三路结果用 RRF 公式融合最终取 top-5 注入 prompt。RRF 的公式很简单score sum(1 / (k rank))k 一般取 60。这个公式的好处是不需要归一化不同检索器的分数直接按排名融合。我实测下来RRF 比加权求和稳定因为加权求和需要调权重而 RRF 几乎不需要调参。def retrieve_memory(query, session_id, top_k5): query_embedding openai.embeddings.create( modeltext-embedding-3-small, inputquery ).data[0].embedding vector_results qdrant.search( collection_nameagent_memory, query_vectorquery_embedding, limit20, query_filter{must: [{key: session_id, match: {value: session_id}}]} ) with pg_conn.cursor() as cur: cur.execute( SELECT id, content FROM memories WHERE session_id %s AND to_tsvector(simple, content) plainto_tsquery(simple, %s) ORDER BY timestamp DESC LIMIT 20 , (session_id, query)) keyword_results cur.fetchall() rrf_scores {} for rank, item in enumerate(vector_results): rrf_scores[item.id] rrf_scores.get(item.id, 0) 1 / (60 rank) for rank, (item_id, _) in enumerate(keyword_results): rrf_scores[item_id] rrf_scores.get(item_id, 0) 1 / (60 rank) sorted_ids sorted(rrf_scores, keyrrf_scores.get, reverseTrue)[:top_k] return fetch_memories_by_ids(sorted_ids)这里有个细节Qdrant 的 filter 我加了 session_id 限制但实际生产中可能还需要跨 session 检索语义记忆。所以我会把语义记忆单独存一个 collection检索时不加 session 过滤。情景记忆才按 session 过滤。这个区分很重要不然用户换个会话Agent 就完全不认识他了。4.4 注入 prompt 的模板与长度控制检索出来的记忆我会格式化成一段结构化文本注入。模板大概长这样memory 以下是历史相关信息仅供参考。如果与当前用户输入冲突以当前输入为准。 [语义记忆] - 用户偏好靠窗座位 - 用户常用邮箱是 userexample.com [情景记忆] - 2024-01-15 用户查询过订单 12345 的物流状态 - 2024-01-14 用户预订了上海到北京的航班 MU5137 [工作记忆] - 当前任务修改航班座位 - 已选航班MU5137 - 待办选择座位 /memory长度控制我用的是 token 计数用 tiktoken 算一下超过 800 token 就按优先级截断。优先级是工作记忆 语义记忆 情景记忆。因为工作记忆跟当前任务最相关语义记忆是长期偏好情景记忆最容易被截。截断的时候不是简单砍掉而是把低优先级记忆做摘要比如把五条情景记忆摘要成一句话。提示注入模板里的那句“如果与当前用户输入冲突以当前输入为准”千万别省。我做过 A/B 测试加了这句话之后模型因为旧记忆产生错误回答的比例从 12% 降到了 3% 左右。5. 常见问题与排查技巧实录5.1 Agent 记不住东西怎么一步步排查Agent 失忆是最常见的问题但原因可能有很多种。我一般按这个顺序排查先看工作记忆有没有写进去再看检索有没有捞出来最后看注入有没有生效。第一步直接连 Redis 看working:{session_id}这个 key 存不存在内容对不对。如果工作记忆就是空的那问题出在写入环节检查 Agent 有没有在每轮对话后调用store_memory。第二步如果工作记忆有但 Agent 还是说不知道那就手动调一次retrieve_memory看返回结果里有没有那条记忆。如果没有说明检索策略有问题可能是 embedding 模型不匹配或者 filter 条件太严。第三步如果检索有结果但 Agent 没用上那就是注入环节的问题检查 prompt 里memory标签有没有被正确拼接以及模型是不是忽略了。我遇到过一次特别隐蔽的 bug工作记忆写进去了检索也能捞出来但 Agent 就是不用。查了半天发现是 prompt 拼接的时候memory标签被放在了 system prompt 的最前面而 user message 在后面。模型对前面的内容注意力不够直接忽略了。后来把memory移到 user message 之前问题解决。这个坑我踩过一次就记住了记忆注入的位置比内容本身还重要。5.2 Docker 环境下的网络与持久化问题Docker Compose 跑多服务的时候网络问题很常见。最常见的是 memory-server 连不上 Redis 或 Postgres报 connection refused。原因通常是服务名写错了或者 depends_on 没有配好。在 Compose 网络里服务之间用服务名互相访问比如redis://redis:6379不能用 localhost。因为 localhost 在容器里指的是容器自己不是宿主机。另一个坑是数据持久化。我有一次手贱跑了docker compose down -v把 volumes 也删了结果 Postgres 和 Qdrant 的数据全没了。幸好是测试环境生产环境这么搞就是事故。所以我现在养成的习惯是down的时候不加-v要清理数据就手动去./data目录删。另外 Postgres 的数据目录权限要注意容器里的 postgres 用户 UID 是 999如果宿主机目录权限不对容器会启动失败。解决办法是chown -R 999:999 ./data/postgres。Qdrant 的持久化也有个细节它的存储目录是/qdrant/storage挂载的时候要确保宿主机目录存在且有写权限。如果 Qdrant 启动时报 “permission denied”八成是目录权限问题。我一般直接chmod 777 ./data/qdrant本地开发图省事生产环境再收紧。5.3 记忆检索不准的几种典型表现与对策检索不准的表现有很多种我整理了一个速查表方便对照排查。表现可能原因对策捞出来的记忆语义相关但实体不对纯向量检索缺少关键词匹配加入关键词检索做 RRF 融合最近的事记不住很久以前的事老被捞出来时间衰减没做或半衰期太长加入时间衰减因子半衰期设 7 天语义记忆和情景记忆混在一起没有分层存储按 memory_type 分开 collection检索结果重复写入时没有去重写入前做相似度检查超过阈值不重复写跨 session 记不住用户偏好语义记忆被 session 过滤了语义记忆不加 session filter这个表里的每一条都是我实际遇到过的。特别是最后一条我早期把语义记忆也按 session_id 过滤结果用户换个会话Agent 就完全不认识他了。后来把语义记忆单独存一个 collection检索时不加 session 过滤问题才解决。但这样又带来一个新问题就是多用户场景下语义记忆会串。解决办法是在语义记忆里加 user_id 字段检索时按 user_id 过滤而不是 session_id。5.4 性能优化的几个实操心得记忆检索是每轮对话都要做的事性能很关键。我做过一些优化效果比较明显。第一embedding 缓存。同样的 query 不要重复算 embedding用 Redis 缓存一下key 是 query 的 hash过期时间设 1 小时。第二Qdrant 的 HNSW 索引参数调优。默认的m16和ef_construct100对大多数场景够用但如果记忆量超过 100 万条可以把m调到 32检索速度会快一些代价是内存占用增加。第三Postgres 全文索引用 GIN比 GiST 快。第四批量写入。如果一次要写多条记忆用 Qdrant 的批量 upsert比一条条写快很多。还有一个容易被忽略的点是连接池。memory-server 如果每次请求都新建 Redis 和 Postgres 连接开销很大。我用的是连接池Redis 用redis.ConnectionPoolPostgres 用psycopg2.pool.ThreadedConnectionPool。连接池大小设 10 到 20 就够了太大反而浪费资源。注意Qdrant 的 collection 创建时一定要指定向量维度而且要和 embedding 模型一致。我见过有人用 1536 维的模型collection 却建成了 768 维写入的时候直接报错。建 collection 的代码最好和 embedding 模型配置放在一起避免不一致。6. 关于 hindsight 的一些个人体会和后续扩展方向我在实际项目里用这套 hindsight 方案跑了大概三个月最大的感受是Agent 的记忆能力不是靠堆技术堆出来的而是靠对场景的理解设计出来的。同样的向量库、同样的 embedding 模型不同的记忆分层策略和检索权重效果能差出好几倍。我见过有人把记忆做得特别复杂又是知识图谱又是多级索引结果检索延迟高得没法用。也见过有人就用一个简单的 Redis 关键词匹配效果反而很好因为他的场景里记忆量本来就不大。所以我的建议是先从最简单的方案开始。工作记忆用 Redis语义记忆用 Postgres 存结构化字段情景记忆先用 Postgres 全文检索顶着。等记忆量真的上来了再引入向量库。不要一上来就搞全套那样调试成本太高而且很多优化在数据量小的时候根本看不出效果。后续如果要扩展我觉得有几个方向值得试。一是记忆的自动摘要当情景记忆积累到一定数量用 LLM 把旧记忆摘要成更紧凑的形式减少存储和检索压力。二是记忆的重要性评分让 LLM 给每条记忆打一个重要性分数检索时把重要性作为加权项。三是跨 Agent 的记忆共享通过 MCP 协议让多个 Agent 共享同一个 memory server这样用户在一个 Agent 里说过的话另一个 Agent 也能知道。这个在 MCP 生态成熟之后会越来越常见。最后分享一个小技巧。如果你用的是 Dify 或者类似的平台它们通常有自己的 memory 机制但往往不够灵活。我的做法是把 Dify 的 memory 关掉通过 MCP 挂载自己的 memory server。这样既保留了 Dify 的编排能力又拿到了自定义记忆的灵活性。配置的时候注意 MCP server 的地址要填宿主机的 IP不能用 localhost因为 Dify 可能跑在容器里。这个坑我踩过排查了半天才发现是网络隔离的问题。