ИИ-агенты в n8n: промт, сборка агента и грабли запуска

ИИ-агент в n8n — это нода AI Agent, к которой снизу подключены модель (Chat Model), необязательная память и инструменты, а ваш промт лежит в её поле System Message: оно спрятано в разделе Options, а не в основных параметрах. Сверху агенту нужен триггер — чат, вебхук или расписание. Дальше начинается то, о чём документация сообщает вскользь: Max Iterations по умолчанию равен десяти, память между сессиями не сохраняется, а в режиме очереди нода Simple Memory в активном рабочем воркфлоу не работает вовсе. Отдельная полоса препятствий — сеть: связку с локальной моделью чаще ломает докер, а не модель, и на Linux имени host.docker.internal внутри контейнера не существует, пока его не поднимут со специальным флагом. Ниже — восемь мест, где схема ломается чаще всего: каркас агента, лимит прогонов, память, MCP, Ollama, база знаний, обмен с 1С и железо под всё это. Тексты самих промптов для агентов разбирает соседняя статья, здесь — инструмент и грабли.

Каркас агента: где лежит промт и что проверить до запуска

Человек открывает ноду AI Agent, ищет поле для инструкции среди основных параметров и не находит. System Message живёт в разделе Options — на этом спотыкается примерно каждый, кто собирает первого агента.

Что ещё стоит открыть в этой ноде, пока не нажали «выполнить»:

• Prompt — два режима. «Take from previous node automatically» ждёт на входе поле chatInput. «Define below» принимает статический текст или выражение. Если триггер chatInput не кладёт, первый режим получит пустоту.
• Enable Streaming включён по умолчанию. Он требует триггера с поддержкой стриминга: Chat Trigger или Webhook с Response Mode = streaming. Запускаете агента чем-то другим — начните разбор с этой галки, а не с промта.
• Chat Model обязателен. В документации ноды перечислены OpenAI, Groq, Mistral Cloud, Anthropic и Azure OpenAI. Локальная модель подключается своей нодой — Ollama Chat Model, о ней ниже отдельный раздел.
• Memory — необязательная под-нода, и между сессиями она не сохраняется. Это свойство, а не сбой: закрыли окно чата — агент начинает с чистого листа.
• Require Specific Output Format включается только вместе с под-нодой парсера: Auto-fixing, Item List или Structured Output Parser. Без парсера галка ничего не даёт.

Есть ещё $fromAI() — синтаксис, которым модель сама заполняет параметры инструмента. Удобно ровно до момента, когда выясняется: подставляет она не то, что нужно, а то, что поняла из описания инструмента. Описание инструмента — инструкция для модели, а не документация для коллеги.

Промпт для System Message мы собрали отдельной карточкой. Она держит текст коротким намеренно: поле уходит модели при каждом сообщении, включая «привет».

Собери текст для поля System Message ноды AI Agent в n8n. Это поле лежит в разделе Options, а не в основных параметрах, и его содержимое уходит модели перед каждым запросом — значит оно должно быть коротким и однозначным.

Мои инструменты, подключённые через MCP Client Tool:
[ИНСТРУМЕНТ 1: поиск по базе клиентов — принимает фамилию или телефон, возвращает карточку]
[ИНСТРУМЕНТ 2: создание задачи в трекере — принимает заголовок, описание, срок]
[ИНСТРУМЕНТ 3: отправка письма — принимает адрес, тему, текст]

Что агент должен делать: [ЗАДАЧА: принимать обращения от менеджеров в чате, находить клиента, заводить задачу и уведомлять письмом]
Кто с ним разговаривает: [АУДИТОРИЯ: менеджеры отдела продаж, без технической подготовки]

