企业官网建设流程全解析

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

“hindsight”这个词本身的意思就是“事后之明”——事情发生之后才明白当初应该怎么做。把这个词用在Agent Memory（智能体记忆）这个领域，指向性非常明确：我们要解决的是LLM驱动的Agent在长期运行中“记不住、想不起、用不对”的核心痛点。你如果最近在折腾LLM Agent相关的项目，大概率已经踩过这样的坑——Agent在单轮对话里表现惊艳，一旦对话轮次拉长到几十轮，它就开始胡言乱语，前面明确说过的约束条件被抛到九霄云外，用户纠正过的错误反复再犯。这不是模型能力不够，而是记忆架构没设计好。

我最初接触这个方向，是因为一个实际需求：做一个能持续跟踪项目进展的辅助Agent，它需要记住过去几周内用户提过的所有需求变更、技术决策和踩坑记录。用最朴素的方式——把全部历史对话塞进context window——很快就撞墙了。Token消耗爆炸不说，模型对超长上下文的注意力衰减非常明显，关键信息淹没在大量无关对话里。后来试过简单的摘要压缩，又发现摘要会丢失细节，等到真正需要某个具体参数的时候，摘要里根本没保留。这就是“hindsight”要解决的核心问题：如何让Agent像人一样，在需要的时候能准确回忆起过去发生的关键事件，并且理解这些事件之间的因果关系。

这篇文章适合几类人看：一是正在做LLM Agent应用开发、被记忆问题困扰的工程师；二是对Agent架构设计感兴趣、想了解记忆模块怎么落地的人；三是已经在用Docker部署各种服务、想把手头的LLM工具链整合起来的实践者。我会从整体设计思路讲起，然后拆解核心细节，接着给出完整的实操流程，最后分享我在排查问题时积累的经验。文中涉及的技术栈包括LLM、MCP协议、Docker容器化部署，以及Agent Memory的分层存储设计。

2. 整体设计与思路拆解：Agent Memory到底该怎么分层

2.1 为什么不能只靠Context Window硬撑

很多人刚开始做Agent的时候，第一反应就是把所有历史对话都拼到prompt里。短对话没问题，一旦超过模型的有效上下文长度，要么截断丢信息，要么就得换更大上下文的模型，成本直线上升。更关键的是，即使模型支持128K甚至更长的上下文，中间部分的信息检索准确率也会显著下降——这是注意力机制的固有特性，不是换个模型就能解决的。

我做过一个简单的对比测试：让Agent记住20轮对话前用户提到的一个特定数字，然后在一段无关对话之后询问这个数字。把全部历史塞进context的方案，准确率大概在60%左右；而采用分层记忆架构、把关键信息单独存储并在需要时检索注入的方案，准确率能到95%以上。这个差距在真实应用里就是“能用”和“不能用”的区别。

所以核心思路很明确：Context Window只放当前最相关的信息，长期记忆放到外部存储，通过检索机制按需注入。这就是hindsight这类Agent Memory系统的设计起点。

2.2 三层记忆架构：Working Memory、Episodic Memory、Semantic Memory

参考认知科学里对人类记忆的分类，我在实际项目中把Agent Memory分成三层：

Working Memory（工作记忆）：当前对话轮次直接相关的信息，放在context window里。这部分容量有限，需要严格控制。通常只保留最近几轮对话的原文，加上从长期记忆中检索出来的相关片段。

Episodic Memory（情景记忆）：具体发生过的事件记录。比如“用户在第三轮对话中要求把数据库从MySQL换成PostgreSQL”、“第七轮对话中用户反馈某个API返回格式不对”。这些记录带时间戳、带上下文，按事件粒度存储。

Semantic Memory（语义记忆）：从多个事件中抽象出来的通用知识。比如“这个用户偏好使用ORM而不是手写SQL”、“这个项目的API设计遵循RESTful风格”。这部分是对情景记忆的进一步提炼，存储的是结论而非原始事件。

三层之间的流转关系是这样的：对话进行时，原始信息先进入Working Memory；对话结束后，关键事件被抽取出来存入Episodic Memory；当同类事件积累到一定数量，系统自动或手动触发提炼，生成Semantic Memory。检索的时候，优先查Semantic Memory（因为信息密度高），不够再查Episodic Memory，最后才回退到Working Memory。

