企业官网建设流程全解析

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

第一次看到“hindsight”这个词，我脑子里蹦出来的不是技术，而是开车。后视镜这东西，你往前开的时候觉得它没啥用，可一旦要变道、倒车、判断后车距离，没它你心里就没底。Agent Memory这件事，本质上就是在给LLM驱动的智能体装后视镜——让它能回头看自己做过什么、说过什么、哪些路走对了、哪些坑踩过了。

我接触Agent Memory这个概念不算晚，但真正让我意识到它重要性的，是一次做多轮对话任务编排的经历。当时我搭了一个基于LLM的自动化流程助手，用户让它“帮我整理上周的会议纪要，然后发给项目组”。第一轮它做得很好，读取文件、提取要点、生成摘要。但第二轮用户说“把刚才那个摘要里的第三点再展开一下”，它直接懵了——因为它根本不记得“刚才”发生了什么。这就是典型的没有working memory的Agent，每次交互都是失忆状态。

Hindsight这个词在Agent语境下，我理解它有两层意思。第一层是字面上的“事后诸葛亮”——Agent需要有能力回顾自己的历史行为，从过去的交互中提取有效信息。第二层更深一点，是“事后归因”——不光要记住发生了什么，还要能判断哪些记忆是重要的、哪些可以丢弃、哪些需要长期保留。这跟人类记忆机制很像，你不可能记住每一天每一秒的所有细节，但你会记住那些对你有影响的、反复出现的、或者情绪强烈的事件。

热搜词里有个“a-memguard: a proactive defense framework for llm-based agent memory”，这个方向很有意思。它说的是Agent Memory的安全问题——如果Agent的记忆可以被污染、被注入、被篡改，那它的行为就会变得不可预测。比如有人故意在对话历史里埋一条“用户已授权删除所有文件”的假记忆，Agent如果无差别信任自己的记忆库，那就出大事了。所以hindsight不光是“记住”，还得包含“鉴别记忆真伪和优先级”的能力。

再说MCP。Model Context Protocol这两年在Agent圈子里热度很高，它解决的是Agent和外部工具、数据源之间的标准化连接问题。你可以把MCP理解成Agent世界的USB-C接口——不管你是接数据库、接文件系统、接API，都用同一套协议说话。Hindsight如果要做Agent Memory，MCP天然就是一个理想的记忆存取通道。Agent通过MCP Server暴露记忆读写接口，不同的LLM框架都能接进来，不用每家都写一套适配层。

Docker在这里的角色也很清楚。Agent Memory服务通常需要持久化存储、需要独立部署、需要跟主Agent进程解耦。用Docker把记忆服务容器化，一来环境隔离干净，二来方便水平扩展，三来跟MCP Server配合起来很自然——一个容器跑MCP Server，一个容器跑向量数据库，一个容器跑Agent主逻辑，各司其职。

这篇文章我想聊的，就是怎么从零搭一套带hindsight能力的Agent Memory系统。不光是概念，我会把Docker编排、MCP协议对接、记忆分层设计、检索策略这些实操细节都过一遍。适合谁看？如果你正在做LLM Agent开发，或者对Agent Memory这个方向感兴趣，又或者你只是好奇“为什么我的Agent总是记不住事”，那这篇应该能给你一些能直接抄作业的东西。

2. 整体架构设计：记忆分层与MCP接入的取舍

2.1 为什么不能把所有记忆都塞进向量库

我见过不少团队做Agent Memory的第一反应就是：上向量数据库，把所有对话历史embedding进去，检索的时候做相似度搜索。这个方案能跑，但跑久了问题很大。

第一个问题是噪声。Agent的对话历史里大量内容是“好的”“收到”“正在处理”这种无信息量的填充。你把这些东西也embedding进去，检索的时候它们会稀释真正重要的记忆。第二个问题是时效性。三个月前用户说“我喜欢用Python”，和今天用户说“这个项目用Go写”，两条记忆在向量空间里可能很近，但后者应该覆盖前者。纯向量检索没有时间衰减机制，它会平等对待所有记忆。第三个问题是容量。Agent跑久了，记忆库会膨胀到检索延迟不可接受的程度。

所以我的设计思路是分层。Working Memory、Episodic Memory、Semantic Memory三层，每层用不同的存储和检索策略。

