AREXOpen in interactive Feed

AREX Feed Article

腾讯混元发布 Hy Memory 2.0：开源记忆模型、框架与 MemHub，官方称跨框架胜过 Opus 5

October 16, 2026

腾讯混元官方 X 账号 @TencentHunyuan 于北京时间 10 月 16 日 17:31 ，宣布推出 Hy Memory 2.0。这套面向 LLM 智能体的记忆方案包含三部分：开源记忆模型 Hy-Memory-30B-A3B、覆盖聊天、工作与代码三类记忆的 Python 框架，以及提供 CLI 与 Mac 版本的 MemHub，官方定位是「私人记忆管家」（private memory steward）。帖文附带的 与 当天均可访问，PyPI 上的 SDK 包 则在 10 月 15 日已经上线。

帖文中最核心的性能主张有两条：官方称在 4 项基准上居开源第一（#1 open-source on 4 benchmarks），并称 Hy-Memory-30B-A3B 在主要记忆框架下胜过 Claude Opus 5。同一发布附带的模型技术报告（，10 月 15 日公开）给出了具体成绩：四个记忆评测框架（harness）的宏平均得分 55.49%，对比 Opus 5 的 54.62%。但其中两个框架的优势分别只有 0.02 分和 0.01 分，且全部数字来自腾讯自己的评测。

图：Hy-Memory-30B-A3B（深蓝）与 Claude Opus 5、DeepSeek V4.1 Flash、Qwen3.6-35B-A3B 在四个记忆框架上的宏平均得分（图源：arXiv:2610.22196 论文图 3）

PyPI、GitHub、Hugging Face 三处制品均已上线

把这次发布拆成了三件事：10 月，SDK 以 hy-memory==2.0.1 发布到 PyPI，同时开源包含 MemHub 的 monorepo；同月，Hy-Memory-30B-A3B 权重（30.1B 参数、约 3B 激活的 MoE 混合专家模型，BF16 精度）登上 Hugging Face，附带同一篇技术报告。PyPI 页面与 arXiv 页面显示的时间均为 10 月 15 日，也就是说制品先上线，官方帖文晚了约一天。仓库以 Apache-2.0 许可开源，同步上线，把三层结构写成「模型、框架、应用三层全开源」。官网时间线还显示，2026 年 5 月的 Hy Memory 1.0 只以论文和产品形式发布、未开源；这一次是模型、SDK 与 MemHub 首次一并开放。腾讯介绍称，Hy Memory 已在腾讯内部金融、资讯、知识管理、办公 Agent、社交娱乐和游戏等领域的多个业务中使用。

仓库新闻列表还记录了此前的节点：8 月，双过程记忆系统论文《Memory Beyond Recall》被 EMNLP 2026 接收（）；9 月，团队放出面向长程编码智能体的 CMB 编码记忆基准论文，投稿 ICLR 2027。

聊天记忆分七层，代码记忆带版本演化链

框架按三类场景组织记忆。chat 场景处理闲聊、个人信息与偏好，官方架构图称之为「七层认知记忆」，层级标签从 L0 排到 L7：原始对话逐层抽象为原子事实、会话摘要、身份画像、心智模型（SCHEMA）和带过期时间的意图（INTENTION）；更新不覆盖旧记录，而是通过 supersede 链把新旧状态连起来，历史可以回溯。ultra 模式下，显式调用 evolve() 会触发一次「System 2」扫描，归纳跨领域的心智模型。

图：Hy Memory 的三场景架构（图源：GitHub 仓库 Tencent-Hunyuan/Hy-Memory）

working 与 coding 共用一套两层结构：每开一个会话恰好写一条「事实层」记录（这个会话做了什么、结果如何），经验层则存可复用的做法，数量不限但必须过价值阈值。coding 场景在此基础上多一条版本演化链。仓库文档解释了原因：事实提取刻意不存代码本身，只记文件、函数、分支这些坐标，所以后来被回滚的代码版本不会出现在事实里；演化链以零 LLM 调用存下每一版真实 diff，按 user_id 加 workspace_id 隔离，搜索时以 chain_block 附在结果后面。

