ИИ-агенты без оркестрации и роутинга

Если у вас мультиагентная система или сложный RAG, то с большой вероятностью вы используете жесткий роутинг или оркестрацию.

Например, в мультиагентной системе могут быть сложные разветвления и в каждой точке, в зависимости от результата предыдущего агента, нужно пойти налево (запустить ветку агентов A) или направо (запустить ветку агентов Б). Это жесткий роутинг.

Или приходит запрос от пользователя и нужно его классифицировать, вы отправляете его в LLM, получаете ответ, что запрос про A или про Б, и направляете к агенту RAG, который отвечает за область A или Б. Это оркестрация.

Минусы такого подхода

Любое изменение такой логики требует изменения графа агентов (в коде или в UI).

Любая ошибка в роутинге, как правило, приводит в тупик, то есть получается неверный результат из-за обработки неправильной цепочкой. Например, в RAG пользователь не получит ответ, потому что роутинг завел в область Б, а ответ на самом деле в области A.

Цепочка может быть длинной и будет долго выполняться. Иногда речь идет о 5-10 минутах и дольше.

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

Если в системе есть проблемы с роутингом или оркестрацией, то система сама себя не исправит и будет глючить на всех аналогичных edge-кейсах.

Какая есть альтернатива?

Работа без роутинга и оркестрации. Но как? Куда будет приходить запрос и как агенты будут понимать, что им делать?

Каждый ИИ-агент имеет доступ к LLM, то есть он уже умный и способен распарсить любой объем данных в любом формате (в рамках контекстного окна LLM).

Тогда зачем нам определять жесткую связь агентов и жесткие форматы данных между ними?

Как конкретный агент поймет, что ему делать? Он должен знать свою задачу, то есть свою цель. Значит, каждому агенту задаем, кроме prompt, еще и goal (цель).

Теперь каждый агент читает общий чат и сравнивает его со своей целью, если в этом общем шуме есть что-то для него, он начинает работать и возвращает результат обратно на эту борду.

Количество шума и объем данных на борде растет. Нужно как-то разделить агентов, не могут же они все работать на одной борде.

Тогда объединяем агентов в рои: один рой агентов = одна борда. У роя, как и у агента, тоже есть цель (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-системы

AI-агенты — клоны сотрудников

Как сделать ИИ-агентов и RAG действительно автономными

Как сделать RAG/ИИ-ассистента без кода