记忆精炼-云原生数据仓库AnalyticDB(AnalyticDB)-阿里云帮助中心

解决的问题

在未使用记忆精炼时，长期积累的记忆可能出现以下问题：

同一偏好散落在多条记忆中，Agent无法判断该用哪个值。
矛盾信息共存，旧偏好未被清理。
碎片化知识无法形成完整画像。

主要能力

能力	说明
归并重复信息	把多次表达但含义相近的记忆整理为一条更完整的结论。
消解状态变化	结合新旧信息形成当前有效状态，减少过期偏好对Agent的干扰。
补全用户画像	将分散在不同会话中的相关信息关联起来，让Agent获得更连贯的理解。
保留来源依据	精炼结果可以回溯到支撑它的原始记忆和对话，便于核验与审计。
直接参与召回	精炼结果会和原始记忆一起被搜索，应用不需要改变原有检索方式。

适用场景

用户在多次会话中反复表达偏好，例如饮食、出行、设备设置和沟通习惯。
客服、教育或企业Agent需要从长期交互中形成稳定的用户状态和任务结论。
记忆数量持续增加，需要减少重复内容，提高召回结果的信息密度。
新旧信息同时存在，需要让Agent优先理解用户当前状态，同时保留历史依据。

如何使用

模式	触发方式	说明
自动模式	每次 POST /memories 后异步触发	需设置 MEM0_ENABLE_CONSOLIDATION=true。
手动调用	POST /consolidate?user_id=xxx	无需开启自动模式，可按用户或Agent范围集中整理。

手动触发时，也可以在控制台的工具 > 记忆精炼页面操作，填写用户 ID 或 Agent ID 后点击触发精炼。

系统会把多条相关原始记忆整理成一条更完整的Observation，但不会因此丢失原始依据。业务既可以直接使用精炼结论，也可以在需要核验时回看相关记忆和原始对话。

示例

以下示例直接调用线上服务，先写入3条差旅相关的原始记忆，再触发精炼并查看结果。

说明

API Key建议通过环境变量传入，不要直接写在代码或公共文档中。

步骤一：配置服务地址和认证信息

export MEMORY_URL="https://api-longmemory-cn-beijing.opentrust.net"
export MEMORY_API_KEY="<替换为您的 API Key>"
export USER_ID="demo-user-001"

步骤二：写入3条原始记忆

curl -sS -X POST "${MEMORY_URL}/memories" \
  -H "Authorization: Token ${MEMORY_API_KEY}" \
  -H "Content-Type: application/json" \
  -d '{"messages":[{"role":"user","content":"出差坐飞机时，我总是优先选靠过道的座位。"}],"user_id":"'${USER_ID}'","async_mode":false}'

curl -sS -X POST "${MEMORY_URL}/memories" \
  -H "Authorization: Token ${MEMORY_API_KEY}" \
  -H "Content-Type: application/json" \
  -d '{"messages":[{"role":"user","content":"工作出差时，我更喜欢上午出发的航班。"}],"user_id":"'${USER_ID}'","async_mode":false}'

curl -sS -X POST "${MEMORY_URL}/memories" \
  -H "Authorization: Token ${MEMORY_API_KEY}" \
  -H "Content-Type: application/json" \
  -d '{"messages":[{"role":"user","content":"晚上七点以后出发会影响睡眠，所以我通常避开晚班飞机。"}],"user_id":"'${USER_ID}'","async_mode":false}'

三次调用都会返回 event: "ADD"，表示对应原始记忆已写入。

步骤三：触发记忆精炼

curl -sS -X POST \
  "${MEMORY_URL}/consolidate?user_id=${USER_ID}" \
  -H "Authorization: Token ${MEMORY_API_KEY}"

本次调用处理了3条原始记忆，并生成1条Observation：

{
  "memories_processed": 3,
  "observations_created": 1,
  "observations_updated": 0,
  "observations_deleted": 0,
  "status": "completed"
}

其中，memories_processed 表示本次参与精炼的原始记忆数量，observations_created 表示新生成的精炼结论数量。

步骤四：查看精炼结果

curl -sS \
  "${MEMORY_URL}/memories?user_id=${USER_ID}" \
  -H "Authorization: Token ${MEMORY_API_KEY}"

查询结果包含1条Observation和3条raw memory：

{
  "results": [
    {
      "memory": "用户在工作出差时更喜欢选择上午出发的航班，并通常避开晚上七点以后出发的航班，因为会影响睡眠。",
      "fact_type": "observation"
    },
    {
      "memory": "用户通常避开晚上七点以后出发的航班，因为会影响睡眠",
      "fact_type": "raw"
    },
    {
      "memory": "用户在工作出差时更喜欢选择上午出发的航班",
      "fact_type": "raw"
    },
    {
      "memory": "用户在出差乘坐飞机时总是优先选择靠过道的座位",
      "fact_type": "raw"
    }
  ],
  "total": 4
}

fact_type 为 observation 的记录就是精炼结果；原始记忆仍然保留，可以用于追溯和核验。

从结果可以看到，系统保留了3条原始记忆，并将其中两条航班时间偏好合成为一条更完整的Observation；座位偏好作为独立主题继续保留。

使用建议

持续服务场景使用自动模式：适合让新记忆在后台持续参与精炼。
已有大量历史记忆时手动触发：可以按用户或Agent范围集中整理一次。
先积累再精炼：多条相关记忆能够形成更有价值的结论；只有一条信息时，通常保留原始记忆即可。
与实时更新配合使用：明确的状态变化可以在写入时及时更新，跨会话的归纳总结再交给记忆精炼完成。
保留原始记忆：精炼用于提高理解和召回效率，原始记录仍可用于追溯和审计。