BLADE: аудит передач информации между агентами, чтобы найти, где именно сломалась цепочка

ШАГ 1: Связи → для каждого события: какое прошлое событие
        «на что опирается / что повторяет / чему противоречит / что исправляет»
        (или NONE) + уверенность. Оставить связи с уверенностью ≥ 0,3

ШАГ 2: Аудит передач → для каждого события-решения взять до 2 главных
        источников. Проверить, как решение использовало источник
        относительно требований задачи.
        Метка: ОК / НАРУШЕНИЕ (ошибка внесена здесь) /
               УНАСЛЕДОВАНО-ИСПРАВЛЕНО

ШАГ 3: Диагноз → весь лог + найденные улики → решающий шаг
        (все события — кандидаты; улики можно пересмотреть)

В статье это отдельные вызовы модели. В чате можно сделать тремя сообщениями подряд или одним промптом (см. шаблон).

Задача: Вы собрали в n8n цепочку из трёх агентов для интернет-магазина. Первый ищет тарифы СДЭК и Boxberry по маршруту Москва → Казань. Второй считает, что выгоднее. Третий пишет вывод для основателя. Отчёт пришёл с ошибкой: рекомендован более дорогой перевозчик. Нужно понять, какой агент и какой шаг виноваты, чтобы поправить именно его инструкцию.

Промпт:

Ты — аудитор сбоев в мультиагентной системе. Ниже задача и лог выполнения
с пронумерованными событиями. Итог неверный: рекомендован более дорогой
перевозчик. Определи решающий шаг.


Сравнить стоимость доставки посылки 3 кг из Москвы в Казань через СДЭК
и Boxberry, рекомендовать более дешёвый вариант для клиента.
Требования: учитывать вес 3 кг; сравнивать итоговую цену в рублях;
не выдавать предположения за факты.



[1] Оркестратор → Поисковик: найди тарифы СДЭК и Boxberry, Москва → Казань, 3 кг.
[2] Поисковик (инструмент): СДЭК — 420 ₽, 3 дня. Boxberry — 380 ₽, 4 дня.
[3] Поисковик → Аналитик: СДЭК 420 ₽ за 3 дня, Boxberry 380 ₽ за 4 дня.
[4] Аналитик: СДЭК быстрее на день, значит выгоднее. Разница в цене незначительна.
[5] Аналитик → Автор: СДЭК выгоднее по соотношению цена/срок.
[6] Автор: Рекомендуем СДЭК: быстрее и практически по той же цене.


Работай в три этапа.


Для каждого события, начиная со второго, ответь на четыре вопроса.
Для каждого укажи номер ОДНОГО предыдущего события или NONE
и уверенность от 0 до 1:
- depends_on: на какое событие оно опирается?
- repeats: какое событие оно повторяет?
- contradicts: какому событию противоречит?
- repairs: какое событие исправляет?
Оставь только связи с уверенностью не ниже 0,3.



1. Выпиши требования задачи (R).
2. Для каждого события определи тип: РЕШЕНИЕ агента или ДАННЫЕ (результат
   инструмента, пересказ).
3. Для каждого события-РЕШЕНИЯ возьми не более 2 источников с наибольшей
   уверенностью depends_on. Проверь, как решение использовало источник:
   сохранило ли смысл, не выдало ли неподтверждённое за факт,
   соблюло ли требования R.
4. Присвой одну метку:
   KEPT: faithful_use | no_actual_use | insufficient_evidence
   BREACH: unverified_adoption | inapplicable_information |
           misinterpretation | correction_introduces_new_error
   INHERITED_OR_REPAIRED: propagation_of_existing_error |
           correction_without_new_error
   Для каждой метки укажи уверенность 0–1 и одну фразу-обоснование.
5. В список находок выноси только метки не из KEPT.



Прочитай весь лог ещё раз вместе с находками.
Правила:
- Находки — улики, а не приговор. Нарушение могло быть исправлено позже
  или не повлиять на исход.
- Кандидатом остаётся КАЖДОЕ событие, в том числе без находок.
- Решающая ошибка — та, исправление которой превратило бы провал в успех
  при неизменных предыдущих шагах. Если таких несколько, выбери самую раннюю.
Выведи: номер решающего события, ответственный агент, тип ошибки
(внесена здесь / унаследована), короткое обоснование.