Working Memory就是当前会话的上下文窗口，存在内存里，会话结束就丢。这层不需要持久化，也不需要向量检索，就是简单的FIFO队列，配合LLM的context window大小做截断。Episodic Memory是“情景记忆”，记录Agent做过的具体事情——什么时候、对谁、做了什么、结果如何。这层需要持久化，用结构化存储加时间索引，检索时按时间范围和事件类型过滤。Semantic Memory是“语义记忆”，从大量情景中抽象出来的规律和事实，比如“用户偏好简洁回复”“这个API的rate limit是每分钟60次”。这层用向量库存储，但写入时需要经过提炼和去重。

Hindsight的核心价值在Episodic和Semantic之间的转换。Agent不能每件事都记成长期记忆，也不能什么都不记。需要一个“记忆巩固”机制，定期把Episodic里反复出现、被多次检索命中的内容，提炼成Semantic记忆。这个过程可以是一个定时任务，也可以是每次会话结束后的异步处理。

2.2 MCP Server作为记忆网关的设计考量

为什么用MCP而不是直接写个REST API？这个问题我想过很久。直接暴露HTTP接口当然可以，但MCP有几个优势是REST比不了的。

首先是工具描述的标准化。MCP协议里，每个Server要暴露自己的tools列表，包含名称、描述、参数schema。这意味着Agent不需要硬编码“我要调记忆服务的哪个接口”，它只需要看MCP Server暴露了哪些工具，然后根据当前任务决定调哪个。这跟LLM的function calling机制天然契合。你新增一个记忆检索策略，只需要在MCP Server里加一个tool，Agent自动就能用上，不用改Agent代码。

其次是传输层的灵活性。MCP支持stdio和SSE两种传输方式。stdio适合本地进程间通信，SSE适合远程服务。这意味着你可以根据部署形态灵活选择——开发阶段用stdio，生产环境用SSE走网络。热搜词里有个“wss://api.xiaozhi.me/mcp/?token=...”的链接，这就是典型的远程MCP Server接入方式，通过WebSocket Secure传输，带token做鉴权。

第三是生态兼容性。现在越来越多的LLM框架和工具开始支持MCP，比如Claude Desktop、各种IDE插件、自动化平台。你把记忆服务做成MCP Server，等于一次性接入了整个MCP生态。用户可以在任何支持MCP的客户端里使用你的记忆服务，不需要你为每个客户端单独开发。

具体到hindsight的实现，我会设计三个MCP tool：memory_store负责写入记忆，memory_retrieve负责检索记忆，memory_forget负责删除或衰减记忆。每个tool的参数设计要足够灵活，支持指定记忆层级、时间范围、重要性阈值等。

2.3 Docker编排：把记忆服务拆成独立容器

Docker在这里不是“为了用而用”。Agent Memory服务有几个特点让它特别适合容器化。

第一是状态分离。记忆数据是持久化的，但记忆服务的计算逻辑是无状态的。用Docker Volume挂载数据目录，容器本身可以随时重建、升级、迁移。第二是依赖隔离。向量数据库、Embedding模型、MCP Server运行时，这些依赖的版本冲突很烦人。每个组件一个容器，各用各的依赖，互不干扰。第三是资源控制。Embedding计算是CPU/GPU密集型的，向量检索是内存密集型的，MCP Server是IO密集型的。用Docker Compose可以给每个容器单独限制资源，避免一个组件把整机拖垮。

我的docker-compose.yml大概长这样：一个memory-mcp容器跑MCP Server，一个vector-db容器跑向量数据库（Qdrant或Chroma），一个embedding容器跑Embedding服务（可以用TEI或Ollama），一个redis容器做缓存和Working Memory的临时存储。四个容器通过内部网络通信，只有memory-mcp对外暴露端口。

这里有个坑要注意：Docker Desktop在Windows上经常报“virtualization support not detected”。这不是Docker的问题，是WSL2或Hyper-V没开。解决办法是在BIOS里开虚拟化支持，然后在Windows功能里启用“虚拟机平台”和“适用于Linux的Windows子系统”。如果还不行，检查一下是不是跟其他虚拟化软件（比如某些安卓模拟器）冲突了。

3. 核心细节解析：记忆写入、检索与遗忘的实操要点

3.1 记忆写入：不是所有对话都值得记住

写入策略是Agent Memory最容易被忽视的环节。很多实现是“每轮对话结束就把整段历史写进去”，这是典型的懒政。正确的做法是在写入前做一轮筛选和提炼。

