Почему AI-агенты сбоят и как сделать, чтобы они перестали

Привет, хочу поговорить об AI-агентах. Но не об их преимуществах: все и так уже знают, как они ускоряют разработку и освобождают команду от рутины. Здесь я хочу обсудить риски и новые варианты сбоев, которые появляются вместе с внедрением агентов. В реальности даже один AI-агент способен уронить проект быстрее, чем человеческая ошибка ^[1].

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

Что будет в статье:
Типичные сбои в агентных системах ^[2]
Как заставить AI-агентов работать, а не валить проект ^[3]
— Observability: логи, трейсы и метрики ^[4]
— Метрики качества и ошибок ^[5]
— Как договориться про «успех» и «ошибку» ^[6]
Eval AI-агентов ^[7]
Автономия агентов, права и лимиты ^[8]
Автономия — это ответственность ^[9]

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

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

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

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

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

Также нередки сбои и конфликты, которые рождаются не «магией модели», а тем, как их интегрируют в инфраструктуру. Агенты завязаны на внешние API, базы и очереди, планировщики задач — любая задержка, таймаут, потерянное сообщение или гонка за ресурс превращается для них в неконсистентное состояние, из которого они принимают вполне логичные, но неверные решения.

Отдельный пласт проблем связан уже не со случайными багами, а с намеренными атаками: отравление памяти ^[11] и контекста, обход авторизации через цепочки инструментов, эскалация привилегий, эксплуатация того, что один агент слепо доверяет выводам другого. Это полноценная security‑история уровня red team и политик доступа, разбирать ее подробно здесь я не буду.

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

Типичные сбои в агентных системах

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

Еще одна проблема — «война агентов», когда между ними возникает конфликт ^[12] целей. Это происходит, если задачи противоречат друг другу, а действия агентов не скоординированы. Они начинают конкурировать за ресурсы: вычисления, память, сеть, доступ к API. В результате — резкий рост нагрузки на систему из-за бессмысленных операций, неконтролируемый рост затрат на инфраструктуру, срыв сроков релизов.

В многоагентных системах может возникать эффект снежного кома: ошибка или нештатное поведение ^[13] одного AI-агента запускает цепную реакцию ^[14] у других и становится причиной целой серии проблем.

Приведу такой пример. Мониторинговый AI-агент ошибочно сигнализировал о проблеме в сервисе. Без агента-координатора, который бы подтвердил или отклонил алерт, связанный с ним агент аварийного реагирования сразу запустил rollback, а агент деплоя параллельно попытался развернуть старую версию конфигурации. В итоге получили конфликт версий на ровном месте: команда потратила время на поиск несуществующей ошибки, MTTR взлетел, доверие к системе упало. Этого можно было избежать, если бы между сигналом мониторинга и действием стоял агент-координатор или человек, который проверяет алерты и явно утверждает опасные операции.

В каждом из описанных сбоев проблема в одном — в архитектуре агентных систем: без централизованного контроля и валидации сигнала любой из узлов легко запускает каскад ошибок.

Как заставить AI-агентов работать, а не валить проект

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

На практике это означает несколько вещей:

• нужна оркестрация: координатор или workflow‑агент, который задает общий сценарий, разбивает задачи и согласует решения подчиненных агентов;

• нормальная observability по всей цепочке: логи, трейсинг, метрики и трейсы агентных workflows;

• явные рамки автономии: какие действия агент может делать сам, а где нужен человек или внешний процесс.

Вместо одной «серебряной пули» имеет смысл опираться на уже описанные agentic‑паттерны вроде orchestrator/worker, координатора или контрол‑плейна, выбирать их под свой риск‑профиль и сверху добавлять старые добрые инженерные вещи: права доступа, лимиты, проверки и аудит.

Все ниже —чек‑лист из этих паттернов из собственного опыта ^[15], который помогает заставить агентов работать на продукт, а не против него.

Observability: логи, трейсы и метрики

Для мультиагентных систем под observability я понимаю совокупность трех вещей: детализированные логи событий, измеримые метрики и end‑to‑end tracing цепочек вызовов. С помощью observability можно выявить проблемы, найти слабое звено, из-за которого произошел сбой. Для этого недостаточно одного логирования, нужен end‑to‑end tracing.