Требования к тексту:
1. Первым абзацем — что агент делает и чего не делает. Без «ты — помощник» и прочих представлений: модель уже знает, что она модель.
2. По одному предложению на инструмент: когда его вызывать и когда НЕ вызывать. Именно второе экономит вызовы — без этого агент дёргает все инструменты подряд и упирается в Max Iterations, а он по умолчанию равен 10.
3. Что делать, если данных для вызова не хватает: спросить у пользователя, а не подставлять выдуманное. Опиши это явно — модель охотно заполняет пропуски сама.
4. Формат ответа пользователю: [ФОРМАТ: две-три строки простым языком, без markdown-разметки]
5. Отдельной строкой — чего агент не делает никогда: [ЗАПРЕТ: не отправляет письма без подтверждения менеджера, не создаёт задачи задним числом]

Отсечка. Держись в 1200 знаках: это поле уходит модели при каждом сообщении, включая «привет». Не вставляй примеры диалогов и схемы JSON — здесь живут правила, а не образцы. Не описывай, что умеет сам инструмент: это его собственное описание, и продублированное оно разъедется при первой правке. Не пиши «ты — ассистент» и другие представления.

Проверка перед выдачей: пройди по трём инструментам и на каждом убедись, что написано не только «когда звать», но и «когда не звать». Если по какому-то инструменту второе сформулировать не получилось — скажи об этом прямо, вместо того чтобы выдумывать условие.

Отдай готовый текст одним блоком, без пояснений до и после.

Десять прогонов: почему агент бросает задачу на середине

Max Iterations по умолчанию равен десяти. Это не число инструментов и не число сообщений — это сколько раз модель прогоняется на один ответ.

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

Посмотреть, на чём агент крутится, помогает галка Return Intermediate Steps в той же ноде: она отдаёт промежуточные шаги в выводе, и по ним видно, кого агент звал и в каком порядке.

Поднять лимит до тридцати — решение на один вечер. Следующий сложный вопрос упрётся в новый потолок, а токены за холостые прогоны спишутся все.

Работает другое: описание каждого инструмента, где сказано не только «когда звать», но и «когда не звать». Именно вторая строка экономит прогоны — без неё агент дёргает всё подряд, потому что у каждого инструмента описано только собственное назначение и ни у кого не описаны границы.

Напиши описание инструмента для ИИ-агента. Агент видит только это описание и по нему решает, звать инструмент или нет — значит текст должен отвечать на «когда», а не рассказывать, как инструмент устроен внутри.

Что делает инструмент: [ИНСТРУМЕНТ: ищет запись клиента в базе по фамилии или номеру телефона]
Что принимает: [ПАРАМЕТРЫ: строка поиска — фамилия целиком или телефон из 11 цифр]
Что возвращает: [ВОЗВРАТ: карточка клиента с историей обращений или пустой ответ]
Рядом есть похожие: [СОСЕДИ: поиск по сделкам и поиск по задачам — агент их путает]

Что нужно:

1. Первая строка — что инструмент делает, одним предложением, глаголом в настоящем времени. Без «этот инструмент предназначен для».
2. Вторая — когда звать. С примером запроса пользователя, по которому видно, что нужен именно он.
3. Третья — когда НЕ звать, с указанием на соседей: агент путает похожие инструменты именно потому, что у каждого описано только своё назначение и ни у кого не описаны границы.
4. Описание каждого параметра: что подставлять и в каком виде. Если формат жёсткий, скажи об этом прямо — модель охотно передаёт обрезанный номер и получает пустой ответ, после чего уверенно сообщает, что клиента нет.
5. Что делать с пустым результатом: переспросить пользователя или сообщить, что не найдено. Выбери одно.

Отсечка. Не описывай внутреннее устройство, таблицы и запросы — агенту это не нужно, а токены на описание тратятся при каждом обращении. Не дублируй сюда правила из системного сообщения: при правке они разъедутся. Не делай описание длиннее пяти строк.

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

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

Раздели мою задачу между несколькими ИИ-агентами и опиши роль каждого. Сейчас всё делает один агент и путается.

