1. 从“hindsight”说起：为什么我们需要给Agent装上“后视镜”

第一次看到“hindsight”这个词，我脑子里蹦出来的不是词典释义，而是开车时看后视镜的那个动作。后视镜这东西有意思，它不帮你踩油门，也不帮你打方向，但没有它，你变道、超车、倒车心里都没底。Agent Memory这个领域，现在缺的就是一面好用的后视镜。

大模型本身是个“金鱼记忆”患者。你这次对话告诉它“我叫张三，做后端开发，偏好用Go”，下一轮新开一个session，它又变成一张白纸。这不是模型笨，是架构决定的——Transformer的注意力窗口再大，也架不住上下文被截断、session被重置。于是就有了Agent Memory这个方向：给LLM外挂一套记忆系统，让它能记住用户偏好、历史决策、任务上下文，甚至跨会话保持一致性。

“hindsight”这个项目标题，我理解它想解决的核心问题是：让Agent能够回看自己过去的交互轨迹，从中提取可复用的经验，而不是每次都从零开始。这跟简单的“把聊天记录塞进向量库”有本质区别。后者是存储，前者是反思。存储解决的是“我记得你说过什么”，反思解决的是“我从你说过的话里学到了什么”。

这个项目适合谁看？如果你正在做AI Agent应用，被“上下文窗口不够用”“多轮对话失忆”“任务执行到一半忘了目标”这些问题折磨过，那这篇内容就是写给你的。如果你只是用ChatGPT聊聊天，那可能暂时用不上，但了解一下背后的思路也没坏处——毕竟Agent化是接下来两年应用层的主旋律。

我先把结论撂在这儿：Agent Memory的难点从来不是“存”，而是“取”和“用”。存的东西再多，检索不出来等于零；检索出来了，不知道怎么注入prompt，也等于零。hindsight这个项目，我理解它的价值就在于把“存-取-用”这条链路串起来了，而且串得比较优雅。

2. 核心架构拆解：hindsight到底在“看”什么

2.1 记忆分层：working memory、episodic memory、semantic memory

人脑的记忆不是一锅粥，至少分三层：瞬时记忆（你现在看到的这行字）、情景记忆（昨天中午吃了什么）、语义记忆（北京是中国的首都）。Agent Memory要做得像样，也得分层。

hindsight这个项目，我推测它的架构里至少有这么几层：

• Working Memory（工作记忆）：当前session内的上下文，对应LLM的context window。这部分是易失的，session结束就没了。它的作用是维持当前对话的连贯性，让Agent知道“我们正在聊什么”。
• Episodic Memory（情景记忆）：按时间线存储的交互记录。每一次用户提问、Agent回复、工具调用、执行结果，都作为一条episode存下来。这部分是hindsight的核心数据源——没有这些历史轨迹，就谈不上“hindsight”。
• Semantic Memory（语义记忆）：从episodic memory中提炼出来的结构化知识。比如从多次对话中提取出“用户偏好用Python而非Java”“用户所在团队使用Kubernetes”“用户对响应速度要求高”这类事实。这部分是跨session复用的关键。

为什么要分这么细？因为检索策略不一样。Working memory直接拼进prompt就行；episodic memory需要按时间或相关性检索；semantic memory需要做知识图谱或向量化检索。混在一起做，检索精度会崩。

提示：很多团队做Agent Memory一上来就搞一个大向量库，把所有东西往里塞。结果检索的时候，要么召回一堆无关的闲聊，要么把关键事实淹没了。分层是必须的，别偷懒。

2.2 记忆写入：什么时候该记，什么时候不该记

不是所有对话都值得记。用户说“你好”“谢谢”“再见”，记下来纯属浪费存储和检索带宽。hindsight这类项目通常会有个记忆重要性评分机制，我推测它的逻辑大概是：

• 显式事实：用户明确说“我住在上海”“我用的是Mac”，直接写入semantic memory，权重高。
• 隐式偏好：用户多次选择某个选项、多次纠正Agent的某个行为，触发写入episodic memory，并标记为“待提炼”。
• 任务上下文：Agent执行多步任务时，中间状态写入working memory，任务完成后归档到episodic memory。
• 噪音：寒暄、重复确认、无信息量的反馈，直接丢弃。