Один запрос пользователя превращается в trace‑дерево: корневой span — входной запрос, дочерние spans — вызовы агентов и tools, глубина дерева показывает количество шагов и вложенных вызовов, а ширина — fan‑out по параллельным агентам и инструментам. Каждый span описывает небольшую единицу работы (llm_call, tool_execution, запрос к БД) и несет атрибуты: prompt_id, latency_ms, token_count, user_id, agent_name.

Мы в команде сервиса Evolution AI Agents  ^[16]запустили новый функционал — сквозную трассировку (tracing) запросов. Теперь можно не просто смотреть логи, а видеть полную картину: как именно агент пришел к своему ответу, какие инструменты вызывал, сколько времени занял каждый шаг и где возникли задержки.

На скриншоте ниже — пример такой трассировки. Интерфейс показывает работу встроенной телеметрии платформы: зафиксирована полная цепочка вызовов — от запуска агента (agent_run) до исполнения конкретного инструмента (execute_tool_get_today_weather). Для каждого шага доступны ключевые метрики производительности (время ответа, потребление токенов), а справа — итоговый результат обработки запроса пользователя.

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

Сейчас функционал доступен в режиме Preview. Вы можете протестировать трассировку в своих сценариях и повлиять на финальную версию продукта. Замечания и предложения будем учитывать при доработке.

Пример трейса в интерфейсе LangSmith. Каждый span содержит метаданные: длительность, затраты, число токенов и имя вызванного агента.

По таким trace‑деревьям сразу видно, почему агент дает сбой, например: несколько раз пересобирает план без прогресса, глубина цепочки внезапно выросла (зацикливание) или какой‑то инструмент стабильно возвращает ошибки вместо того, чтобы передать управление человеку.

Отслеживать работу AI‑агентов проще с open inference — это набор семантических конвенций и библиотек поверх OpenTelemetry, который задает единый формат трейсинга для LLM‑запросов, агентов и их инструментов. Спецификация semantic_conventions описывает, какие атрибуты вешать на спаны разных типов (LLM, tool, retriever, agent) и как кодировать статус, метаданные и метрики, чтобы трейсы из разных сервисов складывались в одну модель. Open inference позволяет автоматически снимать трейс каждого шага — от промпта до вызова инструмента и запроса в БД, — связывать их в цепочку рассуждений агента, в том числе с параллельными и условными ветвлениями. В итоге вместо того, чтобы доставать все из сырых json‑логов, можно нормально развернуть исполнение задачи по шагам: какие промпты ушли, какие инструменты вызывались, как действовали агенты и на каком именно шаге произошла ошибка или деградация.

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

Langfuse — open source платформа для observability LLM-приложений. Подходит для трейсинга сложных LLM-пайплайнов: иерархические трейсы, визуализация графов, версионирование промптов, экономика токенов, обратная связь с пользователями, фильтрация и поиск. А кроме того, в Langfuse можно протестировать разные варианты промптов или LLM-модели и посмотреть по метрикам, какой результат лучше.

OpenLIT — инструмент для observability генеративного AI и LLM‑приложений, построенный на стандарте OpenTelemetry. Автоматически генерирует трейсы и метрики, отслеживает время запросов, использование токенов, затраты. Позволяет сравнивать производительность в разных окружениях.

Agent Development Kit (ADK) — открытый фреймворк от Google для создания, тестирования и развертывания агентов на базе AI. В нем есть встроенные механизмы трассировки, которые позволяют логировать шаги агента и анализировать bottlenecks. Кроме того, в нем есть Before_tool_callback: он позволяет перехватить вызов инструмента до исполнения, проверить параметры, сопоставить их с текущим состоянием агента и при необходимости запретить вызов или заменить его. Так можно внедрять лимиты по шагам и стоимости, блокировать опасные действия и в целом ограничивать произвольные tool‑вызовы.

