Агентный ИИ или три чат-бота в плаще: как отличить одно от другого

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

Но правда и то, что так умеют не все. Разбираемся, как отличить настоящего агента от подделки.

Что на самом деле продают под словом «агентный»

В некоторых недобросовестных случаях агентом могут назвать что угодно — Gartner называют это agent washing, то есть выдавание обычного продукта с ИИ-ассистентом или RPA за полноценный агентный инструмент. По оценкам компании, только 130 вендоров из тысяч и тысяч представленных на рынке, действительно продают ИИ-агентов. 

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

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

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

Признаки агентности

У платформенного агентного ИИ есть несколько проверяемых свойств:

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

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

3. Права доступа к данным настраиваются для ИИ так же, как для человека — по ролям, по отделам, по чувствительности данных. Агент, который отвечает на вопросы бухгалтерии, не должен видеть переписку HR просто потому, что модель одна на всех.

Как это работает на примере агента в поддержке

Как выглядит работа ИИ агента со стороны пользователя: юзер пишет «где моя заявка», и вместо ссылки на портал самообслуживания получает готовый ответ с актуальным статусом. А если заявка зависла, ИИ-агент сам эскалирует её нужному специалисту, не дожидаясь, пока кто-то заметит просрочку по SLA.

Со стороны архитектуры посмотрим на примере платформы SimpleOne (подробнее об архитектуре ИИ-агентов на платформе рассказывали в статье). Тут агент — это не отдельная функция, а конфигурация из нескольких частей: инструкция, которая описывает роль («ты аналитик по инцидентам», «ты агент поддержки первой линии»), и адаптер — набор методов, которые агент может вызвать. Если метода нет в адаптере, агент физически не может его выполнить. Придумать себе новый инструмент по ходу дела он не может, и это, конечно, ограничивает фантазию модели, зато закрывает главный страх безопасников: ИИ, который сам решил, что ему можно.

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

Агент проверит заявки в системе и проанилизирует их

В универсальном ассистенте можно попросить агента создать другого агента с конкретной задачей

Каждый вызов метода при этом попадает в журнал: какой инструмент дёрнул, с какими параметрами, что вернулось в ответ и как модель интерпретировала результат перед следующим шагом.

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

Адаптер при этом не ограничен методами внутри платформы. Через MCP туда же подключаются внешние инструменты — Jira, git, система мониторинга, — и агенту без разницы, откуда именно брать результат: он просто видит единый список того, что ему разрешено вызвать. Если пользователь написал «сервер лежит с ночи», агент может сам проверить статус в системе мониторинга, найти по нему связанный тикет в Jira и только после этого вернуться с готовым ответом. Чат-бот выдал бы статью из базы знаний и отправил бы человека в поддержку.

Это один и тот же механизм, применённый к разным задачам, а не набор разных ИИ-функций, каждая со своей логикой. Разницу между агентом и чат-ботом с советами видно тогда, когда нужно узнать не что ответила модель, а что она сделала, по какому праву и где это записано.