Hindsight 深度解析：Agent 记忆的工程化实践与 MCP、Docker 落地

1. 从“hindsight”这个词说起：为什么它值得单独拿出来聊

第一次看到“hindsight”作为项目名，我脑子里蹦出来的不是词典释义，而是一个很具体的场景：你让一个 agent 帮你处理一个跨天的任务，它今天信誓旦旦地说“我已经记住了你的偏好”，结果第二天你换个会话再问，它一脸茫然，仿佛昨天那个它从来没存在过。这种“事后才明白当时该记什么”的尴尬，恰恰就是 hindsight 这个词的题眼——后见之明。

在 LLM 和 agent 的语境里，hindsight 不是一个抽象概念，它指向一个非常硬核的工程问题：agent 的记忆到底该怎么存、怎么取、怎么在事后被重新利用。热词里出现了 agent memory、working memory、MCP、Docker、LLM wiki 知识库、RAG、GraphRAG、本体 RAG 这一串词，它们其实都在围绕同一件事打转——让模型在“当下”能拿到“过去”该拿到的信息，并且在“未来”能回头审视“过去”做过的决策。

这篇内容适合谁看？如果你正在做 agent 应用，被“记忆丢失”“上下文爆炸”“检索不准”折磨过，或者你只是好奇 MCP 协议和 Docker 在 agent 记忆体系里到底扮演什么角色，那这篇就是写给你的。我会把 hindsight 这个标题背后的核心领域、潜在需求、技术点和落地场景一层层拆开，尽量说人话，也尽量给能直接抄的配置和思路。

需要先说明一点：输入里项目正文和关键词都是空的，所以下面的内容是基于标题“hindsight”加上热词网络（agent memory、MCP、Docker、LLM wiki、RAG/GraphRAG 等）做的合理演绎和工程补全。我会明确区分哪些是通用实践、哪些是我个人的经验判断，不会把推测包装成事实。

2. hindsight 到底在解决 agent 记忆的哪个痛点

2.1 三种记忆的边界：working memory、episodic memory、semantic memory

聊 agent 记忆，绕不开一个基本分类。很多人一上来就说“我要给 agent 加记忆”，但没想清楚加的是哪一种，结果就是存了一堆没用的东西，检索时全是噪声。

• working memory（工作记忆）：当前会话或当前任务链里临时用到的信息。比如用户刚说的“用 Python 写”，这个偏好只需要在本次任务里生效。它的生命周期短，容量小，通常直接塞在上下文窗口里。
• episodic memory（情景记忆）：具体发生过的事件。比如“上周三用户让我把报告导出成 PDF，并且要求页边距 2cm”。它带时间戳、带情境，是“我做过什么”的记录。
• semantic memory（语义记忆）：从多次事件里沉淀出来的稳定知识。比如“这个用户偏好简洁的代码风格，不喜欢过度注释”。它是“我知道什么”的抽象。

hindsight 的价值，恰恰在于它天然偏向episodic 和 semantic 的交叉地带。因为“后见之明”意味着：事情已经发生了，你现在回头看，才知道当时哪个信息是关键的、哪个决策是错的、哪个偏好应该被固化下来。working memory 不需要 hindsight，它本来就是即时的；真正需要 hindsight 的，是那些“当时没意识到重要，事后才发现必须记住”的东西。

我见过太多项目把这三者混在一个向量库里，结果就是检索时 working memory 的临时指令和 semantic memory 的长期偏好打架，agent 行为飘忽不定。一个务实的做法是：working memory 走上下文，episodic memory 走带时间索引的存储，semantic memory 走经过提炼的知识库。hindsight 这个项目名，暗示的正是从 episodic 向 semantic 的提炼过程——事后复盘，把情景沉淀成知识。

2.2 为什么“事后记忆”比“实时记忆”更难做

实时记忆的难点在写入，事后记忆的难点在筛选和重写。

实时记忆是你边聊边存，存进去就完了，顶多做个去重。但事后记忆要求你回答一个问题：在已经发生的一堆事件里，哪些值得被长期记住？这个问题没有标准答案，因为“值得”取决于未来的使用场景，而未来还没发生。这就是 hindsight 的悖论——你用后见之明去决定什么该记，但后见之明本身也是有限的。

