Почему ломаются агентные воркфлоу — таксономия из литературы и данных GitHub
Саммари
Один и тот же внешний симптом сбоя агентного воркфлоу может породить модель, оркестрация, внешний инструмент, инфраструктура или их сочетание — и без локализации по осям «стадия процесса × возможность агента» диагностика превращается в угадывание. Авторы строят source-aware таксономию: словарь из 65 операционных типов сбоев в 16 семействах, матрица «стадия × способность» и разделение источника доказательства (agentic / non-agentic / mixed), после чего прогоняют её на 397 записях академической литературы и 1 196 эпизодах из GitHub. Главный практический вывод: публичные данные показывают острый перегиб в зоне «итеративное исполнение × актуация» (77,3% против 30,7% у литературы), то есть надёжность агентных систем — это systems-проблема исполнения, а не только проблема качества вывода модели.
Из этого следует, что при аудите любого агентного конвейера надо спрашивать не «почему модель ответила плохо», а «на какой стадии и в какой способности это случилось»: матрица стадия × способность сразу разводит поломки промпта, оркестрации, инструментов и инфраструктуры.
На практике для команд, автоматизирующих бизнес-процессы: 70,6% всех записей сидят в трёх ячейках — мониторинг tool-call валидности, ретраев и восстановления даёт покрытие за малую часть усилий, в отличие от попыток «поднять качество модели» вслепую.
Важный нюанс: концентрация S3×D на 61% состоит из неагентных отказов (сам API, креды, зависимости), поэтому регрессия в чужом сервисе выглядит как «агент сломался» — обоснование для разделения SLO внешних контрактов и поведения агента.
Ограничение: публичный GitHub — взгляд снаружи; расхождение литературы и практики partly отражает то, что вообще попадает в issue, а не реальную частоту прод-отказов.