1. 从“hindsight”说起为什么我们需要给Agent装一个“后视镜”“hindsight”这个词本身很有意思字面意思是“事后的洞察力”也就是我们常说的“事后诸葛亮”。但在Agent Memory和LLM工程化的语境里它指向的是一个非常具体且棘手的问题当一个大模型驱动的智能体Agent在完成多轮任务之后它能不能回过头来从自己过去的交互记录中提取出真正有价值的经验而不是把一堆原始对话日志原封不动地塞回上下文窗口我最初接触这个方向是因为在实际项目里踩了一个很典型的坑。当时我们在做一个基于LLM的自动化运维助手用户会连续几天跟它交互让它帮忙排查服务异常、生成巡检报告、记录变更操作。前几轮还好到了第十几轮之后模型开始“失忆”——它不记得三天前用户明确说过“这台机器不要重启上面跑着关键批处理”也不记得上周已经确认过某个告警是误报。每次都要用户重新解释一遍体验非常割裂。这就是当前LLM Agent最核心的瓶颈之一上下文窗口有限但真实任务的历史是无限增长的。你不可能把几百轮对话全部塞进prompt里成本扛不住注意力机制也会被稀释。于是就有了Agent Memory这个方向而“hindsight”代表的正是其中一种思路——不是简单地做向量检索而是让Agent具备一种“回头看”的能力从历史中提炼出结构化的、可复用的记忆单元。围绕这个标题热搜词里还出现了agent memory、MCP、Docker、LLM wiki、RAG、GraphRAG等一串关键词。这说明大家关心的不只是“记忆”这个概念本身而是它怎么落地用什么协议对接工具MCP怎么部署Docker怎么和现有的知识库体系LLM wiki、RAG结合。我下面会把这些线索串起来讲清楚一个可复现的Agent Memory方案应该怎么设计、怎么跑起来、怎么避坑。这篇文章适合谁看如果你正在做LLM应用开发尤其是涉及多轮对话、任务型Agent、自动化工作流或者你已经在用Docker部署一些LLM相关的服务那这篇内容应该能给你一些直接能抄的作业。如果你只是刚听说MCP和Agent Memory也没关系我会从最基础的概念讲起用生活化的类比把原理说透。2. 核心思路拆解Agent Memory到底在解决什么问题2.1 为什么“把历史全塞进去”是一条死路先算一笔账。假设一个Agent每天处理50轮对话每轮平均200个token一天就是10000个token。如果用户连续使用一个月历史记录就是30万token。当前主流模型的上下文窗口虽然已经能做到128K甚至200K但你把30万token全塞进去先不说超限的问题光是推理成本和延迟就足以让产品不可用。更关键的是长上下文并不等于有效记忆。有研究表明当上下文超过一定长度后模型对中间部分信息的召回率会显著下降这就是所谓的“lost in the middle”现象。所以Agent Memory的第一个核心任务就是做减法从海量历史中筛选出真正值得记住的东西。这跟人脑的工作方式很像——你不会记得今天中午吃了什么但你会记得“我对花生过敏”这种关键信息。Agent也需要这种筛选机制。2.2 Hindsight思路从“检索”到“反思”传统的RAG检索增强生成思路是把历史对话切片、向量化、存进向量数据库需要的时候做相似度检索。这个方法能解决一部分问题但它有个天然缺陷它只能找到“相似”的内容找不到“重要”的内容。比如用户三天前说“这台机器不要重启”这句话和当前“帮我重启一下服务”的查询在语义上并不相似向量检索很可能漏掉它。Hindsight的思路则更进一步它不只是被动地检索而是主动地“回头看”。具体来说它会在任务完成之后或者在一个固定的时间间隔触发一次“反思”过程——让LLM自己回顾最近一段时间的交互记录提取出关键事实、用户偏好、约束条件、已完成的动作然后把这些提炼后的信息写入一个结构化的记忆存储。下次需要的时候直接读取这些精炼后的记忆而不是去翻原始日志。这个“反思”过程可以用一个简单的prompt来实现比如reflection_prompt 你是一个记忆整理助手。请回顾以下对话记录提取出 1. 用户明确表达的偏好或约束如“不要重启”“优先用A方案” 2. 已经确认的事实如“某告警是误报”“某服务已下线” 3. 待办事项或未解决的问题 4. 任何可能影响未来决策的关键信息 请以JSON格式输出每个条目包含type、content、confidence三个字段。 对话记录 {conversation_history} 这个思路的好处是它把“记忆”从原始的、非结构化的文本变成了结构化的、可查询的数据。你可以把这些记忆存进关系型数据库、文档数据库甚至直接存成一个JSON文件然后根据type字段做精确过滤。这比纯向量检索要可靠得多。2.3 和MCP、Docker的关系为什么这些词会一起出现热搜词里MCP和Docker频繁出现这不是偶然的。MCPModel Context Protocol本质上是一个让LLM和外部工具、数据源对接的协议。你可以把它理解成“AI世界的USB接口”——不管你是要读数据库、调API、还是访问文件系统只要实现MCP协议LLM就能统一调用。在Agent Memory的场景里MCP的价值在于它可以把记忆存储做成一个标准的MCP Server。这样任何支持MCP的LLM客户端比如一些IDE插件、聊天界面、自动化平台都能直接接入这个记忆服务而不需要每个应用都自己实现一套记忆逻辑。这大大降低了集成的成本。而Docker则是部署层面的刚需。你要跑一个MCP Server、一个向量数据库、一个LLM网关如果每个都手动装环境光是依赖冲突就能让人崩溃。用Docker Compose把这些服务编排在一起一键启动这才是工程化的做法。后面我会给一个具体的docker-compose配置示例。3. 核心细节解析一个可落地的Agent Memory系统长什么样3.1 记忆的分层设计短期、长期、工作记忆我在实际项目中把Agent Memory分成三层这个分层方式参考了认知科学里的人类记忆模型但在工程上做了简化第一层是工作记忆Working Memory。这就是当前对话的上下文窗口容量有限通常只保留最近几轮交互。它的作用是维持对话的连贯性让Agent知道“刚才在聊什么”。这一层不需要额外存储就是prompt里的messages数组。第二层是短期记忆Short-term Memory。它存储的是最近几天或最近几次会话的摘要。比如每次会话结束后自动生成一个200字左右的摘要记录这次会话的主要目标和结论。下次会话开始时把最近3-5条摘要注入promptAgent就能快速恢复上下文。第三层是长期记忆Long-term Memory。这是经过多次“反思”后沉淀下来的结构化知识包括用户偏好、系统约束、历史决策记录等。这一层的数据量可以很大但每次只按需检索少量条目注入prompt。这三层的读写策略不同工作记忆是每轮都读写短期记忆是会话结束时写、会话开始时读长期记忆是定期反思时写、按需检索时读。分开管理之后整个系统的可控性会好很多。3.2 记忆的写入时机什么时候该“回头看”Hindsight的核心在于“事后反思”但反思的触发时机很关键。我试过几种方案一种是会话结束时触发。用户关闭对话窗口或者显式说“今天就到这里”就触发一次反思。这个方案最简单但问题是如果用户不主动结束反思就不会发生。另一种是每N轮对话触发一次。比如每10轮触发一次反思把最近10轮的内容提炼成记忆。这个方案比较均衡但N的取值需要调——太小了会增加LLM调用成本太大了会丢失细节。还有一种是我目前最推荐的基于事件触发。当检测到某些关键事件时触发反思比如用户表达了明确的偏好“以后都这样”、确认了某个重要事实“这个配置已经改好了”、或者完成了某个阶段性任务。这种触发方式最精准但需要额外的意图识别逻辑。实际落地时我通常会组合使用每10轮做一次常规反思同时监听关键事件做即时反思。这样既能保证覆盖率又不会太浪费token。3.3 记忆的检索策略不只是向量相似度检索长期记忆时如果只用向量相似度很容易漏掉关键信息。我的做法是混合检索先用元数据过滤缩小范围。比如当前任务是“重启服务”那就优先检索type为“constraint”且content里包含“重启”相关的记忆。再用向量检索做语义匹配补充一些元数据没覆盖到的内容。最后用时间衰减做排序。越近期的记忆权重越高但如果是高置信度的约束类记忆即使时间久远也保留高权重。这个混合策略可以用一个简单的打分公式来实现score 0.4 * metadata_match 0.4 * vector_similarity 0.2 * time_decay其中time_decay可以用指数衰减函数比如exp(-days / 30)表示30天前的记忆权重降到约0.37。这个参数可以根据实际场景调整。3.4 和LLM Wiki、RAG的关系记忆不等于知识库热搜词里出现了LLM wiki、RAG、GraphRAG这些概念很多人会把Agent Memory和知识库混为一谈。这里需要澄清一下知识库是静态的、领域相关的文档集合而Agent Memory是动态的、与具体用户和任务相关的交互记录。举个例子一个医疗问答Agent的知识库是医学指南和药品说明书这是RAG要处理的内容。而它的Agent Memory是“这位患者上次说对青霉素过敏”“这位患者偏好用中文回答”这是Hindsight要处理的内容。两者可以共用一套向量数据库基础设施但数据的来源、更新频率、检索策略都不一样。在实际架构里我通常会把知识库检索和记忆检索做成两个独立的模块然后在prompt组装阶段把两者的结果合并。这样职责清晰也方便分别优化。4. 实操过程用Docker和MCP搭一套可运行的记忆服务4.1 环境准备Docker Desktop安装与常见坑如果你在Windows上做开发第一步是装Docker Desktop。这个过程本身不复杂但有几个坑我踩过第一个坑是虚拟化支持。Docker Desktop需要开启WSL2或者Hyper-V如果你的机器BIOS里没开虚拟化启动时会报“virtualization support not detected”。解决办法是进BIOS把Intel VT-x或AMD-V打开。如果是公司电脑有安全策略限制可能需要联系IT。第二个坑是WSL2的内存占用。默认情况下WSL2会占用大量内存跑几个容器之后机器就卡了。可以在用户目录下创建一个.wslconfig文件限制内存和CPU[wsl2] memory8GB processors4 swap2GB第三个坑是镜像拉取慢。这个不用多说配置一个国内可访问的镜像加速地址就行具体地址各云厂商都有提供这里不展开。装好之后用docker --version和docker compose version确认一下版本。我建议用Docker Compose V2语法更简洁。4.2 用Docker Compose编排记忆服务下面是一个我实际用过的docker-compose配置包含三个服务记忆存储用PostgreSQL pgvector、MCP Server、以及一个简单的LLM网关用于调用模型做反思和摘要。version: 3.8 services: memory-db: image: pgvector/pgvector:pg16 environment: POSTGRES_USER: agent POSTGRES_PASSWORD: agent_memory_2024 POSTGRES_DB: agent_memory ports: - 5432:5432 volumes: - memory_data:/var/lib/postgresql/data healthcheck: test: [CMD-SHELL, pg_isready -U agent] interval: 10s timeout: 5s retries: 5 mcp-server: build: ./mcp-server ports: - 8080:8080 environment: DB_HOST: memory-db DB_PORT: 5432 DB_USER: agent DB_PASSWORD: agent_memory_2024 DB_NAME: agent_memory LLM_API_BASE: http://llm-gateway:8000 depends_on: memory-db: condition: service_healthy llm-gateway: image: ghcr.io/example/llm-gateway:latest ports: - 8000:8000 environment: MODEL_NAME: gpt-4o-mini API_KEY: ${LLM_API_KEY} volumes: - ./gateway-config:/app/config volumes: memory_data:这个配置里pgvector是PostgreSQL的向量扩展用来存记忆的embedding。mcp-server是我们自己写的服务实现MCP协议对外暴露记忆的读写接口。llm-gateway是一个轻量网关统一管理模型调用方便做限流和日志。启动命令很简单docker compose up -d然后用docker compose logs -f mcp-server看日志确认服务正常。4.3 MCP Server的核心实现MCP Server需要实现几个关键接口memory.write、memory.search、memory.reflect。下面是一个简化版的Python实现用的是FastAPI MCP SDKfrom fastapi import FastAPI from pydantic import BaseModel import asyncpg import numpy as np app FastAPI() class MemoryWrite(BaseModel): user_id: str type: str # preference, fact, constraint, todo content: str confidence: float 1.0 class MemorySearch(BaseModel): user_id: str query: str top_k: int 5 app.post(/memory/write) async def write_memory(item: MemoryWrite): embedding await get_embedding(item.content) async with pool.acquire() as conn: await conn.execute( INSERT INTO memories (user_id, type, content, confidence, embedding, created_at) VALUES ($1, $2, $3, $4, $5, NOW()) , item.user_id, item.type, item.content, item.confidence, embedding) return {status: ok} app.post(/memory/search) async def search_memory(query: MemorySearch): embedding await get_embedding(query.query) async with pool.acquire() as conn: rows await conn.fetch( SELECT content, type, confidence, 1 - (embedding $1) AS similarity FROM memories WHERE user_id $2 ORDER BY embedding $1 LIMIT $3 , embedding, query.user_id, query.top_k) return {results: [dict(r) for r in rows]}这里用的是pgvector的操作符做余弦距离计算。实际部署时还需要加上embedding的生成逻辑可以调OpenAI的embedding接口也可以用本地部署的小模型。4.4 反思流程的完整实现反思流程是整个Hindsight的核心。我的实现方式是每次会话结束后把最近的对话记录发给LLM让它输出结构化的记忆条目然后批量写入数据库。async def reflect_and_store(user_id: str, conversation: list): prompt build_reflection_prompt(conversation) response await call_llm(prompt) memories parse_json_response(response) for mem in memories: # 去重检查是否已有相似记忆 existing await search_similar(user_id, mem[content], threshold0.9) if existing: # 更新置信度或合并 await update_memory(existing[id], mem) else: await write_memory(MemoryWrite( user_iduser_id, typemem[type], contentmem[content], confidencemem[confidence] ))这里有个关键细节去重。如果不做去重同一个偏好会被反复写入导致检索时全是重复内容。我的做法是用向量相似度做判断如果相似度超过0.9就认为是同一条记忆做合并或更新而不是新增。4.5 参数选择与性能调优在实际跑的过程中有几个参数需要重点关注参数建议值说明反思触发间隔10轮对话太频繁浪费token太稀疏丢失细节检索top_k5-8条太多会稀释prompt太少可能漏关键信息相似度阈值0.75低于这个值的检索结果不注入prompt去重阈值0.9高于这个值认为是重复记忆时间衰减系数30天30天前的记忆权重降到0.37这些值不是固定的需要根据你的具体场景调。比如如果是客服场景用户偏好变化快时间衰减可以设短一点比如7天。如果是运维场景系统约束比较稳定可以设长一点比如90天。5. 常见问题与排查技巧实录5.1 记忆检索不准确怎么办这是最常见的问题。我遇到过的原因主要有三个第一是embedding模型选择不当。如果你用的是通用的文本embedding模型它可能对“约束类”语句的区分度不够。比如“不要重启”和“可以重启”在向量空间里可能很接近。解决办法是换一个在指令跟随数据上微调过的embedding模型或者在写入记忆时把type信息也拼进embedding的文本里比如[constraint] 不要重启这台机器。第二是检索时没有做元数据过滤。纯向量检索很容易被语义相似但类型不同的记忆干扰。加上type过滤之后准确率会明显提升。第三是记忆条目太碎。如果反思时提取的记忆太细比如把“用户说不要重启”和“用户说这台机器很关键”分成两条检索时可能只召回其中一条。我的做法是在反思prompt里明确要求“合并相关约束”让LLM输出更完整的记忆单元。5.2 Docker网络不通的排查思路用Docker Compose编排多个服务时网络问题很常见。我总结了一个排查顺序先用docker compose ps确认所有容器都在运行。用docker compose exec mcp-server ping memory-db测试容器间连通性。如果ping不通说明不在同一个网络里。默认情况下Compose会创建一个共享网络所有服务都在里面但如果你用了network_mode: host就会破坏这个机制。检查环境变量里的主机名是否和service名一致。Compose里的服务发现是基于service名的如果你在代码里写的是localhost那肯定连不上。检查端口映射。容器间通信用的是容器端口不是宿主机映射的端口。比如memory-db的5432是容器端口mcp-server应该连memory-db:5432而不是localhost:5432。5.3 LLM请求失败的常见原因热搜词里有一条“llm request failed: provider rejected the request schema or tool payload”这个我遇到过好几次。通常是因为JSON schema不匹配。如果你用了function calling或者structured output模型返回的JSON格式和你的schema对不上就会被拒绝。解决办法是在prompt里给出明确的JSON示例并且在代码里做容错解析。token超限。反思时如果把整段对话历史都塞进去很容易超限。我的做法是先做一轮摘要压缩把长对话压成短摘要再发给LLM。并发限流。如果你同时触发多个反思请求可能会被API限流。加一个简单的队列或者信号量控制并发数就行。5.4 记忆膨胀与清理策略长期运行之后记忆库会越来越大。如果不清理检索效率会下降成本也会上升。我的清理策略是定期归档低置信度记忆。confidence低于0.5且超过60天没被检索到的记忆移到归档表。合并重复记忆。每周跑一次去重任务把相似度高于0.95的记忆合并。设置记忆上限。每个用户的活跃记忆条目不超过500条超过之后按“最后检索时间置信度”排序淘汰末尾的。这些策略可以用一个定时任务来实现比如用cron或者APScheduler每天凌晨跑一次。5.5 常见问题速查表问题现象可能原因排查方法解决方案记忆检索不到关键约束embedding区分度不够手动测试几条约束的相似度在embedding文本里加type前缀容器间连接超时不在同一网络docker compose execping测试检查network配置避免host模式反思输出格式错误prompt不够明确查看LLM原始返回加JSON示例做容错解析记忆库增长过快去重逻辑失效统计重复条目比例调整去重阈值加定期合并任务检索延迟高向量索引未建查看查询执行计划建IVFFlat或HNSW索引6. 一些实操心得和扩展思路6.1 关于MCP协议的实际使用体验MCP协议目前还在快速演进中不同客户端的支持程度不一样。我在用的时候发现有些客户端对MCP Server的返回格式要求比较严格如果返回的JSON里有多余字段可能会被拒绝。建议在实现MCP Server时严格按照协议文档的schema来不要自己加字段。另外MCP的认证机制也需要注意。如果你的MCP Server暴露在公网上一定要加token认证。热搜词里有一个wss://api.xiaozhi.me/mcp/?token...的链接这说明已经有人在用WebSocket做MCP传输了。WebSocket的好处是支持双向通信适合需要实时推送的场景但实现复杂度比HTTP高一些。6.2 和Playwright MCP、Chrome DevTools MCP的结合热搜词里出现了playwright mcp和chrome devtools mcp这给了我一个启发Agent Memory不仅可以记录对话还可以记录Agent操作浏览器时的状态。比如Agent用Playwright打开了一个页面填了一个表单这个操作历史也可以作为记忆存下来。下次遇到类似任务时Agent可以直接复用之前的操作路径而不需要重新探索。这个思路在自动化测试和RPA场景里特别有用。你可以把每次操作的成功路径存成记忆失败路径也存下来作为“避坑指南”。这样Agent会越用越聪明。6.3 关于LLM Wiki和GraphRAG的思考LLM wiki这个概念最近很火Karpathy也提过类似的想法。我的理解是LLM wiki更像是一个“可读写的知识库”它不只是静态文档而是可以被LLM不断更新和修正的。这和Agent Memory有重叠但侧重点不同wiki更偏向领域知识memory更偏向交互经验。GraphRAG则是另一个方向它用知识图谱来组织信息适合处理实体关系复杂的场景。如果你的Agent需要理解“A依赖BB依赖C”这种链路关系GraphRAG会比纯向量检索更有效。但它的构建成本也更高需要做实体抽取和关系抽取。我的建议是先从简单的向量检索元数据过滤做起等确实遇到瓶颈了再上GraphRAG。6.4 最后分享一个小技巧如果你想让Agent的记忆更“人性化”可以在反思prompt里加一条要求让LLM用第一人称写记忆。比如不要写“用户表示不要重启”而是写“我记得用户说过这台机器不要重启”。这样在检索出来注入prompt时Agent读起来更像是在回忆自己的经历而不是在查数据库。实测下来这种写法能让Agent的回复更自然用户感知到的“记忆感”也更强。这个技巧不涉及任何复杂的技术就是prompt层面的一句话调整但效果提升很明显。你可以试试。