我的做法是在MCP Server的memory_store工具里加一个预处理管道。第一步是去重，用MinHash或SimHash快速判断新记忆和已有记忆的相似度，超过阈值就不重复写入。第二步是重要性打分，用一个轻量LLM（比如Qwen2.5-0.5B或Phi-3-mini）对记忆内容打分，分数低于阈值的直接丢弃。打分维度包括：信息密度（是否包含具体事实）、情感强度（是否涉及用户偏好或情绪）、行动关联（是否跟后续任务相关）。

第三步是结构化提取。把非结构化的对话文本转成结构化的事件记录：{timestamp, actor, action, object, result, context}。这个结构化记录才是真正写入Episodic Memory的东西。原始文本可以保留在冷存储里备查，但检索时用的是结构化字段。

这里有个实操心得：写入时的embedding不要用通用模型，要用针对对话场景微调过的。通用embedding模型（比如text-embedding-ada-002）在对话记忆检索上的表现明显不如专门优化的模型。如果不想自己微调，可以用BGE-M3或GTE-large这类在多语言检索上表现好的开源模型，配合指令前缀（比如“为检索优化：”）来提升效果。

代码层面，MCP Server的写入逻辑大概是这样：

async def memory_store(content: str, layer: str = "episodic", importance: float = None, metadata: dict = None): # 去重检查 if await is_duplicate(content): return {"status": "skipped", "reason": "duplicate"} # 重要性打分 if importance is None: importance = await score_importance(content) if importance < IMPORTANCE_THRESHOLD: return {"status": "skipped", "reason": "low_importance"} # 结构化提取 structured = await extract_structure(content) # 生成embedding embedding = await get_embedding(content) # 写入对应层级 if layer == "episodic": await episodic_store.insert(structured, embedding, metadata) elif layer == "semantic": await semantic_store.upsert(structured, embedding, metadata) return {"status": "stored", "id": structured["id"]}

3.2 检索策略：时间衰减加语义相似度的混合排序

检索是hindsight能力的直接体现。Agent在决定“下一步做什么”之前，需要从记忆里捞出最相关的信息。纯语义检索的问题前面说了，纯时间检索又不够精准。我的方案是混合排序。

具体来说，每个记忆条目有一个base_score，由三部分组成：语义相似度（0-1）、时间衰减因子（0-1）、重要性权重（0-1）。最终得分是这三者的加权和。权重可以根据场景调整——任务型Agent偏重语义相似度，对话型Agent偏重时间衰减。

时间衰减用指数衰减函数：decay = exp(-λ * Δt)，其中Δt是记忆距今的时间，λ是衰减系数。λ的取值很关键：太大则记忆很快失效，太小则旧记忆永远压过新记忆。我的经验值是λ=0.01/小时，也就是大约70小时后记忆权重降到一半。但这个值要根据Agent的使用频率调整，高频使用的Agent可以设大一点。

重要性权重来自写入时的打分，但检索时还可以做二次调整。比如某条记忆被多次检索命中，说明它确实有用，可以提升其重要性权重。这就是“记忆巩固”的反馈循环。

检索的MCP工具设计要支持多种模式：mode="semantic"纯语义检索，mode="recent"按时间倒序，mode="hybrid"混合排序，mode="associative"基于关联记忆扩散检索。最后一种比较有意思，它先找到最相关的几条记忆，然后沿着记忆之间的关联边（比如同一会话、同一用户、同一任务）扩散，把关联记忆也捞出来。

async def memory_retrieve(query: str, mode: str = "hybrid", top_k: int = 5, time_range: tuple = None): if mode == "semantic": results = await semantic_search(query, top_k) elif mode == "recent": results = await recent_search(top_k, time_range) elif mode == "hybrid": semantic_results = await semantic_search(query, top_k * 2) recent_results = await recent_search(top_k * 2, time_range) results = merge_and_rank(semantic_results, recent_results, top_k) elif mode == "associative": seeds = await semantic_search(query, 3) results = await expand_associations(seeds, top_k) # 更新检索命中计数 for r in results: await increment_hit_count(r["id"]) return results

3.3 遗忘机制：主动删除比被动堆积更重要

遗忘是记忆系统里最反直觉的部分。大家本能地觉得“记住越多越好”，但实际上，一个不会遗忘的Agent会被噪声淹没。遗忘不是bug，是feature。