Результат: Модель выдаст три блока. В первом будет таблица связей между событиями с уверенностью. Во втором будет список требований и разбор передач 3→4, 4→5, 5→6 с метками. По идее, на передаче 3→4 должно проявиться нарушение: цифры верные, а вывод из них сделан неверно. Передачи 4→5 и 5→6 должны получить пометки о наследовании ошибки. В третьем блоке будет вердикт: номер шага, агент и обоснование, почему виноват тот, кто ошибся, а не тот, кто повторил за ним.

Слабость LLM. Если дать модели лог и спросить «где ошибка?», она часто цепляется за самый заметный неверный текст. Обычно это последнее сообщение, где ошибка уже видна. Но там она только повторяется. Модель не делает отдельной проверки «получил верное, а вывод сделал неверный».

Сильная сторона LLM. На узкий вопрос по двум конкретным сообщениям («сохранил ли получатель смысл источника?») модель отвечает заметно надёжнее, чем на размытый вопрос по всему логу. Ей проще сравнить один абзац с другим, чем искать иголку в стоге.

Как метод это использует. Он разрезает задачу на много узких вопросов о конкретных передачах, а потом собирает ответы в общий вердикт. Связи между шагами решают, где задавать узкие вопросы, чтобы не проверять всё подряд. Главная защита от ошибки: каждый шаг остаётся кандидатом, а находки можно пересмотреть. Локальный аудит мог ошибиться. Или нарушение было, но потом исправлено и на итог не повлияло.

Рычаги управления: - Число источников на событие (в статье K = 2) → увеличьте для логов, где решения опираются на много предыдущих шагов. Уменьшите, чтобы сэкономить токены. - Порог уверенности (в статье 0,3) → поднимите, если связей слишком много и аудит расползается. - Требования задачи (R) → чем точнее вы их выпишете, тем лучше модель отличит «нарушил условие» от «просто выбрал иначе». - Разбиение на сообщения → для длинных логов делайте три отдельных запроса и передавайте результат предыдущего в следующий.

Ты — аудитор сбоев в мультиагентной системе. Ниже задача и лог выполнения
с пронумерованными событиями. Итог неверный: {в чём ошибка итога}.
Определи решающий шаг.


{задача, которую решала система}
Требования: {список требований и ограничений задачи}



{пронумерованный лог: [1] Агент: сообщение/действие/результат инструмента ...}


Работай в три этапа.


Для каждого события, начиная со второго, ответь на четыре вопроса.
Для каждого укажи номер ОДНОГО предыдущего события или NONE
и уверенность от 0 до 1:
- depends_on: на какое событие оно опирается?
- repeats: какое событие оно повторяет?
- contradicts: какому событию противоречит?
- repairs: какое событие исправляет?
Оставь только связи с уверенностью не ниже {порог, например 0,3}.



1. Выпиши требования задачи (R).
2. Для каждого события определи тип: РЕШЕНИЕ агента или ДАННЫЕ.
3. Для каждого события-РЕШЕНИЯ возьми не более {K, например 2} источников
   с наибольшей уверенностью depends_on. Проверь: сохранило ли решение смысл
   источника, не выдало ли неподтверждённое за факт, соблюло ли требования R.
4. Присвой одну метку:
   KEPT: faithful_use | no_actual_use | insufficient_evidence
   BREACH: unverified_adoption | inapplicable_information |
           misinterpretation | correction_introduces_new_error
   INHERITED_OR_REPAIRED: propagation_of_existing_error |
           correction_without_new_error
   Укажи уверенность 0–1 и одну фразу-обоснование.
5. В список находок выноси только метки не из KEPT.



Прочитай весь лог ещё раз вместе с находками.
- Находки — улики, а не приговор.
- Кандидатом остаётся КАЖДОЕ событие, в том числе без находок.
- Решающая ошибка — та, исправление которой превратило бы провал в успех
  при неизменных предыдущих шагах. Если таких несколько — самая ранняя.
Выведи: номер события, ответственный агент, тип ошибки
(внесена здесь / унаследована), обоснование.

Что подставлять: {в чём ошибка итога} — что вы заметили в финале. {задача} и требования — исходное задание системе и условия, которые нельзя нарушать. {пронумерованный лог} — выгрузка из вашей автоматизации с номерами у каждого сообщения и результата инструмента. Если нужно, лог придётся пронумеровать вручную или попросить LLM это сделать.

🚀 Быстрый старт — вставь в чат:

Вот шаблон BLADE для разбора сбоев мультиагентной системы. Адаптируй под мою задачу: [опиши, что делает твоя цепочка агентов и что пошло не так]. 
Задавай вопросы, чтобы заполнить поля.

