企业官网建设流程全解析

我最近在调一个 AI Agent 项目时碰到一个诡异现象：用户明确说过“我习惯早上九点开会”，结果第二天 Agent 照旧在下班时间帮用户安排会议；用户第三次重申“预算不要超过五千”，Agent 依然在第四轮把报价推荐到八千。日志里明明记录了用户说过的话，系统提示词里也写着“请记住用户偏好”，可它就是记不住。

这不是模型能力问题，是 Agent 的记忆架构问题。很多人做 Agent 时只关注工具调用和规划能力，把记忆当成“把历史对话拼进上下文”这种小事，结果做到后面发现：对话一长就乱、跨会话全忘、用户画像形同虚设。这篇是“走进 AI Agent”系列的第三篇，我把自己在真实项目里给 Agent 加记忆的完整思路、踩坑过程和可落地的代码骨架，一次性说清楚。

无论你是在用 LangGraph、Spring AI 这类框架，还是从零搭建自己的 Agent，只要你想让 AI 记住用户，这篇文章都值得看完。

1. 先复盘一个真实场景：为什么 Agent 总在“记住”之后继续忘

1.1 在调试日志里看到的“三连忘”

那个项目的功能其实不算复杂：一个帮用户做日程管理、差旅规划、采购审批的办公 Agent。最开始我们把所有历史对话一股脑丢进上下文，指望大模型“自己记住”，结果一上线就出问题。

日志里反复出现三种情况：

• 用户第一轮说“我预算五千以内”，第六轮 Agent 推荐了八千的商务舱套餐；
• 用户说“我不吃辣”，三小时后 Agent 又推荐了川菜馆；
• 用户说“以后周五下午不要安排会议”，第二周周五 Agent 照样给用户拉了个三点半的评审会。

最典型的一次，用户已经被问了三遍“您常去哪个城市出差”，用户在第一遍就答过了。每问一次，用户就得重复一次。这种体验用一句话概括：Agent 像个金鱼，只有七秒记忆。

1.2 记忆缺失的连锁反应：重复提问、重复确认、体验崩坏

表面上这只是“信息没记住”，实际上它会引发一连串连锁反应。

第一，交互轮次暴增。用户被反复追问已经提供过的信息，原本 5 轮能完成的日程安排，被拖到 12 轮以上。每多一轮，都意味着 Token 消耗增加、响应延迟变长、出错概率变大。

第二，用户信任崩塌。信任这东西很奇怪，用户能容忍 Agent 某一步算错了，但容忍不了“我已经告诉过你的事情，你一点反应都没有”。后者会直接让人觉得“这东西根本没有脑子”。

第三，业务动作失效。这不是聊天游戏，Agent 是要干活的。安排会议、提交审批、预订行程，这些动作都依赖对用户历史偏好的准确理解。没有记忆，Agent 每次开工都是“失忆状态”，所有流程都要从头问一遍。

1.3 工程上给“记忆”一个可落地的定义

在动手之前，我们先说清楚“记忆”在 Agent 工程里到底是什么。我的定义是这样的：

记忆是 Agent 在当前会话及历史会话中获取的信息，经过筛选、加工和持久化之后，能在后续决策时被检索并利用的那部分结构化或半结构化数据。

拆开看有三个关键点：

• 可筛选：不是所有东西都值得记，记忆的前提是“去噪”；
• 可持久化：内存里的东西断电就没了，真正有用的记忆要落到存储里；
• 可检索：存进去不代表能用上，必须在需要的时候能快速找回来。

很多团队做记忆系统失败，就是只做了“收集”和“存储”，漏了“筛选”和“检索”。信息存了一堆，召回时什么都捞不到，或者捞回来一堆没用的，效果自然差。

2. 给 Agent 记忆做分层：别让所有信息都挤在一个篮子里

市面上各种记忆方案五花八门，但其实只要按“存活时间”和“抽象程度”两个维度去拆，所有记忆都能分成四类。这个分类方式参考了认知科学里对记忆的研究，直接搬过来用就行。

2.1 短期记忆：跟着上下文窗口走的“工作台”

短期记忆就是当前对话过程中的上下文。它对应大模型的 context window，存活时间从几秒到几小时不等，取决于对话多长、窗口多大。

短期记忆的价值在于“即时性”。用户说“刚才那份报表的分析结论是什么”，Agent 能回答，就是因为对话历史还在上下文里。它的问题是“容量有限”，现阶段主流模型窗口再大也经不住长对话无限堆叠。

