企业官网建设流程全解析

1. 记忆问题，是 Agent 从玩具走向工具的一道坎

聊 AI Agent，聊到第三篇，终于要碰最“人格化”也最棘手的问题了——记忆。前两篇我拆过 Agent 的任务规划，也聊过工具调用的工程实现，但很多朋友做完 demo 之后都会撞上同一堵墙：Agent 每次对话都像一个“初次见面”的新朋友，你说过的话、做过的选择、踩过的坑，它转头就忘。这用户体验，怎么说呢，像你养了个金鱼。

其实不怪大模型，大模型的上下文窗口再长，也有极限，而且每次请求结束后状态就归零了。Agent 要真正“记住你”，不是靠模型本身的“灵光一现”，而是要靠在外面搭一套“记忆系统”。这一篇我就用自己实际调过的方案，把 Agent 记忆这件事彻底讲清楚：记忆分哪几层、每层怎么存、怎么取、怎么更新，以及最关键的——怎么让记忆不被乱七八糟的旧信息污染，越用越聪明而不是越用越糊涂。

这篇内容适合三类人：一类是已经搭过 Agent 但觉得“不够聪明”的开发者；一类是准备做 AI 原生产品、想设计“用户越用越懂你”功能的产品经理；还有一类是纯粹好奇“AI 怎么记住我”的技术爱好者。我会结合 LangGraph、向量数据库、MCP 协议这些实际工程组件来讲，也会附上我踩过的坑和排查思路，直接可参考。

在动手之前，先记住一句话：Agent 的“记忆”，本质上是把人的记忆机制——感官记忆、短期工作记忆、长期叙事记忆——用工程手段模拟出来。理解了这个模型，后面所有代码和配置都顺理成章。

2. 先拆解：Agent 的“记忆”到底分几种

2.1 三种记忆的分工，比你想的更接近人脑

我在跟很多朋友聊记忆设计时，发现大家一上来就想上向量数据库，觉得“把历史对话存进去、语义检索出来”就完事了。但这样做出来的东西，短期看着能用，长期一定会出乱子。原因是记忆不是单一的东西，它至少分三层：

第一层是瞬时记忆，也叫工作记忆。它对应大模型的上下文窗口，就是在当前对话轮次里，模型能直接看到的信息。这一层的特点是快，但容量有限，而且对话一结束就没了。在工程上，这一层主要靠精心设计 Prompt 结构和滑动窗口来管理。

第二层是短期记忆，对应“这次会话内需要记住的东西”。比如用户在一个多小时的多轮交互里反复提到自己的偏好、临时给了你一些任务约束、中途纠正过你的一些错误判断。这些信息不需要永久保存，但在当前这轮会话中必须能被随时取用。工程实现上通常存在会话级别的 Redis 或者内存里，配合摘要机制来控制体积。

第三层是长期记忆，对应“跨会话的、属于这个用户的稳定画像”。比如用户是前端工程师、喜欢简洁代码风格、讨厌冗长解释、之前已经确认过的技术选型、家庭住址、作息规律等等。这一层才是真正让 Agent “记住你”的核心，也是投入产出比最高的部分。工程上通常用向量数据库加结构化存储配合实现。

这三层不是互相替代的关系，而是层层过滤、逐级沉淀的关系。瞬时记忆负责“当下反应”，短期记忆负责“这次对话的上下文韧性”，长期记忆负责“跨时间的个性化延续”。三者合起来，才构成一个完整的记忆闭环。

2.2 只做上下文窗口，为什么一定会翻车

很多人最开始做 Agent 记忆，首选方案是把所有历史都塞进上下文窗口里。听起来挺美的，说白了大模型不是没上下文，只是窗口有上限，GPT-4 级别也就一百多 K token，更长窗口的模型价格又贵到肉疼。

而且这里有个特别隐蔽的坑：上下文过长会带来“迷失在中间”的问题。模型对长篇内容中间部分的注意力会明显下降，旧信息要么被新信息覆盖，要么被模型选择性地“忽略”。我做过实验，把五十轮对话全部塞进上下文后，模型对早期用户偏好的遗忘率相当高，检索准确度会明显打折。

更现实的问题是成本。每轮请求都把全部历史塞给模型，Token 费用按指数涨，响应延迟也跟着涨。用户其实只关心“你还记不记得我不吃香菜”，你没必要把十年前的那次点餐记录也一起背一遍。

