Менеджер продуктов Google выпустил в открытом доступе Always On Memory Agent, отказавшись от векторных баз данных в пользу постоянной памяти на базе языковых моделей
Старший менеджер по продуктам Google в области ИИ Шубхам Сабу (Shubham Saboo) превратил одну из самых сложных проблем проектирования агентов в задачу для открытого исходного кода: обеспечение постоянной памяти.
На этой неделе он опубликовал проект с открытым исходным кодом «Always On Memory Agent» на официальной странице Google Cloud Platform в GitHub под мягкой лицензией MIT, разрешающей коммерческое использование.
Он был создан с помощью комплекта разработки агентов Google (ADK), представленного весной 2025 года, и Gemini 3.1 Flash-Lite — недорогой модели, которую Google выпустила 3 марта 2026 года в качестве своей самой быстрой и экономичной модели серии Gemini 3.
Этот проект служит практической эталонной реализацией того, к чему стремится множество команд, занимающихся ИИ, но что лишь немногие смогли полноценно внедрить в производство: агентской системы, способной непрерывно принимать информацию, консолидировать её в фоновом режиме и извлекать её позже без использования традиционной векторной базы данных.
Для корпоративных разработчиков этот релиз важен не столько как запуск продукта, сколько как сигнал о том, куда движется инфраструктура агентов.
Репозиторий предлагает видение долгосрочной автономности, которое становится всё более привлекательным для систем поддержки, исследовательских ассистентов, внутренних вторых пилотов (копилотов) и автоматизации рабочих процессов. Он также заостряет вопросы управления и комплаенса, как только память перестает быть привязанной к конкретной сессии.
Что этот репозиторий делает — и на что он явно не претендует
Судя по всему, в репозитории используется многоагентная внутренняя архитектура, где специализированные компоненты отвечают за приём, консолидацию и запросы данных.
Однако предоставленные материалы не содержат четких доказательств более масштабного утверждения о том, что это фреймворк разделяемой памяти для нескольких независимых агентов.
Это различие имеет принципиальное значение. ADK как фреймворк поддерживает многоагентные системы, но этот конкретный репозиторий лучше всего описывать как постоянно работающий агент памяти (или уровень памяти), построенный с использованием специализированных субагентов и постоянного хранилища.
Даже на этом более узком уровне он решает фундаментальную инфраструктурную проблему, над которой активно работают многие команды.
Архитектура отдает предпочтение простоте перед традиционным стеком извлечения данных
Согласно документации репозитория, агент работает непрерывно, принимает файлы или входные данные через API, сохраняет структурированную память в SQLite и по умолчанию выполняет плановую консолидацию памяти каждые 30 минут.
В комплект входят локальный HTTP API и панель управления на Streamlit. Система поддерживает обработку текста, изображений, аудио, видео и PDF-файлов. Дизайн проекта сопровождается намеренно провокационным заявлением: «Никаких векторных баз данных. Никаких эмбеддингов. Только языковая модель (LLM), которая читает, думает и записывает структурированную память».
Такое проектное решение наверняка привлечет внимание разработчиков, занимающихся оптимизацией затрат и операционной сложности. Традиционные стеки извлечения данных часто требуют наличия отдельных конвейеров эмбеддингов, векторных хранилищ, логики индексирования и процедур синхронизации.
Пример Сабу, напротив, полагается на саму модель для прямой организации и обновления памяти. На практике это позволяет упростить прототипы и сократить разрастание инфраструктуры, особенно для агентов с малым или средним объемом памяти. Это также смещает вопрос производительности с накладных расходов на векторный поиск в сторону задержки модели (латентности), логики компактизации памяти и долгосрочной поведенческой стабильности.
Flash-Lite придает экономический смысл работе постоянно активной модели
Именно здесь в дело вступает Gemini 3.1 Flash-Lite.
По заявлению Google, эта модель создана для высоконагруженных рабочих процессов разработчиков в масштабных проектах и оценивается в $0,25 за 1 млн входных токенов и $1,50 за 1 млн выходных токенов.
Компания также заявляет, что Flash-Lite в 2,5 раза быстрее Gemini 2.5 Flash по времени до получения первого токена и обеспечивает увеличение скорости вывода на 45% при сохранении аналогичного или более высокого качества.
Согласно опубликованным бенчмаркам Google, модель набирает 1432 балла по шкале Elo на Arena.ai, 86,9% в GPQA Diamond и 76,8% в MMMU Pro. Google позиционирует эти характеристики как оптимальные для высокочастотных задач, таких как перевод, модерация, генерация пользовательских интерфейсов (UI) и симуляция.
Эти показатели помогают понять, почему Flash-Lite используется в паре с агентом фоновой памяти. Круглосуточный сервис, который периодически перечитывает, консолидирует и предоставляет память, нуждается в предсказуемой задержке и достаточно низкой стоимости инференса, чтобы не делать режим «always on» непомерно дорогим.
Документация Google ADK подкрепляет общую картину. Фреймворк представлен как независимый от моделей и средств развертывания, с поддержкой рабочих агентов, многоагентных систем, инструментов, оценки и целей развертывания, включая Cloud Run и Vertex AI Agent Engine. Такое сочетание делает агента памяти не столько разовой демоверсией, сколько ориентиром для более широкой стратегии выполнения агентов (runtime).
Корпоративные дебаты касаются управления, а не только возможностей
Реакция общественности показывает, почему корпоративное внедрение постоянной памяти не будет зависеть исключительно от скорости или стоимости токенов.
Несколько комментариев в X (бывший Twitter) четко обозначили опасения, которые, скорее всего, выскажут корпоративные архитекторы. Франк Абе (Franck Abe) назвал Google ADK и круглосуточную консолидацию памяти «блестящим скачком к непрерывной автономности агентов», но предупредил, что агент, который «мечтает» и перекрестно опыляет воспоминания в фоновом режиме без детерминированных границ, превращается в «кошмар для специалистов по комплаенсу».
ELED высказал схожую мысль, утверждая, что главная стоимость круглосуточно работающих агентов заключается не в токенах, а в «дрейфе и зацикливании» (drift and loops).
Эти критические замечания бьют точно по операционной нагрузке постоянных систем: кто может записывать память, что именно объединяется, как работает хранение, когда воспоминания удаляются и как команды проверяют то, чему агент научился со временем?
Другой комментарий от пользователя по имени Иффи (Iffy) поставил под сомнение концепцию репозитория «без эмбеддингов», аргументируя это тем, что системе всё равно приходится разбивать на фрагменты (chunking), индексировать и извлекать структурированную память, и что это может хорошо работать для агентов с малым контекстом, но дать сбой, когда объемы памяти станут значительно больше.
Эта критика технически обоснована. Удаление векторной базы данных не отменяет проектирование извлечения данных; оно меняет место сосредоточения сложности.
Для разработчиков компромисс заключается не в идеологии, а в соответствии задачам. Более легкий стек может быть привлекателен для недорогих агентов с ограниченной памятью, в то время как крупномасштабные внедрения всё равно могут потребовать более строгих элементов управления извлечением, более явных стратегий индексирования и надежных инструментов управления жизненным циклом.
ADK расширяет рамки за пределы одной демоверсии
Другие комментаторы сосредоточились на рабочем процессе разработчиков. Один из них запросил репозиторий и документацию ADK, пожелав узнать, является ли среда выполнения бессерверной (serverless) или долгоживущей (long-running), а также доступны ли из коробки вызовы инструментов (tool-calling) и хуки для оценки (evaluation).
Судя по предоставленным материалам, ответ по сути положителен и для того, и для другого: сам пример агента памяти структурирован как долгоживущий сервис, в то время как ADK в целом поддерживает различные паттерны развертывания и включает в себя инструменты и возможности оценки.
Постоянно работающий агент памяти сам по себе интересен, но главный вывод заключается в том, что Сабу пытается сделать агентов похожими на развертываемые программные системы, а не на изолированные промпты. В такой концепции память становится частью среды выполнения, а не просто дополнительной функцией.
Что Сабу показал — а чего нет
То, чего Сабу еще не показал, ровно так же важно, как и опубликованные материалы.
Предоставленные материалы не содержат прямого сравнения (бенчмарка) между Flash-Lite и Anthropic Claude Haiku для агентских циклов в производственных условиях.
В них также не прописаны средства контроля соответствия корпоративного уровня (enterprise-grade compliance), специфичные для данного агента памяти, такие как: детерминированные границы политик, гарантии хранения, правила сегрегации или формальные рабочие процессы аудита.
И хотя в репозитории, судя по всему, внутренне используются несколько специализированных агентов, материалы убедительно не доказывают более масштабное утверждение о постоянной памяти, разделяемой между несколькими независимыми агентами.
На данный момент этот репозиторий выглядит скорее убедительным инженерным шаблоном, чем полноценной корпоративной платформой памяти.
Почему это важно именно сейчас
Тем не менее, релиз появился вовремя. Корпоративные ИИ-команды выходят за рамки одноразовых ассистентов и переходят к системам, от которых ожидается способность запоминать предпочтения, сохранять контекст проекта и работать на более длинных горизонтах планирования.
Репозиторий памяти с открытым исходным кодом от Сабу предлагает конкретную отправную точку для этого нового уровня инфраструктуры, а Flash-Lite придает этой экономической модели достоверность.
Однако самый сильный вывод из реакции на запуск заключается в том, что непрерывная память будет оцениваться не только по возможностям, но и по уровню безопасности и контроля (governance).
Это и есть главный корпоративный вопрос, стоящий за демонстрацией Сабу: не сможет ли агент запоминать информацию, а сможет ли он делать это таким образом, чтобы оставаться в определенных рамках, поддаваться проверке и быть достаточно безопасным для доверия в production-среде.