工程上的做法通常是滑动窗口截断：只保留最近 N 轮对话，再早的直接丢弃，或者压缩成摘要再放回窗口。这个 N 怎么定，是个非常讲究的经验问题，后面踩坑部分我会详细说。

2.2 长期记忆：跨会话保留的“用户档案”

长期记忆是让 Agent“记住你”的核心。它的特点是：跨会话、可持久化、结构化程度高。

典型的内容包括：

• 用户的基本信息：称呼、城市、职位、所在行业；
• 用户的偏好：沟通风格、预算范围、时间习惯、内容喜好；
• 用户的决策历史：过往审批过的方案、拒绝过的类型；
• 用户的身份关系：和公司、团队、项目之间的关联。

长期记忆不追求“全”，追求“准”。存一百条过期噪音，不如存十条准确画像。因为长期记忆每一条都会在未来的决策里反复被调用，一旦某条是错的，错误会被无限放大。

2.3 情景记忆和语义记忆：记忆系统里容易混淆的两类数据

这两类来自认知心理学，但在 Agent 工程里也有明确对应。

情景记忆（Episodic Memory）记录的是“具体发生过的事件”：上周二用户拒绝了蓝色款式的设计方案、上个月用户把机票改签到了下午三点。这类记忆的特点是带时间、带上下文、不可替代。

语义记忆（Semantic Memory）记录的是“抽象出来的知识”：用户偏好极简风格、用户出差一般选靠窗座位。语义记忆通常是从一段或多段情景记忆里归纳提炼出来的。

很多人做记忆系统只做语义记忆，直接问 LLM“从这个对话里摘要出用户的偏好”，结果丢失了大量关键细节。更合理的做法是：先保存情景记忆的原始记录，再定期用 LLM 做归纳，把提炼出的语义记忆单独存一层。两层配合使用，一个管“细节回溯”，一个管“快速决策”。

2.4 各层记忆的核心差异一览

工作记忆容易被忽略，但做多工具协同的 Agent 时非常关键。它负责保存当前任务的中间结果，比如已经搜到的材料、正在填的表单、下一步要执行的动作。没有工作记忆，Agent 一旦调用了五六个工具，很快就忘了自己一开始想干什么。

3. 搭一套最小可用记忆系统：写入、存储、召回三段式

理论说完，直接进入实操。一个能用且不用过度设计的记忆系统，核心就三个环节：写入、存储、召回。我把每个环节最容易犯的错和最优做法一起讲。

3.1 写入阶段：规则触发与 LLM 抽取的取舍

写入记忆最忌讳“什么都记”。如果每轮对话都调用一次 LLM 做抽取，成本爆炸不说，还会把大量无关信息写进记忆库，污染后续召回。

我的实践方案是“规则触发 + LLM 抽取”两层配合：

• 规则层：先用轻量规则判断哪些对话值得进入抽取流程。比如用户在句子中表达了偏好（“我喜欢”“我习惯”“以后不要”）、提供了个人信息（“我在上海工作”“我的预算是”）、或者对 Agent 的动作给出了否定反馈（“不对”“不要这个”）。这些模式可以用正则或关键词快速命中。
• LLM 抽取层：命中的对话才交给 LLM，让它按照预定义的字段结构抽取记忆点。比如抽取用户的预算范围、风格偏好、时间习惯，每条记忆附带一个置信度和来源时间。

这样设计的好处是省钱、省时、噪音少。大量无关对话在规则层就被拦住了，LLM 只处理真正值得记的内容。

3.2 存储阶段：从 JSON 文件到向量数据库的选型思路

存储选型没有银弹，完全取决于你的数据规模。我从轻到重排个序：

• JSON 文件：适合原型验证、个人项目、单用户场景。把用户记忆读进内存，用关键词匹配。优点是零依赖，缺点是检索能力基本没有。
• SQLite / 关系型数据库：适合结构化记忆较多的场景。用户画像、事件记录、偏好表都可以建表存。配合全文索引，能解决一部分检索需求。优点是查询灵活，缺点是语义检索做不了。
• 向量数据库（Chroma、Milvus、Weaviate、pgvector 等）：适合需要“按语义召回”的场景。用户说“我出差喜欢安静”，你要在记忆库里找到“偏好靠窗、远离走廊”这条记录，关键词匹配做不到，向量相似度可以。
• 知识图谱：适合实体关系复杂的场景，比如记忆里有多个人、多个项目、多个组织之间的关联。优点是可以做逻辑推理，缺点是构建和维护成本高，普通项目慎用。

