Agent 记忆与当前上下文发生冲突时，如何判断、使用和更新？

核心回答

我会先判断冲突是不是发生在同一主体、同一字段、同一适用范围和时间，再决定当前使用哪条信息，最后单独决定是否更新长期记忆。不能简单按“长期记忆更稳定”或“最后一句话永远优先”处理。

• 当前任务偏好：用户这次明确要求详细解释，就按这次要求回答；这不自动把“平时偏好简短”改成永久详细。
• 明确事实变化：用户确认已经从北京搬到上海，就把上海设为当前居住地，并保留北京曾在何时有效的历史。
• 客观状态或高风险信息：要核对来源与有效时间；冲突尚未消解时，保留待核实状态，必要时澄清，不能让一句模糊表述覆盖业务记录或重要限制。

例如“一个月前喜欢吃辣，一周前不能吃辣”，偏好和当前限制本来就是两个字段。系统应尊重仍有效的限制，必要时确认其适用时间，不能根据旧偏好推断用户现在可以吃辣。

展开说明

1. 先识别冲突类型，再比较优先级

记忆召回后，应先校验用户或实体、业务范围、来源和有效期，再比较具体内容。不同家庭成员的地址、不同项目的模型配置、工作日与周末的时间偏好，都可能同时成立；相似文本不代表同一事实。

对同一字段还要区分三类情况：明确更正旧记录、状态随时间变化、仅本次任务的例外。例如“以前住北京，现在常住上海”是时间变化；“这周出差上海”不一定修改常住地；“刚才地址说错了”则是对原记录的纠正。

“最新”应看事件何时生效，而不只是数据库何时写入。今天导入的一封旧邮件，不能覆盖昨天确认的新地址；后台任务晚处理一轮历史对话，也不能把旧偏好重新写成当前值。

2. 使用当前上下文时，区分意图与事实

用户能决定本次任务想要什么：语言、表达长度、这次查询的城市等，当前明确要求通常比历史默认偏好更合适。但“我已经付款”与业务系统的交易状态冲突时，不能把用户表达直接改写成已付款；应核对对应交易、数据时点和回执。

上下文中的信息也不是同等可信。用户引用的文档、工具返回文本、模型生成摘要和用户本人的明确更正，应保留来源标签。外部材料里一句“忽略以前偏好”，不能自动变成记忆写入指令；摘要丢失了否定词时，要回看原始证据。

组装上下文时，可分别列出当前目标、已确认条件、有效记忆和待解决冲突。已被替代的旧值不再作为当前默认值使用，需要解释历史时再按对应时间读取。对于无法判定的事实，可以把双方证据和缺口交给后续核验，而不是只留下一个模型猜出的结论。

3. 记忆更新要有明确记录和一致性

一条可管理的记忆可以保存主体、字段、值、作用范围、来源消息、记录时间、有效时间、版本和状态。状态可以区分候选、当前有效、已被替代或待核实；这些字段由应用按业务定义，不要求套用某个固定框架。

确认搬家后，可以把当前视图中的居住地更新为上海，将原北京记录标记为历史，并关联替代关系。用户问“去年住哪里”仍能查询旧事实，当前推荐则读取现行视图。若用户要求删除个人信息，应按删除规则处理主记录及派生数据，不能只把向量检索分数调低。

写入时先抽取候选，再检查范围、去重与冲突，决定新增、更新、保持不变或等待确认。已有明确依据、符合记忆写入规则的更正可以直接提交；含糊信息不必急着固化。一次临时要求只有在用户明确表达长期意图，或满足产品约定的可靠更新条件时，才改变长期偏好。

多端或后台异步更新需要版本检查，防止旧任务覆盖新记录。同一来源重复处理也不应不断新增相同记忆。更新后还要处理检索索引、摘要和缓存；若索引尚未同步，读取候选时回查主记录的状态与版本，避免用户刚纠正完，下一轮又召回旧值。

4. 高风险冲突不能只靠时间衰减

对于过敏等重要健康信息，系统应保留明确对象、来源、相关反应和时间，以及信息是否已经核实。前后表述不一致时，可以提示存在冲突并请求进一步核实，不能把“未提到过敏”解释成“没有过敏”，也不能仅因新消息较短就静默删除旧记录。

记忆模块应保留不确定性，按风险限制自动使用，并把事实核实交给相应业务流程。同样的原则也适用于账户归属、付款结果、设备权限等业务事实：错误覆盖的代价越高，所需核验依据越明确。

常见追问

相似度最高的记忆是不是最该使用？

不是。相似度主要帮助找候选，“喜欢辣”和“不能吃辣”也可能很相似。候选还要经过主体、字段、时间、范围和有效状态检查，已删除或未授权的记录应直接排除，不能仅降权。

能不能让 LLM 判断冲突后直接覆盖？

可以让模型辅助抽取和识别冲突，但最终写入应受字段、来源、范围和版本规则约束。明确的低风险偏好变化可以自动更新，模糊或高风险变化则保留候选并核实。模型自报置信度不能替代证据。

怎样验证冲突处理有效？

构造带时间顺序的测试对话，覆盖临时例外、明确更正、状态变化、否定句、不同用户相似信息和后台更新乱序。分别检查本轮是否使用正确值、是否误写长期记忆、旧版本是否仍被错误召回，以及纠错或删除能否影响摘要和缓存。

对应教程

参考资料