Агенты выходят на работу (часть 3)

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

Во второй части говорили о процессах — чего не хватает в типовых BPM и как можно ситуацию улучшить.

И вот настало время поговорить об агентах.

Хайп, мимо которого нельзя пройти

Когда разговоры об агентах несутся из каждого утюга, это невозможно игнорировать. Хайп? — Несомненно. Однако, рациональное зерно тут все-таки есть, и, когда хайп уляжется, что-то полезное да останется. Чем раньше его получится разглядеть, тем лучше.

Вот и я не смог пройти мимо))
Сначала никаких агентов в моем плане не было, я хотел просто немного усовершенствовать BPM, чтобы было удобнее назначать исполнителей.

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

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

Почему же люди, несмотря на эти риски, пытаются включить агентов в свои рабочие процессы? Опять синдром FOMO — Fear Of Missing Out, страх упущенных возможностей. Пока мы рассуждаем о рисках, конкуренты уже внедряют ИИ.

— А вдруг у них все грохнется? — Вот было бы славно! — А вдруг нет? — Тогда они уйдут в отрыв, что не есть хорошо.

Настоящий разрыв заключается не в самой технологии, а в пространстве между возможностями ИИ и их безопасным применением в корпоративной среде

Строим мост

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

Но при этом в корпоративной среде всё работает под жесткими рамками: security, accountability, compliance, «кто, что, когда, зачем нажал». Каждое решение хочется видеть прослеживаемым, аудируемым и уложенным в политики управления рисками. Именно поэтому классические системы строятся консервативно — не ради бюрократии, а чтобы гарантировать надежность и защитить бизнес.

Вот тут и появляется концепция unified execution — своего рода «единое ядро выполнения» для всего этого хаоса систем и процессов внутри компании. Она дает структуру: как собирать разрозненные воркфлоу, согласовывать их с реальностью корпоративных правил и обеспечивать, чтобы работа продвигалась плавно, предсказуемо и без лишнего трения.

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

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

Что значит «нанять агента»?

Все говорят «мы нанимаем агентов». Но что это значит на практике? — Обычно сводится к тому, что ставят на локальный компьютер Claude, Open Claw или Hermes, дают ему все логины-пароли и он начинает работать. А иногда творить дичь. То есть, это все не более, чем метафора — «мы нанимаем».

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

Как это выглядит технически:

• Заводим нового сотрудника, говорим, что его тип это АГЕНТ, а не ЧЕЛОВЕК.

• Создаем аккаунты в корпоративных системах и связываем их с сотрудником-агентом.

• Назначаем агента на должность или на несколько должностей.

• Вуаля! — Агент может приступать к работе!

Теперь агенты отображаются у нас в общем списке сотрудников наряду с людьми — quod erat demonstrandum.

Дальше вы можете назначать агентов исполнителями на юзер-таски в процессах точно так же, как и людей. Причем сами процессы перепроектировать не надо!

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

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

Но целом так — агент выполняет юзер-таски. Тогда действительно появляется взаимозаменяемость агентов и людей. Это была ключевая идея.

К слову сказать, основные вендоры BPM-платформ, Camunda и Flowable идут по другому пути. Они читают агента некой особой сущностью и создают под него новые типы задач. В итоге это сводится к вызову API, совершенно инженерный подход.

Тоже вариант, но это требует от вас изменения процессов, что может оказаться хлопотно.
И, как мне кажется, они недооценивают агентов. Работая с тем же Cursor, я заметил, что иногда он вполне понимает задачу с полуслова, без огромных md-файлов скиллов и спецификаций. Определенно, агенты будут умнеть и лучше понимать контекст. Может скоро и не придется им писать пошаговые инструкции.

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

Процессы — это инструменты

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

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

Простейший пример — выполнить поиск в интернет, прочитать выбранные страницы и составить краткую справку по теме.

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

Здесь он отредактировал какой-то файл, здесь пошарил что-то в интернете, отправил куда-то сообщение… Конечно, в каждой системе может быть настроено логирование и можно потом все действия агента собрать воедино каким-нибудь process mining’ом, но это все сложно и непрозрачно.

А пусть инструментами агента будут процессы! Что это нам дает:

• Прозрачность — процессы наглядны, их выполнение отражается в единой истории.

