AI 快讯腾讯开源混元记忆2.0,让Agent接着干
行业快讯

腾讯开源混元记忆2.0,让Agent接着干

2026-10-16T12:03:26.067Z
腾讯开源混元记忆2.0,让Agent接着干

腾讯10月16日发布并开源Hy Memory 2.0,将聊天、工作与代码记忆统一接入Agent。相比单纯保存历史,它更关注任务续接、决策追溯和经验复用,官方评测同时展示了准确率与Token效率的改善。

腾讯把 Agent 的记忆能力,从“记住聊过什么”推进到了“记住事情做到哪一步”。10 月 16 日,腾讯混元宣布发布并开源 Hy Memory 2.0,提供专用模型、记忆框架和 MemHub 应用三层能力,新增工作记忆与代码记忆,开发者可通过 SDK 将其接入 Agent。

Hy Memory 2.0 是腾讯混元面向智能体的记忆框架,用于管理跨对话、跨任务的历史信息,并在后续执行中找回相关事实、决策和经验。 根据IT之家今日报道,三层能力可以独立使用,也可以组合成完整的记忆解决方案。目前,Hy Memory 已在腾讯内部金融、资讯、知识管理、办公 Agent、社交娱乐和游戏等多个业务领域使用。

这次更新最值得关注的,是它把任务状态和经验的适用条件纳入了记忆管理。对需要连续工作几天、反复修改方案或跨会话维护代码的 Agent 来说,记住用户喜欢什么只是起点;记住为什么否决过一个方案、哪个阶段已经完成、旧经验现在还能不能用,才直接影响执行质量。

Hy Memory 2.0 三层能力示意图:底部为专用模型,中间为统一管理聊天、工作和代码记忆的框架,上层为 MemHub 应用;在框架侧标注通过 SDK 接入 Agent,以及存储、更新、经验复用与任务续接能力

新增工作与代码记忆,重点是让任务能继续

Agent 记忆是智能体在当前上下文之外保存、更新和调用历史信息的机制。 它与长上下文解决的问题有所不同:长上下文扩大一次能够读入的信息量,记忆系统则决定哪些信息值得留下、发生变化后如何更新,以及下一次任务应当取回什么。两者可以配合使用,但更大的上下文窗口不会自动完成这些管理工作。

传统的聊天记忆通常围绕用户事实和偏好展开,例如职业、常用工具、饮食习惯。Hy Memory 2.0 的变化在于,它开始把“一件正在推进的事”作为需要持续维护的对象。按照腾讯披露的设计,框架会从多个维度记录任务目标、已确定的做法、阶段结果,以及可复用经验和对应的适用条件,并按时间整理信息更新。

工作记忆是围绕任务目标、执行状态和历史决策组织的信息集合。 例如,一项旅行规划可能经历预算调整、目的地变更、住宿方案确认等多个阶段。再次启动任务时,助手需要恢复当前有效的约束,而不是把最早的想法与最后的决定混在一起。这个例子说明了工作记忆的用途,并非腾讯公布的具体产品演示。

代码记忆是服务于代码理解与开发任务的历史信息和经验集合。 对编程 Agent 而言,仅检索到相关函数还不够:此前为何选择某种实现、哪个尝试已经失败、任务目前停在哪里,同样会影响下一步修改。Hy Memory 2.0 将代码记忆作为新增能力,意味着它试图覆盖代码任务的连续执行过程。

腾讯披露的经验复用机制,核心是先判断适用条件,再决定是否调用经验。一条在特定环境中有效的处理方法,如果被无条件套用到另一个项目,可能增加错误。把“什么时候能用”与“怎么做”一起保存,比单独积累成功案例更有实际价值。

长程任务的续接也被放到了明确的位置。按照官方介绍,每次继续任务前,Hy Memory 会先判断当前处理的是哪一件事,再找回相关决定、仍然适用的经验和历史工作过程。对用户而言,这项能力真正要减少的,是重新解释背景、重复验证旧结论,以及 Agent 沿着已经放弃的路线再走一遍。

