Разработка настоящих AI-агентов требует не только продуманной архитектуры, но и общей памяти, которой у большинства решений попросту нет. Агенты работают изолированно, что приводит к дублированию усилий, конфликтующим гипотезам и ошибкам. Решение этой проблемы — Agentis Memory: сервер, совместимый с Redis-протоколом, но с встроенным семантическим поиском и локальной генерацией эмбеддингов.

Проблема: у агентов не было общей памяти

Представьте шесть агентов, расследующих инцидент. Один находит OOMKilled в логах, другой — CPU-пик в Grafana, третий — недавний деплой в Slack. Все действуют параллельно, но не обмениваются информацией. Результат — три конкурирующие версии, из которых две ложные.

Первоначальные попытки использовать общий файл привели к гонкам за запись, отсутствию структуры и невозможности поиска. Была нужна оперативная память — быстрая, разделяемая, с семантическим поиском. Не долгосрочный RAG, а shared-контекст, где факт, сохранённый одним агентом, мгновенно доступен другим.

Почему существующие решения не подошли

Mem0 и Zep требуют REST API, внешние сервисы для эмбеддингов и отдельные векторные базы. Это означает минимум три сетевых вызова на одну операцию — неприемлемо для оперативной памяти.

Redis с модулем RediSearch ближе к цели: поддержка RESP-протокола, но эмбеддинги нужно считать отдельно. Всё равно нужен внешний inference-сервис, API-ключи и задержки.

Главная проблема всех решений — зависимость от сети и внешних зависимостей. Цель была проще: MEMSAVE key text → +OK, всё в одном процессе, без HTTP, без SDK, без ключей.

Почему не стал форкать Redis

Первая попытка — модуль на C с ONNX Runtime внутри Redis. Ручное управление памятью, сегфолты, сложная линковка, падения при нагрузке. Через неделю стало ясно: это тупик.

Вопрос: зачем писать на C, если можно на Java? Никто не видит внутренности — клиенту важно только, чтобы redis-cli -p 6399 PING возвращал PONG. Нужен не «настоящий Redis», а сервер, говорящий на его протоколе.

Технологии: GraalVM, Java 25 и инкубационные проекты

Решение принято — писать с нуля на Java, но не на обычной JVM, а с использованием GraalVM native-image. Результат — один бинарник ~150 МБ, нулевой startup, никакой JVM.

Использованы передовые технологии:

• Java Vector API (Project Panama) — SIMD-инструкции прямо в Java для ускорения косинусного сходства.
• Project Loom (Virtual Threads) — лёгкие потоки, упрощающие параллелизм без overhead’а от OS-тредов.
• ONNX Runtime — локальный inference модели all-MiniLM-L6-v2, 384-мерные векторы за 2–5 мс.
• jvector — HNSW-граф для быстрого approximate nearest neighbor search.

Как производительность упала, а потом взлетела

Первая версия на обычной JVM показала пропускную способность вдвое ниже Redis. Было обидно.

Два изменения изменили всё:

• Сборка через GraalVM native-image — устранён JIT-warmup и GC-переменные.
• Переписан hot path вычисления косинусного сходства с использованием Vector API.

Результат — 1.36x производительности Redis на строковых операциях: с 60 тыс. до 168 тыс. ops/sec.

Как это работает

Agentis Memory — единый процесс с двумя движками:

• KV-движок — поддержка 90+ Redis-команд: строки, хэши, списки, TTL, SCAN, pub/sub. Можно использовать Redis Insight — всё выглядит как обычный Redis.
• Векторный движок — четыре специальные команды:

MEMSAVE — принимает текст, разбивает на чанки, генерирует эмбеддинги через ONNX, индексирует в HNSW. Операция возвращает +OK мгновенно — тяжёлая работа идёт асинхронно. Задержка до готовности поиска — 5–10 мс.

MEMQUERY — семантический поиск по запросу. Возвращает ключ, текст и score.