所以，正确的做法是给 Agent 建一个外部记忆仓库，平时把记忆沉淀到仓库里，等到需要的时候，再把相关的几条记忆“唤起”并放回上下文。这个思路跟人脑的记忆提取机制其实很像——你不是把整个人生都放在脑子里随时调用，你是碰到具体场景才会想起具体的事。

2.3 记忆系统的架构，最终长这样

我跑过几版架构之后，最后沉淀下来的记忆系统分四个模块：

• 记忆写入层：从对话中提炼“值得记的信息”，判断哪些是噪音、哪些是长期信号。
• 记忆存储层：用向量数据库存语义索引，用结构化数据库存事实型信息（比如用户身份、明确设置的偏好）。
• 记忆检索层：在每轮对话开始时，根据当前用户输入和 Task 目标，把相关的记忆召回并注入 Prompt。
• 记忆更新层：负责解决“旧记忆冲突了怎么办”“记忆过期了怎么办”“哪些记忆该降权或删除”的问题。

这四个模块串起来，就是一个“记忆生命周期”的完整闭环。接下来我逐个环节讲实操。

3. 记忆的工程实现：怎么写、怎么存、怎么取

3.1 记忆写入：不是把所有对话都记下来，是提炼“值得记的事”

写入是整个记忆系统里最考验设计能力的环节。你说让 Agent 记住你，如果它把你每一句废话都记住了，那它记住的就不是“你”，而是“一串流水账”。

我用的方法是写一个 Memory Extractor，专门负责从对话里抽记忆点。它本质上是一个带结构化输出的子 Agent 调用，输入是最近几轮对话，输出是一个 JSON 数组，每一条包含entity（主体）、attribute（属性）、value（值）、memory_type（事实型/偏好型/行为习惯型）、importance（重要度）、expire_at（过期时间）这些字段。

举个例子，用户在对话里说：“我平时都骑电动车上班，大概四十分钟吧，下次帮我算出发时间的时候记得留点余量。”Memory Extractor 会把它提炼成一条记录：

• entity: user
• attribute: commute_mode
• value: e-bike / 40min / need_bufffer
• memory_type: habit
• importance: 7

这条记录会被写入记忆仓库。下次用户说“明天九点开会帮我定出发时间”，Agent 检索到“骑电动车、四十分钟”这条记忆，就会主动把出发时间定在八点前后，还会补一句“考虑到早高峰，给你多留了十分钟余量”。这个体验，用户会觉得你是真懂他。

写人的时候要特别注意过滤节奏。如果每个轮次都写，记忆库会被无关信息淹没；我的经验是，设置一个“记忆增益阈值”，只有当提炼出的记忆点重要度超过一定数值，或者在连续多轮对话中被重复提到，才写入长期记忆库。短期记忆库则放宽一点，毕竟会话内需要足够的信息冗余。

3.2 记忆存储：向量库和结构化库，各干各的活

存储层我建议用“双轨制”：向量数据库负责“语义模糊检索”，关系型数据库负责“精确事实存储”。市面上常用的向量库有 Milvus、Qdrant、pgvector 等。个人项目和中小型应用用 pgvector 就够了，直接复用 PostgreSQL 的表结构，省去多维护一套存储系统的心智负担；量级上来之后再迁 Qdrant 或 Milvus 也不迟。

向量库里存的是“语义索引”，也就是把一条条记忆用 Embedding 模型转成向量。检索的时候，用当前用户的输入做一次向量化，然后算相似度，把最相关的记忆捞回来。这个方案适合回答“用户之前有没有提到过类似的话题”这类问题。

结构化库存的是“板上钉钉的事实”，比如用户的称呼、地点、明确的偏好设置、之前确认过的决策结果。这类数据用 SQL 查更快更准，也可以直接在生成回答前做规则映射。

双轨之间不是相互孤立的。我的习惯是，向量库里每条记忆带一个memory_id，结构化表里同一条事实也引用这个 ID。这样在更新或删除时，两边可以联动，不会出现库里信息不一致的问题。

还有个值得说的细节：Embedding 模型要用跟业务领域匹配的。你用通用 Embedding 模型存医疗领域的对话记录，召回的准确率会惨不忍睹。有条件的话，拿一批业务数据做微调，或者至少做一轮领域适配评测，效果差别很明显。

3.3 记忆检索：质量全看“怎么把记忆塞回 Prompt”

检索这一步，做得不好会让整个记忆系统前功尽弃。我见过不少项目，记忆库建得很漂亮，但检索召回的东西跟当前对话毫无关系，Agent 反而被旧记忆带偏，回答得莫名其妙。