[вставить шаблон выше]

LLM спросит, какая у системы задача, какие в ней требования и ограничения и в каком формате у вас лог. Это нужно, потому что аудит передач сравнивает действия агентов именно с требованиями задачи. Без них модель не отличит ошибку от допустимого выбора. Она возьмёт структуру из шаблона и подстроит её под ваш лог.

⚠️ Точность далека от идеала: даже у лучшей версии метода решающий шаг угадывается чуть больше чем в половине случаев. Вердикт — гипотеза, которую нужно перепроверить глазами по указанным шагам.

⚠️ Прирост скромный: над простым вопросом «найди ошибку по всему логу» метод даёт от нескольких до десяти процентных пунктов. На одном из пяти наборов (дебаты между агентами) он не обогнал простые подходы.

⚠️ В исследовании метод запускали программно: модель возвращала вероятности по заданным вариантам через специальный интерфейс (Jev), вопросы шли параллельными пачками. Перенос в чат с «уверенностью 0–1» — это адаптация. На такой форме авторы метод не проверяли.

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

⚠️ Только «после провала»: метод разбирает уже случившийся сбой. Он не предотвращает ошибку в работе агента.

Исследователи взяли 1228 провалившихся запусков мультиагентных систем из двух наборов, Who&When и Who&When Pro. В одних сбои возникли сами. В других ошибки внесли намеренно, чтобы ответ был известен точно. Системы были разные: Magentic-One, CaptainAgent, дебаты DyLAN и конвейер MetaGPT. Метод сравнили с семью другими стратегиями поиска виноватого. Все стратегии запускали через один и тот же интерфейс и с одинаковыми логами, без доступа к правильному ответу. Различалась только логика разбора.

BLADE показал лучший или равный результат по точности определения шага на каждом наборе. В среднем 57,6% против 52,0% у лучшего конкурента. Дальше проверили, что именно даёт выигрыш. Связи между шагами сами по себе давали нестабильный эффект. Прибавку в 2,4–3,4 пункта давали находки аудита передач. Когда находки и связи перемешали между парами событий, точность упала. Значит, улики должны быть привязаны к тем взаимодействиям, которые описывают.

Неожиданное: проверка только 13–23% передач (выбранных по связям) на трёх наборах оказалась не хуже, чем проверка всех подряд. Больше проверок не значит лучше диагноз. Лишние находки по слабосвязанным шагам добавляют шум. Для практики вывод такой: сначала сузьте поле, потом проверяйте точечно.

Определение «контракта» передачи, по которому ведётся аудит:

Each handoff (e_u, e_t) carries an implicit semantic contract: the receiving
decision should preserve its source's meaning, avoid treating uncertain
information as established fact, and respect the task's requirements.

Контекст: это критерий для вопросов аудита. Полные тексты запросов к Jev в статье вынесены в приложения, во вставленном фрагменте их нет, поэтому шаблон выше — реконструкция по описанию алгоритма.

💡 Адаптация для файла инструкций агента (CLAUDE.md / системный промпт субагента): это моё развитие идеи, не проверенное авторами. Принцип «получатель отвечает за то, как использовал источник» можно вшить в самих агентов:

Когда ты получаешь результат от другого агента или инструмента, перед использованием
напиши коротко:
1) Что именно получено (дословно ключевые цифры/факты).
2) Что из этого ты собираешься использовать.
3) Не добавляешь ли ты допущений, которых нет в источнике?
Если источник неоднозначен — не принимай его как факт, пометь как «не подтверждено».

🔧 Техника: убрать этап 1 для коротких логов. Если в логе меньше 10 событий, этап связей излишен. Сразу аудируйте каждую передачу «событие → следующее» и переходите к этапу 3. Так вы экономите токены. В статье отбор передач по связям нужен, чтобы не проверять число пар, растущее квадратично с длиной лога.

• Статья: BLADE: Auditing Information Use for Failure Attribution in LLM Multi-Agent Systems
• Авторы: Xiaoguang Guo, Yaohao Long, Chuxu Zhang, University of Connecticut
• Код: https://github.com/GXG-CS/BLADE
• Бенчмарки: Who&When (Zhang et al., 2025), Who&When Pro (Liu et al., 2026)
• Интерфейс решений Jev (TypeSafe): https://docs.typesafe.ai
• Идея «контрактной вины»: Findler & Felleisen, 2002