MEMSTATUS — статус индексации: indexed, pending, error.

MEMDEL — удаляет и из KV, и из векторного индекса.

Никаких SDK: используйте Jedis, redis-py, go-redis — любые клиенты, поддерживающие call() или execute_command().

Теперь агенты видят общую картину: один нашёл OOM — сделал MEMSAVE, другой перед анализом выполнил MEMQUERY и увидел факт. Никаких дублей, одна истина.

Бенчмарки: честные цифры

Тесты проводились через memtier_benchmark на отдельном Ubuntu-сервере.

Throughput (ops/sec)

На строках — 1.36x Redis. На mixed workload — 1.40x. Lux быстрее (1.62x), но без встроенного векторного поиска.

Latency p99 (ms)

Redis быстрее на строках: 3.82 мс против 6.27 мс. Это цена GC-пауз, несмотря на GraalVM. На хэшах и множествах — паритет.

Pipeline scaling

При глубине pipeline 100 — 3.19 млн ops/sec (1.71x Redis). Virtual threads и многопоточность позволяют лучше масштабироваться под пакетной нагрузкой.

Важно: ни один из конкурентов не поддерживает MEMSAVE/MEMQUERY «из коробки». Agentis Memory — единственный, кто совмещает высокую производительность KV-операций и встроенный семантический поиск без внешних зависимостей.

Privacy-first: эмбеддинги остаются внутри

Данные инцидентов — логи, метрики, Slack-переписки — чувствительны. Отправлять их в облако ради эмбеддингов? Нет.

Модель all-MiniLM-L6-v2 работает локально через ONNX Runtime. Никаких API-ключей, задержек, внешних вызовов. Inference за 2–5 мс — быстрее, чем roundtrip в облако.

И это бесплатно. Ноль долларов за миллион операций — критично для внутренних систем.

Итог

Agentis Memory решает реальную проблему: отсутствие общей памяти у AI-агентов. Это не волшебная пуля, но рабочее решение, уже используемое в нескольких проектах: Claude Desktop, Codex, Antigravity и других.

Результат — меньше ошибок, меньше дублирования, выше качество выводов. Проблема автора решена. Возможно, поможет и вам.

Примечание: это перевод моей же статьиhttps://scrobot.substack.com/p/agentis-memory-redis-compatible-store, так что автор точно доносит свою мысль, без потери контекста при переводе :)

В наше время уже никого не удивишь разработкой агентов, очередной оптимизацией, новой моделью или новой инфраструктурой для нейронок. Всё это в порядке вещей. Однако одно дело читать в Twitter «мы написали агента X и он оптимизировал нам процессы на 300000%», и совсем другое — начать копать чуть глубже. Копнёшь — а «агентом» называют скилл с одним промптом.

Разработка настоящих агентов — задача не тривиальная. Достаточно посмотреть на утёкшие исходники Claude CLI — это не просто CLI, а целая инфраструктура бизнес-логики вокруг LLM. Я бы сравнил разработку агентов с разработкой типичных бэкенд-компонентов. Аналогия такая: если вы пишете каноничный бэкенд-сервис — вам нужна СУБД. Если Web3-сервис — блокчейн. Но на СУБД или блокчейне происходит в лучшем случае 50% всей логики. Вся магия крутится именно на бэкенде. С агентами то же самое: подключаешь AI SDK, конфигурируешь мыслительное ядро и пишешь вокруг него всю обвязку — мониторинги, AIOps, оркестрацию, memory management.

Вот про memory management и пойдёт речь.

Представьте: у вас шесть AI-агентов расследуют инцидент на продакшене. Один нашёлOOMKilledв логах — это root cause. Второй в это же время копается в Grafana и строит свою теорию про CPU spike. Третий вытаскивает из Slack, что вчера был деплой. Они работают параллельно, но ничего не знают друг о друге. Результат — три конкурирующих гипотезы, из которых две мусор.

У наших агентов не было общей памяти. И я решил её написать.