我的检索策略分两步。第一步是“粗召回”，用向量相似度取回 Top 20 条候选记忆。第二步是“精过滤”，用一个小的重排模型或规则评分模型，按“与当前任务的相关性、信息的新鲜度、重要度”三个维度排序，最后只保留 Top 3 到 5 条注入 Prompt。

这里有个容易忽视的细节：记忆注入的位置和格式。我实践下来，把记忆放在 Prompt 的“身份设定”之后、“用户输入”之前，并且用明确的标签包裹，效果最好。比如：

[用户长期记忆] - 用户通勤方式：电动车，单程约40分钟，需要预留余量 - 用户偏好：回答简洁，不喜欢长篇大论 - 用户近期目标：准备在三个月内上线一个 AI 写作工具 [当前对话] 用户：帮我规划一下这周的工作安排。

注意，记忆条目不能一股脑全塞。每轮对话注入的记忆条数要控制在合理范围内，多了会让模型信息过载，少了又发挥不了作用。另外，“强行注入无关记忆”比“没有记忆”更糟糕，这一点在下面的问题排查环节我会细说。

4. 记忆系统的进阶设计：LangGraph 里的状态管理

4.1 用 LangGraph 管理 Agent 的“记忆状态流”

说到 Agent 工程化，LangGraph 是目前绕不开的一个框架。它的核心思想是“图”，把 Agent 执行流程定义成一张状态机图，节点之间按条件跳转，状态在整张图中流转。

这套思路跟记忆系统的设计天然匹配。我之前用 LangGraph 重写过一个对话 Agent，把“记忆操作”作为图里的一个独立节点，整个过程是一个清晰的循环：接收输入 → 检索记忆 → 注入上下文 → 模型生成回复 → 提炼新记忆 → 更新记忆库 → 进入下一轮。

用 LangGraph 有个特别大的好处：你可以非常直观地看到每一步记忆的状态。哪个节点读了哪些记忆、写了哪些记忆、在哪个环节过滤掉了什么，全部可以用调试面板一条条审。比起自己手撸状态管理逻辑，不知道省了多少调试心酸。

我实现的简化版本，核心节点定义大致是这样的：

def retrieve_memory_node(state): query = state["current_user_input"] candidate = vector_store.search(query, top_k=20) filtered = rerank(candidate, query)[:5] state["relevant_memory"] = filtered return state def generate_node(state): memory_text = format_memory(state["relevant_memory"]) prompt = build_prompt( memory_text=memory_text, user_input=state["current_user_input"], task=state["task_objectives"] ) response = llm.chat(prompt) return {**state, "response": response}

这个结构出来以后，你的 Agent 记忆流就是可视化、可追踪、可干预的。想加一层“记忆冲突检测”，就在 update 节点前面插一个 compare 节点；想加“用户主动遗忘”指令，就在 retrieve 节点前面加一个 filter 节点。比起在主业务逻辑里写死一套记忆流程，图化编排的扩展性强太多了。

4.2 多 Agent 协作时，记忆要不要共享

现在不少项目已经演进到多 Agent 架构，比如 Spring AI 里的 multi-agent 模式，或者 LangGraph 里拆 Planner / Executor / Critic 多个角色的做法。这时候冒出一个问题：记忆到底是每个 Agent 各自维护，还是共享一个池子？

我的答案是：不要完全共享，要分“角色记忆”和“共享事实”两层。每个角色 Agent 有自己的短期记忆和角色偏好，比如 Executor 只需要记住执行细节和工具调用习惯，不需要关心用户的通勤方式；而共享记忆池只存跨角色的公共事实，比如用户身份、项目目标、重大决策结果。

这样设计的好处是：一方面降低记忆检索的噪音，各取所需；另一方面避免多 Agent 之间互相污染。我最早偷懒，所有 Agent 共用一套记忆，结果 Planner 被 Executor 的执行细节干扰，经常在规划环节输出过度具体的内容，后来把记忆层按角色做隔离之后，整体准确率高了一大截。

4.3 MCP 协议在记忆系统里的新玩法

聊到多 Agent 和工具链，就绕不开 MCP（Model Context Protocol）。MCP 现在基本成了 Agent 工具调用的“通用插头”，但它在记忆系统上的价值被很多人忽略了。