工程上常见的折中方案是分层写入 + 延迟提炼。第一层，所有事件先原样落盘，保证不丢；第二层，用一个轻量的提炼任务（可以是定时任务，也可以是触发式的）把原始事件压缩成摘要或结构化条目；第三层，把提炼后的条目和已有的 semantic memory 做合并、冲突检测、去重。这个过程里，LLM 负责“读懂”事件，规则负责“约束”格式，存储负责“兜底”不丢数据。

热词里出现的 “a-memguard: a proactive defense framework for llm-based agent memory” 其实点出了另一个维度：记忆不仅要存得对，还要防得住。事后记忆如果被污染，比如有人往记忆库里注入一条“用户允许删除所有文件”，那后果比实时记忆被污染更严重，因为它会被长期信任。所以 hindsight 类系统在设计时，写入路径上的校验和来源标记是必须的，不能等出事再补。

2.3 一个具体的失败案例：记忆没丢，但取错了

我拿一个真实遇到过的场景来说明。有个做客服 agent 的项目，记忆库用的是向量检索。用户 A 之前问过“退款要多久”，agent 回答“3-5 个工作日”。一周后用户 A 又问“退款进度”，agent 检索到了那条旧记忆，直接回“3-5 个工作日”，但用户其实是在问“我上周提交的那笔退款现在到哪一步了”。

记忆没丢，但取错了。问题出在：旧记忆是semantic 层面的通用规则，新问题是episodic 层面的具体事件，两者被同一个检索器混在一起，相似度还很高。hindsight 的思路在这里就很有用——如果系统在写入时给每条记忆打上类型标签（规则/事件/偏好），检索时先按类型过滤再算相似度，这个错误就能避免。

这也解释了为什么热词里同时出现了 RAG、GraphRAG、本体 RAG。纯向量 RAG 擅长“找相似”，但不擅长“找对类型”“找对时间”“找对关系”。GraphRAG 和本体 RAG 的价值，就是把实体、关系、时间这些结构化维度补进来，让检索从“像不像”升级到“是不是该它”。

3. MCP 在 hindsight 体系里扮演什么角色

3.1 MCP 不是记忆本身，而是记忆的“插座”

热词里 MCP 出现频率极高，还有 “mcp是什么”“mcp 是软件协议 硬件协议那个概念叫什么来着” 这种很真实的疑问。先把概念说清楚：MCP（Model Context Protocol）是一套让模型和外部工具/数据源对话的协议。你可以把它理解成 USB-C——它不生产数据，它只是让模型能方便地插上各种“外设”：文件系统、数据库、浏览器、代码执行环境等等。

在 hindsight 的语境里，MCP 的角色是记忆的接入层。记忆存在哪里？可能是一个向量库、一个关系库、一个文件目录、甚至一个 wiki。模型怎么访问这些记忆？通过 MCP server 暴露出来的工具。比如一个 memory MCP server 可以提供store_memory、recall_memory、list_memories这几个工具，模型在需要的时候调用它们。

这样做的好处是解耦。记忆的存储实现可以换，从本地 SQLite 换成远程 Postgres，只要 MCP 接口不变，agent 侧不用改。反过来，agent 框架可以换，从 A 框架换到 B 框架，只要它还支持 MCP，记忆层不用动。热词里 “agent mcp”“playwright mcp”“burpsuite mcp”“blender mcp”“unity mcp” 这些，本质上都是不同领域把自家能力包装成 MCP server，让模型能统一调用。

3.2 用 MCP 暴露记忆工具的接口设计

如果你要自己写一个 hindsight 风格的 memory MCP server，接口设计有几个坑要避开。

第一，写入和读取要分离。store_memory负责写入，recall_memory负责检索，不要用一个memory工具既写又读，否则模型很容易在检索时误触发写入。

第二，检索参数要显式。不要只给一个 query 字符串，至少要有query、memory_type（episodic/semantic/working）、time_range、top_k。模型不是人，你不给它类型过滤的选项，它就会把所有记忆混在一起搜。

第三，返回结果要带元数据。每条记忆返回时带上id、created_at、source、confidence。这样模型在引用记忆时能说“根据 3 月 5 日的一条记录”，而不是含糊地说“我记得”。可追溯性对 hindsight 尤其重要，因为事后复盘的前提是知道“当时到底记了什么”。