注意：不要一上来就追求全自动的语义提炼。我踩过的坑是，自动提炼的语义记忆经常出现过度概括或错误归纳，反而污染了记忆库。建议初期以手动或半自动方式管理Semantic Memory，等积累足够多的样本后再考虑自动化。

2.3 为什么选择MCP协议做记忆服务的接口层

MCP（Model Context Protocol）是Anthropic推出的一个开放协议，用来标准化LLM与外部工具、数据源之间的交互方式。我选择用MCP来封装记忆服务，主要考虑几点：

第一，解耦。记忆服务作为一个独立的MCP Server运行，LLM Agent通过标准协议调用，不依赖具体的Agent框架。今天用LangChain，明天换AutoGen，记忆服务不用改。

第二，可组合。MCP Server可以同时暴露多个工具，比如store_memory、retrieve_memory、summarize_episodes，Agent根据需要调用。而且多个MCP Server可以并行运行，记忆服务可以和文件系统服务、数据库服务共存。

第三，生态兼容。现在越来越多的工具支持MCP协议，包括各种IDE插件、浏览器扩展、命令行工具。把记忆服务做成MCP Server，意味着任何支持MCP的客户端都能直接接入。

具体实现上，我用Python写了一个MCP Server，底层存储用SQLite（轻量、零配置）加向量数据库（用于语义检索）。SQLite存结构化的事件记录，向量库存embedding用于相似度搜索。两者通过事件ID关联。

2.4 Docker化部署：为什么不用裸机跑

把记忆服务跑在Docker容器里，好处是环境隔离和可移植性。我试过直接在宿主机上装依赖，结果Python版本冲突、SQLite扩展加载失败、向量数据库的C库版本不匹配，折腾了一整天。换成Docker之后，所有依赖打包在镜像里，换台机器docker compose up就能跑起来。

另外，Docker的网络管理让MCP Server和Agent之间的通信更可控。我可以把记忆服务放在一个内部网络里，只暴露必要的端口，Agent通过服务名访问，不用关心IP地址。如果后续要加认证和限流，在Docker网络层面做也比在应用层做更干净。

3. 核心细节解析与实操要点：从存储格式到检索策略

3.1 记忆条目的数据结构设计

每条记忆记录我设计了这些字段：

ttl字段的设计很关键。Working Memory的记录通常设置较短的TTL（比如1小时），过期自动清理。Episodic Memory的TTL可以设长一些（比如30天），Semantic Memory则永不过期。这样能自动控制存储增长，避免记忆库无限膨胀。

access_count用来做热度加权。检索的时候，除了向量相似度，还会考虑这条记忆被访问的频率。经常被用到的记忆说明价值高，排序时应该靠前。

3.2 向量化模型的选择与权衡

Embedding模型我试过好几个，最后选的是text-embedding-3-small（OpenAI）和bge-m3（本地部署）两个方案并行。原因如下：

OpenAI的方案优点是稳定、无需维护，适合快速验证。缺点是API调用有延迟和成本，而且数据要出境（如果在意的话）。本地部署bge-m3的优点是数据不出本地、无API成本，缺点是需要GPU资源，推理速度取决于硬件。

实际使用中，我做了个路由策略：对延迟敏感的检索走本地模型，对精度要求高的走API模型。两者生成的向量存在不同的表里，检索时分别查询再合并结果。

提示：embedding维度不一致会导致无法直接比较相似度。如果混用不同模型，务必在metadata里标记embedding来源，检索时按来源分组查询。

3.3 检索策略：向量相似度+关键词+时间衰减

单纯的向量相似度检索有个问题：它擅长语义匹配，但对精确的关键词匹配不够敏感。比如用户问“上次说的那个端口号是多少”，向量检索可能返回一堆关于“端口”的讨论，但真正包含具体端口号的那条记录可能排在后面。

我的做法是混合检索：

1. 向量检索：用query的embedding去向量库搜Top-K，K取20。
2. 关键词检索：用BM25算法在content字段上做全文搜索，取Top-20。
3. 合并去重：两路结果按id合并，计算综合得分。
4. 时间衰减：综合得分乘以时间衰减因子，越久远的记忆得分越低。衰减公式我用的是score * exp(-lambda * days_ago)，lambda取0.01，意味着大约70天后权重降到一半。
5. 热度加权：再乘以log(1 + access_count)，让高频访问的记忆获得加成。
6. 最终排序：取Top-5返回给Agent。