我个人的建议：MVP 阶段直接用 SQLite 存结构化记忆 + 一个轻量向量索引就够。不要一上来就上重型向量数据库，后面你维护的时候会后悔的。

3.3 召回阶段：检索时机、Top-K 与上下文注入位置

召回是整个记忆系统里最影响体验的环节。存了好记忆，召回不出来等于没有。

先解决“什么时候召回”。我的做法是：在每次 Agent 执行任务前，先做一个意图判断。如果当前任务涉及用户偏好、历史事实、已有决策（比如推荐、审批、规划），就触发记忆召回；如果任务是纯工具型操作（比如查天气、算个公式），就不召回，节省 Token。

再解决“召回多少条”。Top-K 到底取多少，取决于记忆库的质量。记忆库质量高、去噪做得好，K 可以取 3 到 5；记忆库噪音多，K 越大越危险。我常用的策略是动态 K：根据当前用户问题的复杂度决定，问题里涉及多个条件（预算、时间、地点），就把 K 调大。

最后解决“注入到哪里”。召回出来的记忆应该拼进 System Prompt 的一个独立区块，用明确的分隔符包起来，比如：

<memory_section> 用户身份：上海某创业公司市场负责人 预算习惯：单次采购不超过5000元 沟通偏好：喜欢直接给结论，不用铺垫 近期事件：上周否决了8000元商务舱方案 </memory_section>

这样做有两个好处：一是模型能明确区分“记忆信息”和“当前对话”，不会被混淆；二是方便调试，输出日志时能清楚看到每次请求拼了哪些记忆进去。

3.4 一个可以直接跑的 MemoryManager 骨架

下面给出一段简化但可运行的 Python 骨架代码，涵盖写入、存储、召回三段逻辑。它不绑定具体框架，你可以直接嵌到自己的 Agent 里。

import json import hashlib import time from dataclasses import dataclass, asdict from typing import List, Optional @dataclass class MemoryItem: content: str # 记忆内容 memory_type: str # personal / preference / event / fact user_id: str # 用户标识 created_at: float # 写入时间 source_turn: str # 来源对话轮次，便于溯源 importance: float = 0.5 # 重要度，0-1，用于后续合并/淘汰 retrievable: bool = True # 是否可以被召回 class MemoryManager: """ 最小可用记忆系统 - 写入：save() 写入一条记忆 - 召回：retrieve() 按关键词/语义返回相关记忆 - 更新：update() 合并或淘汰旧记忆 - 遗忘：forget_before() 清理过期记忆 """ def __init__(self, storage_path: str = "./memory_store.json"): self.storage_path = storage_path self._items: List[MemoryItem] = self._load() def _load(self) -> List[MemoryItem]: try: with open(self.storage_path, "r", encoding="utf-8") as f: raw = json.load(f) return [MemoryItem(**item) for item in raw] except FileNotFoundError: return [] def _flush(self): with open(self.storage_path, "w", encoding="utf-8") as f: json.dump([asdict(item) for item in self._items], f, ensure_ascii=False, indent=2) def save(self, content: str, memory_type: str, user_id: str, source_turn: str, importance: float = 0.5): item = MemoryItem( content=content, memory_type=memory_type, user_id=user_id, source_turn=source_turn, created_at=time.time(), importance=importance ) self._items.append(item) self._flush() def retrieve(self, query: str, user_id: str, top_k: int = 5) -> List[MemoryItem]: """ 简化版检索： 1. 过滤出该用户可召回的记录 2. 按关键词简单打分 3. 按重要度加权 生产环境可以把这里替换成向量库的语义检索 """ query_words = set(query.lower().split(" ")) scored = [] for item in self._items: if not item.retrievable or item.user_id != user_id: continue content_words = set(item.content.lower().split(" ")) hit = len(query_words & content_words) / max(len(query_words), 1) score = hit * 0.7 + item.importance * 0.3 scored.append((score, item)) scored.sort(key=lambda x: x[0], reverse=True) return [item for _, item in scored[:top_k]] def update(self, item_id: str, new_content: str = None, new_importance: float = None): """按 id 更新一条记忆，通常是偏好变更时使用""" for item in self._items: # 生产环境这里应该用唯一 id 匹配，示例中省略 if item.content == item_id: if new_content: item.content = new_content if new_importance is not None: item.importance = new_importance break self._flush() def forget_before(self, timestamp: float): """遗忘早于某个时间点的低频记忆""" self._items = [ item for item in self._items if item.created_at >= timestamp or item.importance > 0.7 ] self._flush()