Задача целиком: [ЗАДАЧА: обработка заявок с сайта — разобрать текст, определить услугу, посчитать примерную стоимость, написать ответ клиенту, завести сделку]
Что уже есть: [ЕСТЬ: один агент с пятью инструментами, отвечает медленно и иногда считает стоимость по чужому прайсу]
Чем агенты обмениваются: [ОБМЕН: через n8n, каждый следующий получает результат предыдущего]

Что нужно:

1. Разбиение на роли: сколько агентов и что делает каждый. Меньше — лучше: каждый лишний агент это лишняя передача данных и лишнее место, где теряется контекст.
2. Для каждой роли — три строки: что входит в зону, что НЕ входит, и что он передаёт следующему. Вторая строка важнее первой: пересечение зон и есть причина, по которой один агент лезет в чужой прайс.
3. Формат передачи между агентами: какие поля обязательны, какие нет. Если поле не пришло — кто отвечает за это, отправитель или получатель.
4. Где в цепочке нужен человек. Назови один шаг, самый дорогой при ошибке, и объясни, почему именно он.
5. Что делать, когда агент не уверен: передавать дальше с пометкой или останавливать цепочку. Выбери одно и объясни, а не описывай оба варианта.

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

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

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

Память: главная грабля рабочих схем

У ноды Simple Memory всего два параметра: Session Key и Context Window Length. Настроить нечего, ломается она не настройками.

Первое. В режиме очереди (queue mode) нода не работает в активном production-воркфлоу. Причина прямо названа в документации: n8n не гарантирует, что каждый вызов памяти попадёт к тому же воркеру. Это не «иногда подглючивает» и не лечится перезапуском. На одной машине в тестовом прогоне диалог держится, на боевом сервере с очередью — нет, и разница между этими двумя запусками не в промте.

Второе. AI Chain память не поддерживает вовсе — только нода AI Agent. Собрали диалогового помощника на цепочке, удивляетесь, почему он не помнит предыдущую реплику: он и не должен.

Третье, тихое. Выражения в под-нодах резолвятся только по первому элементу входа, а не по каждому, как в обычных нодах. Пришло на вход двадцать элементов — выражение посчитается один раз, по первому, и одинаково уедет во все двадцать. Для Session Key это означает, что двадцать разных клиентов могут оказаться в одной сессии.

И общее правило поверх всего: память между сессиями не сохраняется. Если диалог должен пережить перезапуск, хранить его придётся самому — в базе рядом, а не в под-ноде.

MCP: n8n отдаёт инструменты наружу

MCP Server Trigger превращает воркфлоу в MCP-сервер: он отдаёт URL, к которому подключается клиент. Первое разочарование наступает через минуту — после этого триггера нельзя поставить обычную цепочку нод. Он соединяется только с нодами-инструментами. Хотите отдать клиенту целый воркфлоу — для этого есть отдельная нода, Custom n8n Workflow Tool.

Дальше по списку:

• Два URL. Тестовый работает, пока воркфлоу неактивен; продакшен — после публикации. Адрес, который вы скопировали при отладке, на боевом клиенте молчит.
• Authentication: None, Bearer auth или Header auth. Path генерируется случайно, но его можно задать своим.
• Транспорты — SSE и Streamable HTTP. Stdio не поддерживается. Клиент, который умеет только stdio, к n8n не подключится, и обойти это настройками нельзя.

Три ограничения вылезают у тех, кто держит n8n у себя на сервере:

• Режим очереди. С одной webhook-репликой всё соединяется. С несколькими нужно маршрутизировать все запросы /mcp* на выделенную реплику — иначе соединение будет рваться постоянно, и выглядеть это будет как «MCP не работает».
• Обратный прокси. Придётся отключить буферизацию, gzip и chunked transfer encoding. Стандартный конфиг из любого гайда по nginx делает ровно наоборот.
• claude.ai просит вход, даже когда аутентификация выставлена в None. Поведение клиента, а не ваша ошибка в настройке.

