助手跨会话又犯同一个错，因为记下来不等于会改检索
dev.to 2026-09-15 对照六家记忆产品的文档：负反馈要挂在被召回的条目上，并写明会不会改变下一次排序。只在 CLAUDE.md 里追加一句常常不够。
周二你告诉助手迁移脚本不能碰预发库，它改对了。周四新会话里，同一条错误迁移又出现。纠正已经写在记忆里，和旧做法一起被检索出来，没有东西标明哪一条失败过。Edward Izgorodin 在 2026 年 9 月 15 日的 dev.to 文章里把这件事收成一个机械问题：当某次召回的结果是坏的，记忆层有没有一个公开输入会因此改变下一次读取。跨会话重复犯错 往往卡在这里，而不是卡在「没有记笔记」。作者声明自己在做对比表中的 Mnemoverse，下面他家那一行要按利益关系读。
存下来和改变下一次检索不是同一件事
文章的区分是：存储表示错误还能再被读到；学习表示因为结果不好，系统下一步的行为变了。只把纠正写进笔记，旧记忆仍可被检索，下次会和纠正并排出现。他用各家自己的文档（他写的复核日是 2026-09-12）看有没有「明确接受负向结论」的输入、挂在什么对象上、厂商是否写了会移动什么。他声明下文没有性能数字。
| 系统 | 接受负向结论的公开输入 | 挂在 | 文档是否写了后续效果 |
|---|---|---|---|
| Cognee | cognee.session.add_feedback，文本加 1–5 分 |
某次召回答案的 ID | 要再跑 improve() 并带上 session_ids，反馈才会影响以后的检索 |
| Mem0 | POST /v1/feedback/，POSITIVE / NEGATIVE / VERY_NEGATIVE |
某条记忆的 ID | 页面写明可提交正负反馈，没有写排序会不会变 |
| Letta | PATCH /v1/steps/{step_id}/feedback |
某一步执行 | 改的是步骤上的反馈，页面没有把它连到检索顺序 |
| Supermemory | 审核：approve / decline / undo | 引擎推断出的记忆，不是你写明的那句 | 未审核的推断记忆在搜索中降权，decline 则从搜索移除 |
| Zep | 作者在可读文档和站点地图上没找到 | ||
| Mnemoverse | memory_feedback(atom_ids, outcome)，-1 到 +1 |
一次召回返回的那些记忆 | 作者称会调整以后的召回顺序，无用的降权而不是删掉 |
Cognee 是他眼中最清楚的一条：反馈打在答案上，并且文档写了怎样让它影响下一次检索（再跑 improve）。Mem0 有输入，但没写排序；它另有按项目的衰减，默认关闭，厂商原话大意是衰减可以重排候选但从不删除，动的是新旧和频率，不是对错。Letta 的反馈挂在执行步骤上，适合观测，不是「这条记忆错了」。Supermemory 审核的是「推断出的事实是否成立」，不是「这次召回是否有用」。
上下文变厚也不等于按结果学习
Supermemory 写自己的模型会从用户、任务、租户的上下文里提取；Letta 的一篇研究认为学习发生在 token 里的上下文更新，而不是权重。两者都是把更多经过放进简报，没有对上一次答案的对错下判断。Letta 同一页把 Cursor 的补全模型当作大规模从用户反馈学习的例子，并加上厂商自己的限制：改进的是所有人的补全模型，不是你的仓库，而且覆盖的是补全，不是推理和工具动作。
Claude Code 会话之间怎么带记忆，是产品功能，不是这张表里的 API。功能说明见 跨会话记忆。若那个记忆只是把旧结论再贴进新会话，它属于「存储」，要另找有没有负反馈入口。
一分钟可以做的对照
作者建议：找一条你知道是错的记忆，提一个会把它召回的问题，先在新会话里重复两三次，看顺序会不会自己变（这是对照）。再用工具允许的方式告诉它错了（接口、审核按钮或一句聊天），然后在全新会话里再问一次，避免上下文窗口里还留着上一轮。错的条目仍排第一，不能单独证明反馈没生效，因为它可以降权但还没掉出名次。若对照运行顺序不动、反馈之后顺序动了，再去读厂商对那个输入的说明。
向厂商问的四个问题，按他的顺序：有没有接受「你返回的是错的」的输入，而不是再写一条笔记；挂在答案、记忆、步骤还是推断事实上，前两者才关于召回；它移动的是正文、权重还是下次顺序，写在哪一页；谁负责在结果已经出来之后发送这条反馈。若答案是「靠 Agent 自己想起来」，那么没人调用的入口和没有入口，表现一样，错误还会回来。作者写 Mnemoverse 时也把这条限制算在自己头上：他们测到的生产流量里，显式结果反馈几乎没人发。