阿里云给Agent装上长期记忆

阿里云在 11 月 2 日升级了 Memory 服务，重点面向 Personal Agent 补齐长期记忆、用户画像以及 MCP、CLI 接入能力。升级后，Agent 可以跨会话记住用户的偏好、计划和历史约定，并把这些信息持续用于后续任务，而不必每次都从一张白纸开始。(ithome.com)

Memory 是为 AI Agent 提供跨会话信息提取、持久化存储和按需召回的记忆层。 它不负责替 Agent 做最终决策，而是从对话中找出值得长期保留的信息，将其整理成事实记忆或结构化用户画像，在新会话中检索相关内容并注入当前上下文。

这次升级看起来不像发布一个新模型那样吸睛，但对 Personal Agent 的实际体验可能更重要。模型能力决定 Agent 一次能想多明白，Memory 决定它能不能在几天、几个月后继续理解同一个人。

不只是保存聊天记录

长期记忆的核心不是保存更多对话，而是从大量对话中保留正确、有效且仍然成立的信息。 如果只是把历史消息全部塞回上下文，系统不仅会消耗更多 Token，还会把闲聊、重复信息和已经失效的偏好一起交给模型。

阿里云 Memory 采用的是更接近生产系统的处理方式：先按照开发者设定的规则，从对话中提取关键信息；再判断这些信息应该新增、更新还是忽略；最后在用户提出新问题时，通过语义检索召回相关记忆。

整个流程可以概括为四步：

1. 提取： 从当前对话中识别偏好、计划、事实和历史约定。
2. 存储： 将有效内容保存为事实记忆、用户画像或技能记忆。
3. 检索： 根据用户身份和当前任务，召回最相关的记忆。
4. 更新： 当用户目标发生变化时，确认新信息并替换旧状态。

这个区别很关键。聊天记录是一份流水账，记忆系统更像一名会整理会议纪要的助理：它不仅要记下“说过什么”，还要判断哪些内容值得长期保留，以及新信息是否推翻了旧信息。

用户画像是这次升级的重点

用户画像是按照预定义字段，从对话中持续提取和更新的结构化个人信息。 开发者可以定义需要记录的字段，例如风险偏好、沟通风格、常用技术栈、工作时间、饮食限制或长期目标，而不是任由模型把所有内容混在一段摘要里。

阿里云给出的理财咨询案例很典型。用户第一次表示自己“偏稳健、半年内可能用钱、不希望有太大波动”，Memory 可以把这句话拆成三个可复用字段：

• 风险偏好：稳健
• 资金期限：半年内可能使用
• 流动性需求：较高

当用户几周后开启新会话询问另一款产品时，Agent 不需要再次追问完整背景，而是可以直接调取画像，结合产品资料和业务规则进行比较。如果用户后来表示资金两年内不用，系统也不应该把两条互相冲突的信息同时当成真相，而应先确认变化，再更新画像。

Memory 负责保存与召回，Agent 负责分析与行动。 这一边界意味着，Memory 本身不会替用户判断某款产品是否合适，也不会自动完成风险评估；它只是把正确的个人背景交给执行任务的模型、工具或 Skill。

这种分工比“让模型自己记住一切”更可靠。模型可以替换，工作流可以重构，但用户画像和历史约定作为独立数据层保留下来，不需要与某一个模型版本永久绑定。

MCP 和 CLI 让记忆进入现有工作流

MCP 是让大模型或 Agent 以统一协议调用外部工具和数据服务的开放标准。 阿里云此次提供 MCP 接入，意味着开发者可以把 Memory 作为一个标准化能力，挂到编码助手、终端 Agent 或已有的自动化流程里，而不是只能在百炼控制台中使用。

根据此次发布信息，Memory 可以接入 Codex、DeepSeek Harness、Claude Code、OpenClaw 等 Agent 工具与框架。阿里云百炼 CLI 也已将 Memory、MCP 和 Skill 纳入命令行能力，开发者可以在终端完成记忆查询、调试和 Agent 配置。(help.aliyun.com)

这对 Personal Agent 的意义比单纯新增一个 SDK 更大。一个真正可用的个人 Agent 往往不是单一聊天窗口，而是同时存在于代码编辑器、命令行、日程管理和文档工具中。如果每个入口都维护一套独立记忆，用户仍然需要反复解释背景；通过 MCP 暴露统一 Memory，多个 Agent 理论上可以共享同一套用户状态。