聊天记忆从事实清单升级为事件脉络

Hy Memory 2.0 对聊天记忆的调整,重点是把分散事实组织成可以追溯的事件。框架会以事件为主体,梳理跨时间、跨对话出现的时间、地点、人物等关键要素,试图保留信息之间的关系。

事件组织更适合处理“事情后来发生了什么变化”这类问题。例如,用户先说计划周五出差,几天后改成线上会议,随后又确认周四需要提前提交材料。只保存三个孤立事实,可能让助手同时保留多个相互干扰的安排;围绕事件维护更新,才有机会分清原计划、变更原因和当前状态。这同样是对其机制的场景化说明。

多线索问答还需要在召回后处理重复与冲突。腾讯介绍,Hy Memory 会先合并重复信息、剥离前后冲突,再把整理后的记忆交给模型。这里决定效果的,并不只是“找到了多少条相关内容”,还包括这些内容能否组成一致、有效的回答依据。

这一设计方向有用,但效果最终取决于更新是否可靠。新信息可能是正式变更,也可能只是用户临时提出的假设;一段历史记录可能已经失效,也可能仍然承担解释决策的作用。如果记忆系统过早合并或错误删除,模型得到的上下文会更短,却未必更准确。因此,准确率与信息处理成本需要一起看。

四个评测集,最有说服力的是哪些数字

腾讯公布的成绩同时覆盖聊天、工作和代码三类场景。按照发布信息,Hy Memory 在 LoCoMo、MemoryArena、CodeMemoryBench 和 SWE-ContextBench 四个 Benchmark 上,对比 Mem0、MemOS、EverOS、OpenViking、RepoMemory 和 Simple RAG 等开源方案取得第一;这一排名应理解为腾讯此次公布的评测结果。

Benchmark 是用于在约定任务和评分规则下比较系统表现的标准化测试集或测试流程。 记忆框架的分数还会受到基础模型、召回配置、输入预算和执行方式影响,因此评测结果适合判断能力方向,不能直接换算为所有业务中的收益。

| 场景与评测集 | Hy Memory 公布结果 | 披露的对照结果 | 可以直接读出的差异 | | --- | --- | --- | --- | | 工作记忆:MemoryArena 旅行规划与组合购物任务 | 平均分 55.31% | 领先次优 EverOS 10.2 个百分点 | 此次披露中,工作记忆的领先幅度较明显 | | 代码记忆:CodeMemoryBench | 代码问答准确率 64.2%;代码任务解决率 35.6% | 参考报道未列出对应对手的具体分数 | 代码理解与任务完成分别计分,不能混为同一指标 | | 代码记忆:SWE-ContextBench | 代码任务解决率 28.3% | MemOS、Mem0 均为 25.3% | 高出 3.0 个百分点,按对照值计算相对提升约 11.9% | | 聊天记忆:LoCoMo | 准确率 72.6%;每题使用 703 Token | EverOS 准确率 71.9%;每题使用 1,159 Token | 准确率高 0.7 个百分点;每题减少 456 Token,降幅约 39.3% |

工作记忆是这组数字里更值得优先验证的部分。MemoryArena 的旅行规划与组合购物任务平均分达到 55.31%,领先次优方案 10.2 个百分点,比聊天准确率上的 0.7 个百分点差距更突出。如果这种优势能延续到真实流程,它对应的价值是让 Agent 更好地利用前序决策推进后续任务。

聊天记忆更清晰的收益则体现在信息效率上。Token 是大模型处理文本时使用的计量单位。 LoCoMo 上每题从 1,159 Token 降至 703 Token,意味着在这项评测中,Hy Memory 用更少的相关输入取得了略高的准确率。对于高频调用的助手,这种变化值得关注。

39.3% 的 Token 降幅不能直接等同于总成本降低 39.3%。实际系统还包含记忆提取、写入、更新、存储和检索等开销,也可能涉及额外的模型调用。是否省钱,需要按完整任务链路计算;同样,Token 减少也不自动保证端到端延迟按相同比例下降。

