GlowByte: как ИИ-агенты вырастают из реальных задач сотрудников

Архитектура многих корпоративных мультиагентных платформ строится вокруг конструктора. Предполагается, что пользователь или специальная команда соберет агента из готовых блоков и свяжет их в нужной последовательности. Агентов создают либо специалисты, которые обслуживают платформу, либо продвинутые пользователи. Выглядит это просто, но, по нашему опыту в GlowByte, задача на деле сложная и архитектурная.

Устроены такие конструкторы примерно одинаково. Есть «белая доска» и множество готовых блоков, которые нужно расставить, соединить в нужном порядке и настроить по отдельности. Агента для подготовки к переговорам с поставщиком мы собрали именно в таком конструкторе. Получилась схема из 29 блоков. Часть блоков конструктор помечает красными значками, потому что им еще не хватает подключений и настроек.

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

Кажется, что интерфейс конструктора снижает технический барьер. На деле пользователю приходится одновременно разбираться в бизнес-процессе, в архитектуре агента и в том, какие примитивы есть на платформе. Блоков в каталоге сотни, среди них Embeddings, Retrievers, Output Parsers, Vector Stores, и значение каждого придется выяснять.

Это работа для сильного архитектора, который проектирует серьезные системы, а такие конструкторы задумывались для обычных бизнес-пользователей. Накидать блоки, соединить их и нажать «Старт» у них, скорее всего, получится, хотя с первого раза агент вряд ли заработает. Но сопоставить бизнес-архитектуру агента с набором технических примитивов одной кнопкой не выйдет. Можно возразить, что пользователь будет двигаться итерациями, то есть соберет, посмотрит и поправит. Но для этого нужно понимать, что происходит на стыке двух блоков, а ждать такого знания от обычного пользователя нереально.

Я сам считаю себя продвинутым бизнес-пользователем и пробовал собрать агента в таком конструкторе. Расставить блоки оказалось мало, каждый нужно настроить. Заходишь внутрь блока и видишь, что данные соседнему блоку он передает в формате JSON, а тебе показывают схему этого формата. Первый вопрос, который у меня возник: что такое JSON и что за схема у него?

Это напоминает историю SQL. Его придумали в начале 1970-х, чтобы информацию из баз данных могли доставать не только программисты, но и, скажем, бухгалтеры или инженеры. Синтаксис и правда выглядит понятным: SELECT означает «извлеки», FROM показывает источник, в WHERE пишут условия. Казалось, что пользователи смогут сами выгружать любые данные, не дергая аналитиков. Но много ли бизнес-пользователей сегодня сами пишут SQL-запросы? С конструкторами агентов происходит то же самое. Идея хорошая, но порог входа на практике высокий.

Исключения бывают. Я знаю одну компанию, где нашлась группа продвинутых бизнес-пользователей, которая освоила конструктор и теперь как летучий отряд ходит по участкам и собирает агентов для себя и коллег.

При таком подходе создание агента повторяет весь длинный цикл заказной разработки: сбор требований, описание текущего (AS-IS) и целевого (TO-BE) процессов, согласования, тестирование и запуск. Поэтому от момента, когда нашли боль бизнеса, до готового решения может пройти слишком много времени.

Обычно команда бизнес-аналитиков (своих или наемных) идет к пользователям с вопросом «Где у вас что болит?». Люди и так замучены операционной рутиной, часто не понимают, чего от них хотят, и отвечают как получится. Потом аналитики рисуют текущий процесс и сверяют его с пользователями, затем формулируют целевой, в котором найденных проблем нет или их стало меньше. На этой основе пишут требования к решению, и их еще нужно согласовать.

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

Сейчас появляются модули, которые собирают агента по текстовому запросу. Это упрощает создание агентов: блоки подбирает платформа, а разбираться в схеме JSON, скорее всего, уже не придется. Но цикл по-прежнему начинается с требований. Как правило, такие модули уточняют требования и оформляют их, но не идут дальше, пока человек не подтвердит, что агент правильно понял задачу. Значит, пользователю придется заранее разобраться в бизнес-процессе и понять, где агент принесет пользу, а на это может уйти те самые полгода. А если требования собраны неточно или процесс успел измениться, платформа за несколько часов соберет агента, который аккуратно решает не ту задачу.

При новом подходе специализированного агента не обязательно проектировать заранее. Пользователь сразу получает агента общего назначения «из коробки», а специализация появляется в ходе работы. Мы в GlowByte даем пользователю корпоративную мультиагентную платформу, где такие агенты есть сразу. Внутри работает агентный цикл, но вникать в него пользователю не нужно: достаточно написать агенту в веб-интерфейсе или в мессенджере, в том числе в корпоративном.

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

Для пользователя это маленькое открытие: подготовку к переговорам уже можно отдавать агенту. Агент тоже кое-что замечает. Если пользователь часто приходит с одним и тем же запросом, проще упаковать его в навык, тогда результат будет предсказуемее и появится быстрее. Агент предлагает запомнить сценарий, и пользователь отвечает что-то вроде «О, классно, давай».

Пользователь может в любой момент поправить такой навык или отключить его. Так агент постепенно обрастает записями в памяти и навыками, и чем дольше с ним работают, тем сильнее он «прокачан» под пользователя.

Собрать специализированного агента заранее на такой платформе тоже можно, но блоки для этого не нужны, потому что агенту пишут инструкции обычным языком и дают навыки, свои или готовые. Правда, сделать это можно, только когда уже понятно, что агент должен делать, а иначе мы снова упираемся в сбор требований. Зато править агента, даже сложившегося из диалогов, проще, чем перестраивать схему из блоков: достаточно переписать инструкцию или поправить навык. В GlowByte мы обычно советуем сначала дать ИИ-агенту сложиться на реальных задачах пользователя, а потом дорабатывать его вручную, когда видно, что работает, а что нет.

Пользователю не нужно сначала учиться работать с платформой. Возможности агента он открывает постепенно, на своих задачах. Агента несложно сразу подключить к корпоративной почте и календарям. Допустим, пользователь просит агента посмотреть календарь коллеги. Оказывается, агент может заглянуть и в календарь самого пользователя, а потом и назначить встречу. Следом пользователь просит большего: «А ты можешь напомнить мне об этой встрече и подготовить такой же отчет, как для переговоров, только под тему встречи?» Агент может, а иногда сам предлагает такой сценарий, потому что знает, какие у него есть инструменты. Так пользователь шаг за шагом узнает, что умеет агент, и агент становится его напарником.

ИИ-агента не нужно создавать отдельным проектом: он складывается из повседневных задач, и для этого не нужны ни длительная подготовка, ни многодневное обучение. Никому не приходится выискивать проблемные места в процессах. Если что-то действительно болит, пользователь сам придет с этим к агенту. По-моему, именно так агенты и приносят основную пользу.

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

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

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

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

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

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