Agentis Memory: تخزين متوافق مع Redis مع بحث متجه وتضمينات محلية

Agentis Memory предлагает простую, но важную для рынка AI-агентов идею: общую оперативную память, с которой можно работать как с обычным Redis. Вместо отдельной векторной базы, внешнего embedding API и кастомных SDK проект совмещает key-value хранилище, семантический поиск и локальный расчёт эмбеддингов в одном процессе. Для команд, которые строят мультиагентные системы, это попытка закрыть одну из самых болезненных проблем — обмен контекстом между агентами без лишних сетевых слоёв и задержек.

Проблема появилась в реальном сценарии расследования продакшн-инцидентов. Когда несколько специализированных агентов параллельно изучают логи, метрики, переписку и историю прошлых сбоев, каждый видит только свой фрагмент картины. Один агент может найти в логах OOMKilled и фактически докопаться до root cause, но остальные в этот момент продолжают строить собственные версии: про всплеск CPU, недавний деплой или любую другую корреляцию.

В итоге синтезатор собирает несколько конфликтующих гипотез, часть из которых просто шум. Попытка хранить такие находки в общем markdown-файле не помогает: начинаются гонки при записи, нет TTL, нет структуры и нет поиска по смыслу. Для агентной системы этого уже недостаточно.

Изучение готовых решений показало ту же проблему с другой стороны. Mem0 и Zep уже позиционируются как memory layer для AI-агентов, но тянут за собой REST API, отдельные SDK, векторное хранилище и внешние сервисы для эмбеддингов. Redis Stack ближе к нужной модели, потому что сохраняет совместимость с Redis-клиентами, но оставляет вычисление векторов за пределами сервера.

Для долговременного RAG это терпимо, а для оперативной памяти, где один агент сохраняет факт и второй должен найти его через миллисекунды, такая схема слишком тяжёлая. Каждый лишний сетевой hop здесь бьёт и по латентности, и по надёжности. Первая инженерная гипотеза была очевидной: взять сам Redis, форкнуть его и встроить внутрь ONNX Runtime и векторный индекс.

На практике этот путь быстро упёрся в сложную работу с C, нативными библиотеками, управлением памятью и нестабильностью при конкурентных запросах. После неудачного прототипа проект переписали с нуля на Java 25 с использованием GraalVM native-image. Так получился единый нативный бинарник примерно на 150 МБ с уже встроенной моделью эмбеддингов.

Внутри используются Java Vector API для SIMD-ускорения косинусного сходства, Project Loom для virtual threads, ONNX Runtime для локального инференса модели all-MiniLM-L6-v2 и библиотека jvector для HNSW-поиска ближайших соседей. Снаружи Agentis Memory ведёт себя как привычный Redis-сервер. Он поддерживает более 90 стандартных команд, TTL, SCAN и базовый pub/sub, а подключаться к нему можно через обычные клиенты вроде redis-py, Jedis, ioredis или go-redis.

Ключевое отличие — четыре дополнительные memory-команды. MEMSAVE принимает текст, режет его на чанки по предложениям, считает 384-мерные векторы и индексирует их асинхронно, обычно за 5–10 миллисекунд на чанк. MEMQUERY принимает запрос на естественном языке и возвращает ближайшие записи по косинусному сходству.

MEMSTATUS показывает, готов ли индекс для конкретного ключа, а MEMDEL удаляет данные одновременно из key-value слоя и из векторного индекса. Для разработчика это выглядит как минимальное расширение уже знакомой модели Redis, а не как отдельная платформа с новой экосистемой. По производительности история тоже получилась показательной.

Первая Java-версия работала примерно вдвое медленнее Redis. После перехода на GraalVM native-image и переписывания hot path через Vector API ситуация развернулась: строковые операции выросли примерно с 60 тысяч до 168 тысяч ops/sec, то есть проект вышел на уровень около 1,36x от Redis. В mixed workload результат составил около 1,40x.

При pipeline depth 100 система показала 3,19 миллиона операций в секунду, или около 1,71x от Redis, благодаря многопоточной архитектуре без single-threaded event loop. Но компромисс остаётся: по latency p99 на строках Redis всё ещё впереди — 3,82 миллисекунды против 6,27 у Agentis Memory, и это цена, которую приходится платить за garbage collection. Отдельный акцент сделан на приватности и стоимости.

Эмбеддинги считаются локально через ONNX Runtime прямо внутри процесса, без API-ключей, без вызовов внешних сервисов и без отправки логов, метрик или служебной переписки в облако. Для систем, которые работают с инцидентами и внутренней инфраструктурой, это не косметическое улучшение, а важное архитектурное решение. Локальный inference занимает около 2–5 миллисекунд на чанк, обходится без отдельного счёта за embedding и снимает зависимость от чужого uptime.

Чем чувствительнее данные и выше частота обращений, тем заметнее выгода такого подхода. На более широком уровне Agentis Memory хорошо показывает, как меняется инфраструктура вокруг AI-агентов. Рынку уже мало просто подключить LLM, инструменты и оркестратор.

Следующая точка конкуренции — общая память, скорость синхронизации контекста и способность системы быстро отбрасывать ложные гипотезы. Если Redis-совместимая модель с локальными эмбеддингами закрепится в реальных нагрузках, такие решения могут стать для агентных систем тем же, чем обычный Redis давно стал для классического backend-разработчика: быстрым слоем координации, кэша и общей рабочей памяти.