Собрали ИИ-агента в n8n за вечер, через месяц переписали ядро на Python: где мы провели границу

Есть категория задач, которые приходят от клиента примерно так: «нам бы через две недели показать, что оно работает, дальше решим». В прошлом квартале нам прилетел ровно такой запрос — обработка входящих заявок из почты и формы на сайте, с классификацией, черновиком ответа и постановкой в CRM. Знакомая история. Мы открыли n8n, подтянули AI Agent Node, воткнули GigaChat Pro в качестве модели, и через вечер у клиента был живой ИИ-агент, читающий письма.

А через месяц мы этого агента переписывали. Не потому что n8n плохой — потому что мы неправильно провели границу.

Ниже — как мы её теперь проводим, что оставляем в n8n, что уносим в Python, и чему в связи с этим пришлось доучить команду.

n8n и ИИ-агенты: где начинается кайф и где он заканчивается

n8n хорош ровно в том, для чего он придуман: склеивать разнородные системы. Триггер на новое письмо, парсинг, отправка в 1С, ответ в CRM, уведомление в Telegram — это всё собирается визуально, и любой человек с техническим складом ума за пару часов разбирается, как использовать ИИ-агента внутри такого сценария.

В свежем релизе 2.35.0, который вышел 11 августа, добавили Agent Builder с тестовыми запусками, human-in-the-loop и локальный подсчёт токенов. Стало ощутимо приятнее: раньше отладка агентской ноды напоминала гадание, теперь видно, что модель получила на вход и что вернула. Заодно почистили утечку текста pre-tool-call — мелочь, а раньше это ловили руками.

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

Первое, обо что мы споткнулись, — сложная логика инструментов. Агенту нужно не просто вызвать поиск в 1С, а сначала проверить, есть ли клиент в чёрном списке, потом уточнить у второго ИИ-агента-судьи, не является ли запрос попыткой prompt injection, потом сходить в pgvector за похожими прошлыми ответами, склеить контекст с учётом лимита токенов и только тогда дёрнуть основной инструмент. В n8n это делается через россыпь Function-нод с JavaScript внутри. Работает. Ревьюить это в git — боль.

Второе — версионирование. Workflow n8n живёт в JSON, и когда четыре человека одновременно правят ноды, merge выглядит как последствия торнадо. Мы честно попробовали организовать процесс через экспорт-импорт и pull request на JSON — сдались.

Третье — свои штуки поверх LLM. Circuit breaker, когда модель начинает отвечать через раз. Дедупликация одинаковых задач через pg_try_advisory_xact_lock. Компактификация контекста в диалоговых агентах. Трейсинг с проброшенным traceparent от фронта до модели. Всё это делается на n8n через кастомные ноды или внешние сервисы — и в какой-то момент становится понятно, что внешних сервисов уже больше, чем самого n8n.

Почему первый подход провалился, а второй — нет

Первый подход был «сделаем всё в n8n, а если чего-то не хватит, дожмём». Не сработало. Мы получили workflow, в который страшно было заходить: тридцать нод, семь Function-блоков с бизнес-логикой внутри, и никто, кроме автора, не помнил, зачем нужен вот этот IF.

Второй подход был «разделим». И вот его короткое описание.

n8n оставили как оркестратор и клей. Триггеры (почта, вебхуки, крон), готовые интеграции (Bitrix24, 1С через MCP-сервер, Telegram, Google Sheets), передача файлов и биндов — это его сильная сторона, тут он побеждает любой самописный код за счёт скорости сборки.

Ядро ИИ-агента на Python переехало в отдельный FastAPI-сервис. Планирование шагов, выбор инструментов, RAG поверх pgvector, guardrails, ретраи, circuit breaker, трейсинг, лимиты — всё там. n8n дёргает этот сервис как обычный HTTP-инструмент: отправил задачу, получил ответ или webhook о завершении.

Получилась двухслойная схема, где каждый слой делает то, что умеет.

