Как ИИ-агенты делят общую память и не мешают друг другу

Мультиагентная система из трёх ролей — планировщик, исполнитель, критик — падает не там, где вы ждёте. Не в логике рассуждений, а в момент, когда два агента одновременно обращаются к общему хранилищу: один дописал промежуточный результат, второй прочитал версию до записи и построил вывод на устаревших данных. Это не гипотетика, а типичная гонка данных, знакомая всем, кто когда-либо писал многопоточный код. Только теперь вместо потоков — LLM-агенты, а вместо переменной в памяти процесса — векторное хранилище или общий стейт в оркестраторе.

Разберём, какие бывают модели общей памяти между агентами, чем каждая платит за удобство и как не превратить систему в клубок неявных зависимостей.

Что вообще значит «общая память» у агентов

Под памятью в мультиагентных системах понимают три разных вещи, и их постоянно путают.

• Контекст в рамках одного вызова — то, что попадает в промпт: история сообщений, результаты инструментов. Живёт от запроса до ответа.
• Рабочий стейт задачи (working memory) — общие для агентов данные текущей задачи: план, промежуточные факты, статусы шагов. Живёт от начала до конца выполнения.
• Долгосрочная память (long-term) — то, что переживает задачу: векторная база с фактами, профиль пользователя, накопленные наблюдения.

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

Термин, который стоит зафиксировать

Neймспейс (namespace) — именованная область памяти, к которой привязаны записи. Например, task:1234/plan и user:42/preferences — два разных неймспейса. Разграничение по неймспейсам — базовый способ не дать агентам затирать чужие данные.¹

Четыре модели совместного доступа

1. Общий плоский стейт

Самый простой вариант: один словарь или один объект, куда все агенты пишут и откуда все читают. В LangGraph это State, в CrewAI — общий контекст экипажа. Работает, пока агенты ходят по очереди.

Как только появляется параллелизм — например, два исполнителя одновременно обновляют список findings — последняя запись затирает предыдущую. Классический lost update. Спасает не размер модели, а дисциплина: либо строго последовательный доступ, либо разведение веток по ключам.

2. Неймспейсы и владельцы

Каждый агент пишет только в свой раздел, читать может из общих. Планировщик владеет plan, исполнитель — results/*, критик — review. Пересечений по записи нет, а значит нет и гонок на запись.

Минус — координация. Если критику нужно, чтобы исполнитель дописал ещё один результат, он не может сделать это сам: приходится возвращать управление. Система становится предсказуемой, но более «болтливой».

3. Сообщения вместо общей памяти

Агенты не лезут в общий стейт, а обмениваются сообщениями — как акторы в модели Actor. Общего изменяемого состояния нет вообще: есть входящие очереди. Такой подход снимает гонки по определению, но переносит сложность на согласованность: кто-то должен собирать финальный результат из потока сообщений.

4. Версионированное хранилище

Каждая запись получает версию или временную метку. Агент, читая значение, запоминает версию; при записи проверяет, что версия не изменилась (оптимистичная блокировка). Если изменилась — перечитывает и повторяет. Это дороже по обращениям, но единственный вариант, где параллельная запись в общий ключ безопасна.

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

Сравнение подходов

Как это выглядит в коде

Пример оптимистичной блокировки поверх обычного хранилища ключ-значение. Логика не зависит от конкретной БД — важен принцип compare-and-set.

def update_shared(store, key, mutate_fn, retries=5):
    for _ in range(retries):
        record = store.get(key)          # {'value':..., 'version': N}
        current = record["value"]
        version = record["version"]
        new_value = mutate_fn(current)   # агент считает новое значение
        ok = store.compare_and_set(
            key,
            expected_version=version,
            new_value=new_value,
        )
        if ok:
            return new_value
    raise ConflictError(f"Не удалось записать {key} после повторов")

compare_and_set должен быть атомарным на стороне хранилища — иначе проверка версии сама превращается в гонку. Redis умеет это через WATCH/MULTI, Postgres — через условный UPDATE ... WHERE version = $1.

Что почитать из чужого опыта

Практика сходится к нескольким правилам, независимо от фреймворка:

1. По умолчанию — раздельные неймспейсы. Общий ключ на запись заводите только осознанно.
2. Любой параллельный запуск агентов требует явной стратегии слияния результатов, а не «пусть пишут в один список».
3. Долгосрочную память отделяйте от рабочей: смешивание приводит к тому, что мусор из одной задачи всплывает в другой.
4. Логируйте версии и авторство записей. При разборе странного поведения вы захотите знать, кто и когда затёр значение.

Отдельная боль — векторная память как общее хранилище. Когда несколько агентов пишут наблюдения в одну коллекцию, поиск начинает возвращать дубликаты и противоречия. Помогает дедупликация на записи и метаданные с источником, чтобы при извлечении можно было отфильтровать по агенту или задаче.

Общая память ускоряет обмен между агентами ровно до того момента, пока вы не наступаете на первую гонку. Дальше выигрывает та архитектура, где заранее решено, кто владеет каждым ключом и что происходит при конфликте. Начните с неймспейсов и переходите к версионированию только там, где параллельная запись действительно нужна.