Получился сервер, который говорит на Redis-протоколе, но умеет в семантический поиск из коробки. Один бинарник, эмбеддинги считаются локально, любой Redis-клиент подключается без переделок. Никаких REST API, никаких внешних зависимостей, никаких API-ключей.

Вот история о том, как я к этому пришёл, почему попытка форкнуть Redis провалилась, и как Java-код, который был в два раза медленнее Redis, стал в 1.36 раза быстрее.

У наших агентов была амнезия

Полгода назад мы строили агента для расследования инцидентов на продакшене. Архитектура, в общем-то, каноничная для таких систем: Supervisor принимает алерт, составляет план через PlannerService, а дальше запускает пачку субагентов параллельно черезPromise.allSettled(). Каждый субагент идёт в свой источник данных, копает что может, и потом Synthesizer собирает из их находок финальный отчёт.

Субагентов шесть, и у каждого свой MCP-инструмент, свой scope, своя зона ответственности:

MetricsInvestigator лезет в Grafana, LogsInvestigator — в логи, SlackContextInvestigator — в переписку, HistoryInvestigator — в базу прошлых инцидентов. На бумаге — красота, всё параллельно, всё быстро.

А на практике — все шесть агентов работали в абсолютном вакууме друг от друга.

LogsInvestigator находит в логахOOMKilledна подеpayment-service. Отлично, это root cause, дело закрыто. Но MetricsInvestigator об этом ни сном ни духом — он в это время параллельно копается в Grafana, видит spike CPU и старательно строит свою альтернативную теорию. SlackContextInvestigator вытаскивает из переписки, что вчера деплоили новую версию, но не может сопоставить это с OOM, потому что не знает про OOM. В итоге Synthesizer получает на вход три конкурирующих гипотезы, из которых две — откровенный мусор. А иногда и вовсе галлюцинации, потому что единого источника правды у агентов просто не существовало.

Первое, что мы попробовали — md-файлы. Идея простая до безобразия: каждый агент пишет свои findings в общий файл, остальные читают. На словах звучит разумно, на деле работает отвратительно. Race conditions при параллельной записи, никакой структуры, никакого поиска по смыслу, никакого TTL. Это не память — это блокнот, который шестеро человек одновременно пытаются заполнить одной ручкой.

Стало очевидно, что нужнаоперативная память. Не долгосрочный RAG на OpenSearch, который мы и так менеджим и курируем для других задач — а именно быстрый shared-контекст. Такой, куда агент записал факт, и через миллисекунды другой агент нашёл его по смыслу. По сути — как Redis, только с пониманием семантики. И вот с этой мыслью я полез смотреть, что есть на рынке.

Что есть на рынке и почему ничего не подошло

Ландшафт решений для «памяти агентов» выглядит на первый взгляд вполне зрело: три основных кандидата, у каждого документация, SDK, примеры. Но стоит присмотреться к архитектуре — и начинается головная боль.

Mem0— позиционируется как «memory layer for AI agents». Звучит именно как то, что нужно, пока не начинаешь смотреть, из чего оно состоит. REST API, Python SDK. Чтобы завести, тебе нужен Docker, Qdrant или Postgres для хранения векторов, и API-ключ от OpenAI или Cohere для эмбеддингов. Считаем: каждый MEMSAVE — это HTTP-запрос к твоему серверу, который делает ещё один HTTP-запрос к OpenAI, ждёт вектор, пишет его в Qdrant. Три сетевых хопа, чтобы сохранить один факт. Для оперативной памяти, где счёт идёт на миллисекунды — это, мягко говоря, расточительно.

Zep— примерно та же история, вид сбоку. REST API, свой SDK, Postgres под капотом, эмбеддинги через внешний API. Плюс бонусом — необходимость менеджить ещё одну базу данных. Как будто у нас их мало.

