腾讯混元开源Hy-Memory 2.0：三层持久记忆让AI智能体不再遗忘

AI编程智能体最令人头疼的毛病之一，是它在几十轮对话后忘掉此前敲定的架构决策，或者反复调试一段早已修好的代码。上下文窗口再大，原始对话历史的无差别堆积也会带来注意力精度衰减（context rot）、单轮延迟膨胀和推理成本失控。腾讯混元认知计算团队给出的解法是开源一整套持久记忆方案 Hy-Memory 2.0，把智能体的记忆拆成三层分别管理。

一套栈、三个部件、Apache 2.0

Hy-Memory 2.0 以 Apache 2.0 许可在 GitHub 与 Hugging Face 全面开源，由三个互补部件组成：客户端库与 SDK hy-memory（稳定版 2.0.2）、本地桌面与命令行管理应用 MemHub（可即插即用对接十款主流开发环境与自主智能体工具）、以及专门负责信息抽取与矛盾消解的神经网络模型 Hy-Memory-30B-A3B。

这个模型采用混元稀疏专家（MoE）结构，每次前向传播仅激活 30 亿参数，负责从复杂交互流中抽取实体、识别时序前提变化、去重，再写入本地 SQLite 关系库与分层向量索引。官方在 LoCoMo 连续记忆评测上给出 72.6% 准确率，同时把单次查询平均消耗的 token 从 1159 降到 703，上下文开销削减 39.3%。

稀疏专家（MoE）结构指模型由多个前馈专家子网络组成，每个 token 的前向传播只路由到其中少数几个专家，因而总参数量可以远大于实际激活量。Hy-Memory-30B-A3B 的命名即表示总参数约 300 亿、每次推理仅激活约 30 亿。这种设计让模型在保持较强语义抽取能力的同时，把显存占用和单次推理延迟压到可在本地或少量加速卡上部署的水平，适合需要低延迟反复调用的记忆写入与调和场景。

LoCoMo 是面向超长对话记忆的学术评测集，通过多轮会话中跨越数十轮的事实提问，检验系统能否在冗长历史中准确定位并正确使用早期信息。之所以用 token 消耗与准确率并列汇报，是因为无限扩大上下文窗口虽然能提升召回，却会带来注意力精度衰减和成本线性上升，单位查询成本因此成为衡量记忆方案是否实用的关键指标。

三层记忆各司其职

Working Memory：短期工作记忆

这一层记录智能体当前执行状态：分解后的行动计划、待办子任务、刚调用的工具原始输出、以及中间推理草稿。跑一个五十轮迭代的重构循环时，把五十次工具调用历史全塞进 prompt 会撑爆窗口，而 Working Memory 只动态合成状态增量——哪些文件已过单测、哪些函数编译失败、下一步该做什么。在评测目标持久性的 MemoryArena 上，该层拿到 55.31%，比纯摘要压缩管线高 8.4 个百分点。

Code Memory：代码库语义记忆

面向持续软件工程场景，Code Memory 不只存文本片段，而是在项目抽象语法树（AST）之上构建语义图，索引跨文件导入关系、函数签名、接口类型以及 diff 与 commit 的时间线。它还持久化"经验教训"：当工程师纠正智能体，指出公司消息库需要在自定义单例下异步初始化，这条约束会锚定到具体配置文件，之后在同 monorepo 其他微服务任务中被主动召回并注入 prompt。在 CodeMemoryBench 上，该层代码上下文召回准确率 64.2%，SWE 级问题直接解决率 35.6%。

抽象语法树（AST） 是源代码在语法层面的树状结构化表示，节点对应函数定义、参数、调用、导入与类型声明等语言构造，剥离了空白与注释等表层信息。相较于把代码当作纯文本切片，基于 AST 的索引可以精确建立“函数签名—调用点—所属文件—导入关系”的图结构，使检索能够按符号而非按字符串相似度定位。当代码重构导致行号漂移时，AST 节点及其语义身份仍保持稳定，因此 Code Memory 能把历史经验教训锚定到具体符号与配置文件上，并在跨文件、跨微服务的任务里被准确召回。

Chat Memory：对话情景记忆

Chat Memory 把碎片化对话转成按实体-关系-时间三元组索引的结构化情景事件。传统相似度检索最容易踩的坑是前提冲突：用户周一说生产节点跑 Python 3.12，周四说已迁移到 3.14，朴素 RAG 会把两条都召回，诱导模型生成不兼容脚本。Hy-Memory-30B-A3B 在这一层做语义调和，识别较新陈述在时间上使旧事实失效，归档遗留数据、保留当前有效事实。面向十万 token 级连续对话的 LoCoMo 上，该层支撑整体达到 72.6% 命中率。