这个评分机制怎么实现？常见做法是用一个小模型（比如BERT级别的分类器）或者规则引擎。hindsight如果做得轻量，可能用的是规则+关键词匹配；如果做得重，可能上了LLM as judge——让大模型自己判断“这条信息值不值得记”。

我个人的经验是：初期用规则，后期用模型。规则的好处是可解释、可控、零成本；坏处是覆盖不全。等积累了一定量的标注数据，再训个小模型做分类，效果会好很多。

2.3 记忆检索：三个关键问题——我是谁、我在找什么、我能提供什么

热搜词里有个很有意思的说法：“llm的token三个点key我是谁、query我在找什么、value我能提供什么”。这其实是在用注意力机制的QKV来类比记忆检索。

在hindsight的语境下，这三个点对应的是：

• Key（我是谁）：当前Agent的身份、角色、能力边界。比如“我是一个代码助手，擅长Python和Go，不擅长前端”。
• Query（我在找什么）：当前任务需要什么信息。比如“用户问了一个关于Docker网络配置的问题，我需要回忆之前是否处理过类似问题”。
• Value（我能提供什么）：检索到的记忆内容。比如“上次用户遇到Docker网络不通，是因为防火墙规则没放行，解决方案是xxx”。

检索策略上，hindsight大概率是混合检索：向量相似度 + 关键词匹配 + 时间衰减 + 重要性加权。纯向量检索的问题是对精确匹配不友好，比如用户问“MySQL 8.0的默认端口”，向量检索可能召回一堆“数据库配置”相关的泛泛内容，但关键词匹配能直接命中“3306”。

时间衰减也很关键。三个月前的记忆和昨天的记忆，权重应该不一样。常见做法是加一个指数衰减因子，半衰期设成7天或30天，看场景。

2.4 记忆注入：怎么把检索结果塞进prompt而不撑爆上下文

检索出来一堆记忆，不能全塞进prompt。Context window是有限的，塞太多反而稀释了关键信息。hindsight这类项目通常会有个记忆压缩与排序模块：

1. 去重：多条记忆表达同一个意思，合并成一条。
2. 排序：按相关性、重要性、时间新鲜度综合打分，取Top-K。
3. 压缩：长文本用摘要模型压缩成短句。
4. 格式化：按固定模板拼进system prompt或user prompt。

我见过最优雅的做法是：把记忆分成“必须知道”和“可能有用”两类。必须知道的直接拼进system prompt，可能有用的放在user prompt后面作为参考。这样既保证了关键信息不丢，又不会让模型被无关信息干扰。

3. 实操落地：从零搭一套hindsight风格的Agent Memory

3.1 环境准备：Docker是绕不过去的坎

热搜词里Docker出现频率极高，说明大家在这上面踩坑不少。hindsight这类项目，依赖通常包括向量数据库（Milvus/Qdrant/Chroma）、关系型数据库（PostgreSQL/MySQL）、缓存（Redis）、消息队列（可选）。本地开发最省事的方式就是Docker Compose一把梭。

先给个我实测可用的docker-compose.yml骨架：

version: '3.8' services: postgres: image: postgres:15 environment: POSTGRES_USER: hindsight POSTGRES_PASSWORD: hindsight123 POSTGRES_DB: hindsight ports: - "5432:5432" volumes: - pgdata:/var/lib/postgresql/data redis: image: redis:7-alpine ports: - "6379:6379" qdrant: image: qdrant/qdrant:latest ports: - "6333:6333" - "6334:6334" volumes: - qdrant_data:/qdrant/storage volumes: pgdata: qdrant_data:

Windows用户注意：Docker Desktop安装时如果报“Virtualization support not detected”，大概率是BIOS里没开虚拟化。重启进BIOS，找Intel VT-x或AMD-V，设为Enabled。另外Windows 11家庭版需要先装WSL2，Docker Desktop会提示你装，跟着走就行。