这段代码故意做得很轻，把向量检索替换成了简单的关键词打分，目的就是让你先跑通逻辑。生产环境只要把 retrieve 方法内部换成向量数据库的相似度查询就行，接口不用动。

4. 让记忆“准”而不是“多”：检索阈值、冲突合并与更新策略

写完第一版记忆系统，本地测试看着不错，一旦接上真实用户，问题就全冒出来了。核心矛盾是：记忆不是越多越好，而是越准越好。这一节讲我把检索从“能用”调到“好用”的过程。

4.1 Top-K 召回为什么经常把关键记忆漏掉

用向量库做 Top-K 召回，最典型的翻车场景是：该记的没出来，不该记的出来一堆。

原因在于，用户当前问题里的关键词，和真正有用的历史记忆之间，往往不是字面匹配，而是语义关联。比如用户问“出差住宿怎么选”，真正有用的记忆是“用户上次出差选了行政楼层，理由是隔音好”——这中间隔着“出差”和“行政楼层”两层抽象。

如果你只对对话末尾的最新一条做检索，肯定召回不到几个月前的那条关键记录。我的解决办法是多路召回：

• 第一路：对用户当前 query 做向量检索，取 top 10；
• 第二路：对用户当前会话的主题标签做检索，取主题相关的历史记忆；
• 第三路：对用户画像中的高频偏好直接轮询（按重要度排序取前几条）；
• 最终合并去重，按综合得分重新排序。

三种召回渠道画像不同，综合得分 = 检索相似度 × 0.5 + 重要度 × 0.3 + 新鲜度 × 0.2。这个权重我调了很久，核心逻辑是：既要让相关性强的内容排前面，又要给重要但相似度稍低的记忆一个出场机会。

4.2 相似度阈值怎么调才不容易误伤

召回出来的内容不是每条都有用。上一轮还聊着聚餐，下一轮问工作安排，如果相似度阈值太低，Agent 就把“聚餐偏好”当成高优先级记忆塞进上下文，反而干扰判断。

我踩过的坑是按“推荐值”抄阈值。向量库的相似度分数没有一个通用标准，不同 embedding 模型的分数分布完全不同。有的模型打分普遍在 0.7 到 0.9 之间，你以为 0.75 是很接近了，其实已经差得很远；换一个模型，0.5 以下才真的没关系。

我的做法是给自己做一个校准实验：

• 选 50 个真实用户 query；
• 每个 query 手动标注“应该召回”和“不该召回”的记忆集合；
• 在测试集上跑不同阈值，看 precision 和 recall 的交点；
• 选一个“宁缺毋滥”的阈值——记忆召回宁可少一点，不要召回乱七八糟的东西进上下文。

校准之外，还有一个实用技巧：不要只看相似度分数，要设一个绝对的最低分底线。不管什么场景，低于 0.4 的召回结果直接丢。这个底线能挡掉大量无意义的语义噪声。

4.3 用户偏好变了：记忆冲突的更新与淘汰机制

记忆系统做得再准，也会碰到一个绕不开的问题——用户变了。用户上个月喜欢详细汇报，这个月嫌你啰嗦；上周说预算五千，这周说预算可以放宽。

如果不处理冲突，Agent 会陷入“人格分裂”：一会儿按旧偏好办事，一会儿按新偏好办事，用户感觉像个杠精。

我在系统里加了三道处理机制：

1. 时间戳权重：相同主题的记忆，优先采信时间更近的那条。具体实现是给每条记忆加一个衰减系数，召回的排序得分乘以 exp(-days / half_life)。半衰期我一般设 30 天，也就是一条记忆过了一个月，相关度折一半。

2. 显式否定优先：当用户明确说“不要/不用/取消/以后别”，这条指令优先级最高。我不只把它当作一条新记忆，还会把它标记为“废止”相关联的旧记忆。比如用户说“我以后不吃辣了”，系统要把之前“用户喜欢吃辣”这条记忆的 retrievable 置为 False，而不是让它继续和新记忆打架。

3. 周期性固化：每周五跑一次任务，把本周的情景记忆拿去让 LLM 归纳，更新到语义记忆层。归纳时如果发现新旧偏好矛盾，以最近三条的用户反馈为准，生成一条新的偏好记忆，并把旧记忆降权。

4.4 用 LLM 做记忆合并/去噪时的注意事项

很多人喜欢让 LLM 做记忆抽取和合并，但要小心几个问题。