我现在的做法是，把记忆仓库本身封装成一个 MCP Server。这样任何 Agent，不管用什么框架，只要配置一下 MCP 客户端，就能调用同一套记忆读写能力。记忆的存储实现细节被完全隔离在 Server 内部，Agent 只需要发出read_memory、write_memory、update_memory这几个标准调用。

这样做还有个隐蔽的好处：记忆服务可以独立部署、独立扩容。Agent 实例可以开多个，但记忆服务只有一个中枢，用户不管从网页端还是小程序端进来，读到的是同一套记忆。这就解决了“换了终端、Agent 就失忆”的问题。在做跨端产品的时候，这一点几乎是刚需。

5. 记忆准确性和时效性：怎么让记忆不变成负担

5.1 冲突处理：新记忆和旧记忆打架，听谁的

记忆写到一定程度，冲突一定会出现。最典型的场景是：用户最开始告诉你“我喜欢喝美式”，三个月后跟你说“我要戒咖啡因，以后别推荐咖啡了”。如果你不做冲突处理，Agent 下次推荐饮品时，既可能推荐美式，也可能推荐别的，完全取决于哪条记忆被检索出来。

我的做法是在记忆更新层加一套“冲突消解机制”。每条记忆写入时，先按兵不动，查一下库里有没有同主体、同属性的旧记录。如果有，就进入“新旧对决”逻辑：比较写入时间和重要度，默认新记录覆盖旧记录，但旧记录不物理删除，而是打上superseded_by标记留档。这样能保留纠错能力，一旦发现新记录是误提取的，可以回滚。

这里顺手分享一个小技巧：用户主动更正过的信息，权重自动拉高。如果用户在对话里明确说“我之前说错了，其实我不吃辣”，这条“不吃辣”的记忆要标记为high_confidence，优先级高于一般推断出来的偏好。推断信息再准，也远远比不上用户亲口确认的信息值钱。

5.2 时效性管理：记忆也有“保质期”

长期记忆不是永远不会过时的。用户的职位会变，兴趣会变，通勤方式可能因为搬家改变，宠物生病了这种临时状态更是一两周就失效。如果 Agent 拿着三个月前“用户养了一只猫”的记忆来推荐宠物保险，而其实用户早就把猫送人了，那场面会非常尴尬。

我的解决方案是给每条记忆加一个expire_at过期时间。不同类型的记忆，默认保质期不同：稳定的个人属性（名字、称呼）可以设一年以上；行为习惯类默认设 90 天；临时状态类（比如“用户最近在准备面试”）默认设 30 天；甚至有些极端场景可以设成“仅本次会话有效”。

过期不是简单删除。我习惯把过期记忆先挪进“待确认区”，在下一次相关话题出现时，Agent 可以主动问用户一句：“我之前了解到您通勤是骑电动车，最近还是这样吗？” 用户回答后，要么续期，要么更新，要么彻底删除。这一招既避免了记忆僵化，又能让用户觉得“Agent 真的在关心我变了没有”，体验分直接拉满。

5.3 检索精度的隐形杀手：Embedding 噪声和记忆穿插

用向量库做记忆检索，最容易出现的问题是两个：一是“语义相近但实际无关”的记忆被召回，比如用户说“我今天心情不好”，结果检索到一条“用户提到过抑郁症相关文章”的记忆，Agent 突然开始心理疏导，这会让用户一脸懵；二是“多条记忆互相穿插”，比如用户之前同时聊过“想开咖啡店”和“讨厌加班文化”，结果 Agent 把两条记忆强行融合成“用户想开一家天天加班的咖啡店”，这就属于典型的语义污染。

对付这两类问题，除了精过滤阶段的重排，还有一个笨但很有效的办法：检索结果里加一道“主题一致性校验”。具体做法是，召回记忆后，用当前对话的主题标签跟每条记忆的主题标签做匹配，不一致的直接过滤掉。这种方法不依赖复杂模型，效果却立竿见影，我一度把它当成默认配置在跑。

说到 Embedding 噪声，顺带提一个很常见的坑：不要用同一套 Embedding 同时处理“用户输入检索”和“记忆入库”。原因是用户输入往往口语化、碎片化，而记忆条目是提炼过的结构化文本，两者分布差异很大，共用一个向量空间会导致召回偏差。我现在的做法是入库时用“总结式文本”做向量化，查询时先用一个小模型把用户输入改写成一个“查询式表达”，再去做相似度检索。多这一个步骤，召回准确率能提升不少。

6. 记忆安全和隐私：功能再强，也不能越界

6.1 敏感信息的边界，必须在设计阶段就划清楚

