Все запланированные задачи остановились. Дашборд был зелёным.

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

Оповещения не срабатывают. Уровень ошибок на нуле. Дашборд состояния зелёный. А все запланированные задачи агентов, выстроившиеся в очередь за одним сбоящим AI-провайдером, незаметно прекратили выполняться.

Именно это произошло у нас. Один провайдер в ротации начал возвращать HTTP 402 — сигнал об оплате или квоте, а не о временной сетевой ошибке. Наш шлюз отреагировал так, как большинство шлюзов реагируют на неожиданные статус-коды: пробросил ошибку выше и прекратил попытки. Все вызовы, выстроившиеся за этим провайдером, завершились одинаково. Провайдер не был недоступен — он возвращал корректный HTTP-ответ. Мониторинг не видел ошибок в привычном смысле.

Мы исправили это. Исправление оказалось меньше самой проблемы. Но урок, который за ним стоял, оказался шире, чем мы ожидали.

Почему 402 — это не то же самое, что 500

Когда провайдер возвращает HTTP 500, намерение понятно: что-то пошло не так, попробуй ещё раз. Большинство логик повторных попыток справляется с этим корректно. HTTP 402 — другой случай: он говорит «требуется оплата» — это сигнал бизнес-уровня, а не временный сбой. AI-провайдер может вернуть 402, когда ключ исчерпал квоту, когда биллинговое событие ещё не обработано или когда бесплатный тариф закончился на сегодня.

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

Именно это мы и выпустили. Когда AI-шлюз Forge получает 402 от провайдера, он теперь переходит по списку предпочтений к следующему работоспособному провайдеру — так же, как он обрабатывает провайдера, систематически дающего ошибки 5xx. Запланированные задачи, стоявшие в очереди за сбоящим провайдером, выполнились. Ничего не пришлось повторять вручную.

Поверхностная площадь технического изменения была небольшой. Осмысление логики заняло больше времени.

Вторая проблема: что говорило сообщение об ошибке

Пока мы разбирались, мы исправили ещё кое-что.

Когда AI-модель отказывается отвечать по политике допустимого использования, она возвращает структурированный отказ — обычно понятное сообщение о том, что она не будет отвечать. Это не системный сбой. Это решение модели. Но наш шлюз показывал это как «бюджет инструментов исчерпан» — сфабрикованная системная ошибка, не сообщавшая пользователю ничего правдивого о том, что произошло.

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

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

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

Что общего у этих двух вещей

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

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

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

Накопительный эффект непонятных сбоев

Когда сообщения об ошибках лгут, накапливается определённая цена. Не только немедленная путаница — долгосрочное разрушение доверия к системе в целом.

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

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

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

Как это выглядит на практике

Мультипровайдерная маршрутизация в Forge всегда обрабатывала ошибки 5xx и деградацию состояния провайдера. Теперь она обрабатывает ответы 402 с той же логикой: запрос переходит к следующему провайдеру в вашем порядке предпочтений — прозрачно, без необходимости повторять вручную. Вашим агентам не нужно знать, у какого провайдера биллинговый момент; они просто получают ответ.

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

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

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

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

Именно это мы и выпустили. Запланированные задачи выполняются. Сообщения об ошибках говорят правду.

Мультипровайдерная маршрутизация Forge обрабатывает переключение, отслеживание состояния и предпочтения провайдеров по всем подключённым AI-провайдерам. Подробнее →