Redis + Vector Search (Redis Stack)— вот это уже ближе к делу. RESP-протокол родной, любой клиент подходит. Но векторный поиск идёт через модуль RediSearch, а эмбеддинги надо считать снаружи и передавать готовые вектора. То есть ты всё равно где-то поднимаешь отдельный сервис для инференса, и к каждому запросу прилетает дополнительный сетевой вызов к embedding API. Полшага до цели, но полшага — это не цель.

Главная боль, которая объединяла все эти решения —сеть и маршалинг. Мне не нужен REST. Мне не нужен кастомный SDK, который я потом буду обновлять и отлаживать. Мне не нужен API-ключ от OpenAI, чтобы сохранить факт «подpayment-serviceзакончилась память». Я хочу сделатьMEMSAVE key textи получить+OK. Всё. В одном процессе, без сетевых вызовов, без внешних зависимостей. Это же оперативная память, а не бюрократия.

Попытка номер один: форкнуть Redis

Окей, раз на рынке ничего подходящего нет — значит, надо строить самому. И первая идея была, казалось бы, очевидной: берём Redis, пишем модуль на C, встраиваем ONNX Runtime прямо в него. Redis уже умеет в KV, протокол готов, production-tested, осталось только добавить эмбеддинги и HNSW-индекс. Что может пойти не так?

Я попробовал. Пошло не так всё.

Встраивать ONNX Runtime в C-код Redis — это, скажем так, специфический вид инженерного удовольствия. Ручное управление памятью на стыке Redis allocator и ONNX, линковка нативных библиотек, отладка сегфолтов в месте, где event loop Redis встречается с inference thread от ONNX. Через неделю у меня был полурабочий прототип, который стабильно падал при конкурентных запросах, и стойкое ощущение, что я двигаюсь в неправильном направлении.

Я остановился и задал себе честный вопрос: зачем я мучаю себя C, если 12 с лишним лет пишу на Java?

Ответ был неприятно прост — я зачем-то решил, что «настоящий» Redis должен быть написан на C. Что это чуть ли не закон природы. Но если подумать трезво: мне не нужен «настоящий Redis». Мне нужен сервер, который говорит на RESP-протоколе и умеет в эмбеддинги. А на чём он внутри написан — дело десятое. Пользователю вообще без разницы, он видит толькоredis-cli -p 6399 PING → PONG.

Стек: GraalVM, Java 25 и игрушки из инкубатора

Итак, решение принято — пишем с нуля на Java. Но не на классической JVM, нет. Тут важный нюанс.

GraalVM native-image— это штука, которая компилирует Java-байткод в самый настоящий нативный бинарник. Никакой JVM при запуске, никакого прогрева JIT-компилятора, startup за миллисекунды. На выходе — один файл размером ~150MB, внутрь которого вшита модель эмбеддингов. Скачал, запустил, работает. Ровно как Redis — никаких плясок с зависимостями.

А раз уж проект всё равно внутренний, не для продажи, и на нём никто в продакшене жизнью не рискует — я решил заодно обкатать несколько технологий из инкубатора. Когда ещё представится такая возможность поиграться с ними на чём-то живом?

Java Vector API (Project Panama)— это SIMD-инструкции прямо из Java-кода, без JNI, без unsafe. Зачем это здесь? Всё просто: самая горячая операция в семантическом поиске — вычисление косинусного сходства между векторами. Когда MEMQUERY пробегает по HNSW-графу и на каждом шаге считает расстояние до очередной ноды — именно здесь SIMD даёт ощутимый прирост. Не теоретический, а вполне измеримый, о чём расскажу ниже.

Project Loom (Virtual Threads)— легковесные потоки, которые Java-рантайм переключает сам, без overhead на OS-треды. Каждое RESP-соединение живёт в своём virtual thread. Никакого event loop, никаких колбэков, никакого reactor pattern — просто пишешь линейный код, а рантайм разруливает конкурентность. После years of reactive programming это ощущалось как глоток свежего воздуха.

