1. 从“hindsight”这个词说起为什么记忆是Agent落地的最后一公里“hindsight”这个词本身很有意思字面意思是“事后的洞察力”也就是我们常说的“后见之明”。把这个词用在一个Agent项目上指向性其实非常明确它要解决的是Agent在任务执行完之后能不能回头看、能不能记住、能不能从已经发生的事情里提取经验。这恰恰是当前LLM Agent落地过程中最容易被低估、也最要命的一环。我接触过不少Agent项目从简单的工具调用到复杂的多步规划绝大多数团队在早期都会把精力砸在prompt工程、工具编排、模型选型上但真正跑起来之后用户抱怨最多的往往不是“它不够聪明”而是“它记不住我刚才说过什么”“它每次都要重新问一遍”“它明明上次已经处理过类似的问题了”。这就是记忆层缺失带来的体验断层。Agent的working memory如果只依赖上下文窗口那本质上就是一个金鱼记忆系统窗口一满前面的事情全部归零。“hindsight”这个项目标题配合agent memory、LLM、MCP、Docker这几个关键词基本可以勾勒出一个清晰的技术画像这是一个围绕Agent记忆机制构建的系统大概率涉及记忆的存储、检索、压缩和跨会话复用同时通过MCP协议与外部工具或数据源打通并且以Docker作为部署和分发的载体。它要解决的核心问题就是让Agent具备“回头看”的能力把一次性的对话变成可积累的经验资产。这篇文章我会从记忆层的设计逻辑讲起拆解Agent memory到底应该存什么、怎么存、怎么取然后聊MCP在这个体系里扮演什么角色接着给出基于Docker的完整部署和实操路径最后分享几个我在实际搭建过程中踩过的坑和验证过的调优手段。不管你是刚开始接触Agent开发还是已经在做记忆相关模块应该都能从中拿到可以直接用的东西。2. Agent memory到底该存什么三层记忆结构的拆解2.1 为什么不能把所有东西都塞进向量库很多人一提到Agent记忆第一反应就是“上向量数据库”。这个思路不能算错但太粗糙了。我见过不少项目把每一轮对话原封不动地embedding之后丢进向量库结果就是检索出来的内容又长又碎噪声极大模型拿到之后反而被干扰。问题的根源在于记忆不是同质的不同类型的记忆需要不同的存储策略和检索方式。从认知科学的角度类比人的记忆至少分三层感觉记忆、短期记忆、长期记忆。Agent其实也需要类似的分层。我在实际项目中通常会把Agent memory拆成三个层次来设计每一层的存储介质、生命周期、检索方式都不一样。第一层是工作记忆working memory对应当前会话的上下文。这一层就是放在内存或者Redis里的最近N轮对话特点是读写极快、容量有限、会话结束就丢弃。它的作用是维持当前任务的连贯性让Agent知道“我刚才在干什么”。这一层不需要向量检索直接按时间顺序拼接就行。第二层是情景记忆episodic memory对应过去发生过的具体事件和交互。比如“上周三用户让我帮他订了一张去上海的机票”“昨天处理过一个类似的报错”。这一层需要持久化存储通常用结构化数据库加向量索引的混合方案。检索的时候既要能按时间范围过滤也要能按语义相似度召回。第三层是语义记忆semantic memory对应从多次交互中抽象出来的规律和知识。比如“这个用户偏好简洁的回答”“这类报错通常是因为配置项缺失导致的”。这一层是最高级的需要Agent在任务结束后主动做总结和归纳把零散的情景记忆压缩成可复用的知识条目。提示三层记忆不是必须全部实现但如果你只做一层那大概率会遇到“要么记不住要么记太乱”的问题。建议至少把工作记忆和情景记忆分开处理。2.2 记忆条目的结构化设计光分层还不够每一条记忆本身也需要有结构。我见过最粗暴的做法是把整段对话直接存成一条记录检索出来就是一大坨文本。这种做法在Demo阶段能跑通但到了真实场景就会暴露问题检索精度低、token消耗大、无法做细粒度的更新和删除。我的做法是给每条记忆定义一套schema至少包含以下几个字段字段名类型说明memory_idstring唯一标识建议用UUIDsession_idstring所属会话用于按会话聚合memory_typeenumworking / episodic / semanticcontenttext记忆的正文内容建议控制在200字以内summarytext一句话摘要用于快速预览和粗筛embeddingvector内容的向量表示用于语义检索entitiesjson涉及的关键实体如人名、工具名、文件路径timestampdatetime创建时间用于时间衰减和排序access_countint被检索命中的次数用于热度排序importancefloat重要性评分0到1之间ttlint过期时间秒为单位0表示永不过期这套schema看起来字段不少但每一个都有实际用途。比如entities字段在检索的时候可以先做实体匹配做粗筛再用向量做精排效果比纯向量检索好很多。access_count和importance结合起来可以做记忆的淘汰策略避免向量库无限膨胀。ttl则用于处理那些有时效性的记忆比如“用户当前正在处理的临时任务”。2.3 记忆的写入时机与压缩策略记忆写得好不好很大程度上取决于写入时机的选择。我的经验是不要在每一轮对话结束后都写记忆那样会产生大量冗余。比较合理的写入时机有三个第一个是任务完成时。当一个多步任务走到终点把整个任务的执行路径压缩成一条情景记忆。比如“用户要求生成一份销售报告我调用了数据库查询工具、图表生成工具、文档导出工具最终产出了PDF”。这条记忆的价值在于下次遇到类似任务时可以直接复用执行路径。第二个是用户显式反馈时。用户说“记住我喜欢用表格展示数据”或者“以后不要用这种格式”这种信号必须立刻写入语义记忆而且importance要给高分。第三个是会话即将结束时。对整个会话做一次总结提取出关键决策点和未完成事项写入情景记忆。这一步可以用一个小模型来做成本很低但收益很大。压缩策略方面我通常会用“滑动窗口摘要”的组合。工作记忆保留最近10轮原始对话超过的部分用模型压缩成一段摘要摘要再超过一定长度就进一步压缩。这样可以在有限的上下文窗口里保留尽可能多的有效信息。实测下来这种方案比单纯截断或者单纯摘要的效果都要好因为近期细节完整远期信息不丢失。3. MCP在记忆体系里的位置不只是工具调用协议3.1 MCP解决的是记忆的“出入口”问题MCPModel Context Protocol这两年被讨论得很多但大多数讨论都集中在“怎么用MCP接工具”这个层面。其实在Agent memory的语境下MCP的价值远不止工具调用。它本质上解决的是记忆的“出入口”标准化问题。你想Agent的记忆要发挥作用必须能在合适的时机被写入、被检索、被注入到上下文里。如果没有一套标准协议每个记忆后端都要写一套适配代码换一个存储方案就要重写一遍。MCP的出现让这件事变得规范了记忆的读写可以抽象成一组标准的工具接口Agent通过MCP client调用这些接口底层用什么存储、什么检索算法对上层完全透明。我在设计hindsight这类系统的时候通常会把记忆相关的操作封装成几个MCP toolmemory_write写入一条记忆参数包括content、type、importance等memory_search语义检索记忆参数包括query、top_k、type_filtermemory_update更新已有记忆的内容或元数据memory_delete删除指定记忆memory_summarize对指定范围的记忆做摘要压缩这样一来Agent的prompt里只需要描述“什么时候该调用哪个记忆工具”具体的存储实现完全解耦。今天用SQLite加FAISS明天换成PostgreSQL加pgvector上层代码一行不用改。3.2 MCP server的部署形态选择MCP server的部署方式直接影响到整个系统的稳定性和可维护性。常见的部署形态有三种各有适用场景。第一种是本地进程模式MCP server和Agent跑在同一台机器上通过stdio通信。这种模式最简单适合开发和单机部署。缺点是没法多Agent共享记忆而且进程挂了记忆就断了。第二种是独立服务模式MCP server作为一个HTTP服务独立部署Agent通过SSE或者streamable HTTP连接。这种模式适合多Agent协作场景记忆可以集中管理。缺点是需要处理网络通信的稳定性和鉴权问题。第三种是容器化部署模式把MCP server打包成Docker镜像通过Docker Compose或者Kubernetes编排。这种模式结合了前两种的优点既有独立服务的可扩展性又有容器化的环境一致性。对于hindsight这种需要持久化存储的项目我强烈推荐这种模式。注意MCP server如果走HTTP模式一定要加鉴权。我见过不少项目把MCP server直接暴露在公网上没有任何认证等于把Agent的记忆库完全敞开。至少加一个Bearer Token生产环境建议上mTLS。3.3 记忆检索的MCP工具设计细节memory_search这个工具的设计有很多讲究直接影响到检索质量和token消耗。我通常会给它设计这么几个参数{ query: 用户上次提到的报告格式偏好, top_k: 5, type_filter: [semantic, episodic], time_range: { start: 2024-01-01T00:00:00Z, end: 2024-12-31T23:59:59Z }, min_importance: 0.3, include_content: true, max_content_length: 500 }这里有几个细节值得展开说。top_k不要设太大3到5条通常就够了多了反而引入噪声。type_filter让Agent可以指定只搜某一类记忆比如做规划的时候只搜语义记忆做具体任务的时候搜情景记忆。time_range用于处理时效性强的查询。min_importance可以过滤掉低价值的记忆。include_content和max_content_length控制返回内容的详细程度有时候Agent只需要知道“有这么一条记忆”不需要全文。返回结果的结构也要设计好我一般会返回一个数组每条包含memory_id、summary、content可选、relevance_score、timestamp。Agent拿到之后可以根据relevance_score决定要不要深入读取某条记忆的全文。4. 用Docker把整套记忆系统跑起来4.1 容器编排的整体架构hindsight这类项目的部署我建议用Docker Compose来编排因为涉及的组件比较多手动管理容易乱。一个典型的架构包含以下几个容器agent-coreAgent的主进程负责对话管理和工具调用mcp-memory-server记忆服务的MCP server对外暴露记忆读写接口vector-db向量数据库比如Qdrant或者Milvus负责语义检索relational-db关系型数据库比如PostgreSQL负责结构化记忆的存储cacheRedis负责工作记忆和热点记忆的缓存embedding-service向量化服务可以用TEI或者自己封装一个这几个容器通过Docker网络互联只有agent-core和mcp-memory-server需要对外暴露端口数据库和缓存只在内部网络通信。这样既保证了安全性也方便做水平扩展。4.2 Docker Compose配置的关键细节下面是一份我实际用过的docker-compose.yml骨架重点看几个容易出问题的地方version: 3.9 services: mcp-memory-server: build: context: ./mcp-memory-server dockerfile: Dockerfile ports: - 8080:8080 environment: - VECTOR_DB_URLhttp://vector-db:6333 - RELATIONAL_DB_URLpostgresql://user:passrelational-db:5432/memory - REDIS_URLredis://cache:6379/0 - EMBEDDING_SERVICE_URLhttp://embedding-service:8081 - MCP_AUTH_TOKEN${MCP_AUTH_TOKEN} depends_on: vector-db: condition: service_healthy relational-db: condition: service_healthy cache: condition: service_started networks: - memory-net restart: unless-stopped vector-db: image: qdrant/qdrant:latest volumes: - qdrant-data:/qdrant/storage healthcheck: test: [CMD, curl, -f, http://localhost:6333/healthz] interval: 10s timeout: 5s retries: 5 networks: - memory-net relational-db: image: postgres:16-alpine environment: - POSTGRES_USERuser - POSTGRES_PASSWORDpass - POSTGRES_DBmemory volumes: - pg-data:/var/lib/postgresql/data healthcheck: test: [CMD-SHELL, pg_isready -U user -d memory] interval: 10s timeout: 5s retries: 5 networks: - memory-net cache: image: redis:7-alpine command: redis-server --appendonly yes --maxmemory 512mb --maxmemory-policy allkeys-lru volumes: - redis-data:/data networks: - memory-net embedding-service: image: ghcr.io/huggingface/text-embeddings-inference:latest command: --model-id BAAI/bge-small-zh-v1.5 --port 8081 volumes: - embedding-cache:/data networks: - memory-net volumes: qdrant-data: pg-data: redis-data: embedding-cache: networks: memory-net: driver: bridge这份配置里有几个点是我踩过坑之后才加上的。depends_on配合condition: service_healthy非常关键否则mcp-memory-server可能在数据库还没就绪的时候就启动导致连接失败。Redis的maxmemory-policy设成allkeys-lru避免缓存把内存吃满。embedding-service的模型选择要考虑中文场景bge-small-zh是个不错的平衡点速度快、效果够用。4.3 数据持久化与备份策略记忆数据是Agent的核心资产丢了就没了所以持久化必须做扎实。Docker的volume机制本身能保证容器重启后数据不丢但这还不够还需要考虑备份和迁移。我的做法是三层保护。第一层是数据库自身的持久化机制PostgreSQL开WAL归档Qdrant开snapshot。第二层是定期导出用一个cron容器每天把PostgreSQL的memory表导出成SQL文件把Qdrant的collection导出成snapshot文件存到独立的备份volume里。第三层是异地备份把备份文件同步到对象存储或者另一台机器上。恢复的时候也有讲究。PostgreSQL直接restore SQL文件就行但Qdrant的snapshot恢复需要先创建同名collection再导入。我建议把恢复步骤写成一个脚本定期演练一遍免得到真出事的时候手忙脚乱。提示Qdrant的snapshot文件比较大如果记忆量在百万条以上单次snapshot可能好几个G。建议做增量备份或者用Qdrant的collection alias机制做蓝绿切换。5. 记忆检索质量的调优从能用到好用5.1 混合检索比纯向量检索靠谱得多纯向量检索在记忆场景下有个致命问题它对精确匹配不敏感。比如用户问“我上次让你查的那个订单号是多少”向量检索可能召回一堆语义相似但订单号不同的记忆。这时候就需要引入关键词检索做补充。我的方案是混合检索向量召回和BM25召回各取top 20然后用RRFReciprocal Rank Fusion做融合排序。RRF的公式很简单对每个文档把它在各个召回列表里的排名取倒数再求和。这个方法的优点是无需调参对不同类型的召回结果都能公平融合。def rrf_fusion(vector_results, bm25_results, k60): scores {} for rank, doc_id in enumerate(vector_results): scores[doc_id] scores.get(doc_id, 0) 1.0 / (k rank 1) for rank, doc_id in enumerate(bm25_results): scores[doc_id] scores.get(doc_id, 0) 1.0 / (k rank 1) return sorted(scores.items(), keylambda x: x[1], reverseTrue)实测下来混合检索在记忆场景的召回准确率比纯向量检索能高出15到20个百分点尤其是涉及具体数字、文件名、工具名的查询提升非常明显。5.2 时间衰减与重要性加权记忆的价值不是恒定的新记忆通常比旧记忆更相关高重要性的记忆应该优先被召回。所以在排序的时候除了相关性分数还要叠加时间衰减和重要性权重。时间衰减我用的是指数衰减公式是score * exp(-lambda * days_ago)lambda取0.01左右意味着大约70天后记忆的权重降到一半。重要性权重直接乘上去就行importance在0到1之间。最终的排序分数是relevance * time_decay * (0.5 0.5 * importance)这样既考虑了语义相关性也考虑了时效性和重要性。这个公式里的系数不是拍脑袋定的我做过一轮A/B测试用不同的系数组合跑了一周的线上流量最后选定了这组。当然不同场景可能需要调整比如客服场景可能更看重时效性知识库场景可能更看重重要性。5.3 记忆去重与冲突消解记忆写多了必然会出现重复和冲突。比如用户今天说“我喜欢用Markdown格式”明天说“以后都用纯文本吧”这两条语义记忆是冲突的。如果不处理Agent检索到两条矛盾的信息行为就会不稳定。我的处理策略是写入新记忆之前先做一次相似度检索如果发现相似度超过0.9的已有记忆就走更新流程而不是新增。更新的时候保留历史版本但把旧版本标记为superseded检索时默认只返回最新版本。对于明确冲突的情况比如上面那个格式偏好的例子用时间戳新的覆盖旧的同时在记忆里记录一条“偏好变更”的元数据。去重这块还有个细节不同来源的记忆可能有不同的可信度。用户显式说的可信度最高Agent自己总结的可信度次之从外部文档提取的可信度再次。我通常会给每条记忆加一个source字段检索排序的时候根据source做微调。6. 实际跑起来之后才会遇到的几个坑6.1 上下文注入的token预算控制记忆检索出来之后要注入到Agent的上下文里但上下文窗口是有限的。我见过不少项目检索了20条记忆每条500字一下子就把窗口占满了留给当前对话的空间所剩无几。我的做法是给记忆注入设一个硬预算比如总token不超过2000。在这个预算内按相关性排序依次注入每条记忆的内容长度动态调整。高相关性的记忆给全文中等相关性的给摘要低相关性的只给标题。这样可以在有限预算内最大化信息密度。还有一个技巧是把记忆注入的位置放在system prompt之后、用户消息之前并且用明确的分隔符标记出来。这样模型能清楚区分哪些是历史记忆、哪些是当前输入减少混淆。6.2 记忆写入的异步化记忆写入如果做成同步的会显著增加每轮对话的延迟。尤其是做摘要压缩的时候要调用模型可能好几秒。用户等不起。我的方案是把记忆写入做成异步任务。对话结束后把需要写入的记忆丢进一个消息队列由后台worker慢慢处理。Agent主流程不等待写入完成直接返回响应。这样用户感知不到延迟记忆也在后台慢慢积累。消息队列用Redis的Stream或者RabbitMQ都行我倾向Redis Stream因为已经在用Redis了少引入一个组件。worker的数量根据写入量动态调整高峰期多开几个低峰期缩容。6.3 多租户场景下的记忆隔离如果Agent是面向多个用户或者多个团队的记忆隔离必须做好。我见过一个项目因为没做隔离A用户的记忆被B用户检索到了直接导致数据泄露。隔离方案有两种物理隔离和逻辑隔离。物理隔离是每个租户一套独立的存储实例成本高但最安全。逻辑隔离是所有租户共享存储但在每条记忆上打tenant_id标签检索时强制过滤。大多数场景下逻辑隔离就够了成本低、运维简单。但要注意向量检索的过滤条件要下推到数据库层不能检索完了再在应用层过滤那样既慢又不安全。注意逻辑隔离的tenant_id一定要在MCP server层强制注入不能依赖Agent传参。Agent可能被prompt注入攻击伪造tenant_id。正确的做法是从鉴权token里解析tenant_id和请求参数做交叉验证。6.4 记忆膨胀的治理系统跑久了记忆库会越来越大检索变慢、存储成本上升。这时候需要做记忆治理。我的治理策略分三步。第一步是定期清理过期记忆ttl到期的直接删。第二步是合并低价值记忆把access_count很低、importance也很低的记忆做批量摘要多条合并成一条。第三步是归档冷记忆把超过半年没被访问过的记忆移到冷存储检索时默认不查需要的时候再手动开启。治理任务建议做成定时任务每周跑一次。跑之前先做一次全量备份万一治理逻辑有问题还能回滚。7. 关于hindsight这类项目的一点个人判断我在搭这套记忆系统的过程中最大的体会是记忆层的难点从来不在存储和检索的技术实现而在于“什么该记、什么该忘、什么时候该想起来”这三个判断。技术方案再先进如果写入策略是错的检索出来的东西就是垃圾。反过来哪怕用最简单的SQLite加关键词检索只要写入和检索的时机对了效果也能很好。另一个感受是MCP这类协议的出现确实降低了记忆系统的集成成本但它也带来一个新的问题当记忆读写变得太容易的时候开发者容易滥用什么都往记忆里塞。我的建议是给记忆写入设一个门槛不是所有信息都值得记。一条记忆如果不能在未来的某个场景里产生实际价值那它就不该被写入。最后说一个我一直在用的检验方法把Agent的记忆库导出来随机抽100条人工判断每一条“如果我是Agent这条记忆对我有用吗”。如果有用率低于70%说明写入策略需要调整。这个方法很土但比任何自动化指标都管用。
1. 从“hindsight”这个词说起为什么记忆是Agent落地的最后一公里“hindsight”这个词本身很有意思字面意思是“事后的洞察力”也就是我们常说的“后见之明”。把这个词用在一个Agent项目上指向性其实非常明确它要解决的是Agent在任务执行完之后能不能回头看、能不能记住、能不能从已经发生的事情里提取经验。这恰恰是当前LLM Agent落地过程中最容易被低估、也最要命的一环。我接触过不少Agent项目从简单的工具调用到复杂的多步规划绝大多数团队在早期都会把精力砸在prompt工程、工具编排、模型选型上但真正跑起来之后用户抱怨最多的往往不是“它不够聪明”而是“它记不住我刚才说过什么”“它每次都要重新问一遍”“它明明上次已经处理过类似的问题了”。这就是记忆层缺失带来的体验断层。Agent的working memory如果只依赖上下文窗口那本质上就是一个金鱼记忆系统窗口一满前面的事情全部归零。“hindsight”这个项目标题配合agent memory、LLM、MCP、Docker这几个关键词基本可以勾勒出一个清晰的技术画像这是一个围绕Agent记忆机制构建的系统大概率涉及记忆的存储、检索、压缩和跨会话复用同时通过MCP协议与外部工具或数据源打通并且以Docker作为部署和分发的载体。它要解决的核心问题就是让Agent具备“回头看”的能力把一次性的对话变成可积累的经验资产。这篇文章我会从记忆层的设计逻辑讲起拆解Agent memory到底应该存什么、怎么存、怎么取然后聊MCP在这个体系里扮演什么角色接着给出基于Docker的完整部署和实操路径最后分享几个我在实际搭建过程中踩过的坑和验证过的调优手段。不管你是刚开始接触Agent开发还是已经在做记忆相关模块应该都能从中拿到可以直接用的东西。2. Agent memory到底该存什么三层记忆结构的拆解2.1 为什么不能把所有东西都塞进向量库很多人一提到Agent记忆第一反应就是“上向量数据库”。这个思路不能算错但太粗糙了。我见过不少项目把每一轮对话原封不动地embedding之后丢进向量库结果就是检索出来的内容又长又碎噪声极大模型拿到之后反而被干扰。问题的根源在于记忆不是同质的不同类型的记忆需要不同的存储策略和检索方式。从认知科学的角度类比人的记忆至少分三层感觉记忆、短期记忆、长期记忆。Agent其实也需要类似的分层。我在实际项目中通常会把Agent memory拆成三个层次来设计每一层的存储介质、生命周期、检索方式都不一样。第一层是工作记忆working memory对应当前会话的上下文。这一层就是放在内存或者Redis里的最近N轮对话特点是读写极快、容量有限、会话结束就丢弃。它的作用是维持当前任务的连贯性让Agent知道“我刚才在干什么”。这一层不需要向量检索直接按时间顺序拼接就行。第二层是情景记忆episodic memory对应过去发生过的具体事件和交互。比如“上周三用户让我帮他订了一张去上海的机票”“昨天处理过一个类似的报错”。这一层需要持久化存储通常用结构化数据库加向量索引的混合方案。检索的时候既要能按时间范围过滤也要能按语义相似度召回。第三层是语义记忆semantic memory对应从多次交互中抽象出来的规律和知识。比如“这个用户偏好简洁的回答”“这类报错通常是因为配置项缺失导致的”。这一层是最高级的需要Agent在任务结束后主动做总结和归纳把零散的情景记忆压缩成可复用的知识条目。提示三层记忆不是必须全部实现但如果你只做一层那大概率会遇到“要么记不住要么记太乱”的问题。建议至少把工作记忆和情景记忆分开处理。2.2 记忆条目的结构化设计光分层还不够每一条记忆本身也需要有结构。我见过最粗暴的做法是把整段对话直接存成一条记录检索出来就是一大坨文本。这种做法在Demo阶段能跑通但到了真实场景就会暴露问题检索精度低、token消耗大、无法做细粒度的更新和删除。我的做法是给每条记忆定义一套schema至少包含以下几个字段字段名类型说明memory_idstring唯一标识建议用UUIDsession_idstring所属会话用于按会话聚合memory_typeenumworking / episodic / semanticcontenttext记忆的正文内容建议控制在200字以内summarytext一句话摘要用于快速预览和粗筛embeddingvector内容的向量表示用于语义检索entitiesjson涉及的关键实体如人名、工具名、文件路径timestampdatetime创建时间用于时间衰减和排序access_countint被检索命中的次数用于热度排序importancefloat重要性评分0到1之间ttlint过期时间秒为单位0表示永不过期这套schema看起来字段不少但每一个都有实际用途。比如entities字段在检索的时候可以先做实体匹配做粗筛再用向量做精排效果比纯向量检索好很多。access_count和importance结合起来可以做记忆的淘汰策略避免向量库无限膨胀。ttl则用于处理那些有时效性的记忆比如“用户当前正在处理的临时任务”。2.3 记忆的写入时机与压缩策略记忆写得好不好很大程度上取决于写入时机的选择。我的经验是不要在每一轮对话结束后都写记忆那样会产生大量冗余。比较合理的写入时机有三个第一个是任务完成时。当一个多步任务走到终点把整个任务的执行路径压缩成一条情景记忆。比如“用户要求生成一份销售报告我调用了数据库查询工具、图表生成工具、文档导出工具最终产出了PDF”。这条记忆的价值在于下次遇到类似任务时可以直接复用执行路径。第二个是用户显式反馈时。用户说“记住我喜欢用表格展示数据”或者“以后不要用这种格式”这种信号必须立刻写入语义记忆而且importance要给高分。第三个是会话即将结束时。对整个会话做一次总结提取出关键决策点和未完成事项写入情景记忆。这一步可以用一个小模型来做成本很低但收益很大。压缩策略方面我通常会用“滑动窗口摘要”的组合。工作记忆保留最近10轮原始对话超过的部分用模型压缩成一段摘要摘要再超过一定长度就进一步压缩。这样可以在有限的上下文窗口里保留尽可能多的有效信息。实测下来这种方案比单纯截断或者单纯摘要的效果都要好因为近期细节完整远期信息不丢失。3. MCP在记忆体系里的位置不只是工具调用协议3.1 MCP解决的是记忆的“出入口”问题MCPModel Context Protocol这两年被讨论得很多但大多数讨论都集中在“怎么用MCP接工具”这个层面。其实在Agent memory的语境下MCP的价值远不止工具调用。它本质上解决的是记忆的“出入口”标准化问题。你想Agent的记忆要发挥作用必须能在合适的时机被写入、被检索、被注入到上下文里。如果没有一套标准协议每个记忆后端都要写一套适配代码换一个存储方案就要重写一遍。MCP的出现让这件事变得规范了记忆的读写可以抽象成一组标准的工具接口Agent通过MCP client调用这些接口底层用什么存储、什么检索算法对上层完全透明。我在设计hindsight这类系统的时候通常会把记忆相关的操作封装成几个MCP toolmemory_write写入一条记忆参数包括content、type、importance等memory_search语义检索记忆参数包括query、top_k、type_filtermemory_update更新已有记忆的内容或元数据memory_delete删除指定记忆memory_summarize对指定范围的记忆做摘要压缩这样一来Agent的prompt里只需要描述“什么时候该调用哪个记忆工具”具体的存储实现完全解耦。今天用SQLite加FAISS明天换成PostgreSQL加pgvector上层代码一行不用改。3.2 MCP server的部署形态选择MCP server的部署方式直接影响到整个系统的稳定性和可维护性。常见的部署形态有三种各有适用场景。第一种是本地进程模式MCP server和Agent跑在同一台机器上通过stdio通信。这种模式最简单适合开发和单机部署。缺点是没法多Agent共享记忆而且进程挂了记忆就断了。第二种是独立服务模式MCP server作为一个HTTP服务独立部署Agent通过SSE或者streamable HTTP连接。这种模式适合多Agent协作场景记忆可以集中管理。缺点是需要处理网络通信的稳定性和鉴权问题。第三种是容器化部署模式把MCP server打包成Docker镜像通过Docker Compose或者Kubernetes编排。这种模式结合了前两种的优点既有独立服务的可扩展性又有容器化的环境一致性。对于hindsight这种需要持久化存储的项目我强烈推荐这种模式。注意MCP server如果走HTTP模式一定要加鉴权。我见过不少项目把MCP server直接暴露在公网上没有任何认证等于把Agent的记忆库完全敞开。至少加一个Bearer Token生产环境建议上mTLS。3.3 记忆检索的MCP工具设计细节memory_search这个工具的设计有很多讲究直接影响到检索质量和token消耗。我通常会给它设计这么几个参数{ query: 用户上次提到的报告格式偏好, top_k: 5, type_filter: [semantic, episodic], time_range: { start: 2024-01-01T00:00:00Z, end: 2024-12-31T23:59:59Z }, min_importance: 0.3, include_content: true, max_content_length: 500 }这里有几个细节值得展开说。top_k不要设太大3到5条通常就够了多了反而引入噪声。type_filter让Agent可以指定只搜某一类记忆比如做规划的时候只搜语义记忆做具体任务的时候搜情景记忆。time_range用于处理时效性强的查询。min_importance可以过滤掉低价值的记忆。include_content和max_content_length控制返回内容的详细程度有时候Agent只需要知道“有这么一条记忆”不需要全文。返回结果的结构也要设计好我一般会返回一个数组每条包含memory_id、summary、content可选、relevance_score、timestamp。Agent拿到之后可以根据relevance_score决定要不要深入读取某条记忆的全文。4. 用Docker把整套记忆系统跑起来4.1 容器编排的整体架构hindsight这类项目的部署我建议用Docker Compose来编排因为涉及的组件比较多手动管理容易乱。一个典型的架构包含以下几个容器agent-coreAgent的主进程负责对话管理和工具调用mcp-memory-server记忆服务的MCP server对外暴露记忆读写接口vector-db向量数据库比如Qdrant或者Milvus负责语义检索relational-db关系型数据库比如PostgreSQL负责结构化记忆的存储cacheRedis负责工作记忆和热点记忆的缓存embedding-service向量化服务可以用TEI或者自己封装一个这几个容器通过Docker网络互联只有agent-core和mcp-memory-server需要对外暴露端口数据库和缓存只在内部网络通信。这样既保证了安全性也方便做水平扩展。4.2 Docker Compose配置的关键细节下面是一份我实际用过的docker-compose.yml骨架重点看几个容易出问题的地方version: 3.9 services: mcp-memory-server: build: context: ./mcp-memory-server dockerfile: Dockerfile ports: - 8080:8080 environment: - VECTOR_DB_URLhttp://vector-db:6333 - RELATIONAL_DB_URLpostgresql://user:passrelational-db:5432/memory - REDIS_URLredis://cache:6379/0 - EMBEDDING_SERVICE_URLhttp://embedding-service:8081 - MCP_AUTH_TOKEN${MCP_AUTH_TOKEN} depends_on: vector-db: condition: service_healthy relational-db: condition: service_healthy cache: condition: service_started networks: - memory-net restart: unless-stopped vector-db: image: qdrant/qdrant:latest volumes: - qdrant-data:/qdrant/storage healthcheck: test: [CMD, curl, -f, http://localhost:6333/healthz] interval: 10s timeout: 5s retries: 5 networks: - memory-net relational-db: image: postgres:16-alpine environment: - POSTGRES_USERuser - POSTGRES_PASSWORDpass - POSTGRES_DBmemory volumes: - pg-data:/var/lib/postgresql/data healthcheck: test: [CMD-SHELL, pg_isready -U user -d memory] interval: 10s timeout: 5s retries: 5 networks: - memory-net cache: image: redis:7-alpine command: redis-server --appendonly yes --maxmemory 512mb --maxmemory-policy allkeys-lru volumes: - redis-data:/data networks: - memory-net embedding-service: image: ghcr.io/huggingface/text-embeddings-inference:latest command: --model-id BAAI/bge-small-zh-v1.5 --port 8081 volumes: - embedding-cache:/data networks: - memory-net volumes: qdrant-data: pg-data: redis-data: embedding-cache: networks: memory-net: driver: bridge这份配置里有几个点是我踩过坑之后才加上的。depends_on配合condition: service_healthy非常关键否则mcp-memory-server可能在数据库还没就绪的时候就启动导致连接失败。Redis的maxmemory-policy设成allkeys-lru避免缓存把内存吃满。embedding-service的模型选择要考虑中文场景bge-small-zh是个不错的平衡点速度快、效果够用。4.3 数据持久化与备份策略记忆数据是Agent的核心资产丢了就没了所以持久化必须做扎实。Docker的volume机制本身能保证容器重启后数据不丢但这还不够还需要考虑备份和迁移。我的做法是三层保护。第一层是数据库自身的持久化机制PostgreSQL开WAL归档Qdrant开snapshot。第二层是定期导出用一个cron容器每天把PostgreSQL的memory表导出成SQL文件把Qdrant的collection导出成snapshot文件存到独立的备份volume里。第三层是异地备份把备份文件同步到对象存储或者另一台机器上。恢复的时候也有讲究。PostgreSQL直接restore SQL文件就行但Qdrant的snapshot恢复需要先创建同名collection再导入。我建议把恢复步骤写成一个脚本定期演练一遍免得到真出事的时候手忙脚乱。提示Qdrant的snapshot文件比较大如果记忆量在百万条以上单次snapshot可能好几个G。建议做增量备份或者用Qdrant的collection alias机制做蓝绿切换。5. 记忆检索质量的调优从能用到好用5.1 混合检索比纯向量检索靠谱得多纯向量检索在记忆场景下有个致命问题它对精确匹配不敏感。比如用户问“我上次让你查的那个订单号是多少”向量检索可能召回一堆语义相似但订单号不同的记忆。这时候就需要引入关键词检索做补充。我的方案是混合检索向量召回和BM25召回各取top 20然后用RRFReciprocal Rank Fusion做融合排序。RRF的公式很简单对每个文档把它在各个召回列表里的排名取倒数再求和。这个方法的优点是无需调参对不同类型的召回结果都能公平融合。def rrf_fusion(vector_results, bm25_results, k60): scores {} for rank, doc_id in enumerate(vector_results): scores[doc_id] scores.get(doc_id, 0) 1.0 / (k rank 1) for rank, doc_id in enumerate(bm25_results): scores[doc_id] scores.get(doc_id, 0) 1.0 / (k rank 1) return sorted(scores.items(), keylambda x: x[1], reverseTrue)实测下来混合检索在记忆场景的召回准确率比纯向量检索能高出15到20个百分点尤其是涉及具体数字、文件名、工具名的查询提升非常明显。5.2 时间衰减与重要性加权记忆的价值不是恒定的新记忆通常比旧记忆更相关高重要性的记忆应该优先被召回。所以在排序的时候除了相关性分数还要叠加时间衰减和重要性权重。时间衰减我用的是指数衰减公式是score * exp(-lambda * days_ago)lambda取0.01左右意味着大约70天后记忆的权重降到一半。重要性权重直接乘上去就行importance在0到1之间。最终的排序分数是relevance * time_decay * (0.5 0.5 * importance)这样既考虑了语义相关性也考虑了时效性和重要性。这个公式里的系数不是拍脑袋定的我做过一轮A/B测试用不同的系数组合跑了一周的线上流量最后选定了这组。当然不同场景可能需要调整比如客服场景可能更看重时效性知识库场景可能更看重重要性。5.3 记忆去重与冲突消解记忆写多了必然会出现重复和冲突。比如用户今天说“我喜欢用Markdown格式”明天说“以后都用纯文本吧”这两条语义记忆是冲突的。如果不处理Agent检索到两条矛盾的信息行为就会不稳定。我的处理策略是写入新记忆之前先做一次相似度检索如果发现相似度超过0.9的已有记忆就走更新流程而不是新增。更新的时候保留历史版本但把旧版本标记为superseded检索时默认只返回最新版本。对于明确冲突的情况比如上面那个格式偏好的例子用时间戳新的覆盖旧的同时在记忆里记录一条“偏好变更”的元数据。去重这块还有个细节不同来源的记忆可能有不同的可信度。用户显式说的可信度最高Agent自己总结的可信度次之从外部文档提取的可信度再次。我通常会给每条记忆加一个source字段检索排序的时候根据source做微调。6. 实际跑起来之后才会遇到的几个坑6.1 上下文注入的token预算控制记忆检索出来之后要注入到Agent的上下文里但上下文窗口是有限的。我见过不少项目检索了20条记忆每条500字一下子就把窗口占满了留给当前对话的空间所剩无几。我的做法是给记忆注入设一个硬预算比如总token不超过2000。在这个预算内按相关性排序依次注入每条记忆的内容长度动态调整。高相关性的记忆给全文中等相关性的给摘要低相关性的只给标题。这样可以在有限预算内最大化信息密度。还有一个技巧是把记忆注入的位置放在system prompt之后、用户消息之前并且用明确的分隔符标记出来。这样模型能清楚区分哪些是历史记忆、哪些是当前输入减少混淆。6.2 记忆写入的异步化记忆写入如果做成同步的会显著增加每轮对话的延迟。尤其是做摘要压缩的时候要调用模型可能好几秒。用户等不起。我的方案是把记忆写入做成异步任务。对话结束后把需要写入的记忆丢进一个消息队列由后台worker慢慢处理。Agent主流程不等待写入完成直接返回响应。这样用户感知不到延迟记忆也在后台慢慢积累。消息队列用Redis的Stream或者RabbitMQ都行我倾向Redis Stream因为已经在用Redis了少引入一个组件。worker的数量根据写入量动态调整高峰期多开几个低峰期缩容。6.3 多租户场景下的记忆隔离如果Agent是面向多个用户或者多个团队的记忆隔离必须做好。我见过一个项目因为没做隔离A用户的记忆被B用户检索到了直接导致数据泄露。隔离方案有两种物理隔离和逻辑隔离。物理隔离是每个租户一套独立的存储实例成本高但最安全。逻辑隔离是所有租户共享存储但在每条记忆上打tenant_id标签检索时强制过滤。大多数场景下逻辑隔离就够了成本低、运维简单。但要注意向量检索的过滤条件要下推到数据库层不能检索完了再在应用层过滤那样既慢又不安全。注意逻辑隔离的tenant_id一定要在MCP server层强制注入不能依赖Agent传参。Agent可能被prompt注入攻击伪造tenant_id。正确的做法是从鉴权token里解析tenant_id和请求参数做交叉验证。6.4 记忆膨胀的治理系统跑久了记忆库会越来越大检索变慢、存储成本上升。这时候需要做记忆治理。我的治理策略分三步。第一步是定期清理过期记忆ttl到期的直接删。第二步是合并低价值记忆把access_count很低、importance也很低的记忆做批量摘要多条合并成一条。第三步是归档冷记忆把超过半年没被访问过的记忆移到冷存储检索时默认不查需要的时候再手动开启。治理任务建议做成定时任务每周跑一次。跑之前先做一次全量备份万一治理逻辑有问题还能回滚。7. 关于hindsight这类项目的一点个人判断我在搭这套记忆系统的过程中最大的体会是记忆层的难点从来不在存储和检索的技术实现而在于“什么该记、什么该忘、什么时候该想起来”这三个判断。技术方案再先进如果写入策略是错的检索出来的东西就是垃圾。反过来哪怕用最简单的SQLite加关键词检索只要写入和检索的时机对了效果也能很好。另一个感受是MCP这类协议的出现确实降低了记忆系统的集成成本但它也带来一个新的问题当记忆读写变得太容易的时候开发者容易滥用什么都往记忆里塞。我的建议是给记忆写入设一个门槛不是所有信息都值得记。一条记忆如果不能在未来的某个场景里产生实际价值那它就不该被写入。最后说一个我一直在用的检验方法把Agent的记忆库导出来随机抽100条人工判断每一条“如果我是Agent这条记忆对我有用吗”。如果有用率低于70%说明写入策略需要调整。这个方法很土但比任何自动化指标都管用。