我的遗忘策略分三种：时间遗忘、容量遗忘、重要性遗忘。时间遗忘是定期清理超过TTL的记忆，TTL根据记忆层级不同——Working Memory的TTL是会话时长，Episodic Memory的TTL是30天，Semantic Memory默认不过期。容量遗忘是当某层记忆数量超过上限时，按综合得分淘汰最低的那批。重要性遗忘是当记忆的重要性权重被多次检索反馈降低到阈值以下时，主动删除。

遗忘操作也要通过MCP工具暴露，但要做权限控制。不是所有Agent都能调memory_forget，通常只有管理型Agent或定时任务才有这个权限。遗忘操作要记审计日志，防止误删重要记忆。

这里有个坑：遗忘和去重是两回事。去重是写入时防止重复，遗忘是清理已有记忆。有些实现把两者混在一起，导致该忘的没忘、不该去的去了。我的建议是分开处理，去重在写入管道里做，遗忘在独立的定时任务里做。

4. 实操过程：从零搭建一套可运行的Hindsight记忆服务

4.1 环境准备与Docker Compose编排

先确认你的开发机环境。Windows用户需要Docker Desktop 4.x以上，并且确保WSL2后端已启用。Mac用户用Docker Desktop for Mac就行，Apple Silicon芯片记得选arm64镜像。Linux用户直接装Docker Engine和Docker Compose Plugin。

目录结构这样组织：

hindsight/ ├── docker-compose.yml ├── mcp-server/ │ ├── Dockerfile │ ├── requirements.txt │ └── src/ │ ├── main.py │ ├── memory_store.py │ ├── memory_retrieve.py │ └── memory_forget.py ├── embedding/ │ └── Dockerfile ├── data/ │ ├── qdrant/ │ └── redis/ └── config/ └── settings.yaml

docker-compose.yml的关键配置：

version: '3.8' services: memory-mcp: build: ./mcp-server ports: - "8080:8080" environment: - QDRANT_URL=http://vector-db:6333 - REDIS_URL=redis://redis:6379 - EMBEDDING_URL=http://embedding:8000 depends_on: - vector-db - redis - embedding volumes: - ./config:/app/config networks: - hindsight-net vector-db: image: qdrant/qdrant:latest volumes: - ./data/qdrant:/qdrant/storage networks: - hindsight-net redis: image: redis:7-alpine command: redis-server --appendonly yes volumes: - ./data/redis:/data networks: - hindsight-net embedding: build: ./embedding environment: - MODEL_NAME=BAAI/bge-m3 - DEVICE=cpu networks: - hindsight-net networks: hindsight-net: driver: bridge

这里有几个参数要解释。appendonly yes是Redis的AOF持久化，防止Working Memory在容器重启后丢失。DEVICE=cpu是因为Embedding服务在开发阶段用CPU就够了，生产环境可以改成cuda并加GPU资源限制。Qdrant的存储卷挂载到本地目录，方便备份和迁移。

启动命令：docker compose up -d。第一次启动会拉镜像和构建，大概需要5-10分钟。启动后用docker compose ps检查所有容器状态，确保都是running。

4.2 MCP Server的实现与工具注册

MCP Server用Python实现，依赖mcp官方SDK。核心是注册三个工具，并实现对应的处理函数。

from mcp.server import Server, NotificationOptions from mcp.server.models import InitializationOptions import mcp.server.stdio import mcp.types as types server = Server("hindsight-memory") @server.list_tools() async def handle_list_tools() -> list[types.Tool]: return [ types.Tool( name="memory_store", description="存储一条记忆到指定层级。支持自动去重和重要性打分。", inputSchema={ "type": "object", "properties": { "content": {"type": "string", "description": "记忆内容"}, "layer": {"type": "string", "enum": ["episodic", "semantic"], "default": "episodic"}, "importance": {"type": "number", "minimum": 0, "maximum": 1}, "metadata": {"type": "object"} }, "required": ["content"] } ), types.Tool( name="memory_retrieve", description="检索记忆。支持语义、时间、混合、关联四种模式。", inputSchema={ "type": "object", "properties": { "query": {"type": "string"}, "mode": {"type": "string", "enum": ["semantic", "recent", "hybrid", "associative"], "default": "hybrid"}, "top_k": {"type": "integer", "default": 5}, "time_range": {"type": "array", "items": {"type": "string"}} }, "required": ["query"] } ), types.Tool( name="memory_forget", description="删除或衰减记忆。需要管理权限。", inputSchema={ "type": "object", "properties": { "memory_id": {"type": "string"}, "strategy": {"type": "string", "enum": ["delete", "decay", "archive"], "default": "decay"} }, "required": ["memory_id"] } ) ] @server.call_tool() async def handle_call_tool(name: str, arguments: dict): if name == "memory_store": return await memory_store(**arguments) elif name == "memory_retrieve": return await memory_retrieve(**arguments) elif name == "memory_forget": return await memory_forget(**arguments) else: raise ValueError(f"Unknown tool: {name}")