这套组合拳实测下来，检索准确率比单用向量检索提升了大概20个百分点。尤其是在需要精确回忆具体数值、名称、日期的场景下，关键词检索的补充作用非常明显。

3.4 MCP Server的工具定义

MCP Server暴露给Agent的工具我定义了四个：

# 工具1：存储记忆 { "name": "store_memory", "description": "存储一条新的记忆记录", "parameters": { "content": "string, 记忆正文", "memory_type": "string, 枚举值: working/episodic/semantic", "metadata": "object, 可选扩展字段", "ttl": "integer, 可选过期时间(秒)" } } # 工具2：检索记忆 { "name": "retrieve_memory", "description": "根据查询检索相关记忆", "parameters": { "query": "string, 查询文本", "top_k": "integer, 返回条数, 默认5", "memory_type": "string, 可选过滤类型" } } # 工具3：提炼语义记忆 { "name": "summarize_episodes", "description": "将多条情景记忆提炼为语义记忆", "parameters": { "episode_ids": "array, 情景记忆ID列表", "instruction": "string, 提炼指令" } } # 工具4：清理过期记忆 { "name": "cleanup_expired", "description": "清理已过期的记忆记录", "parameters": {} }

Agent在对话过程中，根据上下文自主决定何时调用这些工具。比如用户说“记住这个配置”，Agent就调store_memory；用户问“之前那个配置是什么”，Agent就调retrieve_memory。

4. 实操过程与核心环节实现：从零搭建一个可用的记忆服务

4.1 环境准备与Docker Compose编排

先确保Docker Desktop已经装好并且能正常启动。Windows上如果遇到“Virtualization support not detected”的报错，需要进BIOS开启虚拟化支持（Intel VT-x或AMD-V），然后在Windows功能里启用WSL2。Mac上相对简单，装好Docker Desktop即可。

项目目录结构如下：

hindsight-memory/ ├── docker-compose.yml ├── mcp-server/ │ ├── Dockerfile │ ├── requirements.txt │ └── src/ │ ├── main.py │ ├── storage.py │ ├── retrieval.py │ └── models.py ├── vector-db/ │ └── data/ └── config/ └── settings.yaml

docker-compose.yml的内容：

version: '3.8' services: mcp-memory: build: ./mcp-server container_name: hindsight-mcp ports: - "8765:8765" volumes: - ./vector-db/data:/app/data - ./config:/app/config environment: - EMBEDDING_MODEL=bge-m3 - DB_PATH=/app/data/memory.db - VECTOR_DIM=768 networks: - agent-net restart: unless-stopped networks: agent-net: driver: bridge

Dockerfile：

