「记忆越少反而越聪明」：Hy-Memory 的反直觉设计为什么被全网热议

「记忆越少反而越聪明」：Hy-Memory 的反直觉设计为什么被全网热议

【免费下载链接】Hy-Memory项目地址: https://gitcode.com/gh_mirrors/hy/Hy-Memory

2026 年 10 月 16 日，腾讯混元将 Hy Memory 2.0 整体开源：hy-memorySDK（2.0.4）、本地记忆管理产品 MemHub、以及专为记忆写入训练的 MoE 模型 Hy-Memory-30B-A3B，三层能力一次性放出。发布后社区讨论最热烈的并不是"又开源了一个记忆框架"，而是一组反直觉的评测数据——Hy Memory 在 LoCoMo 基准上聊天记忆准确率做到 72.6%，超过对比框架 EverOS 的 71.9%，而单题消耗的 Token 从 1,159 降到 703，减少 39.3%。

记住的东西更多，答得更准，花得更少。这三件事同时发生，直接挑战了"记忆系统 = 更大的库 + 更多的条目"这条默认路径。极客公园因此给这篇文章起了个标题：Agent 记忆越少反而越聪明。这篇技术文就沿着这个问题往下拆：这个反直觉结论的证据是什么，Hy-Memory 在源码层面是怎么"做减法"的，以及它对 Agent 产品形态意味着什么。

一、反直觉的起点：记太多，Agent 真的会变笨

先说清楚"变笨"的机制。把对话原文或全量摘要都塞进检索库，检索时 Top-K 召回的是一堆同质、重复、甚至互相矛盾的碎片，上下文窗口被低信息密度内容占满，模型的有效注意力被稀释——这就是所谓的上下文污染。社区里流传的"三周失忆症"（Agent 记了三个月，问什么都答不准）本质上是同一个问题：记忆总量上涨，记忆信噪比下降。

Hy-Memory 开源仓库自带了佐证这种"每一层记忆都必须挣到席位"的实验方法。其 CMB 基准（提交 ICLR 2027，仓库内见 docs/papers/CMB_A_Coding_Memory_Benchmark_for_Long_Horizon_and_Interleaved_Coding_Agents.pdf）的消融测试在测试代码里留有明确注记（tests/coding/test_scene_coding_variant.py）：

# 消融开关: 让 coding 退化成"纯向量双层"(= working 的召回形态), 用来做 # 单变量 A/B。CodeMemoryBench 消融靠它: 去掉这层 77/216 → 45/216。

版本演进链这一层砍掉后，216 个长程编码任务里能解决的从 77 个掉到 45 个。这说明"少"不是无差别地删，而是删掉低信息密度的部分、留下高信息密度的精确轨迹——记住"代码在第几版被改成了什么"（真实 diff），比记住十段相似的自然语言总结更有用。

二、选择性记忆的机制：双系统认知架构如何取舍

Hy-Memory 的架构论文《Memory Beyond Recall: A Dual-Process Cognitive Memory System for Self-Evolving LLM Agents》被 EMNLP 2026 接收，核心是借用认知科学的双过程模型：System 1 负责写入路径上的快速提取与冲突调和，System 2 负责慢速的认知加工。落到工程上就是lite/pro/ultra三档模式（见 README.md）：

也就是说，"深加工"不是默认行为，而是显式开关——这本身就是一种成本控制上的"少"。

真正的取舍发生在写入端的抽取提示词里。以 Working/Coding 场景为例（hy_memory/coding/prompts_zh.py），提示词定义了一个硬性门槛VALUE BAR，一条经验（EXPERIENCE）必须同时满足三条才能入库：

1. 解决了同一用户以后很可能再次遇到的问题；
2. 解决方案并非琐碎操作——组合了多项信息/步骤、包含决策理由，或记录了来之不易的 workaround；
3. 未来的 agent 更愿意查阅它，而不是重新摸索。

同时给出了明确的负面清单：

不要抽取： - 没有可复用流程、真正琐碎的单步操作（"rename one file"、"git status"、 "run ls once"） - 已经解决且没有可迁移经验的一次性问题 - repo/system 中已经存在的信息（不要重复 package.json）