• Унификацию — все тулы имеют единообразные интерфейсы; помните из прошлого поста, что у процесса есть input/output JSON-схемы?

• Кастомизацию — процесс легко изменять и дорабатывать.

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

Агент видит JSON-схему, генерит нужные входные данные и стартует процесс. Когда процесс-инструмент завершается, агент читает его результат и думает, что делать дальше.

Таким образом, круг замкнулся:

• Агент участвует в процессе, выполняя задачи

• Агент запускает процессы-инструменты и пользуется их результатами

Вы ведь уже поняли, что в процессе-инструменте исполнителями могут быть и другие агенты, да? Или люди, если это эффективнее или требуется по протоколу. Например, агент может готовить договора, но подписывает их человек.

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

Собственно, настоящих tool’ов, объявленных согласно спецификации Open AI, у любого из агентов всего четыре:

• Вызвать процесс (invoke_process)

• Получить схему процесса (get_process_schema) — чтобы не раздувать системный промпт их полными описаниями

• Получить результаты процесса (get_process_result)

• Получить навык (get_skill) — тоже чтобы сохранить системный промпт компактным

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

Реализация

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

Поэтому я пошел стандартным путем:

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

• Привязываться к конкретной модели тоже резона не было. Также не хотелось закладываться на какой-то один сервис. Поэтому сделал две интеграции — с Groq (не путать с Grok!) и с OpenRouter.

Оба эти сервиса дают какой-то лимит бесплатных токенов, что для экспериментов было важно. Конкретную LLM-модель можно выбрать в настройках.

Диалог

Мы привыкли, что ИИ чат-боты могут вести с нами осмысленный диалог и помнят, о чем мы говорили. Но это потому, что нам дают не просто доступ к LLM, а готовое приложение.

Когда мы обращаемся к LLM по API, никакой памяти у нее нет, сама модель stateless. Поэтому на каждом шаге диалога с ней приходится передавать полный контекст — каждый раз начинать с системного промпта и все, что было уже сказано по данной задаче. Ведь за одну итерацию практически никакой вопрос решить невозможно.

В итоге получилась вот такая блок-схема диалога:

Мы терзаем модель модель вопросами, пока она не даст финальный ответ и не выберет при этом, по какому пути продолжить процесс.

Вы еще не забыли, что сейчас мы находимся внутри user task в BPMN-процессе?
И что по выходу из него может стоять шлюз, и исполнитель задачи должен принять решение — согласовать или отказать договор, повернуть налево или направо, выдать командировочные или нет и так далее.

Все это агент видит через JSON-схему задачи и поэтому может дать нам детерменированный ответ.

Если заглянуть немного под капот, то будет примерно такая картина:

Цифровые следы

Для энтерпрайза важно не только выполнить задачу, но еще правильным образом все запротоколировать, чтобы потом достойно отбиться от всяких проверок. Это называется красивым непонятным словом комплаенс.

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

Однако, если посмотреть вооруженным глазом, есть еще одна вещь, за которой стоит приглядывать — это взаимодействие агента с LLM-моделью. Чтобы и здесь у нас все было шито-крыто, добавил протоколирование всех этих разговоров — все сообщения пишутся в специальный объект Conversation, который можно выгрузить в текстовый формат в виде одного файла — это очень удобно для анализа, если что-то пошло не так.

Просто берем весь этот conversation, кидаем в тот же ChatGPT и просим разобраться.

Модель агента

Приведу для иллюстрации, чтобы подытожить, что у меня получилось.

Модель агента здесь описана как функциональный блок IDEF0.

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

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

Механизмами выступают доступные инструменты — то есть, процессы, где агент имеет роль «инициатор». Когда эти инструменты использовать, агент решает сам.

Такой подход делает модель не абстрактной, а инженерно управляемой. Мы не просто говорим, что агент что-то делает, а явно фиксируем, что именно приходит на вход, чем он управляется, через что работает и какой результат обязан выдать.

О дальнейших планах

Что еще хотелось бы сделать, чтобы стало совсем хорошо:

Подпишитесь на канал Agentic Enterprise — про жизнь агентов в кровавом энтерпрайзе

Приходите на вебинар Агенты и процессы в корпоративном контуре