11 月 2 日，阿里云宣布对其 Memory 服务做了一次全面升级，方向很明确：面向 Personal Agent（个人助理类智能体）场景，加强用户偏好、计划和历史约定这类"跨会话信息"的记忆能力，同时开放了 MCP、CLI、API 三种接入方式，可以直接挂到 Codex、Claude Code、DeepSeek Harness、OpenClaw 这些工具上。

说白了，就是给智能体配一块外置硬盘，让它下次开新会话时不用从"你好，请问有什么可以帮您"重新开始。

记忆这件事，本质是四个动作

不管包装成什么名字，长期记忆系统干的事都是四步：提取、存储、检索、注入。

• 提取：一轮对话结束后，挑出"值得记住的东西"，比如你说是做运营的、下周三要去趟杭州。
• • 存储：把碎片结构化成记忆条目，或者归纳成"用户画像"。
• • 检索：下次提问时，按语义把相关的几条捞出来。
• • 注入：拼到 prompt 里，让模型在回答前"看到"。
    这次升级相对以前的变化在两处。一是从"存原始对话"转向"存画像 + 结构化记忆"，据官方说明，会从对话中实时提取关键信息，按规则自动保存为用户画像与结构化记忆，并支持在控制台自定义画像字段和记忆规则。二是接入口从 SDK 扩展到 MCP 和 CLI——这个改动对开发者更实在，不用改代码，改个配置文件就能让手边的 AI 编程工具拥有跨会话记忆。

没变的是底层逻辑：它仍然是一个套了语义检索的 RAG，只是检索对象从文档换成了"关于你的事实"。RAG 那些老问题，一个都不会少。

榜单分数要拆开看

官方给出的评测结果是有具体数字的：在 HaluMem-medium 对比中，其记忆提取的召回率、准确率 F1 和记忆问答指标均为最高分；在 PersonaMem-v2 评测中总体得分 56.82，在 8 个参评系统中排第一，9 个任务维度里拿了 7 项第一。

排第一是事实，但 56.82 这个绝对分值更值得留意——它意味着一半左右的任务还是没答对。

更值得参考的是今年被 EMNLP 2026 主会接收的 HaluMem 基准，它把评测拆到记忆提取、更新、问答三个环节，测了 Mem0、MemOS、Zep 等六套主流方案。据报道，几个结论相当扎心：

• 在中等长度上下文的测试集上，部分方案的记忆召回率只有 42.91%，另一些低到 14.55%；把上下文拉长到百万 token 量级并插入无关对话后，召回率进一步掉到 3.23% 这个级别。
• • 有的系统召回率高，但"虚假记忆抵抗能力"只有 28.85%——也就是助手自己瞎编、用户没确认过的细节，被当成事实写进了长期记忆。
• • 更新环节，主实验里所有系统的"更新幻觉率"都低于 1.2%，看着很漂亮，但遗漏率在长上下文下有五套超过 60%，其中两套达到 98% 以上。旧信息根本没被改掉，只是"没改错"，不能说明它改对了。
• • 统一问答设置下，所有受测系统的正确率都没到 70%。
    这几条放在一起看，结论很清楚：记忆系统现在的主要矛盾不是"记不住"，而是"记错了自己不知道"。写入时记歪了，后面检索再精准，也只是更准确地找回一个错误。

想接入，先想清楚三件事

第一，什么时候值得接。

判断标准很简单：用户是否会重复交代同一件事。客服、教务、理财顾问、个人助理，这些是刚需；一次性的数据处理脚本、单轮问答机器人，接记忆只会增加成本和故障面。

第二，接进来之后，注入策略比存储策略更重要。

记忆检索出来不是越多越好。常见的坑是 top_k 设得太大，一次塞七八条进去，其中三条是过期的，模型就开始一本正经地用旧信息回答。文档里的建议是 top_k 控制在 3 到 10 之间，这个范围是合理的起点。

用百炼的长期记忆 API，一轮对话结束后写入、下一轮提问前检索，大概长这样（接口来自官方文档，DASHSCOPE_API_KEY 需要自己配）：

# 每轮对话结束后写入
curl -X POST https://dashscope.aliyuncs.com/api/v2/apps/memory/add \
  --header "Authorization: Bearer ${DASHSCOPE_API_KEY}" \
    --header "Content-Type: application/json" \
      --data '{
          "user_id": "user_001",
              "messages": [
                    {"role": "user", "content": "以后周报别用表格，用条目列就行"},
                          {"role": "assistant", "content": "好的，已记录"}
                              ]
                                }'
                                ```
```bash
# 下一轮提问前检索
curl -X POST https://dashscope.aliyuncs.com/api/v2/apps/memory/search \
  --header "Authorization: Bearer ${DASHSCOPE_API_KEY}" \
    --header "Content-Type: application/json" \
      --data '{
          "user_id": "user_001",
              "messages": [{"role": "user", "content": "帮我把这周的工作整理一下"}],
                  "top_k": 5
                    }'
                    ```
Python 侧官方提供 `agentscope-runtime` 里的 `AddMemory` / `SearchMemory`，需 `>=1.0.5`。接入本身不难，工作量在**什么该记、记成什么粒度、新旧冲突以谁为准**。

**第三，隔离和清理必须一开始就设计。**

- **按用户隔离**：`user_id` 是检索的边界，不能出现跨用户串记忆。多租户系统里这个字段最好由后端从登录态推导，别让前端传。
- - **可删除**：留好按 ID 删除和全量清空的接口。用户说"忘掉我刚才说的"，你得真能删掉。
- - **冲突处理**：同一个人三个月前说"预算五万"，上周说"预算砍到两万"，两条都存着，命中哪条全看语义相似度。要么写入时去重覆盖，要么注入时按时间排序并显式标注时间。
- - **成本**：别每轮都把记忆目录整个塞进系统 prompt。那是固定开销，条目越多越贵。按需检索取回，才是长期成本能控住的关键。
## 自建还是上云

如果团队已经在用 Mem0 这类开源方案，迁移成本不高——不少云厂商的记忆服务做了 Mem0 兼容，接口层能对得上，改的主要是配置。

但我倾向于这样分：

| 情况 | 建议 |
|---|---|
| 做原型、验证记忆有没有用 | 直接用云服务，别自己造 |
| 只涉及偏好、日程这类通用信息 | 用云服务，省掉向量库运维 |
| 含业务实体、权限敏感的字段 | 自建，或至少自己掌控存储 |
| 要和已有知识库、鉴权打通 | 自建，外部服务接不进你的权限系统 |

现在这个阶段，记忆层的技术壁垒不在"能不能存"，而在"存进去的对不对、该更新的时候有没有更新"。这块各家都还在补课，指望换个服务商就彻底解决，大概率会失望。

我的建议是：先把记忆当成一个**有状态的、会出错的依赖**来对待。写入时留痕，检索时打印命中了哪几条，回答错了要能回溯到是"没记住"、"记错了"还是"记对了没用上"。没有这层可观测性，出问题时你连从哪儿查都不知道。

---

Agent 从"能干活"到"能长期一起干活"，中间隔着的就是这一层。但记忆这玩意儿有点像备份：平时感觉不到价值，出问题时才知道有多重要。你的项目现在给 Agent 加记忆了吗，自建还是托管，评论区聊聊。