| 接入方式 | 适合场景 | 优势 | 主要代价 | | --- | --- | --- | --- | | REST API | 自研应用、后端服务 | 控制粒度高，可管理完整生命周期 | 需要自行处理业务编排 | | MCP Server | Claude Code、Codex 等 Agent | 协议统一，容易挂入现有工具链 | 需要管理权限与工具调用边界 | | CLI | 本地开发、自动化脚本、调试 | 接入快，适合开发者工作流 | 不适合直接承载复杂前台产品 | | 控制台 | 规则配置、检索测试、审计 | 可视化，便于排查错误记忆 | 自动化能力有限 |

不过，MCP 只能解决“怎么接入”，不能自动解决“该记住什么”。如果记忆规则设置得过宽，Agent 会保存大量无关细节；如果设置得过窄，又会在关键任务中不断失忆。长期记忆真正困难的部分仍然是信息边界、时间有效性和冲突更新。

Memory 与 Skill 是两层能力

Skill 是封装可复用任务步骤、工具和执行规则的流程单元。 如果说 Memory 保存的是“这个用户是谁、过去发生过什么”，Skill 保存的就是“这类任务应该怎么完成”。

阿里云把两者组合起来的思路是合理的。以理财咨询为例，Memory 保存用户的风险偏好和资金期限；Skill 则封装读取画像、查询产品资料、比较风险、检查需求匹配和生成说明等步骤。

同一个 Skill 可以服务不同用户，因为它每次执行时读取的是不同画像。相反，同一名用户也可以在旅行规划、健康管理、编程协作等多个 Skill 中复用同一部分偏好。

| 能力 | 保存内容 | 更新频率 | 典型问题 | | --- | --- | --- | --- | | Memory | 用户偏好、事实、计划、历史约定 | 随交互持续更新 | “这个人是谁，之前说过什么？” | | Skill | 可复用的方法、步骤和工具组合 | 由开发者维护或从轨迹归纳 | “这件事应该怎么做？” | | 模型上下文 | 当前任务消息、临时资料和召回结果 | 每次请求变化 | “现在具体要完成什么？” |

这套拆分比把提示词、用户资料和任务流程全部塞进一个超长系统提示词更清晰，也更适合审计。出了问题时，开发者可以判断是画像抽取错误、检索错误，还是 Skill 的业务步骤有问题，而不是只能笼统地归因于“模型表现不稳定”。

跑分第一，但暂时不能只看第一

HaluMem 是一个从记忆提取、记忆更新和记忆问答三个环节评估幻觉问题的 Agent Memory 基准。 它不仅检查最终回答是否正确，也检查系统有没有漏记事实、写入错误信息，或者在用户偏好变化后继续使用旧状态。

阿里云披露的近期 HaluMem-medium 对比中，其 Memory 在记忆提取召回率、准确率、F1 和记忆问答 C 指标四项获得最高分；在 PersonaMem-v2 评测中，Memory 的总体得分为 56.82，在所列 8 个系统中排名第一，并在 9 个任务维度中的 7 项取得最高分。(ithome.com)

PersonaMem-v2 是评估系统能否理解并追踪用户隐含偏好、敏感信息和偏好变化的个性化记忆基准。 它包含要求系统忘记信息、反刻板偏好、健康背景和敏感个人信息等任务，比单纯测试“是否记住用户喜欢咖啡”更接近真实产品。

但这些结果仍需谨慎解读。公开的 Memory 基准成绩会受到写入模型、回答模型、检索参数、上下文预算和评测版本影响；即使使用同一个数据集，不同测试配置也不能直接横向比较。公开项目 OmniMemEval 就明确提醒，论文公布分数与复现分数可能使用不同模型、提示词和评审方法，不应被视为完全可比。(github.com)

换句话说，56.82 证明阿里云 Memory 在其披露的测试条件下有竞争力，但还不能单凭一个总分判断它已经全面领先 Mem0、Zep、Supermemory 或 MemOS。开发者更应该关心三类指标：错误记忆率、冲突更新能力，以及在真实业务数据上的召回成本。

价格已经进入可计算阶段

