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

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

Коротко: чат-бот отвечает на вопрос, агент выполняет задачу и меняет состояние системы.

Чат-бот получает сообщение и возвращает текст. На этом его работа заканчивается - что делать с ответом, решает человек. У агента устроено иначе: у него есть цель, набор инструментов для действия (файлы, база, внешний сервис, другой агент) и право довести задачу до результата без постоянного присмотра. Он не просто отвечает "вот как настроить рассылку" - он идёт и настраивает.

Разница ощущается сразу, как только агент начинает ошибаться. Чат-бот, который ошибся, - это неверная строка в переписке. Агент, который ошибся, - это изменённый файл, отправленное сообщение или потраченный бюджет. Поэтому к агенту предъявляются требования, которые к обычному диалоговому окну никто не предъявляет: границы полномочий, журнал действий и понятный момент, когда решение передаётся человеку.

Как я строю такие системы: живой пример

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

Я строил его поэтапно, а не одним запуском. Закрыты фазы 0-8 и ступень 9.1. Задачи ставятся текстом и голосом прямо из мессенджера. У агента есть память между сессиями - он не начинает каждый разговор с нуля. И есть гейты: точки, где действие требует моего подтверждения, а не происходит само.

Отдельно у меня работает ночной конвейер новостей. Он обходит источники, проверяет факты и выбирает тему дня. Затем готовит черновик поста. Утром я открываю панель, читаю черновик и прохожу проверку перед публикацией. Про то, как я довёл систему такого рода до рабочего состояния, я разбирал подробнее в статье Контент-завод на Claude: система, а не демо на 20 минут.

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

Как агент понимает, какую задачу решать сейчас

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

У меня это устроено через простую модель: тема переписки равна конкретному агенту-исполнителю. Есть и отдельный канал-штаб, куда идёт всё, у чего нет очевидного адресата. Штаб сам решает, кому передать задачу. Каждая задача движется по одной и той же цепочке статусов: принята в работу - готова к запуску - выполняется - на проверке - закрыта. Есть и аварийные ветки: "заблокирована" с указанием причины и того, кто может снять блокировку, и "ждёт подтверждения" - когда решение требует моей кнопки.

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

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

Почему за агентом должен стоять сторож

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

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

Молчание агента у меня - это сбой, а не нормальное состояние ожидания.

Что агенты делают вместе

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

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

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

Что агенту нельзя доверять напрямую

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

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

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

Как я проверяю, что агент действительно работает

Коротко: статус "запущено успешно" и "принесло результат" - это два разных факта, и путать их нельзя.

Живой пример у меня самого: контролирующий процесс может отчитаться, что задание выполнено, а на деле артефакт устарел или не появился вовсе. Поэтому проверка идёт по факту: открыл файл, увидел свежую дату, увидел свежий результат. Тот же принцип я применяю, когда проверяю обновления моделей перед тем, как встраивать их в проекты. Я не доверяю описанию, а прогоняю сам и смотрю на результат. Как именно я это делаю, я разбирал в статье ChatGPT Images 2.5: как я проверяю модель перед внедрением.

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

Где агент реально экономит время

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

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

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

Частые ошибки при внедрении агента

Коротко: большинство проблем с агентами - это дыры в процессе вокруг них, а не баги в коде.

Из того, что я закрывал у себя лично:

Каждая из этих ошибок один раз стоила мне лишнего круга проверки. После того как я формализовал правила выше, повторов не было.

Как понять, что вам нужен именно агент

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

Если процесс укладывается в "спросил - получил текст - использовал сам", хватит обычного чат-бота, и городить агентную архитектуру избыточно. Другое дело - процесс вида "собрать данные из нескольких мест, сопоставить их, подготовить черновик, дождаться моего решения, довести до результата". Тут уже нужна память между шагами, доступ к инструментам и понятная точка, где система останавливается и передаёт решение человеку.

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

С чего начинать сборку своего первого агента

Коротко: сначала пишется инструкция, потом система прогоняется руками несколько раз, и только затем ставится на автомат.

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

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

Итог

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

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