ONNX Runtime— инференс моделиall-MiniLM-L6-v2прямо в процессе сервера. 384-мерные вектора, inference ~2-5ms на чанк. Никуда не ходим по сети, всё прямо здесь, в том же процессе.

jvector— Java-реализация HNSW-графа для approximate nearest neighbor search. Зрелая библиотека, хорошо ложится в экосистему.

История про то, как производительность упала, а потом взлетела

А теперь — самое интересное, ради чего, возможно, стоит читать эту статью.

Первая версия работала на обычной JVM. Без Vector API, без native-image. Просто Java, просто ConcurrentHashMap, просто ONNX Runtime через Java-binding. Я запустил memtier_benchmark, посмотрел на цифры и... увидел throughputв два раза хуже, чем у Redis.

Знаете это ощущение, когда ты неделю писал код, запускаешь бенчмарк, и тебе хочется молча закрыть ноутбук и переосмыслить жизненные решения? Вот это было оно.

Но вместо экзистенциального кризиса я сделал две конкретные вещи. Во-первых, скомпилировал всё через GraalVM native-image — убрал JVM startup overhead, убрал JIT warmup, получил предсказуемую производительность с первой секунды. Во-вторых, переписал hot path вычисления косинусного сходства на Vector API с явным использованием SIMD-инструкций.

Результат: с 0.5x Redis до1.36x Redisна строковых операциях. С ~60 тысяч ops/sec до 168 тысяч. Тот самый момент, когда понимаешь, что Java может быть быстрой — надо только знать, где именно она тормозит, и что с этим делать.

Как это работает

Внутри всё устроено достаточно прямолинейно — один процесс, два движка, которые живут рядом и делят данные:

По левую сторону — классический KV-store. 90+ стандартных Redis-команд: строки, хэши, списки, множества, sorted sets, TTL, SCAN, даже базовый pub/sub. Можно подключить Redis Insight на порт 6399 и всё будет выглядеть ровно как обычный Redis. Потому что для клиента это и есть Redis.

Но поверх этого живут четыре команды, ради которых всё и затевалось:

MEMSAVE— принимает текст, разбивает его на чанки по предложениям, каждый чанк прогоняет через ONNX-модель для получения 384-мерного вектора, и индексирует результат в HNSW-граф. При этом сама KV-запись возвращает+OKмгновенно — вся тяжёлая работа с эмбеддингами и индексацией идёт в фоне, асинхронно. Типичная задержка от сохранения до готовности к поиску: 5-10ms на чанк.

MEMQUERY— семантический поиск. Ты формулируешь запрос человеческим языком, система его векторизует и находит ближайших соседей в HNSW-графе по косинусному сходству. Возвращает ключ, текст и score.

MEMSTATUS— статус индексации конкретного ключа:indexed,pendingилиerror.

MEMDEL— удаление из KV-store и из векторного индекса одновременно.

И вот что мне нравится в этом подходе больше всего: никаких кастомных SDK. Jedis, redis-py, ioredis, go-redis — берёшь любой Redis-клиент, который у тебя уже есть в зависимостях, и отправляешьMEMSAVE/MEMQUERYкак обычные кастомные команды черезcall()илиexecute_command():

Для нашего incident investigation agent это изменило всё. LogsInvestigator нашёл OOM — сделалMEMSAVE. MetricsInvestigator перед тем, как лезть строить свои теории, делаетMEMQUERYи сразу видит: коллега уже нашёл root cause, можно не дублировать работу, а дополнить контекст метриками. Один источник правды, никаких галлюцинаций на пустом месте.

Бенчмарки: честные цифры

Примечание: замеры перформанса были произведены с помощью memtier_benchmark, инструмент от redis labs, на отдельном ubuntu-сервере, не на локальной машине, так что результат бенчмарка можно считать легитимным.Результаты можно посмотреть тутhttps://scrobot.github.io/agentis-memory/benchmarks/report.html, ну или произвести самостоятельно.