注意：Docker Desktop默认走NAT网络，容器间通信用服务名就行。但如果你在容器里要访问宿主机上的服务（比如本地跑的LLM），得用host.docker.internal这个特殊域名，别用localhost。

3.2 记忆存储层：PostgreSQL + Qdrant双写

为什么用两个存储？PostgreSQL存结构化数据——用户ID、session ID、时间戳、记忆类型、重要性评分。Qdrant存向量——记忆内容的embedding。检索的时候，先用PostgreSQL过滤（比如“只要最近7天的”“只要重要性>0.7的”），再用Qdrant做向量相似度搜索。这叫预过滤+向量检索，比纯向量检索精度高很多。

建表语句大概长这样：

CREATE TABLE memories ( id UUID PRIMARY KEY DEFAULT gen_random_uuid(), user_id VARCHAR(64) NOT NULL, session_id VARCHAR(64), memory_type VARCHAR(32) NOT NULL, -- working/episodic/semantic content TEXT NOT NULL, importance FLOAT DEFAULT 0.5, created_at TIMESTAMP DEFAULT NOW(), last_accessed_at TIMESTAMP DEFAULT NOW(), access_count INT DEFAULT 0, metadata JSONB ); CREATE INDEX idx_memories_user_type ON memories(user_id, memory_type); CREATE INDEX idx_memories_created ON memories(created_at DESC);

Qdrant那边，collection的配置关键是距离度量选Cosine，向量维度跟你用的embedding模型对齐。如果用OpenAI的text-embedding-3-small，维度是1536；如果用BGE-M3，维度是1024。

3.3 记忆写入流程：从对话流到结构化记忆

我画不出图（也不让画），但可以用文字描述这个pipeline：

1. 对话截获：Agent每轮回复后，把(user_message, agent_response, tool_calls)打包成一个raw episode。
2. 重要性评分：用规则或小模型打分。规则可以这么写：包含“记住”“我喜欢”“我习惯”等关键词+0.3；包含具体事实（数字、日期、专有名词）+0.2；长度超过50字+0.1；纯寒暄-0.5。
3. 事实提取：用LLM从raw episode里抽三元组。Prompt大概是这样：“从以下对话中提取用户的事实性信息，以JSON格式输出，包含subject、predicate、object三个字段。如果没有事实性信息，输出空数组。”
4. 去重与合并：新提取的事实跟已有semantic memory比对，如果语义相似度>0.9，更新旧记忆的last_accessed_at和access_count，不新增。
5. 双写：结构化字段写PostgreSQL，embedding写Qdrant。

这里有个坑：事实提取的prompt要反复调。我试过直接用“提取关键信息”这种模糊指令，结果模型把“用户说今天天气不错”也提取出来了。后来改成明确要求“只提取关于用户身份、偏好、技能、环境配置的持久性事实”，噪音少了很多。

3.4 记忆检索流程：多路召回+重排序

检索的时候，我一般走这么几步：

1. Query理解：把用户当前问题用LLM改写成检索query。比如用户问“这个报错怎么修”，改写成“Docker网络不通 报错 解决方案”。
2. 多路召回：
   • 向量召回：Qdrant搜Top-20。
   • 关键词召回：PostgreSQL全文检索Top-20。
   • 时间召回：最近3天的episodic memory Top-10。
3. 合并去重：三路结果合并，按memory_id去重。
4. 重排序：用一个cross-encoder模型（比如bge-reranker）对合并后的结果精排，取Top-5。
5. 格式化注入：把Top-5记忆按模板拼成一段文本，插入prompt。

重排序这步很关键。向量召回是双塔模型，精度有限；cross-encoder是交互式模型，精度高但慢。先用双塔粗筛，再用cross-encoder精排，是业界标准做法。

3.5 记忆更新与遗忘：不是所有记忆都值得留一辈子

记忆系统要有“遗忘”机制。我见过一个团队，Agent Memory跑了半年，向量库膨胀到几千万条，检索延迟从50ms涨到2s。后来加了TTL和重要性淘汰，才降回来。

hindsight这类项目通常的遗忘策略：