Ollama: три разных адреса и почему localhost не годится

Локальная модель нужна, когда данные не должны уходить наружу. Нода называется Ollama Chat Model, крутится в ней немного: Sampling Temperature, Top K, Top P.

Самая частая ошибка связки — ECONNREFUSED. И почти всегда это сеть в докере, а не модель: Ollama работает, порт слушает, а контейнер n8n до неё не дотягивается.

• localhost в креденшалах не работает — нужен http://127.0.0.1:11434.
• Docker Desktop на Windows и macOS — http://host.docker.internal:11434.
• Docker на Linux — та самая грабля. Имени host.docker.internal там не существует вовсе, пока контейнер не поднят с флагом --add-host host.docker.internal:host-gateway. Гайд, написанный на макбуке, на сервере с Ubuntu не заработает, и виноватой назначат модель.
• Два контейнера рядом — Ollama должна слушать 0.0.0.0. В официальных образах это уже так.

Проверять связку надо изнутри контейнера n8n. С хоста проверка почти всегда проходит и создаёт ложное чувство, что всё готово, — а падает оно потом, на первом же запросе агента.

Если поднимать всё с нуля, есть Self-hosted AI Starter Kit: Ollama, Qdrant и PostgreSQL одним набором.

Помоги собрать связку ноды Ollama Chat Model в n8n с локальной Ollama, чтобы агент работал на своей модели, а не на облачной.

Моя схема:
n8n запущен: [КАК: docker run на Ubuntu 22.04]
Ollama запущена: [КАК: нативно на том же хосте, systemd]
Железо: [РЕСУРСЫ: 8 ГБ оперативной памяти, без видеокарты]
Для чего агент: [ЗАДАЧА: разбирать входящие письма и раскладывать по папкам]

Что нужно:

1. Точный адрес для поля Base URL под мою схему. Разбери три случая отдельно: Docker Desktop на Windows и macOS, Docker на Linux, обе программы нативно. Для Linux укажи, чем именно контейнер при запуске получает доступ к хосту — без этого нужное имя внутри контейнера не существует вовсе.
2. Как убедиться, что Ollama слушает тот интерфейс, который виден снаружи её процесса, и чем это задаётся.
3. Одна команда проверки, выполняемая изнутри контейнера n8n, а не с хоста. С хоста проверка почти всегда проходит и создаёт ложное чувство, что связка готова.
4. Какую модель взять под мою задачу и моё железо. Назови одну, а не список: размер модели в гигабайтах должен оставить запас оперативной памяти самому n8n.
5. Три настройки ноды — Sampling Temperature, Top K и Top P — с конкретными значениями под мою задачу и объяснением в одну строку, что изменится, если крутить каждую.

Отсечка. Не предлагай отключать firewall, переводить контейнер в режим сети хоста и не советуй вернуться к облачной модели — нужна рабочая локальная связка. Не давай список из пяти моделей на выбор: выбери одну под названные ресурсы. Не пересказывай, как устанавливать саму Ollama, она уже стоит.

Проверка перед выдачей: сверь размер предложенной модели с моим объёмом памяти и скажи, сколько останется на n8n. Если не остаётся — предложи модель меньше, а не советуй докупить память.

База знаний: RAG и режим «как инструмент для агента»

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

Сплиттера два. Character Text Splitter режет по длине. Recursive Character Text Splitter идёт рекурсивно — по Markdown, HTML, блокам кода, и только потом по символам; он рекомендован по умолчанию. Разница видна на инструкциях: резка по длине рвёт пункт посередине, и в ответ агенту приезжает полпункта без начала.

Хранилища: Simple Vector Store живёт в памяти, рядом есть PGVector, Qdrant, Pinecone и Azure AI Search. Если у вас уже стоит PostgreSQL, отдельный сервис под векторы заводить незачем.

