«Не сломано — но неправильно»: AWS предлагает мерить корректность агентов на каждом прогоне

20 лет один вопрос

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

Всё это опирается на разумное допущение: когда программа отказывает, отказ в конце концов проявляется как что-то, что машина умеет измерить. Агенты это допущение ломают.

Агент с нулевой долей ошибок, который врёт

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

Все дашборды зелёные. Ничего как будто не сломано. Ответ неправильный.

Что именно добавил агент

Программы и раньше умели ошибаться. Новое в агентах — какая доля важного нам поведения решается уже во время работы системы.

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

Отсюда вывод: вопрос «делает ли он правильную вещь?» больше нельзя полностью закрыть до релиза. Часть ответа обязана приходить из продакшена — непрерывно, по множеству прогонов. Это не отменяет прежние вопросы наблюдаемости, а добавляет к ним новые.

Что значит «корректность на уровне прогона»

Корректность теперь приходится измерять на уровне отдельного прогона. Была ли работа хорошей? Набор тестов, прогнанный до запуска, по-прежнему важен — но рядом с ним появляется живое измерение.

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

Качество приходится делать явным

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

Оценщику нужно нечто более конкретное. Что считается корректным решением о возврате? Когда агент должен передать вопрос человеку?

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

Где в цепочке ошибка

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

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

Что общего у плохих прогонов

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

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

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

Плохой прогон как часть теста

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

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

Больше автономии — больше доказательств

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

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

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

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

Куда AWS вкладывается

На этой неделе AWS запустила Amazon CloudWatch Omni — первый большой шаг в эту сторону. Он сводит трейсы агентов, сервисы приложений и инфраструктуру в одно представление.

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

AWS DevOps Agent подключается к разбору инцидентов и работает на той же телеметрии, что видят инженеры. Разработчики видят в своей среде разработки те же трейсы, что операторы — в продакшене.

Всё построено вокруг OpenTelemetry, инструментирование агентов — на OpenInference и AWS Distro for OpenTelemetry, поддерживаются агенты на LangGraph, CrewAI, Strands и других фреймворках. Автор честно оговаривает: это только начало, и многое зависит от того, как продукт будут использовать клиенты.

Что в итоге

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

Всё, что мы уже умеем наблюдать, остаётся важным: агенты работают на сервисах, базах данных, сетях, очередях и инфраструктуре.

Главная мысль статьи: объём полномочий, который организация может спокойно дать агентам, зависит от того, насколько ясно она видит, что они делают.