Blackboard для агентов: общая доска вместо цепочки промптов

Пока разработчики спорят, что лучше — жёсткий граф из LangGraph или свободный рой агентов, старая идея из мира экспертных систем 1980-х тихо вернулась в мультиагентные фреймворки. Речь про blackboard — общую «доску», куда все агенты пишут промежуточные результаты и откуда читают то, что нужно для своего шага. Вместо того чтобы передавать сообщения по цепочке, агенты работают с одним разделяемым состоянием. Паттерн описан ещё в проекте распознавания речи Hearsay-II, но в 2024–2025 годах его начали переоткрывать команды, у которых линейные пайплайны перестали масштабироваться.

Что такое blackboard в мультиагентной системе

Идея простая. Есть центральное хранилище — доска. Есть набор специалистов (в терминах паттерна — knowledge sources, в терминах LLM — агенты). И есть контролёр, который решает, кому дать ход. Каждый агент смотрит на доску, проверяет, может ли он что-то добавить, делает свой шаг и записывает результат обратно. Дальше цикл повторяется, пока задача не решена.

В отличие от диалога «агент А отправил сообщение агенту Б», здесь нет прямой адресации. Агент-исследователь кладёт на доску собранные факты. Агент-критик видит их появление и добавляет замечания. Агент-редактор собирает из этого черновик. Никто из них не знает о существовании остальных напрямую — они знают только про доску.

Blackboard меняет вопрос «кому переслать результат» на вопрос «что сейчас лежит на доске и кто может это продвинуть дальше». Это развязывает агентов друг от друга ценой усложнения контроля.

Три части паттерна

• Доска (blackboard) — структурированное общее состояние. На практике это JSON-объект, запись в базе или документ, разбитый на секции: задача, факты, гипотезы, черновики, финал.
• Knowledge sources / агенты — независимые модули. Каждый умеет одно и активируется, когда на доске появляется то, с чем он работает.
• Контролёр (controller) — компонент, который на каждом такте выбирает, какому агенту дать выполниться. Может быть простым циклом, а может быть отдельной LLM, оценивающей состояние доски.

Чем это отличается от графа и оркестратора

Три подхода к координации агентов сегодня конкурируют, и у каждого своя цена.

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

Как это ложится на текущие фреймворки

Явной «кнопки blackboard» в популярных библиотеках пока нет, но паттерн собирается из готовых кирпичей:

• В LangGraph роль доски играет общий объект состояния (state), который узлы читают и обновляют. Контролёр — это условные рёбра, решающие, какой узел вызвать следующим.
• В AutoGen общий чат группы агентов частично выполняет ту же функцию: история сообщений становится разделяемым контекстом, а менеджер группы — контролёром.
• В CrewAI координация ближе к оркестратору, но общий контекст задачи можно использовать как упрощённую доску.

То есть blackboard сегодня — это скорее способ мышления об архитектуре, чем отдельный продукт. Вы реализуете его поверх того, что уже есть.

Кому это пригодится и кому нет

Blackboard — не универсальное улучшение. Он решает конкретный класс проблем и создаёт новые.

Когда стоит брать

• Итеративная доработка. Черновик статьи или кода прогоняется через генератор, критика и редактора неопределённое число раз, пока не пройдёт проверку. Порядок и количество итераций заранее неизвестны.
• Сбор из разных источников. Несколько агентов независимо добывают куски информации (поиск в вебе, запрос к базе, вызов API), и результат собирается по мере готовности, а не строго по очереди.
• Расширяемость. Вы планируете часто добавлять новых специалистов, не переписывая логику маршрутизации. Новый агент просто начинает читать и писать на доску.

Когда лучше не надо

• Линейный процесс из 2–3 шагов. Если маршрут фиксирован, граф или простая функция дешевле и понятнее. Доска добавит накладных расходов на контроль без выгоды.
• Жёсткие требования к предсказуемости. Когда нужен воспроизводимый результат и аудит каждого шага, свободный порядок активации агентов усложняет отладку.
• Бюджет на токены ограничен. Доска легко разрастается, и на каждом такте агент может подтягивать её большой кусок в контекстное окно¹. Это прямые деньги: чем больше состояние, тем дороже каждый вызов модели.

Подводные камни

Паттерн выглядит элегантно на диаграмме, но в реализации у него несколько болячек.

1. Зацикливание. Критик отправляет черновик на доработку, редактор возвращает почти то же самое, критик снова недоволен. Без счётчика итераций и критерия остановки система крутится и жжёт токены.
2. Гонки за состояние. Если несколько агентов пишут на доску параллельно, они могут перезаписать чужой результат. Нужна дисциплина обновлений: секции доски, версии или блокировки.
3. Раздувание контекста. По мере работы доска накапливает историю. Приходится либо суммаризировать старое, либо давать каждому агенту только нужную секцию, а не всё состояние целиком.
4. Непрозрачный контроль. Если контролёром выступает отдельная LLM, её решения о том, кого активировать, тоже нужно логировать и проверять — иначе разобраться, почему система выбрала не того агента, будет тяжело.

¹ Контекстное окно — максимальный объём текста (в токенах), который языковая модель может учитывать за один вызов. Всё, что не влезло, модель «не видит». Большая доска, целиком подаваемая на вход, быстро упирается в этот предел и удорожает запрос.