Arize AI — платформа наблюдаемости для машинного обучения ^[17] и оценки больших языковых моделей. В веб‑консоли Arize AI можно смотреть session‑ и trace‑уровень (как ведут себя цепочки агентов, где появляются аномалии по latency, стоимости, error rate) и настраивать алерты поверх этих метрик и eval‑результатов. SDK позволяет собирать метрики и трейсы из разных окружений.

LangChain — фреймворк и библиотека для разработки LLM-приложений. В нем видны шаги выполнения: какой промпт отправлен модели, какой ответ получен, какой инструмент вызван и с какими параметрами. А кроме того, в нем можно ограничивать вызовы tools: например, фильтровать доступные инструменты на основе разрешений пользователя и сценария, задавать middleware, которые ограничивают число tool‑вызовов на run или сессию и прерывают агента, если лимит превышен.

Метрики качества и ошибок

Для живых AI‑агентов важно не абстрактное «качество модели», а то, как они ведут себя в конкретных сценариях: решают ли задачи, сколько стоят, где ломаются. Поэтому метрики вешают на запуски (runs, сессии, workflow), а не только на оффлайновые бенчмарки модели.

Практическое правило от Confident AI — Five‑Metric Rule: на один use‑case достаточно примерно пяти хорошо подобранных метрик, иначе вы тонете в цифрах и все равно не понимаете, что именно пошло не так. Обычно это 2–3 метрики качества ответа и 2–3 метрики надежности или стоимости.

Смысловые метрики по ответам и поведению агента

Минимальный набор смысловых метрик для agentic-сценариев может выглядеть так:

Task accuracy — доля сценариев, где агент довёл задачу до правильного финального результата по эталону.

Task completion rate — процент запусков, которые вообще доходят до «нормального конца», а не обрываются по пути из‑за ошибки тулзы, таймаута или эскалации.

Relevance / faithfulness (для agentic RAG) — насколько ответ агента остаётся в рамках запроса и опирается на доступный контекст; в agentic‑RAG‑пайплайнах это обычно меряют тулзами вроде RAGAS или LLM‑as‑a‑judge‑метриками в MLflow, которые отдельно считают answer relevancy и faithfulness к вытащенным документам и по сути ловят контекстные галлюцинации.

Plan adherence — насколько агент следует сгенерированному плану: выполняет шаги в нужном порядке, не пропускает важные и не добавляет лишние. Для multi‑step агентов это хороший индикатор того, не «уползла» ли логика ^[18] в сторону.

Task adherence / instruction adherence — насколько поведение агента соответствует цели пользователя и заданным инструкциям (формату ответа, ограничениям, политике). Это отдельный сигнал: ответ может быть «умным», но не делать того, что реально просили.

Tool / API misuse — частота некорректных вызовов инструментов: неправильные параметры, лишние вызовы, опасные операции не по задаче. По сути, это специализированный error rate для действий агента через инструменты.

Refusal / safety metrics — насколько корректно агент отказывается от задач вне своих полномочий: не слишком ли часто «отнекивается» и не пропускает ли опасные запросы.

Метрики по трассировкам и ресурсам

Поверх OpenTelemetry / OpenInference‑трейсинга имеет смысл смотреть на базовый сет операционных метрик:

Error rate — доля трассировок, где есть span со статусом error (падение инструмента, API, БД и т.п.).

Latency per workflow / step latency — среднее время выполнения сценария и отдельных шагов; помогает понять, где агент реально тормозит.

Tokens per task / cost per workflow — средний расход токенов и денег на один законченный сценарий; по резким отклонениям от базовой линии удобно ловить неэффективные ветки логики или зацикливания.

Calls per user / tools per task — сколько запросов и вызовов инструментов приходится на одну задачу или пользователя; полезно для поиска «чата ради чата» и чрезмерной болтовни агента.

Как договориться про «успех» и «ошибку»

Прежде чем считать accuracy, adherence и error rate, нужно формально определить для конкретного агента:

• что считается успешной задачей: корректный финальный результат, нужное состояние системы, выполненный план;

• какие события считаются ошибками;

• неверный финальный результат;

• неотловленный сбой инструмента или API;

• нарушение политики или попытка запрещённого действия;

• заметное отклонение от плана или задачи (низкая plan/task adherence).

