你上周刚跟 agent 交代过项目的技术栈和命名规范，今天新开会话，它礼貌地请你再讲一遍。这不是模型变笨了，是记忆没人管：上下文窗口一关，什么都没留下。10 月 16 日，腾讯混元把这个老大难摊开来做了三层，并且一口气全部开源：底层是专门管记忆写入与更新的 30B 模型，中间是记忆框架 SDK，上面是本地优先的记忆中枢 MemHub。按官方论文口径，框架层在四项基准上排开源第一；模型在自建横评里的总分还压过了闭源的 Opus 5——虽然只高 0.87 分。真值不值得上手？这篇把架构、跑分、许可证和局限一次说清，所有数字标明出处：官方数字标厂商口径，二手解读标二手口径，没公布的数字不编。
先把「三层全开源」这件事的分量说清楚。这一年大模型开源的常规动作是放权重：模型给你，周边生态留给自己。模型、框架 SDK、应用端三层同时放开的情况少得多——因为每一层都是单独的工程量，也都各自有竞品在打。混元这次等于把记忆这件事的完整技术栈摊开了：你可以只用它的模型，可以只用它的框架，也可以只装一个桌面端把各工具的记忆攒起来。对想研究记忆系统怎么设计的人来说，三层代码同仓，对照着看本身就省了一层逆向。
一、先说时间线和许可证
先把版本线捋清。这套系统 1.0 在 2026 年 5 月发布，当时没有开源，论文以 DCPM 的名字挂在 arXiv 上，编号 2606.09483。到 10 月 16 日发布 2.0，三层全部放出。GitHub 仓库 10 月 15 日创建，截至 10 月 20 日实测 960 星、79 fork，主体是 Python。
许可也没藏着掖着。LICENSE 原文我们 10 月 20 日实抓过，确认是 Apache-2.0，Tencent 的版权前言里明确写了「不施加任何额外限制」。有个小插曲：GitHub API 因为 LICENSE 文本不是标准模板，把许可识别成了 Other/NOASSERTION——以仓库里 LICENSE 原文为准，一句话带过，不影响结论。
仓库在这里：Tencent-Hunyuan/Hy-Memory。
仓库地址：github.com/Tencent-Hunyuan/Hy-Memory
模型权重放在 Hugging Face：tencent/Hy-Memory-30B-A3B。
权重地址：huggingface.co/tencent/Hy-Memory-30B-A3B
技术报告编号 arXiv 2610.22196，官网在 memory.hunyuan.tencent.com。单看仓库动作也算标准：README 把安装、模型下载、MemHub 使用各写了一节，技术报告负责讲方法论，公众号负责讲结论，各管一段。
二、三层全开源：模型、SDK、应用各占一层
三层怎么分，先讲清边界。
**模型层：Hy-Memory-30B-A3B。**总参数 30B、每个 token 激活约 3B 的 MoE。名字先统一一下口径：官方文档里混用过「Hy-Memory-30A3B」和「Hy-Memory-30B-A3B」两种写法，以 Hugging Face 仓库实名为准，本文统一用后者。这模型不是「记性好的聊天模型」——按智囊团公众号的解读（二手口径），它是记忆框架里专门负责记忆写入与更新的工位模型，理论上可以把 Mem0、MemOS 这些框架里的通用大模型换成它。训练分两段：记忆在线策略蒸馏，加上归因强化学习按记忆块分配功劳。训练时只见过 Mem0、MemOS、Hy-Memory 三套系统，第四套 EverMemOS 是拿来验证迁移能力的。
算一笔成本账就知道这个定位的意义。记忆写入和更新是高频操作——每轮对话都可能触发抽取、合并、冲突消解，拿 70B 级的通用大模型干这活，成本和延迟都压不住。30B 总参、3B 激活的 MoE 结构，推理开销按 3B 级算，这正是「工位模型」的逻辑：不用聪明到会写诗，只要把记忆的活干得又快又稳。
**框架层：Hy Memory SDK。**pip install hy-memory，PyPI 上当前版本 2.0.3，代码在同一个 GitHub Monorepo 里。记忆分 L0 到 L7 八层，比较有意思的是 L2 的 FACT 层做了版本化、不可变，L7 的 INTENTION 层带过期时间——意图会过期，这是把「人说话会变」写进了数据结构。运行模式分 lite、pro、ultra 三档，ultra 档始终开着 System 2 的 schema 归纳。存储后端：向量库默认 ChromaDB，可换 Qdrant、FAISS；图库默认 Kuzu，可换 Neo4j；元数据走 SQLite。
**应用层：MemHub。**本地记忆中枢，版本 v1.0.3，CLI 加 macOS 桌面端。授权关联之后，它能把你散落在各个 AI 工具里的历史会话导入，沉淀成本地记忆，新会话实时同步，插件化一键接入。目前 README 标注还在 preview 阶段。
三层可以单独用，也可以组合用：只要 SDK、不上 MemHub，可以；只想给现有框架换个记忆模型，也可以。这套分层对部署方还有一个实际好处：升级互不牵连。模型出 2.1 不用动存储后端，MemHub 迭代不影响 SDK 的接口契约——至少架构设计上是这么承诺的，实际维护成本要等社区用上一段时间才能验证。
三、三类记忆：聊天、工作、代码
这套框架最值得记的一件事，是官方口径里说的「业界首个提出工作记忆与代码记忆的记忆框架」。三类分开说。
聊天记忆很多框架都做，但混元把它升级成了事件脉络：时间、地点、人物，加上后续发展。写入前先合并重复、剥离冲突，再交给模型——而不是把对话原文堆进向量库了事。用户三月说在用 A 方案，十月换成了 B，旧结论不该和新事实并排躺在检索结果里打架。
工作记忆记的是任务状态：目标是什么、已经定了哪些做法、阶段结果、可复用的经验。关键是每条经验带适用条件，复用之前先判断当前场景符不符合——「上次这么做成了」不等于「这次也能这么做」。
代码记忆按版本演化的 diff 链来存。README 里说存的是真实 diff，零 LLM 调用，还给了句挺有性格的自我定位：「decorator, not a retriever」——它是个装饰器，不是检索器，插在开发流程边上被动记账，而不是每次都主动去检索一遍。零 LLM 调用还有一层含义：代码记忆的维护成本不随模型涨价，diff 本身就是精确记录，不存在「模型总结时记错了」这种失真。
四、跑分怎么看：两层都要标厂商口径
跑分分两层，全部是官方自报口径，社区还没有独立复现，先立此存照。
模型层：官方在固定 20% 基准子样本上，对四套记忆系统做六项指标等权平均，结果如下：
| 系统 | 总均分 |
|---|---|
| Hy-Memory-30B-A3B | 55.49 |
| Opus 5（闭源） | 54.62 |
| DeepSeek V4.1 Flash | 53.64 |
| Qwen3-30B-A3B（同尺寸开源） | 44.37 |
一个 3B 激活的开源模型压过闭源旗舰，这是标题里「干翻」的出处。但智囊团的提醒（二手口径）值得听：0.87 分的领先差距很小，真正拉开差距的是 3B 激活带来的成本差——同样的活，便宜一大截。同尺寸对比更扎眼：对上同为 30B 总参、3B 激活的 Qwen3-30B-A3B，领先超过 11 分，这组对比里没有闭源嫌疑，参考价值更高。顺带说一句表格怎么读：六项指标等权平均意味着没有单项定胜负，聊天、工作、代码各场景权重一样，总分领先说明没有明显短板，不代表每一项都赢——事实上分系统均分里四套系统有两档咬得非常紧。
框架层，四项基准均排开源第一：
- 工作记忆 MemoryArena（旅行规划与组合购物等权平均）：55.31%，领先次优 EverOS（45.1%）10.2 个百分点；Mem0 38.78%、MemOS 37.30%、Simple RAG 41.22%。
- 代码记忆 CodeMemoryBench：问答准确率 64.2%、任务解决率 35.6%，均排第一；SWE-ContextBench（Lite Related）解决率 28.3%，对上 MemOS 与 Mem0 的各 25.3%、Simple RAG 的 22.2%。
- 聊天记忆 LoCoMo：准确率 72.6%，EverOS 71.9%，只高 0.7 个百分点。但这项有个更实在的数字：每题召回 token 从 1,159 降到 703，降了 39.3%。按智囊团的解读（二手口径），聊天记忆这场真正的赢面在 token 省下的近四成——那是实打实的成本、延迟和注意力。
三类场景的存储占用，官方给了「高效果、低占用」的象限图，结论是占用都小，具体数字没在公众号里铺开，这里不编。
五、MemHub：把散落各处的会话汇成一份记忆
MemHub 值得单独一节，因为它是三层里离日常使用最近的一层。逻辑是这样：你一天里在一个工具里写代码、在另一个工具里改需求、在第三个工具里查资料，会话散落在各处，谁的记忆也不互通。MemHub 授权关联后把这些历史会话导入，沉淀成一份本地记忆，新会话再实时同步回去，插件化一键接入。
支持多少工具，两处口径不一样，并写在这里：腾讯混元官方公众号说支持 10 种 AI 工具，点名了 WorkBuddy、Cursor、Codex、Pi、Qwen Code、Hermes、DeepSeek Harness、OpenCode 等；README 则明确点名其中 5 种——Claude Code、Cursor、Codex、OpenCode、Qwen Code。哪边为准？README 是代码仓库自带的说明，相对保守；公众号口径可能含测试中的适配。用之前以你机器上的实际插件列表为准。
内部业务验证（官方口径）给了三组数。腾讯自选股接入后，多跳召回从 50% 提到 90%，整体通过率从 64% 提到 81%，综合得分从 64.3 涨到 79.6，冲突消解从 67% 提到 83%。iWiki 场景里，只用召回记忆作答的正确率 36.7%，对照提供全部原始对话的 24.7%，相对提升 48.6%——信息量少了一大截，正确率反而更高，这是记忆筛选价值的直接体现。腾讯新闻的长期偏好评测平均 91.68 分，87.8% 的案例超过 90 分。
六、上手之前，五个局限先摆清楚
以下局限均来自第三方解读，标二手口径：
一，bench 全是自建的。模型层横评和框架层四项基准都出自官方论文，公信力要等社区独立复现，目前没有。
二，Windows 用不了 MemHub。README v1.0.3 明说只支持 CLI 加 macOS，Windows 用户暂时只能用框架层 SDK 自己搭。
三，主场优势。模型训练只见过 Mem0、MemOS、Hy-Memory 三套系统，横评里对这三套的熟悉度天然更高；EverMemOS 的迁移成绩算部分补证，但不能完全消除怀疑。
四，多语言场景待验证。官方数据基本围绕英文和中文业务，其他语言没有给出数字。
五，MemHub 还在 preview 阶段，桌面端只有 macOS，接口和行为随时可能变。
这五条里，最值得掂量的是第一条和第三条的组合：自建基准加上主场优势，意味着「开源第一」这个结论目前的证据链全部来自出题人自己。不是说数字有问题，而是在社区拿这套 bench 复测 Mem0、Letta 的最新版本之前，把它当成「官方实测报告」而不是「第三方横评」来读，预期会更准。
七、现成的，和从零搭的，不冲突
最后交代分工。本站 2026 年 8 月写过一篇 AI agent 长期记忆系统搭建 SOP，讲的是怎么用 mem0、Letta 这些现成组件从零搭一套自己的记忆系统，适合想完全掌控数据与行为的团队；这篇讲的是腾讯直接给的三层现成方案，开箱即用，适合想先跑起来再说的场景。两条路不冲突：先用现成方案验证需求，再做自建，也是常见路径——先用 MemHub 攒两周真实会话，看看记忆召回在你的场景里到底有没有用，比一开始就写自建代码省得多。另外站内还有一篇讲上下文压缩的 SOP，解决的是窗口装不下的问题，和记忆系统是相邻但不同的两件事：压缩管的是单次会话里的信息密度，记忆管的是跨会话的信息存活。
常见问题
Q1：这套系统是真开源吗？许可有什么限制？ A1：是。三层全部开源：模型权重在 Hugging Face，SDK 与 MemHub 在 GitHub。LICENSE 原文确认为 Apache-2.0，腾讯版权前言明确不施加额外限制。GitHub API 因非标准许可文本识别为 Other，以仓库内 LICENSE 原文为准。
Q2：一定要用它那个 30B 模型吗？ A2：不用。三层可独立使用，框架层 SDK 单独装就能跑，PyPI 当前版本 2.0.3。按智囊团解读（二手口径），模型层定位是记忆工位模型，可替换 Mem0、MemOS 等框架里的通用大模型。
Q3：Windows 用户能用 MemHub 吗？ A3：目前不能。README v1.0.3 明确只支持 CLI 与 macOS 桌面端，且整体处于 preview 阶段。Windows 用户可先用框架层 SDK 自行搭建。
Q4：跑分可信吗？ A4：全部是官方自建基准、厂商口径，社区尚无独立复现。两点参考：模型层对 Opus 5 仅领先 0.87 分，差距很小；但 LoCoMo 每题召回 token 降 39.3% 是成本侧的硬收益。
Q5：和自己从零搭记忆系统怎么选？ A5：想开箱即用、快速验证需求，直接上这套三层方案；想完全掌控数据流与行为，参考本站 2026 年 8 月的自建长期记忆 SOP。先用现成方案跑通、再决定是否自建，是稳妥路径。
延伸阅读
- AI agent 长期记忆系统搭建 SOP：让 agent 跨会话记住你：给 agent 装长期记忆：mem0 与 Letta 上手实录
- AI agent 记忆工具横评：Mem0、Zep、Letta 怎么选：六大 agent 记忆工具横评：Mem0、Zep、Letta 怎么选
- codebase-memory-mcp 代码智能引擎：codebase-memory-mcp：AI 编程 agent 的代码智能引擎