更新记忆

什么时候需要更新

• 用户明确更正了旧信息。
• 用户偏好、计划、身份或约束发生变化。
• 旧 Summary 已经过期，但仍可能被召回。
• 业务侧发现某条记忆来源错误，需要通过治理流程降权、归档或删除。

推荐方式：写入更正 Message

用户更正信息时，把更正作为新的 Message 写入。

JavaScript

await session.addMessages([
  {
    role: "user",
    content: "更正一下，我下周三不是去上海，是去深圳。",
    metadata: {
      source: "correction"
    },
    timestamp: "2026-04-24T11:00:00Z"
  }
]);

cURL

curl -X POST "http://localhost:8000/api/sessions/session_xxx/messages" \
  -H "Authorization: Api-Key your_api_key" \
  -H "Content-Type: application/json" \
  -d '{
    "messages": [
      {
        "role": "user",
        "content": "更正一下，我下周三不是去上海，是去深圳。",
        "metadata": {
          "source": "correction"
        },
        "timestamp": "2026-04-24T11:00:00Z"
      }
    ]
  }'

GUMem 会把这条 Message 作为新的证据来源处理。后续 Summary 生成时，应保留最新或更确定的信息，并避免继续把旧信息当成当前事实。

为什么不直接改 Summary

Summary 是由 Facts 支撑的长期记忆摘要。直接覆盖 Summary 会丢失几个关键能力：

• 无法解释修改依据来自哪条 Message。
• 无法区分用户更正、系统修正和管理员治理。
• 无法追踪旧 Facts 与新 Facts 的关系。
• 删除或审计时难以定位来源。

因此，用户主动更正时，优先新增 Message；管理员修复或合规处理时，使用治理流程调整 Summary 状态。

治理状态

Summary 可以进入不同管理状态：

状态	说明
active	默认可召回状态。
deprioritized	降低召回优先级，适合低置信或可能过期的信息。
archived	归档保留，默认不应进入普通召回。
deleted	已删除或软删除，不应继续用于召回。

这些状态属于治理能力。公开文档不假设存在一个稳定的 PATCH /memory endpoint；具体接口以部署版本的后台或管理 API 为准。

检查结果

写入更正 Message 后，用同一 query 再次查询 Memory。期望结果是：

• 返回的新 Summary 反映更正后的信息。
• 如果返回 details，可以追溯到新的 Message 或 Facts。
• Agent 不再使用旧 Summary 作为当前事实。

下一步

阅读 删除记忆 了解用户要求移除记忆时的处理方式。