• 时间淘汰：working memory session结束即删；episodic memory保留30天；semantic memory永久保留但定期压缩。
• 重要性淘汰：importance < 0.3且access_count = 0的记忆，7天后删除。
• 容量淘汰：每个用户最多保留1000条记忆，超出按重要性+时间综合排序淘汰。

提示：遗忘策略一定要可配置。不同场景需求不一样——客服Agent可能需要保留半年的对话记录，而代码助手可能只需要保留最近一周的。

4. 与MCP的集成：让Agent Memory成为可插拔能力

4.1 MCP是什么，为什么它跟Agent Memory天然契合

MCP（Model Context Protocol）是Anthropic推的一个协议，目的是让LLM应用能以标准化方式接入外部工具和数据源。你可以把它理解成“AI应用的USB接口”——以前每个工具都要写一套适配代码，现在只要实现MCP协议，就能被任何支持MCP的客户端调用。

热搜词里有人问“mcp是软件协议还是硬件协议”，答案是软件协议。它定义的是通信格式和交互流程，跟硬件没关系。还有“ruoyi-vue-pro合并mcp功能”，说明国内开发者已经在把MCP往传统Web框架里集成了。

Agent Memory跟MCP的契合点在于：记忆系统本质上就是一个外部数据源。用户问“我之前跟你说过什么”，Agent通过MCP调用memory server，检索出相关记忆，返回给LLM。这样记忆系统就跟Agent解耦了——你可以用hindsight，也可以用别的，只要实现MCP接口就行。

4.2 用MCP封装hindsight的memory server

一个MCP memory server大概需要暴露这几个tool：

• memory_write：写入一条记忆。参数：content, memory_type, importance, metadata。
• memory_search：检索记忆。参数：query, top_k, memory_type_filter, time_range。
• memory_forget：删除记忆。参数：memory_id或过滤条件。
• memory_summarize：对某个时间段的记忆做摘要。参数：user_id, start_time, end_time。

用Python实现的话，可以用mcp这个库：

from mcp.server import Server from mcp.types import Tool, TextContent app = Server("hindsight-memory") @app.list_tools() async def list_tools(): return [ Tool( name="memory_search", description="检索用户的历史记忆", inputSchema={ "type": "object", "properties": { "query": {"type": "string"}, "top_k": {"type": "integer", "default": 5}, "memory_type": {"type": "string", "enum": ["working", "episodic", "semantic"]} }, "required": ["query"] } ) ] @app.call_tool() async def call_tool(name: str, arguments: dict): if name == "memory_search": results = await search_memories( query=arguments["query"], top_k=arguments.get("top_k", 5), memory_type=arguments.get("memory_type") ) return [TextContent(type="text", text=format_results(results))]

这样任何支持MCP的客户端（比如Claude Desktop、Cursor、Codex）都能直接调用你的记忆系统。热搜词里“codex接入figma mcp怎么授权”“codex无法找到mcp”这些问题，本质都是MCP client配置问题，跟memory server本身没关系。

4.3 多Agent共享记忆：MCP的另一个优势

单Agent场景下，记忆系统就是个外挂。但多Agent场景下，MCP的价值就大了。比如一个团队有代码审查Agent、测试Agent、部署Agent，它们可以通过同一个MCP memory server共享记忆：

• 代码审查Agent发现“这个模块的异常处理有问题”，写入episodic memory。
• 测试Agent检索时看到这条记忆，重点测试异常路径。
• 部署Agent看到“该模块近期有变更”，触发回滚预案。

这种跨Agent的记忆共享，用MCP来做是最自然的。每个Agent不需要知道记忆存在哪、怎么检索，只需要调用MCP tool就行。

5. 常见问题与排查技巧实录

5.1 记忆检索不准：召回一堆无关内容怎么办

这是最常见的问题。我排查下来，原因通常有三个：

第一，embedding模型选错了。用通用embedding模型（比如text-embedding-ada-002）做代码相关记忆的检索，效果很差。代码场景建议用专门的代码embedding模型，或者至少用BGE-M3这种多语言、多场景的模型。