А вот место, где схема тихо не работает. У Simple Vector Store четыре режима: Get Many, Insert Documents, Retrieve Documents (As Vector Store for Chain/Tool) и Retrieve Documents (As Tool for AI Agent). Инструментом агента база становится только в последнем. Выбрали предыдущий — агент не решает сам, когда идти искать, и на вопрос «что написано в инструкции по модели X» отвечает общими словами. Есть и готовый Vector Store Question Answer Tool: он отвечает по найденным кускам и суммирует их.

Про эмбеддинги без мистики: маленькие модели вроде text-embedding-ada-002 быстрее и дешевле на коротких документах, большие вроде text-embedding-3-large лучше держат смысл на длинных и сложных.

Спроектируй в n8n конвейер, который положит мои документы в векторное хранилище и подключит его к агенту как инструмент.

Что за документы: [ДОКУМЕНТЫ: 40 инструкций по оборудованию, PDF, от 2 до 30 страниц]
Откуда берутся: [ИСТОЧНИК: папка на Google Drive, пополняется раз в месяц]
Что агент должен уметь: [ЗАДАЧА: отвечать монтажникам на вопросы по конкретной модели прибора со ссылкой на пункт инструкции]
Где всё крутится: [СРЕДА: self-hosted n8n в Docker, рядом PostgreSQL]

Что нужно:

1. Цепочка нод от файла до хранилища: чем загружаем, чем режем на куски, чем считаем векторы, куда кладём. Назови ноды точными именами, как они подписаны в интерфейсе.
2. Выбор разбивки. У n8n есть разбивка по длине и рекурсивная; скажи, какая нужна под мой тип документов и почему, в одну строку. Для инструкций важно, чтобы кусок не рвался посреди пункта.
3. Размер куска и перекрытие — конкретные числа под мои документы, а не «зависит от задачи».
4. Какое хранилище взять под мою среду. У меня рядом уже стоит база — учти это, прежде чем предлагать отдельный сервис.
5. Каким режимом хранилище подключается к агенту именно как инструмент, а не как отдельная цепочка. Это разные режимы одной ноды, и от выбора зависит, сможет ли агент сам решать, когда искать.
6. Что делать при пополнении папки: перезаливать всё или добавлять. Назови, по какому полю различать уже загруженные документы.

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

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

Вебхук: чем агента дёргают снаружи

Агент сам по себе не запускается. Для чата сверху ставят Chat Trigger, для всего остального — вебхук: пришла оплата, пришла заявка, пришло письмо от стороннего сервиса.

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

Помоги настроить приём вебхука в n8n и разобрать то, что приходит.

Кто присылает: [ОТПРАВИТЕЛЬ: платёжный сервис, уведомление об успешной оплате]
Что в запросе: [ТЕЛО: JSON с полями order_id, amount, status, signature]
Что должно произойти: [ДЕЙСТВИЕ: найти заказ в таблице, пометить оплаченным, отправить письмо покупателю]
Как отвечать отправителю: [ОТВЕТ: код 200 и пустое тело, иначе сервис будет повторять]

Что нужно:

1. Настройки ноды приёма: метод, путь, режим ответа. Объясни в одну строку разницу между тестовым и рабочим адресом — тестовый живёт, пока воркфлоу не опубликован, и об это спотыкаются при переносе на прод.
2. Проверка подлинности. Покажи, как сверить подпись из тела запроса до того, как что-то делать с данными. Если подпись не сошлась — какой код вернуть и почему не 200.
3. Разбор тела: как достать нужные поля и что будет, если поле не пришло. Мне нужна ветка на случай отсутствующего поля, а не падение в середине цепочки.
4. Ответ отправителю: где задаётся код и тело, и как отвечать сразу, не дожидаясь конца обработки. Платёжные сервисы ждут ответ секунды, а моя цепочка может идти дольше.
5. Повторные доставки. Один и тот же заказ придёт дважды — покажи, чем отсечь повтор, чтобы письмо не ушло покупателю два раза.

