Tencent Hunyuan выложил в open source двухсистемную «когнитивную» память для агентов: SDK на Python, отдельная модель памяти Hy-Memory-30B-A3B и локальное приложение MemHub. Разбираем, что реально умеет 2.0, как её поставить за десять минут и где границы применимости.
Hy Memory — это слой долговременной памяти для LLM-агентов от Tencent Hunyuan: он хранит не переписку, а извлечённые факты, схемы и опыт, а для кода ещё и цепочку версий изменений. Первая версия вышла в мае 2026 года, вторая — 15–17 октября 2026 года: добавились отдельная модель памяти, локальное приложение MemHub и разделение на три сцены.
pip install hy-memory и работает с любым OpenAI-совместимым LLM и эмбеддером — то есть с DeepSeek, Qwen или локальной моделью в Ollama. Память делится на три сцены: chat (личные факты), working (рабочие задачи) и coding (изменения кода). Отдельная модель Hy-Memory-30B-A3B нужна только для качественного извлечения фактов — её можно не поднимать, если вас устраивает внешний API.Обычный RAG хранит куски текста и ищет похожие по эмбеддингу. Hy Memory работает иначе: каждое сообщение проходит через извлечение — модель превращает диалог в атомарные факты, версионирует их (новое значение перекрывает старое, но история остаётся), а затем поднимает на верхние слои: саммари сессии, профиль пользователя, схемы и «проспективные намерения» — то, что пользователь собирается сделать.
В основе архитектуры — двухсистемность: быстрая «Система 1» отвечает за дешёвую запись и поиск, медленная «Система 2» периодически переупорядочивает память, гасит конфликты и выводит обобщённые схемы. Система 2 запускается не на каждый запрос, а методом evolve() в режиме ultra — поэтому расход на LLM остаётся предсказуемым.
lite работает без LLM вообще, но тогда это просто векторный поиск по сырым записям.Сцена (scene) выбирается при записи и определяет, по какому конвейеру пойдут данные. Если её не указать, роутер сам решает: записи без вызовов инструментов уходят в chat без единого обращения к LLM, а записи с tool-calls классифицируются один раз.
| Сцена | Задачи | Форма памяти |
|---|---|---|
| chat | Личные факты, предпочтения, общий Q&A | Иерархия L0–L7 |
| working | Документы, таблицы, ресёрч, аналитика, работа с компьютером | Два слоя: факты сессии + переиспользуемый опыт |
| coding | Разработка, отладка, тесты, сборки, SQL | Два слоя + цепочка версий кода (diff-цепочка) |
Слои в chat-сцене идут от самого сырого к самому обобщённому: L0 BASIC_INFO, L1 RAW (журнал диалога только на добавление), L2 FACT (атомарные версионированные факты), L3 SUMMARY (саммари сессий), L6 SCHEMA (ментальные модели и шаблоны), L7 INTENTION (намерения с истечением срока — по истечении факт понижается до обычного). Слои L4 IDENTITY и L5 KNOWLEDGE зарезервированы в текущей версии.
В сценах working и coding из одной сессии получается два разных слоя: факты (что именно сделали: задача, подход, результат — ровно один на сессию, без порога) и опыт (0–N переиспользуемых решений, которые проходят порог полезности). Обе части ссылаются друг на друга, а вытесненные факты остаются доступными по цепочке прогресса задачи.
Ядро ставится из PyPI и уже включает векторное хранилище ChromaDB и графовое Kuzu. Требуется Python 3.9 или новее. Дополнительные хранилища подключаются extras-флагами.
pip install hy-memory==2.0.4 # ядро: ChromaDB + Kuzu pip install "hy-memory[qdrant]==2.0.4" # + Qdrant pip install "hy-memory[faiss]==2.0.4" # + FAISS pip install "hy-memory[graph]==2.0.4" # + Neo4j pip install "hy-memory[rerank]==2.0.4" # + локальный реранкер pip install "hy-memory[all]==2.0.4" # всё сразу
Затем достаточно указать LLM и эмбеддер — подойдёт любой сервис с OpenAI-совместимым API. В примере ниже внешняя модель DeepSeek и эмбеддинги DashScope; вместо них можно поставить локальные.
export MEMORY_LLM_API_KEY="sk-..." export MEMORY_LLM_BASE_URL="https://api.deepseek.com" export MEMORY_LLM_MODEL="deepseek-chat" export MEMORY_EMBEDDER_API_KEY="sk-..." export MEMORY_EMBEDDER_BASE_URL="https://dashscope.aliyuncs.com/compatible-mode/v1" export MEMORY_EMBEDDER_MODEL="text-embedding-v3" export MEMORY_EMBEDDING_DIMS=1024
from hy_memory import HyMemoryClient client = HyMemoryClient(mode="pro")
client.add("I love sci-fi movies", user_id="user_1")res = client.search("What movies does the user like?", user_ids=["user_1"])client.add(messages, scene="coding", user_id="u1", workspace_id="github.com/acme/api")
lite сцена и слои игнорируются — всё пишется как сырой вектор, поэтому фактов и опыта там не будет. Второй частый случай — запись в coding без tool-calls: без трассировки инструментов цепочка версий кода просто не строится.Режим определяет, сколько работы делает LLM и нужен ли граф. Это главная ручка стоимости: чем «умнее» память, тем больше токенов она сжигает на извлечение.
| Режим | Что делает | Граф | Когда брать |
|---|---|---|---|
| lite | Только запись и поиск по эмбеддингам, без вызовов LLM; сцена и слои игнорируются | нет | Классический векторный RAG, быстрый приём данных, нулевая цена по токенам |
| pro | Извлечение фактов + сглаживание конфликтов | опционально (по флагу) | Обычные рабочие нагрузки, личная и рабочая память |
| ultra | То же + вывод схем Системой 2 и кросс-доменный проход по evolve() | всегда включён | Полная когнитивная схема, долгие проекты, накопление опыта |
Практическое правило: начинайте с pro. В ultra переходите, когда в памяти уже есть история и начали мешать противоречивые факты — именно там включается периодическая «переуборка» и вывод схем. Если задача — только хранить и искать большие объёмы текста, lite дешевле и предсказуемее.
Класс «память для агентов» уже плотно занят: mem0 — самый популярный, Letta (бывший MemGPT) — самый академичный, Zep — про графовую память для продуктовых сценариев. Hy Memory заходит в этот ряд с двумя отличиями: явное разделение сцен и отдельная обученная модель извлечения.
| Проект | Звёзды GitHub | Загрузки PyPI/нед | Лицензия |
|---|---|---|---|
| Hy-Memory | 880 | 1 469 | Apache-2.0 |
| mem0 | 67 425 | 605 555 | Apache-2.0 |
| Letta (MemGPT) | 25 187 | 2 967 | Apache-2.0 |
| Zep | 4 966 | — | Apache-2.0 |
Что это значит на практике: Hy Memory пока не конкурент mem0 по объёму сообщества, но у неё есть то, чего у большинства нет — memory-специфичная модель и работа с историей кода. Если вы уже используете mem0 и он закрывает задачу, менять стек смысла нет; Hy Memory стоит смотреть там, где нужны именно сцены и опыт повторного использования, а не просто поиск по прошлым сообщениям.
Путь данных всегда один: запись попадает в роутер сцен, тот направляет её в нужный конвейер, извлечённое раскладывается по слоям, а поиск собирает ответ из нескольких каналов. Для кода к факту дополнительно пристёгивается дифф-цепочка версий — намеренно без обращения к LLM, чтобы не терять детали.
| Компонент | Варианты | Комментарий |
|---|---|---|
| Векторные хранилища | ChromaDB (по умолчанию), Qdrant, FAISS | Выбор через extras при установке |
| Графовые хранилища | Kuzu (по умолчанию), Neo4j | Нужны в режиме ultra |
| Метаданные | локальный SQLite | Факты, опыт и граф кода |
| Модель извлечения | Hy-Memory-30B-A3B или любая через API | 30B-A3B = ~30 млрд параметров, ~3 млрд активных |
Цепочка версий кода — самая необычная часть. Факты намеренно не хранят код целиком: в бюджет идут координаты (файл, функция, ветвь), а сам код остаётся в диффах. Поэтому версия, которую потом откатили, всё равно находится в истории — её не было бы ни в саммари, ни в рабочем дереве. Изоляция идёт по паре user_id + workspace_id, то есть по репозиторию.
MemHub — локальное приложение (подписанная сборка для macOS плюс CLI на npm) поверх того же ядра. Оно собирает историю диалогов и следы работы в разных AI-приложениях в одно локальное хранилище и отдаёт агенту при поиске с фильтрацией по источнику.
source при записи и include_sources / exclude_sources при поиске.memhub-cli (последняя версия 1.0.5 от 18.10.2026).Сам проект бесплатный: SDK и MemHub под Apache-2.0, модель на Hugging Face тоже Apache-2.0. Платите вы за инференс: извлечение фактов делает LLM, а значит расход растёт вместе с объёмом записей и выбранным режимом.
lite или вообще классический RAG.hy-memory.