第二，chunk策略不对。把一整段对话作为一个chunk，embedding会稀释关键信息。正确做法是按语义切分——一个事实一个chunk，一个决策一个chunk。hindsight如果做得好，应该在写入时就做了细粒度切分。

第三，缺少重排序。纯向量召回Top-20，里面可能只有3条相关。加一个cross-encoder重排序，精度能提升30%以上。

排查步骤：

1. 拿一个具体query，看向量召回Top-20都是什么。
2. 人工标注哪些相关、哪些不相关。
3. 如果相关率<30%，检查embedding模型和chunk策略。
4. 如果相关率>50%但排序靠后，加重排序。

5.2 Docker网络不通：容器间通信的坑

热搜词里“docker网络不通”出现多次，我分享一个经典场景：PostgreSQL容器起来了，但应用容器连不上。

排查顺序：

1. docker ps看容器是否都在运行。
2. docker network ls看是否在同一个network。
3. docker exec -it app_container ping postgres看能否解析主机名。
4. 如果ping不通，检查docker-compose里是否声明了同一个network。
5. 如果ping通但连不上端口，检查PostgreSQL的pg_hba.conf是否允许远程连接。

注意：Docker Desktop在Windows和Mac上，容器访问宿主机的行为不一样。Windows用host.docker.internal，Mac也用这个，但Linux需要用宿主机的实际IP或--network host模式。

5.3 记忆膨胀导致检索变慢

前面提过，记忆不淘汰，向量库会爆炸。我实测的数据：Qdrant单collection超过100万条向量后，检索延迟从20ms涨到200ms。超过1000万条，直接上秒级。

解决方案：

• 按用户分collection，避免单collection过大。
• 加TTL，过期自动删除。
• 定期做记忆压缩——把多条相关episodic memory合并成一条semantic memory。
• 用量化索引（Qdrant支持scalar quantization），内存占用降4倍，精度损失很小。

5.4 LLM request failed: provider rejected the request schema or tool payload

这个报错在MCP集成时很常见。原因通常是tool的inputSchema定义跟实际传参不匹配。比如schema里定义top_k是integer，但客户端传了string"5"。

排查方法：

1. 打印实际发送的payload。
2. 对照MCP tool的inputSchema逐字段检查。
3. 在server端加参数类型转换和校验。

我一般会在server端加一层Pydantic校验，把类型转换和错误提示都做了，省得客户端传错类型直接崩。

5.5 常见问题速查表

6. 一些个人体会和后续扩展方向

我在实际搭这套东西的过程中，最大的体会是：Agent Memory的瓶颈不在技术，而在产品定义。什么该记、什么不该记、记多久、怎么用，这些问题没有标准答案，得根据具体场景反复调。我见过一个团队花了三个月做记忆系统，最后发现用户根本不需要跨session记忆——他们的场景是单次任务型的，session结束就结束了。所以动手之前，先想清楚你的用户到底需不需要“后视镜”。

另一个体会是：别一上来就追求完美。先用最简单的方案跑起来——PostgreSQL存文本，关键词检索，手动注入prompt。跑通了，有数据了，再逐步加向量检索、重排序、自动提取。我见过太多项目死在“架构设计太复杂，还没上线就重构了三遍”。

后续扩展的话，有几个方向我觉得值得试：

• 记忆可视化：让用户能看到Agent记住了什么，能手动编辑和删除。这不仅是功能，更是信任建设。
• 记忆共享：多Agent之间共享记忆，或者同一用户在不同应用间共享记忆。MCP让这件事变得可行。
• 记忆压缩：用LLM定期对episodic memory做摘要，生成semantic memory。这能大幅降低存储和检索成本。
• 记忆评估：建一套评估指标，比如检索命中率、注入后任务完成率提升、用户满意度变化。没有评估，优化就是盲人摸象。

最后分享一个小技巧：在prompt里显式告诉模型“你有记忆”。我试过，如果不告诉模型它可以参考历史记忆，即使你把记忆塞进了prompt，模型也可能忽略。加一句“以下是你之前与该用户的交互记忆，请在回答时参考”，效果立竿见影。这听起来很蠢，但实测有效。