工程上，SDK 分 lite、pro、ultra 三档，lite 只做向量读写、不调 LLM；存储内置 ChromaDB 与 Kuzu，可选 Qdrant、FAISS、Neo4j 和 MySQL；配置只需要一个 OpenAI 兼容的 LLM 端点和一个 embedding 端点。

模型只干一件事：决定记忆写什么

技术报告的出发点是：外部记忆系统的质量取决于执行「写路径」的模型，而现有框架普遍把一个通用 LLM 放在框架专属提示词后面，既抬高服务成本，换一个框架又不能复用。Hy-Memory-30B-A3B 的做法是直接顶替 Mem0、MemOS 和 Hy-Memory 内部的通用 LLM，决定什么值得存、存得多精确、新证据如何更新记忆库；按论文的说法，它还能直接迁移到从未参与训练的框架 EverMemOS。

训练分两阶段。第一阶段是记忆在线策略蒸馏（Memory On-Policy Distillation，OPD），在真实 harness 里学各框架的写协议，教师是冻结的 Hy3 旗舰模型，只做前向、返回 top-50 概率分布；第二阶段是归因强化学习，以 chunk（一次写入输入，约十轮对话）为单位做 GRPO，奖励由逐 chunk 探针、跨 chunk 归因和库增长惩罚构成，训练数据包含 164,576 条正例探针和 8,599 条专门诱捕「不该存的东西」的陷阱探针。部署侧，模型卡给出的实测环境是 vLLM 0.31.0，走 OpenAI 兼容 API，关闭思考模式。

官方成绩单：框架层与模型层的两套口径

帖文没有说明「4 项基准」挂在哪一层。的口径是框架层成绩：在聊天、工作、代码三类场景的 4 个 benchmark 上，对比 Mem0、MemOS、EverOS、OpenViking、RepoMemory 和 Simple RAG 等开源框架，Hy Memory 均为开源框架第一。四项数字是：聊天记忆 LoCoMo 准确率 72.6%；工作记忆 MemoryArena 旅行规划与组合购物平均分 55.31%，领先次优的 EverOS 10.2 个百分点；代码记忆 CodeMemoryBench 问答准确率 64.2%、任务解决率 35.6%；SWE-ContextBench 解决率 28.3%。转述的腾讯介绍还补充了两处对比：LoCoMo 上次优的 EverOS 为 71.9%，聊天记忆每题 Token 消耗从 1,159 降到 703、减少 39.3%；SWE-ContextBench 上 MemOS 和 Mem0 的解决率为 25.3%。腾讯并称 Hy Memory 是「业界首个提出工作记忆与代码记忆的记忆框架」。

模型层的对比是另一套口径，出自 arXiv 报告：Mem0、Hy-Memory、MemOS 和未参与训练的 EverMemOS 四个评测框架（harness）。评测协议刻意只换一个变量——「写手」：框架版本、提示词、检索配置、答题模型和评审全部冻结，主表在固定的 20% 抽样上运行，每个框架的得分是六项指标的等权平均（LoCoMo Judge、LongMemEval、PersonaMem-v2、Travel SPS、Shopping PS 和 CMB）。按这套口径，Hy-Memory-30B-A3B 在四个框架上全部排名第一：Mem0 得 54.02，对 Opus 5 的 53.43；Hy-Memory 60.55 对 60.53；MemOS 50.51 对 50.50；EverMemOS 56.89 对 54.04。总体宏平均 55.49 对 54.62。其余对比对象中，DeepSeek V4.1 Flash 得 53.64，Qwen3.6-35B-A3B 得 50.37，同规模的 Qwen3-30B-A3B 只有 44.37。

