ИИ-агенты: полезный коллега или модное слово?

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

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

Из чего состоит агент

У рабочей агентной системы обычно есть пять частей:

1. Цель. Что должно быть достигнуто и как выглядит готовый результат.
2. Модель. Интерпретирует состояние, планирует и выбирает действие.
3. Инструменты. Поиск, база данных, почта, браузер, терминал или внутренний API.
4. Состояние. Что уже сделано, какие данные получены и какие ограничения действуют.
5. Цикл управления. Выполнить действие, прочитать результат, проверить прогресс и решить, что делать дальше.

Модель сама по себе не отправляет письмо и не меняет запись в CRM. Она формирует структурированный вызов инструмента; затем программа или сервис исполняет его и возвращает результат. Это важная деталь: безопасность агента зависит не только от модели, но и от того, какие действия разрешила окружающая система.

Чат, workflow или агент

Подход	Кто выбирает шаги	Когда подходит
Чат	Пользователь	Разовые вопросы, тексты, анализ
Workflow	Заранее написанная схема	Стабильный повторяемый процесс
Агент	Модель в заданных границах	Вариативная задача, где путь заранее неизвестен

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

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

Где агенты уже полезны

Исследование с понятным результатом

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

Запрос «исследуй рынок» почти гарантированно породит много текста. Запрос «сравни пять поставщиков по этим шести критериям, используй первичные источники не старше года и пометь отсутствующие данные» даёт агенту проверяемую работу.

Работа с кодом

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

Однако зелёные тесты ещё не доказывают правильность продукта. Нужны ограниченная область изменений, просмотр diff и подтверждение человека перед объединением или развёртыванием.

Внутренние операции

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

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

Где агент только мешает

Агентность добавляет задержку, стоимость и новые способы отказа. Она не нужна, если:

• результат получается одним запросом к модели;
• шаги известны заранее и легко кодируются;
• нет объективного способа проверить промежуточный результат;
• ошибка необратима или затрагивает деньги, права доступа и людей;
• задача возникает слишком редко, чтобы окупить поддержку системы;
• данные и инструменты ещё не приведены в порядок.

Главные риски

Неверный план

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

Ошибка инструмента

API может вернуть неполные данные, страница — измениться, команда — завершиться частично. Агент должен различать «действие выполнено» и «цель достигнута», уметь читать ошибки и не бесконечно повторять один вызов.

Избыточные полномочия

Инструмент «управление пользователями» опаснее инструмента «найти справочную статью». Выдавайте минимальные разрешения, разделяйте чтение и запись, используйте тестовую среду и одноразовые подтверждения для важных действий.

Потеря контекста

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

Непонятная ответственность

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

Лестница безопасного внедрения

Не переходите от ручной работы сразу к автономному исполнению.

1. Советник. Модель предлагает действие, человек выполняет его сам.
2. Черновик. Система готовит письмо, изменение или заявку, человек подтверждает.
3. Ограниченное выполнение. Агент делает обратимые действия в узком контуре.
4. Автоматическое выполнение. Только для наблюдаемых, хорошо протестированных и низкорисковых случаев.

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

Как поставить задачу агенту

Цель: [проверяемый результат]

Разрешённые источники и инструменты:
[список]

Запрещено:
[действия и данные]

Перед началом:
составь короткий план и назови допущения.

После каждого важного шага:
проверь результат, прежде чем продолжать.

Остановись и запроси подтверждение, если:
- нужно отправить сообщение;
- требуется изменить или удалить данные;
- действие связано с оплатой или правами доступа;
- информации недостаточно;
- выполнено больше [число] шагов.

Финальный отчёт:
что сделано, какие источники использованы,
что изменено и что должен проверить человек.

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

Главное

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

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