时序前提变化与矛盾消解是记忆系统区别于普通检索的核心难点。朴素相似度检索只看语义接近程度，无法判断两条陈述在时间上是否存在替代关系，于是新旧事实会被同时召回。常见工程做法是给每条事实附加有效区间，把新陈述视为对旧事实的失效声明，旧记录转入归档而不再进入活动检索集。Hy-Memory-30B-A3B 承担的就是这一判定：识别“已迁移到 3.14”这类陈述在语义上覆盖了此前的版本声明，从而在写入阶段完成调和，而不是把冲突留给基座模型在生成时自行取舍。

与前沿模型的正面对比

实验把 Hy-Memory 2.0 与 DeepSeek^广告 4.1、Claude Fable 5.1、GPT-6 Astra 直接对比，覆盖四个维度：LoCoMo 情景记忆、CodeMemoryBench 代码库理解、MemoryArena 目标持久性、以及单次查询平均 token 消耗。

• LoCoMo 领先：72.6% 对比 GPT-6 Astra 的 71.2%、Claude Fable 5.1 的 70.8%、DeepSeek 4.1 的 68.4%。优势来自 30B-A3B 专家模型的主动整合：不等基座模型去读几千 token 噪声历史里找开头声明的变量，Hy-Memory 直接从本地 SQLite 里在 4 毫秒内给出已经清洗过的事实。
• 39.3% 的 token 削减：用原生 context caching 的远程方案，工程师仍要为整段历史付费读取。Hy-Memory 把每次查询的 token 从 1159 降到 703，省下近四成推理配额，也避免上下文窗口撞上注意力饱和区。
• 代码领域优势明显：CodeMemoryBench 上 64.2% 的 QA 精度与 35.6% 的完整任务解决率，来自与项目 AST 的原生集成，能把编译期错误和以往任务中记录的经验教训关联起来。

Python 集成示例

官方 SDK 提供异步接口，智能体可以不经网络往返、以毫秒级延迟在事务保护下的关系存储上读写记忆。下面的实现连接本地 MemHub 守护进程，写入工作记忆中的活动目标、在 Code Memory 登记一条语义补丁与经验，再执行一次情景查询：

import asyncio
import aiosqlite
from datetime import datetime

async def open_memhub_store(db_path: str = "/tmp/memhub_local.db"):
    conn = await aiosqlite.connect(db_path)
    await conn.execute("PRAGMA journal_mode=WAL;")
    await conn.execute("PRAGMA synchronous=NORMAL;")
    await conn.execute(
        "CREATE TABLE IF NOT EXISTS mem_records "
        "(node_id TEXT PRIMARY KEY, stratum TEXT NOT NULL, payload TEXT NOT NULL, "
        "info TEXT NOT NULL, logged_at TEXT NOT NULL);"
    )
    await conn.commit()
    return conn

async def insert_working_state(conn, chore_id: str, objective: str, scratch: str) -> str:
    rid = f"wrk_{chore_id}_{int(asyncio.get_event_loop().time() * 1000)}"
    meta = f'{{"chore_id": "{chore_id}", "phase": "active"}}'
    body = f"OBJECTIVE: {objective} | NOTES: {scratch}"
    t_now = datetime.utcnow().isoformat()
    await conn.execute(
        "INSERT OR REPLACE INTO mem_records VALUES (?, ?, ?, ?, ?);",
        (rid, "working", body, meta, t_now),
    )
    await conn.commit()
    return rid

async def store_codebase_rule(conn, pkg: str, ast_tag: str, lesson: str) -> str:
    rid = f"code_{pkg}_{ast_tag}"
    meta = f'{{"package": "{pkg}", "symbol": "{ast_tag}"}}'
    t_now = datetime.utcnow().isoformat()
    await conn.execute(
        "INSERT OR REPLACE INTO mem_records VALUES (?, ?, ?, ?, ?);",
        (rid, "code", lesson, meta, t_now),
    )
    await conn.commit()
    return rid

async def query_episodic_log(conn, top_k: int = 3):
    cur = await conn.execute(
        "SELECT node_id, stratum, payload, info, logged_at FROM mem_records "
        "ORDER BY logged_at DESC LIMIT ?;", (top_k,)
    )
    rows = await cur.fetchall()
    await cur.close()
    return [
        {"node_id": r[0], "stratum": r[1], "payload": r[2], "info": r[3], "logged_at": r[4]}
        for r in rows
    ]

