记忆不是聊天记录仓库
用户说“下次记得我的偏好”，产品很容易把需求翻译成“保存更多历史对话”。在短演示里，这似乎有效：模型看见之前说过的话，就能给出更连贯的回答。
一旦任务跨天、跨版本或涉及真实动作，这个做法会迅速失效。聊天记录里混着事实、猜测、旧状态、重复解释和已经过期的决定。把它们全部塞回上下文，不但成本越来越高，还会让系统无法回答一个关键问题：这句话现在还算数吗？
可靠记忆的起点，不是保存得更多，而是把不同信息分开。
五类信息，五种责任
工作上下文是模型当前完成这一步所需的最小视图。它可以被压缩和重建，不应成为长期事实真源。
运行状态记录一次任务的对象、权限、预算、已完成步骤、等待与终止状态。它只能由受控事件修改，不能被自然语言摘要悄悄改写。
长期知识是跨任务复用、经过批准的规则、术语和产品信息。它要有 Owner、版本、生效范围和删除机制，不应自动吸收某次对话中的临时判断。
过程轨迹用于诊断和评测，记录系统读取了什么、选择了什么、调用了什么工具、在哪一步第一次偏离。它可能敏感，不应每轮全部暴露给模型或所有操作者。
版本成果是可复用的报告、证据包、草稿或解析结果。它有来源和版本，可以失效和重建，却不能替代任务状态机。
这五类信息可能在界面上同时出现，但保存、访问和更新规则完全不同。把它们统称为 Memory，会让责任消失。
摘要不能改写硬事实
长任务需要压缩上下文，这是现实。但压缩不是“把聊天写短”，而是一场有验收的数据迁移。
对象标识、金额单位、权限、截止时间、禁止动作和当前状态，属于硬字段，应当原值保留并做确定性比较。证据可以只留索引和版本；已经完成的判断可以形成工作摘要；寒暄和被正式成果替代的中间草稿则可以丢弃。
如果压缩前写着“只允许生成草稿，禁止正式提交”，压缩后只剩“协助完成提交”，意思看似接近，风险却完全不同。此时系统应该拒绝新摘要，回到上一版本，而不是继续运行。
记忆设计的质量，不在于模型能复述多少历史，而在于关键约束能否跨越压缩、重启和版本变化保持不变。
跨天恢复靠账本，不靠模型记住
想象一个任务发出外部请求后等待回复。第二天系统被唤醒，首先要确认的不是“我们昨天聊到哪了”，而是：委托是否仍有效，等待项是否还开放，对象版本有没有变化，旧请求是否已经产生结果，这条回复是否重复或过期。
这些问题需要稳定标识、状态记录、回执和事件版本。来源真实的回复也可能已经失效；用户已经取消，或者对象已经更新。只有先读最新状态，才能决定这条旧事件是否允许推进任务。
所以，可恢复 Agent 的核心不是超长上下文，而是把承诺、工作、唤醒、成果和外部动作分别记账。
写入长期记忆之前，要过一道门
不是用户说过的每句话都值得长期保存。一条信息进入长期记忆前，至少要回答：
- 它服务什么明确目的，是否真的需要跨任务复用；
- 谁提供、谁确认，来源是否可能变化；
- 适用于哪个用户、角色、组织和时间范围；
- 谁可以读取和修改，是否会被用于新的任务；
- 何时过期，用户怎样查看、更正、删除或撤回；
- 删除后，索引、缓存和派生摘要怎样同步失效。
没有这些答案，“更懂用户”很容易变成无法治理的个人数据仓库。
个性化不是无限保留
反对无限记忆，不等于反对个性化。好的个性化通常来自少量、明确、可见的偏好：语言、表达长度、常用格式、已确认的工作约束。它们应该允许用户查看和修改，并在不再需要时删除。
相反，把每次聊天都当作隐含偏好，会把偶然表达固化为人格判断。用户在一个场景里的临时选择，也可能被错误带到另一个场景。产品需要定义作用域，而不是让模型自己猜“这个人一直都这样”。
记得住，不等于信得过
一个系统能在下次对话里提到旧信息，只证明它保存并取回了内容。它没有证明内容仍有效、允许使用、没有被新事实推翻，也没有证明用户知道它被保存。
记忆是一组数据与产品责任：分类、来源、状态、权限、版本、保留、删除和恢复。把聊天记录全存下来很容易；让系统只在正确的时间，以正确的权限，使用仍然有效的信息，才是真正困难的部分。