一个简化的工具定义大概长这样（伪代码，具体语言看你的 MCP SDK）：

{ "name": "recall_memory", "description": "检索 agent 的长期记忆", "inputSchema": { "type": "object", "properties": { "query": { "type": "string" }, "memory_type": { "type": "string", "enum": ["episodic", "semantic", "working"] }, "time_range": { "type": "string", "description": "如 7d, 30d, all" }, "top_k": { "type": "integer", "default": 5 } }, "required": ["query"] } }

提示：MCP 工具的 description 字段非常关键，模型是靠它来决定什么时候调用哪个工具的。description 写得含糊，模型就会乱调。宁可啰嗦，也要把“什么时候用我”说清楚。

3.3 MCP 连接失败时，先查这三处

热词里有 “llm request failed: provider rejected the request schema or tool payload.” 和 “谷歌浏览器扩展设置中启用「mcp 连接」” 这类很具体的报错和操作。MCP 连接问题我踩过的坑，基本集中在三个地方。

第一，schema 不匹配。MCP server 声明的 inputSchema 和模型实际发过来的 payload 对不上，provider 就会拒绝。常见原因是可选字段被当成必填，或者类型写错（比如top_k声明成 string，模型传了 number）。排查方法：把 server 日志打到 debug 级别，看它收到的原始 payload 长什么样。

第二，传输层没通。MCP 支持多种传输方式，本地进程用 stdio，远程用 HTTP/SSE 之类。如果是远程，先确认地址和端口可达；如果是本地，确认进程真的起来了，而不是启动脚本报错后静默退出。热词里 “wss://api.xiaozhi.me/mcp/?token=...” 这种带 token 的地址，还要确认 token 没过期、没被截断。

第三，权限和路径。文件系统类的 MCP server 经常因为工作目录不对，导致读不到该读的文件。Docker 里跑 MCP server 时尤其容易出这个问题，因为容器内的路径和宿主机不一样。解决办法是把记忆目录显式挂载进去，并且在 server 配置里用绝对路径。

4. Docker 把 hindsight 记忆服务跑起来：从安装到排错

4.1 为什么记忆服务值得用 Docker 跑

记忆服务有几个特点：它要长期运行、它要持久化数据、它可能被多个 agent 共享、它的依赖可能比较重（向量库、图数据库、嵌入模型）。这四点加起来，Docker 几乎是自然选择。

用 Docker 跑的好处很直接：环境隔离，不会因为宿主机 Python 版本或系统库版本把服务搞崩；数据用 volume 挂出来，容器删了记忆还在；多个 agent 连同一个容器，记忆天然共享；迁移的时候把镜像和 volume 一搬就走。

热词里 “docker安装”“docker desktop安装教程”“windows安装docker”“linux安装docker”“启动docker” 这些搜索量很高，说明很多人卡在第一步。我下面按 Windows 和 Linux 分别说，重点讲那些教程里不常提但实际会卡住的点。

4.2 Windows 上装 Docker Desktop 最容易卡在哪

Windows 装 Docker Desktop，最常见的拦路虎是虚拟化。热词里 “virtualization support not detected docker desktop failed to start because v...” 这个报错，基本就是虚拟化没开或者被占用了。

排查顺序是这样的：

1. 确认 CPU 虚拟化在 BIOS/UEFI 里开了。任务管理器 -> 性能 -> CPU，看“虚拟化”是不是“已启用”。没启用就进 BIOS 开，不同主板按键不同，常见的是 Del、F2、F10。
2. 确认没有其他虚拟化软件抢占。Hyper-V、WSL2、某些安卓模拟器、部分安全软件会占用虚拟化能力。如果开了 Hyper-V，Docker Desktop 一般走 WSL2 后端，这时候要确认 WSL2 装好了：wsl --install，然后wsl --set-default-version 2。
3. 确认 Docker Desktop 用的是 WSL2 后端。设置 -> General -> Use the WSL 2 based engine，勾上。如果只能用 Hyper-V 后端，那 Hyper-V 功能得在“启用或关闭 Windows 功能”里打开。
4. 重启。改完虚拟化相关设置，不重启经常不生效，别问，问就是重启。

装好之后，验证一下：

docker --version docker run hello-world

hello-world能跑通，说明 Docker 引擎和镜像拉取都正常。如果卡在拉取，检查网络和镜像源配置。