需要标注的是：两套数字全部是腾讯自报，模型评测跑在固定的 20% 抽样上；论文自己的 Limitations 一节也把「不显著的差距（non-significant margins）」列为归因评估的局限。截至发稿，公开渠道可见的评测数字均出自腾讯自己的报告、官网与模型卡。

MemHub：本地一份记忆，CLI 加 Mac，Windows 暂缺

官网把三层交付物分别标给记忆系统研究者、Agent 开发者和 AI 工具用户，MemHub 对应最后一层：一个本地优先的桌面与 CLI 应用，把用户授权的多个 AI 应用的对话历史和编码轨迹汇总成同一份本地记忆，各应用在单独授权后可以复用。帖文称 MemHub 能跨 10 余款 AI 工具同步记忆；转述的官方介绍列出了其中八款——WorkBuddy、Cursor、Codex、Pi、Qwen Code、Hermes、DeepSeek Harness 和 OpenCode；点名的授权应用则是 Claude Code、Cursor、Codex、OpenCode 和 Qwen Code 五款，两份清单只有部分重合，Greg Glazewski（）在回复中指出帖文的「10+」与 README 列举的五款对不上。仓库的则收录了 Claude、CodeBuddy、Codex、Cursor、DeepSeek、Hermes、OpenClaw、OpenCode、Pi、Qwen、WorkBuddy 共 11 款工具的标识。

发行形态上，npm 包 memhub-cli 只是一个约 384 KB 的引导程序，用户显式执行 memhub install 后才下载完整 Runtime；数据默认放在 ~/.one-memory。v1.0.0 的目标平台是 macOS arm64/x64 的 App 与 Runtime、Linux x64/arm64 的 Runtime，Windows 不支持；macOS 制品走 Developer ID 签名和公证。文档写明了采集边界：不采集屏幕内容与 Accessibility 树、不做 OCR、不监听键鼠、不读剪贴板、不录音。MemHub 没有独立仓库： 目前返回 404，代码就在 Hy-Memory 仓库的 memhub/ 目录里；在回复中报告过点进 404 的经历。

首日反馈：欢迎之外，追问集中在记忆机制上

发布约两个半小时后的检索快照显示，帖文获得 380 余个赞、29 条回复和约 1.6 万次浏览；在 18:18、即帖文发出约 47 分钟后发出报道，转述官方口径。欢迎的声音之外，具体的追问大多落在机制上。Vik（）说 30B-A3B 的尺寸「小到能住进家里的机器」，但他想知道十个工具写入冲突事实时 MemHub 如何仲裁；Asmir（）的担心更直接：一个工具写错一条记忆，同步到其余 10 个工具，错误会跟着扩散；@CcVylree（）问的是 squash merge 和 rebase 之后，diff 链指向孤立提交时会不会悄悄失效。

中文用户问得最直接。@ajs6888（安叫兽）在里问：「记错的东西能一键让所有工具都忘掉吗？」SDK 提供 client.delete(id) 这样的单条删除，但 MemHub 文档面向用户的删除命令是 memhub delete-data——先停止 Runtime、再二次确认精确路径，删的是整份记忆库。帖文里那两条性能主张的第三方复现，截至发稿仍未出现。

参考链接

  • 腾讯混元官方帖文（@TencentHunyuan）：
  • Hy-Memory 2.0 官网：
  • IT之家报道：
  • GitHub 仓库 Tencent-Hunyuan/Hy-Memory：
  • PyPI：hy-memory 2.0.1：
  • Hugging Face 模型卡 tencent/Hy-Memory-30B-A3B：
  • 技术报告 arXiv:2610.22196：
  • MemHub README：
  • MemHub 界面资源目录 r6/：
  • 《Memory Beyond Recall》（arXiv:2606.09483）：
  • github.com/Tencent-Hunyuan/MemHub（返回 404）：
  • @Greg_GL_87 的回复：
  • @uctive 的回复：
  • @asmirkn 的回复：
  • @CcVylree 的回复：
  • @ajs6888 的回复：
  • @liewcf 的回复：