Почему агенты, впечатляющие на демо-версиях, терпят неудачу в производственных условиях, и что следует создавать вместо них.

Чего никогда не показывают в демо

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

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

В демо-версиях также часто пропускают этапы оценки и мониторинга. Без них галлюцинации или переполнение окна контекста не вызывают никаких сигналов тревоги. Агент продолжает отвечать, но ответы бывают неверными, и первым признаком проблемы становится жалоба пользователя или повреждённая запись. Система, которая работает корректно только при тщательном наблюдении, не готова к автономной работе.

Небольшой пример помогает проиллюстрировать эту проблему. Представьте агента, который бронирует встречи, обращаясь к API календаря. В демо-версии календарь отвечает за 200 миллисекунд с структурированным JSON-данными. В реальных условиях API иногда возвращает поле с изменённым именем, иногда — пустую страницу, а иногда застревает на тридцать секунд. В таких случаях модель может выдумать правдоподобный временной интервал, чтобы заполнить пробел. Каждому из этих сценариев требуется осознанный подход: проверка формата данных, рассмотрение пустых значений как отдельного состояния, ограничение времени ожидания и отказ от гаданий.

Где сбои возникают у агентов после отправки

Те же самые проблемные моменты постоянно встречаются снова и снова.

• Ненадежный результат работы модели. Модель выдает утверждения, не имеющие оснований в реальности. Когда агент подключается к действующим системам или ему требуется критически важная информация, выдуманные детали приводят к неправильным действиям.
• Сбои инструментов. Агенты зависят от API и внешних инструментов, которые могут меняться, терять связь или отклонять неожиданный ввод. Агенту необходим план на случай сбоя инструмента, например, попытка выполнения действия заново или переход на более простой метод.
• Бесконечные циклы. Недостаточный отслеживание состояния или нерешенные крайние случаи могут заставить агента бесконечно циклировать без какого-либо прогресса. Четкое ведение записей о выполненных действиях помогает избежать повторной работы.

Превышение объема контекста. Чем больше агент читает, тем выше вероятность превышения лимита его рабочей памяти, в результате чего вывод становится неполным или неверным. Больше всего страдают задачи, требующие длительной памяти.

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

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

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

Ненадежные API от сторонних поставщиков. Время отклика варьируется, возникают сбои. Основными средствами защиты являются таймауты и повторные попытки.

Большее количество агентов не означает большую надежность

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

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

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

Оркестрация оправдывает себя, когда задача естественным образом делится на части. В среде обслуживания клиентов один агент может собирать информацию, другой — оценивать настроение сообщения, а третий — составлять ответ; оркестрация объединяет все эти элементы в один ответ.

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

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

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

Проектирование с учётом производственных условий с самого начала

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

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

Повторные попытки с задержками и таймаутами. Временные проблемы, такие как сбои в сети или кратковременная недоступность сервиса, следует преодолевать с помощью повторных попыток с увеличивающимися интервалами ожидания. Таймауты предотвращают бесконечное ожидание чего-то, что так и не появится.

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

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

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

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

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

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

Реальная стоимость работы агента

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

• Звонки во внешние сервисы. Каждый звонок стоит денег и времени, а также увеличивает риски сбоев. Агент часто не может работать без них, но эта зависимость делает систему дороже и сложнее.
• Инфраструктура. Серверы, хранилища и сети должны быть настроены с учетом изменяющейся нагрузки, зависящей от активности пользователей и сложности задач. Обеспечение высокой доступности этой инфраструктуры увеличивает расходы.
• Повторные попытки и обработка ошибок. Это необходимо для надежности, но каждая попытка потребляет вычислительные ресурсы. В системе с частыми временными сбоями их количество быстро растет.

Задержка. Медленная работа раздражает пользователей, может привести к дополнительным попыткам выполнения задачи или к более длительному использованию ресурсов. Для снижения её уровня необходимы инвестиции как в инфраструктуру, так и в программное обеспечение.

Мониторинг и возможность наблюдения. Это критически важно для обеспечения надежности работы системы, однако для анализа данных, предоставляемых инструментами, требуется дополнительное программное обеспечение, оборудование и персонал.

Участие человека. Проверка, корректировка и утверждение результатов обеспечивают точность и соответствие требованиям, причем время, затрачиваемое сотрудниками, может существенно влиять на экономическую эффективность.

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

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

Что на самом деле означает надежность

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

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

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

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

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

Связанные материалы

• Практические заметки: создание системы обнаружения мошенничества на основе агентов, готовой к использованию в производстве — Пошаговое руководство по использованию Практических заметок: создание системы обнаружения мошенничества на основе агентов, готовой к использованию в производстве: контракты, проверки и готовые блоки кода для команд, внедряющих эту схему.
• Практические заметки: Claude Code Agent Teams: практическое руководство по созданию команды — Пошаговое руководство по использованию Практических заметок: Claude Code Agent Teams: практическое руководство по созданию команды: контракты, проверки и готовые блоки кода для команд, внедряющих эту схему.

Практические заметки: Feature Stores потратили десять лет на борьбу с темпоральными утечками в машинном обучении. — Подробное руководство по Практическим заметкам: Feature Stores потратили десять лет на борьбу с темпоральными утечками в машинном обучении: контракты, проверки и готовые блоки кода для команд, использующих эту практику.

Стабильное имя агента — это не тот артефакт, который вы рассматривали: фиксация кандидата — Почему имя агента может оставаться прежним при изменении навыков, инструментов и прав, и как разделять имя, кандидата на выполнение задач и идентификатор запуска для проверки и отката.

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

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