每段会话的记忆配额被严格限定：FACT（情节层）恰好 1 条，EXPERIENCES（经验层）0 到 N 条且必须过门槛。提示词里甚至专门警告了一种"记忆污染"的自复制风险：

从停滞中提炼出的 experience 在检索时会像一项真正的技能；同一任务的后续片段会匹配它，再次向用户提问而不是继续推进，导致这种停滞在余下会话中不断自我复制。

这条规则值得所有做 Agent 记忆的人抄走：垃圾记忆不只浪费存储，它还会在检索-执行闭环里自我繁殖。

"少"在库内同样成立。写入后的调和阶段做去重与合并，hy_memory/core/merger.py 中两组阈值写得直白：

merge_threshold: float = 0.85 # 高于此值触发合并 duplicate_threshold: float = 0.95 # 高于此值是认为是重复

而 hy_memory/coding/fact_reconciler.py 的 supersede（取代）机制保证同一任务上的新事实可以覆盖旧事实，被取代的事实通过fact_chain_summary链保留可追溯性——记忆库随时间推移保持"当前状态 + 必要历史"的紧凑形态，而不是一路追加到底。检索端还有最后一道门：hy_memory/pipelines/_retrieval/underflow.py 的补槽逻辑注释明确要求"enforces the output gate once more and never invents a score"，低于min_score的候选宁可留白也不塞进来。LoCoMo 上每题 703 Token 的结果，就是写入门槛、库内合并、检索门禁三道闸叠加出来的产物。

三、对产品形态的影响：记忆要的是密度，不是长度

"密度优先"这个设计哲学一路传导到了模型和应用层。

模型层：Hy-Memory-30B-A3B 是一个 30B 总参数、仅 3B 激活的 MoE 模型，用"有归因的强化学习"专门训练长期记忆写入与冲突调和。arXiv 报告（2610.22196）给出的数字：在 Mem0、MemOS、Hy-Memory 三套框架组合上训练、四套评测框架上，宏观平均 55.49%，高于 Claude Opus 5 的 54.62。注意它干的是"决定什么值得写进记忆"这件小而关键的事——用 3B 激活参数把这件关键的事做好，而不是用一个大模型无差别地总结一切。

数据层：Chat 场景的记忆被组织成 L0–L7 共八层（基础信息、原文、原子事实、会话摘要、心智模式、带过期时间的意图），其中 L7INTENTION过期后自动降级为普通事实——连"未来的计划"都有明确的衰变规则。Coding 场景的版本演进链更是极致密度的例子（hy_memory/coding/chain_store.py）：它以"装饰器"而非"检索器"身份存在，零 LLM 调用，把每个版本的用户原话加真实 diff 挂在对应事实下——被回滚掉的代码版本在 git 工作树里已经找不回来，只有这条链能读回，而它的存储成本远小于等量的自然语言摘要。

应用层：MemHub 把这套机制做成了 local-first 的桌面/CLI 产品，将 Claude Code、Cursor、Codex、OpenCode、Qwen Code 等 10 款 AI 工具的会话统一汇入同一份本地记忆，按user_id → agent_id → session_id三层作用域隔离。10 个工具共享一份经过门槛过滤的记忆库，恰恰说明：共享的前提是这份记忆足够干净，否则十份上下文污染会互相放大。

结语

Hy-Memory 被热议的"反直觉"，拆开看其实是一套很工程化的预算纪律：写入端用 VALUE BAR 决定"值不值得记"，库内用合并与 supersede 决定"留几条"，检索端用分数门禁决定"带几条走"。三道闸门把记忆从"垃圾填埋场"改造成"受控预算"，才换来 703 Token 下更高的准确率。对正在给 Agent 加记忆系统的团队，这组数据的提示非常具体：先审你的记忆入库门槛和检索门禁，再考虑扩容你的向量库。

【免费下载链接】Hy-Memory项目地址: https://gitcode.com/gh_mirrors/hy/Hy-Memory