「记忆越少反而越聪明」Hy-Memory 的反直觉设计为什么被全网热议【免费下载链接】Hy-Memory项目地址: https://gitcode.com/gh_mirrors/hy/Hy-Memory2026 年 10 月 16 日腾讯混元将 Hy Memory 2.0 整体开源hy-memorySDK2.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模式行为适用lite纯向量读写零 LLM 调用快速灌入、零成本 RAGproLLM 抽取 冲突调和reconcile标准负载ultra强制 GraphSystem 2 由evolve()显式触发 schema 归纳与跨域扫描完整认知架构也就是说深加工不是默认行为而是显式开关——这本身就是一种成本控制上的少。真正的取舍发生在写入端的抽取提示词里。以 Working/Coding 场景为例hy_memory/coding/prompts_zh.py提示词定义了一个硬性门槛VALUE BAR一条经验EXPERIENCE必须同时满足三条才能入库解决了同一用户以后很可能再次遇到的问题解决方案并非琐碎操作——组合了多项信息/步骤、包含决策理由或记录了来之不易的 workaround未来的 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创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考