第一，LLM 容易被上下文“带偏”。如果 prompt 里给的示例都是关于出差偏好的，它就会把用户今天聊的“喜欢安静”强行理解成出差偏好，而实际上用户说的是办公室环境。解决办法是：抽取任务的任务描述要独立清晰，不要给太多无关示例。

第二，LLM 会把推测当成事实。用户说“我最近在看房子”，LLM 可能在抽取时记成“用户打算买房”。这两句话差别巨大，但 LLM 很容易越过事实做推断。我的处理方式是在抽取 prompt 里写死原则：只能抽取用户明确表达的事实，禁止任何推断，识别到不确定内容时标 low confidence 而不是直接记录。

第三，LLM 抽取结果要过“校验层”。我用一个很小的人工规则库做兜底：比如抽取出的内容必须包含至少一个动词短语、必须能还原出“谁、什么、怎么样”三个要素、不能只有形容词。过不了校验的直接丢弃。

5. 实测踩坑记录：从“什么都记”到“记不住重点”的完整排查链路

这部分是重头戏。我把上线后用户反馈最多的几个问题，从现象到根因到修复，完完整整走一遍排查链路。如果你已经做了记忆系统但效果不好，建议对照检查。

5.1 坑一：记忆全量塞进上下文，输入 Token 直接翻倍

现象：接上记忆系统之后，Token 消耗暴涨，响应延迟明显变高，更离谱的是效果反而变差了。

排查过程：先看日志，发现每次请求的 system prompt 里都拼了近五千字的历史记忆摘要。原来第一版实现图省事，把用户所有历史记忆全部序列化进 prompt。上下文从原本的一千字 token 涨到六千多，模型要处理的信息量暴增，注意力被大量低价值记忆稀释。

根因：我没有给记忆做“范围限制”，理想情况是每次只注入当前任务最相关的 3 到 5 条记忆，我直接一股脑全塞。

修复：把注入逻辑改成“先召回，再注入”。每次请求只带召回的 top 5 记忆，每条记忆不超 100 字。Token 消耗立刻回落，效果也恢复了。

5.2 坑二：记忆污染——召回出来的内容本身就有毒

现象：Agent 有时候会突然无中生有。用户没说过的话，它当成用户偏好说出来。比如用户只是问了一句“你们有儿童套餐吗”，第二天 Agent 就断定“用户带娃”，推荐了一堆亲子产品。

排查过程：把一条被召回的“用户带娃”记忆拿到人工审查，发现源头是某次对话里用户提到帮朋友问儿童套餐。LLM 抽取记忆时丢了“帮朋友问”这个上下文，直接记成了“用户关注儿童餐”。

根因：记忆抽取阶段没有约束“主体归属”。用户对话里提到的信息，不一定是关于用户本人的。必须区分“用户的事实”和“用户提到的第三方事实”。

修复：在抽取 prompt 里加入强制要求——只有包含“我 / 我们 / 本人”等第一人称指代，且明确表达主体是用户本人的内容，才允许写入用户画像。涉及第三人称的内容，最多写入 event 类型记忆，并且检索权重降到最低。修复后这类幻觉消失了大半。

5.3 坑三：旧记忆和新偏好打架，Agent 像个杠精

现象：用户明确说“这次不用考虑预算，选最好的”，Agent 却在好几个方案里反复标注“考虑到您以往预算五千以内”。用户直接炸毛。

排查过程：查看召回的候选列表，发现旧记忆“预算不超过五千”评分非常高，因为历史里提过很多次，重要度已经被反复写入抬得很高；而“本次不考虑预算”这条新记忆只有一条，重要度低，排序排在后面。

根因：我完全没有做“即时压制”。用户在当前对话给出的信息，优先级应该天然高于历史记忆。旧记忆靠重复把重要度刷上去了，但它在当下已经失效。

修复：加了一条硬规则——当前对话中用户的最新指令永远排在所有历史记忆之前。具体做法是：先把当前对话涉及的主题标记出来，召回历史记忆时，凡是主题相同且时间早于当前对话轮次的，一律降权 0.5。新指令说完，旧记忆立刻让位。

5.4 坑四：把记忆直接拼进 System Prompt，改起来想哭

现象：每次要调整记忆注入格式，都要重新发版；更糟的是，有些模型的 System Prompt 一长，指令遵循能力就开始下降。

排查过程：统计线上失败案例，发现凡是带有大量历史记忆的请求，模型漏掉关键指令的概率明显上升。System prompt 同时承载了“角色设定、工具说明、安全约束、记忆数据”四类内容，互相干扰严重。

