Hy Memory 2.0 发布：腾讯一次性开源了记忆写入器、框架和 Mac 应用

腾讯混元本周一口气发布了三样东西，而其中只有两样今天就能装上用。Hy-Memory-30B-A3B是一个 300 亿参数的混合专家模型，它的全部工作就是写记忆——决定智能体保留什么、如何措辞，以及新证据如何覆盖旧内容。Hy Memory 2.0是围绕它搭建的框架：一个名为 hy-memory 的 Python 包，覆盖聊天记忆、工作记忆和编码记忆。而MemHub则是那款应用——一个本地优先的 CLI 与 macOS 产品，能把十种不同 AI 工具中的对话历史和编码轨迹抽取到你本机磁盘上的同一个记忆库中。公告文章的标题是：Hy-Memory-30B-A3B 在各大主流记忆框架上击败了Claude Opus 5。这话就其本身而言没错，而有趣之处在于它到底领先多少：在四个框架中的三个上，差距不到 0.6 个百分点，而且整项对比只跑了每个基准的五分之一。我们追踪到的每一次服务中断与回滚都记录在Orca AI Incident Archive中，那里除了本次事件的邻近条目之外，还保存着完整的记录集。

以下所有内容要么读取自 Tencent 自己的代码仓库、包注册表和技术报告，要么被标注为 Tencent 自己的说法。这里没有任何内容被其他任何人复现过，因为截至撰写本文时，还没有其他人运行过它。

实际发布了什么，以及何时发布的

这三层在约 24 小时内先后落地，而发布说明异常具体地指出了其中哪些已经完成：

• 该模型——tencent/Hy-Memory-30B-A3B 已于 2026 年 10 月 15 日（UTC 09:52）以 Apache 2.0 许可发布至 Hugging Face，技术报告 arXiv 2610.22196 于同日提交。

• 该框架 —— hy-memory==2.0.1 于 2026 年 10 月 15 日 17:24 UTC 上传至 PyPI，且该 monorepo 于同日开源。GitHub 上的 v1.0.0 发布标签于 10 月 16 日 08:44 UTC 创建。

• 该应用 — MemHub 的发布资产已存在：按 GitHub 的统计方式，一个经公证的 macOS arm64 磁盘映像为 303 MB，另有 Linux arm64 和 x64 运行时包，分别为 245 MB 和 251 MB。Windows 被列为不受支持。

• 差距——项目自己的更新日志指出，MemHub“尚无公开发布版本”，其源码版本为 1.0.0（构建 4），且 npm 发布和 GitHub Release 制品均仍待完成。它打算使用的 npm 包 memhub-cli 在注册表中返回 404。磁盘镜像已附加在该 release 上；本应获取它们的命令行安装程序尚未发布。

最后一点值得读两遍，因为这正是正式发布与候选版本之间的区别。Apple 构建版本已经签名并完成公证，这是实打实的工作，发布页面上也已经积累了寥寥几次下载。但文档中记录的安装路径，开头是一个在撰写本文时并不存在的 npm 包。如果你这周打算试用 MemHub，请做好从源码检出的准备，而不是指望一行命令安装。

Hy-Memory-30B-A3B，该模型

配置文件是整个发布版本中最不浪漫、却最有用的文档。它描述的是一个标准且被充分理解的 MoE 形态，而不是任何异乎寻常的东西：

• 参数——总计 30B，每个 token 约 3B 激活，这正是 A3B 后缀的含义。

• 架构 — 48 层，其中 1 层为稠密层，47 层为稀疏 MoE；每块 128 个专家，采用 top-8 路由加 1 个共享专家；隐藏维度 2,048；专家中间宽度 768；32 个注意力头对应 4 个键值头，并带有查询-键归一化；一个带专家偏置项、缩放因子为 2.826 的 sigmoid 路由器。

• 上下文 — 262,144 个位置，RoPE 基数为 11,158,840。

• 存储占用 — 51 个 safetensors 分片，BF16 下约 60.1 GB。这是 Tencent 发布的唯一精度版本。

• 服务 — 该卡片是围绕 vLLM 编写的，已针对 v0.31.0 进行测试，置于兼容 O​penAI 的端点之后，并且还将 SGLang 和 Docker Model Runner 列为受支持的运行时。它没有被任何推理提供商部署，而且 Hugging Face 搜索索引中也找不到任何 GGUF、FP8 或 NVFP4 构建，也没有任何微调版本。

这种缺失就是实际障碍。一个只发布 60 GB BF16 检查点、别的什么都没有的供应商，等于在告诉你它预期这个模型在哪里运行，而答案就是一台你已经在数据中心里拥有或租用的机器。没有任何量化版本可供任何人在工作站上评估。