Отсечка. Не предлагай принимать запрос без проверки подписи, даже «для начала». Не советуй отвечать 200 на неподошедшую подпись, чтобы «сервис не спамил» — так теряются реальные сбои. Не пересказывай, что такое вебхук.

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

1С: обмен через OData и его потолок

Ноды для 1С в n8n нет. Обмен делают нодой HTTP Request по REST-интерфейсу OData, который публикуется на стороне 1С. Через него доступен полный набор операций: GET — чтение, POST — создание, PUT и PATCH — обновление, DELETE — удаление.

Теперь честная часть, ради которой этот раздел и написан. Через OData нельзя получить: отчёты, команды, критерии отбора, регламентные задания, внешние источники данных, пользователей и журнал регистрации. Схема «агент раз в пятнадцать минут забирает новые заказы и заводит задачи» — рабочая. Схема «агент утром присылает готовый отчёт из 1С» — нет, и узнать об этом лучше до того, как отчёт пообещан руководителю.

Для асинхронного обмена и нестандартной логики на стороне 1С публикуют HTTP-сервисы, а не OData. Это уже работа программиста 1С и согласование правок конфигурации.

Спроектируй обмен между n8n и 1С через опубликованный REST-интерфейс OData. Ноды для 1С в n8n нет, работать будем нодой HTTP Request.

Моя задача: [ЗАДАЧА: забирать новые заказы покупателей и создавать по ним задачи в трекере]
Конфигурация: [1С: Управление торговлей, OData опубликован, доступ по логину и паролю]
Как часто: [РАСПИСАНИЕ: каждые 15 минут в рабочее время]
Объём: [ОБЪЁМ: 30-80 документов в день]

Что нужно:

1. Адрес запроса к нужному объекту и вид авторизации в ноде HTTP Request. Покажи, как выглядит путь к документам и к справочникам — они адресуются по-разному.
2. Отбор на стороне 1С, а не в n8n: как запросить только документы за период и только непроведённые. Тянуть всё и фильтровать после — это лишний трафик и нагрузка на базу.
3. Постраничная выдача: чем ограничить размер ответа и как забрать следующую порцию. При 80 документах в день это не жмёт, но на первой выгрузке за год жмёт сразу.
4. Запись обратно: какими методами создаётся новый объект, какими обновляется существующий, и чем отличаются полная и частичная замена. Мне нужно проставлять признак обработки, не затирая остальные поля.
5. Отдельным списком — **чего через OData получить нельзя в принципе**. Это сэкономит мне день: я успел заложить в схему получение отчёта и хочу знать заранее, что так не выйдет.
6. Что делать с тем, что недоступно: какой механизм на стороне 1С публикуется для нестандартной логики и асинхронного обмена.

Отсечка. Не предлагай выгрузку через файлы обмена и COM-соединение — нужен HTTP. Не советуй писать обработку внутри 1С там, где хватает OData: правка конфигурации требует согласования, а это недели. Не пересказывай, как публиковать OData, он уже опубликован.

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

Чужие шаблоны: почему воркфлоу из интернета не заводится

Спрос на готовое заметный: по нашему замеру 21.09.2026 «n8n workflows» просят 372 раза в месяц, «n8n шаблоны» — 151, «n8n примеры» — 148.

Ловушка в том, что шаблон собран под чужие сервисы. Gmail вместо вашей почты по IMAP, Google Sheets вместо базы, аккаунт, которого у вас нет и не будет. Замена ноды меняет формат данных на выходе, а следующая нода берёт поля по имени из предыдущей — вот на этом стыке всё и рвётся, обычно молча. Плюс ноды, оставленные «на всякий случай»: они ничего не делают, но ломают цепочку.

