В 2025 году главной темой были агенты: Claude Code, Cursor, Codex, Roo Code, Cline — кто только не выпустил терминального помощника. К началу 2026-го стало очевидно, что модели и тулинг — это инфраструктура, а узкое место сместилось выше: как агенту помнить, что было вчера, и как команде агентов помнить то, что помнит каждый из них.
Ниша «память для агентов» в 2026 году стала одной из самых горячих. Только за последние недели августа два проекта — корпоративный TencentDB Agent Memory и open-source ядро LoopX — прибавили по несколько тысяч звёзд за неделю каждый. Разберём, что они делают, чем отличаются и почему это важно для индустрии в целом.
Проблема: агенты живут в сессиях, проекты — в месяцах
Базовая модель работы с LLM-агентом сейчас такая: открыл терминал, поставил задачу, агент выполнил, сессия закрылась. Если завтра нужен похожий результат — открываешь новую сессию и начинаешь с нуля. Контекст, наработанные правила, знание о структуре проекта — всё потеряно.
RAG-системы частично решают это для документации и кода. Но у RAG есть фундаментальное ограничение: он отвечает на вопрос «что можно найти?». Не отвечает на «кто имеет право это использовать, какая версия актуальна и какому агенту это вообще нужно». В команде агентов это критично.
Два проекта, появившихся весной 2026-го, по-разному атакуют именно эту проблему.
TencentDB Agent Memory: корпоративный ответ на «у нас 20 агентов и 4 разработчика»
TencentDB Agent Memory — проект от команды Tencent Cloud, запущенный 7 апреля 2026 и собравший 18,6k звёзд за четыре месяца (только за последнюю неделю — плюс 8 тысяч). Это team-level memory hub: программа, которая превращает разговоры, документацию и код в четыре типа переиспользуемых «активов» и шарит их между агентами и людьми внутри команды.
Четыре типа активов:
- Chat Memory — предпочтения, факты, решения и история взаимодействий. То, что обычно хранится в памяти LLM-сессии, но persistent и доступное другим.
- Skill — не просто промпт, а полноценная единица с версиями, ресурсами, триггерами, шагами выполнения и правилами валидации. Приватный по умолчанию, расшаривается после ревью.
- LLM-Wiki — структурированные страницы документации со связями между ними (link graph). Подход вдохновлён идеями Karpathy про LLM knowledge base.
- Code-Graph — индекс символов, файлов, call-relationships и impact-paths в коде. Агент может до изменения проверить, «а что ещё это затронет».
Внутри Chat Memory работает многоуровневая модель L0 → L1 → L2 → L3: сырой разговор (L0) автоматически превращается в атомарные факты (L1), затем в сценарии по проектам (L2), затем в долгосрочные персоны и паттерны (L3). На запросе сначала подгружается быстрый контекст L2/L3, а если нужны точные факты — падает в L1/L0 через BM25 + vector + RRF. Это даёт контроль над тем, сколько памяти уходит в контекстное окно.
Главное, чего нет в RAG, но есть здесь — это ownership, версии, статусы и контроль доступа. У каждого актива есть владелец, видимость (private / team / restricted / agent), история версий и привязка к конкретным агентам. Можно сказать: «эту инструкцию по деплою — агенту-релизёру, архитектурную вики — всем агентам-разработчикам, а Code-Graph — только кодеру и ревьюеру».
Запуск — на удивление простой для корпоративного проекта:
git clone https://github.com/Tencent/TencentDB-Agent-Memory.git
cd TencentDB-Agent-Memory/deploy/global-images
cp .env.example .env
$EDITOR .env
./start-all.sh
# открыть http://localhost:8125
После запуска — панель, где можно создать команду агентов, расшарить ассеты и смотреть, кто что использует. Поддерживается интеграция с Claude Code, CodeBuddy и собственными рантаймами через proxy.
Для команд из нескольких человек и десятков агентов это выглядит как первый разумный ответ на вопрос «где хранить всё, что мы узнали о проекте».
LoopX: state kernel, который делает для агентов то, что Git делал для кода
LoopX — проект поменьше и поамбициознее в философском смысле. Создан 31 мая 2026, за два с небольшим месяца набрал 3,7k звёзд, из них плюс 3,4k только за последнюю неделю. Это «лёгкий state kernel для долгоиграющих агентских команд» — Python-пакет без runtime-зависимостей (только стандартная библиотека), который работает поверх любых agent runtimes: Codex, Claude Code, Cursor, Pi, OpenCode или собственного shell-агента.
Идея такая: агент может закрыть задачу за одну сессию. Но долгая работа — это другое: цели меняются, приходят решения от владельца, evidence устаревает, агенты передают задачи друг другу, scheduler продолжает тратить квоту, когда полезной работы уже нет. Чат-памяти и таймера для этого мало.
LoopX хранит всё нужное в одном компактном слое: objective + gates + todos + scope + evidence + quota. Agent runtime исполняет bounded turn. LoopX управляет состоянием, которое позволяет инженерным, исследовательским, discovery- и operations-лупам продолжаться между запусками.
Авторы называют это «agent-native Kanban для долгоиграющей работы». Карточки на доске несут identity, authority, evidence и continuation. Перемещение между колонками — это валидируемые операторы: claim, gate, monitor, writeback. Доска — это проекция состояния, истина — в LoopX state.
Несколько важных архитектурных решений:
- Peer agents, не лидер. У зарегистрированных агентов нет постоянного лидера. Кто действует следующим, решается через claims, leases, task boundaries и typed continuation.
- Human-in-the-loop на gates. LoopX явно не позиционируется как автономный production-контроллер. Опасные пермишены, публикация, production-writes и финальная ответственность остаются за человеком.
- Local-first, provider-neutral. Не привязан к конкретному провайдеру или облаку. Состояние проекта хранится в
.loopx/в вашем репозитории.
Установка — три команды:
curl -fsSL https://huangruiteng.github.io/loopx/install.sh | bash
export PATH="$HOME/.local/bin:$PATH"
cd /path/to/your-project
loopx doctor
loopx connect
Из интересных кейсов в README — независимый пользователь запускал LoopX на четыре дня unattended, и проект продолжал делать полезную работу. Другой кейс — рефакторинг Engine в публичном проекте zilliztech/mfs, атрибутированный к LoopX, завершился семью смерженными PR. Все цифры — user reports, не лабораторные бенчмарки, но сам факт показателен.
LoopX не пытается заменить agent framework — он надстройка, которая даёт state. Если TencentDB Agent Memory — это корпоративная CMS для знаний, то LoopX — это Git для long-running агентских процессов.
Сравнение: два ответа на один вопрос
Несмотря на общую тему, проекты решают разные задачи:
| TencentDB Agent Memory | LoopX | |
|---|---|---|
| Фокус | Knowledge assets: что агенты должны помнить | Process state: как агенты продолжают работу |
| Единица | Актив (chat memory, skill, wiki, code-graph) | Loop / kanban-card с gates и evidence |
| Аналогия | CMS / knowledge base для команды | Git + issue tracker для агентских процессов |
| Модель доверия | Корпоративная: роли, ACL, аудит | Open: peer-to-peer с human gates |
| Vendor lock | Низкий (open source), но рядом экосистема Tencent | Нулевой (Python stdlib, локальный state) |
| Подходит для | Команд с 5+ людьми и десятками агентов | Индивидуальных разработчиков и небольших команд с долгими задачами |
TencentDB Agent Memory пытается ответить на вопрос «где хранить всё, что мы узнали». LoopX отвечает на «как продолжить работу, которая идёт неделю».
Почему это важно: persistent state как третий слой агентского стека
До 2026 года стек агента выглядел как «модель + тулинг». В 2026-м к нему добавляется третий слой — persistent state:
- Уровень модели. GPT, Claude, Gemini, локальные LLM. Без изменений.
- Уровень тулинга. Terminal agent, IDE-плагин, browser agent. Тоже понятно.
- Уровень состояния. Память, контекст, evidence, gates. Вот это оформляется прямо сейчас, на наших глазах.
Это похоже на то, как Git появился не как замена компилятора, а как дополнение: возможность сохранять состояние проекта во времени, делиться им, откатываться. Без Git мы бы писали код в одиночку. Без persistent state для агентов мы будем каждый раз запускать агента с чистого листа.
Независимое появление TencentDB Agent Memory и LoopX в один год — симптом зрелости рынка. Когда разные команды, из разных стран, с разной философией начинают решать одну и ту же проблему, значит проблема настоящая.
Что попробовать прямо сейчас
Если у вас один разработчик и пара pet-проектов — начните с LoopX. Он ставится за минуту, не тянет облака, и вы за пару часов поймёте, нужен ли вам long-running state для агентских процессов.
Если у вас команда из трёх и более человек и десятки AI-помощников в работе — посмотрите на TencentDB Agent Memory. Тот факт, что проект делается внутри Tencent Cloud и при этом open source, говорит о серьёзности намерений: компания не боится отдать эту инфраструктуру сообществу.
В обоих случаях узкое место «агент забывает» перестаёт быть узким местом. И это — пожалуй, самое интересное, что произошло в open-source AI за лето 2026.
Ссылки
- TencentDB Agent Memory: github.com/TencentCloud/TencentDB-Agent-Memory
- TencentDB Agent Memory (документация по установке): INSTALL.md
- LoopX: github.com/huangruiteng/loopx
- LoopX public website: huangruiteng.github.io/loopx
- LoopX developer book: docs/book
