Han workflow in n8n: как закрыть разрыв между одобрением и записью в Bitrix24

Проблему обнаружил и описал на Хабре разработчик, который собрал лабораторный workflow на n8n с моделью Groq, MCP-сервером и Bitrix24. В серии контрольных прогонов выяснилось: экран согласования и узел записи получали параметры из разных источников. Bitrix24 отклонил некорректный вызов, реального ущерба не было, но сам путь существовал. Ниже разбираем, как воспроизвести исправленную архитектуру и не попасть в ту же ловушку.

Что понадобится

• Установленный n8n (self-hosted или облачная версия)
• Аккаунт Bitrix24 с доступом к API и тестовой задачей
• MCP-сервер для Bitrix24 (открытый коннектор, связывающий n8n с CRM по стандартизированному протоколу)
• Доступ к LLM через API, в эксперименте использовался Groq
• Базовое понимание, как устроен workflow в n8n (цепочка узлов, где каждый передаёт данные следующему)
• Примерно 2 часа на настройку и проверку

Как устроена уязвимость: одобрение без привязки

Прежде чем строить workflow, важно понять, где именно ломается контроль.

В исходной архитектуре ИИ-агент имел только права на чтение в Bitrix24. Он мог прочитать задачу и предложить изменение, но не мог сам записать. Запись выполнял отдельный узел n8n после того, как человек нажимал «Подтвердить».

Проблема не в модели. Проблема в «проводке» между узлами: approval node показывал человеку параметр A, а execution node формировал вызов update_task из собственной конфигурации, где мог оказаться параметр B.

BEFORE (уязвимая схема)
Approval screen: requested_title = "A"
Downstream execution node: title = "B" ← настроено независимо

Флаг approved: true фиксировал только сам факт нажатия кнопки. Из него нельзя было восстановить, какую именно операцию, какой объект и какие значения полей видел человек.

Пошаговая инструкция: как закрыть разрыв

1. Соберите Action Envelope. Перед экраном согласования сформируйте единый JSON-объект, который содержит: целевую систему и ID объекта, операцию, исходное состояние полей, запрошенное изменение и список полей, которые должны остаться неизменными. Именно этот объект показывайте человеку.

2. Привяжите execution node к envelope. Узел записи должен брать параметры вызова только из того же Action Envelope, который одобрил человек. Никаких независимых источников. В n8n это делается через выражения, ссылающиеся на выход approval node.

{
  "target_system": "bitrix24",
  "object_id": "TASK-42",
  "operation": "update_task",
  "approved_fields": {
    "title": "Новое название задачи"
  },
  "frozen_fields": ["responsible_id", "deadline"],
  "pre_read_state": {
    "title": "Старое название задачи",
    "responsible_id": 7,
    "deadline": "2025-09-01"
  },
  "approved": true
}

1. Добавьте свежий pre-read. Прямо перед записью выполните повторное чтение задачи из Bitrix24. Сравните текущее состояние с тем, что зафиксировано в envelope. Если задача уже изменилась другим пользователем или процессом, прервите workflow и покажите расхождение.

2. Выполните запись через связанный update_task. MCP-клиент вызывает update_task строго с параметрами из envelope. Ни одно поле из списка frozen_fields не передаётся в вызов.

3. Проведите post-write verification. Сразу после записи прочитайте задачу ещё раз. Сравните фактическое состояние с ожидаемым: изменённые поля должны совпасть с approved_fields, замороженные поля должны сохранить значения из pre_read_state. Если есть расхождение, зафиксируйте его в логе и отправьте алерт.

AFTER (исправленная схема)
Action Envelope → Human Approval → Pre-read check →
→ Linked update_task (параметры ТОЛЬКО из envelope) →
→ Post-write verification

Что с этим делать по ролям?

Разработчику, который строит workflow в n8n. Проверьте каждый существующий конвейер с человеческим согласованием: execution node должен получать параметры только из того объекта, который видел оператор. Добавьте pre-read и post-write проверку. Это занимает пару часов, но закрывает конкретный сценарий отказа.

Автору Дзена и контент-маркетологу. Если вы используете ИИ-агентов для публикации или редактирования через API (например, автопостинг), убедитесь, что экран предпросмотра и фактический вызов API связаны одним набором данных. Та же логика: одобрили заголовок X, а улетел заголовок Y, потому что узлы настроены порознь.

Предпринимателю в РФ. Bitrix24 широко используется в российских компаниях, n8n доступен для self-hosted установки без ограничений. Связка работает. Но если вы подключаете LLM-агентов к CRM, передайте команде разработки конкретный чеклист: Action Envelope, pre-read, post-write. Без этого «человек в контуре» остаётся формальностью.

Главный вывод прост: «одобрено» без привязки к параметрам равно подписи под пустым бланком. Добавьте Action Envelope, свежее чтение до записи и проверку после неё. Три элемента, два часа работы, и ваш workflow в n8n перестаёт быть формальностью с кнопкой «Подтвердить».