Многоуровневая память для корпоративных AI-агентов: опыт реализации в VK AI Space
В июле 2026 года VK AI Space представила новую систему памяти для корпоративных искусственных интеллектов. Решение позволяет агентам сохранять контекст между сессиями и эффективно работать над долгосрочными проектами. Автор статьи, Сергей Врулин, описывает переход от теоретических моделей к практической реализации, где ключевым элементом стали обычные текстовые файлы вместо сложных векторных баз данных.
# Как создали многоуровневую память для AI-агентов в VK
Приветствую. Меня зовут Сергей Врулин, я Team Lead в команде агентов VK AI Space. Наша задача — создать платформу, где искусственный интеллект способен вести себя как профессиональный коллега, а не как чат-бот, который забывает всё после завершения диалога. В этой статье я расскажу о технической реализации многоуровневой памяти, представленной в июле 2026 года, и о компромиссах, сделанных в пользу прозрачности и управляемости для корпоративного сектора.
Зачем агенту нужна память?
Типичный языковая модель (LLM) работает без сохранения состояния. Контекстное окно ограничено, и при завершении сессии вся информация исчезает. Для бытового использования это допустимо: пользователю не критично, если бот не помнит диалог из месяца назад. Однако в корпоративной среде отсутствие памяти делает автоматизацию бессмысленной.
Рассмотрим примеры сценариев: * Анализ инцидентов: Если агент участвовал в разборе сбоя в продакшене, он должен помнить эти выводы через неделю, а не начинать поиск логи заново. * Подготовка тендеров: Формулировки, написанные для одного заказчика, должны быть доступны для нового тендера от того же лица. * Проектная отчетность: Агент должен сохранять шаблон дайли-репорта и не требовать повторного объяснения формата каждый день.
Для этих задач агент должен уметь сохранять профиль сотрудника, накопленные решения и собственный опыт.
Архитектура памяти и выбор формата
В теории выделяют пять типов памяти: кратковременная (текущий диалог), эпизодическая (события), семантическая (факты), процедурная (навыки) и профильная (данные пользователя). Существующие фреймворки, такие как MemGPT или LangGraph, часто используют векторные базы данных для долгосрочного хранения.
Однако в корпоративном сегменте подход с «черным ящиком» неприемлем. Векторные эмбеддинги невозможно прочитать человеку, их сложно редактировать и гарантировать изоляцию между проектами. Мы отказались от сложной системы поиска по смыслу в пользу модели «память как обычные текстовые файлы» (plain text / Markdown).
Преимущества простого текста
1. Прозрачность: Файлы SOUL.md или USER.md читаются человеком в обычном редакторе без декодирования векторов.
2. Управляемость: Сотрудник может напрямую исправить фразу в документе, а не искать нужную запись в базе данных и пересчитывать хеши.
3. Предсказуемость: LLM получает контекст точно так, как он записан в файле, без вероятностной ошибки семантического поиска.
Реализация на практике
Мы построили архитектуру на основе стандартных файловых систем, расположенных в объектном хранилище S3. Вся память структурирована по типам данных:
| Тип памяти | Файл | Хранилище | Описание | | :--- | :--- | :--- | :--- | | Кратковременная | Session Scope | В памяти раннера | История сообщений текущей сессии | | Эпизодическая | Workspace файлы | S3 (по проекту) | События и решения, дописываемые после выполнения задачи | | Семантическая | SOUL.md | S3 (по агенту) | Идентичность и характер агента | | Процедурная | AGENTS.md, TOOLS.md | S3 (по агенту) | Правила работы и инструкции к инструментам | | Профильная | USER.md | S3 (по пользователю) | Данные о сотруднике и его предпочтениях |
Изоляция данных обеспечивается через префиксы в S3, зависящие от ProjectID, UserID, AgentID и SessionID. Это гарантирует, что агент одного проекта не увидит данных другого.
Механизм инъекции контекста
Критически важным решением стало отсутствие необходимости тратить токены модели на поиск файлов. Мы выбрали подход Full Injection + Sandbox Write.
Вместо того чтобы агент запрашивал файлы по требованию (on-demand), мы используем системные pre-hooks. Перед запуском цикла агента скрипт считывает указанные файлы и вставляет их содержимое в системный промпт. Это позволяет агенту видеть всю необходимую информацию (правила, профиль пользователя, историю) с самого первого сообщения, экономя до 5 тысяч токенов и секунд задержки на каждый запрос.
Запись в память происходит через стандартные операции с файловой системой песочницы (Sandbox), которая синхронизирует изменения обратно в S3. Таким образом, агент работает с файлами как с локальным диском, не понимая при этом сложности распределенной архитектуры.
Управление контекстом через хуки
Логика работы с памятью управляется системой хуков (hooks) с четырьмя триггерами: pre, post, tool, error. Для работы с памятью ключевыми являются pre и post хуки.
* Pre-agent hook: Собирает контекст из файлов SOUL.md, USER.md и инструкций перед началом выполнения задачи. Формирует единый блок <agent_identity>, <user_profile> и других секций в промпте. * Post-agent hook: Сохраняет итоги работы. Может обновлять процедурную память (новые правила в AGENTS.md) или профильную информацию.
Такой подход универсален: файлы служат надежным хранилищем, а хуки обеспечивают гибкую логику сборки и обновления контекста, позволяя агентам работать автономно и безопасно в корпоративной среде.
Помните: даже самый совершенный алгоритм бесполезен без правильной памяти. Прозрачность и контроль над данными становятся решающими факторами при внедрении ИИ в сложные бизнес-процессы.