Failure patterns in production traces

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

• Зацикливание — агент повторяет один и тот же вызов инструмента с теми же аргументами, надеясь на другой результат, пока не упрётся в лимит шагов или бюджета;
• Проглоченная ошибка инструмента — инструмент вернул ошибку, но агент проигнорировал её и сгенерировал ответ так, будто данные получены — то есть выдумал их;
• Невалидные аргументы — модель галлюцинирует параметры инструмента: несуществующий ID, дата в неверном формате, поле не из схемы;
• Переполнение контекста — история или результаты инструментов распухли, начало контекста (часто системные инструкции) вытеснено или ответ обрезан;
• Ранняя капитуляция — «к сожалению, я не могу помочь» там, где инструменты позволяли решить задачу;
• Галлюцинация после пустого retrieval — поиск вернул ноль документов, но ответ звучит уверенно.

Исследование MAST («Why Do Multi-Agent LLM Systems Fail?», arXiv 2503.13657) на сотнях трейсов мультиагентных систем свело 14 мод отказов в три группы: дефекты спецификации (плохо поставленная задача и роли), межагентное рассогласование и слабая верификация результата. Главный вывод переносится и на одиночных агентов: большинство отказов — не «модель глупая», а дефекты оркестрации и проверки, то есть чинится кодом и промптами, а не ожиданием новой модели.

Каждый паттерн оставляет в трейсе машинно-находимый след — сигнатуру:

• Цикл: аномальное число спанов в трейсе (30 при типичных 6) и подряд идущие tool-спаны с одинаковыми name и аргументами;
• Переполнение контекста: finish_reason = length либо input_tokens последних генераций у потолка окна модели; рост input от шага к шагу виден прямо в дереве;
• Проглоченная ошибка: tool-спан со status = ERROR, при этом трейс завершён со статусом OK и уверенным финальным ответом — самая коварная комбинация;
• Невалидные аргументы: серия «tool error → повторная генерация» с сообщением валидатора в результате инструмента;
• Пустой retrieval + галлюцинация: retrieval-спан с нулём документов или низкими скорами, за которым следует длинный содержательный ответ;
• Деградация инструмента: latency-выброс или всплеск ошибок одного конкретного tool-имени после определённой даты.

Сигнатуры превращаются в сохранённые фильтры платформы: «трейсы с числом спанов > 20», «generation с finish_reason != stop», «tool status = ERROR и trace status = OK», «retrieval вернул 0 документов». В Langfuse и LangSmith такие фильтры сохраняются и вешаются на дашборд счётчиками — и вы получаете постоянный мониторинг паттернов, а не разовую охоту. Полезная привычка: у каждой категории отказа из вашей таксономии должен быть свой фильтр; если категорию нельзя выразить фильтром — значит, в спанах не хватает атрибута, и это задача на доинструментирование.

Фильтры ловят известные паттерны, но откуда берутся новые? Из систематического чтения плохих трейсов. Источники выборки, по убыванию сигнала: явный негативный фидбэк (👎, жалоба в поддержку), низкий скор online-судьи, поведенческие сигналы (пользователь немедленно переспросил то же самое, эскалация на человека), выбросы по латентности, стоимости или числу шагов, и — обязательно — случайная выборка обычных трейсов, иначе вы увидите только то, о чём пользователи потрудились сообщить.

Дальше процедура из курса по эвалам, применённая к трейсам: берёте 30–50 штук и читаете целиком — не только финальный ответ, а весь путь: какой контекст собрался, что вернули инструменты, где решение свернуло не туда. На каждый трейс — свободная заметка об ошибке (open coding), затем группировка заметок в категории с частотами (axial coding). Результат — таблица вида «циклы на search_orders — 22%, галлюцинации после пустого retrieval — 17%, обрезка контекста в длинных диалогах — 12%», которая и определяет приоритеты фиксов.

При больших объёмах ручное чтение дополняют полуавтоматикой: эмбеддинги входных запросов кластеризуются, и аномальные кластеры (новая тема, всплеск похожих жалоб) всплывают без ручного перебора. Аннотационные очереди в Langfuse/LangSmith ставят процесс на поток: дежурный размечает очередь раз в день, категории копятся, тренды видны по неделям. Час чтения трейсов в неделю даёт больше понимания системы, чем любой дашборд.

Паттерн — это симптом. Прежде чем чинить, сформулируйте гипотезу о первопричине и проверьте её по трейсам — иначе фикс залатает частный случай. Типовые связки «паттерн → первопричина → фикс»:

• Цикл: инструмент возвращает бесполезный результат, а промпт не говорит, что делать дальше → лимит итераций в коде, детект повтора «тот же tool + те же аргументы», инструкция «если инструмент дважды вернул одно и то же — смени стратегию или сообщи пользователю»;
• Проглоченная ошибка: результат инструмента вставляется в контекст без пометки об ошибке → пробрасывать ошибку явным текстом («инструмент недоступен, данных нет»), запрет отвечать «по памяти» о данных, которые должен был дать инструмент;
• Невалидные аргументы: свободный текст вместо схемы → structured outputs / строгая JSON-схема, ретрай с сообщением валидатора в контексте;
• Переполнение контекста: неограниченная история → бюджет контекста, суммаризация старых ходов, усечение результатов инструментов до релевантного;
• Капитуляция: расплывчатый системный промпт → явные критерии, когда отказывать, плюс eval-кейсы на «решаемые» запросы.

Железное правило: фикс без регрессионного кейса — временный фикс. Каждый диагностированный паттерн обязан превратиться в кейс eval-сета (как именно — в уроке 6), иначе через три релиза он вернётся, и вы будете ловить его заново, уже забыв сигнатуру.