1. 从“hindsight”这个词说起为什么它值得单独拿出来聊第一次看到“hindsight”作为项目名我脑子里蹦出来的不是技术而是一句老话——事后诸葛亮。但恰恰是这个“事后”的视角在 LLM 和 Agent 的语境里价值被严重低估了。我们平时做 Agent注意力几乎全放在“当下这一步怎么决策”“下一步调哪个工具”“上下文窗口还够不够”很少有人认真对待一件事Agent 做完一件事之后回头看的那一眼到底该看什么、该怎么存、该怎么用。“hindsight”这个项目名本质上指向的就是 Agent 的事后记忆与复盘机制。它不是一个具体的框架名也不是某个大厂的产品代号而是一个概念性的项目方向——围绕 Agent 的长期记忆、工作记忆、经验回放和决策追溯来构建一套可落地的存储与检索体系。结合热词里反复出现的 agent memory、working memory、MCP、Docker、LLM 这些词可以很清楚地判断这个项目要解决的是Agent 在运行过程中“记不住、想不起、复盘难”的核心痛点。我接触过不少做 Agent 的团队大家一开始都觉得自己不需要记忆系统。理由很统一上下文窗口都 128K 了甚至 1M 了把历史全塞进去不就行了但真跑起来就会发现长上下文不等于有效记忆。你把 200 轮对话全塞进去模型该忘的还是忘该混淆的还是混淆而且 token 成本线性上涨延迟也跟着涨。更关键的是Agent 需要的不是“所有历史”而是“在正确的时间想起正确的事”。这就是 hindsight 要解决的问题域。这篇文章适合三类人看第一类是在做 Agent 产品、被记忆问题折磨过的开发者第二类是对 MCP 协议、Docker 部署、LLM 应用架构感兴趣想找一个完整案例来练手的技术人第三类是对“Agent 存储”“working memory”这些概念还比较模糊想搞清楚它们到底怎么落地的人。我会从概念拆解讲到架构设计再讲到 Docker 环境下的实操部署最后分享几个我踩过的坑。内容会比较长但都是能直接抄作业的东西。2. hindsight 到底在解决什么问题Agent 记忆的三层结构2.1 为什么“全塞进上下文”是一条死路先把这个误区说透。很多人对 Agent 记忆的理解停留在“把对话历史存下来下次拼进 prompt”。这个做法在 demo 阶段没问题一旦上生产就会暴露三个致命问题。第一个问题是信噪比崩塌。Agent 跑了 50 轮之后历史里 90% 的内容是无关的寒暄、重复的确认、失败的尝试。这些内容全塞进去模型注意力被稀释真正关键的决策依据反而被淹没。我实测过一个客服 Agent历史超过 30 轮之后回答准确率从 85% 掉到 60% 出头原因就是噪声太多。第二个问题是成本不可控。按 GPT-4 级别的模型算128K 上下文的单次调用成本是 8K 上下文的十几倍。如果每轮都带全量历史一个日活几千的 Agent 产品光 token 成本就能把预算烧穿。而且长上下文的推理延迟明显更高用户体验直接受影响。第三个问题是结构缺失。对话历史是线性的、扁平的但 Agent 真正需要的是结构化的经验——什么条件下做了什么决策、结果如何、下次遇到类似情况该不该复用。这些信息在原始对话里是隐含的不经过抽取和结构化存了也白存。所以 hindsight 的核心思路不是“存更多”而是“存得更聪明”。它把 Agent 记忆拆成三层每层职责不同、存储方式不同、检索策略也不同。2.2 三层记忆的分工working memory、episodic memory、semantic memory这三层不是我想出来的是认知科学里对人类记忆的经典划分被搬到 Agent 领域后意外地好用。Working memory工作记忆对应的是 Agent 当前任务上下文。它容量小、生命周期短、读写频繁。比如用户正在问一个多步骤问题Agent 需要记住“上一步查了什么”“当前进行到哪一步”。这层记忆通常放在内存里用 Redis 或者进程内缓存就够了不需要持久化。热词里出现的“agent 存储 working memory”说的就是这一层的工程实现。Episodic memory情景记忆对应的是 Agent 的历史经历。每一次任务执行、每一次工具调用、每一次成功或失败都是一条情景记录。这层记忆需要持久化通常存到关系库或向量库里。它的价值在于“回放”——当 Agent 遇到类似场景时可以检索出过去是怎么处理的。hindsight 这个名字很大程度上就是为这层记忆服务的。Semantic memory语义记忆对应的是 Agent 沉淀下来的知识和规则。比如“用户偏好用中文回复”“这个 API 的 rate limit 是每分钟 60 次”“遇到退款请求要先验证订单状态”。这些是从大量情景中抽象出来的稳定知识更新频率低但检索频率高。这层通常用向量库加结构化标签来存。三层之间的关系是working memory 支撑当前决策episodic memory 提供案例参考semantic memory 提供规则约束。一个成熟的 Agent 记忆系统三层缺一不可。很多项目只做了 working memory所以 Agent 表现得像个“金鱼”有些项目只做了 semantic memoryAgent 又显得死板不会从新经历里学习。2.3 hindsight 的差异化把“事后复盘”做成一等公民大部分记忆系统是“写入优先”——先把东西存进去需要的时候再检索。hindsight 的思路有点不一样它把事后复盘post-hoc reflection作为记忆写入的前置步骤。具体来说一个任务结束后hindsight 不会直接把原始对话存进去而是先跑一轮复盘这次任务的目标是什么、实际结果如何、哪些步骤是有效的、哪些是绕弯路的、有没有可复用的模式。复盘产出的结构化摘要才是真正写入 episodic memory 的内容。原始对话可以保留作为审计日志但不参与日常检索。这个设计的好处非常明显。第一存储的信噪比大幅提升检索时命中有效经验的概率更高。第二复盘过程本身可以调用 LLM 来做相当于让模型“想一想刚才发生了什么”这比单纯存原始文本有价值得多。第三复盘产出的模式可以直接晋升为 semantic memory实现从经验到知识的沉淀。我自己的体会是没有复盘的记忆系统本质上只是一个日志系统。日志谁都会存但能从日志里提炼出可复用经验的才是真正的记忆。hindsight 把复盘做成一等公民这是它和普通方案最大的区别。3. 支撑 hindsight 落地的技术底座MCP、Docker 与 LLM 的配合3.1 MCP 在这里扮演什么角色记忆能力的标准化接口热词里 MCP 出现频率极高很多人搞不清楚它到底是什么。简单说MCP 是一套让 LLM 应用和外部能力对接的软件协议不是硬件协议。你可以把它理解成“AI 应用世界的 USB 接口标准”——以前每个工具都要写一套对接代码现在只要实现 MCP 协议就能被任何支持 MCP 的客户端调用。在 hindsight 的架构里MCP 的价值在于把记忆能力做成一个标准化的服务。Agent 不需要在自身代码里硬编码记忆逻辑而是通过 MCP 协议去调用一个独立的记忆服务。这个服务负责 working memory 的读写、episodic memory 的检索、semantic memory 的更新。Agent 只管用不管实现。这样做的好处是解耦。记忆服务的存储选型、检索算法、复盘策略都可以独立迭代不影响 Agent 主体。而且同一个记忆服务可以被多个 Agent 共享实现跨 Agent 的经验复用。我在实际项目里试过这种架构当你有三四个 Agent 在跑不同任务时共享记忆带来的效果提升非常明显——A Agent 踩过的坑B Agent 通过检索就能避开。MCP 的另一个好处是工具生态。热词里提到的 browser use MCP、playwright MCP、figma MCP、蓝湖 MCP都是把不同能力封装成 MCP 服务的例子。hindsight 作为记忆服务也可以和这些工具 MCP 协同工作——比如 Agent 通过 browser MCP 抓取网页抓取结果经过复盘后写入记忆下次遇到类似网页就能直接调用经验。3.2 Docker 部署为什么记忆服务必须容器化记忆服务看起来只是个存数据的东西为什么非要上 Docker我一开始也觉得没必要直接跑个进程不就行了。但真到了多环境部署的时候问题就来了。首先是依赖隔离。记忆服务通常要同时用到向量库比如 Milvus、Qdrant、关系库比如 PostgreSQL、MySQL、缓存Redis。这些组件的版本、配置、端口很容易和宿主机上已有的服务冲突。用 Docker 把它们各自封在容器里端口映射清楚互不干扰。热词里“docker 网络不通”“docker 安装 mysql 失败”这类问题本质上都是环境冲突导致的容器化能规避掉大部分。其次是一键复现。用 docker compose 把记忆服务、向量库、关系库、缓存编排在一起一条命令就能拉起完整环境。新人入职、换机器、部署到测试环境都是同一套配置不会出现“在我机器上能跑”的尴尬。热词里“docker compose 安装”“docker compose”出现多次说明这已经是标准做法。最后是资源控制。记忆服务在复盘阶段会调用 LLMtoken 消耗和内存占用波动较大。用 Docker 可以给容器设置内存上限和 CPU 配额避免记忆服务把宿主机资源吃光影响其他服务。下面是我实际用的一套 docker compose 配置把记忆服务的核心组件都编排进去了。注意这里用的是 PostgreSQL 加 pgvector 扩展来做向量存储比单独部署一个向量库更轻量适合中小规模场景。version: 3.8 services: hindsight-db: image: pgvector/pgvector:pg16 container_name: hindsight-db environment: POSTGRES_USER: hindsight POSTGRES_PASSWORD: hindsight_pass POSTGRES_DB: hindsight ports: - 5433:5432 volumes: - hindsight_pgdata:/var/lib/postgresql/data healthcheck: test: [CMD-SHELL, pg_isready -U hindsight] interval: 10s timeout: 5s retries: 5 hindsight-cache: image: redis:7-alpine container_name: hindsight-cache ports: - 6380:6379 command: redis-server --maxmemory 512mb --maxmemory-policy allkeys-lru volumes: - hindsight_redis:/data hindsight-service: build: ./hindsight-service container_name: hindsight-service depends_on: hindsight-db: condition: service_healthy hindsight-cache: condition: service_started environment: DB_HOST: hindsight-db DB_PORT: 5432 DB_USER: hindsight DB_PASSWORD: hindsight_pass DB_NAME: hindsight REDIS_HOST: hindsight-cache REDIS_PORT: 6379 LLM_API_BASE: ${LLM_API_BASE} LLM_API_KEY: ${LLM_API_KEY} ports: - 8080:8080 restart: unless-stopped volumes: hindsight_pgdata: hindsight_redis:这份配置里有几个细节值得说。第一PostgreSQL 端口映射到宿主机的 5433 而不是默认的 5432就是为了避开宿主机上可能已有的 MySQL 或 PostgreSQL。第二Redis 设置了maxmemory 512mb和allkeys-lru淘汰策略因为 working memory 是短生命周期的不需要无限增长。第三hindsight-service用depends_on加condition确保数据库健康后再启动避免启动顺序问题导致的连接失败。这些都是踩过坑之后加上的。3.3 LLM 在记忆链路里的三个关键调用点hindsight 不是纯存储系统它在记忆的写入和读取链路上都要调用 LLM。具体来说有三个关键调用点每个点的 prompt 设计都不一样。第一个调用点是复盘生成。任务结束后把原始对话和工具调用记录喂给 LLM让它输出结构化的复盘摘要。这个 prompt 的核心是要求模型回答四个问题目标是什么、结果如何、关键决策点在哪、有什么可复用的模式。输出格式用 JSON方便后续解析入库。第二个调用点是记忆检索的重排。当 Agent 需要检索历史经验时先用向量相似度召回一批候选然后用 LLM 对候选做相关性重排。因为纯向量检索经常召回“字面相似但语义无关”的内容加一层 LLM 重排能显著提升准确率。这个调用点的 prompt 要给出当前任务描述和候选记忆列表让模型打分排序。第三个调用点是语义记忆的抽象。当 episodic memory 里积累了足够多的相似案例时触发一次抽象调用让 LLM 从中提炼出通用规则写入 semantic memory。这个调用频率低但价值高是 Agent “越用越聪明”的关键。这三个调用点里复盘生成是最高频的也是 token 消耗最大的。我的经验是复盘用的模型可以比主 Agent 用的模型低一档比如主 Agent 用 GPT-4 级别复盘用 GPT-3.5 级别甚至更小的开源模型效果差距不大但成本能降一个数量级。这个取舍在实际项目里非常关键。4. 从零搭一套 hindsight 记忆服务核心模块与实操步骤4.1 数据模型设计三张表撑起三层记忆记忆服务的核心是数据模型。我设计的时候尽量保持简单三张表对应三层记忆不搞过度设计。working_memory 表存当前会话的临时状态字段包括 session_id、step_index、content、created_at。这张表的数据有 TTL默认 2 小时过期由定时任务清理。用 Redis 存也行但我选择放 PostgreSQL 是为了统一查询接口减少组件数量。episodic_memory 表存复盘后的情景记录字段包括 id、task_type、goal、outcome、key_decisions、reusable_patterns、embedding、created_at。其中 embedding 是复盘摘要的向量表示用 pgvector 的 vector 类型存储建 HNSW 索引加速检索。semantic_memory 表存抽象出的规则字段包括 id、rule_type、content、confidence、source_episodes、embedding、updated_at。confidence 字段表示这条规则的置信度随着被验证次数增加而提升长期未被验证则衰减。三张表的关系是working memory 在任务结束后被复盘产出 episodic memoryepisodic memory 积累到一定数量后触发抽象产出 semantic memory检索时三层都查按相关性和置信度加权排序。建表 SQL 大概长这样CREATE EXTENSION IF NOT EXISTS vector; CREATE TABLE working_memory ( id BIGSERIAL PRIMARY KEY, session_id VARCHAR(64) NOT NULL, step_index INT NOT NULL, content TEXT NOT NULL, created_at TIMESTAMPTZ DEFAULT NOW() ); CREATE INDEX idx_wm_session ON working_memory(session_id, step_index); CREATE TABLE episodic_memory ( id BIGSERIAL PRIMARY KEY, task_type VARCHAR(64), goal TEXT, outcome TEXT, key_decisions JSONB, reusable_patterns JSONB, embedding vector(1536), created_at TIMESTAMPTZ DEFAULT NOW() ); CREATE INDEX idx_em_embedding ON episodic_memory USING hnsw (embedding vector_cosine_ops); CREATE INDEX idx_em_task_type ON episodic_memory(task_type); CREATE TABLE semantic_memory ( id BIGSERIAL PRIMARY KEY, rule_type VARCHAR(64), content TEXT NOT NULL, confidence FLOAT DEFAULT 0.5, source_episodes BIGINT[], embedding vector(1536), updated_at TIMESTAMPTZ DEFAULT NOW() ); CREATE INDEX idx_sm_embedding ON semantic_memory USING hnsw (embedding vector_cosine_ops);这里 embedding 维度设成 1536 是因为用的 OpenAI text-embedding-3-small。如果你用别的 embedding 模型维度要相应调整。HNSW 索引的构建参数默认值在数据量小于 10 万条时够用超过之后需要调m和ef_construction。4.2 复盘链路的实现从原始对话到结构化经验复盘是 hindsight 最核心的环节我把它拆成四步收集、压缩、抽取、入库。收集阶段把一次任务的完整轨迹拉出来包括用户输入、Agent 的每一步输出、工具调用参数和返回结果。这些数据在任务执行时就要埋点记录不能事后补。压缩阶段处理超长轨迹。如果一次任务跑了 100 步原始轨迹可能几万 token直接喂给 LLM 会超限。我的做法是按“决策点”切分只保留有工具调用、有状态变更、有异常的关键步骤跳过纯文本输出。这样通常能压缩到原来的 20% 到 30%。抽取阶段调用 LLM 生成结构化复盘。prompt 大致是这样的REFLECTION_PROMPT 你是一个 Agent 复盘助手。请分析以下任务轨迹输出 JSON 格式的复盘结果。 任务轨迹 {trace} 请输出以下字段 - goal: 任务的最终目标一句话 - outcome: 实际结果成功/失败/部分成功 - key_decisions: 关键决策点列表每项包含 step、decision、reason - reusable_patterns: 可复用的模式列表每项包含 condition、action、expected_result - failure_reasons: 如果失败列出原因 只输出 JSON不要有其他内容。入库阶段解析 JSON生成 embedding写入 episodic_memory。同时检查是否有相似的历史记录如果有更新 semantic_memory 的置信度。这里有个实操心得复盘 prompt 里一定要强调“只输出 JSON”。我一开始没加这句模型经常在 JSON 前后加解释文字解析就失败了。加了之后成功率从 70% 提到 95% 以上。另外解析失败要有兜底把原始输出存到一张 failed_reflections 表里方便事后排查不要直接丢弃。4.3 检索策略向量召回加 LLM 重排的两段式设计检索是记忆服务的出口直接决定 Agent 能不能“想起正确的事”。我用的是两段式向量召回加 LLM 重排。第一段向量召回把当前任务描述转成 embedding在 episodic_memory 和 semantic_memory 里各查 top 20合并去重后得到候选集。这一步追求召回率宁可多召回一些。第二段 LLM 重排把候选集和当前任务描述一起喂给 LLM让它按相关性打分并排序取 top 5 返回。prompt 设计的关键是给出明确的评分标准比如“完全匹配当前任务场景的给 5 分部分相关的给 3 分无关的给 1 分”。RERANK_PROMPT 当前任务{current_task} 候选记忆 {candidates} 请为每条候选记忆的相关性打分1-5分并说明理由。 输出 JSON 数组每项包含 id、score、reason。 只输出 JSON。这个两段式设计比纯向量检索准确率高很多。我做过对比测试纯向量检索的 top 5 命中率大概 55%加 LLM 重排后能到 80% 以上。代价是每次检索多一次 LLM 调用延迟增加 300 到 500 毫秒。对于非实时场景可以接受实时场景可以考虑用更小的模型做重排或者缓存高频查询的结果。还有一个优化点semantic_memory 的检索要加权 confidence。最终排序分数是相关性分数乘以置信度。这样高置信度的规则会优先被采用低置信度的经验则作为参考。置信度的更新规则是被检索到且任务成功加 0.05被检索到但任务失败减 0.1长期未被检索每次衰减 0.01。4.4 启动与验证确认记忆服务真的在工作环境搭好之后怎么确认记忆服务真的在干活我一般用三步验证。第一步写入验证。手动调一次复盘接口传一段模拟轨迹进去然后查数据库确认 episodic_memory 表里有新记录embedding 字段不为空。curl -X POST http://localhost:8080/reflect \ -H Content-Type: application/json \ -d { session_id: test-001, trace: [ {step: 1, action: search, input: 天气, output: 晴}, {step: 2, action: reply, input: 今天晴天, output: 已回复} ] }第二步检索验证。用一条和刚才任务相似的新任务描述去查检索接口确认能召回刚才写入的记录且排序合理。第三步端到端验证。把记忆服务接到一个真实的 Agent 上跑 20 轮对话观察 Agent 是否在后续轮次里引用了前面的经验。这个验证最直观但需要 Agent 侧配合埋点。注意验证阶段一定要用独立的测试数据库不要在生产库上做写入测试。我见过有人直接在生产库跑测试结果测试数据污染了真实记忆Agent 行为变得很奇怪排查了半天才发现是测试数据的问题。5. 实际跑起来才会遇到的坑我的踩坑记录与排查思路5.1 Docker 网络不通导致记忆服务连不上数据库这个坑我踩过两次症状是 hindsight-service 启动后一直报数据库连接超时但 hindsight-db 容器本身是健康的。第一次的原因是 compose 文件里服务名写错了。DB_HOST写的是hindsight_db下划线但 compose 里的服务名是hindsight-db连字符。Docker 内部 DNS 是按服务名解析的名字对不上就解析失败。这个错误很隐蔽因为容器都能启动只是互相连不上。第二次的原因是网络模式。我为了图方便给某个服务加了network_mode: host结果它就不在 compose 默认创建的 bridge 网络里了自然连不上其他服务。后来统一用默认网络只在端口映射上做区分问题就没了。排查这类问题的思路是先进容器内部用ping或nc测试目标服务名能不能解析、端口通不通。docker exec -it hindsight-service sh nc -zv hindsight-db 5432如果解析失败检查服务名拼写和网络配置如果解析成功但端口不通检查目标服务是否真的在监听、防火墙有没有拦。5.2 复盘 LLM 调用超时拖垮整个任务链路复盘是异步的理论上不该影响主任务。但我一开始把复盘做成了同步调用任务结束后必须等复盘完成才返回。结果 LLM 偶尔抽风一次调用要 30 秒整个任务链路就被拖住了。改成异步之后又遇到新问题异步任务堆积。任务高峰期复盘请求排队内存里堆了几千个待处理任务最后 OOM 了。最终的方案是异步加队列加限流。复盘请求先写入 Redis 队列后台 worker 按固定并发消费并发数根据 LLM 的 rate limit 设置。队列长度超过阈值时直接丢弃最老的请求因为复盘不是关键路径丢一些不影响主流程。import redis import json r redis.Redis(hosthindsight-cache, port6379) def enqueue_reflection(session_id, trace): if r.llen(reflection_queue) 5000: r.lpop(reflection_queue) r.rpush(reflection_queue, json.dumps({ session_id: session_id, trace: trace }))这个限流阈值 5000 是拍脑袋定的实际要根据 worker 消费速度和内存情况调整。我的经验是队列长度控制在 worker 一分钟能消费完的量比较合适。5.3 向量检索召回了一堆“看起来像但其实没用”的记忆这个问题困扰了我挺久。Agent 检索历史经验时经常召回一些字面相似但场景完全不同的记录导致 Agent 被误导。举个例子用户问“帮我查一下订单状态”检索召回了一条“帮我查一下物流状态”的记录。字面上很像但订单状态查的是订单系统物流状态查的是物流系统工具调用完全不同。Agent 如果照搬物流那条的经验就会调错工具。根因是纯向量相似度只看语义距离不看场景约束。解决办法是在 embedding 之外加上结构化过滤。每条 episodic memory 入库时打上 task_type 标签检索时先按 task_type 过滤再做向量召回。这样“订单查询”和“物流查询”虽然语义相近但 task_type 不同就不会互相干扰。task_type 的生成可以在复盘阶段让 LLM 一起输出不用额外调用。我在复盘 prompt 里加了一个字段task_type让模型从预定义的枚举里选效果比事后分类好。5.4 记忆置信度只升不降导致错误规则长期霸占检索结果semantic_memory 的置信度机制我一开始只做了正向更新——被验证就加分。结果跑了一个月后发现早期因为数据少而误判的几条规则置信度被刷得很高一直霸占检索结果新积累的正确经验反而排不上来。修复方案是引入时间衰减和负向反馈。时间衰减前面提过长期未被检索的规则定期降分。负向反馈是如果一条规则被检索到但任务最终失败了这条规则的置信度要扣分。扣分幅度比加分大因为一次失败比一次成功的信息量更大。调整之后错误规则的置信度会在几周内自然衰减下去正确规则逐渐上位。这个机制让记忆系统有了“自我纠错”的能力不需要人工干预。提示置信度的初始值不要设太高我设的是 0.5。新规则从 0.5 开始被验证几次后才升到 0.8 以上。这样能避免新规则一上来就压过老规则给系统一个观察期。6. 记忆系统上线后的调优方向几个我验证过有效的思路6.1 复盘粒度按任务切还是按会话切复盘粒度直接影响记忆质量。按会话切一次复盘覆盖整个对话粒度粗但上下文完整。按任务切每个子任务单独复盘粒度细但可能丢失任务间的关联。我两种都试过最终选择混合策略会话结束时做一次整体复盘产出高层经验会话中的关键子任务单独复盘产出细粒度模式。两者都写入 episodic_memory但用不同的 task_type 区分。检索时根据当前任务的复杂度决定查哪一层——简单任务查细粒度复杂任务查高层经验。这个策略的代价是复盘调用次数增加token 成本上升。我的取舍是只对“有工具调用”的子任务做细粒度复盘纯对话的子任务跳过。这样能过滤掉大部分低价值复盘。6.2 记忆的冷热分离高频记忆放缓存episodic_memory 和 semantic_memory 都存在 PostgreSQL 里每次检索都要查库QPS 高了之后数据库压力不小。我加了一层 Redis 缓存把高频检索的记忆缓存起来TTL 设 10 分钟。缓存的 key 是任务描述的 embedding 哈希value 是检索结果。这样相似的任务描述会命中同一个缓存命中率还不错。实测下来缓存命中率在 40% 左右数据库查询量降了一半多。冷热分离的另一个维度是记忆本身。超过 90 天未被检索的 episodic memory可以归档到冷存储不参与日常检索只在需要深度回溯时才查。这个策略能控制主表的大小保持检索性能。6.3 多 Agent 共享记忆时的隔离与复用当多个 Agent 共享一套记忆服务时隔离和复用的平衡很关键。全隔离的话Agent 之间学不到彼此的经验全共享的话不同领域的记忆会互相干扰。我的做法是按 domain 分区跨 domain 只共享 semantic memory。每个 Agent 有自己的 domain 标签episodic memory 按 domain 隔离检索时只查本 domain 的记录。semantic memory 则全局共享因为抽象出的规则通常具有跨领域通用性。这个设计在实操中效果不错。比如客服 Agent 和运维 Agent 共享一套 semantic memory客服学到的“用户情绪激动时先安抚”这条规则运维 Agent 在处理告警时也能用上。但客服的具体案例不会干扰运维的检索。6.4 记忆系统的监控指标怎么知道它有没有在变好记忆系统不像普通服务没有明显的成功失败信号。我定义了四个指标来监控它的健康度。检索命中率检索返回的结果中被 Agent 实际采用的比例。这个指标低说明检索质量差。复盘成功率复盘 LLM 调用成功并正确解析的比例。低于 90% 要检查 prompt 或模型。记忆增长率episodic memory 每天新增条数。突然暴涨可能是复盘逻辑出问题突然归零可能是写入链路断了。置信度分布semantic memory 的置信度直方图。健康的分布应该是中间高两边低如果大量规则挤在高分区说明衰减机制没生效。这四个指标我接了个简单的 Grafana 面板每天扫一眼有异常再深入排查。监控这东西平时觉得多余出问题的时候能省大量排查时间。7. 关于 hindsight 这类项目我个人的几点体会做记忆系统这一年多最大的感受是记忆的价值不在于存了多少而在于能不能在正确的时刻被正确地想起。很多团队把精力花在存储扩容上却忽略了检索质量和复盘深度结果记忆库越来越大Agent 却越来越笨。另一个体会是记忆系统一定要有“遗忘”能力。不会遗忘的系统最终会被噪声淹没。时间衰减、置信度衰减、冷热分离本质上都是在做有策略的遗忘。这一点和人类记忆很像——记住所有细节的人往往什么都想不起来。最后说个实操层面的建议如果你刚开始做 Agent 记忆不要一上来就搞三层架构。先用最简单的方案——把复盘摘要存到一张表里检索时用向量查——跑通闭环验证价值。等确认记忆确实能提升 Agent 表现之后再逐步加 working memory、semantic memory、置信度机制这些。我见过太多项目架构设计得很漂亮但从来没跑通过完整闭环最后不了了之。先跑起来再优化这个顺序不能反。