Ранас Мукминов – Оркестрация ИИ-агентов. Claude Opus 4.7 (страница 41)

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

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

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

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

Набор агентов изменчив. Если состав исполнителей меняется со временем — добавляются новые специализации, выводятся устаревшие, — слабая связанность blackboard окупается: новый источник знания подключается, не затрагивая существующие, потому что все они связаны только через схему доски, а не друг с другом. Это аргумент эволюционируемости (связь с версионированием ролей — см. главу 22).

Сводно условия применимости и противопоказания:

Признак задачи | Blackboard уместен | Адресная топология лучше

Порядок шагов | неизвестен, выводится из данных | фиксирован или предсказуем

Характер вклада | разнородный, оппортунистический | однородный или строго стадийный

Форма результата | инкрементальное частичное решение | результат за один проход

Состав агентов | изменчивый, расширяемый | стабильный, известный

Зависимости | многие-ко-многим, неявные | явные, направленные

Главная ценность | гибкость и развязка | предсказуемость и трассируемость

Если по большинству строк выбор тяготеет к правой колонке, blackboard добавит сложность общего состояния, ничего не дав взамен. Это типовой антипаттерн (см. главу 7): доску берут за «архитектурность», тогда как fan-out/fan-in или конвейер решили бы задачу с меньшим риском.

Полезно сформулировать выбор и через предмет декомпозиции (см. часть V). Адресные топологии предполагают, что задачу можно разложить заранее: оркестратор знает подзадачи на старте, конвейер знает стадии. Blackboard уместен ровно тогда, когда разложить задачу заранее нельзя — декомпозиция сама становится частью работы и происходит динамически, по мере того как находки одних источников открывают подзадачи для других. Иными словами, blackboard переносит декомпозицию из этапа проектирования в этап исполнения. Это и его сила (он справляется там, где план неизвестен), и его цена (исполнение становится недетерминированным и хуже наблюдаемым). Если же декомпозиция статична и известна на старте, выносить её в исполнение через общую доску — значит платить за гибкость, которая не нужна.

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

Опрос (polling). Простейший контроль: периодически проверять предусловия всех источников знания и активировать применимые. Дёшево в реализации, но плохо масштабируется — стоимость растёт с числом источников и частотой опроса, а для агентов на больших языковых моделях каждая проверка применимости может стоить вызова модели, то есть реальных денег и латентности. Опрос терпим при малом числе источников и нечастых изменениях доски.

Событийная активация. Изменение доски порождает событие, и активируются только источники, чьи предусловия зависят от изменённого участка. Это связывает blackboard с событийной координацией (см. главу 28): доска становится источником событий, а контроль — диспетчером подписок. Дороже в проектировании, но устраняет холостое сканирование и лучше масштабируется.

Приоритизированная очередь готовности. Контроль ведёт очередь источников, чьи предусловия выполнены, и выбирает из неё по приоритету: какой вклад вероятнее всего продвинет решение к завершению. Это самая мощная и самая хрупкая стратегия — её качество определяет, сойдётся ли система к решению или будет блуждать. Приоритизация в blackboard играет ту же роль, что планирование очередей в распределении работы (см. главу 35).

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

Первая — строгая сериализация: активировать ровно один источник за цикл, дать ему зафиксировать вклад, затем заново пересчитать применимость. Это максимально предсказуемо и исключает гонки записи по построению, но это и максимально медленно: вся параллельность принесена в жертву упорядочиванию. Подходит, когда вклады сильно зависят друг от друга и порядок важен.

Вторая — параллельная активация с непересекающимися областями записи: контроль пускает несколько источников одновременно, но только если они пишут на разные участки доски и потому не могут затереть друг друга. Это восстанавливает параллелизм там, где он безопасен, и опирается на ту же стратификацию уровней: если контроль знает, какой источник на какой уровень и участок пишет, он может доказать непересечение до запуска. Это предпочтительная стратегия для масштабируемого blackboard.

Третья — оптимистическая параллельная активация с разрешением конфликтов после: пустить всех применимых, дать им писать, а пересечения разрешать на фиксации — по версии записи, по приоритету источника или повторным прогоном проигравшего на обновлённом состоянии. Это самый быстрый и самый сложный путь; он смыкается с темой конфликтов изменений (см. главу 40), и его корректность целиком зависит от того, насколько аккуратно реализовано разрешение. Для недетерминированных агентов-на-модели оптимистический путь рискован: повторный прогон проигравшего стоит ещё одного вызова модели, и нет гарантии, что повтор сойдётся, — поэтому на практике для таких узлов чаще выбирают вторую стратегию, разводя писателей заранее, а не разрешая конфликты постфактум.

Здесь кроется неустранимое напряжение паттерна. Чтобы blackboard был корректен, доступ к доске должен быть согласован: нельзя, чтобы два источника одновременно прочитали одно состояние, независимо его изменили и затёрли вклад друг друга. Значит, нужна та или иная сериализация записи. Но чем строже сериализация, тем больше контроль становится узким местом (см. главу 57) и единой точкой отказа (см. главу 75): вся система ждёт, пока контроль решит, кого пустить к доске.

Это прямое следствие закона Амдала для роёв (см. главу 56): доска и контроль образуют последовательную долю, которую нельзя распараллелить. Можно сколько угодно увеличивать число источников знания, но если все они проходят через единственную точку упорядочивания доступа к доске, пропускная способность упрётся в эту точку. Поэтому масштабируемый blackboard почти всегда требует разбиения доски на слабосвязанные секции, к которым можно обращаться независимо, — но это разбиение возвращает часть той самой связанности, ради устранения которой брали blackboard.

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

Если два источника знания читают доску, независимо вычисляют вклад и пишут обратно без согласования, второй затирает первого — классическая гонка lost update. В адресном обмене такого нет: сообщение от одного агента не уничтожает сообщение от другого. На доске же, где координация — это запись в общее состояние, незащищённая параллельная запись прямо ведёт к потере работы. Защита — это механизмы из главы 41: единственный писатель на участок, оптимистическая блокировка с проверкой версии записи, атомарные операции обновления. Дешевле всего проектировать доску так, чтобы у каждого участка был ровно один тип источника-писателя, а остальные только читали; тогда гонок записи на этот участок нет по построению.

Опаснее открытого тупика — ситуация, когда источники продуктивно работают, но не сходятся. Источник A видит запись от B и переписывает её; источник B видит переписанное и возвращает своё; контроль исправно активирует обоих. Доска меняется без остановки, бюджет токенов расходуется, а решение не приближается. Это livelock на уровне роя (см. главу 74), и в blackboard он коварен тем, что выглядит как активная работа: система занята, метрики активности высокие, но завершающее условие не приближается. Защита — отдельная тема главы 45; на уровне доски минимум таков: завершающее условие должно опираться на монотонную меру прогресса (например, доля заполненных слотов решения, которая не должна убывать), а контроль обязан останавливать систему, если эта мера не растёт в течение заданного числа циклов.