Разбери готовый шаблон n8n и переделай его под мою задачу. Шаблон рабочий, но собран под чужие сервисы.

Что делает шаблон: [ШАБЛОН: принимает письмо, вытаскивает вложение, распознаёт текст и кладёт в таблицу]
Ссылка или список нод: [НОДЫ: Gmail Trigger, Extract from File, OpenAI, Google Sheets]
Что нужно мне: [МОЯ ЗАДАЧА: то же самое, но почта на своём домене через IMAP, а таблица — база PostgreSQL]
Мои ограничения: [ОГРАНИЧЕНИЯ: self-hosted n8n, наружу ходит только через прокси, аккаунта Google нет вовсе]

Что нужно:

1. Разбор по нодам: что делает каждая и что из неё выходит дальше. Отдельно отметь ноды, которые в моём случае не нужны вовсе, — их чаще всего оставляют «на всякий случай», и они ломают цепочку.
2. Замены: чем заменить каждую чужую ноду под мои сервисы. Не просто название, а что изменится в данных на выходе: у замены другой формат, и следующая нода это почувствует.
3. Места стыка, где шаблон сломается после замены. Обычно это поля, которые следующая нода берёт по имени из предыдущей.
4. Что настроить в креденшалах для моей схемы: почта по IMAP и база требуют других данных, чем у оригинала.
5. Порядок сборки: какую ноду подключить первой и на каком шаге проверять, что данные идут, чтобы не отлаживать всё разом в конце.

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

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

Сколько памяти ест n8n и откуда берётся out-of-memory

Самый обсуждаемый вопрос ниши — не «какую модель взять». В нашей выборке тредов r/n8n (84 треда, июль 2026) первое место держит вопрос про самый дешёвый способ поднять n8n у себя и про нужные характеристики сервера: 106 комментариев.

Причина понятна из соседних тредов. Там кластером идут «Workflow did not finish, possible out-of-memory issue», «Execution stopped at this node — n8n may have run out of memory», зависшие в статусе queued выполнения и краши на чтении PDF. Отдельная боль — Render Starter Plan вместе с AI-агентами: те же ошибки памяти.

Цифры, по которым это считается (сводка из 102 замеров с источниками, собранная для калькулятора сервера, проверена 15.09.2026):

• холостой расход — около 860 МБ;
• +40–50 МБ на каждое выполнение;
• диск — 0,25 МБ на выполнение: тысяча выполнений в сутки это примерно 250 МБ в день, то есть около 7,5 ГБ за месяц, если ничего не чистить;
• пол для AI-воркфлоу — 8 ГБ. Не рекомендация из вежливости, а нижняя граница, ниже которой начинается список ошибок выше.

И два уточнения, которые экономят деньги. Режим очереди не лечит проблему с бинарными файлами: по бенчмарку n8n доля падений 87% против 74% на четырёх гигабайтах — помогает память, а не смена режима. И есть ловушка с переменной N8N_CONCURRENCY_PRODUCTION_LIMIT в queue mode; мы её на своём стенде не прогоняли, поэтому лишь помечаем место, где стоит читать документацию внимательно.

Про версии. n8n 2.0 вышел в общий доступ 5 декабря 2025: task runners включены всегда, in-memory binary убран, MySQL больше не поддерживается, SQLite переведён в WAL. Ветка 1.x — EOL. Практический вывод: гайд, где вам предлагают MySQL или настройку хранения бинарных данных в памяти, написан до этого релиза, и повторять его не надо.

Облако вместо своего сервера тоже есть: у n8n Cloud квоты 2,5k, 10k и 40k выполнений, Starter — 20 евро, Pro — 50 при годовой оплате, помесячно примерно на 17% дороже (сверка 15.09.2026, цены меняются — смотрите на сайте). Свой сервер выходит дешевле и без квоты на выполнения, но обслуживать его придётся вам. Как установить n8n на VPS по шагам — с Docker Compose, доменом и HTTPS для вебхуков — разобрано в статье установка n8n на VPS.

