Нельзя запускать агента, за которым не можешь следить

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

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

Агенты падают так, что это выглядит как успех

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

Агент падает так, что это выглядит как успех: складно сформулированный ответ, который неверен; вызов инструмента, который был не нужен; действие, синтаксически валидное и семантически бессмысленное. Он возвращает чистый HTTP 200 и уверенный результат, сделав при этом не то. Это тот же провал, о котором я писал в объявлении победы против неверной цели, — и снаружи этот провал невидим. Ничего не упало. Дашборд зелёный. Агент тихо обработал случай не так и поехал дальше.

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

Провал живёт в следе, а не в ответе

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

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

Это негламурная половина «следи, а не одобряй»

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

Ровно этот пробел спешат закрыть корпоративные вендоры. Новый Control Tower от Hyland подаётся как командный центр, который отслеживает агентов по KPI и может в реальном времени поставить одного на паузу или подправить, когда он переходит ограждение, — а его Agent Lifecycle Management описывает агента как то, чем управляют от проектирования до вывода из эксплуатации, а не запускают и забывают. Уберите корпоративную упаковку — и это тот же урок: масштабировать агентов без надзора — не масштабирование, а азартная игра.

Что реально делать

Чтобы отнестись к принципу серьёзно, платформа не нужна. Даже на сольном проекте:

• Трассируйте всю сессию, а не только результат. Логируйте каждый вызов инструмента и решение по порядку, чтобы при сбое можно было переиграть путь, а не гадать. Финальный вывод — наименее информативное, что стоит хранить.
• Ловите «успешно, но неверно», а не только ошибки. Ваши алерты должны ловить семантический провал — агента, который вернул 200 и сделал не то, — а это значит оценивать выводы против критериев, а не просто проверять, что он отработал.
• Считайте агента чем-то с жизненным циклом. Он будет дрейфовать по мере обновления моделей и изменения мира; бо́льшая часть дрейфа случается тихо после демо. Перепроверяйте его по расписанию, как любую систему, которая может тихо гнить.
• Не видишь — не давай действовать без присмотра. Честное правило: агент, за которым вы не можете наблюдать, — это агент, которому нельзя поручать ничего значимого самостоятельно.

Суть

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

Так что прежде чем дать агенту крутить что-то важное, задайте простой вопрос: если бы он прямо сейчас сделал не то, узнал бы я об этом вообще? Если ответ «нет», у вас не продакшн-агент. У вас немониторимый — а это просто инцидент, который ещё не заметили.