Что теперь пишем на Python и почему

Ядро агентов мы пишем на Python не потому, что модно, а потому что стек LLM живёт именно там. Свежих релизов за последние недели столько, что перечислить сложно: LangGraph подъехал с node caching, deferred nodes и pre/post model hooks (это как раз про trimming контекста, guardrails, PII — те самые штуки, которые в n8n приходилось приколачивать сбоку). Pydantic AI выкатил очередной патч с новыми адаптерами моделей — типизированные агенты на Python стали удобнее, чем самописный вызов через requests. Microsoft показал Agent Framework с Agent Harness и Hosted Agents в превью.

Мы для себя выбрали связку FastAPI + LangGraph + pgvector + свой слой LLM-ops. Причины прозаичные:

• Python-код на ИИ-агента можно нормально ревьюить, тестировать и катить через привычный CI.
• Модель в коде меняется в одной строчке. Сегодня у клиента GigaChat Pro по требованиям 152-ФЗ, завтра тот же агент на стенде запускается на YandexGPT или локальной T-lite для сравнения. В n8n такой свап тоже возможен, но каждый раз это ручная работа с нодой.
• Свои примитивы (тот же advisory lock, партиционирование задач, дедлайны на весь запрос) пишутся так, как удобно нам, а не как позволяет визуальный редактор.

При этом мы не фанаты писать всё на голом asyncio. Фреймворк выбираем под задачу: где нужен граф с ветвлением и памятью — LangGraph, где важна строгая типизация и минимализм — Pydantic AI, где заказчик уже сидит в экосистеме Google и хочет Vertex AI — Google ADK. Слепой преданности одному инструменту у нас нет.

Где теперь проходит граница

Правило, которое мы сформулировали для себя после нескольких итераций, простое.

В n8n остаётся всё, что можно описать как «когда пришло X — сходи в Y — положи в Z». Триггеры, транспорт, простые преобразования, интеграции с системами, где уже есть готовые ноды. Плюс — HITL-шаги: остановились, дождались человека, поехали дальше. В новом Agent Builder это стало прямо удобно.

В Python уезжает всё, где есть слово «решить». Решить, какой инструмент вызвать. Решить, доверять ли ответу модели. Решить, что делать с ошибкой провайдера. Решить, как склеить контекст под лимит. Как только в ноде появляется больше одной ветки «если модель сказала А, то...», это сигнал вынести логику в питон-сервис.

Граница подвижная. Каждый релиз n8n её немного двигает — тот же Agent Builder уменьшает соблазн лезть в код ради простых агентских сценариев. Но фундаментальная асимметрия остаётся: визуальный редактор оптимизирован под скорость сборки, код — под управляемость на длинной дистанции.

Создание ИИ-агентов и обучение команды под новую схему

Разделение слоёв поменяло и то, как мы учим людей — и своих, и на стороне заказчика. Раньше «создание ИИ-агентов» и обучение под него означало «покажи, где кликать в n8n». Теперь картина сложнее.

Проектные менеджеры и продуктовые аналитики учатся собирать flow в n8n сами. Триггер, интеграция, вызов нашего питон-сервиса, ветвление по ответу — этому реально научить за пару недель практики, и после этого мелкие изменения в сценарии не требуют разработчика. Мы это ценим: чем меньше правок проходит через нас на каждую мелочь, тем быстрее живёт продукт.

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

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

Что в итоге

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

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

Где эту границу проводите вы?

Похожие статьи

• Как мы делали презентацию про ИИ-агентов для VS Code без единого слайда — и совет директоров наконец сказал «да»
• Ломаем API собственного ИИ-агента: чему нас научил свежий разбор атак от Касперского
• Собственный ИИ-агент на сайт вместо чат-бота: как мы разбираем заявки B2B до того, как их увидит менеджер
• Личный ИИ-агент директора: как мы пишем инструкцию, а не очередной промпт