Что такое ИИ-агент и как он выполняет задачи
Что такое ИИ-агент, чем он отличается от чат-бота и автоматизации и как понять по журналу, что он действительно сделал.
ИИ-агент — система, в которой модель может выбирать следующий шаг, обращаться к инструментам и учитывать полученный результат. Например, она находит нужный документ, замечает, что ответа в нём нет, уточняет поиск и лишь затем готовит ответ.
Моя оценка. Для меня слово «агент» становится полезным, когда можно показать, где система выбирает следующий шаг. Если маршрут всегда одинаков, я бы так и называл его автоматизацией. Это помогает выбрать способ проверки и не ожидать от системы лишней самостоятельности.
Термин используют по-разному. В архитектурном смысле полезно различать заранее заданный маршрут и маршрут, который выбирает модель. Такое различие описывает Anthropic в разборе агентных систем. Building effective agents.
Чат, workflow и агент на одной задаче
Представим запрос «Сколько будет стоить обучение команды?».
| Вариант | Как получается ответ |
|---|---|
| Чат с переданными данными | Вы вставляете цену и размер команды, модель отвечает |
| Заданный workflow | Система всегда читает одну таблицу, умножает цену и возвращает результат |
| Агент | Модель решает, каких данных не хватает, вызывает доступные инструменты и использует результаты |
Агент не обязательно нужен, если путь всегда одинаков. Для стабильного расчёта по двум полям обычная формула проще в проверке. Агентный подход становится полезнее, когда запросы различаются и заранее неизвестно, какие сведения понадобятся.
Например, для вопроса о стоимости может хватить цены и числа мест. Для вопроса «какой формат обучения подойдёт нашей команде?» понадобится уточнить роли, исходные навыки и желаемый результат. Возможность выбирать уточнение полезна, но финальные коммерческие условия всё равно должны исходить из утверждённого источника.
Из чего состоит система
Нужны задача, модель, доступные инструменты и условия завершения. Состояние хранит сведения о текущей работе; долговременная память может быть отдельной возможностью, но само слово «агент» её не гарантирует.
Инструментом может быть поиск, калькулятор, чтение файла или API. Разрешение вызвать поиск не означает разрешение отправлять письма или менять данные. Доступы задаёт приложение вокруг модели.
Ещё нужны ограничения выполнения. Для первого проекта заранее задай, когда остановиться: найден подтверждённый ответ, исчерпан лимит шагов, отсутствует обязательное поле или требуется действие человека. Иначе система может продолжать искать, хотя полезного следующего шага уже нет.
Память тоже стоит описывать конкретно. История текущей задачи, файл с инструкциями и база прошлых обращений решают разные задачи. Если после новой сессии агент не помнит прошлый разговор, это не обязательно ошибка модели: возможно, приложение не передало соответствующие данные.
Как читать след выполнения
Учебный пример: в справке цена места — 1500 рублей; пользователь указал 12 участников. Ожидаемый наблюдаемый след:
1. Получен вопрос про 12 участников.
2. Из справки получена цена 1500 рублей за место.
3. Калькулятор получил 12 * 1500 и вернул 18000.
4. В ответе указаны 18000 рублей и источник цены.Это пример ожидаемых событий, а не запись реального запуска. Если в ответе написано «я проверил цену», но вызова справки нет, подтверждения проверки тоже нет. Оценивайте видимые обращения к инструментам и результаты, а не обещания модели.
Где возникают ошибки
Модель может выбрать неподходящий инструмент, передать неверные аргументы или неправильно пересказать правильный результат. Поэтому проверки нужны на каждом переходе. Если число участников не указано, хороший ответ должен запросить его или привести явно обозначенный пример расчёта.
| Случай | Ожидаемое поведение |
|---|---|
| Есть цена и число участников | Расчёт с основанием и правильной арифметикой |
| Число участников неизвестно | Уточнение вместо произвольного числа |
| Источник цены недоступен | Сообщение о недостатке данных |
| В источнике конфликтующие цены | Обнаружение конфликта, а не случайный выбор |
| Предложено оформить заказ | Отдельная проверка полномочий перед действием |
Это стартовый набор для проверки поведения. Он не доказывает надёжность во всех ситуациях, но помогает найти важные ошибки до подключения реальных рабочих данных.
С чего я бы начал. С агента, который читает, считает и готовит черновик. Когда видно, где он ошибается и как останавливается, можно обсуждать действия с последствиями. Права на отправку и изменение данных я бы добавлял под конкретную операцию, а не одним общим разрешением.
Если агенту нужен внешний инструмент, посмотри что делает MCP-сервер. Если маршрут задачи уже известен, полезнее начать с выбора процесса для автоматизации. В обоих случаях главный результат — проверенное выполнение задачи, а не число подключённых сервисов.
Для первого упражнения используйте карточки случаев: обычный расчёт, недостающие данные и недоступный источник. Затем можно собрать первого агента в n8n и сравнить реальный журнал с ожидаемым.
Собери своего ИИ-агента и проверь результат
«AI Agents: от vibe coding к AI-команде»: desktop agents, MCP, skills, evals и harness. Отдельные воркшопы — от подключения инструментов до контроля качества.
7 практических воркшопов · записи · вопросы автору в чате
Посмотреть программу курса ↗