async def execute_hymemory_orchestration():
    db = await open_memhub_store()
    await insert_working_state(db, "TASK-890", "调整异步连接池", "检查高峰超时")
    await store_codebase_rule(db, "pkg.io", "SocketPool", "固定 max_connections=500，空闲 60 秒关闭")
    matches = await query_episodic_log(db, 3)
    await db.close()
    return {"outcome": "ready", "hits": len(matches), "entries": matches}

async def main():
    res = await execute_hymemory_orchestration()
    print(f"执行完成: {res['outcome']}，记录数: {res['hits']}")
    for e in res["entries"]:
        print(f"  [{e['stratum']}] {e['payload']}")

if __name__ == "__main__":
    asyncio.run(main())

这段代码展示了 MemHub 异步接口如何让智能体在不增加网络开销的前提下登记技术经验与操作步骤，在 WAL（Write-Ahead Logging）事务保护下的关系存储上以毫秒级完成查询。

WAL（Write-Ahead Logging） 是 SQLite 的一种日志模式，写操作先追加到独立的日志文件再合并回主库，使读操作与写操作可以并发进行，而不会因单一大锁互相阻塞。对智能体高频、小批量的记忆写入与即时查询来说，这意味着查询延迟更可控、事务提交更轻量。上文示例中同时设置 synchronous=NORMAL，是在持久性与吞吐之间取的折中：崩溃时理论上可能丢失最后一小段已提交事务，但常规断电与进程退出不会损坏数据库，适合记忆这类可容忍极小回退的场景。

需要说明的是，示例代码直接操作 SQLite 的 mem_records 表，属于演示层与存储层的简化对接；生产环境应通过 hy-memory SDK 的异步接口写入，由 SDK 负责分层向量索引维护、实体关系抽取结果落库以及跨层的一致性保证，避免绕过索引导致检索失效。

成本账与部署路径

若百人工程团队每人每天与智能体对话 50 轮，传统方案每轮平均消耗 1159 token 历史，日消耗约 580 万 token，月计超过 1.7 亿 token 按前沿价格计费。换成 Hy-Memory 2.0 后每轮 703 token，日消耗降至 350 万，月省超 6800 万 token，同时因输入窗口更小而降低首 token 延迟。

部署分两种形态。个人开发者直接安装 MemHub 桌面应用或本地编译，程序自动探测已安装的编辑器与自动化工具、注入记忆拦截器，并在用户目录下创建静态加密的 SQLite 库。分布式团队可把 MemHub 守护进程部署在 Docker 容器中、挂载 PostgreSQL 或网络 SQLite，Hy-Memory-30B-A3B 可用两块均衡 NVIDIA 加速卡或单块高端加速卡加本地加速运行时私有化部署，不依赖第三方 API。从 LangChain Memory 或朴素 RAG 迁移，官方仓库提供迁移脚本，把 JSON 历史与向量库转成三层类型化结构。

技术问答

和传统 RAG 有何不同？ 传统 RAG 在向量库上做几何检索，忽略时间维度与推理结构，常召回过时或无关片段。Hy-Memory 2.0 用三层架构加 30B-A3B 专家模型的主动语义调和，对事实去重、检测顺序陈述中的矛盾，并把工具草稿隔离在 Working Memory。

必须用 Hy-Memory-30B-A3B 吗？ 不必。MemHub 设计为解耦，笔记本上可跑基于 AST 规则与 SQLite 的启发式模式；需要深度调和长对话、做高保真语义去重时再上 MoE 模型。

支持哪些编辑器与工具？ MemHub 原生对接十款：VS Code（官方智能体扩展）、JetBrains 系列、Neovim（Lua 插件）、自主命令行终端等。

查询延迟多少？ 本地 SQLite WAL 加 HNSW 索引下，Working Memory 与 Code Memory 检索单轮低于 5 毫秒，相比前沿模型数百毫秒到数秒的推理延迟可以忽略。

许可与数据归属？ 源码、库和模型权重均以 Apache 2.0 发布，允许商用、修改、安全审计与完全私有化托管，满足 LGPD、GDPR 等合规要求，无需把数据发给外部厂商。

几点观察

三层记忆的划分方式比单纯堆上下文窗口更贴近工程现实：代码结构、会话事实、执行草稿本就该用不同的保留策略和过期规则。开源加本地优先的组合，对数据敏感的企业团队有实际吸引力。需要留意的是，文中引用的 LoCoMo、CodeMemoryBench、MemoryArena 成绩均出自官方技术报告口径，第三方复现结果尚未出现，实际效果仍需在真实项目中验证。