TL;DR
BRIDGE — управляющий слой для цепочки агентов. Он следит за тем, что один агент передал другому, и сверяет это со списком фактов, которые контракт задачи требует доставить. Если факт потерян, не использован или ушёл не тому, слой чинит передачу. Но только если по накопленной статистике такой ремонт обычно помогает. После ремонта он проверяет, что дыра закрылась. Если не закрылась, сообщение уходит в исходном виде.
Главная находка: в мультиагентных цепочках «подстраховка» вредит чаще, чем помогает. Агент А забыл мелочь, агент Б всё равно справился. Любое «давай уточним» или «давай переделаем» в таком случае ломает рабочий ход. В исследовании около 88% невыбранных ремонтов ничего не меняли, то есть тратили токены впустую. Если вмешиваться всегда, результат становился хуже, чем без вмешательства. Ещё хуже вмешательство не по типу поломки: переспрашивать то, что уже доставлено, отвлекает получателя.
Метод работает по цепочке: найти дыру в передаче → подобрать ремонт, подходящий к типу дыры → решить, стоит ли вмешиваться → применить ремонт → проверить результат → при провале откатить. Полностью он реализуется кодом. Но его принципы (не чинить без нужды, подбирать ремонт под тип поломки, проверять ремонт, держать список обязательных фактов) переносятся в инструкции агентам.
Схема метода
ОФЛАЙН (HandoffProbe, один раз на модель):
берём старые прогоны → ломаем передачу → гоняем два продолжения:
«как есть» и «с ремонтом» → сравниваем итог тестами
→ получаем таблицу: какой ремонт при какой поломке помогает / вредит / бесполезен
ОНЛАЙН (BRIDGE, на каждой передаче):
ШАГ 1: Строим граф: сообщения, результаты инструментов, обязательства контракта
ШАГ 2: Ищем «дыры» (фронтиры) → 3 типа:
• доставлено, но не использовано
• факт вообще не появлялся
• факт ушёл не тому адресату
ШАГ 3: Берём самую раннюю дыру, набираем допустимые ремонты (ASK / INTEGRATE / VERIFY / DECOMPOSE / RETRIEVE)
ШАГ 4: Ворота: польза − риск − цена > 0, риск вреда ниже порога, данных достаточно?
нет → пересылаем сообщение как есть
ШАГ 5: Делаем снимок состояния, применяем ремонт
ШАГ 6: Проверка: дыра закрыта, старые связи целы?
да → отправляем исправленное; нет → откат, отправляем оригинал
Шаги 1–4 и 6 выполняет код-контроллер, и LLM для них не нужна. LLM-запрос нужен только для ремонта ASK («спросить отправителя»).
Пример применения
Задача: Вы автоматизируете подготовку коммерческого предложения. Цепочка из трёх агентов: «Сборщик требований» (читает письмо клиента из Битрикс24) → «Копирайтер КП» → «Проверяющий». В письме клиента есть жёсткие факты: бюджет до 450 000 ₽, срок до 15 июня, цена с НДС, нельзя упоминать конкурента «Контур». Раз за разом какой-то из фактов теряется на стыке. А когда вы добавили «пусть копирайтер на всякий случай всё переспросит», стало хуже: он начал переделывать уже верные абзацы.
Промпт (системная инструкция для агента-контролёра, который смотрит на каждую передачу):
Ты — контролёр передач в цепочке агентов. Ты не пишешь КП.
Ты проверяешь, дошли ли до следующего агента обязательные факты,
и вмешиваешься только если это действительно нужно.
Обязательные факты (id | суть | кто производит | кому нужен):
F1 | Бюджет не выше 450 000 ₽ | Сборщик требований | Копирайтер
F2 | Срок до 15 июня | Сборщик требований | Копирайтер
F3 | Цены указывать с НДС | Сборщик требований | Копирайтер
F4 | Не упоминать конкурента «Контур» | Сборщик требований | Копирайтер, Проверяющий
Для каждого факта определи статус по истории переписки:
- OK: факт доставлен адресату и отражён в его работе
- UNCONSUMED: факт доставлен, но адресат его не использовал
- ABSENT: факт нигде не появлялся
- MISROUTED: факт ушёл не тому, кому нужен
Если несколько дыр сразу — работай с самой ранней в цепочке.
Подбирай ремонт строго по типу дыры:
- UNCONSUMED → INTEGRATE: вставь факт в исходящее сообщение адресату
- ABSENT → ASK: задай отправителю один точный вопрос по этому факту
- MISROUTED → INTEGRATE: перешли факт нужному адресату
Запрещено: ASK по факту, который уже доставлен (это отвлекает получателя).
Запрещено: INTEGRATE для факта, которого в переписке не было.
Вмешивайся только если одновременно:
1. Пропущенный факт есть в списке обязательных.
2. Его потеря меняет результат (бюджет, срок, запрет — да; тон и мелкие формулировки — нет).
3. Подходящий ремонт из существует.
Иначе — верни статус FORWARD и перешли сообщение без изменений.
После ремонта перепроверь: факт теперь есть в сообщении адресату?
Остальные факты остались на месте? Ничего лишнего не переписано?
Если «да» — статус COMMIT и исправленное сообщение.
Если «нет» или сомневаешься — статус ROLLBACK и исходное сообщение.
Результат: Модель выдаст таблицу по четырём фактам со статусами и решением по каждому. Дальше будет один из трёх вердиктов: переслать как есть, исправить и отправить, либо откатиться к оригиналу. Если пропал только малозначимый нюанс, она должна пересылать без правок. Если потерян срок или бюджет, она вставит факт в сообщение копирайтеру и перепроверит весь список.
Почему это работает
Слабость LLM. Агент, получивший неполную передачу, всё равно выдаёт правдоподобный ответ. Снаружи не видно, что именно потерялось. Попытка «улучшить всё» («переспроси», «перепроверь», «доработай») тоже ломается. Модель не знает, что дырой было, а что нормой, и портит рабочие куски.
Сильная сторона LLM. Сверять сообщение со списком заранее заданных фактов модель умеет хорошо, это простая сверка. В исследовании единый проход по графу зависимостей дал диагностику на уровне многошаговых цепочек, но с затратами на 32–42% меньше.
Как метод использует это. Он превращает расплывчатое «что-то пошло не так» в конкретную дыру с типом. Тип определяет, какой ремонт допустим. Ворота отсекают лишнее вмешательство, а проверка с откатом не даёт ремонту испортить рабочее.
Рычаги управления: - Список обязательных фактов (контракт) → короче список, меньше шума. Включайте только то, без чего результат ломается. - Условие «Gate» → строже условие, реже вмешательство и дешевле. Мягче условие, больше ремонтов и выше риск навредить. - Таблица «тип дыры → ремонт» → пополняйте её по своим логам: какой ремонт у вас реально помогал. - Вердикт ROLLBACK → если не уверен, отправь оригинал. Это страховка от «лечения хуже болезни».
Шаблон промпта
Ты — контролёр передач между агентами в задаче: {задача}.
Ты не выполняешь работу сам. Ты проверяешь, дошли ли обязательные факты
до нужного агента, и вмешиваешься только когда это необходимо.
Обязательные факты (id | суть | кто производит | кому нужен):
{список_фактов}
Для каждого факта определи статус по истории переписки:
- OK: доставлен адресату и отражён в его работе
- UNCONSUMED: доставлен, но не использован
- ABSENT: нигде не появлялся
- MISROUTED: ушёл не тому, кому нужен
Если дыр несколько — работай с самой ранней в цепочке.
Подбирай ремонт строго по типу дыры:
- UNCONSUMED → INTEGRATE: вставь факт в исходящее сообщение
- ABSENT → ASK: задай отправителю один точный вопрос
- MISROUTED → INTEGRATE: перешли факт нужному адресату
- {другие_правила}
Запрещено: ASK по факту, который уже доставлен.
Запрещено: INTEGRATE для факта, которого не было в переписке.
Вмешивайся только если пропущенный факт обязателен,
его потеря меняет итог, и подходящий ремонт существует.
Иначе верни FORWARD и перешли сообщение без изменений.
После ремонта проверь: целевой факт на месте, остальные факты не тронуты.
Да → COMMIT и исправленное сообщение.
Нет или сомнение → ROLLBACK и исходное сообщение.
{сообщение_от_предыдущего_агента}
{история_переписки}
Что подставлять: {задача} — что делает цепочка. {список_фактов} — 3–8 обязательных пунктов с владельцем и адресатом. {другие_правила} — свои пары «тип дыры → ремонт», если нашли их по опыту. {сообщение_от_предыдущего_агента} и {история_переписки} — то, что контролёр проверяет на этой передаче.
🚀 Быстрый старт — вставь в чат:
Вот шаблон контролёра передач между агентами (BRIDGE). Адаптируй под мою задачу: [опиши свою цепочку агентов и что они передают друг другу].
Задавай вопросы, чтобы заполнить поля.
[вставить шаблон выше]
LLM спросит, какие агенты есть в цепочке, что и кому они передают и какие факты нельзя терять. Это нужно, чтобы собрать «контракт»: без явного списка обязательных фактов нельзя отличить настоящую дыру от безобидного пропуска. Остальное она возьмёт из шаблона.
Ограничения
⚠️ Полный метод требует кода: граф зависимостей, ворота по статистике, снимки состояния и откат выполняет программа-контроллер, а не промпт. Промптом можно воспроизвести только идею и диагностику, а не саму систему.
⚠️ Ворота в промпте слабее, чем по статистике: в исследовании «решение самой LLM, вмешиваться или нет» дало заметно меньше пользы, чем решение по накопленной статистике офлайн-прогонов. Промптовая версия ворот — это приближение.
⚠️ Статистика привязана к модели: таблица «что помогает» переносилась между разными задачами, но не переносилась между разными моделями. Сменили модель — калибруйте заново.
⚠️ Нужны видимые следы: метод опирается на то, что поломка видна в переписке и логах. Если сбой целиком внутри «чёрного ящика» одного агента, он бессилен.
⚠️ Небольшие выборки: часть выводов по отдельным компонентам держится на малом числе прогонов, и значимость там пограничная. Направление убедительное, точные цифры хрупкие.
Как исследовали
Идея была простой: перестать гадать, помогает ли вмешательство, и измерить это на повторах. Сначала команда взяла записи прошлых прогонов мультиагентных систем и искусственно ломала в них передачи: терялся факт, адресат игнорировал данные, сообщение уходило не туда. Из каждой точки поломки запускали два продолжения. Одно шло как есть, второе с ремонтом. Итог оценивали тестами, а не LLM-судьёй. Так получилась таблица: ремонт X при поломке Y помогает, вредит или ничего не меняет.
Потом метод проверили на двух бенчмарках с двумя моделями. Сравнивали с Self-Refine, AgentAsk, MOC и VeriMAP. На SILO-BENCH успех вырос с 63,3% до 75,6% на одной модели и с 68,9% до 77,8% на другой. На TeamBench прирост составил до 11,1 пункта. Таблицу, собранную на синтетических данных, применили к TeamBench без доводки, и она сработала. Дополнительные токены — от 2% до 5%. Диагностику отдельно проверили на 562 реальных трассах MAST. Там метод показал около 70% F1 за один вызов вместо двухшаговых цепочек.
Самые полезные для практики данные в абляциях. Если вмешиваться всегда, успех падает до 56,7%, то есть на 6,6 пункта ниже, чем вообще без помощи. Столько же теряется без отката. Замена графа плоским чеклистом даёт 68,9%. Замена статистики на самооценку модели даёт 70,0%. Отдельно показано, что подбор ремонта под тип дыры критичен. Вставка недостающего контекста исправляла около половины случаев «доставлено, но не использовано», но не давала ничего при «факта нет совсем». Лишний вопрос по уже доставленному вредил. Удивило, что ломаются не только слабые вмешательства. Любое неточное «лечение» тоже ломает.
Адаптации и экстраполяции
🔧 Техника: правила вмешательства в файл инструкций агента → меньше «лишней суеты».
Это не метод из статьи, а перенос его выводов в AGENTS.md / CLAUDE.md. Эффект такой формулировки в статье не измерялся, проверьте на своих задачах.
## Правила передачи работы между агентами
- В начале задачи составь список обязательных фактов: что, кто производит, кому нужно.
- При каждой передаче сверяй сообщение со списком. Не «улучшай» сообщение, если обязательные факты на месте.
- Пропал факт, которого не было в переписке → задай один точный вопрос его владельцу.
- Факт был доставлен, но не использован → вставь его в сообщение получателю. Не переспрашивай.
- Никогда не переспрашивай то, что уже передано.
- После правки проверь: нужный факт появился, остальные не изменились. Не уверен — отправь исходное сообщение.
Ресурсы
- Работа: BRIDGE: Selective Boundary Repair with Dependency Graph Evidence in Multi-Agent Systems
- Авторы: Encheng Su, Pengze Li, Ziheng Hua и др. Университет науки и технологий Китая (USTC), Фуданьский университет, Шанхайская лаборатория искусственного интеллекта и другие.
- Бенчмарки: SILO-BENCH, TeamBench, MAST (таксономия сбоев мультиагентных систем, Cemri et al., 2025).
- Сравнивались с: AgentAsk, Self-Refine, MOC, VeriMAP.