根因：职责混杂。System prompt 应该只放“不会变的东西”，可变的数据不该生硬拼接进去。

修复：把所有记忆数据挪到 user 消息的单独区块，或者用工具方式独立传参。让 System Prompt 保持精简，记忆作为独立的上下文段落传入。改动之后，模型指令遵循能力明显回升。如果你框架支持，也可以直接用消息数组里单独一个 system 分段放记忆，注意观察不同模型对多段 system 的兼容性。

5.5 踩完坑之后留下的四条铁律

把上面几个坑复盘完，我提炼出四条铁律，现在每次新项目都直接套用：

• 先召回再注入：记忆永远只带相关的一小部分，不搞全量搬运；
• 主体识别兜底：只有关于用户本人的明确事实才能进画像，第三方信息单独隔离；
• 当前指令优先：用户当下说的话，永远比历史记忆权重高；
• 数据与指令分离：记忆是数据，不是指令，不要污染 System Prompt。

6. 记忆系统要不要做重，取决于你的场景终局

最后一篇的篇幅留给架构取舍。很多人问我“记忆系统到底要做到多复杂”，我的回答是：先看你产品离了记忆能不能转。

6.1 按使用场景选记忆方案：轻量聊胜于无，重量未必划算

不同产品对记忆的依赖程度完全不一样。我按轻重梯度列个表：

这里我给一个特别重要的建议：不要为了技术炫技而做重记忆系统。如果你的用户一周只来一次，对话轮次也少，一个轻量 JSON 存储可能比向量数据库体验更好。重系统的维护成本远超你想象。

6.2 隐私与数据主权：记忆本身就是用户的数据

这一点一定要单独拿出来说，因为它太容易被忽略了。

记忆系统本质上在做的事，是把用户说过的话长期保存下来。这会让你的产品更懂用户，但也意味着你掌控了用户的隐私数据。我的处理原则：

• 记忆必须支持查看和删除，用户在设置里能看到“AI 记住了我的什么”，并能一键清空；
• 深度个性化数据默认加密存储，不在日志里明文打印；
• 业务不需要的敏感信息（银行卡号、身份证号、密码）需要在写入阶段就拦截，绝不进记忆库；
• 记忆数据不会用于训练，这一点需要在产品协议里写清楚。

不要觉得这是小题大做。如果哪天用户发现你的 Agent 还记得他三个月前的体检指标，而你没法解释清楚数据的用途，信任崩塌的速度比功能上线快得多。

6.3 让记忆可被看见：可视化调试是长期维护的关键

记忆系统是个黑盒，看不见就会失控。

我踩过一个教训：有一次 Agent 推荐质量大跳水，排查了半天发现是记忆库里有十几条互相矛盾的旧记录在轮流生效，导致每次推荐逻辑都不一样。但因为记忆存在数据库里，只能看文件，根本没法快速定位。

后来我加了个简单的“记忆可视化”面板，把每个用户的记忆列表按类型、时间、重要度列出来，还能直接手动修改和删减某条记忆。有了这个面板，调试效率翻了好几倍。

你不用做什么复杂前端，一个简单的后台页面或者一条 debug 命令就够。关键是让“Agent 当前记住的东西”可见、可改、可溯源。

6.4 如何评估一个记忆系统“做得好不好”

记忆系统的效果，不像大模型推理能力那样有清晰的 benchmark，但我们可以用三个指标来衡量：

• 重复提问率：用户问过同一个问题的次数占比，理想情况应该随着记忆积累明显下降；
• 偏好一致率：Agent 的输出和用户历史明确表达的偏好之间的匹配程度，可以抽样人工打分；
• 记忆时效性：过时记忆在召回结果中的占比，这一条越低越好，需要定期清理机制来保证。

这三个指标不需要做得很重，哪怕是每周人工抽 20 条日志来看一眼，也比完全黑盒强得多。我自己常用的组合是“重复提问率 + 定期人工抽检”，在小团队的资源约束下性价比最高。

我个人在做记忆系统时最深的体会是：记忆不是功能，是架构。它横跨数据层、检索层、prompt 层和产品交互层，任何一环掉链子，最终表现都是“Agent 记不住你”。所以不要指望一个灵光一现的技巧能解决问题，老老实实把分层、写入、召回、更新、清理这套链路走通，你手里那个 Agent 才会真正从一个“每次都重新认识的陌生人”，变成一个越用越懂你的搭档。