Как собрать в n8n ИИ-агента«бриф → черновик КП»

Ниже — рабочая карта, которую можно собрать в n8n workflows без «магии одного агента».

Webhook / почта / форма
        ↓
Нормализация текста (Code)
        ↓
Проверка: бриф не пустой? (IF)
        ↓
Ключ идемпотентности (хеш брифа)
        ↓
LLM №1: извлечь JSON-требования
        ↓
Валидация полей (Code / IF)
        ↓
Сборка структуры КП по шаблону (Set / Code)
        ↓
LLM №2: черновик Markdown по полям
        ↓
Запись в таблицу / CRM
        ↓
Telegram / email менеджеру → HITL-правка

Два вызова LLM и детерминированные ноды между ними

У модели в этом пайплайне ровно две задачи:

1. Extract — вытащить структурированные требования.
2. Generate — написать текст по уже собранному каркасу.

Всё остальное делают обычные ноды: IF, Set, Code, запись в БД, Telegram. Так вы снимаете с модели ответственность за повторы, формат и «не отправить лишнее».

Альтернатива — один Tools Agent, который сам решает, какие инструменты вызвать. Он уместен, если нужен диалог уточнений («спросить бюджет в CRM»). Для документа с ценой и сроками свободный цикл агента чаще вреден: модель может «дописать» факты через tool или зациклиться.

Где ставить HITL, чтобы модель не «отправила сама»

В n8n есть два уровня HITL — их легко перепутать:

1. Tool-level — нативный Approve/Deny перед опасным инструментом (например, «отправить email клиенту»). Есть в документации n8n для Human review через Telegram, Slack, Gmail и др.
2. Workflow-level — агент вообще не шлёт клиенту: кладёт черновик менеджеру («доработай и отправь сам»).

Для коммерческого предложения обязателен второй уровень. Первый — дополнительная страховка, если в Tools Agent вообще есть tool отправки наружу.

Три рабочих входа:

1. Форма на лендинге → Webhook с полем brief.
2. Письмо → IMAP/Gmail trigger, тело письма = бриф.
3. Telegram-бот продаж → сообщение менеджера или лида.

На старте проще всего webhook: один POST с текстом, удобно тестировать из Postman или curl.

Как принять повторный бриф без дублей (идемпотентность)

Клиент (или сам webhook при таймауте) часто пришлёт один и тот же бриф дважды. Без защиты вы дважды заплатите за LLM и получите два черновика.

Практика:

1. Нормализуйте текст (обрезать пробелы, привести переносы).
2. Посчитайте SHA-256 от текста — это ключ.
3. Перед LLM проверьте: ключ уже есть? → не вызывайте модель снова.

Таймауты webhook и ответ 202, когда генерация долгая

Два вызова LLM легко выходят за ~60 секунд — типичный лимит ожидания webhook. Если режим ответа «ждать конца флоу», клиент формы получит таймаут и нажмёт «отправить» ещё раз.

Рабочий приём:

• сразу ответить 202 Accepted («принято, обрабатываем»);
• дальше гнать async-ветку: extract → generate → Telegram менеджеру;
• клиенту/форме отдать ссылку на статус или просто «менеджер свяжется».

Между двумя LLM — детерминированная сборка. Вы маппите JSON в блоки шаблона коммерческого предложения. Здесь ещё нет «красивого текста» — только каркас.

Блоки: оффер, объем, сроки, цена, next step

Базовый каркас:

1. Оффер — что предлагаем под цель клиента.
2. Объём — scope + исключения.
3. Сроки — дата или [уточнить у клиента].
4. Цена — сумма или [уточнить у клиента].
5. Next step — «созвон / уточнение / счёт».

Шаблон храните в Set/Code или в таблице — так легче версионировать без правки промпта.

Почему структуру лучше собрать кодом/шаблоном, а не одним промптом

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

После LLM №2 сценарий должен:

1. сохранить черновик;
2. прислать менеджеру превью;
3. остановиться с точки зрения клиента.

