1. 从“hindsight”这个词说起为什么它值得单独拿出来聊“hindsight”直译过来是“后见之明”但在技术圈尤其是围绕 LLM 和 Agent 的讨论里它指向的是一类非常具体的能力让智能体在任务执行完之后回过头去审视自己走过的路从已经发生的交互中提炼出可复用的经验。这件事听起来像“复盘”但落到工程实现上它牵扯到记忆存储、上下文压缩、检索策略、工具调用链路的重新编排甚至涉及 MCP 协议下不同服务之间的数据流转。我最初注意到这个词是因为一个很实际的问题大多数 Agent 在单轮对话里表现不错可一旦任务跨越多轮、涉及多个工具调用它就开始“忘事”。上一轮明明已经查到了关键参数下一轮又去重新查一遍前面已经确认过的约束条件后面推理时完全没纳入考虑。这不是模型能力不够而是记忆机制缺了“回看”这一环。hindsight 要解决的正是这个断层。这篇文章适合谁看如果你正在搭 Agent 系统、调 LLM 工作流、用 MCP 串接外部工具或者单纯对“Agent 怎么记住自己干过什么”这件事好奇那接下来的内容应该能给你一些可以直接上手的东西。我会从记忆架构的设计逻辑讲起拆到具体的存储结构、检索策略、MCP 集成方式再补上 Docker 环境下的部署细节和几个我实际踩过的坑。不堆概念尽量说人话。提示文中涉及的所有工具和协议均以公开技术文档和常见工程实践为准不涉及任何特定网络环境或敏感配置。2. Agent 记忆的三种形态working memory、episodic memory 和 hindsight 的位置在聊 hindsight 的具体实现之前得先把 Agent 记忆这件事拆清楚。目前业界比较通用的分法是把 Agent 记忆分成三类working memory工作记忆、episodic memory情景记忆和semantic memory语义记忆。这三者不是互斥的而是处在不同的时间尺度和抽象层级上。2.1 working memory当前任务窗口内的“草稿纸”working memory 最直观的理解就是模型当前的上下文窗口。你给它一个任务它把任务描述、中间结果、工具返回都塞进这个窗口里然后基于这些内容做下一步推理。它的特点是容量有限、生命周期短、随任务结束而清空。很多 Agent 框架所谓的“记忆”其实只是把历史对话拼接到 prompt 里这本质上还是在 working memory 层面做文章。问题在于上下文窗口再大也有上限。当你调了十几个工具、每个工具返回几百行 JSON窗口很快就被撑爆了。这时候要么截断要么压缩要么把一部分内容挪到外部存储。hindsight 的价值在这里就体现出来了它不是在窗口里硬塞而是在任务结束后把值得留下的东西写到窗口外面去。2.2 episodic memory按“经历”存储的原始记录episodic memory 记录的是“发生了什么”。比如“在 2024-11-05 14:23:07Agent 调用了 weather_api参数是 {city: ‘Hangzhou’}返回结果是 {temp: 18, condition: ‘cloudy’}”。这种记录是按时间线组织的、带上下文的、未经深度加工的。它的好处是保真度高坏处是检索效率低——你不可能每次推理都去扫一遍全部历史。我见过不少项目把 episodic memory 直接存成 JSON 文件或者塞进向量库结果要么查询慢要么召回不准。核心原因是原始经历里噪音太多直接拿来做检索相似度计算会被大量无关细节干扰。2.3 hindsight 的定位从 episodic 到 semantic 的提炼层hindsight 做的事是在 episodic memory 之上加一层离线提炼。任务结束后Agent 不是简单地把记录存下来就完事而是会触发一个“回看”流程把这次任务的完整轨迹拿出来让 LLM 自己总结——哪些步骤是有效的、哪些参数是关键、遇到了什么异常、下次遇到类似任务应该怎么做。总结出来的内容才是真正进入 semantic memory 的东西。打个比方episodic memory 是行车记录仪的原始视频hindsight 是事故发生后你回看视频写的那份“事故分析报告”semantic memory 则是你以后开车时脑子里那条“雨天路滑要减速”的经验规则。没有 hindsight你只有视频没有规则。记忆类型存储内容生命周期检索方式典型实现working memory当前上下文单次任务直接拼接prompt 窗口episodic memory原始交互轨迹长期时间/向量检索JSON 向量库semantic memory提炼后的经验长期语义检索知识库/规则库hindsight提炼过程本身触发式按任务触发LLM 总结 写入注意hindsight 不是一种独立的存储介质而是一个处理流程。它的输入是 episodic memory输出是 semantic memory。理解这一点后面搭系统时就不会把架构搞混。3. 用 MCP 串起记忆服务协议选型与数据流设计MCPModel Context Protocol在这套架构里扮演的是“连接器”的角色。Agent 本身不直接连数据库而是通过 MCP server 暴露的工具来读写记忆。这样做的好处是记忆服务可以独立部署、独立扩展Agent 端只需要知道工具名和参数格式。3.1 为什么用 MCP 而不是直接写 SDK直接写 SDK 当然也能跑通但有几个现实问题第一不同 Agent 框架的 SDK 接口不统一换一个框架就要重写一遍第二记忆服务的鉴权、限流、监控这些事散落在业务代码里很难维护第三调试的时候你没法单独测试记忆读写必须把整个 Agent 跑起来。MCP 把这些事标准化了。记忆服务作为一个 MCP server 跑起来暴露store_episode、query_memory、trigger_hindsight这几个工具。Agent 端不管是 Python 写的还是 TypeScript 写的只要支持 MCP 客户端就能用同一套接口。我实测下来用 MCP 封装之后记忆模块的替换成本从“改三天代码”降到了“改一个配置”。3.2 记忆 MCP server 的工具设计一个最小可用的记忆 MCP server我建议至少暴露以下工具store_episode(task_id, step_index, action, observation, timestamp)写入一条原始经历。参数里task_id用来把同一次任务的步骤串起来step_index保证顺序可还原。query_episodes(task_id, limit)按任务 ID 拉取原始轨迹用于 hindsight 触发时的输入。trigger_hindsight(task_id)触发提炼流程内部会调 LLM 做总结然后把结果写入 semantic 存储。query_semantic(query_text, top_k)语义检索返回提炼后的经验条目。list_tasks(status, limit)列出任务及其状态方便排查哪些任务还没做 hindsight。这几个工具的参数设计有个细节store_episode里的observation字段我建议存原始返回的字符串不要提前做结构化解析。因为 hindsight 阶段 LLM 需要看到完整信息才能判断哪些细节重要你提前解析成结构化数据反而可能丢掉关键线索。3.3 数据流从任务执行到经验入库完整的数据流是这样的Agent 接到任务生成task_id。每执行一步调工具、推理、得到结果通过 MCP 调store_episode写入一条记录。任务结束成功或失败Agent 调trigger_hindsight(task_id)。记忆 server 收到触发后先调query_episodes拉取该任务全部轨迹。把轨迹拼成 prompt调 LLM 做总结要求输出结构化的经验条目。把经验条目写入 semantic 存储可以是向量库也可以是结构化数据库。下次新任务开始时Agent 先调query_semantic拉取相关经验注入到 working memory 里。这个流程里第 5 步的 prompt 设计是关键。我试过几种模板最后稳定下来的格式是要求 LLM 输出 JSON 数组每条包含situation什么场景、action做了什么、result结果如何、lesson经验教训四个字段。这样后续检索和展示都方便。[ { situation: 调用天气 API 查询杭州天气, action: 使用 city 参数传入 Hangzhou, result: 成功返回温度 18 度多云, lesson: 城市名用拼音首字母大写格式API 接受度最高 } ]提示hindsight 的 LLM 调用建议用温度较低的配置比如 0.2 以下因为总结任务需要稳定输出不需要创造性。温度高了容易生成花哨但无用的“经验”。4. Docker 环境下的部署从 compose 文件到持久化存储记忆服务要长期跑Docker 是最省心的方式。但这里有几个坑我一个个说。4.1 docker-compose 编排三个服务的依赖关系一个完整的记忆服务栈通常包含三个容器记忆 MCP server、向量数据库用于 semantic 存储、关系型数据库用于 episodic 存储和任务状态。用 docker-compose 编排时依赖顺序很重要——MCP server 启动时要能连上后面两个库否则会反复重启。version: 3.8 services: memory-mcp: build: ./memory-mcp ports: - 8080:8080 environment: - EPISODIC_DB_URLpostgresql://user:passepisodic-db:5432/memory - SEMANTIC_DB_URLhttp://vector-db:6333 - LLM_API_KEY${LLM_API_KEY} depends_on: episodic-db: condition: service_healthy vector-db: condition: service_started restart: unless-stopped episodic-db: image: postgres:16 environment: - POSTGRES_USERuser - POSTGRES_PASSWORDpass - POSTGRES_DBmemory volumes: - episodic_data:/var/lib/postgresql/data healthcheck: test: [CMD-SHELL, pg_isready -U user] interval: 5s retries: 5 vector-db: image: qdrant/qdrant:latest volumes: - vector_data:/qdrant/storage ports: - 6333:6333 volumes: episodic_data: vector_data:这里depends_on用了condition: service_healthy确保 Postgres 真正就绪之后 MCP server 才启动。我一开始没加这个结果 MCP server 启动时连不上库直接崩了然后 Docker 的 restart 策略让它反复重启日志刷得飞快排查了半天才发现是启动顺序问题。4.2 数据持久化volume 挂载的注意事项上面 compose 文件里用了 named volume这是推荐做法。但如果你是在 Windows 上用 Docker Desktop要注意named volume 的实际存储位置在 WSL2 的虚拟磁盘里直接去文件系统找是找不到的。想备份数据的话用docker run --rm -v episodic_data:/data -v $(pwd):/backup alpine tar czf /backup/episodic.tar.gz -C /data .这种命令来打包。另外向量库的 volume 挂载路径要确认清楚。Qdrant 默认存储在/qdrant/storage你挂载的时候如果写成/qdrant会把整个目录覆盖掉导致配置丢失。这个坑我踩过一次容器起来之后一直报“collection not found”查了半天才发现是挂载路径写错了。4.3 资源限制别让记忆服务把宿主机吃干记忆服务本身不重但向量库和 LLM 调用可能会吃资源。建议在 compose 里加上资源限制deploy: resources: limits: memory: 2G cpus: 1.5尤其是向量库如果你不做限制它可能会把索引全加载到内存里。数据量小的时候没感觉上了十万条以上内存占用会明显上升。我一般给 Qdrant 配 2G 内存上限超过这个量级就考虑分片或者换更轻量的方案。注意Docker Desktop 在 Windows 上默认使用 WSL2 后端如果你遇到virtualization support not detected这类报错先去 BIOS 里确认虚拟化选项是否开启再检查 WSL2 是否正常安装。这跟记忆服务本身无关但会卡住整个部署流程。5. 检索策略为什么“相似度”不是唯一指标semantic memory 存进去之后怎么查出来是个大学问。最直觉的做法是向量相似度检索把 query 转成 embedding去向量库里找最相近的几条。但实际用下来纯相似度检索在 Agent 记忆场景下经常翻车。5.1 相似度检索的盲区时间衰减和任务相关性举个例子你存了一条经验“调用支付接口时金额参数要传分为单位的整数”。后来 Agent 在处理一个完全无关的文本翻译任务时query 是“如何处理文本中的数字”向量相似度可能会把这条支付经验排到前面因为都涉及“数字处理”。这就是语义相似但任务不相关的典型误召回。我的做法是加两层过滤第一层用任务类型标签做粗筛每条经验在写入时打上task_category标签比如api_call、data_transform、text_process第二层再用向量相似度在同类经验里精排。这样召回准确率明显提升。另外时间衰减也要考虑。三个月前的经验和昨天的经验即使内容一样权重也应该不同。我在检索打分公式里加了一个衰减因子final_score similarity * (0.98 ** days_since_created)这个 0.98 是拍脑袋定的实际调的时候可以根据经验更新频率来改。更新频繁的领域衰减可以快一点稳定的领域衰减慢一点。5.2 混合检索关键词 向量 规则纯向量检索还有个问题对精确匹配不敏感。比如你存了一条“API 返回 429 时应该退避 2 秒重试”query 是“429 错误怎么处理”向量检索可能召回一条“HTTP 错误码大全”的经验而不是那条具体的重试策略。因为“429”这个精确 token 在向量空间里被稀释了。解决办法是混合检索先用关键词匹配比如 BM25召回一批再用向量相似度召回一批最后做融合排序。融合算法可以用 RRFReciprocal Rank Fusion简单有效def rrf_score(rank, k60): return 1.0 / (k rank)把两个列表的 RRF 分数加起来排序效果比单一检索稳得多。我实测下来混合检索的召回率比纯向量检索高了大概 20 到 30 个百分点尤其是在技术类经验上。5.3 检索结果注入 prompt 的格式召回之后怎么把经验塞进 prompt 也有讲究。我试过直接拼 JSON也试过自然语言描述最后发现结构化但带自然语言解释的格式效果最好[经验 1] 场景调用外部 API 返回 429 做法等待 2 秒后重试最多重试 3 次 结果成功获取数据 注意重试间隔不要固定建议指数退避这种格式 LLM 理解起来最顺既保留了结构又有足够的上下文。纯 JSON 太干纯自然语言又容易丢字段。提示注入的经验条数不要太多一般 3 到 5 条就够了。塞太多会挤占 working memory反而影响当前任务的推理。我一般按 final_score 排序取 top 5超过 5 条的截断。6. 踩坑实录hindsight 触发时机与 LLM 总结的边界这套东西跑起来之后我遇到了几个比较典型的问题这里详细说一下排查过程。6.1 任务没结束就触发 hindsight导致经验不完整最开始我把trigger_hindsight放在了 Agent 的“任务完成”回调里。但实际跑的时候发现有些任务会中途失败失败之后 Agent 可能还会重试重试成功之后才算真正结束。如果失败时就触发 hindsight总结出来的经验是“这个任务失败了”但实际上是“第一次失败、第二次成功”经验完全不对。后来改成只在任务最终状态确定后触发不管是成功还是彻底失败。判断“最终状态”的逻辑放在 Agent 端重试次数用尽、或者显式标记完成才调trigger_hindsight。这个改动之后经验质量明显提升。6.2 LLM 总结时“编造”不存在的步骤这是最头疼的问题。LLM 在做 hindsight 总结时有时候会“脑补”一些轨迹里没有的步骤。比如轨迹里只调了一次天气 API总结里却写“先查了天气又查了空气质量”。这种编造的经验一旦入库后续检索出来会误导 Agent。我的解决办法是在 prompt 里加硬约束要求 LLM 只基于提供的轨迹做总结每条经验必须引用具体的 step_index。然后在解析输出时做校验如果引用的 step_index 不存在就丢弃这条经验。这个校验逻辑加上之后编造问题基本消失了。def validate_lesson(lesson, valid_step_indices): if lesson.get(step_index) not in valid_step_indices: return False return True6.3 经验库膨胀什么时候该清理旧经验跑了一段时间之后semantic memory 里的经验越来越多检索速度开始下降而且有些经验已经过时了比如 API 版本升级旧的参数格式不再适用。这时候需要一套清理机制。我目前的做法是每条经验带一个last_hit_at字段记录最后一次被检索命中的时间。如果一条经验超过 90 天没有被命中就标记为“冷经验”在检索时降权。超过 180 天没命中直接归档到冷存储不参与在线检索。这个策略跑下来经验库的规模稳定在一个可控范围内检索延迟没有明显增长。另外如果同一条经验被反复命中说明它确实有用可以给它加一个hit_count在排序时适当提权。这样形成正反馈好经验越来越容易被召回差经验自然沉底。6.4 MCP 连接超时导致的经验丢失还有一个坑是 MCP 连接层面的。Agent 调store_episode时如果记忆 server 响应慢或者网络抖动可能会超时。超时之后 Agent 端如果直接忽略这条经历就丢了hindsight 总结时就会缺步骤。我的处理方式是在 Agent 端加本地缓冲store_episode失败时先把记录写到本地临时文件等连接恢复后再补发。补发的时候带上原始时间戳保证顺序不乱。这个缓冲机制加上之后经验丢失的情况基本没再出现过。注意本地缓冲文件要定期清理避免磁盘占满。我一般设置保留最近 7 天的缓冲记录超过就自动删除。7. 从 hindsight 到持续学习这套架构还能怎么扩展hindsight 跑通之后我发现在它基础上还能做不少延伸。这里分享几个我正在试的方向不一定成熟但思路可以参考。第一个方向是跨任务的经验关联。目前每条经验是独立的但实际上很多经验之间有因果关系。比如“API 返回 429 要重试”和“重试时要加指数退避”这两条经验如果能在检索时一起召回效果会更好。我试过用图数据库把经验之间的关联关系存起来检索时做一跳扩展召回质量有提升但图数据库的维护成本不低还在权衡。第二个方向是hindsight 的自动化触发。目前是任务结束后手动触发未来可以考虑按时间窗口批量触发比如每小时把这一小时内的新任务统一做一次 hindsight这样 LLM 调用可以批量化成本更低。但批量总结可能会丢失单个任务的细节需要做权衡。第三个方向是经验的多 Agent 共享。如果多个 Agent 共用一套记忆服务一个 Agent 学到的经验其他 Agent 也能检索到。这在多 Agent 协作场景下很有价值但需要解决经验冲突的问题——不同 Agent 对同一场景可能有不同的处理方式直接共享可能会互相干扰。我目前的思路是给经验加上source_agent标签检索时根据当前 Agent 的偏好做加权。这套东西说到底核心就一句话让 Agent 不只是“做完就忘”而是能从做过的事情里提炼出下次能用的东西。hindsight 是这个链条上的关键一环但也不是全部。working memory 的管理、episodic 的存储效率、semantic 的检索质量每一环都会影响最终效果。我自己的体会是先把最小闭环跑通——存一条、总结一条、查一条——然后再逐步优化各个环节比一上来就追求完美架构要靠谱得多。