FROM python:3.11-slim WORKDIR /app RUN apt-get update && apt-get install -y \ build-essential \ && rm -rf /var/lib/apt/lists/* COPY requirements.txt . RUN pip install --no-cache-dir -r requirements.txt COPY src/ ./src/ COPY config/ ./config/ EXPOSE 8765 CMD ["python", "-m", "src.main"]

requirements.txt：

mcp>=0.1.0 fastapi>=0.104.0 uvicorn>=0.24.0 sqlite-utils>=3.35 numpy>=1.24 sentence-transformers>=2.2.0 rank-bm25>=0.2.2 pydantic>=2.0

4.2 存储层实现：SQLite+向量的混合方案

存储层我用SQLite做结构化存储，向量部分用numpy数组存在单独的文件里，通过id关联。这样做的原因是SQLite对向量类型的支持还不够成熟，而引入专门的向量数据库（如Milvus、Qdrant）又增加了部署复杂度。对于中小规模的记忆库（几万条以内），numpy数组加暴力检索完全够用。

# storage.py 核心逻辑 import sqlite3 import numpy as np import json from datetime import datetime, timedelta from uuid import uuid4 class MemoryStore: def __init__(self, db_path, vector_dim=768): self.conn = sqlite3.connect(db_path, check_same_thread=False) self.vector_dim = vector_dim self._init_tables() self.vectors = {} # id -> np.array def _init_tables(self): self.conn.execute(""" CREATE TABLE IF NOT EXISTS memories ( id TEXT PRIMARY KEY, timestamp TEXT NOT NULL, session_id TEXT, memory_type TEXT NOT NULL, content TEXT NOT NULL, metadata TEXT, ttl INTEGER DEFAULT 0, access_count INTEGER DEFAULT 0 ) """) self.conn.execute(""" CREATE INDEX IF NOT EXISTS idx_type ON memories(memory_type) """) self.conn.execute(""" CREATE INDEX IF NOT EXISTS idx_timestamp ON memories(timestamp) """) self.conn.commit() def store(self, content, memory_type, session_id=None, metadata=None, ttl=0, embedding=None): mem_id = str(uuid4()) ts = datetime.utcnow().isoformat() self.conn.execute( "INSERT INTO memories VALUES (?,?,?,?,?,?,?,?)", (mem_id, ts, session_id, memory_type, content, json.dumps(metadata or {}), ttl, 0) ) self.conn.commit() if embedding is not None: self.vectors[mem_id] = np.array(embedding, dtype=np.float32) return mem_id def cleanup_expired(self): now = datetime.utcnow() rows = self.conn.execute( "SELECT id, timestamp, ttl FROM memories WHERE ttl > 0" ).fetchall() expired = [] for row in rows: ts = datetime.fromisoformat(row[1]) if now > ts + timedelta(seconds=row[2]): expired.append(row[0]) for mem_id in expired: self.conn.execute("DELETE FROM memories WHERE id=?", (mem_id,)) self.vectors.pop(mem_id, None) self.conn.commit() return len(expired)

4.3 检索层实现：混合排序算法

检索层的核心是把向量相似度、关键词匹配、时间衰减、热度加权四个信号融合成一个综合得分。

# retrieval.py 核心逻辑 import numpy as np from rank_bm25 import BM25Okapi from datetime import datetime import math class MemoryRetriever: def __init__(self, store, embedder): self.store = store self.embedder = embedder self.bm25 = None self.bm25_ids = [] self._build_bm25_index() def _build_bm25_index(self): rows = self.store.conn.execute( "SELECT id, content FROM memories" ).fetchall() self.bm25_ids = [r[0] for r in rows] corpus = [r[1].lower().split() for r in rows] if corpus: self.bm25 = BM25Okapi(corpus) def retrieve(self, query, top_k=5, memory_type=None): # 向量检索 query_vec = self.embedder.encode(query) vec_scores = {} for mem_id, vec in self.store.vectors.items(): sim = np.dot(query_vec, vec) / ( np.linalg.norm(query_vec) * np.linalg.norm(vec) + 1e-8 ) vec_scores[mem_id] = float(sim) # 关键词检索 kw_scores = {} if self.bm25: tokens = query.lower().split() scores = self.bm25.get_scores(tokens) for i, mem_id in enumerate(self.bm25_ids): kw_scores[mem_id] = float(scores[i]) # 合并 all_ids = set(vec_scores.keys()) | set(kw_scores.keys()) combined = {} for mem_id in all_ids: v = vec_scores.get(mem_id, 0) k = kw_scores.get(mem_id, 0) # 归一化后加权 combined[mem_id] = 0.7 * v + 0.3 * min(k / 10.0, 1.0) # 时间衰减和热度加权 now = datetime.utcnow() final = {} for mem_id, score in combined.items(): row = self.store.conn.execute( "SELECT timestamp, access_count, memory_type FROM memories WHERE id=?", (mem_id,) ).fetchone() if not row: continue if memory_type and row[2] != memory_type: continue ts = datetime.fromisoformat(row[0]) days_ago = (now - ts).total_seconds() / 86400 decay = math.exp(-0.01 * days_ago) heat = math.log(1 + row[1]) final[mem_id] = score * decay * (1 + 0.1 * heat) # 排序取Top-K sorted_ids = sorted(final.keys(), key=lambda x: final[x], reverse=True) results = [] for mem_id in sorted_ids[:top_k]: row = self.store.conn.execute( "SELECT id, timestamp, content, memory_type, metadata FROM memories WHERE id=?", (mem_id,) ).fetchone() results.append({ "id": row[0], "timestamp": row[1], "content": row[2], "memory_type": row[3], "metadata": row[4], "score": final[mem_id] }) # 更新访问计数 self.store.conn.execute( "UPDATE memories SET access_count = access_count + 1 WHERE id=?", (mem_id,) ) self.store.conn.commit() return results

4.4 MCP Server的启动与接入

main.py里用FastAPI起一个HTTP服务，同时实现MCP协议的处理逻辑。MCP协议本身支持多种传输方式，我用的是HTTP+SSE（Server-Sent Events），因为Docker网络里HTTP最省事。

# main.py 核心逻辑 from fastapi import FastAPI, Request from fastapi.responses import StreamingResponse import json from src.storage import MemoryStore from src.retrieval import MemoryRetriever from src.models import get_embedder app = FastAPI() store = MemoryStore("/app/data/memory.db") embedder = get_embedder("bge-m3") retriever = MemoryRetriever(store, embedder) @app.post("/mcp/tools/call") async def call_tool(request: Request): body = await request.json() tool_name = body.get("name") args = body.get("arguments", {}) if tool_name == "store_memory": embedding = embedder.encode(args["content"]).tolist() mem_id = store.store( content=args["content"], memory_type=args.get("memory_type", "episodic"), metadata=args.get("metadata"), ttl=args.get("ttl", 0), embedding=embedding ) return {"result": {"id": mem_id, "status": "stored"}} elif tool_name == "retrieve_memory": results = retriever.retrieve( query=args["query"], top_k=args.get("top_k", 5), memory_type=args.get("memory_type") ) return {"result": results} elif tool_name == "cleanup_expired": count = store.cleanup_expired() return {"result": {"cleaned": count}} return {"error": f"Unknown tool: {tool_name}"} @app.get("/mcp/tools/list") async def list_tools(): return { "tools": [ {"name": "store_memory", "description": "存储记忆"}, {"name": "retrieve_memory", "description": "检索记忆"}, {"name": "cleanup_expired", "description": "清理过期记忆"} ] }

启动命令：

cd hindsight-memory docker compose up -d --build

验证服务是否正常：

curl http://localhost:8765/mcp/tools/list

返回工具列表就说明MCP Server跑起来了。然后在Agent端配置MCP连接，指向http://localhost:8765即可。

4.5 与Agent框架的对接示例

以LangChain为例，接入MCP记忆服务的代码大概长这样：

from langchain.agents import Tool, AgentExecutor from langchain_openai import ChatOpenAI import requests def store_memory(content: str, memory_type: str = "episodic") -> str: resp = requests.post("http://localhost:8765/mcp/tools/call", json={ "name": "store_memory", "arguments": {"content": content, "memory_type": memory_type} }) return resp.json()["result"]["status"] def retrieve_memory(query: str) -> str: resp = requests.post("http://localhost:8765/mcp/tools/call", json={ "name": "retrieve_memory", "arguments": {"query": query, "top_k": 5} }) results = resp.json()["result"] return "\n".join([r["content"] for r in results]) tools = [ Tool(name="store_memory", func=store_memory, description="存储重要信息到长期记忆"), Tool(name="retrieve_memory", func=retrieve_memory, description="从长期记忆中检索相关信息") ] llm = ChatOpenAI(model="gpt-4") agent = AgentExecutor.from_agent_and_tools( agent=llm.bind_tools(tools), tools=tools )

这样Agent在对话过程中就能自主决定何时存储、何时检索了。

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

5.1 Docker相关的高频问题

问题一：Docker Desktop启动报“Virtualization support not detected”

这是Windows上最常见的问题。原因通常是BIOS里没开虚拟化，或者WSL2没装好。解决步骤：重启进BIOS，找到Intel VT-x或AMD-V选项，设为Enabled；回到Windows，在“启用或关闭Windows功能”里勾选“虚拟机平台”和“适用于Linux的Windows子系统”；重启后wsl --update更新内核。

问题二：容器间网络不通

如果Agent跑在宿主机、MCP Server跑在Docker里，用localhost:8765访问通常没问题。但如果Agent也在Docker里，就需要用Docker网络的服务名访问，比如http://mcp-memory:8765。检查方法：docker network inspect agent-net看两个容器是否在同一个网络里。

问题三：SQLite数据库文件权限错误

挂载volume的时候，容器内用户和宿主机用户UID不一致会导致写不进去。解决办法是在Dockerfile里创建非root用户，或者简单粗暴地chmod 777数据目录（开发环境可以，生产环境别这么干）。

5.2 记忆检索效果差的排查思路

检索不准的时候，按这个顺序排查：

我遇到过一次检索完全失效的情况，排查了半天发现是embedding模型加载失败，返回了全零向量。全零向量之间的余弦相似度是NaN，导致排序完全乱掉。后来在代码里加了断言，embedding的norm小于1e-6就直接报错，避免静默失败。

5.3 记忆库膨胀的控制策略

跑了一段时间之后，记忆库会越来越大，检索速度下降。几个控制手段：

第一，严格执行TTL。Working Memory设1小时，Episodic Memory设30天，定期跑cleanup_expired。我写了个cron任务，每天凌晨清理一次。

第二，去重合并。相似度超过0.95的记忆条目自动合并，保留最新的时间戳和最高的access_count。这个逻辑我放在存储层，每次store之前先查一下有没有高度相似的已有记忆。

第三，分层归档。超过90天的Episodic Memory转移到冷存储表，检索时默认不查，需要时手动指定。这样热数据保持精简，检索速度快。

第四，语义提炼。把多条相关的情景记忆提炼成一条语义记忆，原始情景记忆可以删除或归档。比如用户提了五次“喜欢用深色主题”，提炼成一条“用户偏好深色主题”的语义记忆，五条原始记录就可以清理了。

5.4 MCP协议对接的坑

MCP协议还在快速演进中，不同版本的字段定义可能有差异。我遇到过的几个问题：

一是工具描述格式不兼容。有些客户端要求description字段必须有，有些要求parameters必须是JSON Schema格式。建议严格按照MCP官方文档的示例来写，别自己发挥。

二是SSE连接超时。HTTP+SSE的长连接如果超过一定时间没有数据传输，中间的网络设备可能会断开。解决办法是加心跳，每隔30秒发一个空事件保持连接。

三是并发调用冲突。多个Agent同时调store_memory的时候，SQLite的写锁可能导致超时。我的做法是在存储层加一个简单的队列，写操作串行化。对于读多写少的场景，这个方案够用了。

提示：MCP Server的日志一定要打详细，每个工具调用的入参和出参都记下来。排查问题时，日志是最可靠的线索。我用logging模块把日志同时输出到文件和stdout，Docker的docker logs命令就能直接看。

5.5 性能优化的几个实测数据

在我的测试环境（MacBook Pro M1, 16GB RAM）上，几个关键指标：

• 单条记忆存储（含embedding计算）：约50ms
• 检索Top-5（记忆库1000条）：约30ms
• 检索Top-5（记忆库10000条）：约120ms
• 清理过期记忆（10000条中清理100条）：约200ms

当记忆库超过5万条时，numpy暴力检索的延迟会超过500ms，这时候就需要考虑上专门的向量数据库了。我的建议是，先用SQLite+numpy快速验证，等数据量真的上来了再迁移到Qdrant或Milvus，不要过早优化。

6. 几个我踩过的坑和对应的解法

第一个坑是embedding模型的热加载。最开始每次检索都重新加载模型，导致第一次检索要等好几秒。后来改成服务启动时加载一次，全局复用，检索延迟直接降到毫秒级。这个改动很简单，但效果立竿见影。

第二个坑是时间戳的时区问题。我用datetime.utcnow()存UTC时间，但检索时用本地时间比较，导致时间衰减计算错误。统一用UTC之后问题解决。建议所有时间戳都存UTC，展示的时候再转本地时区。

第三个坑是记忆内容的截断。有些记忆条目特别长（比如一整段代码），存进去之后检索出来占满了context window。后来加了长度限制，超过500字符的内容自动摘要后再存储，原始内容存到metadata里备查。

第四个坑是MCP Server的重启丢数据。最开始向量存在内存里，容器一重启就没了。改成持久化到磁盘后解决。SQLite的数据文件挂载到宿主机，向量用numpy的save/load存成.npy文件，重启后自动加载。

第五个坑是并发写入的竞态条件。两个请求同时写同一条记忆的access_count，导致计数丢失。加了个简单的线程锁之后解决。Python的GIL在IO密集型场景下保护有限，涉及共享状态的地方该加锁就得加锁。

这套记忆服务我跑了大概三个月，累计存储了上万条记忆记录，检索准确率稳定在90%以上。最大的体会是：Agent Memory不是越复杂越好，关键是找到适合当前场景的粒度。一开始就上全套的语义提炼、自动归档、多级缓存，反而容易出bug。先用最简单的方案跑通，遇到问题再逐步加机制，这样每一步的收益和代价都清清楚楚。