В автоматизации есть соблазн называть агентом всё подряд. Скрипт сходил в API, обработал таблицу, отправил сообщение в Telegram — уже «ИИ-агент». На практике такая подмена быстро мешает: простые задачи начинают проектировать слишком сложно, а сложные, наоборот, пытаются закрыть одним cron-скриптом и удивляются, почему оно ломается на первом нестандартном случае.
Я для себя разделяю эти инструменты жёстко. Обычный скрипт — это предсказуемый исполнитель понятного алгоритма. ИИ-агент — это система, которая работает с контекстом, принимает ограниченные решения, использует инструменты и оставляет после себя проверяемые артефакты. Это не вопрос моды. Это вопрос цены ошибки, изменчивости входных данных и того, сколько самостоятельности вы готовы отдать автоматизации.
В этой статье разберу, как я выбираю между скриптом, workflow и агентом, где проходит граница и почему «сначала агент» почти всегда хуже, чем «сначала понятный процесс».
Сначала не инструмент, а форма задачи
Любую автоматизацию я начинаю не с выбора модели, фреймворка или сервиса. Сначала смотрю на форму задачи.
Есть задачи линейные: взять файл, привести поля к нужному виду, загрузить результат, записать лог. Есть задачи ветвящиеся: если источник недоступен, попробовать второй; если данных не хватает, поставить статус «на проверку»; если результат подозрительный, остановить публикацию. Есть задачи с неопределённостью: прочитать обращение клиента, понять намерение, выбрать следующий шаг, сформировать ответ, но не сделать лишнего.
Для первого типа обычно нужен скрипт. Для второго — скрипт плюс нормальная архитектура: состояния, ретраи, идемпотентность, понятные ошибки, мониторинг. Для третьего уже можно думать про агента.
Ошибка начинается там, где неопределённость притаскивают искусственно. Если задача звучит как «каждый день в 03:00 скачать XML, проверить новые позиции и обновить Markdown», ИИ-агент не делает её лучше. Он только добавляет стоимость, задержку и ещё один слой, который может ошибиться.
Но если задача звучит как «каждый день понять, есть ли среди новых источников тема, достойная статьи, сравнить её с редакционной политикой, собрать контекст, написать черновик и не публиковать сомнительный материал», это уже другая зона. Тут важно не только выполнить шаги, но и принять несколько решений по смыслу.
Что я называю обычным скриптом
Обычный скрипт — это код, у которого есть понятный вход, понятная последовательность действий и понятный выход. Он может быть маленьким bash-файлом, Python-утилитой, npm-командой, обработчиком webhook или cron-задачей. Размер не так важен. Важна детерминированность.
Скрипт хорош, когда:
- правила можно описать без «подумай»;
- входные данные структурированы;
- исключения известны заранее;
- результат легко проверить программно;
- ошибка должна приводить к остановке, а не к творческой импровизации;
- один и тот же вход должен давать один и тот же результат.
Например, генерация sitemap, проверка битых ссылок, конвертация изображений, выгрузка отчёта из API, пересборка статического сайта, чистка кэша, обновление статусов по таблице — всё это естественная территория скриптов.
Скрипт не обязан быть примитивным. Хороший скрипт может иметь конфиг, dry-run, защиту от повторного запуска, логи, алерты, тесты и аккуратную обработку ошибок. Иногда именно такой «скучный» скрипт надёжнее агента, потому что не пытается угадывать.
Главный плюс скрипта — контроль. Я заранее знаю, что он сделает. Главный минус — он не понимает смысл. Если в данных появляется ситуация, которую автор не предусмотрел, скрипт либо падает, либо молча делает не то.
Что я называю ИИ-агентом
ИИ-агент для меня — это не просто «модель с инструкцией». В локальной архитектуре я разделяю два уровня: технический агент и системный агент.
Технический агент — это движок: модель, инструменты, подключение к API, выполнение команд, доступ к файлам или сервисам. Он умеет делать действия, но сам по себе ещё не является полноценным цифровым работником.
Системный агент шире. У него есть роль, сессия, контекст, артефакты, границы доступа и рабочие правила. В моей терминологии это ближе к цифровому сотруднику: он не просто отвечает на один запрос, а живёт внутри процесса.
Практически это означает, что агент может:
- прочитать несколько источников и выбрать релевантные;
- сопоставить новую задачу с уже принятыми правилами;
- создать промежуточный артефакт: план, отчёт, черновик, список рисков;
- использовать инструменты: поиск, файловую систему, CRM, CMS, базу знаний;
- остановиться, если действие небезопасно;
- передать результат человеку или другому процессу с понятным объяснением.
Именно поэтому агент дороже скрипта не только по API-запросам. Он дороже архитектурно. Ему нужны инструкции, память, права, наблюдаемость, режимы автономности, проверка качества и понятный откат.
Где скрипт лучше агента
Если процесс можно выразить как набор правил, я почти всегда начинаю со скрипта. Это дешевле, быстрее, прозрачнее и проще поддерживать.
Повторяемые операции
Скрипт лучше, когда задача повторяется одинаково. Например: «пройти по папке, найти изображения больше заданного размера, конвертировать в WebP и сохранить рядом». Агент здесь не нужен. Он не добавляет понимания, потому что понимать нечего.
Жёсткие бизнес-правила
Если правило звучит как «при статусе paid отправить чек, при статусе canceled ничего не делать», агент тоже лишний. В таких местах важна не гибкость, а предсказуемость. Чем меньше интерпретации, тем лучше.
Высокая цена самодеятельности
Есть процессы, где автоматизация не должна «догадаться». Платёж, удаление данных, массовая рассылка, изменение прав доступа, публикация на продакшне — всё это требует строгих ограничений. Агент может подготовить предложение, но финальное действие лучше оставить скрипту с проверками или человеку.
Простая проверка результата
Если результат можно проверить тестом, схемой, статус-кодом или контрольной суммой, скрипт обычно выигрывает. В таких задачах не нужно привлекать языковую модель как судью. Достаточно написать валидатор.
Где агент действительно нужен
Агент становится оправданным там, где задача не сводится к стабильному алгоритму.
Неструктурированный вход
Письма клиентов, голосовые расшифровки, сообщения в мессенджерах, свободные комментарии, длинные документы, набор ссылок без единого формата — всё это плохо ложится на обычные условия if/else. Тут нужна смысловая классификация.
Например, если клиент пишет «у нас что-то странное с заявками, вчера ещё приходили», скрипт не поймёт, что это может быть проблема формы, CRM, почты, рекламы или аналитики. Агент может собрать симптомы, проверить несколько направлений и оформить гипотезы.
Контекст важнее одного действия
Если решение зависит от прошлых договорённостей, истории проекта, редакционной политики, состояния задач и ограничений доступа, скрипту приходится тащить всё это через конфиги и таблицы. В какой-то момент конфиг превращается в хрупкую имитацию памяти.
В агентной архитектуре для этого есть артефакты. Артефакт — это не магия, а сохранённый результат работы: план, отчёт, профиль клиента, список правил, выводы из источника. Агент может использовать его в следующем запуске.
Нужно выбирать маршрут
Агент полезен, когда процесс не один, а несколько возможных путей. Например:
- если данных достаточно — готовим черновик;
- если источник слабый — откладываем;
- если факт сомнительный — проверяем по первичному источнику;
- если есть риск навредить — ставим на ручное подтверждение;
- если задача типовая — передаём её простому скрипту.
Такой агент не должен делать всё сам. Хорошая схема наоборот часто выглядит так: агент принимает решение, а конкретные операции выполняют обычные скрипты.
Требуется человеческий формат результата
Сводка для владельца бизнеса, объяснение причины отказа, редакторский комментарий, план внедрения, чек-лист для команды — это не просто данные. Тут важны смысл, тон, приоритеты и понятная структура. Скрипт может собрать сырьё, но финальную формулировку часто лучше отдавать агенту.
Промежуточная зона: workflow без агента
Между «скрипт» и «ИИ-агент» есть важная прослойка — workflow. Это когда процесс уже состоит из нескольких шагов, но смысловых решений ещё мало.
Например:
- Получить новые заявки из формы.
- Проверить обязательные поля.
- Обогатить данные из CRM.
- Отправить уведомление менеджеру.
- Записать событие в журнал.
Такой процесс можно собрать в n8n, Make, собственном orchestrator или обычном коде. Если на каждом шаге правила понятны, агент не нужен. Если же появляется этап «понять, что хотел клиент, и выбрать сценарий ответа», можно добавить ИИ ровно туда, а не переписывать весь workflow в агентный режим.
Это важный принцип: ИИ не обязан быть центральным мозгом всей автоматизации. Иногда он всего лишь один шаг в обычной цепочке.
Типовые ошибки при выборе инструмента
Ошибка 1. Делать агента вместо нормального скрипта
Так появляется дорогая и медленная автоматизация там, где достаточно 100 строк кода. Признак ошибки: агент каждый раз «рассуждает» над задачей, которая уже давно имеет однозначное правило.
Правильный вопрос: «Что здесь должен понять ИИ?» Если ответа нет, нужен не агент.
Ошибка 2. Делать скрипт там, где нужен смысл
Обратная крайность — пытаться регулярками, флагами и бесконечными исключениями описать живой человеческий вход. Сначала это выглядит экономно, потом превращается в набор хрупких костылей.
Если каждую неделю приходится добавлять новое условие «а если клиент написал вот так», пора признать, что задача стала смысловой.
Ошибка 3. Путать автономность и отсутствие контроля
Агент не обязан иметь право делать всё. Наоборот, хорошая агентная система начинается с ограничений. Он может читать, анализировать, предлагать и готовить черновики. Публикация, платёж, удаление, массовая отправка и изменение прав могут оставаться за человеком или за отдельным безопасным механизмом.
Ошибка 4. Не оставлять следов работы
Если агент что-то решил, но не оставил артефакт, потом невозможно понять, почему он так поступил. Для меня это один из главных признаков сырой автоматизации. У каждого нетривиального решения должен быть след: источник, вывод, статус, причина отказа или ссылка на проверку.
Ошибка 5. Считать модель архитектурой
Выбор модели важен, но он не заменяет процесс. Можно взять сильную модель и получить ненадёжную систему, если нет контекста, прав, тестов, логов и fallback. И можно получить хороший результат на простой модели, если задача правильно разложена. В контекст-инжиниринге действует тот же принцип: качество часто определяется не названием модели, а тем, что именно попадает в контекст и как проверяется результат.
Моя практическая рамка выбора
Я использую простую развилку.
Выбираю скрипт, если
- вход структурирован;
- правила можно описать заранее;
- результат должен быть одинаковым при одинаковом входе;
- проверка результата программная;
- нет необходимости объяснять решение человеческим языком;
- ошибка должна останавливать процесс, а не запускать рассуждение.
В этом случае я лучше потрачу время на нормальный лог, dry-run, конфиг, тесты и понятный rollback. Это скучнее, зато живёт дольше.
Выбираю workflow, если
- шагов несколько;
- есть интеграции с разными сервисами;
- нужны ретраи, очереди, статусы;
- часть операций можно выполнять независимо;
- правила ветвления понятны;
- нужен мониторинг процесса целиком.
Workflow — хороший формат для большинства бизнес-автоматизаций. Он дисциплинирует: видно, где вход, где выход, где ошибка, кто владелец процесса и что делать при сбое.
Выбираю агента, если
- вход неструктурированный;
- нужно понимать смысл текста, документа или диалога;
- решение зависит от накопленного контекста;
- есть несколько допустимых маршрутов;
- важно сформулировать вывод для человека;
- система должна создавать артефакты и использовать их дальше;
- есть понятные границы автономности.
Агент без границ — риск. Агент в правильно спроектированном процессе — полезный цифровой работник.
Как это выглядит в реальной автоматизации
Допустим, нужно автоматизировать подготовку экспертных статей для сайта.
Плохой вариант: «агент, каждый день напиши и опубликуй статью». Звучит красиво, но внутри спрятано слишком много решений: какую тему брать, какие источники считать надёжными, что делать с устаревшими фактами, как проверять внутренние ссылки, когда не публиковать, как не потерять черновик при сбое.
Более рабочий вариант:
- Скрипт собирает список доступных тем и проверяет, что slug ещё не занят.
- Скрипт достаёт локальные источники и существующие страницы для внутренних ссылок.
- Агент выбирает ракурс, пишет черновик и явно отделяет факты от выводов.
- Скрипт проверяет frontmatter, ссылки, сборку сайта и отсутствие технических маркеров.
- При ошибке процесс останавливается, а не публикует «почти готово».
- Человек или отдельный безопасный этап принимает решение о публикации.
В такой схеме агент делает то, что у него получается лучше: работает со смыслом, структурой и редакционным качеством. Скрипты делают то, что у них получается лучше: проверяют, собирают, валидируют и не импровизируют.
Такой подход особенно важен в AI First трансформации: не превращать каждый шаг в разговор с моделью, а распределять роли между обычным кодом, инструментами, агентами и человеком.
Чек-лист перед внедрением
Перед тем как выбирать инструмент, я прохожу по короткому списку вопросов.
1. Что является входом?
Если вход — таблица, JSON, XML, событие webhook или понятный файл, сначала думаю про скрипт. Если вход — письмо, диалог, запись разговора, свободный текст или набор источников, появляется повод для агента.
2. Можно ли заранее описать правила?
Если правила помещаются в документацию и не требуют постоянных исключений, ИИ не нужен. Если правила зависят от смысла, контекста и приоритетов, агент может быть оправдан.
3. Кто отвечает за ошибку?
Если ошибка приводит к деньгам, юридическим последствиям, удалению данных или публичной публикации, автономность должна быть ограничена. Агент может готовить решение, но не обязан нажимать финальную кнопку.
4. Как проверяется результат?
Хорошая автоматизация имеет проверку. Для скрипта это тест, схема, статус-код, контрольная сумма, сборка. Для агента — ещё и верификатор: проверка источников, полноты, тона, ссылок, соответствия правилам.
5. Что останется после работы?
Если процесс важный, после него должен остаться артефакт: лог, отчёт, черновик, карточка решения, причина отказа. Без этого автоматизация становится непрозрачной.
6. Что произойдёт при сбое?
Недоступен источник, закончился лимит API, сломалась сборка, сервис вернул пустой ответ, модель не справилась. Для каждого такого сценария нужен ответ: повторить, пропустить с пометкой, остановиться, позвать человека или откатить состояние.
Практический сценарий выбора
Если коротко, я бы выбирал так.
Для регулярной технической операции — скрипт. Для процесса из нескольких технических операций — workflow. Для смыслового решения внутри процесса — агент. Для критичного действия наружу — человек или строго ограниченный механизм подтверждения.
Когда бизнес говорит «нам нужен ИИ-агент», я обычно переформулирую задачу: «вам нужен результат процесса». Иногда этот результат лучше даст агент. Иногда — обычный скрипт за меньшие деньги и с большей надёжностью. А чаще всего нужна связка: скрипты держат каркас, workflow управляет состояниями, агент разбирается с неоднозначностью.
Именно такую связку я считаю взрослой автоматизацией. Не «везде ИИ», а «каждому типу работы — свой инструмент». Если нужен отдельный агент под продажи, поддержку, аналитику или внутренние процессы, это уже задача из зоны ИИ-агентов для бизнеса. Но начинать всё равно стоит не с агента, а с карты процесса: где правила, где смысл, где риск и где человеку нужно оставить право последнего решения.