На практике под каждый класс ошибок заводят отдельный счетчик и 1–2 пороговых алерта, чтобы в сумме уложиться в тот самый Five‑Metric Rule и не превратить мониторинг агента в еще одного «агента по чтению дашбордов».

Eval AI-агентов

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

Что вообще делает eval агентов

Eval‑система для агента — это способ измерять производительность, надежность и безопасность не абстрактной модели, а конкретного рабочего процесса. Агента специально запускают в контролируемой среде, с разными LLM и настройками, разбивают его работу на шаги и оценивают каждый из них и финальный результат. Используются и количественные метрики (accuracy, error rate, latency, cost, adherence), и сценарные проверки: как агент ведет себя в заранее прописанных кейсах, в том числе пограничных и адверсариальных.

Как выполнять eval по шагам

Шаг 1. Собрать eval‑датасет под свои сценарии

• Golden‑кейсы с понятным правильным ответом и ожидаемой последовательностью шагов.

• Edge‑кейсы и адверсариальные сценарии: нестандартные вводы, длинные истории, промпт‑инъекции, попытки обойти политики.

Шаг 2. Задать критерии и 4–5 ключевых метрик (Five‑Metric Rule)

• По ответу: task accuracy, relevance/faithfulness (для agentic RAG), helpfulness, безопасность.

• По траектории: plan adherence, task adherence, tool/API misuse, количество шагов.

• По системе: error rate, latency, tokens/cost per task.

• Важно не расширять набор: на один use‑case достаточно примерно пяти метрик, иначе теряется фокус.

Шаг 3. Прогонять агента по датасету как по тестам

• Для каждого кейса запускать сценарий, собирать логи и трассы (OpenTelemetry/OpenInference), сохранять все шаги, вызовы инструментов и ответы.

• Автоматически рассчитывать метрики и оценивать кейсы: хард‑чекеры + LLM‑as‑a‑judge там, где требуется семантика.

Шаг 4. Сводить результат в отчет «до/после»

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

• Фиксировать, как изменились качество и стоимость после новой версии промпта, модели, оркестратора.

• Выявлять критические регрессы (качество, безопасность), которые блокируют деплой.

Шаг 5. Замыкать цикл: фиксы → снова eval → только потом прод

• Любую правку логики агента сначала прогонять на eval, сравнивая с прошлой версией по тем же метрикам.

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

Что дает ADK из коробки

Google ADK превращает это в нормальный инженерный процесс.

Критерии и метрики:

• Встроенные критерии для финального ответа (match по шаблону, ROUGE, LLM‑as‑a‑judge по рубрикам) и для траекторий: tool_trajectory_avg_score, правильный выбор и порядок инструментов, план‑adherence.

• Можно формализовать «идеальную» последовательность действий и автоматически считать отклонения.

User simulation и multi‑turn eval:

• ADK умеет симулировать пользователя и гонять многошаговые сценарии: агент задаёт уточнения, симулятор отвечает, всё это оценивается как единый workflow.

• Это важно для agentic‑систем, где баги вылезают на втором–третьем обмене.

Интеграция и наблюдаемость:

• Готовые связки с MLflow, W&B, Galileo, Arize и др., чтобы метрики и трассы eval‑запусков лежали рядом с прод‑метриками.

• Callbacks для логирования, вмешательства и гардрейлов прямо во время eval.

Практически это выглядит как: YAML/JSON‑кейсы, команда/скрипт «прогнать eval», набор чисел и отчет, по которому понятно, можно ли жить с новой версией агента.

Что есть для eval в LangChain и LangSmith

В LangChain‑экосистеме похожие штуки лежат вокруг LangSmith.

Batch и regression evals:

• Прогон датасетов, сравнение версий агентов, автоматический diff качественных и количественных метрик.

• Поддержка human‑eval, rule‑based чекеров и LLM‑as‑a‑judge.

Trajectory evaluations:

• Отдельные trajectory evals, которые сравнивают не только ответы, но и последовательность действий: какие тулзы вызывались, в каком порядке, насколько маршрут разумен с точки зрения ^[19] «судьи».