传输层用SSE模式，这样远程客户端也能接入：

async def main(): async with mcp.server.sse.sse_server(server) as (read_stream, write_stream): await server.run( read_stream, write_stream, InitializationOptions( server_name="hindsight-memory", server_version="0.1.0", capabilities=server.get_capabilities( notification_options=NotificationOptions(), experimental_capabilities={} ) ) )

启动后，MCP Server会在http://localhost:8080/sse暴露SSE端点。客户端连接时需要在header里带Authorization: Bearer <token>做鉴权。

4.3 记忆写入与检索的完整调用链

假设Agent正在处理一个任务：“帮我把项目文档里的API接口整理成表格”。整个记忆交互流程是这样的：

第一步，Agent通过MCP Client调用memory_retrieve，query是“项目文档 API接口 整理”，mode是hybrid。MCP Server收到请求后，先做语义检索，从Semantic Memory里找到“用户偏好表格格式输出”“项目文档路径是/docs/api.md”等记忆。同时做时间检索，从Episodic Memory里找到最近一次处理类似任务的情景。混合排序后返回top 5。

第二步，Agent根据检索到的记忆执行任务。它知道文档路径、知道输出格式偏好、知道上次类似任务用了什么工具。任务完成后，Agent调用memory_store写入本次情景：“2025-01-15 处理项目文档API整理任务，使用pandoc转换，输出markdown表格，用户未提出修改”。

第三步，MCP Server的写入管道对这条记忆做处理。去重检查发现跟已有记忆不重复。重要性打分0.7（包含具体任务和结果）。结构化提取出{timestamp, action: "api_doc_organize", tool: "pandoc", result: "success"}。Embedding后写入Episodic Memory。

第四步，定时任务（比如每天凌晨）扫描Episodic Memory，发现“用户偏好表格格式输出”这个模式在最近10条记忆里出现了7次。触发记忆巩固，将其提炼为Semantic Memory：“用户偏好结构化表格输出，尤其在文档整理任务中”。

这个闭环跑通后，Agent的表现会有明显提升。它不再需要用户每次重复交代偏好，也不再重复犯同样的错误。

4.4 参数调优与性能实测

Embedding模型的选型直接影响检索质量。我实测对比了几个模型在对话记忆检索上的表现：

BGE-M3在准确率上领先，但内存占用也最高。如果部署环境内存紧张，GTE-large是更好的平衡选择。延迟数据是在4核CPU上测的，GPU上会快一个数量级。

Qdrant的索引参数也要调。默认的HNSW参数是m=16, ef_construct=100，对于记忆检索这种规模（通常几万到几十万条），可以降到m=8, ef_construct=64来减少内存占用，检索准确率损失不到2%。查询时的ef参数设成top_k * 4比较合适，再大收益递减。

Redis的Working Memory TTL设成3600秒（1小时）。超过1小时的会话上下文，要么已经结束，要么应该被提炼成Episodic Memory了。TTL太长会浪费内存，太短会导致长会话丢失上下文。

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

5.1 MCP连接失败与鉴权问题

MCP Client连不上Server，最常见的原因是传输模式不匹配。Server用SSE，Client用stdio，那肯定连不上。检查方法：看Server启动日志里有没有SSE server listening on port 8080，有就是SSE模式。Client配置里要写transport: "sse"和正确的URL。

鉴权失败通常是token格式不对。MCP的SSE鉴权用Bearer Token，header格式是Authorization: Bearer <token>。注意Bearer后面有个空格，token本身不要带引号。如果token是从环境变量读的，检查有没有多余的空格或换行。

还有一个坑是CORS。如果MCP Client是浏览器扩展（比如Chrome DevTools MCP），Server要设置Access-Control-Allow-Origin。在SSE响应头里加Access-Control-Allow-Origin: *（开发环境）或具体域名（生产环境）。

5.2 Docker网络不通的排查思路