阿里云 Memory 已在 2026 年 8 月 20 日开始商业化计费，费用由记忆写入、记忆检索、存储和额外模型上下文消耗组成。 官方定价显示，事实记忆写入 Pro 版为 0.03 元/次，Lite 版为 0.018 元/次；检索 Pro 版为 0.001 元/次，Lite 版为 0.00002 元/次。(help.aliyun.com)

| 计费项 | Pro | Lite | 差异 | | --- | ---: | ---: | --- | | 事实记忆写入 | 0.03 元/次 | 0.018 元/次 | Pro 使用更高质量提取策略 | | 用户画像写入 | 0.03 元/次 | 0.025 元/次 | 用于结构化画像更新 | | 记忆检索 | 0.001 元/次 | 0.00002 元/次 | Pro 包含 Rerank，价格为 Lite 的 50 倍 | | 技能记忆写入 | 0.3 元/次 | 暂无 | 面向可复用任务经验 | | 记忆存储 | 约 1.44 元/万条/月 | — | 按小时计费 |

这里最值得注意的不是存储价格，而是 Pro 与 Lite 检索之间的差距。Pro 检索通过 Rerank 对候选记忆进行二次排序，适合金融、企业服务等准确性优先的场景；Lite 跳过重排序，成本只有每千次 0.02 元，更适合高频但容错空间较大的个人助手。

服务还设置了账号级限流：全部接口合计 3000 QPM，事实记忆写入 120 QPM，事实记忆检索 300 QPM。对于普通 Personal Agent 这通常足够，但面向大量用户的消费级产品需要提前设计异步写入、批处理和流量削峰。(help.aliyun.com)

真正的风险是“记错”和“记太多”

长期记忆系统的最大风险不是忘记，而是自信地使用错误、过期或不该保存的信息。 一条错误记忆被持续召回后，会在多个任务中反复污染结果，比单次模型幻觉更难发现。

阿里云此次强调控制台可查看记忆内容、调试检索效果和追踪变更，这是产品能否进入严肃场景的关键。开发者至少需要为 Memory 建立四道边界：

• 明确哪些字段允许长期保存，避免无差别记录完整对话。
• 为计划、职位和偏好等动态信息增加时间与状态标记。
• 对敏感信息提供删除、停用和审计能力。
• 在高风险决策前，让 Agent 对关键画像进行二次确认。

用户画像也不应被理解为永久不变的标签。一个人今天偏好简短回答，不代表所有场景都不需要详细解释；一次提到预算紧张，也不等于系统可以永久把用户定义为低消费能力。好的 Memory 应该保存上下文和置信度，而不是把临时表达固化成人设。

阿里云想争的不是一个组件

阿里云正在把 Memory 从百炼内部功能变成 Agent 基础设施的一部分。 API 解决自研应用接入，MCP 连接外部 Agent，CLI 进入开发者终端，Skill 负责复用任务方法，控制台则承担规则配置与审计。

相比开发者自行组合向量数据库、Embedding、抽取模型和更新逻辑，托管 Memory 的优势是上线更快、组件更少、审计链路更完整。它的劣势也同样明显：开发者需要接受平台定义的记忆模型、计费方式与地域可用性，并评估数据治理和供应商绑定问题。

这次升级最有价值的部分不是 Agent 能记住“用户喜欢什么”，而是阿里云开始提供一套可管理、可检索、可更新、可审计并能接入第三方 Agent 的记忆层。Personal Agent 要从演示走向长期使用，记忆不是锦上添花，而是与模型、工具调用同等重要的底层能力。

模型越来越强以后，用户很快会把“回答得聪明”视为基础能力。下一轮 Personal Agent 的差异，可能取决于谁更了解用户，同时又知道哪些事情不该记。

参考来源

• IT之家：阿里云 Memory 服务升级，增强长期记忆与个性化能力 — 本次产品更新、评测成绩与接入方式的主要信息来源。
• GitHub：HaluMem — Agent Memory 幻觉评测基准，覆盖记忆提取、更新和问答环节。
• GitHub：OmniMemEval 用户记忆评测结果 — 多种记忆系统在 PersonaMem-v2、HaluMem 等基准上的统一复现结果。
• Hugging Face：HaluMem 数据集 — HaluMem-medium 与 HaluMem-long 数据集页面。