100 万 Token 上下文，为什么还需要长期记忆？

核心结论： 用户希望 AI 助手读懂一份长文档，也希望它记得上次已经确认的安排。换一个会话后，预算不用重新解释；偏好改变后，推荐能跟着调整；不想保留的信息，也有办法删除。

大上下文扩展了模型一次处理信息的范围。长期记忆关注这些信息如何延续到下一次交互，包括哪些值得保留、属于谁、何时更新，以及什么时候停止使用。

在记忆张量MemTensor，我们通过 MemOS 管理这一过程，让 Agent 能够从持续交互中积累有用信息，并在后续任务中调用。即使上下文窗口达到 100 万 Token，这些跨会话的管理需求依然存在。

四类能力，怎样配合？

上下文窗口、RAG、向量数据库和长期记忆处在不同层次，可以共同服务于一次任务。

RAG 可以使用向量数据库，也可以结合关键词、图谱等检索方式。长期记忆同样可以利用这些能力，把适合当前任务的信息送入上下文。模型负责理解和推理，记忆系统负责持续维护可供使用的信息。

看一条会变化的用户事实

周一，用户告诉旅行助手：“这趟上海行每晚预算 800 元。”周三，她补充：“公司报销，预算上限改为 1,200 元，但要靠近会场。”周五，她换一个会话继续选酒店。

此时，助手需要接上这趟行程，使用最新预算和位置要求，而用户不必重述前两次对话。如果用户问起最初的安排，助手又应该能够找到 800 元预算的历史记录。

这里还涉及信息的适用范围：1,200 元是这次出差的预算，不宜直接变成用户今后所有旅行的默认标准。记忆需要保留事实所关联的任务、时间和来源，帮助后续检索选出适用的信息。

更大的上下文为模型理解完整历史提供了空间；长期记忆则让应用能够持续维护这趟行程，并在用户回来时带入相关内容。

MemOS 怎样接上这条链路

在 MemOS Cloud 中，开发者可以提交对话消息，由系统处理并保存为记忆，再在后续请求中检索使用。围绕上面的旅行场景，可以把这一过程理解为三个环节。

把不同用途的信息组织起来。

MemOS 支持事实、偏好、属性、事件、技能、工具和知识库记忆。事实和事件可以记录行程条件与相关安排，偏好用于辅助个性化推荐，知识库则可以提供公司的差旅制度。检索时，应用可以选择需要的记忆种类，并让用户记忆与知识库内容共同参与，为酒店推荐提供更完整的依据。

让记忆跟上用户的变化。

MemOS 的时间感知帮助检索区分当前信息与历史记录。预算调整后，当前任务应使用新的条件；回顾最初计划时，仍可以查询此前的信息。对于需要纠正的内容，开发者可以按记忆 ID 修改，也可以通过自然语言反馈提交“这次预算已经改了”这样的说明，由系统定位并更新相关记忆。

让用户能够管理被记住的内容。

MemOS Cloud 提供记忆删除能力，支持在项目内删除指定记忆或某个用户的记忆；开启 Agent 独立记忆后，也支持按 Agent 删除。应用可以将这些能力接入用户设置或客服流程，并同步处理自己保存的相关副本，让记忆管理成为产品体验的一部分。

先从一个真正需要记忆的任务开始

一次性的文档分析，可以优先利用大上下文和按需检索。对于持续服务的旅行助手、客服 Agent 或研发助手，长期记忆能帮助用户接着上次的进度继续工作，减少重复说明，也让已经确认的信息得到复用。

接入时，我们建议先选一个具体场景，走完四个动作：跨会话找回信息、修改一条事实、检查不同用户的访问范围，再删除一条测试记忆。观察这些变化是否反映在后续回答中，就能判断记忆是否真正服务于任务。

上下文容量决定一次能放入多少信息。用户持续使用一个 Agent 时，更容易感受到的是：它能否接上已有的安排，并随着新的需求一起调整。长期记忆让这种连续性成为可以设计和维护的产品能力。

关于记忆张量MemTensor

记忆张量（上海）科技有限公司（以下简称“记忆张量MemTensor”）是由上海算法创新研究院孵化，并由中国科学院院士担任首席顾问的新一代大模型与长期智能基础设施企业。

公司以“低幻觉、个性化、自我学习进化”为核心，长期聚焦大模型长期记忆与持续学习问题，围绕 Memory³ 相关记忆机制研究、MemOS 记忆操作系统、Agent 和记忆基础设施产品化，以及记忆原生通用基座模型，构建从理论探索、系统工程化到模型层探索的递进式技术路线，推动 AI 从一次性生成走向长期智能。

公司已与招商、海诚、荣耀等重要合作伙伴建立深度协同关系，并在 AI 陪伴、游戏、端侧智能硬件、金融及工业等多个重点行业实现商业化落地，先后累计完成近两亿元融资，由中金、孚腾、华为哈勃、商汤、和玉等众多知名投资机构参投。