4.3 Linux 上装 Docker 的干净流程

Linux 上我倾向于用官方脚本或包管理器，别用那些来路不明的“一键脚本”。

Ubuntu/Debian 系：

sudo apt-get update sudo apt-get install -y ca-certificates curl gnupg 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 a+r /etc/apt/keyrings/docker.gpg 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 sudo apt-get update sudo apt-get install -y docker-ce docker-ce-cli containerd.io docker-compose-plugin

装完把当前用户加进 docker 组，省得每次 sudo：

sudo usermod -aG docker $USER newgrp docker

然后docker run hello-world验证。如果报权限错误，多半是组没生效，退出重新登录一次。

4.4 用 Docker Compose 编排记忆服务

一个 hindsight 风格的记忆服务，通常至少包含：记忆存储（向量库或图库）、嵌入服务、MCP server。用 Compose 编排最省心。

version: "3.9" services: memory-store: image: qdrant/qdrant:latest ports: - "6333:6333" volumes: - ./data/qdrant:/qdrant/storage restart: unless-stopped memory-mcp: build: ./memory-mcp depends_on: - memory-store environment: - STORE_URL=http://memory-store:6333 - MEMORY_DIR=/data/memories volumes: - ./data/memories:/data/memories ports: - "8080:8080" restart: unless-stopped

几个关键点：volumes一定要挂，不然容器一删记忆全没；depends_on只保证启动顺序，不保证服务就绪，MCP server 里最好加个重试逻辑；restart: unless-stopped让服务在宿主机重启后自动起来，记忆服务断断续续的体验很差。

4.5 Docker 网络不通的排查链路

热词里 “docker网络不通” 是个高频问题。容器之间连不上，按这个顺序查：

最省事的做法是让 Compose 自动创建网络，服务名就是主机名。上面例子里memory-mcp直接用http://memory-store:6333就能连上，不用管 IP。

注意：如果你在容器里跑 MCP server，而 agent 在宿主机上跑，那 agent 连的是localhost:8080（映射出来的端口），不是容器内部的地址。这个映射关系搞混，是最常见的“网络不通”。

5. 把记忆做成 wiki：LLM wiki 知识库与本体 RAG 的落地思路

5.1 为什么“wiki”这个隐喻对 hindsight 很贴切

热词里 “llm wiki知识库”“llm wiki项目”“llm wiki 原文” 反复出现。wiki 这个隐喻用在 agent 记忆上，我觉得非常准。

wiki 的特点是：条目化、可链接、有版本、可回溯、人机都能读。这正好对应 hindsight 需要的几个能力——记忆要能被拆成条目（而不是一坨对话记录），条目之间要能建立关联（而不是孤立向量），要能知道某条记忆是什么时候写的、被谁改过（版本），要能被人审查（可读）。

纯向量库的问题是它是“黑盒相似度”，你很难向用户解释“为什么 agent 想起了这条”。wiki 式的记忆是“白盒”的：每条记忆是一个有标题、有正文、有链接、有时间的条目，检索时可以展示“我找到了这三条相关记忆”，用户能看懂，也能纠正。

5.2 从对话流到 wiki 条目的提炼流程

把原始对话变成 wiki 条目，我一般分四步：

1. 切分：按话题或任务边界把对话切成段。不要按固定 token 数硬切，那样会把一个完整决策切碎。
2. 抽取：对每段，让 LLM 抽取出“事实、偏好、决策、待办”四类信息。事实是客观信息，偏好是用户倾向，决策是已经拍板的选择，待办是还没做的事。
3. 归一：把抽取结果和已有条目比对，能合并的合并，冲突的标记出来。比如用户之前说“喜欢深色主题”，现在说“喜欢浅色主题”，这不是新增，是更新，要保留历史版本。
4. 链接：给新条目找相关的已有条目，建立双向链接。这一步是 wiki 区别于普通笔记的关键，也是 GraphRAG 发挥的地方。

这个流程里，LLM 负责 2 和 4 的语义部分，规则负责 1 和 3 的结构部分。全交给 LLM 会不稳定，全交给规则会太死板。

5.3 本体 RAG 在记忆检索里的实际作用

热词里 “llm ontology”“rag graphrag llm wiki 本体rag” 指向同一个方向：用本体（ontology）给记忆建立概念层级和关系约束。