在 Tencent 自家的快速入门中，该模型以 reasoning_effort: "no_think" 和 temperature 0.0 驱动。记忆写入器会在每一轮对话时触发，以决定保留什么，因此进行深思熟虑是错误的取舍：它需要是确定性的、输出简短且成本低廉。这一设计选择也是该模型之所以存在的最有力论据，因为这恰恰是前沿聊天模型最为浪费的工作负载。

55.49，就该按它应有的方式读出来

​腾讯在三个记忆框架上训练了这个写入器——Mem0、MemOS 以及自家的 Hy-Memory——随后在第四个框架 EverMemOS 上对其进行评估，而该框架完全被排除在训练之外。把一个评测框架留出来，正是检验迁移主张的正确做法，而跨框架迁移恰恰是这篇论文的全部命题所在。

这些结果是 T​encent 自己得出的，且尚未被复现：

{{1}}Hy-Memory-30B-A3B{{/1}} —— 在四个测试框架上的宏平均值为 55.49。

• Claude Opus 5 — 54.62。

• DeepSeek V4.1 Flash — 53.64。

• Tencent Hy3 — 51.63.

• Qwen3.6-35B-A3B — 50.37.

• Hy3-A3B Base — 47.66，即在进行记忆专项训练之前的同一模型，标题中7.8个百分点的训练提升正源于此。

• Qwen3-30B-A3B — 44.37。

按测试框架拆开来看，优势就变薄了。对阵 Claude Opus 5，在 Mem0 上领先幅度为 54.02 对 53.43，在 Hy-Memory 上为 60.55 对 60.53，在 MemOS 上为 50.51 对 50.50，在 EverMemOS 上为 56.89 对 54.04。这四项中有三项不过是戴着桂冠的统计噪声——在 Hy-Memory 测试框架上领先百分之二个点，根本算不上领先。一个 3B 激活量的专家模型与一个前沿模型之间的全部分野，都落在那一个被排除在训练之外的测试框架上：在那里差距是 2.85 个点，而且那里的说法也最不可能被针对性地调过参。

有两个设计细节与数字本身同样重要。主矩阵中的每一个数字都基于固定的 20% 子样本，而非完整基准测试集；而且评测只改变写作模型，将评测框架、提示词、检索配置、答案模型和评判模型都固定不变。第二个选择是良好的实验规范——它隔离了被测变量——但那是腾讯的评测框架和腾讯的评判模型。请把这张表看作一个附带了代码仓库的假设：这比大多数发布当天的说法多一些东西，却又算不上一个结论。

框架数据才是更重要的主张

模型对比是 Tencent 在帖子里放的那句引语。框架对比则是那种如果成立、就会改变读者架构的对比。

在公司自己的网站上，Hy Memory 2.0 在四项基准测试中位列开源记忆框架第一——领先于 Mem0、MemOS、EverOS、OpenViking、RepoMemory 以及一个普通的滑动窗口 RAG 基线——涵盖其所涉及的三个场景：

• Chat — 在 1,527 个非对抗性问题中，LoCoMo 上达到 72.6%。

• 有效——在 MemoryArena（一套旅行规划和捆绑购物测试套件）上平均得分 55.31%，领先下一个框架 10.2 个百分点。

• 编程 — 在 CodeMemoryBench 问答上达到 64.2%，解题率为 35.6%，另外在 SWE-ContextBench 上解题率为 28.3%。

• 内存占用 — 内存存储量为输入 token 的 6.06%，而与之对比的框架则为 31.9% 至 41.2%。

占用规模这个数字才是值得借鉴的。记忆系统在生产环境中失败有两个原因：它们会忘记不该忘的东西，并且会无限制地增长。一个成本为所总结对话的百分之六的记忆库，与一个成本为百分之四十的记忆库，在运营上是截然不同的命题；而这正是关注路由与成本的受众应当关心的维度，无论准确率排序能否经得起审查。评测协议也一并公布：记忆模型 DeepSeek V4.1 Flash，回答与评判模型 GPT-5.6-sol，存储量按记忆库 token 数除以输入 token 数来衡量，且记忆库只计入生成的记忆。

腾讯还列出了内部部署——一项股票助手的召回测试，在多跳任务上提升了40分；一个知识库插件；以及一项新闻应用偏好评估，平均得分为91.68分（满分100）——涵盖金融、新闻、知识管理、办公智能体、社交和游戏。这些是该公司自己的产品指标，而非基准测试；它们应被解读为该事物确实在某个真实场景中运行的证据，而不是它能击败任何东西的证据。

