Thoughtworks переоткрыла для ИИ-агентов паттерн blackboard из 1980-х

Thoughtworks Europe провела внутренний эксперимент под названием hyper-agentic: 10 инженеров собрали в одной комнате в барселонском офисе компании, чтобы проверить, как далеко и как быстро можно продвинуться, если по максимуму положиться на агентную разработку (agentic engineering). Задачей было построить систему IROps, irregular operations, то есть систему, которой пользуются диспетчерские центры авиакомпаний при сбоях: техническая неисправность самолёта, заболевший член экипажа, отмена рейсов, замена бортов, размещение снятых с рейса пассажиров в отелях и так далее, причём одновременно по сотням самолётов, сотням тысяч пассажиров и множеству экипажей на разных станциях и в разных аэропортах. Это специально признанная сложная задача, сложно построить, сложно понять, сложно эксплуатировать. Систему собрали за четыре дня. Работали от практического технического задания и симулированной (не настоящей) авиакомпании, поскольку это было учебное упражнение, а не проект для реального клиента.

Все инженеры работали одновременно в одном общем репозитории (монорепозитории). Когда агентов стало много, сборочный конвейер начал страдать, и команда ввела дисциплину: агенты обязаны были постоянно коммитить изменения и делать rebase от основной ветки, а затем пушить только после того, как пройдут все проверки сборки, это должно было ловить ошибки сборки локально, интегрируя изменения часто и рано. У этого решения обнаружился побочный эффект. Агентов направляли планировать работу, привязывая план к конкретным пронумерованным разделам технического задания, и эти планы хранились прямо в репозитории. Все агенты работали по одному и тому же техзаданию с одинаковой нумерацией разделов, а по мере работы обновляли планы, фиксируя прогресс, и эти обновления, наравне со всем остальным, попадали в тот же частый коммит-цикл. В результате агенты стали видеть прогресс друг друга.

Например, один агент работал над «оценщиком» (evaluator), компонентом, который определяет, допустим ли конкретный план восстановления операций и не нарушает ли он жёсткие или мягкие ограничения. Одновременно другой агент работал над алгоритмом поиска планов устранения сбоя, который зависит от оценщика: у компонентов общий интерфейс, и поиск не может работать без оценщика. В планах фиксировались именно точки интеграции: один агент писал в плане, что на определённом этапе ему нужно будет переключить вызовы на настоящий верификатор, другой, что на своём этапе ему нужно будет вставить вызов этого верификатора, когда тот появится. Оба агента видели чужие планы и прогресс по ним: один агент помечал строку плана как «в работе», и второй просто не брался за неё; когда первый заканчивал, второй видел не только то, что работа готова и путь свободен, но и получал заметки о том, как именно она была сделана. Команда начала сознательно этим пользоваться: например, зная, что кто-то параллельно пишет и постоянно коммитит модель стоимости (cost model), агента, работающего над верификатором, направляли следить за репозиторием и планами и начинать интеграцию сразу, как только код модели стоимости появится в репозитории. И это сработало. Всё это возникло случайно, как побочный эффект цепочки решений, команда сначала это заметила, а уже потом начала использовать намеренно.

У обнаруженного поведения есть название, паттерн «доска объявлений» (blackboard). Доска объявлений (или тьюпл-спейс), это общая память, в которую независимые друг от друга автономные агенты могут писать и из которой могут читать записи («тьюплы») минимальной согласованной структуры, но с произвольными дополнительными полями и без единой жёсткой схемы. Это эффективный способ координировать автономных решателей задач, направленных на одну общую цель: каждый решает свой кусок декомпозированной задачи, кладёт результат в общее пространство, помечает его, а другие агенты находят пометку, забирают результат и используют в своей работе. Автор материала узнал паттерн по собственному научному опыту: в университетском исследовании по управлению поведением агентов через иерархические сенсоры он опирался на технику blackboard как основную структуру координации, паттерн, впервые обнаруженный при разработке системы Hearsay-II в 1980 году и позднее оформленный в более строгую концепцию тьюпл-спейсов Гелернтером с соавторами (Gelernter et al.) в 1986 году.

Автор подчёркивает, что команда наткнулась на использование репозитория как доски объявлений случайно, а не намеренно, и получившаяся реализация была неполной, в ней не хватало ряда ключевых элементов настоящей архитектуры blackboard. Из-за случайности автор не уверен, что смог бы надёжно воспроизвести это поведение у агентов снова, хотя пост-фактум команда провела разбор и вычленила конкретный промпт, который запустил всю цепочку. От дисциплины частых коммитов и пушей команда впоследствии отказалась: она перегружала конвейер непрерывной интеграции (CI), и пушить стали только по завершении цельного логического куска изменений, но это лишило агентов постоянного потока обновлений о прогрессе друг друга, на которых и строилась координация. По мнению автора, хороший канал такого рода должен быть независим от системы контроля версий, а не быть побочным эффектом коммитов. Отталкиваясь от этого вывода, автор начал отдельный проект под названием Talwrn (валлийское слово, означающее яму для молотьбы, место, где разбираются споры и конфликты): инструмент, который должен встраиваться прямо в проект и сразу давать агентам канал связи для координации работы, оформленный намеренно, а не случайно. Первая цель проекта, довести Talwrn до состояния, в котором он сможет поддерживать разработку самого себя; автор планирует регулярно публиковать материалы о нём, используя его как один непрерывный пример чистой агентной разработки.

