不展示底层文件名
用户管理的是“我与 Agent 的关系”，不是数据库、配置文件或存储结构。
返回精选项目
让 Agent 的记忆
Agent Memory / 产品设计
Agent 长期记忆产品机制
让 Agent 的记忆
变得可见、可纠正
这是一个单窗口的长期陪伴型 Agent。随着对话累计到数千甚至数万轮，用户无法通过新建会话重置上下文：哪些信息值得长期保留、Agent 实际记住了什么、错误记忆如何被发现和纠正，都会直接影响后续协作。
我系统拆解长期记忆的写入、存储、召回、更新、删除和冲突机制，并将底层能力转化为用户可以查看、修改和维护的 MemoryTab。
- 我的职责
- 机制调研、产品设计、规则制定、研发评审、上线推动、评测与优化
- 固定测试用例
- 30条
- 首轮实际测试用户
- 约 100名
- 闭环成功率
- 67.5%→85%
- 误召回率
- 18%→5%
记得越多不是目标。准确、可见、可纠正，并始终保持一致才是。
01 / 机制拆解
我把“记住用户”拆成
8 个可验证环节
我先追踪一条信息从用户表达进入长期记忆，再回到后续回复的完整路径。每个环节不仅有机制问题，也有用户可直接感知的产品风险。
-
01 写入
- 判断问题
- 什么信息值得长期保留？
- 具体风险
- 把临时状态、一次性指令或不确定表达写成长期偏好。
- 产品原则
- 只写入长期稳定、与后续协作有关的信息。
-
02 存储
- 判断问题
- 如何保存内容、适用范围和有效版本？
- 具体风险
- 产生重复条目、过度概括，或无法区分新旧版本。
- 产品原则
- 保留语义、适用范围和当前有效状态。
-
03 展示
- 判断问题
- 用户如何看懂 Agent 已经记住的内容？
- 具体风险
- MemoryTab 展示与底层有效状态不一致。
- 产品原则
- 使用用户能理解的产品模块，而不是底层字段。
-
04 更新
- 判断问题
- 新信息如何替换或修正旧信息？
- 具体风险
- 新旧值同时保持有效，后续召回结果不稳定。
- 产品原则
- 更新使用替换或合并语义，而不是简单新增。
-
05 删除
- 判断问题
- 删除后哪些状态需要同步失效？
- 具体风险
- 只隐藏前台内容，底层存储、索引或摘要仍继续召回。
- 产品原则
- 删除同步影响展示、底层状态与召回。
-
06 冲突
- 判断问题
- 如何识别时间和语义上的新旧变化？
- 具体风险
- 相互冲突的信息同时存在，回复随机使用旧值。
- 产品原则
- 以用户最新、明确的表达为准。
-
07 召回
- 判断问题
- 当前任务应该使用哪条有效记忆？
- 具体风险
- 召回旧信息、不相关信息，或在无关场景中过度引用。
- 产品原则
- 只召回最新、有效且与当前任务相关的记忆。
-
08 回复
- 判断问题
- 最终回答是否真正使用了正确记忆？
- 具体风险
- MemoryTab 已更新，但 Agent 回复仍沿用旧信息。
- 产品原则
- 以最终回复行为验证任务是否真正完成。
任何一个环节失败，都可能造成“用户以为已经改好，但 Agent 仍在使用旧信息”。
02 / 产品化
我没有把底层存储
直接暴露给用户
用户要管理的不是文件名、数据库或存储字段，而是“Agent 如何理解我、如何与我协作”。因此 MemoryTab 位于 Files 页面，但前台不展示底层文件名，也不采用文件夹式管理。
我将内容组织为行为准则、身份与角色、用户资料与偏好，并使用文档式面板帮助用户整体阅读。修改不采用逐句编辑，而是由 MyClaw 承接模块级自然语言修改。
只有底层更新成功后，MemoryTab 才展示新内容；失败时保留原状态并反馈原因。
按用户心智组织内容
按行为准则、身份与角色、用户资料与偏好组织，而不是要求用户理解技术分类。
使用文档式内容面板
支持整体理解当前设定，避免大量逐条卡片造成碎片化。
更新失败不提前覆盖
底层更新成功后才展示新内容；失败时保留旧状态并明确反馈。
产品化转译的核心，是隐藏底层复杂度，同时保留用户对结果的查看、纠正和控制能力。
03 / 固定评测集
我如何建立 30 条
固定评测集
我没有临时挑选几个 Prompt 判断效果，而是按四类场景建立固定测试集。每次规则或策略调整后，都使用同一批用例重新验证，使前后结果可比较。
01
正常场景
7 条验证稳定信息能否准确写入、正确展示并在相关场景中召回。
以后叫我 Wesley。
称呼是否准确写入并按需召回我主要做 AI 产品相关工作。
是否避免推断公司、职级和项目以后给我写 PRD 时要简洁，研发能直接看懂。
是否保留偏好的适用范围
重点检查写入准确 · 展示一致 · 按需召回
02
边界场景
8 条区分长期信息、临时状态、一次性指令和异常保护。
我今天有点困。
是否避免写入临时状态这次回答简短一点。
是否区分一次性指令和长期偏好更新失败时，旧内容是否仍保持有效？
是否保护旧状态并诚实反馈
重点检查谨慎写入 · 不过度概括 · 失败保护
03
极端复杂场景
8 条验证冲突、删除、长上下文和版本状态。
之前叫我 Wes，现在还是叫 Wesley 吧。
旧称呼是否失效删除后再经过 30 轮对话，是否仍会召回？
删除是否跨摘要和长上下文持续生效旧项目结束后，新项目是否替换而不是与旧状态并存？
是否识别状态变化和版本优先级
重点检查旧值失效 · 删除彻底 · 最新版本优先
04
真实用户场景
7 条覆盖口语表达、上下文指代、多轮操作和用户主动检查。
我现在不做上次那个了，最近主要在做 MemoryTab。
是否结合上下文理解指代你现在到底记住了我什么？
回答是否与当前有效记忆集合一致把你记住的所有工作地点都删掉，其他信息保留。
是否精确执行删除范围
重点检查理解上下文 · 精确处理范围 · 最终一致
评分标准
只有三处一致，才算闭环成功
只有 MemoryTab 展示、底层有效状态和后续 Agent 回复全部一致，才算闭环成功。
检查环节
通过标准
常见失败
归因
是否应该写入
只写入长期稳定、与后续协作有关的信息。
把临时状态或一次性指令写成长期偏好。
模型理解、记忆提取策略
写入内容
信息准确，不擅自扩大、推断或概括。
将局部偏好扩展为全局偏好。
模型理解、摘要策略
MemoryTab 展示
展示内容与当前有效记忆一致。
显示旧值，或展示尚未成功写入的新值。
前台刷新、状态同步
用户修改
新信息替换或合并旧信息。
新旧值并存，后续随机命中。
更新规则、旧值失效
用户删除
前台、底层和召回索引同步失效。
只在界面隐藏，之后仍能召回。
删除链路、索引同步
冲突处理
识别状态变化，以最新明确表达为准。
冲突信息同时被视为当前事实。
冲突检测、版本优先级
后续召回
只使用最新、有效且与当前任务相关的信息。
使用旧值，或在无关任务中过度召回。
召回排序、相关性阈值、缓存
更新失败保护
失败时不提前覆盖旧内容，并明确反馈。
前台先显示新值，但底层更新失败。
异步状态、产品规则
最终一致性
MemoryTab、底层状态和 Agent 回复三处一致。
任一位置与其他两处不一致。
跨链路状态管理
04 / Bad Case
我不只看界面是否更新，而是继续检查下一次真实召回
我会同时检查用户原始表达、原记忆、修改或删除操作、MemoryTab 展示、底层有效状态和后续 Agent 回复，再判断状态从哪里开始不一致。每个修复后的问题都会进入固定回归集。
Bad Case 01
修改后仍使用旧称呼
“之前说叫我 Wes，现在还是叫 Wesley 吧。”
- 原始记忆
- 称呼为 Wes。
- 用户操作
- 通过 MyClaw 将称呼更新为 Wesley。
- MemoryTab 状态
- 已经显示 Wesley。
- 底层状态
- Wes 与 Wesley 同时保持有效。
- 后续 Agent 回复
- 仍然称呼用户为 Wes。
为什么判定失败
前台虽然更新，但底层旧记忆没有失效，最终回复仍使用旧值。
失败归因
- 更新使用新增语义
- 缺少旧值失效状态
- 召回没有最新版本优先级
优化方式
- 更新改为替换语义
- 旧称呼进入失效状态
- 召回只读取当前有效版本
如何加入回归测试
修改后立即检查一次，再经过长对话后复查称呼是否仍为 Wesley。
Bad Case 02
删除后仍继续召回
“把关于我正在找工作的记忆删掉。”
- 原始记忆
- 近期正在找工作。
- 用户操作
- 通过 MyClaw 删除该条工作状态。
- MemoryTab 状态
- 该内容已经消失。
- 底层状态
- 存储、索引或历史摘要中仍保留旧信息。
- 后续 Agent 回复
- 之后的对话继续主动提及求职。
为什么判定失败
删除只影响前台展示，没有让底层与召回链路同步失效。
失败归因
- 删除链路不完整
- 召回索引未同步
- 历史摘要可能重新带回旧信息
优化方式
- 统一删除前台、存储和索引状态
- 召回前过滤失效记忆
- 避免摘要重新写回
如何加入回归测试
删除后立即检查，并在多轮无关对话后再次验证不再召回。
Bad Case 03
临时指令被写成长期偏好
“这次回答简短一点。”
- 原始记忆
- 复杂项目需要详细展开，日常问题可以简洁。
- 用户操作
- 只要求当前回答缩短。
- MemoryTab 状态
- 错误新增“用户永远偏好简短回答”。
- 底层状态
- 一次性指令被保存为全局长期偏好。
- 后续 Agent 回复
- 之后所有任务都被压缩，包括需要详细推理的复杂项目。
为什么判定失败
系统没有识别“这次”的时效范围，也没有区分当前指令与长期偏好。
失败归因
- 模型理解
- 长期与临时信息边界
- 记忆提取策略
优化方式
- 识别时效词和适用范围
- 不确定时谨慎写入
- 单独建立边界场景评测
如何加入回归测试
本轮验证回答变短，下一轮复杂任务验证长期偏好未被改写。
Bad Case 04
新旧项目状态同时保留
“Schedule 已经结束，现在主要负责 MemoryTab。”
- 原始记忆
- 当前项目为 Schedule。
- 用户操作
- 将当前项目更新为 MemoryTab。
- MemoryTab 状态
- Schedule 和 MemoryTab 都被显示为当前项目。
- 底层状态
- 两条记录同时有效，没有时间状态或版本优先级。
- 后续 Agent 回复
- 询问当前工作时随机使用 Schedule 或 MemoryTab。
为什么判定失败
系统没有把“已经结束”识别为旧状态失效信号。
失败归因
- 冲突检测
- 状态变化理解
- 更新规则
- 召回优先级
优化方式
- 识别结束与切换表达
- 新状态成为当前值
- 旧项目退出当前召回
如何加入回归测试
更新后分别询问当前项目和历史项目，验证当前状态唯一且历史关系仍可正确解释。
优化闭环
从真实问题到长期回归资产
- 01
收集用户反馈和使用日志
从真实使用中发现记忆错误和不一致现象。
- 02
提取高频问题
区分可复现问题与偶发噪声。
- 03
分类场景
按写入、更新、删除、冲突、召回和异常状态整理。
- 04
构建评测用例
把问题转成有前置状态、操作和预期结果的固定用例。
- 05
制定评分标准
明确前台、底层与后续回复的端到端通过门槛。
- 06
执行测试
使用同一批测试集评估当前版本。
- 07
分析 Bad Case
定位第一个出现不一致的环节。
- 08
推动优化
调整模型理解、记忆策略、同步链路或产品规则。
- 09
同集回归
使用相同用例验证变化，避免选择性比较。
- 10
沉淀长期回归集
把历史问题变成后续版本必须通过的固定门槛。
05 / 结果与复盘
把长期记忆从底层能力，
推进成可控的用户产品
我推动 MemoryTab 从机制调研、产品设计、研发评审到正式上线，并围绕写入、更新、删除、冲突和后续召回建立固定评测与回归流程。
- 固定测试用例
- 30条
- 首轮实际测试用户
- 约 100名
- 闭环成功率
- 67.5%→85%
- 误召回率
- 18%→5%
- 01机制调研
- 02产品设计
- 03研发评审
- 04正式上线
- 05评测
- 06推动优化
长期记忆产品的核心不是让 Agent 记得越多，而是让记忆准确、可见、可纠正，并在前台、底层和后续回复之间始终保持一致。