背景：记忆从提示词技巧变成独立工程层
智能体跑得越久，记忆就越不像一个功能，而像一个系统问题。早期的处理办法很朴素：把历史对话塞回上下文，超了就压缩或摘要。这条路走到今天暴露出三个互相牵制的矛盾——摘要会丢细节，而长任务恰恰需要在中途回溯某个原始约束；全量保留会把 token 成本推高，而记忆调用是高频动作；多工具并行后，同一个用户的经验散落在不同的会话里，彼此看不见。
过去一年的行业做法是把它当成一个存储层来解：向量库加检索，或者一个结构化的记忆 store。腾讯混元这次给出的方案略有不同——它把「写什么进记忆」这个判断也一并模型化了，并且用一个体量远小于通用模型的专用模型来做。这个取舍是整套设计的轴心：如果记忆写入这件事的难题是「判断哪些值得留、怎样表述才不会在召回时失真」，那么它未必需要调用一次全量推理。
据证券时报与人民财讯的报道，Hy Memory 在腾讯内部已用于金融、资讯、知识管理、办公智能体、社交娱乐和游戏等多个业务。这一点值得单独标出来：它不是先发布再找场景的产物，而是从既有业务里长出来的，这决定了它的许多设计偏向工程可用而非指标漂亮。
Hy Memory 不负责规划、不负责工具选择、不负责生成最终答案。它的作用域止于「哪些信息该留下来、以什么形式留、什么时候取出来、取出多少」。引入它不会让智能体变聪明，改变的是智能体在长时间、多工具之间保持一致性的能力，以及为此付出的 token 成本。把它当成能力增强方案会失望，当成一致性与成本方案来评估才对得上。
三层开源：模型、框架、应用各自解决什么
2.0 版本的发布内容是三层一体的：专用记忆模型、可编程记忆框架、本地记忆应用。官方强调三者既能独立使用，也能组合成完整方案。这个「可拆开用」的设计本身就说明了定位——团队可以只换模型、只接 SDK、或者只装桌面端。
| 层 | 具体形态 | 职责 | 独立可用性 |
|---|---|---|---|
| 模型层 | Hy-Memory-30B-A3B，MoE，约 3B 激活，权重已在 Hugging Face 发布 | 记忆抽取、冲突处理、写入协议的一致性 | 可单独接入其他记忆框架使用 |
| 框架层 | Hy Memory SDK，PyPI 包名 hy-memory 2.0.2，GitHub 开源 | 三类记忆的存储、更新与演化，插拔式存储后端，向量检索与经验写入阈值 | 可搭配其他模型运行 |
| 应用层 | MemHub，本地优先，提供 CLI 与 Mac 客户端 | 导入各工具历史会话、沉淀为本地记忆、持续同步新会话 | 可只当会话归档与上下文补充工具使用 |
许可证方面，GitHub 仓库的许可文件声明 Hy-Memory 以 Apache 2.0 发布。对一个打算被集成进商业产品的组件来说，这是比性能数字更先被法务检查的东西，选择 Apache 2.0 意味着集成方不必公开自身改动。
存储后端做成插拔式这一点也值得注意。它意味着记忆不必绑定某一种数据库：团队可以先用本地文件跑通，再换成生产级存储，而不需要重写记忆逻辑。这类设计通常来自内部多业务复用的压力——不同业务的合规与部署环境差别很大，硬编码存储后端会直接挡掉一批场景。
三类记忆：聊天、工作、代码的噪音各不相同
SDK 按场景切了三类记忆形态。分开做而不是用一套统一结构硬套，理由在于三者的噪音来源完全不同。
聊天记忆的噪音来自碎片化。用户在不同时间说出的事实彼此重叠、互相矛盾，散落在几十轮对话里。2.0 的处理是把散落事实归组为带时间、地点、人物的事件，先合并重复项、先解冲突，再交给模型。这一步的关键是顺序：如果把原始冲突直接塞给模型，等于让模型在推理时顺带做数据清洗，既费 token 又不稳定。
工作记忆的噪音来自任务边界模糊。一次跨天的任务里，目标可能改过、某些做法已经被否决、中间结果有些仍有效有些已作废。这类信息如果只按时间堆叠，恢复任务时就会把过期决策一起带回来。
代码记忆的噪音来自变更频率。代码库每天都在动，任何形式的快照都会立刻过期。这一类的解法下文单独展开。
工作记忆：先判定适用条件，再复用经验
工作记忆与代码记忆是 2.0 新增的两类能力，官方称这是业内较早明确区分并提出工作记忆与代码记忆形态的记忆框架。工作记忆用多个维度记录一项任务，并按时间规整所有信息更新，内容包括任务目标、已经确定的做法、阶段结果，以及可复用的经验与经验所适用的条件。
真正有工程价值的是最后半句——经验带着适用条件一起存。官方描述中，复用经验时 Hy Memory 会先判断当前情形是否符合该经验的适用条件，仅在符合时才精准取用对应经验作为辅助。反过来说，条件不匹配时它应该保持沉默。这一步判断看起来小，实际上决定了记忆是资产还是干扰源：一条在错误条件下被召回的经验，比没有记忆更糟，因为它会以「看起来有依据」的形式误导后续决策。
针对长程任务，恢复流程被拆成两步：先判断当前在处理哪一件事，再找回相关决定、仍然适用的经验以及历史工作过程。这个顺序也有讲究。直接按语义相似度检索，很容易把同名不同事的内容混进来；先做任务识别再做内容召回，等于加了一层作用域过滤。
代码记忆：只存坐标与 diff，把版本控制搬进记忆层
代码记忆的处理方式是整套设计里辨识度最高的一处：不存整段代码，只记录代码坐标并挂载 diff。用官方与转述中的说法，这等于把版本控制那套思路搬进了记忆层。
为什么这样做合理？因为代码记忆的使用场景不是「回忆某个函数长什么样」——那种需求读一次文件就能满足，成本更低且不会失真。真正需要记忆的是「我上次为什么改这里、改成了什么、改完之后发生了什么」。这些信息天然就是差异与原因，而不是快照。存快照的问题是双重的：既浪费存储，又因为代码已经变了而失去参考价值。
把 diff 与坐标一起存，还有一个附带好处：当代码再次变动时，记忆条目可以判断自己是否还挂在有效的位置上。这等于给记忆条目装了一个过期检测器，而多数基于向量的记忆系统缺少这一层。
Hy-Memory-30B-A3B：30B 只激活 3B 的取舍
模型层是这次发布的核心变量。Hy-Memory-30B-A3B 采用 MoE 架构，总参数 30B，每次推理激活约 3B，因此推理成本接近一个 3B 模型。它的训练目标很专一：记忆抽取与冲突处理。
这个设计把成本结构改了一遍。通用模型做记忆写入，等于每次记笔记都要调用一次全量推理；专用模型只激活 3B，单次的账算得过来。在记忆写入属于高频动作的前提下，这个差异会被调用次数放大。
但代价同样明确，而且必须在引入前算清：决策模型自身的判断上限，会成为整个记忆系统的天花板。如果写入模型在复杂场景下判断失误——比如把一条关键约束判定为可丢弃——那么后续执行再快也补不回来。这不是 Hy Memory 一家的问题，所有「用小模型替换大模型做某个环节」的架构都面临同一个权衡，区别在于这个环节的失误是否可逆。记忆写入的失误是可累积的，因为错误条目会持续参与后续召回。
训练路径：蒸馏打底，强化学习对准召回
训练分两步走：先用 On-Policy Distillation，再上归因记忆强化学习，专门优化召回性能。目标被描述为让写入协议保持一致——记忆写入这件事，一致性比聪明更重要。
这句话值得展开。记忆系统的失效很少表现为「某一条记得不对」，更多表现为「格式漂移」：同样的信息在不同时间被写成不同结构，导致召回时检索不到或召回了但用不上。一致性优先于聪明，意味着训练信号主要来自「写下来的东西后面能不能被有效地取回来」，而不是「写下来的文字通不通顺」。
官方评测中有一处安排可以佐证这个取向：模型在 Mem0、MemOS 和 Hy-Memory 三套框架上训练，但在四套系统（含未参与训练的 EverMemOS）上评估，且 EverMemOS 上仍然领先。第三方转述也把这一点点出来，认为在未参与训练的系统上仍然领先，说明泛化能力站得住，而不是对着基准过拟合出来的分数。这个判断逻辑本身是对的，但要注意它的强度有限——四套系统都是记忆框架，彼此的结构差异不等于真实业务的差异。
评测读数：55.49 对 54.62 该怎么读
官方技术报告的评测设置是：在固定 20% 基准子样本上，跨四套记忆系统比较。这个设置在方法上是克制的——固定子样本避免了「挑对自己有利的题」。
| 配置 | 宏平均得分 | 与居首者的差距 | 说明 |
|---|---|---|---|
| Hy-Memory-30B-A3B | 55.49 | — | 在 Mem0、MemOS、Hy-Memory 三套框架上训练 |
| Claude Opus 5 | 54.62 | 0.87 | 通用前沿模型，非记忆专用 |
| DeepSeek V4.1 Flash | 53.64 | 1.85 | 通用模型 |
| Qwen3-30B-A3B | 44.37 | 11.12 | 同量级同激活规模的通用模型 |
读这张表要把握三点。其一，居首者与次席之间只差 0.87 分，在多数评测的置信区间内不足以支撑「明显更强」的结论；把它读作「同等水平下更便宜」比读作「更强」更准确。其二，与 Qwen3-30B-A3B 的 11.12 分差距才是真正说明「专用训练有效」的那组对照——同样是 30B/A3B 的规模，专用训练带来了两位数的提升。其三，55.49 这个绝对值本身不算高，说明记忆这件事离做好还有相当距离，各家都还在中低分区间。
还需要留意一处口径差异：中文转述中把对照系统写作 EverOS 或 EverMemOS，且一处称其为「未参与训练」、另一处将其列入对比的开源方案名单。名称与训练参与状态在不同来源间存在不一致，引用时应以官方技术报告的表述为准，本文在此仅作如实标注。
39.3% 的 token 削减从哪里来
比总分更有工程含义的是分场景的指标，尤其是那组 token 数字。
| 记忆类型 | 评测 | 指标 | 读数 |
|---|---|---|---|
| 聊天记忆 | LoCoMo | 准确率 / 每题 token | 72.6%；1159 → 703，降幅 39.3% |
| 工作记忆 | MemoryArena（旅行规划、购物任务） | 平均得分 | 55.31% |
| 代码记忆 | CodeMemoryBench | 问答准确率 / 任务解决率 | 64.2% / 35.6% |
| 代码记忆 | SWE-ContextBench | 任务解决率 | 28.3% |
39.3% 的 token 削减来自结构化与去重，而不是压缩。这两者有本质区别：压缩是通过丢弃信息换长度，结构化是通过去掉冗余表述保住信息。前者会在长任务中积累风险，后者不会。聊天记忆把散落事实归组为事件、合并重复、解冲突之后再交给模型，省下的 token 主要来自「同一件事不再重复说三遍」。
代码记忆的两个数字落差更值得琢磨：问答准确率 64.2%，而任务解决率只有 35.6%，SWE-ContextBench 上进一步降到 28.3%。这个梯度说明「记得住」与「用得上」之间还隔着相当距离——模型能答对关于代码的问题，但把记忆转成正确的代码改动，成功率要低得多。任何打算用记忆系统提升编码智能体实绩的团队，都应该盯住后者而不是前者。
MemHub：把十款工具的会话收进同一份本地记忆
MemHub 是这次发布里容易被当成附属品、实际上可能是采用门槛最低的一层。它是本地优先的记忆管理应用，提供命令行工具与 Mac 客户端两种形态。用户在授权关联应用后，MemHub 会导入各工具的历史会话，通过内置的 Hy Memory SDK 沉淀为本地记忆，此后各工具产生的新会话会实时同步汇入同一份记忆。
官方与转述来源列出的接入工具包括 WorkBuddy、Cursor、Codex、Qwen Code、OpenCode、DeepSeek Harness、Pi、Hermes 等，合计约十款，覆盖商业编程工具与开源智能体。它以插件形式一键接入，用户在任一已关联工具内发起任务时，MemHub 都可以管理和使用相关记忆作为上下文补充。
这个设计的意义在于解决「记忆孤岛」：同一个开发者上午在 Cursor 里定的接口约定，下午用 Codex CLI 执行时是看不到的。把会话统一收拢到本地一份记忆里，等于给跨工具工作流补了一条 continuity。而本地优先意味着这些记忆不出机器——对涉及未公开代码的团队，这往往比分数更重要。
也要看到它的局限：目前官方列出的客户端形态是 CLI 与 Mac 端，Windows 与 Linux 桌面端的情况官方尚未明确说明；同步能力覆盖的是已接入的这十款工具，接入名单之外的工具仍需自行适配。
路线对照：Mem0、MemOS、EverMemOS 与 OpenViking
官方称在聊天、工作、代码三类场景的四个基准上，对比 Mem0、MemOS、EverOS、OpenViking 等开源方案均取得领先。把这几类方案放在一起看，能更清楚地判断 Hy Memory 的位置。
| 方案类型 | 代表 | 核心思路 | 相对取舍 |
|---|---|---|---|
| 通用记忆 store | Mem0 | 抽取事实 + 向量召回，接入简单 | 上手快，但写入判断依赖通用模型，一致性与成本随规模变化 |
| 记忆操作系统 | MemOS、EverMemOS | 把记忆当资源管理，强调分层与调度 | 结构完整，部署与调优负担相对更重 |
| 上下文工程型 | OpenViking | 偏向上下文组织与检索策略 | 轻量灵活，长期演化的机制较弱 |
| 专用写入模型 + 框架 | Hy Memory 2.0 | 用专用小模型承担写入判断，框架管三类记忆形态 | 写入成本可控、形态划分细，代价是决策模型上限成为天花板 |
需要提醒的是，这张对照表描述的是设计取向而非实测优劣。四类方案的公开评测口径并不统一，跨方案直接比分数的做法目前缺乏支撑。
局限与冷静判断
- 分数优势在误差量级内：55.49 对 54.62 只差 0.87 分。真正体现专用训练价值的是与同规模通用模型 Qwen3-30B-A3B 之间 11.12 分的差距，而不是与前沿大模型的微弱领先。
- 评测基于固定 20% 子样本：官方技术报告明确使用固定子样本，这有助于可比性，但也意味着绝对分数不能直接外推到完整基准。
- 名称为 EverOS 与 EverMemOS 的口径不一致：不同来源对第四套系统的名称与是否参与训练的描述存在出入，引用前建议核对官方报告原文。
- 优势幅度多来自厂商自测：全部指标由腾讯混元方面公布，目前未见独立的第三方复现报告。作为技术选型依据时，应在自己的数据上跑一轮再下结论。
- 决策模型上限是硬约束：约 3B 激活的写入模型判断失误会被记忆持续放大，且这类失误不像单次回答错误那样容易在当轮被发现。
- 代码记忆的「记得住」与「用得上」落差明显：问答准确率 64.2% 对任务解决率 35.6%、SWE-ContextBench 28.3%，说明记忆到实绩的转化仍是短板。
- 桌面端覆盖面有限：MemHub 目前公开的是 CLI 与 Mac 客户端，其他桌面平台的支持情况官方尚未给出明确说明。
- 生态接受度尚未验证：一套记忆基础设施能否成为标配，取决于社区与工具方是否接住，而这需要数月的观察，不是发布当天能判断的。
总体而言，Hy Memory 2.0 的价值不在于把分数抬高了一个名次，而在于把记忆这件事拆成了可以分别讨论的三层：谁来写、以什么形态存、怎么跨工具用。它给出的答案有清晰的取舍——用专用小模型换写入成本，用三类形态换噪音控制，用本地优先换数据边界。对正在自建智能体记忆层的团队，它提供了一个可以直接对照的参考实现；对更多团队，它提供的是一份清单：你的记忆是存了原始事实还是带条件的经验，代码记忆存的是快照还是 diff，同一个人的经验在换工具之后还在不在。目前官方及行业暂未披露更多细节，后续将持续跟进迭代动态。