В MAS сессия — это не диалог, а управляемый граф выполнения задачи. В MAS мысль не заперта внутри одной модели. Она существует в динамике: LLM → гипотеза → State → Blackboard → следующий агент → проверка → новая гипотеза

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

1. Инициализация: Сессия ≠ Окно контекста Оркестратор получает глобальную цель и запускает воркфлоу (session_id, роли, ресурсы, лимиты).

Важно разделять уровни: Session Context живет на протяжении всей задачи/процесса (десятки итераций). LLM Context Window получает только те данные, которые необходимы для одного конкретного шага запроса к LLM.

2. Топологии выполнения Агенты декомпозируют задачу и передают результаты по одной из схем:

Sequential: A → B → C Parallel: Goal → A / B / C → Aggregator Event-driven: A → Event → B & C

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

3. Где хранится состояние? Для архитектурной чистоты разделяем четыре понятия: Session — контур выполнения задачи. Context — данные для конкретного вызова LLM. Memory — долговременная база знаний (RAG / Vector DB / Graph DB). Blackboard / State — оперативное состояние текущего коллективного рассуждения.

Blackboard обеспечивает общий доступ к рабочему состоянию. Сессия завершается по критерию успеха или лимиту (SUCCESS, FAILED, TIMEOUT, MAX_ITERATIONS, HUMAN_REQUIRED).

4. Production-требования к состоянию Без строгого управления жизненным циклом состояния агенты начнут использовать устаревшие данные или затирать результаты друг друга при параллельной работе. Поэтому вокруг Blackboard строят инженерный обвес:

Checkpoints & Versioning — контроль версий и откат состояний. Locks & Transactions — защита от состояния гонки  race conditions. Event Log & Observability — полная прослеживаемость т.е. кто, на основе чего и какой инструмент вызвал.