Сервис отвечает за 200 мс, ошибок почти нет, CPU в норме. На обычном дашборде всё зелёное. Но агент пропустил обязательное согласование, сообщил о действии, которого не совершал, или после таймаута API уверенно продолжил диалог с выдуманным результатом.

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

В июле 2026 года AWS описала подход к поиску silent failures в Amazon Bedrock AgentCore. Сервис анализирует traces, относит сбои к одной из 11 категорий, группирует похожие случаи, ранжирует их по доле затронутых сессий и проходит назад по графу исполнения до подозрительного span. Интересна здесь не конкретная кнопка в AWS, а смена объекта наблюдения: от процесса и HTTP-запроса к результату пользовательской задачи.

Почему инфраструктурных SLI недостаточно

Latency, error rate и saturation всё ещё нужны. Они отвечают на вопросы: доступен ли runtime, не исчерпан ли пул соединений, не падает ли tool endpoint. Но агент может завершить запрос без исключения и всё равно нарушить контракт.

Типичные примеры:

  • агент не вызвал инструмент, хотя действие требовало записи во внешнюю систему;
  • инструмент вернул ошибку, а финальный ответ описывает операцию как успешную;
  • approval был показан, но фактический payload после подтверждения изменился;
  • агент выбрал похожий, но неверный объект;
  • цепочка закончилась формально корректным текстом без полезного результата;
  • после нескольких повторов агент создал дубликат внешнего side effect.

В каждом случае transport может вернуть 200 OK. Значит, эксплуатационный контракт должен включать не только здоровье компонентов, но и истинность результата.

Наблюдаемость начинается с проверяемого исхода

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

Для разных задач это может быть:

  • запись с ожидаемым идентификатором действительно появилась;
  • pull request создан из нужной ветки и содержит ожидаемый commit;
  • платёж остался в разрешённом статусе и связан с заданным заказом;
  • изменение конфигурации прошло schema validation и read-after-write;
  • письмо отправлено ровно указанному получателю;
  • пользователь получил ответ, подтверждённый извлечёнными источниками.

Такой outcome verifier лучше выполнять кодом после действия. Модель может предложить следующую операцию, но именно детерминированный слой должен разрешить target, проверить preconditions, применить policy, вызвать инструмент и сравнить фактическое состояние с ожидаемым.

Что должно попасть в trace

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

Минимальный набор полей:

  • стабильный run_id, session_id и идентификатор версии агента;
  • цель пользователя в нормализованном виде;
  • выбранный инструмент и разрешённый target;
  • хеш или безопасное представление аргументов без секретов;
  • preconditions до действия;
  • approval: кто, что именно и когда подтвердил;
  • ответ инструмента и классифицированный outcome;
  • результат read-after-write или другого verifier;
  • номер попытки и причина retry;
  • итоговый статус задачи, определённый не самой моделью.

Для каждого span полезно разделять proposed, authorized, executed и verified. Тогда пропущенное согласование или расхождение payload становится видимым структурным дефектом, а не впечатлением ревьюера от текста.

Зачем кластеризовать сбои

Ручная проверка десятков traces быстро превращается в чтение случайных историй. Подход AWS полезен тем, что сначала собирает похожие симптомы в группы, а затем ранжирует их по доле затронутых сессий.

Так можно отличить единичный странный диалог от системного дефекта: например, агент стабильно игнорирует timeout одного API или пропускает approval в конкретной ветке плана. Приоритизация по affected sessions обычно полезнее абсолютного числа ошибок: большой поток способен скрыть редкую, но критичную ветку, а небольшой релиз — дать мало событий при высокой доле отказов.

LLM-анализ trace здесь уместен как triage: предложить категорию, выделить подозрительный span, сформулировать гипотезу. Но он не должен единолично закрывать инцидент. Корневая причина подтверждается воспроизведением, проверкой кода, схемы и фактического состояния внешней системы.

Одиннадцать категорий — не универсальная таксономия

AgentCore Optimization заявляет 11 категорий поведенческих сбоев. Это удобно как стартовая рамка, но конкретный набор зависит от продукта. Команде важнее завести собственную версионируемую таксономию.

Практичный верхний уровень выглядит так:

  1. неверное понимание цели;
  2. неправильный выбор инструмента;
  3. неверный target или аргументы;
  4. нарушение approval/policy;
  5. ошибка исполнения инструмента;
  6. некорректный retry или дубликат;
  7. расхождение между ответом и фактическим состоянием;
  8. неполный результат;
  9. потеря контекста;
  10. необоснованное утверждение;
  11. ошибка verifier или телеметрии.

Последняя категория принципиальна. Иногда «сбой агента» на деле вызван неверным эталоном, неполной трассировкой или запоздавшей eventual consistency. Наблюдаемость тоже может ошибаться.

Как превратить находку в защиту

Сам по себе красивый кластер проблем ничего не исправляет. Для каждой подтверждённой причины нужен guard на наиболее дешёвом и надёжном уровне.

  • Ошибка выбора инструмента — уточнить описание и добавить контрастный пример.
  • Неверный target — разрешать идентификатор детерминированно и показывать его перед mutation.
  • Пропущенный approval — перенести проверку в policy layer, а не надеяться на prompt.
  • Ложное сообщение об успехе — формировать статус из результата verifier.
  • Дубликат после timeout — добавить idempotency key и сначала читать фактическое состояние.
  • Потеря контекста — сократить рабочий набор данных и сохранять типизированное состояние run.

После исправления нужен regression-набор из реальных обезличенных traces. Он должен проверять не совпадение формулировок, а инварианты: вызван ли обязательный tool, не изменился ли target после approval, совпал ли заявленный результат с внешним состоянием.

Осторожно с содержимым traces

Глубокая трассировка агента легко превращается в новый источник утечки. В prompt, tool arguments и ответах могут оказаться персональные данные, внутренние URL, токены и содержимое документов.

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

Практический дашборд

Хорошая стартовая панель объединяет технические и поведенческие показатели:

availability → tool error rate → verified task success → policy violations → duplicate side effects

Главная метрика — доля задач с подтверждённым полезным исходом. Рядом нужны разрезы по версии агента, workflow, инструменту и категории сбоя. Тогда после релиза видно не только «стало ли быстрее», но и «стало ли правильнее».

Silent failure перестаёт быть мистикой, когда задача получает явный контракт, trace — причинную структуру, а успех — независимую проверку. Зелёный дашборд снова начинает что-то значить, но только потому, что на нём появился правильный SLI.