将偏好、任务事实和证据分开存储，建立可撤销、可追溯的记忆生命周期。
本文于 2026-09-12 补充整理，按 2026-08 专题归档。示例为方案设计，参数用于说明方法，不代表已上线项目或实测成果。
记忆首先是一种可管理的数据
员工说“我通常维护测试环境”，可以作为低风险偏好候选；一次工具返回“生产环境故障”，则是特定任务事实。若把两者都写进长期记忆，未来可能错误推断用户总在处理生产故障。
建议区分会话历史、任务状态、长期偏好和外部证据。业务任务事实应以权威系统为准，长期记忆不能成为工单是否创建、权限是否有效的唯一来源。
写入前设置门槛
候选记忆经过来源检查、用途判断、敏感性检查和冲突处理后再持久化。低置信度内容可以只保留在当前任务；影响后续行为的重要偏好，应允许用户查看和更正。
memory_id
tenant_id / subject_id
kind
content
source_reference
confidence
created_at / expires_at
policy_version
supersedes_id
deleted_at
这是逻辑字段设计。confidence 只能表达不确定性，不能把模型自评的高置信度当作事实认证。来源引用应能追踪到明确用户陈述或经过验证的工具结果。
读取记忆需要限定用途
检索时先按租户、主体、记忆类型和有效期过滤，再按相关性选择。一个项目的偏好不一定适用于另一个项目；私人偏好也不能在团队共享助手中默认公开。
不要把所有旧记忆放进系统提示。记忆应作为带来源的数据，并保留新指令优先和事实校验机制。来自不可信文档的文字不能因为被写入记忆，就在下一轮升级为可信规则。
当当前任务明确指定环境时，应优先使用本次明确输入，而不是用历史偏好覆盖。
冲突需要显式保留关系
用户曾偏好简短回答，后来要求详细解释，可以创建新版本并关联被替代记录。不要简单叠加两条相反偏好，让模型每次临场判断哪条有效。
任务事实变化时，应从业务系统读取当前值。如果工单已关闭，旧记忆中的“待处理”不能继续用于生成动作。
可以给不同类型设置不同过期策略：短期排障上下文较短，明确用户偏好较长；具体期限依据业务需求确定，没有通用的“所有记忆保存 30 天”。
删除不只是一条数据库标记
删除请求需要覆盖结构化存储、向量索引、查询缓存和可能的派生摘要。若记忆被合并进长期摘要，还要重新生成或移除相应摘要片段。
PostgreSQL 行级安全可以辅助隔离结构化记录，但不会替你清理向量副本和派生内容。删除完成标准必须由应用定义，备份的保留和恢复规则也要说明。
恢复旧备份或回滚索引时，应重新应用删除记录，避免已经删除的记忆再次出现。
用三个场景验收
先让用户建立偏好，再明确修改，检查新偏好生效；切换租户后，确认旧记忆不可检索；删除一条已经进入摘要的记忆，再开启新会话，检查回答不会继续复述它。
还可以比较启用与禁用记忆的任务成功率。记忆增加了个性化，却未必提升所有任务；错误记忆带来的持续影响可能比一次回答错误更难排查。
长期记忆的核心价值是稳定地复用合适信息。只有写入、读取、纠错和删除都有边界，它才是一项工程能力。
