AI-агенты в проде могут выглядеть убедительно ровно до первого длинного сценария: в статье OTUS на Habr / Карьера приводится пример, где связка агентов застряла в цикле на 264 часа и, по разбору из инженерных блогов, довела счёт почти до 47 тысяч долларов. Для российской IT-аудитории это полезный холодный душ: проблема уже не в том, умеет ли агент вызвать API на демо, а в том, переживёт ли он реальную нагрузку, лимиты и чужие права доступа.
Материал написал Сергей Прощаев, Tech Lead и руководитель направления Java/Kotlin-разработки в FinTech и e-commerce. Как пишет Habr / Карьера, его главный тезис прост: большинство AI-агентов ломаются не на уровне модели, а на уровне обвязки и архитектуры. LLM сама по себе не действует во внешнем мире, она только генерирует текст. Все реальные действия, от чтения файлов до записи в базы и вызова сервисов, обеспечивает агентный контур вокруг модели. И именно там, по наблюдениям автора, чаще всего прячутся ошибки, которые на презентации незаметны, а в продакшене быстро превращаются в пустые ответы, бесконечные повторы, потерю контекста и лишние траты.
Первая и, судя по интонации статьи, самая распространённая ошибка — наивный реактивный цикл в духе «подумал, вызвал инструмент, посмотрел результат, снова подумал». На короткой задаче он выглядит почти магией: агент бодро проходит happy path, пишет в логах зелёные строки и создаёт ощущение, что архитектурная часть уже решена. Но если задача длиннее двух-трёх шагов, такой агент начинает ходить кругами: повторяет одни и те же вызовы, уточняет уже уточнённое и теряет цель. Проблема не в «глупой» модели, а в том, что у неё нет явного плана и внятной точки завершения. Автор прямо противопоставляет этому подходу схемы с предварительным планированием, когда агент сначала раскладывает задачу на шаги, а потом идёт по ним последовательно. В материале упоминаются ReAct, Plan-and-Solve, Plan-then-Execute, Tree of Thoughts, LLM Compiler и графовые оркестраторы вроде LangGraph, но без обещаний серебряной пули: универсального победителя нет, просто явный план обычно устойчивее голого цикла.
Из этого же вытекает вторая ошибка — отсутствие жёстких условий остановки. Обычный бизнес-софт часто падает громко: исключение, алерт, отказ. Агентный контур, по версии автора, ломается иначе: тихо, долго и дорого. Если системе не задать лимит шагов, бюджет, количество повторных попыток и условия выхода, она не умеет признать, что застряла. В итоге остановит её не архитектура, а внешний таймаут или внимательный человек, который случайно заглянул в биллинг. Для команд, которые сейчас спешно собирают внутренние AI-инструменты, это, пожалуй, самый практичный вывод из статьи: без step limit и cost guardrails даже рабочая демонстрация остаётся лотереей.
Дальше Прощаев расширяет разговор от циклов к инфраструктурной гигиене. В кратком описании статьи перечислены типовые продовые симптомы: пустые ответы от инструментов, противоречивые данные, задачи на десятки шагов, ограничения бюджета и проблемы с правами. Смысл в том, что агент почти никогда не живёт в стерильной среде. Сервисы иногда отвечают пусто, API меняют формат, контекстное окно не бесконечно, а внешние системы не обязаны быть удобными для «рассуждающего» оркестратора. Если архитектура рассчитывает только на идеальный сценарий, то агент проходит демо, но разваливается при первом же отклонении от happy path. В этом месте статья полезно возвращает разговор с уровня модных фреймворков на уровень инженерной дисциплины: вопрос не в том, какой именно агентный стек выбрала команда, а в том, предусмотрела ли она деградацию, неполные ответы и отказ внешних зависимостей.
Отдельно автор бьёт по популярной иллюзии, что вся память агента помещается в контекст модели. В статье контекст описан как рабочая память, а не хранилище: если бесконечно складывать туда историю, результаты инструментов и промежуточные рассуждения, качество начинает проседать. Для продакшена это означает простую, но неприятную вещь: AI-агенты в проде нельзя проектировать как «один очень длинный чат». Нужны внешняя память, нормальная структура состояния, сжатие промежуточных результатов и правила, что именно агент должен помнить, а что нет. Иначе он либо забудет важный кусок задачи, либо утонет в собственном логе. Для разработчиков здесь мало новой философии, но много знакомой инженерной боли: управление состоянием никуда не делось, просто теперь оно замаскировано под естественный язык.
Для бизнеса у этой истории тоже довольно приземлённый вывод. Автор фактически предлагает перестать оценивать агентные системы по эффектному демо и начать оценивать их как любой другой продовый контур: по предсказуемости, наблюдаемости, цене ошибки и управляемости прав доступа. Если агент умеет читать файлы, писать в базы и дёргать сервисы, это уже не «умный чатик», а полноценный исполняющий компонент с собственным классом рисков. Значит, к нему применимы все старые добрые вопросы: где лимиты, где аудит, где контроль разрешений, где сценарий частичного отказа, кто и как останавливает runaway-процесс. Для CTO и продуктовых команд это особенно актуально сейчас, когда запрос на автоматизацию растёт быстрее, чем зрелость внутренних AI-платформ.
Самое интересное в этом тексте не список из шести ошибок сам по себе, а сдвиг оптики. Ещё год назад рынок обсуждал, какой моделью заменить человека на типовой операции. Теперь разговор постепенно смещается к более скучной, но взрослой теме: можно ли вообще встроить AI-агента в систему так, чтобы он не сжёг бюджет, не потерял контекст и не ушёл спорить сам с собой на несколько суток. Похоже, в ближайшее время выигрывать будут не те команды, которые быстрее всех прикрутили LLM к десятку инструментов, а те, кто раньше остальных научился относиться к AI-агентам в проде как к обычной критичной распределённой системе, только с дополнительной непредсказуемостью на входе.