Hy Memory 2.0 开源后最炸的一条多款主流 AI 编码工具共享同一份记忆连回滚代码都能追溯【免费下载链接】Hy-Memory项目地址: https://gitcode.com/gh_mirrors/hy/Hy-Memory2026 年 10 月 16 日腾讯混元宣布 Hy Memory 2.0 全面开源30B 参数的记忆专用模型 Hy-Memory-30B-A3B 放出权重记忆框架以hy-memorySDK 形式上线 PyPI桌面应用 MemHub 连同 CLI 一起进入 monorepo。三样东西各自独立可用也能拼成一套完整方案。但发布稿里最容易被略过、又最戳中开发者的一点是MemHub 把 WorkBuddy、Cursor、Codex、Claude Code、OpenCode、Qwen Code、Hermes 等 10 款 AI 工具的历史会话导入同一份本地记忆此后各工具产生的新会话实时同步汇入任意一个工具发起任务时都能召回这份共享记忆。官方还给了一个更具体的能力描述——连被回滚掉的代码都能通过记忆里的版本演进链追溯回来。这篇文章不聊发版新闻只干三件事拆解共享记忆的三层开源结构从源码看 Coding 记忆是怎么做到回滚可追溯的以及说清楚这套东西对个人开发者的想象力边界在哪。一、三层全开源模型、框架、应用各自独立、可组合拼装Hy Memory 2.0 的三层不是营销分层而是三个边界清晰、版本独立发布的交付物这一点在仓库里可以直接验证模型层Hy-Memory-30B-A3B。一个 30B 总参数、约 3B 激活参数的 MoE 记忆写入模型权重已在 Hugging Face 发布tencent/Hy-Memory-30B-A3B配套技术报告 arXiv:2610.22196 提出面向长期记忆写入的归因强化学习Attributed RL训练框架。官方数据显示该模型在 Mem0、MemOS、EverMemOS、Hy Memory 四套记忆系统接入的横向测试中宏观平均得分 55.49高于 Claude Opus 5 的 54.62、DeepSeek V4.1 Flash 的 53.64也远高于 Qwen3-30B-A3B 的 44.37。它不是通用聊天模型而是专门优化高精度记忆抽取与冲突消解的写入器。框架层hy-memorySDK。PyPI 包名hy-memory2.0.x 已发布仓库根目录的hy_memory/就是全部实现。框架按任务类型提供三条记忆链路scene参数路由scene面向任务记忆形态chat闲聊、个人偏好、一般问答L0–L7 记忆分层working文档、分析、内容创作等生产力任务双层记忆会话事实 可复用经验coding编码、调试、构建、API/SDK同双层记忆 代码版本演进链diff 链工作记忆与代码记忆是 2.0 新增能力。官方口径在聊天、工作、代码三类场景的 4 个 Benchmark 上对比 Mem0、MemOS、EverOS、OpenViking、RepoMemory 与 Simple RAG 均排名第一工作记忆在 MemoryArena 旅行规划与组合购物任务上平均 55.31%领先次优 EverOS 10.2 个百分点代码记忆在 CodeMemoryBench 上代码问答准确率 64.2%、任务解决率 35.6%SWE-ContextBench 解决率 28.3%MemOS/Mem0 为 25.3%聊天记忆在 LoCoMo 上准确率 72.6% 的同时单题 token 从 1159 降到 703省 39.3%。应用层MemHub。本地优先的桌面应用macOS arm64/x64 CLILinux x64/arm64 Runtimemonorepo 下memhub/子项目包含 Python/FastAPI Core、Electron 桌面壳、React Web UI、packages/host-bridgeAI 工具接入层等。数据默认落在~/.one-memory由唯一 Python Core 作为业务数据库写入者。docs/monorepo.md明确了仓库边界SDK 在根目录保持 Python 包布局与发布流稳定MemHub 作为完整子项目独立构建两者共享这个公开 monorepo 作为唯一事实源。三层解耦的好处很实际只想给自己的 Agent 加记忆pip install hy-memory2.0.3配两组环境变量LLM Embedding任何兼容 OpenAI API 格式的服务就能跑想直接要产品体验装 MemHub想训写入模型拿 30B 权重。二、共享记忆怎么落地一条管道、四类权限、十种宿主共享说起来轻描淡写工程上要回答两个问题记忆怎么汇进来以及谁能查出去。汇入侧所有来源收敛到同一条 durable 管道。MemHub 的架构文档memhub/docs/ARCHITECTURE.md里正常内容路径是authorized source → Evidence → import job → memory_write_jobs → 持久化事件时间窗 → durable drain → Hy Memory bridge → Governance → search / recall关键设计有两点。第一Evidence 先落盘再做模型处理——处理失败不会丢源内容这也是共享记忆敢承诺数据不丢的前提。第二memory_write_jobs是唯一生产入口队列历史导入、实时 Hook、手动输入、Matter 发现全部提交到同一张表按事件时间event_at锚定固定窗口、按queue_seq保持各 Harness 内 FIFO。10 款工具的会话混进来不会互相跳队重启不会让时间窗漂移。召回侧四类权限边界互相独立。架构文档明确要求这四者不能坍缩成一个开关Source grantCore 能不能读某个工具的数据根目录Harness sync要不要持续从该来源发现并导入新会话Model-content permission本地会话内容能不能发给配置的模型供应商Host recall grant某个外部宿主能不能检索指定记忆范围对应的产品语义是一键插入应用管 Recall 接入MemHub → 工具同步开关管会话读取工具 → MemHub两者都开才是双向接通只开一个就是能查旧记忆但不写入或继续读但不给工具召回工具。隐私边界同样写死在文档里产品不包含屏幕、Accessibility/AXTree、OCR、键鼠、剪贴板或后台录音采集所有数据在本地。宿主侧十款工具十种接入形态。memhub/docs/harness-support/README.md的支持矩阵列得很直白Harness查询 MemHub 的方式送入 MemHub 的方式Claude CodeMCP SkillUserPromptSubmit/Stop/SubagentStopCapture HooksCursorMCP SkillCapture HooksCodexMCP SkillCapture HooksOpenCodeMCPJS Capture PluginWorkBuddy.codebuddy-plugin内 MCP SkillPlugin HooksQwen CodeMCP Skill无 HookCore 扫描PiCLI SkillJS Capture ExtensionOpenClaw当前冻结仅底层 MCP 写入器冻结注意 OpenClaw 一栏——矩阵里没有全员绿灯处于冻结状态的宿主就如实标冻结。这也是读这套文档值得注意的一点它把每个宿主的实际生效路径、开关组合效果、撤销行为都写成契约文档如claude-code.md里逐条列出一键开同步关等四种组合的语义而不是只留一句已支持。对纯 SDK 用户同样的隔离能力以参数形式存在add()时传sourcesearch()时用include_sources/exclude_sources做来源过滤黑名单优先于白名单与agent_id正交。hy_memory/client.py的 docstring 直接写明了语义。共享与隔离是同一份数据上的两个开关。三、编码场景的连锁反应双层记忆 版本演进链被删的代码找得回来这是整个 2.0 里我认为信息密度最高的部分因为共享记忆在编码场景里不只是省掉重复解释需求——它让多工具接力开发时上一版到底改了什么有了持久载体。双层 pipeline 一次 LLM 调用出两层草稿。hy_memory/coding/extractor.py的注释把分工写得很清楚经验层EXPERIENCEStask / search_keys / solution / boundary_envs / confidence有严格价值门槛——rename a file 这种琐碎操作不该成 memory只抽未来可能复发的、非平凡的做法事实层FACT每次会话恰好 1 条不设价值门槛记录用户要什么、怎么做的、结果如何。事实层刻意记坐标不记代码。README 解释了原因抽取预算约 200 汉字feat/x这一个 token 的信息量远超 30 行 diff而代码可以回去读。但这个前提有个洞被撤掉的那版代码读不回来——它不在工作区、不在 HEAD只在某次中间提交里。Git 回滚之后连 Git 里都不一定还留着可读的痕迹。版本演进链就是补这个洞的而且完全不用 LLM。实现集中在hy_memory/coding/chain_store.py文件头注释直接自报家门它是装饰器不是检索器——向量层决定返回哪几条 factchain 只负责在每条 fact 下面挂上它所涉及代码的全部改动版本每版的用户原话 每版真实 diff不做相似度、不选版本、不猜哪版是最终答案。存储结构只有两张核心表thread(id, owner, branch, file, symbol, pkey, lo, hi, n_rounds, body) -- 一条 thread 某分支、某文件、某函数的某一块被反复改的历史 round(id, thread_id, seq, said, patch, adds, created_at) -- 一条 round 一次改动seq 第几版纯计数不做版本推断几个源码里能看到的设计决策owner 隔离键必须进主键。thread.owner user_id|workspace_id没有它用户 A 的feat/q4和 B 的feat/q4会并成同一条链A 能读到 B 的 diff。这是多租户共享存储下数据泄漏级的 bug注释里专门标了必须进键。分链三级降级hunk header 带函数名 →(owner, branch, file, symbol, 行区间)只有上下文 → 降到行区间聚类而不是直接文件粒度否则同一文件所有改动挤成一条十几版的长链裸 hunk → 文件粒度。失败闸门从对话里合成 diff 时编辑动作后必须验证成功迹象returncode0等否则agent 只是提议改法被用户否决替换失败的假版本也会进链——链是哪一版赢了的唯一依据掺一个没生效的版本进去agent 可能照着写。best-effort链记录失败不会阻断双层记忆写入或检索抽错比抽不到更坏。召回侧client.search(scenecoding)除了facts、experiences还会返回chain_block与召回 fact 对齐的版本演进上下文无法挂链时为空串和chain_used已挂进块里的 fact 下标。SDK 明确不从 facts 里删除这些条目——不悄悄少给拼块由调用方决定。写入侧则依赖MEMORY_CODING_CHAIN_REPO_ROOT读本地 Git diff或识别工具轨迹中带path/old/new的确定性替换动作。把三节串起来一个真实工作流就出来了Claude Code 里花两周修一个 search timeout方案改了三版、第二版被回滚换到 Codex 上继续问最终保留了哪版实现——召回的事实说清了结论和坐标chain_block把每版的用户原话和真实 diff 按序排出来包括那个既不在工作区也不在 HEAD 的第二版。这正是连回滚代码都能追溯的来源不是模型记住了代码而是管道把 diff 零 LLM 地存了下来。四、对个人开发者一套记忆走天下的想象空间与边界想象空间是实打实的工具可换上下文不换。多工具接力写代码用 A、评审用 B、调试用 C时这个坑上周踩过这个函数的历史决策不再需要人肉复制粘贴。SDK 足够轻。不想要 MemHub 产品pip install hy-memory2.0.3加两组环境变量即可lite模式零 LLM 开销纯向量 RAGpro加抽取与冲突消解ultra再上 System 2 图式归纳与跨域归纳client.evolve()触发。本地优先且数据主权明确。数据在~/.one-memorymemhub uninstall默认保留记忆只有显式memhub delete-data且二次确认精确路径才删模型外发是独立的授权项撤销即时生效live guard 在远端发送边界重查当前设置不靠旧任务快照。边界同样清晰且仓库文档自己就标注了平台macOS LinuxWindows 不支持MemHub 官方 README 自述preview 阶段部分平台制品与宿主体验仍在验证。宿主覆盖十款工具里有冻结项OpenClaw和有 UI Bug 待修项DeepSeek Harness全员支持尚未成立。隔离靠你传参SDK 层面workspace_idbranch是精确匹配的作用域过滤branch 过滤还会刻意保留branch IS NULL的历史数据——机制是有的但多仓库、多用户协作时规范化 ID 的责任在调用方。评测口径官方 benchmark 数据来自厂商自测且团队同时投稿了 CMBCoding Memory BenchmarkICLR 2027 已投稿见 docs/papers/——评测基准由记忆框架方自己定义这一点在引用跑分时值得保留一点距离。大模型厂商卷完上下文长度和推理强度下一站显然在记性上。Hy Memory 2.0 值得关注的地方不在于某项跑分而在于它把记忆从单模型内的会话状态拆成了一个有明确数据面、权限模型、宿主契约、甚至带 diff 级审计能力的独立系统层——这层今天恰好长在腾讯的 monorepo 里Apache-2.0随时可以拿下来看。【免费下载链接】Hy-Memory项目地址: https://gitcode.com/gh_mirrors/hy/Hy-Memory创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考