У меня 13 автоматизаций. Ни одна не использует LangGraph
В студии 13 автоматизаций. Они работают каждый день: собирают темы для блога, генерируют кандидатов, публикуют статьи, логируют, отправляют уведомления.
Все — через cron. Ни одна — агент.
Когда я рассказываю это людям, которые следят за темой, первый вопрос почти всегда один: «Почему не LangGraph?». Ответ скучный. LangGraph интересен. Cron надёжен. Для бизнес-процессов в продакшне я выбираю надёжный.
Что работает: коротко о 13 задачах
Я подробно разобрал эту систему в отдельной статье про автоматизацию студии. Здесь скажу главное: 13 задач покрывают контент-pipeline, мониторинг задач, публикацию, уведомления. Никаких оркестраторов, никакого multi-agent планирования. Каждая задача — это скрипт с ровно одной ответственностью, который Claude Code помог написать, но не он управляет его выполнением.
Система работает. Иногда задача падает — это видно в логах через 5 минут. Иногда Claude возвращает неожиданный вывод — скрипт парсит его детерминированно и либо обрабатывает, либо откладывает в очередь для ручной проверки. Без драмы.
Это и есть отправная точка для разговора про агентов.
Почему «агент» — архитектурное решение, а не замена cron
Когда люди говорят «используй AI-агент», они часто имеют в виду «используй фреймворк, где AI принимает решения о следующем шаге». Это не просто смена инструмента — это передача контроля над потоком выполнения от детерминированного кода к языковой модели.
Cron-задача: запуск → выполнение → результат. Поток полностью определён заранее.
AI-агент: запуск → модель решает, что делать дальше → модель снова решает → ... → результат. Поток управляется рассуждениями модели.
Для исследовательских задач, для сложных многошаговых сценариев с непредсказуемыми условиями — агент может быть правильным выбором. Для публикации поста по расписанию, для отправки уведомления, для парсинга лога — он добавляет недетерминированность туда, где она не нужна.
LangGraph — не плохой инструмент. Просто нужно понимать, что именно ты выбираешь, когда его берёшь.
Три вещи, которые ломаются у агентов в продакшне
Я не просто теоретизирую. Когда система автоматизации только создавалась, я всерьёз смотрел на агентские подходы. Вот три проблемы, которые заставили меня отказаться.
Первое — observability. У детерминированного скрипта есть понятный стектрейс, логи с конкретными значениями переменных, предсказуемые точки отказа. У агента — история «рассуждений» модели, которую сложно декодировать в постфактуме. Когда что-то пошло не так на шаге 4 из 7, мне нужно понять почему. Не читать transcript модели в надежде найти момент, где она «решила не так».
Второе — вариативность прогонов. Разные запуски одного агента с теми же входными данными могут дать разные результаты. Для генерации текста это нормально. Для публикации статьи на сайт — нет. Мне нужно, чтобы каждый прогон делал ровно то, что делал предыдущий.
Третье — debugging и retry. Когда cron-задача упала, я знаю, на каком шаге, с какой ошибкой, и могу запустить её повторно с теми же параметрами. У агента, который принял неправильное промежуточное решение на шаге 3, retry не гарантирует воспроизведение — он может выбрать другой путь. Отладка становится существенно сложнее.
Все три проблемы можно решить. Но их решение — это фактически построение детерминированного слоя поверх агентского. В какой-то момент начинаешь спрашивать: зачем агент, если я пишу детерминированный слой?
Мой паттерн: Claude API внутри cron-обёртки
На практике я использую гибрид: детерминированный cron-скрипт вызывает Claude API на конкретном шаге, где нужна языковая модель, получает ответ, и дальше детерминированно его обрабатывает.
Схема такая: cron запускает скрипт → скрипт собирает контекст → отправляет запрос к Claude API с жёстким системным промптом → парсит ответ по известной схеме → если парсинг успешен — продолжает, если нет — падает с понятной ошибкой.
Это не агент. Это скрипт, который использует LLM как функцию. Управление потоком — в руках кода, а не модели. Claude здесь — мощный text-трансформер, не архитектор логики.
Для 90% задач автоматизации студии этого достаточно. Модель генерирует контент, анализирует данные, форматирует вывод. Код решает, что делать с результатом.
Когда агент оправдан: мои критерии
Я не против агентов. Я против их применения там, где они создают проблемы без соответствующего прироста пользы.
Агент оправдан, когда:
- задача требует реального многошагового планирования с непредсказуемыми условиями;
- стоимость ошибки невысока и задача толерантна к вариативности результата;
- есть time-budget на построение observability-слоя;
- альтернатива — написание огромного детерминированного decision-tree, который уже не читается.
В студии под эти критерии сейчас попадает одна задача: исследование темы перед написанием статьи. Там действительно нужно несколько итераций поиска с промежуточными решениями. Там допустима вариативность. Там я готов потратить время на наблюдаемость.
Всё остальное — cron.
Скучное надёжно
Когда в 2024 году вся лента пестрит заголовками про AI-агентов, «автономные системы» и «оркестровку воркфлоу», выбор cron звучит как признание в отсталости.
Я думаю иначе. Надёжность в продакшне — это не компромисс. Это требование. 13 задач работают каждый день без моего участия именно потому, что каждая из них делает ровно одно, падает предсказуемо и восстанавливается без магии.
LangGraph вернётся в мой стек, когда задача потребует его возможностей. Пока — cron справляется. И это не недостаток архитектуры. Это её суть.
*Смотри также: Как я доверяю AI-агенту в продакшне: 3 паттерна из 13 cron-задач — про паттерны доверия внутри конкретных задач. Мониторинг 13 автономных агентов — что логировать, что алертить. Спецификация до кода — почему дисциплина важнее инструмента.*