Если у вас мультиагентная система или сложный RAG, то с большой вероятностью вы используете жесткий роутинг или оркестрацию.
Например, в мультиагентной системе могут быть сложные разветвления и в каждой точке, в зависимости от результата предыдущего агента, нужно пойти налево (запустить ветку агентов A) или направо (запустить ветку агентов Б). Это жесткий роутинг.
Или приходит запрос от пользователя и нужно его классифицировать, вы отправляете его в LLM, получаете ответ, что запрос про A или про Б, и направляете к агенту RAG, который отвечает за область A или Б. Это оркестрация.
Минусы такого подхода
Любое изменение такой логики требует изменения графа агентов (в коде или в UI).
Любая ошибка в роутинге, как правило, приводит в тупик, то есть получается неверный результат из-за обработки неправильной цепочкой. Например, в RAG пользователь не получит ответ, потому что роутинг завел в область Б, а ответ на самом деле в области A.
Цепочка может быть длинной и будет долго выполняться. Иногда речь идет о 5-10 минутах и дольше.
Сбои в цепочках агентов происходят из-за сбоя в данных. Один агент вернул не тот формат, или не те данные, и следующий агент не смог их обработать.
Если в системе есть пробле��ы с роутингом или оркестрацией, то система сама себя не исправит и будет глючить на всех аналогичных edge-кейсах.
Какая есть альтернатива?
Работа без роутинга и оркестрации. Но как? Куда будет приходить запрос и как агенты будут понимать, что им делать?
Каждый ИИ-агент имеет доступ к LLM, то есть он уже умный и способен распарсить любой объем данных в любом формате (в рамках контекстного окна LLM).
Тогда зачем нам определять жесткую связь агентов и жесткие форматы данных между ними?
Выпускаем агентов в общее поле, даем им общее когнитивное пространство (общий чат), и они начинают читать все и пробуют понять, что им делать.
Как конкретный агент поймет, что ему делать? Он должен знать свою задачу, то есть свою цель. Значит, каждому агенту задаем, кроме prompt, еще и goal (цель).
Теперь каждый агент читает общий чат и сравнивает его со своей целью, если в этом общем шуме есть что-то для него, он начинает работать и возвращает результат обратно на эту борду.
Мы назвали ее Blackboard по аналогии с доской в школе, на которой все пишут мелом
Количество шума и объем данных на борде растет. Нужно как-то разделить агентов, не могут же они все работать на одной борде.
Тогда объединяем агентов в рои: один рой агентов = одна борда. У роя, как и у агента, тоже есть цель (goal). Рой тоже обладает интеллектом за счет подключения к LLM.
Это уже коллективный интеллект и, как правило, он намного умнее отдельно взятого агента. По сути, рой похож на режим DeepThink (умный режим или режим исследования) в нейросетях, но рой быстрее, потому что он не обязан работать последовательно, агенты в роях могут работать параллельно друг другу.
Затем рои объединяем в мета-рои со своим интеллектом, и получаем еще более умную систему.
Рои не обязаны быть статичными, по сути, они могут эволюционировать без изменения кода или графа агентов. Только за счет изменения целей и подсказок, и за счет спец-агента - god-agent, рой может меняться, подстраиваясь под задачи и улучшая результативность ответов.
Создание роев и мета-роев тоже может быть динамическим. А дальше мы подключаем Darwin эволюцию, и вполне можем получить Agentic AGI (то есть сильный искусственный интеллект), только без квадралиона параметров и без недель на обучение и без миллиардов $.
Это вообще работает?
Да, мы уже сделали прототип, назвали его Blackboard и продолжаем развивать дальше. Продолжаем тестировать его на разных кейсах. Некоторые рои и мета-рои выглядят пугающе умными.
Дальше нужно много дней, недель, месяцев тестов, много токенов и много человеческого интеллекта, чтобы развить это в полноценный фреймворк.
Я уверен, что это единственный вариант развития Agentic AI. Все остальные все равно скатываются в if then фреймворки, со всеми проблемами, описанными в начале этой статьи.
Кейсы
Как работает наш новый протокол BlackBoard для Agentic AI?
Для простоты добавлены два rag-agent (один по адаптации сотрудников, другой по юридическим вопросам). Агент user-agent читает все ответы агентов и составляет ответ для пользователя. Это позволяет избежать стадии роутинга (нет задержки) и получить информацию от всех вовлечённых агентов.
Можно включить режим принятия решения агентами в нашем протоколе BlackBoard
Несмотря на то, что агенты хорошо справляются с шумом на BlackBoard и способны фильтровать то, что относится именно к ним, бывает полезно заставить агентов думать прежде, чем отвечать. Для этого включаем режим принятия решения на основании контекста переписки о том, участвовать или нет. Как видим, adaptation-agent понял, что вопрос к его теме не относится, и не стал засорять эфир.
На общий вопрос user-agent ответит сам
Как видим, legal-agent и adaptation-agent поняли, что вопрос не по их теме, и не стали отвечать, но user-agent тоже обладает знаниями и ответил на вопрос пользователя.
Другой агент уже работает над задачей
Переводим наш Blackboard-механизм для общения агентов на параллельный запуск всех агентов 😱
Я думал, всё сломается, но стало даже лучше — вот агент понял, что другой агент уже работает над задачей и принял решение не участвовать 🔥
Перспектива масштабирования нашего подхода становится ещё лучше 🚀
Агенты сами просят других агентов помочь, если нужно
Здесь три агента — один пишет статью по теме, другой редактирует согласно политикам редакции, третий проверяет грамматику. Никто не объединял этих агентов в цепочку, они просто сами просят друг друга помочь.
А что если добавить шума?
Все агенты обучаются жить в шумной среде. Здесь добавлены агенты, создающие шум, но это не влияет на выполнение задачи 🤓.
Для управления хаосом переписки на BlackBoard можно добавить moderator-agent
Он будет подавлять лишний шум. Агенты слушают друг друга и уважают мнение других.
Если никто не смог помочь пользователю, то поможет god-agent
god-agent читает всю переписку на BlackBoard и среди шума понимает, когда нужно создать нового агента, чтобы адресовать новый тип запроса от пользователя.
Будет еще много типов агентов на BlackBoard
На BlackBoard можно создать любое количество и любые типы агентов.
В планах добавить:
🕷️ spider-agent — для поиска в интернете
🧭 lead-agent — для координации микро-роев агентов
🔌 API-agent — для доступа к внешним API
🗃️ sql-agent — для доступа к БД
💬 stream-user-agent — для стриминга ответа пользователю
🧠 memory-agent — для памяти всех переписок
🧩 control-agent — для контроля выполнения мета-задач
🛡️ security-agent — для контроля безопасности переписки агентов
Мета рои агентов
На BlackBoard агенты, которые живут на одной борде, являются роем, агенты внутри борды, объединённые одной задачей, являются микро-роем (координируют сами либо при помощи lead-agent), а вот набор досок, объединённых в мета-чат с помощью user-agent каждой борды, является мета-роем.
Таким образом происходит разделение на 3 уровня, позволяющее очень гибко выстраивать сложные схемы координации агентов. Никакого жёсткого каркаса и связей агентов при этом нет, что позволяет получать результаты уровня человека — наборы микро-, макро- и мета-роев будут сами подстраиваться под входящие задачи.
BlackBoard Darwin version
После внедрения простой версии BlackBoard с функционалом, описанным ранее, будет делаться версия Darwin, где все агенты будут эволюционировать от задачи к задаче. Агенты, плохо выполняющие задачу, не будут отбираться в следующее поколение. Хорошо выполняющие будут отбираться, затем crossover и мутация.
Наша цель — сделать действительно независимую саморазвивающуюся систему агентов, устойчивую к шуму и не ограниченную узкими протоколами (fail-tolerant system). Создаваемые рои агентов BlackBoard должны будут обойти человека в выполнении задач и адаптации к новым правилам и задачам.
Наши предыдущие статьи
Больше по теме Agentic AI вы можете почитать тут. И в статьях ниже.
Как сделать RAG для своей компании — полный разбор архитектуры корпоративной RAG-системы
