
Агент проиграл: agentic vs deterministic в n8n
Один и тот же workflow в n8n собрали дважды — через AI Agent и детерминированно. Агент проиграл. Разбираем почему и когда каждый подход побеждает.
Один workflow, два пути — и неожиданный победитель
В сообществе n8n недавно появился пост, который моментально собрал сотни реакций. Автор построил один и тот же автоматизированный процесс двумя способами: сначала в виде классического детерминированного workflow, затем — переписал его с нуля на базе AI Agent node. Задача была прикладной и вполне реальной: workflow классифицирует загружаемые инвойсы (PDF, PNG, JPG), направляет их в нужную папку Google Drive и отправляет в Slack уведомление о документах с низкой уверенностью классификации.
Многие в комментариях задавали один и тот же вопрос: почему бы не сделать это агентно? Автор ответил делом — пересобрал тот же workflow с AI Agent node, Gemini в качестве chat-модели и семью инструментами (шесть «переместить в папку» и одним Slack-уведомлением). Результат оказался неожиданным: агент проиграл.
Этот кейс — не просто забавная история из форума. Это практическая иллюстрация одного из самых важных архитектурных решений в современной автоматизации. Разберём, что произошло и почему это важно для каждого, кто строит production-системы.
Что такое детерминированный workflow и агентный подход
Прежде чем разбирать результаты эксперимента, нужно чётко понять разницу между двумя парадигмами.
Детерминированные workflow (n8n, Zapier, Make) выполняют заранее определённые шаги в предсказуемом порядке: данные поступают, проходят через узел A, затем B, затем C. Каждое выполнение идёт по одному и тому же пути и производит одинаковые результаты при одинаковых входных данных.
Агентный подход начинается с цели и динамически определяет шаги. Вы описываете желаемое («изучи эту тему и подведи итог»), а агент сам определяет путь выполнения в реальном времени. Это невероятно мощно для исследования, но путь выполнения непрозрачен — когда что-то идёт не так, сложно воспроизвести и отладить шаги.
Можно описать это образно: workflow — это «провода и переключатели», а агент — «электрик», который решает, какой переключатель включить следующим.
Детерминированный workflow — вы рисуете каждый шаг, каждую ветку, каждое решение. LLM обрабатывает контент в конкретных узлах, но управление потоком — за вами.
Агентный workflow — вы описываете цель. AI сам решает, какие шаги предпринять.
Почему агент проиграл: разбор по критериям
Задача с инвойсами — классический пример задачи с заранее известными входами и фиксированным набором выходов. Документ либо попадает в одну из папок, либо уходит в Slack для ручной проверки. Никаких сюрпризов, никакой «рассуждательной» неопределённости.
Посмотрим, как проявили себя оба подхода по ключевым параметрам:
| Параметр | Детерминированный workflow | AI Agent (Gemini + 7 tools) |
|---|---|---|
| Надёжность | Высокая, одинаковый результат каждый раз | Варьируется от запуска к запуску |
| Отладка | Видно каждый шаг и его результат | Путь рассуждений непрозрачен |
| Стоимость | Предсказуемая, per-execution | Зависит от токенов, растёт с каждым вызовом |
| Скорость | Быстро, нет LLM-латентности на маршрутизации | Медленнее из-за inference на каждом шаге |
| Контроль | Полный, все ветки заданы явно | Частичный, агент может «решить» иначе |
| Сложность поддержки | Низкая | Высокая (prompt-инжиниринг, версионирование) |
Детерминированные workflow в n8n гарантируют пути выполнения. Если у вас есть условная ветка (например, «если сумма инвойса > $1000, запросить одобрение»), эта логика явно прописана и можно проследить каждый сценарий до деплоя.
Агент же, как показал эксперимент, вносит лишнюю переменность туда, где она не нужна. Агентные платформы могут «галлюцинировать» пути выполнения или зависать в петлях. Один из участников Reddit-обсуждения прямо написал: агентные платформы хороши — до тех пор, пока нет сбоев, а отладка недетерминированных ошибок мучительна.
Где агент всё же побеждает
Выигрыш детерминированного подхода в данном кейсе — не приговор агентам в целом. Это сигнал о том, что у каждого инструмента есть своя зона применения.
Рассмотрим задачу: «Просмотри 30 тикетов поддержки, пришедших сегодня. Для тех, что можно решить стандартной политикой возврата, составь ответы. Остальные отметь для ручной проверки.» Это уже не детерминированный процесс. Подходит ли тикет для стандартного ответа — зависит от его содержания. Правильный ответ зависит от контекста. Этот workflow нельзя нарисовать в редакторе узлов, не зная входных данных заранее.
Вот где агент оправдывает свою стоимость:
graph TD
A[Задача автоматизации] --> B{Входные данные
предсказуемы?}
B -->|Да| C[Детерминированный
workflow]
B -->|Нет| D{Требуется
рассуждение?}
D -->|Нет| C
D -->|Да| E[AI Agent]
C --> F[✅ Надёжность
💰 Низкая стоимость
🔍 Простая отладка]
E --> G[🧠 Гибкость
📋 Многошаговое рассуждение
⚠️ Выше стоимость и риск]
Агенты не заменяют детерминированные workflow — множество процессов должны выполняться одинаково каждый раз. Но для задач, требующих оценочных суждений, контекста из нескольких систем или ситуаций, не укладывающихся в чёткие ветки, агентный подход подходит лучше.
Практическое правило, которое сформулировали практики: речь идёт не о выборе одного из подходов. Нужно использовать детерминированные workflow для 80% автоматизации (пайплайны данных, интеграции, бизнес-процессы) и AI-агенты для оставшихся 20% (исследование, создание контента, сложное принятие решений).
Стоимость и наблюдаемость: реальные цифры
Один из аргументов в пользу детерминированного подхода, который часто недооценивают — экономика.
Затраты n8n предсказуемы — вы платите за выполнение или за запуск workflow, а self-hosted инстансы снижают инфраструктурные расходы. Агентные workflow тарифицируются по токенам, и сложные многошаговые агенты могут потреблять значительное количество токенов за один запуск. Для высокообъёмных повторяющихся задач n8n почти всегда дешевле. Более высокая стоимость агентов оправдана, когда задача действительно требует рассуждений, с которыми фиксированный workflow не справится.
Ещё один критически важный фактор — наблюдаемость. В детерминированном workflow каждый шаг логируется:
{
"executionId": "abc-123",
"node": "Classify Invoice",
"status": "success",
"input": { "file": "invoice_2026_04.pdf" },
"output": { "category": "utilities", "confidence": 0.94 },
"duration": 312
}
При сбое агента вы видите только: «агент не смог выполнить задачу». Почему? Какой именно шаг рассуждения дал сбой? Когда агент принимает неверное решение, отследить причину сложнее, чем изучить узел в n8n. Путь рассуждений менее прозрачен.
Production-grade надёжность — это не опция. n8n предоставляет нативную обработку ошибок, структурированное логирование и мониторинг выполнений из коробки. Когда workflow падает, вы получаете ровно ту информацию, которая нужна для отладки — какой узел упал, какие данные получил и почему произошла ошибка.
Гибридный подход: лучшее из двух миров
Опытные инженеры по автоматизации давно пришли к выводу, что противопоставление «агент vs. workflow» — ложная дилемма. Правильный вопрос: «Где в этом процессе нужна гибкость рассуждений, а где — надёжность исполнения?»
Workflow обеспечивают надёжность, скорость и наблюдаемость. Агенты добавляют суждение, нечёткое сопоставление и многошаговое рассуждение. Гибрид означает, что LLM может «решать», а n8n безопасно выполняет это решение.
Практический алгоритм построения гибридной системы:
Конкретный пример гибридной архитектуры для обработки инвойсов:
sequenceDiagram
participant W as n8n Workflow
participant E as Extractor (API)
participant A as AI Agent (LLM)
participant G as Google Drive
participant S as Slack
W->>E: Отправить PDF/PNG/JPG
E-->>W: Категория + confidence score
W->>W: Проверить confidence >= 0.85?
alt Высокая уверенность
W->>G: Переместить в нужную папку
else Низкая уверенность
W->>A: Запросить вторичную классификацию
A-->>W: Уточнённая категория
W->>G: Переместить в папку
W->>S: Уведомить команду о ручной проверке
end
В этой архитектуре LLM задействован только там, где его рассуждения действительно нужны — при низкой уверенности экстрактора. Весь остальной процесс остаётся детерминированным, предсказуемым и дешёвым.
Лучшие production-системы часто используют оба подхода: n8n для надёжной оркестрации, агенты встроены там, где нужна оценка. По стоимости и наблюдаемости n8n выигрывает для повторяющейся работы; возможности агентов оправдывают их стоимость для сложных, контекстно-зависимых задач.
Три архетипа задач: как выбрать правильный подход
Исследователи в области AI-продуктов предлагают удобную классификацию всех задач автоматизации по трём категориям:
Категория 1: Детерминированная автоматизация. Вы определяете весь поток, AI обрабатывает контент на конкретных шагах. Думайте об этом как о workflow в n8n или Zapier с LLM-узлами. Сюда относится большинство агентных возможностей, и именно здесь большинству команд стоит начинать. Такие проекты быстрее всего запускаются и быстрее всего приносят измеримый ROI.
Категория 2: Агенты рассуждения и действия. AI решает, что делать дальше, используя доступные инструменты. Инструменты: Cursor, Lovable или агенты на LangGraph, CrewAI, Google ADK. Эти инициативы обычно следуют после Категории 1, когда более ценные задачи требуют гибкости и динамического принятия решений.
Категория 3: Сети мульти-агентов. Несколько специализированных агентов координируются между собой. Такие проекты, как правило, зарезервированы для поздних стадий и почти никогда не должны быть отправной точкой.
Организации часто пытаются решать задачи Категории 1 с помощью фреймворков Категории 2 — переусложняя решения и добавляя ненужные затраты. Реже, но с худшими последствиями — пытаются решить задачи Категории 2 инструментами Категории 1, и это ломается в продакшне.
Перед выбором архитектуры ответьте на три вопроса:
- Известны ли все возможные входные данные заранее? → Если да, детерминированный workflow.
- Требуется ли рассуждение о неструктурированном контенте? → Если да, рассмотрите агента на конкретном шаге.
- Важна ли аудируемость каждого действия? → Если да, детерминированный workflow или гибрид с жёсткими границами агента.
Выводы: агент проиграл не потому, что плох
Агент в кейсе с инвойсами проиграл не из-за слабости технологии. Он проиграл потому, что был применён к задаче, которая его возможностей не требует. Агент — избыточное решение для простых задач. Если ваш процесс — «форма → CRM-запись → уведомление в Slack», вам агент не нужен. AI-рассуждение добавляет задержку и стоимость без практической пользы для детерминированных, структурированных процессов.
n8n и чисто агентные AI-системы представляют две философии: структурированная автоматизация с AI внутри неё — против автономного AI со структурой, добавленной позже. Для бизнес-автоматизации первый подход побеждает по надёжности, аудируемости и поддерживаемости.
Главный урок этого эксперимента: настоящий вопрос не «что лучше», а «какую задачу я на самом деле решаю?»
Drag-and-drop автоматизация никуда не уходит — она становится надёжным фундаментом, поверх которого работают слои AI-агентов. Начинайте с детерминированного подхода. Добавляйте агентность точечно, только там, где она реально нужна. И всегда измеряйте результат.