n8n-агент получил 200 OK, но клиент увидел пустой чат: разбор бага тишины

Зелёные ноды, 200 OK от Meta и пустой чат у клиентки. Так выглядит второй «баг тишины» в ИИ-агенте на n8n, которому посвящён свежий разбор на Habr. Это уже вторая такая история у автора, и по формулировке понятно главное: система считала, что справилась, а человек остался без ответа. Анонс короткий, поэтому ниже только то, что в нём заявлено, и общие механики, из-за которых подобное случается в агентах для мессенджеров.

Что известно из разбора

Фактов в анонсе немного, но они показательные. Workflow на n8n отработал без ошибок: каждая нода окрасилась в зелёный. Запрос к API Meta вернул 200 OK. При этом пользовательница не увидела ответа агента, а в чате было пусто. Какой именно канал задействован и в какой точке цепочки пропал текст, анонс не уточняет. Подробности остаются в полной версии статьи на Habr.

Для ИИ-агентов это самый неудобный тип отказа. Исключения нет, алерт не сработает, в логах чисто. Узнать о проблеме можно только от самого клиента, если он не ушёл раньше.

Где обычно прячется тишина

У такого симптома есть несколько типовых причин. Какая из них сработала в этом случае, неизвестно, но все они дают одну и ту же картину «всё зелёное, ответа нет».

• Код 200 означает приём, а не доставку. API мессенджеров обычно принимают сообщение в очередь и сообщают о судьбе доставки позже, отдельными статусными вебхуками.
• Пустой или битый вывод модели. LLM может вернуть пустую строку, обрезанный JSON или служебный маркер вместо текста. Для n8n это валидные данные, и нода отправки отрабатывает штатно.
• Ограничения платформы. У мессенджеров бывают окна ответа, требования к шаблонам и правила модерации. Сообщение может быть принято, но не показано пользователю.
• Неверное поле в выражении. Если нода отправки берёт текст из пути, которого нет в данных, n8n подставит пустое значение без ошибки.
• Гонки и дубли. Повторные вебхуки, параллельные запуски и общая память диалога способны затереть ответ раньше, чем он уйдёт.

Общее у всех пунктов одно: успешность измеряется на стороне инфраструктуры, а не на стороне человека.

Как ловить такие баги

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

Второе: не считать 200 OK финалом. Статусы доставки из вебхуков нужно сохранять и сопоставлять с исходящими сообщениями по идентификатору. Любое сообщение без подтверждения «доставлено» через заданное время становится инцидентом.

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

Четвёртое: настроить Error Workflow в n8n и отдельный fallback. Если агент молчит, клиент получает короткое «Мы получили сообщение, ответим в ближайшее время», а оператор получает уведомление с контекстом диалога.

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

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