让 Agent “记住你”这件事，本质上是在代用户保存个人数据。越是用得好的记忆系统，存储的隐私数据就越多——用户地址、职业、健康状态、家庭结构，甚至是情绪周期。这些数据的存储、使用、删除规则，不应该是上线以后才补，而是要在记忆系统设计的第一天就想清楚。

我的第一原则是：尽可能把敏感信息留在客户端本地，不上服务端记忆库。比如用户的浏览器历史、本机文件路径、设备信息，这些属于“环境上下文”，可以通过 MCP 在需要的时候临时获取，用完就丢，不需要也不应该长期记忆。

第二原则是：记忆库必须支持“字段级加密”。不同敏感级别用不同强度的保护：普通偏好明文存储，身份信息加密存储，高敏感字段（比如医疗信息）只存 Hash 或脱敏标识，绝不存原始值。这套分级策略跟数据库加密方案配合起来，能让隐私风险降到可控范围。

6.2 用户的“遗忘权”，是记忆系统的基本功能

很多团队做记忆系统时会忽略一个极其重要的用户需求：让用户主动删除记忆的权利。用户可能会因为隐私担忧、产品体验变化，或者单纯不想让 AI 记得那么多，而要求清空记忆。这时候如果你的系统只能“遗忘全部”，或者更糟——根本没法删，那你离流失用户就不远了。

我现在负责的产品里，记忆管理界面是跟 Agent 的对话界面同等重要的存在。用户可以逐条查看 Agent 记住了哪些信息，哪些不确定，哪些已过期，然后逐条删除或者一键清空。这个功能的技术实现不复杂，就是在存储层加删除操作，但产品形态上一定要做出来，让用户有“可控感”。

这里额外提醒一句：删除必须是物理删除，不能只是打标记。很多团队为了“留数据做分析”，删除只是软删，用户以为删了，其实数据还在库里。一旦被监管抽查或者被用户察觉，信任感直接清零。该物理删的就物理删，别打小算盘。

6.3 多租户隔离：一个记忆库，服务多个用户的安全红线

如果你做的是 SaaS 产品，记忆库一定不能是“所有用户混在一起检索”，而必须是严格的“租户隔离”。这里说的租户隔离，不只是数据库层面加个user_id过滤那么简单，还牵扯到向量检索的隔离、Embedding 空间的隔离、缓存层的隔离。

我踩过一个特别深的坑：初期在向量检索时只加了 user_id 作为普通过滤条件，结果在某些场景下，用户 A 的记忆把用户 B 的相似内容带了出来。排查了很久，发现是向量索引的分区粒度不够，导致相似度计算跨越了用户边界。后来我把向量集合改成按租户分片，每个用户一个独立的索引分区，问题才彻底解决。

在记忆系统的多租户隔离上，宁可多做一层隔离也别图省事。凡是涉及“用户级数据召回”的环节，都要默认“不共享”为安全基线，再根据产品需求逐步放宽到团队级、组织级共享。这个原则反过来做，出事只是时间问题。

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

7.1 症状一：Agent“假装记住”了，但回答内容张冠李戴

这个场景相信不少人遇到过：Agent 明明检索到了记忆，回答时也用上了，但用的是另一条不相关的记忆。比如用户问“帮我买咖啡”，Agent 说“好的，您平时喜欢喝茶”。这种问题排查起来很烦，因为从日志看记忆确实被注入进去了，只是注入错了。

我的排查套路是三步走。第一步，检查检索阶段召回的是不是正确记忆，直接在调试面板打印 Top 5 候选及得分；第二步，检查精过滤后的 Top 条是否保持正确，重点看重排权重是否把“语义相似但语境不符”的项排到了前面；第三步，检查 Prompt 模板里的记忆注入位置是否发生了文本截断或格式错位。

多数情况下，问题出在重排权重设置上。我的经验是，相关性打分应该占六成权重，新鲜度占两到三成，重要度占一到两成。如果重要度权重过高，模型就会“挑重要的说”，而不管这条重要记忆跟当前话题合不合。

7.2 症状二：记忆库越来越大，但效果越来越差

记忆系统刚上线时效果往往不错，跑上几个月后反而变笨了，这几乎是每个记忆系统都会遇到的“中年危机”。背后的主要原因，是记忆库里的过时信息、低质量信息在累积，检索时噪音太多，把有用的信号淹没掉了。