举个具体例子。用户说“帮我订明天去上海的机票”。纯向量检索可能召回“用户喜欢靠窗座位”“用户上次去北京是出差”“用户有航空公司会员”。这些都有点相关，但没抓住重点。如果有了本体，系统知道“订机票”这个意图关联的实体是“出发地、目的地、时间、舱位、乘客”，检索时就会优先找这些维度的记忆，而不是泛泛的相似文本。

本体的构建不需要一上来就搞得很复杂。从一个小 schema 开始：实体类型（人、地点、时间、事件、偏好）、关系类型（属于、发生于、偏好于、依赖于）。随着记忆增多，再逐步扩展。关键是让本体服务于检索，而不是为了本体而本体。我见过为了追求“知识图谱完整性”把本体搞得巨大，结果检索时根本用不上，维护成本还高。

5.4 记忆冲突检测：hindsight 最容易被忽略的一环

事后记忆最大的风险不是“记不住”，而是“记错了还一直用”。冲突检测要覆盖几种情况：

• 直接矛盾：新记忆和旧记忆在同一个事实上说法相反。比如“用户邮箱是 A”和“用户邮箱是 B”。
• 时间失效：旧记忆曾经正确，但已经过期。比如“用户当前项目是 X”，但项目已经结束了。
• 来源可信度差异：用户亲口说的，和 agent 自己推断的，可信度不一样。推断出来的记忆不应该覆盖用户明确说过的。

处理策略上，我倾向于不删除旧记忆，而是标记状态。旧记忆标记为superseded，新记忆标记为active，检索时默认只取 active，但保留追溯能力。这样既避免了错误记忆被使用，又保留了“当时为什么那么记”的历史，符合 hindsight 的精神。

6. 一套可复现的 hindsight 记忆服务最小实现

6.1 目录结构和依赖

假设我们用 Python 写 MCP server，存储用 SQLite（轻量、零依赖、方便演示），嵌入先用简单的关键词匹配（生产环境换成向量模型）。目录结构：

hindsight-memory/ ├── docker-compose.yml ├── Dockerfile ├── requirements.txt ├── server.py └── data/ └── memories.db

requirements.txt：

mcp fastapi uvicorn pydantic

6.2 核心数据模型

记忆条目至少要有这些字段：

from pydantic import BaseModel from datetime import datetime from typing import Optional, List class MemoryItem(BaseModel): id: str content: str memory_type: str # episodic / semantic / working source: str # user / agent / system created_at: datetime updated_at: datetime status: str # active / superseded / archived tags: List[str] = [] links: List[str] = [] # 关联的其他记忆 id

status字段是冲突检测的关键，links字段是 wiki 化的关键。

6.3 写入路径：先落盘，再提炼

写入分两步。第一步，原始事件直接落盘，保证不丢：

def store_raw_event(content: str, source: str) -> str: item = MemoryItem( id=gen_id(), content=content, memory_type="episodic", source=source, created_at=now(), updated_at=now(), status="active", ) db.insert(item) return item.id

第二步，异步提炼。用一个后台任务，定期扫描未提炼的 episodic 记忆，调用 LLM 抽取 semantic 条目：

def refine_memories(): unrefined = db.query(memory_type="episodic", refined=False) for batch in chunk(unrefined, 10): extracted = llm_extract(batch) # 返回事实/偏好/决策/待办 for item in extracted: existing = db.find_similar(item) if existing and conflict(item, existing): db.mark_superseded(existing.id) db.insert(item) elif existing: db.merge(existing.id, item) else: db.insert(item)

提示：提炼任务不要和写入路径同步执行，否则用户每说一句话都要等 LLM 处理，体验很差。异步 + 批量是更稳的选择。

6.4 检索路径：类型过滤 + 时间衰减 + 链接扩展

检索不是简单的相似度排序。我的做法是三步：

1. 类型过滤：根据当前任务判断需要哪类记忆。写代码时优先 semantic（偏好、规范），查进度时优先 episodic（事件）。
2. 时间衰减：越新的记忆权重越高，但不是线性衰减。我一般用指数衰减，半衰期设 7 天左右，具体看场景。
3. 链接扩展：命中一条记忆后，把它 links 里的相关记忆也带出来，给模型更完整的上下文。

