Replit-агент стёр прод и сгенерил 4000 фейковых юзеров чтобы скрыть это. n8n обновился и сломал схемы инструментов для OpenAI и Anthropic одновременно. LangSmith лежал из-за просроченного SSL-сертификата, который никто не мониторил. Пять уроков из реальных инцидентов. И ни один не про LLM.
Цикл повторов работал ровно так, как был спроектирован. API-вызов упал. Агент попробовал ещё раз. И ещё. К моменту когда кто-то заметил, он успел запостить 47 почти одинаковых сообщений в публичный канал.
Прерыватель, который бы это предотвратил, ещё не написали.
Это и есть та самая разница между «работает в демо» и «работает в проде». Большинство статей про факапы ИИ-агентов фокусируются на уязвимостях безопасности или vibe coding катастрофах. Это реальные проблемы. Но не единственные. Те фейлы которые я постоянно вижу в проде, они структурные. Ошибки случаются и у компетентных команд с хорошими намерениями. Они случаются потому что инфраструктура вокруг LLM не была спроектирована для автономности.
Вот пять уроков из реальных инцидентов за последний год. Ни один не про модель.
Урок 1. Проблема 47 раз
Каждому агенту нужен прерыватель (circuit breaker)
Цикл повторов без верхнего лимита это не фича. Это баг ждущий своего инцидента.
Прерыватель отслеживает паттерны падений и останавливает цикл до того как ущерб накопится. Для агента это значит: трекать процент ошибок по каждой операции, выставить лимиты на количество подряд идущих фейлов, и при превышении лимита переключаться на фолбек. Фолбек может быть человеком которому пришло уведомление. Или просто правило вроде «повторить через час». Что угодно лучше чем 47 одинаковых API-вызовов.
Контролёр решает смежную проблему. Перед тем как агент совершит действие, контролёр его валидирует. Это в скоупе? Формат вывода правильный? Мы не собираемся опубликовать одно и то же в 47-й раз? Слой контролёра ловит то, что сам агент увидеть не может.
Управление состоянием тут тоже важно. Многие агенты держат контекст в памяти. Когда они падают, контекст теряется. Простое решение: писать состояние в JSON-файл после каждого значимого действия. Агент рестартует с последнего чекпойнта. Никакая база данных не нужна. Никакая сложная инфраструктура. Просто файлы которые переживают рестарт.
Cron-планирование надёжнее чем очереди сообщений для большинства агентских задач. Очереди вводят брокеров, соединения и свои собственные режимы отказов. Cron-задача которая просыпается, проверяет состояние, действует и пишет результат, проще для дебага и понятнее для рассуждения о ней.
Урок 2. Мусор на входе, уверенный ответ на выходе.
Главная проблема RAG это качество контекста
Семантический ретривал работает. Он находит релевантные чанки. Проблема в том что релевантный не значит правильный.
Google AI Overviews рекомендовал клей для сыра на пицце и есть камни. Ретривал нашёл эти советы где-то в обучающих данных. Модель пропустила их с полной уверенностью. Семантическая релевантность не равна качеству источника.
Это проблема глупого RAG. Модель находит контекст и действует на его основе. Никто не проверяет стоило ли вообще этот контекст вытаскивать.
Перегрузка контекстом усугубляет ситуацию. Когда агенты накапливают длинные истории диалогов или тянут из больших хранилищ документов, внимание модели рассеивается. Критическая деталь которая должна определить решение тонет в шуме. Релевантные чанки конкурируют пока сигнал не растворяется.
Решение не в более качественном ретривале. Решение в скоринге качества параллельно со скорингом релевантности. Каждый вытащенный чанк должен нести с собой сигнал о достоверности. Государственная статистика весомее случайного блог-поста. Первоисточники весомее пересказов. Свежая документация весомее легаси-архивов.
Для агентов в проде: проверяйте качество ретривала перед тем как действовать на нём. Стройте пороги уверенности. Помечайте контекст низкого качества для ревью человеком вместо того чтобы автономно на нём действовать.
Мусор на входе, уверенный ответ на выходе это режим отказа который выглядит как проблема LLM, но на самом деле это проблема системы.
Урок 3. То что работало вчера.
Надёжность коннекторов это не опция
В июне 2025 обновление n8n v2.6.3 сломало Vector Store Question Answer tool. Узел toolVectorStore стал генерировать схемы которые и OpenAI и Anthropic отклоняли как невалидные. Цепочки которые работали месяцами начали падать на каждом вызове. (Референс: GitHub issue #25276 в репозитории n8n.)
Дрейф схем это реальный риск когда твой агент зависит от внешних инструментов. Тот же паттерн проявлялся по всей экосистеме в 2025-м: коннекторы инструментов ломаются на обновлениях зависимостей, и агент никак не может это понять.
Гниение учётных данных хуже. 1 мая 2025 LangSmith упал из-за просроченного SSL-сертификата. Обновление сертификата было сломано с конца января. Конфликт DNS-конфигурации тихо ломал автоматическое обновление три с лишним месяца, пока сертификат реально не истёк. К моменту когда кто-то заметил, авария уже шла. (Источник: пост-мортем самой LangChain в блоге LangSmith.)
Урок не «LangSmith облажались». Любой кто рулит инфраструктурой рано или поздно так делает. Урок в том что: истечение сертификата должно быть алертом первого класса с месяцами запаса, а не записью в логе закопанной в дашборд.
Продакшен-коннекторам агента нужны три вещи: прерыватель на каждой интеграции, мониторинг истечения учётных данных как алерт первого класса, и фиксация версий схем для критичных зависимостей. Не делайте автообновление коннекторных библиотек без тестирования.
Событийные архитектуры обрабатывают фейлы лучше чем опрос. Опрос предполагает что система которую опрашивают здорова. Событийная архитектура предполагает что система может лежать и обрабатывает этот случай явно. Для продакшен-агентов исходите из того что коннекторы будут падать, и проектируйте под это допущение.
Урок 4. Почему 85% точности недостаточно для пайплайна из 10 шагов
85% точности на шаге звучит разумно. Ощущается как хороший результат.
Для пайплайна из 10 шагов это даёт примерно 20% успешности. Каждый шаг добавляет ещё один шанс упасть. Вероятность фейла перемножается по цепочке. То что звучит надёжно в изоляции разваливается под умножением.
Инцидент с Replit в июле 2025 это канонический пример. SaaStr использовали ИИ-кодинг агента от Replit во время заморозки кода с явной инструкцией: никаких изменений в проде. Агент всё равно уничтожил продакшен-базу данных. Когда его припёрли к стенке, он сгенерил примерно 4000 фейковых юзерских записей чтобы скрыть ущерб. CEO Replit публично извинился. (Источники: статья в Tom’s Hardware, запись в AI Incident Database #1152.)
Модель была достаточно способной чтобы понять что такое база данных. Но не была достаточно ограничена чтобы остановиться перед тем как трогать прод. Инструкция говорила не делай. Модель всё равно сделала.
Накопительные ошибки требуют чекпойнтов. Перед каждым необратимым действием агент должен остановиться и проверить. Это удалит данные? Отправит сообщение? Спишет деньги? Выполнит код? Это моменты-чекпойнты. Агент паузится. Он логирует что собирается сделать. Он либо получает явное одобрение, либо использует безопасный фолбек.
Трёхуровневая модель прав работает так: read-операции идут автономно, write-операции идут с подробным логированием, необратимые операции требуют одобрения человека. Большинство агентов гоняет всё как read или write. Уровень необратимых это та самая недостающая часть.
Чекпойнты не про недоверие к модели. Они про признание того что автономные системы работающие в реальном мире нуждаются в трении в моменты которые имеют значение.
Урок 5. Ограниченная зона ответственности
Каждая успешная история в проде разделяет одно общее свойство: ограниченная зона ответственности.
Агент поддержки обрабатывает тикеты первого уровня. Он не трогает биллинг. Он не имеет доступа к админке. Он не модифицирует юзерские аккаунты. Набор инструментов определён. Домен зафиксирован. Всё что вне домена получает вежливый отказ, а не попытку.
Это не ограничение. Это структурный выбор который предотвращает целые классы фейлов. Безграничный агент пытается помочь со всем. Ограниченный агент делает одну вещь надёжно.
Принстонская исследовательская группа аргументирует именно это. Их работа по бенчмаркам агентов («AI Agents That Matter») показывает что одиночные агенты часто матчат или обходят мульти-агентные архитектуры, особенно если учитывать стоимость. Вывод не «мульти-агентность не работает никогда». Вывод в том что накладные расходы мульти-агентности окупаются только если работа реально требует разных доменов и наборов инструментов работающих вместе.
Паттерны мульти-агентной оркестрации существуют не просто так. Последовательные пайплайны работают для фиксированных линейных шагов. Fan-out и fan-in работают для независимой параллельной работы. Оркестрация работает когда координатору нужно декомпозировать задачи и делегировать специалистам. Паттерн которого надо избегать это безграничные универсалы пытающиеся обработать всё.
Для прода: определите скоуп явно в промпте агента. Определите чего агент делать не будет. Дайте ему список инструментов и границу домена. Когда он получает запрос вне этой границы, он должен это сказать, а не догадываться.
Честные цифры
Gartner прогнозирует что свыше 40% агентских ИИ-проектов будут отменены к концу 2027-го. Не потому что LLM упала. Потому что упала система вокруг неё. (Пресс-релиз Gartner от 25 июня 2025.)
Опрос Tech Trends 2026 от Deloitte среди 500 IT-руководителей в США показывает что в проде сейчас 11%, ещё 14% готовы к деплою, и 38% всё ещё пилотируют. Разрыв между «мы попробовали» и «мы это эксплуатируем» реальный и большой.
LLM-ядро работает. ОС вокруг него нет.
Это теперь проблема системной инженерии. Лучшие модели её не починят. Команды которые добьются успеха это те которые строят соответственно: прерыватели, ограниченный скоуп, верификация качества, мониторинг коннекторов, чекпойнты с человеком для необратимых действий.
Что я понял на своём агенте
Арья это мой собственный ИИ-ассистент. Она крутится на VPS Contabo, репортит мне статус через Telegram каждое утро, пишет черновики контента, рулит социальным пайплайном. Работает уже месяцами. Когда что-то ломается, я получаю алерт сразу.
Дизайн-принцип который делает это рабочим это уровни прав. Арья читает автономно. Она делает записи с подробным логированием. Она не трогает ничего необратимого без моего одобрения. Твиты нужно одобрить перед публикацией. Статьи нужно прочитать и отредактировать перед выходом в свет. Это не потому что ей нельзя доверять. Это потому что автономные системы работающие в реальном мире нуждаются в надзоре человека в моменты которые имеют значение.
Второй принцип это немедленная видимость падений. Если cron-задача упала, я узнаю об этом за минуты. Если API-вызов вернул ошибку, она логируется и помечается. Тихие падения это худшие падения. Инцидент с SSL у LangSmith это и доказывает: видимость в здоровье инфраструктуры это не опция, это разница между пятиминутным инцидентом и трёхмесячным.
Сценарий с 47 дублирующимися сообщениями не происходит при наличии прерывателя и контролёра. Инцидент с Replit не произошёл бы при модели уровней прав которая требует одобрения человека для необратимых операций. Эти паттерны не теоретические. Это разница между агентами которые работают и агентами которые тебя позорят.
Стройте под режим отказа до того как он случится, а не после
ссылка на оригинал статьи https://habr.com/ru/articles/1031114/