应对策略是一个“记忆三级清理机制”：第一级，入库时过滤低重要度信息；第二级，每天定时跑一个 Batch 任务，把过期记忆转入待确认区；第三级，每周做一次深度整理，自动汇总相似记忆、合并重复项、删除长期未被命中和零重要的记忆。这套机制跑起来之后，记忆库的增长曲线会变得平缓，查询效果也能稳定住。

另一个容易被忽略的隐藏性能雷区：向量索引的精度会随数据规模增大而衰减。如果用的是 HNSW 这类近似最近邻索引，数据量增长后要定期重建索引，否则召回质量会悄悄下降。我一般在数据量增长超过 30% 时就触发一次索引重建，成本不高，但能避免很多“莫名其妙变笨”的问题。

7.3 症状三：写入正常，但检索时经常“失忆”

这类问题通常是“写入-检索链路”上的不一致导致的，最常见的坑有两个：一是写入时用的 Embedding 模型和检索时用的不一致（比如一个升级了版本，另一个忘了同步），导致向量空间变了，检索完全跑偏；二是写入时存的是“提炼后的摘要文本”，但检索时拿“用户原话”去搜，两者语义距离太远。

解决第一个坑很简单：Embedding 模型的版本号必须全局统一管理，升级要灰度替换，不能让新旧模型同时生产。解决第二个坑，就是前面提到的“查询改写”：把用户原话先改写成一个跟记忆摘要风格一致的查询语句，再进向量检索。这两个细节注意不到，表现就是记忆“存了等于没存”。

7.4 症状四：用户主动反馈“这是我没有说过的东西”

这属于记忆误提取导致的信任危机，处理优先级非常高。我在工程上会单独建一套“记忆审计”机制：每条记忆都保留来源对话的引用 ID，一旦用户质疑某条记忆不真实，可以回溯到原始对话确认。

处理规则是：只要用户否认，对应记忆立即标记为“争议状态”并停止参与后续检索，同时触发一个旁路任务去检查是否在同一话题下发生过类似表述。如果确认是误提取，直接删除；如果确实存在但被模型误总结，则把原文附在记忆上下文里重新构造一条更准确的记录。

谈到“用户说这我没说过”这个问题，我还要多说一句：宁可少记，也不能乱记。记忆系统的价值不是“记得多”，而是“记得准”。那些拿不准的判断型信息，与其强行记忆，不如在对话中主动问用户确认一次。成本低，收益高，而且能让用户感到被尊重。

8. 记忆调试中的一些个人经验

最后再聊点偏个人向的经验。我做记忆系统调试时，一直把“单元测试+可视化回溯”当作标配。单元测试覆盖典型场景，比如“用户变更偏好后是否触发冲突处理”“过期记忆是否进入待确认区”“跨用户检索是否被隔离”等；可视化回溯则是把每一轮对话的“检索→注入→生成→更新”全链路打点，任何一次记忆相关的异常都能追溯到具体环节。

可视化这一招帮过我大忙。有一回遇到一个“Agent 对老用户忽然变得陌生”的线上问题，查了很久，最后是在回溯日志里发现用户的session_id在某个版本更新后发生了漂移，导致短期记忆层一直拿不到历史会话数据。如果不做全链路可视回溯，这种问题靠猜要猜很久。

另外，我想强烈建议做记忆系统的团队，给“记忆摘要”专门配一个模型，而不是复用对话生成的模型。对话生成模型追求自然流畅，摘要模型追求信息密度和结构化。两边混用，结果往往是对话变啰嗦，摘要变空泛。我试过用专门的摘要小模型处理记忆写入后，记忆质量有明显的稳定提升。

还有，记忆系统的评估指标要提前定好。我习惯跟踪三个核心指标：记忆命中率（检索出的记忆中有多大比例是与当前任务相关的）、记忆准确度（注入记忆是否与后续对话事实一致）、用户澄清率（用户每百轮对话中纠正 Agent 记忆的次数）。前两个是技术指标，第三个是产品体验指标。如果用户澄清率持续走高，说明你的记忆系统在“自作聪明”地记错东西。

这个方向后续可以扩展的内容还很多，比如记忆的跨语言迁移、多 Agent 情境下的共同记忆构建、基于记忆的个性化生成策略等。我自己下一步在折腾的，是把记忆系统和主动学习机制接起来——同样是记东西，被动地记录用户说了什么，远不如在合适的时候“主动问你一句”来得高效。真正让用户感觉到“被记住了”的瞬间，往往就是 Agent 说出了一句只有记住你才能说出的话。