• Отлично помогает ловить вещи вроде «агент перестал вызывать валидацию», «добавилось два лишних обхода по API».

Интеграция с тестами и CI:

• Eval‑сценарии можно завернуть в обычные тесты (pytest и т.п.) и запускать в CI при каждой смене промпта или модели, как обычные unit/integration tests.

Как это реально улучшает качество и надежность

Eval — это не отчет для галочки, он закрывает несколько реальных болей:

Ловит регрессы до продакшена. Если при изменении промпта или модели, субъективно «стало умнее», то eval может показать падение task accuracy, plan adherence или рост tool‑misuse на ключевых сценариях.

Разделяет проблемы модели и оркестрации. По траекториям видно, где виновата модель (плохой план/выбор тулзов), а где оркестратор/интеграция (не тот контекст, не тот токен, не та политика).

Помогает ставить и проверять гардрейлы. Eval‑сценарии с адверсариалкой сразу показывают, где агент нарушает политику или пропускает проверки; туда проще всего добавить guardrails и затем убедиться по метрикам, что они реально сработали.

Делает качество измеримым для бизнеса. Можно показать в цифрах: «после изменений accuracy +10%, cost_per_workflow −30%, время решения −40%, safety‑эвалы не просели», а не «по ощущениям стало лучше».

Ускоряет отладку. Когда есть траектории и оценки по шагам, разработчик видит конкретно, на каком шаге и почему агент «поехал», а не просто финальное «ответ не тот».

Автономия агентов, права и лимиты

Предлагаю ввести простую градацию автономности агентов и привязать к ней права, наблюдаемость и «тормоза» вроде kill-switch и circuit breaker:

Level 0 — LLM‑приложение, а не агент

Модель не принимает самостоятельных решений и не трогает внешние системы: генерирует текст, SQL, код, но никогда не выполняет их сама. Это по сути «умный редактор» или чат‑интерфейс: ответственность полностью на человеке, который копирует команды дальше.

Level 1 — агент под полным контролем человека

Агента уже можно честно называть агентом: он вызывает инструменты и меняет состояние систем, но каждый шаг подтверждается человеком или SRE. Он не придумывает новые цели и не меняет порядок шагов без явного «ок». Пример — rollout‑агент, который готовит план миграции/деплоя, а каждый шаг запускается по кнопке.

Level 2 — ограниченная автономия по сценарию

Агент сам декомпозирует задачу в рамках заданной цели, планирует шаги и вызывает tools, пока укладывается в лимиты по шагам, времени и бюджету и не нарушает политики. Критичные действия (финансы, прод‑деплой, изменение схемы БД) по‑прежнему требуют явного аппрува человека или выделенного SRE‑агента. Пример — агент поддержки, который сам собирает данные из внутренних сервисов и заводит тикеты, но не меняет прод‑конфигурацию.

Level 3 — саморасширяющийся агент (OpenClaw‑стайл)

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

Чем выше уровень автономии, тем жестче требования:

• для L0 достаточно базовых логов и простого eval по ответам;

• для L1 нужны подробные трейсы, лимиты и человек, который может в любой момент вмешаться;

• для L2 — четкие лимиты по шагам, стоимости, времени, алерты на аномалии и регулярный eval‑пайплайн перед расширением полномочий;

• для L3 — отдельная среда, строгий RBAC/ABAC, kill‑switch и circuit breaker по умолчанию, плюс ревью всех попыток саморедактирования.

Автономия — это ответственность

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

Именно поэтому, на мой взгляд, чем больше автономии вы даете агентам, тем строже должны быть ограничения и observability: уровни L0–L3, права по принципу «стажера», лимиты на шаги и стоимость, kill switch и eval‑пайплайн перед расширением полномочий. С observability видно и цепочку действий агента, и вызовы инструментов, и метрики по ошибкам, тайм-аутам и ретраям. Это не бюрократия, а способ не превращать агента в еще один неконтролируемый микросервис.

А как вы контролируете AI-агентов и справляетесь со сбоями в их работе? Буду рада обсудить ваш опыт, если уже сталкивались с «бунтующими» агентами.