基于MCP与Docker构建LLM Agent记忆系统实战
发布时间:2026/10/1 3:56:25来源:尧图网络
1. 从“hindsight”说起为什么我们需要给Agent装上“后视镜”“hindsight”这个词本身很有意思字面意思是“事后的洞察力”也就是我们常说的“后见之明”。放在LLM Agent的语境里它指向一个非常具体且棘手的问题Agent的记忆系统到底该怎么设计才能让它在后续任务中真正“记得住、找得回、用得上”之前发生过的事情。我接触过不少做Agent落地的团队大家一开始都信心满满觉得接个大模型API、写个ReAct循环、挂几个工具Agent就能跑起来了。结果一上真实场景就露馅——用户上周提过的偏好这周再问它完全不记得同一个任务里前面确认过的参数后面调用工具时又搞错了多轮对话稍微长一点上下文窗口就开始溢出要么截断要么报错。这些问题的根源几乎都指向同一个东西Agent的存储与记忆机制没有设计好。这个项目标题“hindsight”加上agent memory、LLM、MCP、Docker这几个关键词基本可以判断出它要解决的核心问题域如何为基于LLM的Agent构建一套可靠的记忆存储与检索系统并且通过MCP协议进行标准化接入最终用Docker完成环境封装和部署。这不是一个纯理论探讨而是一个有明确工程落地导向的项目。适合谁来参考这篇内容三类人最对口一是正在做Agent应用开发、被记忆问题折磨过的工程师二是对MCP协议感兴趣、想搞清楚它到底怎么落地的人三是需要把LLM能力集成到现有系统里、正在做技术选型的架构师。如果你只是刚听说LLM是什么这篇可能门槛偏高但我会尽量把关键概念用生活化的方式讲清楚。接下来我会从整体设计思路、核心细节拆解、实操部署流程、常见问题排查四个维度把这个项目涉及的技术点完整展开。所有内容基于我在实际项目中积累的经验和对MCP生态的观察涉及具体参数和配置的地方会给出可直接参考的方案。2. 整体设计思路Agent记忆系统的分层架构与MCP接入逻辑2.1 为什么Agent记忆不能只靠上下文窗口很多人第一次做Agent时的直觉是大模型不是有上下文窗口吗我把历史对话都塞进去不就行了这个思路在小规模场景下能跑通但一旦进入生产环境就会撞上三堵墙。第一堵墙是成本。上下文窗口里的每一个token都是要花钱的你把几十轮对话历史全部带上每次请求的token消耗会线性增长。假设一轮对话平均500 token50轮就是25000 token按主流模型的定价单次请求成本可能就上去了。而且很多信息是冗余的用户三天前问的天气跟今天的任务毫无关系但你还是得把它带上。第二堵墙是注意力稀释。上下文窗口不是越大越好当里面塞了大量无关信息时模型对关键信息的注意力会被稀释。这就像你在一个嘈杂的房间里找人说话周围噪音越大你越难听清对方在说什么。学术界已经有大量实验证明长上下文中的“中间遗忘”现象是普遍存在的。第三堵墙是持久化需求。上下文窗口是会话级的会话结束就没了。但Agent需要跨会话记住用户的偏好、之前任务的结论、已经确认过的事实。这些信息必须落到外部存储里不能只活在内存中。所以“hindsight”这个项目的核心价值就出来了它要构建一套独立于上下文窗口的Agent记忆层让Agent能够主动地存储、检索、更新记忆而不是被动地依赖上下文窗口的容量。2.2 记忆系统的三层结构Working Memory、Episodic Memory、Semantic Memory在设计Agent记忆系统时我习惯把它分成三层这个分类方式借鉴了认知科学里对人类记忆的研究但在工程上做了简化。Working Memory工作记忆是最短期的对应的是当前任务执行过程中的临时状态。比如Agent正在处理一个多步任务第一步的输出结果需要传给第二步用这个中间结果就放在Working Memory里。它的特点是生命周期短、读写频繁、容量小。工程上通常用内存数据结构比如Python的dict或者Redis来实现不需要持久化。Episodic Memory情景记忆记录的是“发生了什么”。每一次对话、每一个任务的执行过程、每一个重要的决策节点都可以作为一条情景记忆存下来。它的特点是按时间线组织、数据量大、需要持久化。工程上通常用关系型数据库或者文档数据库来存每条记录包含时间戳、会话ID、内容摘要、嵌入向量等字段。Semantic Memory语义记忆存储的是从情景记忆中提炼出来的“知识”。比如从多次对话中总结出“这个用户偏好简洁的回答风格”从多个任务中归纳出“调用某个API时总是需要先做认证”。它的特点是结构化、去重、可复用。工程上通常用向量数据库来存支持语义检索。这三层之间的关系是Working Memory支撑当前任务Episodic Memory记录历史Semantic Memory沉淀知识。当Agent需要回忆时先从Semantic Memory里检索相关知识再根据需要回溯到Episodic Memory里查具体细节。2.3 MCP协议在记忆系统中的角色定位MCPModel Context Protocol是Anthropic推出的一个开放协议目的是标准化LLM与外部工具、数据源之间的交互方式。你可以把它理解成“AI世界的USB接口”——不管你是哪种模型、哪种工具只要都遵循MCP协议就能即插即用。在“hindsight”这个项目里MCP的作用是把记忆系统封装成一个标准的MCP Server让任何支持MCP协议的Agent都能接入。这样做的好处非常明显解耦记忆系统的实现和Agent的实现完全分离Agent不需要知道记忆存在哪里、怎么检索只需要按照MCP协议发请求就行。复用同一个记忆Server可以被多个Agent共用比如一个团队里所有Agent共享同一套用户偏好记忆。可替换如果以后想换一种存储后端只要保持MCP接口不变Agent侧完全不用改。MCP协议的核心交互模式是Client也就是Agent向Server发送请求Server返回结果。请求和响应都遵循JSON-RPC 2.0格式。对于记忆系统来说最常用的几个操作是store_memory存储记忆、retrieve_memory检索记忆、update_memory更新记忆、delete_memory删除记忆。2.4 Docker在部署中的价值环境一致性与快速交付Docker在这个项目里的角色很明确把记忆系统及其依赖打包成一个可移植的容器镜像确保在任何环境下都能一致运行。我见过太多团队在部署阶段踩坑开发机上跑得好好的一到测试环境就报错原因是Python版本不一致、依赖库版本冲突、系统库缺失。Docker通过镜像层的方式把应用和它的运行环境一起打包从根本上解决了这个问题。具体到这个项目Docker化的对象包括MCP Server进程、向量数据库比如Chroma或Qdrant、关系型数据库比如PostgreSQL或SQLite、以及可能的缓存层比如Redis。通过docker-compose编排一条命令就能把整套记忆系统拉起来。注意如果你在Windows上使用Docker Desktop需要确保开启了WSL2后端否则在挂载卷和网络配置上会遇到不少麻烦。这个后面在实操部分会详细说。3. 核心细节解析记忆存储、检索与MCP接口设计3.1 记忆的存储格式从原始文本到结构化向量记忆存什么、怎么存直接决定了后面能不能检索得到、检索得准。我见过一些实现直接把原始对话文本整段塞进数据库检索时用关键词匹配效果很差。正确的做法是把记忆拆解成结构化的条目每条记忆包含多个字段。一条典型的记忆记录至少包含以下字段字段名类型说明idstring唯一标识符通常用UUIDcontentstring记忆的文本内容经过摘要或提炼embeddingvector内容的向量表示用于语义检索memory_typeenumworking / episodic / semanticsession_idstring所属会话ID用于隔离不同会话的记忆user_idstring所属用户ID用于多用户场景created_attimestamp创建时间updated_attimestamp最后更新时间access_countint被检索次数用于热度排序importancefloat重要性评分0到1之间metadatajson扩展字段存任意附加信息这里有几个设计决策值得展开说。为什么要有importance字段因为不是所有记忆都同等重要。用户说“今天天气不错”和用户说“我对花生过敏”这两条记忆的价值天差地别。importance字段允许在存储时给记忆打分检索时可以按重要性加权排序。打分的逻辑可以用规则比如包含特定关键词的加分也可以用LLM来判断让模型评估这条信息对未来交互的价值。为什么要有access_count这是借鉴了缓存淘汰算法的思路。被频繁访问的记忆说明它确实有用应该优先保留长期不被访问的记忆可以考虑归档或删除。这在记忆量大了之后对控制存储成本和检索效率很关键。embedding怎么生成通常用嵌入模型比如text-embedding-3-small、bge-large-zh等把content字段转成向量。向量的维度取决于模型常见的有768维、1024维、1536维。存储时用向量数据库检索时用余弦相似度或内积来计算。3.2 检索策略语义检索关键词检索时间衰减的混合排序检索是记忆系统里最核心也最难做好的部分。单纯用向量相似度检索有几个明显问题一是对精确匹配不敏感比如用户问“我的订单号是多少”向量检索可能返回一堆语义相关但没用的内容二是没有考虑时间因素三个月前的记忆和昨天的记忆权重应该不一样三是可能返回大量冗余结果。我的做法是混合检索多因子排序具体分三步第一步并行执行语义检索和关键词检索。语义检索用向量数据库的ANN近似最近邻查询返回Top-K个语义最相近的记忆。关键词检索用全文索引比如PostgreSQL的tsvector或Elasticsearch返回包含查询词的记忆。两路结果合并去重。第二步多因子加权排序。对每条候选记忆计算一个综合得分公式大致是score w1 * semantic_similarity w2 * keyword_match_score w3 * importance w4 * recency_score w5 * access_frequency其中recency_score通常用指数衰减函数计算比如exp(-lambda * hours_since_created)lambda控制衰减速度。w1到w5是权重需要根据实际场景调参。我的经验是语义相似度权重最高0.4左右重要性和时间衰减各占0.2其余分摊。第三步去重和截断。对得分最高的若干条记忆检查内容是否高度重复重复的只保留得分最高的那条。最后返回Top-N条通常N5到10给Agent。实操心得检索返回的记忆条数不是越多越好。我实测下来返回5条左右效果最好太多会稀释Agent的注意力太少可能漏掉关键信息。另外检索结果里最好带上记忆的时间戳和类型让Agent自己判断这条记忆的时效性和可信度。3.3 MCP Server的接口设计四个核心Tool的定义MCP Server对外暴露的能力通过Tool来定义。对于记忆系统我建议至少定义以下四个Toolstore_memory存储一条新记忆。入参包括content必填、memory_type必填、importance可选默认0.5、metadata可选。出参返回记忆的id和存储状态。retrieve_memory检索记忆。入参包括query必填、top_k可选默认5、memory_type_filter可选、time_range可选。出参返回记忆列表每条包含content、score、created_at等字段。update_memory更新已有记忆。入参包括id必填、content可选、importance可选、metadata可选。出参返回更新状态。delete_memory删除记忆。入参包括id必填或过滤条件。出参返回删除数量。这四个Tool的定义要写在MCP Server的manifest里ClientAgent启动时会拉取这个manifest知道Server支持哪些操作、每个操作需要什么参数。这就是MCP协议的价值——标准化不需要每个Agent都去适配不同的记忆系统接口。3.4 记忆的写入时机什么时候该存什么时候不该存这是很多实现容易忽略的问题。如果Agent每说一句话都往记忆里存很快数据库就会爆炸而且大量噪音会严重影响检索质量。我的经验是按事件触发写入而不是按消息触发。具体来说以下时机应该触发记忆写入用户明确表达了偏好、约束或重要事实“我住在北京”、“我不吃辣”、“以后回答请用中文”一个任务完成需要记录任务结论和关键步骤Agent做出了一个需要后续保持一致性的决策对话轮次达到一定数量比如每10轮做一次摘要存储用户主动要求“记住这个”以下情况不应该写入寒暄和闲聊“你好”、“谢谢”临时性的中间状态这些放Working Memory就行重复信息写入前先做相似度检查如果已有高度相似的记忆更新而不是新增写入时机的判断可以交给LLM来做——在Agent的prompt里加一段指令让它判断当前对话内容是否值得存入长期记忆。也可以用一个轻量级的分类模型来做成本更低。4. 实操部署从零搭建一套基于MCP的Agent记忆系统4.1 环境准备Docker安装与基础依赖先说Docker的安装。Windows用户直接去Docker官网下载Docker Desktop安装包双击运行。安装过程中会提示是否启用WSL2建议勾选。安装完成后重启电脑打开Docker Desktop等右下角鲸鱼图标变成绿色就说明启动成功了。Linux用户以Ubuntu为例用命令行安装# 更新包索引 sudo apt-get update # 安装必要依赖 sudo apt-get install -y ca-certificates curl gnupg # 添加Docker官方GPG密钥 sudo install -m 0755 -d /etc/apt/keyrings curl -fsSL https://download.docker.com/linux/ubuntu/gpg | sudo gpg --dearmor -o /etc/apt/keyrings/docker.gpg sudo chmod ar /etc/apt/keyrings/docker.gpg # 添加Docker仓库 echo deb [arch$(dpkg --print-architecture) signed-by/etc/apt/keyrings/docker.gpg] https://download.docker.com/linux/ubuntu $(. /etc/os-release echo $VERSION_CODENAME) stable | sudo tee /etc/apt/sources.list.d/docker.list /dev/null # 安装Docker Engine sudo apt-get update sudo apt-get install -y docker-ce docker-ce-cli containerd.io docker-buildx-plugin docker-compose-plugin # 验证安装 sudo docker run hello-world安装完成后建议把当前用户加入docker组这样不用每次敲sudosudo usermod -aG docker $USER newgrp docker注意Windows上如果Docker Desktop启动时报“Virtualization support not detected”说明BIOS里的虚拟化技术没有开启。重启电脑进BIOS找到Intel VT-x或AMD-V选项设为Enabled。另外Windows家庭版需要先安装WSL2用wsl --install命令一键搞定。4.2 用docker-compose编排记忆系统全套服务我建议用docker-compose来管理整个记忆系统的服务栈。下面是一个可直接参考的compose文件version: 3.8 services: # 向量数据库用于语义检索 qdrant: image: qdrant/qdrant:latest ports: - 6333:6333 - 6334:6334 volumes: - qdrant_data:/qdrant/storage restart: unless-stopped # 关系型数据库用于存储结构化记忆元数据 postgres: image: postgres:16-alpine environment: POSTGRES_USER: memory_user POSTGRES_PASSWORD: memory_pass_2024 POSTGRES_DB: agent_memory ports: - 5432:5432 volumes: - pg_data:/var/lib/postgresql/data restart: unless-stopped # 缓存层用于Working Memory redis: image: redis:7-alpine ports: - 6379:6379 volumes: - redis_data:/data restart: unless-stopped # MCP Server记忆系统的核心服务 memory-mcp-server: build: ./mcp-server ports: - 8080:8080 environment: QDRANT_URL: http://qdrant:6333 POSTGRES_URL: postgresql://memory_user:memory_pass_2024postgres:5432/agent_memory REDIS_URL: redis://redis:6379/0 EMBEDDING_MODEL: text-embedding-3-small EMBEDDING_DIM: 1536 depends_on: - qdrant - postgres - redis restart: unless-stopped volumes: qdrant_data: pg_data: redis_data:这个编排文件定义了四个服务Qdrant做向量检索PostgreSQL存结构化数据Redis做缓存memory-mcp-server是核心的MCP服务。它们通过Docker内部网络互相通信不需要暴露所有端口到宿主机。启动命令很简单docker-compose up -d第一次运行会拉取镜像、构建MCP Server可能需要几分钟。启动完成后用docker-compose ps检查各服务状态确保都是Up。4.3 MCP Server的核心实现存储与检索的代码骨架MCP Server的实现语言可以选Python或TypeScript我这里用Python举例因为它生态最成熟。核心代码结构如下import uuid import time from datetime import datetime from typing import Optional from mcp.server import Server, NotificationOptions from mcp.server.models import InitializationOptions import mcp.server.stdio import mcp.types as types # 初始化MCP Server server Server(hindsight-memory) server.list_tools() async def handle_list_tools() - list[types.Tool]: 定义Server支持的所有Tool return [ types.Tool( namestore_memory, description存储一条新的Agent记忆, inputSchema{ type: object, properties: { content: {type: string, description: 记忆内容}, memory_type: { type: string, enum: [working, episodic, semantic], description: 记忆类型 }, importance: { type: number, minimum: 0, maximum: 1, description: 重要性评分 }, metadata: {type: object, description: 扩展元数据} }, required: [content, memory_type] } ), types.Tool( nameretrieve_memory, description根据查询检索相关记忆, inputSchema{ type: object, properties: { query: {type: string, description: 检索查询}, top_k: {type: integer, default: 5}, memory_type_filter: {type: string}, time_range_hours: {type: integer} }, required: [query] } ), # update_memory 和 delete_memory 的定义类似此处省略 ] server.call_tool() async def handle_call_tool( name: str, arguments: dict ) - list[types.TextContent]: 处理Tool调用 if name store_memory: memory_id str(uuid.uuid4()) content arguments[content] memory_type arguments[memory_type] importance arguments.get(importance, 0.5) # 生成嵌入向量 embedding await generate_embedding(content) # 存入向量数据库 await qdrant_client.upsert( collection_nameagent_memories, points[{ id: memory_id, vector: embedding, payload: { content: content, memory_type: memory_type, importance: importance, created_at: datetime.utcnow().isoformat(), access_count: 0 } }] ) # 存入关系型数据库 await pg_pool.execute( INSERT INTO memories (id, content, memory_type, importance, created_at) VALUES ($1, $2, $3, $4, $5), memory_id, content, memory_type, importance, datetime.utcnow() ) return [types.TextContent( typetext, textfMemory stored successfully. ID: {memory_id} )] elif name retrieve_memory: query arguments[query] top_k arguments.get(top_k, 5) # 生成查询向量 query_embedding await generate_embedding(query) # 向量检索 vector_results await qdrant_client.search( collection_nameagent_memories, query_vectorquery_embedding, limittop_k * 2 # 多取一些用于后续重排 ) # 关键词检索从PostgreSQL keyword_results await pg_pool.fetch( SELECT id, content, importance, created_at FROM memories WHERE content ILIKE $1 LIMIT $2, f%{query}%, top_k * 2 ) # 合并、去重、重排 merged merge_and_rerank(vector_results, keyword_results, top_k) # 更新访问计数 for mem in merged: await pg_pool.execute( UPDATE memories SET access_count access_count 1 WHERE id $1, mem[id] ) return [types.TextContent( typetext, textformat_memories(merged) )]这段代码展示了MCP Server的核心骨架。实际项目中还需要处理错误、连接池管理、嵌入模型的调用封装等细节但整体结构就是这样。4.4 与Agent侧对接配置MCP ClientAgent侧要接入这个记忆Server需要在Agent的配置里声明MCP Server的地址。以Claude Desktop为例配置文件在~/Library/Application Support/Claude/claude_desktop_config.jsonMac或%APPDATA%\Claude\claude_desktop_config.jsonWindows{ mcpServers: { hindsight-memory: { command: docker, args: [ exec, -i, memory-mcp-server, python, -m, hindsight.server ] } } }如果MCP Server是以HTTP方式暴露的配置会更简单{ mcpServers: { hindsight-memory: { url: http://localhost:8080/mcp } } }配置完成后重启Agent它就能自动发现记忆Server提供的Tool并在需要时调用。你可以在Agent的对话里测试“记住我喜欢喝美式咖啡”然后开一个新会话问“我喜欢喝什么”看它能不能从记忆里检索出来。4.5 参数调优嵌入模型选择与检索阈值设定嵌入模型的选择直接影响检索质量。我实测过几个主流选项模型维度中文效果成本适用场景text-embedding-3-small1536良好低通用场景性价比高text-embedding-3-large3072优秀中对精度要求高的场景bge-large-zh-v1.51024优秀自部署免费中文为主可本地部署bge-m31024优秀自部署免费多语言混合场景如果预算有限且以中文为主bge-large-zh-v1.5是很好的选择可以本地部署不产生API调用费用。如果追求开箱即用text-embedding-3-small够用了。检索阈值方面余弦相似度的阈值建议设在0.7左右。低于这个值的结果通常相关性不够返回给Agent反而添乱。但这个阈值不是固定的需要根据实际数据分布来调。我的做法是先用一批测试查询跑一遍看相似度得分的分布然后取一个能过滤掉明显无关结果的值。实操心得嵌入模型一旦选定整个记忆库的向量维度就固定了。如果后期想换模型需要重新生成所有记忆的嵌入向量。所以选型时最好留一点前瞻性别选太冷门的模型。5. 常见问题与排查技巧实录5.1 Docker相关容器启动失败与网络不通问题一Docker Desktop启动报“Virtualization support not detected”。这是Windows上最常见的问题。原因通常是BIOS里没有开启虚拟化。重启电脑进入BIOS设置通常是开机按F2、Del或F12找到“Intel Virtualization Technology”或“SVM Mode”设为Enabled。保存退出后重新启动Docker Desktop即可。如果BIOS里已经开了但还是报错检查是否安装了WSL2。在PowerShell里运行wsl --status如果显示未安装运行wsl --install然后重启。问题二容器之间网络不通。在docker-compose里服务之间通过服务名互相访问比如MCP Server连Qdrant用的是http://qdrant:6333而不是http://localhost:6333。如果你在代码里写了localhost容器内部会解析成容器自己的回环地址当然连不上。排查方法进入MCP Server容器用curl http://qdrant:6333/health测试连通性。如果不通检查两个服务是否在同一个docker-compose网络里默认在同一个compose文件里的服务就在同一网络。问题三数据卷挂载后权限报错。Linux上常见容器内的进程用户和宿主机文件所有者不一致导致。解决方法是在compose文件里指定用户services: postgres: user: 1000:1000或者用chown把宿主机目录的所有者改成容器内用户对应的UID。5.2 记忆检索相关检索结果不准确或返回空问题明明存了记忆检索时却返回空。先检查嵌入向量是否正常生成。在Qdrant的管理界面http://localhost:6333/dashboard里查看collection的points数量如果为0说明存储环节就出了问题。如果points数量正常但检索为空检查查询向量的维度和存储的维度是否一致——维度不匹配时Qdrant会直接报错而不是返回空但有些客户端会吞掉错误。另一个常见原因是collection名称写错了。Qdrant里collection名称是大小写敏感的agent_memories和Agent_Memories是两个不同的collection。问题检索结果相关性差。先看相似度得分。如果Top结果的得分都在0.5以下说明嵌入模型可能不适合你的数据。中文场景下用英文为主的嵌入模型效果会打折扣换成bge-large-zh会明显改善。如果得分不低但结果仍然不相关检查记忆的content字段是否太长。一条记忆如果包含几百字嵌入向量会丢失细节检索时匹配的是整体语义而不是关键信息。建议单条记忆控制在200字以内超长的拆成多条。5.3 MCP协议相关Tool调用失败与超时问题Agent调用store_memory时报“Tool not found”。检查MCP Server的manifest是否正确注册了Tool。在Server启动日志里应该能看到注册的Tool列表。如果Server端正常检查Client端的配置——有些Agent需要手动刷新MCP Server列表或者重启后才能识别新添加的Server。问题retrieve_memory调用超时。检索涉及嵌入生成和向量查询两个步骤任何一个慢了都会导致超时。嵌入生成如果是调API网络延迟可能达到几百毫秒向量查询如果数据量大且没有建索引也可能很慢。优化方向一是给Qdrant的collection建HNSW索引二是把嵌入生成改成批量异步三是设置合理的超时时间建议10秒并在超时后返回降级结果比如只返回关键词检索的结果。5.4 常见问题速查表现象可能原因排查步骤解决方案Docker启动失败虚拟化未开启检查BIOS设置开启VT-x/AMD-V容器间网络不通用了localhost进容器curl测试改用服务名数据卷权限错误UID不匹配查看容器内用户UID指定user或chown检索返回空嵌入未生成查Qdrant points数检查嵌入API调用检索相关性差模型不适配看相似度得分分布换中文嵌入模型Tool调用超时嵌入或查询慢看各步骤耗时建索引异步降级记忆重复存储未做去重查content相似度写入前先检索5.5 几个我踩过的坑坑一忘了给向量collection建索引。Qdrant默认不建HNSW索引数据量小的时候感觉不出来一旦超过几千条检索延迟从毫秒级飙升到秒级。建索引的命令是await qdrant_client.update_collection( collection_nameagent_memories, optimizer_config{indexing_threshold: 1000} )坑二记忆的importance字段一直用默认值。结果就是检索时所有记忆权重一样重要的和不重要的混在一起。后来加了一个简单的规则包含“记住”、“重要”、“以后”等关键词的记忆importance自动设为0.8以上。坑三没有做会话隔离。多个用户的记忆混在一起A用户问“我的偏好是什么”检索出了B用户的偏好。解决方法是所有查询都带上user_id过滤条件这个字段在存储时就必须写入。坑四Docker镜像没有固定版本。用了latest标签结果某次重新构建时拉到了不兼容的新版本整个系统跑不起来。后来所有镜像都固定到具体版本号比如qdrant/qdrant:v1.7.4。6. 记忆系统的扩展方向与个人经验这套基于MCP的记忆系统跑通之后有几个方向可以继续扩展。一是记忆的自动摘要与压缩——当Episodic Memory积累到一定量时用LLM定期做摘要把多条相关记忆合并成一条Semantic Memory减少存储量同时提升检索效率。二是记忆的遗忘机制——不是所有记忆都需要永久保留可以设置TTL生存时间过期的记忆自动归档或删除。三是多Agent共享记忆——多个Agent接入同一个记忆Server通过user_id或team_id做隔离实现团队级的知识沉淀。我个人在实际操作中的体会是Agent记忆系统的难点不在于存储和检索的技术实现而在于判断什么值得记、什么时候该记、检索出来怎么用。这三个判断都需要结合具体业务场景来调没有一劳永逸的通用方案。我的建议是先把基础框架搭起来然后拿真实场景的数据跑一段时间观察哪些记忆被频繁检索、哪些从来没被用过根据这些数据来优化写入策略和检索排序。另外一个小技巧在Agent的system prompt里明确告诉它记忆系统的存在和使用方式比如“你可以使用store_memory工具记住用户的重要偏好使用retrieve_memory工具回忆之前的信息”。很多Agent不会主动调用记忆工具是因为它根本不知道有这个能力。把工具的使用说明写进prompt里效果会好很多。
网站建设高端定制企业官网