Ключевые факты

Thoughtworks Europe собрала 10 инженеров в барселонском офисе на учебное упражнение «hyper-agentic» и с помощью ИИ-агентов за четыре дня построила систему IROps для управления сбоями авиакомпании, по практическому техзаданию и с симулированной, не настоящей, авиакомпанией.
Дисциплина постоянных коммитов и rebase от основной ветки (введённая, чтобы ловить ошибки сборки раньше) заодно вынесла в общий репозиторий планы агентов, привязанные к разделам техзадания, и агенты начали читать чужие планы, чтобы понимать прогресс друг друга.
Агенты стали помечать строки плана как «в работе» и «готово», получая от других агентов заметки о том, как выполнена интеграционная точка, например, агент, писавший верификатор, ждал в репозитории появления кода модели стоимости от другого агента и сразу начинал интеграцию.
Автор узнал в этом поведении классический паттерн «доска объявлений» (blackboard), общую память для независимых агентов, впервые описанную на системе Hearsay-II в 1980 году и формализованную как тьюпл-спейс Гелернтером с соавторами в 1986 году.
Поведение возникло случайно и оказалось хрупким: частые коммиты перегружали CI, отказ от них лишил агентов канала координации, и автор запустил отдельный проект Talwrn, инструмент, который должен намеренно давать агентам такой канал в обход системы контроля версий.

Почему это важно

Это первое живое подтверждение того, что классический паттерн распределённых систем 40-летней давности, доска объявлений (blackboard), придуманная для системы Hearsay-II в 1980 году и формализованная как тьюпл-спейс в 1986-м, сам собой воспроизводится, когда несколько ИИ-агентов пишут код в одном репозитории. Команде не понадобилось проектировать отдельный протокол координации: обычные артефакты версионного контроля, коммиты и файлы планов, привязанные к разделам техзадания, сами стали общей памятью, через которую агенты узнавали о прогрессе друг друга и синхронизировали работу над зависимыми компонентами.

Кому это важно

Инженерным командам, которые строят конвейеры из нескольких одновременно работающих кодовых ИИ-агентов (агентная разработка, agentic engineering), а также разработчикам инструментов оркестрации агентов: описанный случай, сырой пример того, какие механизмы координации агенты выстраивают сами, если дать им общий репозиторий и дисциплину частых коммитов.

Как это применить

Из наблюдения можно взять практический приём: хранить планы агентов в самом репозитории и явно привязывать их к пронумерованным разделам технического задания, тогда прогресс одного агента становится видимым другим через обычный git. Но у приёма есть цена: слишком частые коммиты и пуши перегружают конвейер CI, а переход на пуш только цельными кусками работы обрывает поток обновлений, на котором держалась координация. Поэтому автор считает, что канал координации для агентов правильнее строить отдельно от системы контроля версий, а не полагаться на её побочный эффект, этому и посвящён его новый проект Talwrn.

Можно ли доверять

Материал, авторский пост из серии Thoughtworks «Exploring Gen AI», где технологи компании фиксируют собственные эксперименты с генеративным ИИ; в видимом тексте статьи персональное имя автора не указано, подписи нет. Это рассказ из первых рук об одном внутреннем учебном упражнении с симулированной авиакомпанией, а не о продакшене у реального клиента и не результат контролируемого исследования: сам автор прямо пишет, что поведение агентов было случайным и он не уверен, что смог бы надёжно воспроизвести его снова.

Риски и подводные камни

Ключевая оговорка самого автора: эффект был непреднамеренным и, по его собственной оценке, ненадёжно воспроизводимым, реализация координации была неполной и не содержала ряда обязательных элементов настоящей архитектуры blackboard. Использование git как импровизированного канала координации хрупко: дисциплина частых коммитов, которая его порождала, одновременно перегружала CI-конвейер, а отказ от неё эту координацию разрушил. Наконец, эксперимент проходил на симулированном клиенте и учебном техзадании, а инструмент Talwrn, который автор предлагает как осознанную замену случайному эффекту, только начатый проект без объявленных сроков выпуска.

«Удачное случайное решение требует продуманного, осознанного проекта.»

— автор материала Thoughtworks «Exploring Gen AI»