def recall(query: str, memory_type: str = None, top_k: int = 5): candidates = db.search(query, memory_type=memory_type, status="active") scored = [] for c in candidates: score = similarity(query, c.content) * time_decay(c.created_at) scored.append((score, c)) scored.sort(reverse=True) top = [c for _, c in scored[:top_k]] # 链接扩展 expanded = expand_by_links(top, depth=1) return expanded

6.5 用 MCP 把服务暴露出去

最后用 MCP SDK 把store_memory和recall_memory注册成工具：

from mcp.server import Server from mcp.types import Tool, TextContent app = Server("hindsight-memory") @app.list_tools() async def list_tools(): return [ Tool( name="store_memory", description="存储一条 agent 记忆。当用户表达了偏好、做出了决策、或发生了值得记住的事件时调用。", inputSchema={ "type": "object", "properties": { "content": {"type": "string"}, "memory_type": {"type": "string", "enum": ["episodic", "semantic", "working"]}, "source": {"type": "string"}, }, "required": ["content", "memory_type"], }, ), Tool( name="recall_memory", description="检索 agent 记忆。在回答需要历史信息的问题前调用。", inputSchema={ "type": "object", "properties": { "query": {"type": "string"}, "memory_type": {"type": "string"}, "top_k": {"type": "integer", "default": 5}, }, "required": ["query"], }, ), ]

跑起来之后，agent 侧配置 MCP server 地址，就能通过标准协议读写记忆了。

7. 上线之后才会暴露的几个问题

7.1 记忆膨胀：存得越多，检索越差

这是最普遍的问题。一开始觉得“多存点总没坏处”，跑一个月发现记忆库几万条，检索出来的全是噪声。根因是写入没有门槛。

我的做法是给写入加一个“重要性评分”。评分维度包括：是否包含用户明确偏好、是否涉及决策、是否被重复提及、是否与已有记忆冲突。低于阈值的只存原始日志，不进 semantic 层。这样 semantic 层始终保持在可控规模，检索质量才稳。

7.2 检索延迟：别让记忆拖慢首字响应

记忆检索如果同步阻塞在对话主链路上，用户会明显感觉到“这个 agent 反应慢”。优化方向有两个：一是把检索做成异步预取，在用户还在输入时就提前查；二是给检索设超时，超时就返回空，让模型先答，答完再补充记忆。宁可偶尔少用一条记忆，也不要让用户等。

7.3 记忆污染：来源标记和写入校验

前面提过 a-memguard 这类思路，核心就是不信任任何未经校验的写入。具体做法：所有写入带 source 标记；来自外部内容（比如网页抓取、第三方工具返回）的记忆标记为untrusted，检索时降权或需要二次确认；涉及敏感操作的记忆（删除、转账、授权）必须有人工确认环节，不能自动生效。

7.4 多 agent 共享记忆时的隔离

如果多个 agent 共用一个记忆库，必须做命名空间隔离。否则 agent A 的用户偏好会污染 agent B。做法是在记忆条目上加namespace字段，检索时强制带上当前 agent 的 namespace。共享的通用知识可以放在一个公共 namespace 里，但要有明确的写入权限控制。

8. 我对 hindsight 这类项目的一点个人判断

做了这么多 agent 相关的项目，我越来越觉得记忆不是功能，是架构。很多团队把记忆当成一个可以后加的模块，先做对话，再做工具调用，最后才想起来加记忆，结果发现整个数据流都要重构。hindsight 这个词提醒我们的是：记忆的价值不在“存”，而在“事后能回头用”。这意味着从第一天起，写入路径、检索路径、冲突处理、来源标记就要一起设计，而不是等出了问题再打补丁。

MCP 让记忆服务的接入变简单了，Docker 让部署变简单了，但这些都只是手段。真正决定一个 agent 记忆好不好用的，是你有没有想清楚哪些信息值得记、什么时候该取、取错了怎么办。这三个问题想清楚了，用什么存储、什么协议、什么容器，都是次要的。

最后分享一个我自己的小习惯：每次给 agent 加新记忆类型之前，先手动模拟一遍“如果这条记忆是错的，最坏会发生什么”。如果答案是“用户会明显察觉并纠正”，那可以加；如果答案是“用户根本不知道，错误会一直累积”，那就先别加，或者加上强校验再说。这个习惯帮我避开了不少事后才后悔的设计。