Approve в Telegram или email: кнопка «ок / вернуть»

Практичные варианты:

• Telegram: сообщение с текстом КП + кнопки «ок, беру в работу» / «вернуть на доработку» (через Wait / Send and Wait или просто статус в таблице).
• Email: письмо себе/отделу с черновиком; отправка клиенту — вручную из CRM.
• Нативный Human review у tool «send email» — только если отправка автоматизирована и вы сознательно включаете авто-outbox.

Не смешивайте «менеджер правит черновик» и «агент сам шлёт клиенту после Approve» без явной политики команды.

Что нельзя отдавать без глаз: PII, скидки, обещания SLA

Перед отправкой человек обязан проверить:

• персональные данные и внутренние пометки клиента;
• любые скидки и «особые условия»;
• формулировки про сроки, штрафы, SLA;
• что маркеры [уточнить] либо закрыты фактом, либо убраны из клиентской версии.

Брифы часто содержат контакты и бюджеты: на self-host проще контролировать, что уходит во внешнюю LLM; сырой текст лучше не светить в лишних логах.

Когда проще остаться в n8n

• Нужны Code-ноды под хеш, JSON-валидацию и шаблон.
• Важен self-host и данные брифов «у себя».
• Уже есть стек LangChain-нод / AI Agent в n8n.
• Сценарий документный: extract → validate → generate → HITL.

Когда имеет смысл перенести сценарий в Make

• Команда уже живёт в Make и быстро клеит CRM ↔ почта ↔ мессенджеры.
• Нужен быстрый прототип без сервера.
• AI Agents в Make удобны как визуальная оркестрация SaaS; для жёсткой валидации JSON и идемпотентности чаще всё равно упрётесь в кастомный код.

Развёрнутый гайд по Make AI Agents у нас уже отдельной страницей — здесь достаточно выбора: КП с фактами и проверками → n8n; быстрый SaaS-прототип продаж → Make.

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

Шаг 1. Создайте workflow и Webhook

1. В n8n: New workflow → нода Webhook.
2. Method: POST. Path: например brief-to-kp.
3. Включите заголовок/токен проверки (header X-Hook-Secret).
4. Добавьте Respond to Webhook пока с простым {"status":"accepted"}.

Признак успеха: тестовый POST возвращает 200/202 и execution появляется в логе.

Шаг 2. Нормализация и идемпотентность

1. Code: взять body.brief, trim, отказ если длина < N символов.
2. Посчитать хеш брифа.
3. Проверить в Sheets/БД: хеш есть? → Respond «already processed» и стоп.
4. Иначе записать строку со статусом processing.

Признак успеха: повтор того же брифа не создаёт вторую строку и не дергает LLM.

Шаг 3. LLM №1 + валидация JSON

1. Нода LLM с system: «верни только JSON по схеме…; неизвестные поля — null; пробелы — в missing_fields».
2. Code: JSON.parse, проверка ключей.
3. IF: если budget/deadline выдуманы относительно исходного текста — в ошибку.

Признак успеха: на брифе без цены в выходе budget: null и [уточнить у клиента] в каркасе.

Шаг 4. Каркас + LLM №2 + HITL

1. Set/Code: собрать блоки оффер/объём/сроки/цена/next step.
2. LLM №2: «напиши КП по полям, цифры не меняй».
3. Сохранить Markdown в таблицу.
4. Telegram менеджеру с текстом и ссылкой на запись.
5. Никакой ноды «Email клиенту» в этой версии.

Признак успеха: в Telegram приходит черновик; в таблице статус draft_ready; клиент ничего не получил.

Типичные ошибки новичка

1. Один промпт «сделай КП» — лечится разделением extract/generate.
2. Sync-webhook без 202 — форма отваливается по таймауту, бриф шлётся дважды; включите ранний 202 + идемпотентность.
3. Continue On Fail на валидации — битый JSON проходит дальше; на критичных нодах лучше падать в Error Trigger.
4. Автоотправка клиенту — уберите tool/ноду отправки наружу до отдельного согласованного процесса.