北京
从 Cursor 切到 Codex，第一件事往往不是写代码，而是把项目背景、技术栈、踩过的坑重新讲一遍。工具换了，上下文清零，开发者被迫当起"复读机"。腾讯开源的 Hy-Memory 2.0 想解决的正是这件事：让不同 AI Agent 之间共享同一份记忆。
这套系统的核心是一个叫 MemHub 的中央化记忆管理应用。它把分散在不同工具里的对话历史汇集起来，形成一个统一的记忆池。按方案设计，不同平台的 Agent 都可以访问这份记忆池，换工具时不必再对上下文做一次"再教育"。
记忆并不是一股脑堆在一起。Hy-Memory 2.0 把记忆拆成三类，分别对应不同的场景和提取策略：
- Chat Memory：负责跨对话的事实提取，解决日常交流中的信息延续；
- Working Memory：用于任务经验的沉淀，把执行过程里可复用的部分留下来；
- Coding Memory：追踪代码版本演进，把代码 Diff、修改上下文和版本演进链一并纳入记忆体系。
三类记忆里，Coding Memory 的指向最具体。它要让编程 Agent 不只看到当前这份代码，还能往回追溯历史修改以及修改背后的背景。对长期维护的项目来说，这相当于给 Agent 补上了一段它原本看不见的"项目履历"。
方案里还有一条值得注意的拆分：任务事实和可复用经验被分开管理。事实层记录做了什么、结果如何；经验层提炼哪些方法有效、适用于什么条件。两层各管各的，避免把一次性的执行结果和可迁移的方法论混为一谈。
支撑这套记忆体系的是一个专用模型 Hy-Memory-30B-A3B。它的定位不是通用推理，而是专门针对记忆写入做优化，负责把瞬时的交互数据筛选、组织成可长期复用的知识块。把"写记忆"单独拎出来做一个模型，是这套方案区别于常规 Agent 记忆设计的地方。
正方会说，这是 Agent 从单次会话走向长期经验体系的必要一步：记忆一旦能在工具间流动，开发者积累的上下文就不再随工具切换而蒸发。反方则会追问，记忆池越大，筛选和组织的成本越高，30B 的写入模型能不能扛住真实开发流程里的噪声，还得看实际落地。
判断暂时只能落在一个方向上：把分散在不同 AI 工具里的历史对话和工作经验汇入统一记忆体系，让不同 Agent 复用相关上下文，这个目标本身是清晰的。至于共享记忆会不会带来新的混乱，取决于写入模型筛选得够不够准。
特别声明：以上内容(如有图片或视频亦包括在内)为自媒体平台“网易号”用户上传并发布，本平台仅提供信息存储服务。
Notice: The content above (including the pictures and videos if any) is uploaded and posted by a user of NetEase Hao, which is a social media platform and only provides information storage services.
