Что такое ИИ-агент: чем он отличается от чат-бота и от скрипта

Что это решает

Работа с языковой моделью чаще всего выглядит как ручной конвейер: человек копирует данные в чат, получает текст, переносит его в таблицу, письмо или тикет, идёт за следующим куском данных. Вопрос «что такое ИИ агент» встаёт ровно тогда, когда перекладывание отнимает больше времени, чем сама задача. Агент убирает человека из середины цепочки: сам достаёт данные, сам вызывает нужный инструмент, смотрит на результат и выбирает следующий шаг. Польза появляется на задачах в несколько ходов, где заранее неизвестно ни число шагов, ни то, что найдётся по дороге.

Как устроено

Агент собран из четырёх частей: модель, набор инструментов, петля выполнения, условие остановки. Всё остальное — обвязка вокруг них.

Системный промпт. Роль, границы, формат ответа, запреты, порядок действий в спорной ситуации. Отдельно прописывается поведение при нехватке данных: спросить, отказаться или пометить результат неполным. Без этого пункта модель заполняет пустоту догадкой.

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

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

Петля. Код без магии. Исполнитель отправляет контекст, получает ответ, и дальше две ветки: в ответе текст — цикл закончен; в ответе вызов инструмента — исполнитель выполняет вызов сам, дописывает результат в контекст и отправляет запрос заново.

Один шаг целиком

1. Исполнитель собирает контекст и отправляет запрос модели.
2. Модель возвращает либо финальный текст, либо имя инструмента с аргументами.
3. Исполнитель проверяет аргументы по схеме и по собственным правилам доступа.
4. Исполнитель выполняет вызов и получает результат — строку, JSON, ошибку.
5. Результат дописывается в контекст, шаг повторяется.

Модель ничего не выполняет сама. Она называет инструмент и аргументы, выполняет код исполнителя. Отсюда растут и безопасность, и права: агент умеет ровно то, что ему выдали функциями, и ни шага больше.

Чем отличается от чат-бота

Чат-бот отвечает. Агент действует, а текст остаётся побочным продуктом действия.

Чем отличается от скрипта

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

Плата за гибкость — недетерминированность. Один и тот же вход даёт разные трассы выполнения. Скрипт на одном входе всегда даёт один и тот же выход.

Правило: порядок шагов известен заранее и не зависит от данных — пишется скрипт, а не агент.

Уровни автономии

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

Переход идёт снизу вверх и по одной задаче, а не сразу для всего агента.

Как подключить

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

Шаг 1. Задача с проверяемым результатом. Годится всё, где ответ сверяется механически: «сколько заказов без оплаты за прошлую неделю», «найди в переписке письмо с реквизитами». Не годится «сделай маркетинг лучше».

Шаг 2. Модель с поддержкой вызова инструментов. В API это отдельный параметр запроса со списком функций (tools, functions — имя зависит от поставщика). Ответ модели приходит структурой с вызовом, а не свободным текстом.

Шаг 3. Два-три инструмента. Для первой сборки хватит чтения (запрос к базе или файлу) и записи (отправка сообщения). Каждый — с честным описанием: что делает, когда вызывать, чего не умеет.

Шаг 4. Петля. Псевдокод целиком:

messages = [system_prompt, user_task]
for step in range(MAX_STEPS):
    reply = model.create(messages=messages, tools=TOOLS)
    if not reply.tool_calls:
        return reply.text
    for call in reply.tool_calls:
        check_allowed(call.name, call.arguments)   # свои правила доступа
        result = TOOLS[call.name](**call.arguments)
        messages.append(tool_result(call.id, result))
raise LimitReached

Шаг 5. Предохранители. Жёсткий лимит итераций, таймаут на инструмент, белый список таблиц и адресов, отдельная роль в базе с правом только на чтение. Ошибку инструмента возвращать модели текстом, а не ронять процесс: агент часто исправляется сам, когда видит причину.

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

Шаг 7. Прогон на подготовленных примерах. Десяток задач с известными ответами, каждая — по несколько раз подряд.

Полезные сценарии

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

Ограничения

Стоимость растёт быстрее числа шагов. Каждая итерация отправляет весь накопленный контекст заново. Десять шагов — это десять запросов с растущим хвостом, а не десять коротких вопросов.

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

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

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

Без API инструмент не подключить. Там, где у поставщика нет интерфейса, остаётся хрупкая автоматизация через браузер: чужой редизайн ломает её без предупреждения.

Ответственность не делегируется. Юридически значимое решение, медицинская или кадровая оценка, разговор с клиентом на грани конфликта — за человеком.

Как проверить результат

Набор повторяемых задач. Собрать около десятка задач с заранее известными ответами и добавить три-четыре заведомо неразрешимых: данных нет, доступ закрыт, вопрос вне компетенции. Правильное поведение на них — явный отказ, а не правдоподобный текст.

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

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

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

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