MemHub 是大多数读者真正能用得上的那部分

模型需要 GPU。框架需要工程团队。MemHub 需要一台笔记本电脑。

它是一个本地优先的桌面与命令行产品，可将你已授权的 AI 工具中的历史记录整合到单一的受管运行时和单一数据目录中——因此你在某个编码智能体中设置的偏好，下一个也能直接沿用。腾讯列出了十项受支持的集成：WorkBuddy、Cursor、Codex、Claude Code、OpenCode、OpenClaw、Qwen Code、Pi、Hermes 和 DeepSeek Harness。所述数据路径为 ~/.one-memory，使用 SQLite 存储工作与编码元数据，并默认以 ChromaDB 加 Kuzu 作为存储；安全文档明确指出，该产品不会收集屏幕内容、无障碍树、OCR、剪贴板或后台音频。

值得持怀疑态度的说法，是那些关于删除的说法。CLI 区分三个层级：卸载 npm 包只会移除 CLI，memhub uninstall 会移除服务、托管运行时和 CLI 链接，但会保留你的记忆；而只有单独的 memhub delete-data 命令会删除存储——在停止运行时并确认确切路径之后。这比这一类别中的大多数工具设计得更好，而且它也是对某个安装程序尚未发布的版本中预期行为的描述。任何为了重要工作而采用它的人，都应该先亲自核实删除路径，然后再把任何自己不愿被保留的内容托付给它。

尚未确认之事，直白地说

• 没有任何形式的独立基准测试。没有运行任何第三方测试框架，没有任何榜单排名，也没有在 Tencent 之外复现任何结果。

• 未复现跨测试框架表格，尤其是留出的 EverMemOS 结果，而该结果仅凭单一供应商的一次运行就支撑着整个迁移论点。

• 未进行量化，因此无法测出低于 60 GB 的内存占用，也没有工作站级别的评估路径。

• 没有托管端点，模型卡上也未指定推理提供商。

• MemHub 尚无已发布的 npm 包，因此文档中记录的安装路径目前还无法端到端正常工作。

• 没有每次对话的成本数据。记忆写入是一种高频、短输出的工作负载；没有人公布过每次写入的 token 数，也没有人公布过支持记忆的助手按每用户每月计算的实际运行成本。

路由器适合用在哪里，又不适合用在哪里

这一点要说准确，因为很容易言过其实。Hy-Memory-30B-A3B 不在 OrcaRouter 的目录中，我们也不托管它。通往写作模型的途径是 Hugging Face 上的检查点和你自己的硬件。路由层的任何特性都不会改变这一点。

路由器所覆盖的，正是这套 harness 的另一半。记忆系统由一条写入路径和一条读取路径组成，而 T​encent 公开的评测直言不讳地说出了读取路径通常的模样：由写入方决定存什么，再由另一个前沿模型把记忆库读回来并作答。在 T​encent 自己的配置中，这两者分别是记忆模型端的 DeepSeek V4.1 Flash，以及作为作答与评判的 GPT-5.6-sol。OrcaRouter 用一个密钥同时提供两者，按标价、不加价，因此供应商的价格一有变动，我们这边当天就能生效，而不必等到下一次合同续约。

路由 DSL 正是恰好契合这一架构的那一环。它把自托管端点与托管端点组合成单次调用，而这正是记忆系统的形态——写入路径上是你自己运行的廉价专家模型，读取路径上是你租用的前沿模型。同样的设置让有风险的那部分变得可承受：把写入方指向你自己的 Hy-Memory-30B-A3B 部署，让一个通用模型置于自动故障转移之后，这样糟糕的写入路径只会让回答质量下降，而不会拖垮整个应用。这个模式值得在你让写入方跑起来之前就先搭好，因为无论写入路径是一个专家检查点，还是一个带记忆提示的通用模型，它都完全一样。

谁该行动，谁该等待

如果你运行的是带有长期记忆的智能体，并且你已经有 GPU，那么写入路径就是值得花上一周的实在之处：检查点采用 Apache 2.0 许可，而记忆写入器是一种少见的模型——它的价值可以在你自己的流量上衡量，而不是在别人的基准测试表上衡量。如果你是用户而不是运营者，MemHub 才是有意思的那个，而且也是那个要等的：等到安装程序出现，并且有 T​encent 之外的人实际跑通删除路径之后再说。如果你是根据公告的分量来选模型，那么正确的姿态正是这次发布本身所邀请的：55.49 对 54.62，在三个评测框架上是平局，在第四个上是真实差距，而第四个恰恰是没人检查过的那个。