TL;DR
MAScope — способ разбирать логи мультиагентной системы с помощью LLM-судьи. Судье вместе с логом дают «форму» системы: топологию (кто с кем обменивается информацией), частоты типичных сбоев для неё и короткое описание того, как она обычно ломается. Судья идёт по списку из 14 типов сбоев и по каждому решает: да или нет.
Главная находка: у каждой топологии свои характерные поломки. В цепочке «агент → агент → агент» теряются факты по пути. В схеме «главный и подчинённые» проверка главного постепенно расходится с задачей исполнителей. В общей «доске» контекст копится, и каждый следующий читатель молча переосмысливает его по-своему. В логах с равноправными агентами начинаются круги взаимного ожидания и путаница ролей. Без этого знания судья видит одинаковые симптомы («результат неправильный», «проверки нет») и не понимает, где именно сломалась передача информации. Дешёвая модель без подсказки угадывает редко.
Суть метода в двух шагах. Сначала определяем топологию. Если схема известна заранее, это не нужно: топология одна на тысячи запусков. Потом даём судье лог, топологию, частоты сбоев и описание паттернов. С такой подсказкой дешёвая модель догнала сильную, которая видела только лог.
Схема метода
ШАГ 1 (один раз на систему): определить топологию
Из схемы оркестрации ИЛИ восстановить по логу → одна из 4 меток:
Layered / Centralized / Decentralized / Shared Message Pool
ШАГ 2 (на каждый лог): диагностика в ОДНОМ промпте
Вход: лог + метка топологии + частоты сбоев для неё
+ короткое описание «как эта топология обычно ломается»
Инструкция: проверь каждый тип сбоя НЕЗАВИСИМО по тексту лога
Выход: JSON — по одному 0/1 на каждый из 14 типов сбоев
Автоматическое восстановление топологии (в статье это TSE) идёт в четыре этапа: сжатие лога и анонимизация участников, извлечение связей со ссылками на цитаты, проверка и починка связей, присвоение метки. Нужно оно, только если конфигурации под рукой нет.
Пример применения
Задача: Вы продаёте на Ozon и собрали в n8n цепочку из трёх агентов: «Аналитик отзывов → Копирайтер карточки → Редактор». В ТЗ есть жёсткое требование: не обещать «лечебный эффект» и не называть цены. На выходе иногда всё же появляются «поможет от бессонницы». Вы выгружаете лог прогона и просите модель найти причину.
Промпт:
Ты — диагност сбоев в мультиагентных системах. Ты проверяешь лог прогона
и определяешь, какие типы сбоев в нём есть.
Layered (послойная цепочка): Аналитик отзывов → Копирайтер карточки → Редактор.
Информация идёт только вперёд, обратных связей нет.
Для послойных систем чаще всего встречаются:
- утаивание информации (агент не передал дальше важный факт) — высокая частота
- игнорирование входных данных от предыдущего агента — высокая частота
- остальные типы — ниже среднего
В послойных цепочках факты и ограничения теряются по пути вперёд:
верхний этап знал требование, нижний его не получил или не учёл.
Возможны циклы «уточнение — переписывание» между соседними ролями.
Проверь КАЖДЫЙ тип сбоя из списка ниже независимо, опираясь на цитаты из лога.
Частоты — только мягкая подсказка, где смотреть внимательнее;
не ставь «1» без доказательства в логе.
Список типов сбоев: {список_типов_сбоев}
Верни JSON: для каждого типа — 0 или 1 и короткая цитата-доказательство.
{лог_прогона}
Результат: Модель вернёт JSON с флагом по каждому типу сбоя и цитатами из лога. Самые вероятные находки по этой топологии: ограничение «без лечебных обещаний» потеряно на стыке Аналитик → Копирайтер, или Редактор проигнорировал вход. Вы увидите, на каком стыке пропало требование, и сможете починить передачу: добавить ограничение в промпт Копирайтера явно.
Почему это работает
Слабость LLM. Без структуры модель-судья смотрит на лог как на длинный разговор и оценивает локальную связность. Последний обмен «выглядит нормально». Что одно из требований потерялось три хода назад, а проверку никто не выполнил, она замечает плохо. Одинаковые симптомы в разных системах имеют разные причины, а в логе об этом не написано.
Сильная сторона LLM. Она хорошо читает контекст и сверяет утверждения с цитатами, если ей сказали, куда смотреть. Короткое описание «как эта структура обычно ломается» работает как карта: судья проверяет конкретные места передачи информации, а не весь лог подряд.
Как метод это использует. Топология превращает общий вопрос «что пошло не так?» в более узкий: «как в послойной цепочке потерялась информация?». Частоты задают, где искать в первую очередь. Инструкция «проверяй каждый тип независимо» не даёт частотам перевесить доказательства из лога.
Рычаги управления: - Топология и сигнатура → замени под свою схему. Это главный рычаг. - Частоты → бери из своих размеченных прогонов. Чем ближе к вашей системе, тем лучше. - Строгость инструкции («не ставь 1 без цитаты») → ужесточай, если судья видит сбои везде. - Список типов сбоев → сократи до тех, что важны вам. Для начала хватит 4 групп: потеря информации, застой координации, смысловой дрейф, провал проверки.
Шаблон промпта
Ты — диагност сбоев в мультиагентных системах. Ты читаешь лог прогона
и определяешь, какие типы сбоев в нём присутствуют.
{топология}: {описание_схемы_кто_кому_передаёт}
Частота каждого типа сбоя в системах такой топологии:
{частоты_по_типам}
{короткое_описание_как_эта_топология_обычно_ломается}
Проверь КАЖДЫЙ тип сбоя независимо, опираясь на цитаты из лога.
Частоты — мягкая подсказка, не доказательство.
Типы сбоев: {список_типов_сбоев}
Верни один JSON: для каждого типа — 0/1 и цитата-доказательство.
{лог}
Что подставлять:
- {топология} — одна из четырёх:
- Layered: цепочка, информация идёт только вперёд.
- Centralized: хаб раздаёт задачи и проверяет.
- Decentralized: равные агенты общаются напрямую.
- Shared Message Pool: общая доска, все читают и пишут.
- {частоты_по_типам} — доля ваших прогонов с этим сбоем. В статье их считали по 400 размеченным логам и заморозили.
- {описание_как_ломается} — 2–3 предложения. Образцы из статьи:
- Layered: потеря фактов вперёд по цепочке, циклы «уточнить — переписать».
- Centralized: критерий проверки хаба расходится с задачей исполнителей, хаб становится узким местом.
- Decentralized: взаимное ожидание, путаница ролей, дрейф взаимной критики.
- Shared Message Pool: контекст с неясной границей, поздние читатели молча переинтерпретируют ранние намерения, обязанность проверки «ничья».
- {список_типов_сбоев} — в статье это 14 типов таксономии MAST.
🚀 Быстрый старт — вставь в чат:
Вот шаблон диагноста сбоев мультиагентной системы с учётом топологии.
Адаптируй под мою систему: [опиши агентов и кто кому передаёт работу].
Задавай вопросы, чтобы заполнить поля.
[вставить шаблон выше]
LLM спросит, как агенты передают друг другу информацию, кто проверяет результат и какие сбои вы уже видели, потому что от этого зависят топология, сигнатура и частоты. Она возьмёт паттерн из шаблона и соберёт готовый промпт-судью под вашу цепочку.
Ограничения
⚠️ Качество диагноза всё ещё скромное: лучший результат на тесте — около 0,35–0,40 по Macro-F1 (усреднённая точность по 14 типам сбоев). Это подсказка для разбора логов, а не вердикт. Выводы судьи перепроверяйте по цитатам.
⚠️ Сильным моделям помогает слабо: у сильной модели прирост от топологии небольшой (около 7%). Метод в первую очередь выравнивает дешёвую модель с дорогой.
⚠️ Разметка шумная, топология связана с фреймворком: в основном тесте каждый фреймворк имеет одну топологию. Авторы проверяли это контрольным корпусом на одном коде, но часть выводов частично опирается на «отпечатки фреймворков». Децентрализованных систем в основном тесте нет, их проверяли на синтетически внесённых сбоях.
⚠️ Автоматическая часть требует кода: восстановление топологии по логу (TSE) — конвейер с адаптерами под фреймворки. В чате его не повторить. Но если схема вам известна, этот шаг не нужен.
⚠️ Экономия — прогноз: цифра «6% стоимости» посчитана расчётом для фиксированной топологии, а не измерена на реальной эксплуатации.
⚠️ Частоты нужны разметке: без своих размеченных логов частоты взять негде. Какую долю пользы даёт каждый компонент подсказки (метка, частоты, описание) по отдельности, в доступной части статьи не показано.
Как исследовали
Исследователи собрали 2220 трасс мультиагентных запусков в три корпуса. Первый — 851 «чистая» трасса из датасета MAST с готовой экспертной разметкой сбоев. Второй — 961 трасса с искусственно внесёнными сбоями, он покрывает децентрализованные системы. Третий — 408 трасс на одном и том же коде LangGraph, где менялись только связи между агентами.
Сначала проверили, зависит ли тип сбоя от топологии. Тест независимости (χ² = 409,9) показал, что связь есть, и очень сильная. Положительные отклонения для каждой топологии лежат на разных типах сбоев. Контрольный корпус на одном коде нужен был, чтобы связь не списывалась на «манеру фреймворка».
Потом сравнили судью без топологии и судью с ней. Для дешёвой gpt-mini Macro-F1 вырос с 0,173 до 0,350, то есть вдвое. С топологией, которую система восстановила сама, получилось 0,346. Сильная gpt-5.4, видевшая только лог, дала 0,372. Для gpt-5.4 с топологией — 0,399. Удивило то, что дешёвая модель с правильным контекстом почти догнала дорогую без него. На практике это значит, что структурное знание о системе заменяет часть мощности модели. Если топология неизменна, её определяют один раз, и стоимость диагностики на 1000 логов составляет примерно 6% от стоимости повторных вызовов сильной модели. Если не обучать судью, а подавать знания через промпт, диагноз устойчивее переносится на новые фреймворки. При проверке «оставь один фреймворк в стороне» метод сохранял 82% качества.
Адаптации и экстраполяции
Это мои вариации. В статье они не проверялись. Сначала идёт точный метод выше, здесь только идеи.
🔧 Техника: из диагностики в профилактику → встраиваем «сигнатуру слабого места» в инструкции агентам. Статья показывает, где каждая топология ломается. Это можно превратить в правила для самих агентов:
# Для цепочки (Layered) — в промпт каждого этапа:
В конце ответа выведи блок «Исходные требования», дословно перенеся
ограничения из ТЗ. Следующий этап обязан их учесть.
# Для хаба (Centralized) — в промпт оркестратора:
Перед приёмкой работы сверь свой критерий проверки с исходным ТЗ,
которое получили исполнители. Если расходятся — исправь критерий.
# Для общей доски (Shared Message Pool) — в промпт каждого агента:
Каждая запись на доске содержит: автора, к какому требованию относится,
и кто отвечает за её проверку. Ничьих проверок быть не должно.
# Для равноправных агентов (Decentralized):
Если два хода подряд обмениваетесь критикой без нового результата,
остановись и передай решение пользователю.
Экстраполяция: судья + самопроверка. Добавь в промпт-судью в конце инструкцию: «Для каждого найденного сбоя предложи правку инструкции агента, которая устранит этот тип сбоя». Получится цикл «лог → диагноз → правка системного промпта».
Ресурсы
- Работа: Know the Shape, Find the Fault: Topology-Conditioned Diagnosis of Multi-Agent LLM Failures — Xinwen Liu, Jiawei Zhang, Zhuocheng Pan, Xudong Liu, Isabella Zhu, Tianyu Wo; Beihang University, Пекин.
- Основа: таксономия сбоев MAST (14 типов); классификация топологий Guo et al. (layered, centralized, decentralized, shared message pool); Who&When, A2P.
- Данные: MAScope-Bench на Hugging Face (
mascope/mascope-bench); код в анонимном репозитории, ссылка в статье.