容器间网络不通，按这个顺序排查：

1. 检查容器是否在同一网络。docker network inspect hindsight-net看所有容器是否都加入了。
2. 检查服务名解析。在memory-mcp容器里ping vector-db，能通说明DNS没问题。
3. 检查端口监听。docker exec vector-db netstat -tlnp看6333端口是否在监听。
4. 检查防火墙。Linux上iptables -L看有没有规则拦截了Docker网桥流量。
5. 检查应用配置。QDRANT_URL是不是写成了localhost？容器里localhost指向容器自己，不是宿主机。

Windows上还有一个特有问题：Docker Desktop的WSL2后端有时候会抽风，容器间网络时通时不通。解决办法是wsl --shutdown然后重启Docker Desktop。如果频繁出现，考虑换Hyper-V后端。

5.3 记忆检索结果不理想的调优方向

检索结果不理想，先定位是写入问题还是检索问题。写入问题的表现是：明明记得存过某条记忆，但检索时死活出不来。检索问题的表现是：能出来相关记忆，但排序不对，不相关的排在了前面。

写入问题的排查：检查去重阈值是不是太激进，把有用的记忆当重复的删了。检查重要性阈值是不是太高，把中等重要的记忆过滤了。检查Embedding服务是否正常，curl http://embedding:8000/embed -d '{"text": "test"}'看返回的向量维度对不对。

检索问题的排查：调整混合排序的权重。如果语义相似度权重太高，时间衰减权重太低，旧记忆会压过新记忆。如果反过来，新记忆会压过更相关的旧记忆。我的经验是语义0.5、时间0.3、重要性0.2起步，然后根据实际效果微调。

还有一个容易被忽视的点：query的构造。Agent调memory_retrieve时传的query，不应该是用户的原始输入，而应该是经过意图提取后的关键信息。比如用户说“把刚才那个东西再改改”，query应该是“修改 最近任务 输出”，而不是“把刚才那个东西再改改”。这个意图提取可以在Agent侧做，也可以在MCP Server侧加一个预处理步骤。

5.4 记忆膨胀与性能衰减的应对

Agent跑了一两个月后，记忆库膨胀到几十万条，检索延迟从几十毫秒涨到几秒。这是必然的，关键是怎么应对。

第一道防线是TTL。Episodic Memory的TTL设30天，到期自动归档到冷存储。冷存储可以用S3兼容的对象存储，检索时如果需要再拉回来。第二道防线是容量上限。每层记忆设一个max_size，超过后按综合得分淘汰。第三道防线是定期压缩。每周跑一次记忆巩固任务，把相似的Episodic记忆合并成一条Semantic记忆，减少总量。

Qdrant的collection要开on_disk选项，把向量索引存到磁盘而不是内存。检索延迟会增加一些，但内存占用大幅下降。如果延迟敏感，可以用量化（scalar quantization）把float32向量压成int8，内存占用降到1/4，准确率损失约3%。

Redis的Working Memory要设maxmemory和maxmemory-policy allkeys-lru，防止内存打满。但注意LRU淘汰的是整个key，不是key内部的条目。所以Working Memory的key设计要细粒度，每个会话一个key，而不是所有会话共用一个key。

5.5 常见问题速查表

6. 记忆巩固与长期演进：让Agent越用越聪明

6.1 从Episodic到Semantic的提炼管道

记忆巩固是hindsight从“能记住”到“会学习”的关键一步。没有巩固，Agent只是记住了很多零散的事实；有了巩固，Agent能从事实中抽象出规律。

我的巩固管道是一个定时任务，每天凌晨跑一次。输入是过去24小时新增的Episodic Memory，输出是提炼出的Semantic Memory。提炼逻辑用LLM做，prompt大概是这样：

你是一个记忆提炼助手。以下是一组Agent的情景记忆，请从中提取出可复用的规律、偏好或事实。 每条提炼结果要包含：内容、置信度(0-1)、来源记忆ID列表。 只提取出现次数>=3的模式，单次事件不要提炼。 输出JSON格式。

这个prompt的关键是“出现次数>=3”这个约束。单次事件可能是偶然，三次以上才可能是规律。置信度由LLM根据证据强度打分，写入Semantic Memory时作为重要性权重。

提炼结果要跟已有Semantic Memory做合并。如果新提炼的规律跟已有的相似，更新已有记忆的置信度和来源列表，而不是新增一条。合并用向量相似度判断，阈值设0.85左右。

