Материал подготовлен автоматически по первоисточникам: ссылки на них — в конце статьи.
Исследователи из Tsinghua University, Microsoft Research, Microsoft и University of Illinois Urbana-Champaign представили AgentScope для диагностики сбоев LLM-агентов; работа опубликована как препринт, не проходивший рецензирования. По замерам авторов, AgentScope точнее прямой передачи всей истории модели-оценщику определяет шаг и причину ошибки. Результат важен командам, которые строят агентов с длинными цепочками рассуждений, вызовами инструментов и зависимостями между действиями.
Что сделали
AgentScope преобразует журнал работы агента в граф рассуждений и действий ReAG. Узлами становятся отдельные шаги, а рёбрами — зависимости управления и данных: какое решение привело к вызову инструмента, откуда пришёл контекст и какой результат использовал следующий шаг.
Для каждого узла система формирует промежуточное семантическое представление. В нём раздельно хранятся цель и контекст шага, рассуждение и выполненное действие, а также сигналы проверки и завершения. Исходными данными могут служить вызовы API, обращения к инструментам и системные журналы. Неявные действия и рассуждения при необходимости разбирает LLM.
Полученный граф проверяется с помощью нейронных инвариантов — сформулированных авторами условий корректного поведения. В отличие от обычного программного инварианта, такое условие может быть семантическим. Например, проверка сопоставляет заявленную цель шага с выбранным инструментом и его аргументами. Само сопоставление выполняет LLM по специализированному запросу, поэтому AgentScope не отказывается от модели-оценщика, а ограничивает её задачу и контекст.
Проверки покрывают ошибки рассуждения, управления выполнением и действий: пропущенный контекст, нарушение инструкции, преждевременное завершение, цикл шагов, неверный инструмент или ошибку его вызова. Система сохраняет несколько возможных нарушений с подтверждающими фрагментами, после чего выбирает ошибку, которая лучше всего объясняет итоговый сбой. Результат включает предполагаемый исходный шаг, категорию и обоснование.
Что показали
Авторы оценивали две задачи. Точность локализации показывает долю случаев, где система нашла правильный шаг с первопричиной. Точность атрибуции показывает, правильно ли определена категория сбоя.
На созданном авторами датасете AgentErrata лучший результат AgentScope достиг 54,13%, тогда как лучший прямой подход с LLM-оценщиком получил 18,15%. AgentErrata построен посредством управляемого внесения ошибок разных категорий в траектории агентов. Авторы также сообщают о преимуществе структурного подхода на обоих поднаборах публичного датасета Who&When, хотя величина разрыва зависит от модели и типа траекторий.
В экспериментах использовались GPT-4o, GPT-5.1 и DeepSeek-V3.2. По наблюдению авторов, более новая или в целом более способная модель не всегда лучше диагностировала сбои в базовом режиме. Структура входных данных и способ отбора причин влияли на результат заметнее, чем простой выбор другой LLM.
Цена такой декомпозиции — дополнительные вызовы модели. В замере с GPT-4o обработка одной траектории занимала примерно от 25 секунд до 750 секунд. Основной вклад давало количество обращений к LLM, особенно при поиске циклов, где приходится сравнивать фрагменты траектории между собой.
Ограничения
Who&When содержит 184 траектории из задач на временные и причинные связи в повествованиях. Это узкий сценарий по сравнению с производственными агентами, работающими с корпоративными API, браузером, базами данных и изменяемым состоянием процессов. AgentErrata шире по категориям ошибок, но создан самими авторами посредством внесения сбоев, поэтому работа не показывает, насколько его распределение соответствует реальным инцидентам.
Производительность профилировали на 20 траекториях. Этого достаточно, чтобы обнаружить рост задержки на длинных историях, но не чтобы оценить пропускную способность под производственной нагрузкой. В экспериментах также не рассчитаны стоимость API, объём сохраняемых журналов и время инженера на создание инвариантов для нового домена.
Авторы сравнивают AgentScope с передачей траектории модели целиком и с последовательным анализом шагов. В работе нет сравнения с командой инженеров, специализированными средствами наблюдаемости или правилами, написанными для конкретного продукта. Поэтому результаты показывают преимущество над выбранными LLM-подходами, но не доказывают, что AgentScope дешевле или точнее существующего производственного процесса расследования инцидентов.
Что это значит
Работа не требует менять выбранную модель агента или отказываться от текущего оркестратора. Она меняет требования к наблюдаемости: для последующей диагностики нужно сохранять не только ответы LLM, но и цели шагов, входной контекст, вызовы инструментов, аргументы, результаты и зависимости между действиями.
Командам, которые пока передают длинный журнал одной модели с просьбой найти ошибку, имеет смысл запланировать промежуточное структурное представление и отдельные проверки для известных классов сбоев. Такой подход делает вердикт проверяемым: инженер видит конкретный шаг, нарушенное условие и использованные данные, а не только свободное объяснение модели.
При этом AgentScope пока разумнее рассматривать как основу для автономного разбора тестовых прогонов и инцидентов, а не как готовый синхронный предохранитель. Максимальная измеренная задержка слишком велика для процессов, где решение должно приниматься внутри пользовательского запроса. Практический план — сначала обеспечить полные трассировки, затем определить наиболее дорогие категории ошибок и проверить на собственных журналах, окупают ли точечные LLM-проверки дополнительные вызовы и задержку.
Источники
Иллюстрация: рисунок из статьи «Diagnosing with Insights: Structured Analysis of Agent Failures via Behavioral Abstractions», Jiayi Bi, Yanjie Gao, Yuanmin Xie и др., CC BY 4.0
Похоже на вашу задачу?
Расскажите, что собираете. За полчаса разложим на этапы и назовём сроки — это бесплатно и ни к чему не обязывает.