Где запускать агента

Вопрос «какой сервер арендовать» упирается в профиль нагрузки — те самые 860 МБ холостых, расход на каждое выполнение и пол в 8 ГБ из раздела выше. Считать это руками под каждую схему утомительно, поэтому у нас есть калькулятор сервера под n8n: он спрашивает про нагрузку, называет конфигурацию и отдаёт готовый docker-compose под неё.

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

Чего n8n и агент не сделают за вас

Список того, что не чинится настройками, — самое полезное, что можно знать до сборки:

• Память не переживает сессию. Нужен диалог с историей — храните её сами, рядом с n8n.
• Simple Memory в режиме очереди в активном рабочем воркфлоу не работает. Никакая длина контекстного окна этого не изменит.
• AI Chain память не поддерживает вовсе. Только AI Agent.
• Stdio у MCP Server Trigger нет. Только SSE и Streamable HTTP.
• Отчёты, команды, регламентные задания и журнал регистрации 1С через OData недоступны. Это граница интерфейса, а не вопрос прав доступа.
• Выражения в под-нодах считаются по первому элементу входа. Партия из двадцати записей обработается с одним и тем же значением выражения.
• Модель не знает ваших регламентов. Пока документы не лежат в векторном хранилище, агент отвечает общими словами — уверенно и мимо.

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

Соседняя тема — навыки-файлы, по которым модель работает без всякого n8n: о них статья скилы для ИИ.

FAQ

Что нужно, чтобы запустить ИИ-агента в n8n?

Минимум четыре вещи: триггер сверху (чат, вебхук или расписание), нода AI Agent, под-нода Chat Model и текст в поле System Message — он лежит в разделе Options. Память и инструменты добавляются по необходимости. Под AI-воркфлоу закладывайте не меньше 8 ГБ памяти на сервере, иначе начнутся ошибки out-of-memory.

Почему агент отвечает, что не справился, и на этом останавливается?

Первое, что стоит посмотреть, — Max Iterations: по умолчанию он равен десяти. Это число прогонов модели на один ответ, и каждый вызов инструмента с осмыслением результата съедает свои прогоны. Включите Return Intermediate Steps и посмотрите, кого агент звал. Чаще лечится описаниями инструментов со строкой «когда не звать», а не поднятием лимита.

Почему память работает на тесте и не работает на боевом сервере?

Скорее всего, у вас включён режим очереди. Нода Simple Memory в нём не работает в активном production-воркфлоу: n8n не гарантирует, что каждый вызов памяти попадёт к тому же воркеру. Вторая частая причина — агент собран на AI Chain, а эта нода память не поддерживает вовсе. Диалог держит только нода AI Agent.

Как подключить Ollama, если n8n стоит в Docker на Linux?

Адрес localhost в креденшалах не подойдёт, нужен http://127.0.0.1:11434. Имени host.docker.internal на Linux не существует, пока контейнер не запущен с флагом --add-host host.docker.internal:host-gateway. Проверять связку надо изнутри контейнера n8n: с хоста проверка проходит почти всегда и ничего не доказывает.

Можно ли связать n8n с 1С и где готовые промпты под это?

Можно, нодой HTTP Request по REST-интерфейсу OData, опубликованному на стороне 1С: доступны чтение, создание, обновление и удаление. Отчёты, команды, регламентные задания, пользователей и журнал регистрации так получить нельзя — для этого на стороне 1С публикуют HTTP-сервисы. Готовый промпт под проектирование обмена — в карточке из раздела про 1С выше.

Ещё промты по теме

• Запуск по расписанию и разбор cron
• Нода code и два режима обработки
• Поиск ноды, на которой пропадает поле
• Запрос к чужому api и обработка ошибок
• Запись в таблицу без дублей строк
• Запись в базу: конфликты и обрывы