记住旧偏好之后，Agent 能听进新的变化吗？

记错过去，和没听懂现在#

假设你上个月说过“出差尽量订早班机”，这次却补了一句：“周一上午有会，下午再走。”助手记得旧偏好，最后仍然推荐早班机。它没有完全忘记你，问题恰恰出在它记住了什么，又把哪句话当成了现在的要求。

这种错误很容易被一个宽泛的“记忆准确率”掩盖。用户需要的不是助手背出过去说过的话，而是在当前任务里用对信息。

我的判断是：记忆能力上线前，要单独验收“信息发生变化之后会怎样”。 旧信息留在记录里没有问题，继续支配新任务才是问题。

新发布给了一个值得细看的测试#

Meta 于 2026 年 10 月 12 日发布 Muse Wonder 和 Muse Wonder Full。官方把 Active Memory 描述为跨对话保留重要背景，并在需要时找回相关细节。发布时 Wonder 已提供 API 与 Muse Code 入口，Full 面向 Muse Code 订阅者；Muse 内的体验仍是后续逐步推出。

模型卡列出 1M token 推理上下文。但 Meta 的内部评测 MemoryBench 实际使用的是 64K–100K token 多轮对话，加入干扰内容、冲突信息和后续更新，再由模型裁判按加权标准评分。Wonder 得分 85.6，Full 为 85.5；表内对照 Fable 5.1、GPT-6 Astra、Opus 5.5 分别为 79.0、81.4、81.5，均标注 max 推理力度。

这些是特定评测分数，不是线上记忆正确率。相同力度标签也不代表相同耗时或计算预算；卡片提醒竞品内部测试未必最优调校。它没有给出这项测试的完整样本量、独立更新成功率、延迟和成本。不能据此断言某个产品能可靠记住用户一整年的变化。

下面的例子和验收建议是我的产品判断，并非 Meta 已经验证的方案。

先分清长期偏好和这次例外#

“我喜欢早班机”和“这次下午走”可以同时成立。如果系统简单地用最新一句覆盖全部历史，下次出差又可能误以为用户一直偏好下午。

我会给重要信息保留几个简单线索：谁说的、什么时候说的、适用于哪件事、是否已经被明确修改。展示给用户时不必是一张复杂表格，但系统需要能解释：“平时偏好早班，这次因为上午有会，改看下午。”

还有一种情况不能只看先后顺序。用户明确要求下午走，随后网页里出现“建议乘坐早班机”，外部内容不能因此覆盖用户要求。更新规则应当同时考虑来源和适用范围。

用成对的任务，找出旧信息怎样影响结果#

试点评测可以从同一份任务复制几种版本。每次只改一个条件，其他工具、可用资料和时间预算保持一致。

• 原偏好保持不变，检查助手有没有无故改动。
• 用户明确改变长期偏好，检查后续新任务是否跟着更新。
• 用户只提出本次例外，检查当前任务是否遵守、下次是否误用。
• 加入与任务无关的聊天，检查关键变化是否被淹没。
• 加入与用户要求冲突的外部资料，检查助手是否错误接受。

验收不能停在“它复述对了”。要看最终推荐、生成的草稿或待确认操作。例如回答里说“下午出发”，实际方案里却排了早班机，仍应算失败。

我会把“用了过期信息”“丢了仍有效的偏好”“把本次例外当成长期变化”分别记录。它们需要的修复可能不同，混成一个平均分，就很难知道应该改哪里。

记忆更积极，也需要更容易纠正#

对于会长期保存的信息，用户应该能查看、修改和删除。对于影响当前行动的冲突，助手应该把关键差异说出来，而不是悄悄猜一个答案。

但也不需要每次都追问。如果本次要求足够明确，就按它继续；只有信息冲突会改变重要结果时，才问一个具体问题。否则，记忆功能虽然降低了填信息的次数，却增加了确认负担。

试点阶段可以先让助手生成建议，不直接执行高后果操作。除了上述错误，还要记录用户纠正次数、完成任务所需轮数、总耗时和调用成本。记得更多，如果换来更多返工，也未必值得扩大使用。

来源与边界#

• Meta 官方发布文章，2026 年 10 月 12 日。用于确认型号、发布日期、Active Memory 的官方定位及当时的开放范围。
• Muse Wonder Model Card，Meta，随上述发布提供。本文的上下文长度、MemoryBench 设置与得分均来自该卡；分数表在第 3 页，方法说明在后续页面。本文不把它扩展为全部任务的模型排名。
• 本文没有实际调用这两个模型，也没有验证其生产环境中的跨会话存储、删除与权限实现。来源中的能力评测不替代这些产品检查。
• 航班例子、信息范围设计、成对测试与试点指标均为本文建议，没有宣称已产生真实业务收益。

一个有用的记忆系统，既要记住仍然有效的信息，也要允许用户轻松改变主意。选型时看得分，上线时还要看：新的要求，究竟有没有改变最后的结果。