代码任务的成绩说明记忆有帮助,也显示它仍有边界。SWE-ContextBench 上,解决率从对照方案的 25.3% 提升至 28.3%,是可量化的改善,但 28.3% 也意味着该评测中仍有大量任务未被解决。对代码 Agent 的判断仍应落在任务完成、修改正确性和回归验证上,不能只看它是否成功找回历史信息。

三层开源降低组合门槛,部署细节仍需逐项核对

Hy Memory 2.0 的开源范围覆盖专用模型、记忆框架和 MemHub 应用,提供了不同深度的采用方式。腾讯明确表示三层能力既能独立使用,也能组合使用,这给已有 Agent 系统的团队留下了接入空间,不必从产品界面到底层能力全部采用同一套方案。

| 开源层级 | 已披露定位 | 开发者需要重点核对的信息 | | --- | --- | --- | | 专用模型 | 提供记忆相关的专用模型能力 | 模型标识、参数规模、硬件要求、许可证与实际任务表现 | | 记忆框架 | 管理聊天、工作、代码记忆的存储、更新与演化,支持 SDK 接入 | SDK 接口、存储依赖、并发能力、更新策略与部署方式 | | MemHub 应用 | 作为本次开源的应用层组成部分 | 具体功能、支持的接入方式,以及与现有工作流的匹配程度 |

专用模型的性能需要与框架成绩分开判断。参考报道标题提到“专用模型性能超 Opus5”,但所提供的正文没有给出这一比较所需的完整模型名称、测试任务、评分方法和对照设置。因此,现有材料不足以支持“该模型的通用能力超过 Opus5”这一结论,也不宜据此推导它能替代通用模型。

现有材料同样不足以给出部署报价或确定的硬件成本。开源意味着开发者可以获取相应开放内容,但商用条件、部署资源和维护投入仍需依据各组件的实际许可证与文档核对。对于准备上线的团队,这些信息与榜单分数同样重要。

Hy Memory 也不应与腾讯云的 TencentDB Agent Memory 混为一个项目。后者有独立的开源仓库,同样围绕 Agent 记忆展开,但不能把它的安装方式、许可证、团队记忆能力或性能数据直接套到本次混元发布的 Hy Memory 2.0 上。名称接近,不能替代项目归属和版本核验。

真正值得测试的是“隔天回来还能不能接着做”

Hy Memory 2.0 最适合优先验证的,是需要多次续接、持续修订和复用历史决策的 Agent。一次性摘要或简单问答,对长期记忆的依赖相对有限;长期代码维护、连续研究和跨会话办公任务,才更容易暴露状态丢失、经验误用和历史冲突的问题。

开发者可以用三类真实任务判断它是否值得接入:

  • 任务续接: 让 Agent 中断后继续工作,检查它能否恢复当前目标、已完成步骤与尚未解决的问题。
  • 约束更新: 在任务中途改变需求,检查它是否正确采用新约束,同时保留必要的历史决策依据。
  • 经验复用: 给出表面相似但条件不同的任务,检查它会不会把旧项目的做法机械套用过来。

记忆的可追溯性决定了团队能否放心依赖它。真实业务中的错误可能来自原始信息、提取过程、更新过程或最终召回,排查时需要知道一条记忆从哪里来、何时改变、为何被采用。权限隔离、删除机制和冲突处理也应在接入前验证;本次提供的发布材料尚不足以确认这些能力的实现细节。

腾讯这次更新给出的方向值得肯定:Agent 的竞争正在延伸到任务如何连续完成。Hy Memory 2.0 用工作记忆与代码记忆补上了更贴近执行过程的一环,官方成绩也提供了可比较的起点。它接下来需要证明的,是在持续数天甚至更久的真实工作中,能够稳定保留正确决策、淘汰失效信息,并让用户少花时间重复交代背景。

参考来源

相关推荐

查看全部