TL;DR
BRIA — схема работы агента, в которой каждого кандидата-источника проверяют в отдельной изолированной ветке. Ветка сама ищет инструменты и запускает их. Главный агент потом смотрит на трассу выполнения (какие вызовы, с какими аргументами, что вернулось) и забирает в свой контекст только полезные ветки. Остальные в рабочий контекст не попадают.
Типичная боль: у задачи несколько похожих источников. «Данные по лидам» могут лежать в MongoDB, в Notion или в Airtable, и по описаниям не понять, где именно. Обычный агент пробует их по очереди в одной цепочке. Либо сдаётся после первой неудачи, решив, что нужного инструмента нет. Либо тащит все провальные попытки в контекст, и они сбивают дальнейшие рассуждения. В одном из тестов обычный агент провалил 18 задач. В 15 из них он заявил, что цепочки нет, хотя все нужные инструменты ему выдали.
BRIA делает три вещи. Ветвление: каждый кандидат исследуется отдельно и не видит соседей. Проверка: главный агент читает доказательства, а не готовые выводы. Выборочное принятие: в продолжение задачи идёт только то, что подтверждено выполнением. Чем больше инструментов и чем сильнее они похожи, тем заметнее выигрыш. При этом схема тратила меньше токенов, чем сильный конкурент.
Схема метода
ШАГ 0: Агент работает как обычно, подтягивает инструменты по мере нужды
(описывает потребность: цель, входы, нужный выход, область)
ШАГ 1: ЧЕКПОИНТ — если ≥2 конкретных кандидата на ОДНУ потребность
→ фиксируем: цель проверки, список кандидатов, успешные наблюдения до развилки
ШАГ 2: BRANCH — на каждого кандидата своя изолированная ветка
→ ветка видит только свою историю; сама ищет и запускает инструменты (только чтение)
→ итог: вывод + цитата успешного наблюдения (иначе ветка «не разрешена»)
ШАГ 3: INSPECT — главный агент читает временную сводку:
статус, трасса вызовов, вывод, доказательства
→ проверяет трассу, а не верит результату на слово
ШАГ 4: ADOPT — берёт одну, несколько или НИ ОДНОЙ ветки
→ в контекст идут только принятые; остальное — в архив, на рассуждения не влияет
ШАГ 5: Задача продолжается; при новой развилке — новый чекпоинт
В оригинале это делает контроллер (программа вокруг модели). Шаги 0–5 выполняются разными вызовами модели, а не одним промптом.
Пример применения
Задача: Вы настроили агента (Claude Code или похожего) с подключёнными MCP-серверами: Битрикс24, amoCRM, Google Таблицы, Яндекс Метрика. Просите: «Собери итоги по лидам за III квартал и отправь команде». Где лежат нужные лиды, неизвестно: часть сделок могла остаться в старой amoCRM, часть уехала в Битрикс24. Это сильная зона метода: несколько правдоподобных источников и нужен только подходящий.
Промпт:
Собери итоги по лидам за III квартал и подготовь сообщение для отдела продаж.
Правила работы с источниками (Branch–Inspect–Adopt):
1. Если для одной потребности («где лежат лиды Q3?») есть ≥2 правдоподобных
источника — НЕ пробуй их по очереди в основном диалоге. Открой чекпоинт:
запиши цель проверки, список кандидатов (Битрикс24, amoCRM, Google Таблицы)
и что уже успешно выяснено.
2. На каждого кандидата запусти отдельного субагента. Ему передай:
исходную задачу, цель проверки, ЕГО кандидата. Не передавай ему
мои рассуждения и результаты других субагентов. Он работает
только в режиме чтения. Его ответ: вывод + цитата конкретного
успешного вызова, который это подтверждает. Нет такой цитаты —
статус «не разрешено».
3. Когда все вернутся — покажи мне сводную таблицу: кандидат | статус |
какие вызовы делал | вывод | доказательство. Проверяй трассу,
а не только вывод: одинаковые результаты могут быть из неполных запросов.
4. Реши, какие ветки принять: одну, несколько или ни одной. В дальнейшую
работу бери данные только из принятых веток. Остальное не используй
и не цитируй. Если принял не всё — объясни почему.
5. Если ни одна ветка не дала доказательства — скажи прямо, что источник
не найден, и предложи следующие кандидаты. Не придумывай данные.
Если для задачи нужны данные ИЗ ВСЕХ источников (например, суммировать лиды
по всем системам) — ветвление не нужно, работай обычным порядком.
Результат: Агент сначала объявит чекпоинт и перечислит кандидатов. Затем он запустит отдельные проверки по каждой системе и выдаст таблицу сравнения: статус, вызовы, вывод, цитата доказательства. Дальше он назовёт, какие источники принял, а какие отбросил и почему. Итоговый отчёт для команды будет собран только из принятых данных. Провальные попытки в основной диалог не попадут.
Почему это работает
Слабость: общий контекст. Когда агент пробует кандидатов один за другим в одной цепочке, неудача остаётся в контексте. Она либо толкает его сдаться («инструмента нет»), либо подкрашивает дальнейшие рассуждения. Плюс контекст пухнет, а счёт за токены растёт.
Сильная сторона: модель хорошо читает доказательства. Дай ей готовую трассу (вызовы, аргументы, результаты, ошибки) — она сравнит кандидатов и отличит «нашёл данные» от «получил пустой ответ». Изолированные ветки не влияют друг на друга, поэтому каждая оценка честная. В статье 87% веток приходили к выводу, опирающемуся на их собственные успешные вызовы.
Метод соединяет одно с другим. Исследование разнесено по веткам, а решение принимается в одном месте, по сжатой сводке. В основной контекст попадает только принятое. Без шага проверки (когда в контекст вставляли все ветки подряд) стало и хуже, и дороже: при той же задаче входных токенов уходило заметно больше.
Рычаги управления: - Порог открытия чекпоинта (≥2 кандидата на одну потребность) → подними, если хочешь меньше ветвлений и экономии токенов. - Требование цитаты-доказательства → без него ветка считается «не разрешённой»; это защита от выдуманных выводов. - Правило «принять одну / несколько / ни одной» → разреши «ни одной», чтобы агент не придумывал результат. - Режим только чтения в ветках → в оригинале ветки не должны ничего менять во внешней системе. Не ослабляй это правило. - Повторный запрос на поиск → если первый поиск инструментов не дал нужного, разреши агенту повторить тот же запрос и получить следующих по рейтингу, ещё не виденных кандидатов.
Шаблон промпта
Оригинал — программа-контроллер. Ниже текстовая версия тех же правил для системной инструкции агента или файла вроде CLAUDE.md. Исходные промпты статьи находятся в её приложении и в нашем фрагменте не приведены.
Ты — главный агент по задаче: {задача}.
Ты не видишь все инструменты сразу. Подтягивай их по мере нужды.
Когда не хватает возможности, опиши её в четырёх полях:
- цель: {что нужно получить}
- доступные входы: {что уже известно}
- нужный выход: {в каком виде нужен результат}
- область: {домен, система}
Если подходящих инструментов не нашлось — переформулируй запрос ИЛИ повтори его и
возьми следующих ещё не просмотренных кандидатов.
Если вызов упал из-за отсутствия входных данных — найди, чем их получить, и повтори.
Открывай чекпоинт, когда ≥2 конкретных кандидата могут закрыть ОДНУ и ту же потребность,
и понять, какой из них нужен, можно только выполнив инструмент.
Не открывай, если нужны результаты от ВСЕХ кандидатов или кандидат один.
Кандидаты — это альтернативные ИСТОЧНИКИ, а не альтернативные планы всей задачи.
Зафиксируй: цель проверки, список кандидатов, успешные наблюдения до развилки.
Для каждого кандидата запусти отдельную изолированную проверку (субагент / отдельный чат).
Передай ей: исходную задачу, цель проверки, ЕГО кандидата, список доступных инструментов,
запись успешных вызовов до развилки (аргументы, результаты, ошибки).
НЕ передавай свои рассуждения и результаты других веток.
Ветка может сама искать инструменты. Только режим чтения.
Ответ ветки: вывод + цитата хотя бы одного успешного вызова, сделанного ЭТОЙ веткой.
Нет цитаты — статус «не разрешено».
Когда все ветки закончили, составь сводку:
кандидат | статус | трасса (вызовы, аргументы, результаты, ошибки) | вывод | доказательство.
Проверяй трассу, а не только результат: похожие ответы могут быть из неполных запросов.
Реши: принять одну, несколько или ни одной ветки.
В дальнейшей работе используй ТОЛЬКО принятые наблюдения и инструменты.
Непринятое не цитируй и не используй в рассуждениях.
Принятие не гарантирует правильность — по-прежнему сверяй с задачей.
Если приняты все ветки, ветвление было лишним — отметь это.
Продолжай задачу от принятого контекста. Новая развилка — новый чекпоинт.
Что подставлять: {задача} — рабочая задача; {что нужно получить}, {что уже известно}, {в каком виде нужен результат}, {домен, система} — поля описания потребности. Их агент заполняет сам по ходу, вы задаёте только задачу.
🚀 Быстрый старт — вставь в чат:
Вот шаблон BRIA (Branch–Inspect–Adopt). Адаптируй под мою задачу: [твоя задача].
Задавай вопросы, чтобы заполнить поля.
[вставить шаблон выше]
LLM спросит, какие системы и инструменты подключены, где вероятно лежат нужные данные и что считать доказательством. Это нужно, чтобы она могла определить кандидатов и написать правила чекпоинта. Она возьмёт структуру из шаблона и подстроит под вашу среду (чат, Claude Code, Cursor).
Ограничения
⚠️ Нужны результаты от всех кандидатов: если надо собрать данные из каждого источника (координаты нескольких мест, цены на несколько дат), агент принимает все ветки. Тогда ветвление только добавляет расходы, выбора нет.
⚠️ Нужна обвязка: в статье изоляция, архив и контроль состояния сделаны кодом-контроллером. В чате или агенте с субагентами можно воспроизвести механику по тексту, но жёсткой изоляции и проверки происхождения доказательств вы не получите. Текстовая версия выше — наш перенос идеи, а не проверенный авторами метод.
⚠️ Принятие ≠ правильность: авторы прямо пишут, что принятие ветки не подтверждает смысловую правильность. Контроллер проверяет только, что цитируемое наблюдение принадлежит этой ветке, но не отвечает ли оно на вопрос.
⚠️ Только чтение: в ветках используются инструменты, которые ничего не меняют во внешнем мире. Для действий с побочными эффектами (отправка, запись, удаление) схема в таком виде не описана.
⚠️ Узкая выборка проверки: основные сравнения сделаны на 75 задачах из каждого теста, на полном наборе повторена проверка на одной модели. Размер выигрыша сильно разный по моделям: у одной огромный, у других скромный.
⚠️ Ветвление не вместо хорошего поиска: результат во многом зависит от того, попал ли нужный инструмент в видимый список. В задачах, где полного рабочего маршрута агент вообще не увидел, все методы почти не справлялись.
Как исследовали
Идея была простой: если несколько инструментов выглядят подходящими, нужно запустить каждый отдельно и сравнить результаты, а не гадать по описанию. Авторы свалили в общую кучу 1897 инструментов из двух тестов. Первый — PlanBench-XL (327 синтетических задач из ретейла с «подставными» инструментами-двойниками). Второй — MCP-Atlas (500 задач на реальных MCP-серверах; использовали только инструменты, не меняющие данные).
Сравнивали BRIA с однократным поиском топ-k инструментов (k = 50, 250, 500) и с тремя адаптивными методами: MCP-Zero, FitText, ToolGate. Брали три модели из разных семейств. Для скорости использовали 75 задач из каждого теста, а затем перепроверили на полном наборе одной моделью.
Результат: BRIA получила лучший или равный балл во всех шести комбинациях «модель × тест». Самый сильный прирост — на MCP-Atlas с Gemini: 89,77 против 75,40 у MCP-Zero. На PlanBench-XL она была не хуже MCP-Zero, потратив меньше половины входных токенов. FitText часто «заискивался» (исчерпывал бюджет поиска в 52–68 из 75 запусков). ToolGate путал инструменты с одинаковыми типами входов и выходов.
Самое любопытное. Когда агенту сразу выдали нужные инструменты и добавили «подставные», обычный агент упал с 76% до 48%. BRIA без поиска показала 88%, то есть лучше, чем агент, у которого вообще нет подставных инструментов. Разбор показал, что обычный агент часто останавливался раньше времени: делал вывод, что цепочки нет, хотя все нужные звенья были у него в руках. Ветвление заставляет проверить, а не сдаться.
Что дали отдельные части. Без шага проверки (все ветки подряд в контекст) результаты на MCP-Atlas падали, а затраты росли. Без повторного запроса за новыми инструментами успех на PlanBench-XL упал с 22,67% до 16,00%. Чекпоинт открывался примерно в четверти задач одного теста и в трети другого. В задачах «найти, в какой из нескольких баз лежит нужное» BRIA выигрывала у MCP-Zero 29 раз и проигрывала 13.
Практический вывод: изоляция и выборочное принятие помогают там, где нужно выбрать подходящее из правдоподобных. Где нужны все варианты, они бесполезны.
Адаптации и экстраполяции
🔧 Техника: добавить «ветку без доказательства не считается» → меньше выдуманных выводов
В правило ветки добавь: «Вывод без цитаты конкретного успешного вызова — недействителен. Не пиши "скорее всего"; пиши "не разрешено" и причину». Это перенос правила из статьи («разрешена» только с доказательством) на жёсткую формулировку для чата.
🔧 Техника: проверка трассы → поймать «одинаковые» результаты из неполных запросов
В блок
добавь: «Для каждой ветки отметь, какой объём данных реально прочитан (период, страницы, фильтры). Если запрос был неполным — отметь ограничение». Авторы заметили, что похожие результаты бывают из разных, в том числе неполных, выполнений.
Экстраполяция: ручная версия без агента. Если у вас обычный чат без инструментов, но три гипотезы («почему упали продажи: цена, поток или отдел продаж?»), разнесите их по трём отдельным чатам. В каждый дайте одну гипотезу и одни и те же данные. Попросите вывод плюс цитаты из данных. В четвёртый чат отдайте только выжимки с цитатами и скажите принять одну, несколько или ни одной гипотезы. Это не метод из статьи, а перенос принципа «изолируй исследование, принимай выборочно» на другой материал. Мы его не проверяли.
Ресурсы
- Статья: Explore Separately, Adopt Selectively: Execution-Guided Tool Use over Large Tool Libraries.
- Авторы: Anna Mazhar (Cornell University; работа выполнена во время стажировки в Megagon Labs), Seiji Maekawa, Nikita Bhutani (Megagon Labs).
- Бенчмарки: PlanBench-XL, MCP-Atlas.
- Сравнивались: MCP-Zero (github.com/xfey/MCP-Zero), ToolGate (github.com/OceannTwT/ToolGate), FitText, Tree-Planner, ReAct.
- Модель эмбеддингов для поиска инструментов: Qwen3-Embedding-8B.