Слова и архитектурные диаграммы — это замечательно, но в нашем деле принято показывать цифры. Я прогнал memtier_benchmark против Redis 7.4, Dragonfly и Lux. Конфигурация стандартная: 4 threads × 50 clients, данные по 256 байт. Никаких подкруток.

Throughput (ops/sec)

На строках —1.36x Redis. На mixed workload —1.40x. Lux быстрее нас (1.62x) — тут без иллюзий. Но у Lux нет встроенного векторного поиска, и это принципиальная разница.

Latency p99 (ms)

И вот тут нужно быть честным: p99 latency на строках у Redis ощутимо ниже — 3.82ms против наших 6.27ms. Это цена за garbage collection. Даже используя G1, один из лучших GC на сегодняший день, GraalVM native-image минимизирует GC-паузы, но не убирает их полностью — и на хвосте распределения это видно. На хэшах и множествах — примерный паритет со всеми конкурентами.

Pipeline scaling

А вот здесь картина становится по-настоящему интересной:

При pipeline depth 100 —3.19 миллиона ops/sec. Это 1.71x Redis. Здесь начинают играть virtual threads и отсутствие single-threaded event loop: когда запросы идут пачками, многопоточная архитектура масштабируется куда лучше.

Но я хочу подчеркнуть главное: ни один конкурент из этой таблицы не умеетMEMSAVE/MEMQUERYиз коробки. Agentis Memory — единственный в этом сравнении, кто совмещает такую производительность на KV-операциях со встроенным семантическим поиском в одном процессе, без внешних зависимостей.

Privacy-first: почему эмбеддинги должны быть локальными

Отдельно хочу сказать про эмбеддинги, потому что это не просто техническое решение, а осознанный выбор.

Наши агенты работают с данными инцидентов. Логи, метрики, Slack-переписка, PagerDuty алерты — всё это чувствительная информация, которая может содержать что угодно: от имён клиентов до деталей внутренней инфраструктуры. Отправлять всё это куда-то в OpenAI, чтобы получить вектор? Нет, спасибо. Даже если формально это «только эмбеддинги» — зачем рисковать, если можно не рисковать?

all-MiniLM-L6-v2работает через ONNX Runtime прямо в процессе Agentis Memory. Никаких API-ключей, никаких сетевых вызовов, никаких задержек от внешних сервисов, никакой зависимости от чужого uptime. Inference занимает ~2-5ms на чанк — это быстрее, чем один roundtrip до любого облачного API.

И да, это бесплатно. Ноль долларов за embedding, хоть миллион операций в день. Для внутреннего инструмента, который гоняет через себя тысячи фактов — это существенно.

Вместо заключения

Технологии вокруг AI сейчас сменяют одна другую с такой скоростью, что не успеваешь моргнуть. Гонки моделей, гонки инструментов, гонки подходов — даже культура разработки меняется быстрее, чем ты успеваешь к ней привыкнуть. И в этом хаосе очень много инженеров пытается внести свой вклад в новую философию, найти своё место.

Я работаю с AI уже почти пять лет. Мне посчастливилось попробовать GitHub Copilot раньше, чем он стал доступен всем. С тех пор я адаптирую AI в разработке, оптимизирую процессы и переизобретаю подходы — иногда по несколько раз в месяц, потому что то, что работало вчера, завтра уже устаревает.

Agentis Memory — это тоже попытка внести свой вклад в это общее дело. Конечно, это не серебряная пуля и не само совершенство. Можно и покритиковать — и даже нужно, я буду рад конструктивному фидбеку. Но эта штука уже решила множество моих проблем: у меня Claude Desktop, Claude Code, Codex, Antigravity и Junie — все используют shared-память через Agentis Memory. Качество результата стало заметно выше: агенты быстрее понимают, что я от них хочу, совершают меньше ошибок, не дублируют работу.

Свою проблему я решил. Надеюсь, смогу помочь решить и вашу.GitHub:https://github.com/scrobot/agentis-memory