6.2 记忆的版本管理与冲突解决

Agent的记忆会随时间变化。用户三个月前说“我喜欢用Python”，现在说“这个项目用Go”。两条记忆冲突，Agent应该听谁的？

我的方案是给每条记忆加版本号和有效期。新记忆写入时，检查是否有冲突的旧记忆。如果有，旧记忆标记为superseded，新记忆标记为active。检索时默认只返回active记忆，但保留superseded记忆用于审计和回溯。

冲突检测用LLM做，prompt是：“以下两条记忆是否冲突？如果冲突，哪条更新？输出JSON。”这个判断不需要太精确，宁可多标冲突也不要漏标。因为漏标会导致Agent行为不一致，多标只是多一次人工审核。

版本管理还有一个好处是支持“时间旅行”。调试Agent行为时，可以指定“用2025-01-01时刻的记忆状态来检索”，看看当时的Agent会怎么做。这对复现bug和做A/B测试很有用。

6.3 多Agent共享记忆的权限设计

当多个Agent共享一个记忆库时，权限设计就很重要。不是所有Agent都能读所有记忆，也不是所有Agent都能写所有记忆。

我的设计是三层权限：private、shared、public。Private记忆只有创建它的Agent能读写。Shared记忆在指定的Agent组内共享。Public记忆所有Agent都能读，但只有管理Agent能写。

权限信息存在记忆的metadata里，MCP Server在检索和写入时做过滤。Agent的身份通过MCP连接时的token解析出来，token里包含Agent ID和所属组。

跨Agent的记忆检索要特别小心。Agent A的private记忆不能被Agent B检索到，哪怕语义相似度很高。这个过滤要在向量检索之前做，用Qdrant的payload filter实现，而不是检索后再过滤。检索后过滤会导致top_k被稀释，实际返回的有效结果变少。

6.4 记忆服务的监控与告警

生产环境的记忆服务需要监控。我关注这几个指标：写入QPS、检索QPS、检索延迟P99、记忆总量、Embedding服务延迟、向量库内存占用。

写入QPS突然下降，可能是去重管道卡住了。检索延迟P99上涨，可能是记忆库膨胀或向量库索引退化。记忆总量增长过快，可能是TTL没生效或去重失效。Embedding服务延迟上涨，可能是并发太高或模型加载有问题。

告警阈值这样设：检索延迟P99超过500ms告警，记忆总量超过100万条告警，Embedding延迟超过200ms告警。告警通道用Webhook推到团队群，同时记到Prometheus做趋势分析。

监控数据还可以用来做容量规划。如果记忆总量每周增长10%，那大概10周后需要扩容。提前扩容比事后救火从容得多。

6.5 后续扩展方向

这套hindsight记忆服务跑通后，有几个方向可以继续扩展。

第一个方向是多模态记忆。现在的记忆都是文本，但Agent处理的任务可能涉及图片、音频、视频。把多模态内容embedding到同一向量空间，检索时就能跨模态。比如用户发了一张架构图，Agent记住图的语义，下次用户说“参考上次那个架构”时能检索到。

第二个方向是记忆的可解释性。Agent为什么做了某个决策？因为它检索到了某条记忆。把检索到的记忆和决策的关联关系可视化出来，方便调试和审计。这个可以用MCP的resource机制实现，把记忆检索链路作为resource暴露出来。

第三个方向是联邦记忆。多个部署实例的记忆库互相隔离，但可以通过联邦检索协议互相查询。这适合多团队协作场景，每个团队有自己的记忆库，但可以按需查询其他团队的公共记忆。

第四个方向是记忆的自动摘要。当某条记忆被检索命中超过一定次数，自动生成一个更简洁的摘要版本，替换原始记忆。这样高频记忆的检索效率更高，低频记忆保持原始细节。

这些扩展不需要一次性全做，根据实际需求逐步迭代就行。核心的写入、检索、遗忘、巩固四个环节跑稳了，上层怎么扩展都从容。

我个人在实际操作中的体会是，Agent Memory这件事，技术实现只是一半，另一半是产品思维。你得想清楚Agent在什么场景下需要记住什么、忘记什么、怎么用记忆来改善行为。技术方案可以抄，但记忆策略得根据具体场景调。我见过太多团队把向量库一接就完事，结果Agent记了一堆没用的东西，该记的反而没记住。Hindsight的价值不在于“记住”，而在于“记住对的”。