Материал подготовлен автоматически по первоисточникам: ссылки на них — в конце статьи.
Агент научился надёжнее выбирать подходящий инструмент из большой библиотеки, когда несколько вариантов выглядят одинаково уместными. В препринте Cornell University и Megagon Labs, который не прошёл рецензирование и содержит замеры самих авторов, BRIA набрала на MCP-Atlas 89,77 балла против 75,40 у сильнейшего базового метода. Для архитектуры агентов это означает, что неудачные пробные вызовы можно отделить от основного контекста, а не заставлять модель рассуждать поверх накопленных ошибок.
Почему общая цепочка мешает выбирать инструменты
LLM-агент редко может получить описания всей библиотеки сразу. Если передать ему слишком много инструментов, вырастет контекст и усложнится выбор. Поэтому система сначала ищет несколько подходящих вариантов, а затем предоставляет их модели.
Проблема возникает, когда по описанию нельзя понять, какой вариант содержит нужные данные. Например, сведения о покупке могут находиться в MongoDB, Airtable или базе Notion. Агенту приходится выполнить запросы и сравнить ответы.
Обычный адаптивный поиск делает это последовательно в одной цепочке действий. Первый правдоподобный, но бесполезный результат остаётся в контексте. Модель может прекратить поиск раньше времени или опираться на ошибочную попытку в следующих шагах.
BRIA создаёт контрольную точку и запускает отдельную ветку для каждого кандидата. Ветка получает исходную задачу, цель проверки, доступные инструменты и результаты, накопленные до разделения. Действия соседних веток она не видит.
Внутри ветки агент может искать дополнительные инструменты и выполнять их. Чтобы считать проверку завершённой, ветка должна сослаться хотя бы на один успешный результат, который получила после разделения. Контроллер проверяет происхождение этого результата, но не решает за модель, отвечает ли он на вопрос.
После проверок основной агент временно видит вызовы, ошибки, ответы и выводы всех веток. Он выбирает полезные результаты, а контроллер переносит в рабочий контекст только принятые ветки. Остальные сохраняются в журнале, но больше не влияют на рассуждение и выполнение.
Ветвление дало до 14,37 процентного пункта
Методы сравнили в общей библиотеке из 1897 инструментов. На MCP-Atlas средний балл покрытия утверждений вырос с 75,40 у MCP-Zero до 89,77 у BRIA. Эта метрика показывает, какую часть фактов, необходимых для ответа, подтвердил агент.
На PlanBench-XL BRIA решала не меньше задач, чем MCP-Zero, и расходовала менее половины входных токенов. Статический поиск, который один раз выдавал большой набор инструментов перед началом задачи, уступил адаптивному подходу: дополнительные описания занимали контекст, но не гарантировали доступ к нужной цепочке вызовов.
Эффект появился не только от ветвления. BRIA повторяет поиск по мере выполнения задачи: модель формулирует, какой возможности ей не хватает, какие входные данные уже есть и какой результат нужен. Так агент может найти инструмент для позднего шага, даже если его описание слабо связано с исходным запросом.
Проверка охватила PlanBench-XL и MCP-Atlas, три семейства моделей и несколько статических и адаптивных методов. Основные сравнения провели на выборках по 75 задач из каждого набора, а тенденцию отдельно проверили на полных наборах с GPT-6-Luna. PlanBench-XL моделирует длинные цепочки в розничной торговле с отвлекающими инструментами, а MCP-Atlas использует реальные схемы серверов и только операции чтения.
Когда ветвление стоит добавить в архитектуру агента
Работа меняет планы команд, у которых агент выбирает между несколькими источниками одной возможности: базами данных, репозиториями, поисковыми сервисами или сходными API. В такой системе одного поиска по описаниям недостаточно — правильный источник проявляется только после выполнения запроса.
BRIA не требует дообучать модель. Основная работа ложится на контроллер: он создаёт контрольные точки, разделяет контексты и состояние выполнения, учитывает общий бюджет, проверяет принадлежность доказательств и собирает продолжение из принятых веток. Простого копирования истории сообщений недостаточно, если инструменты хранят состояние между вызовами.
Практический шаблон можно внедрять отдельно от конкретной LLM: обнаружить несколько кандидатов, проверить каждый в изоляции, показать модели результаты для сравнения и перенести дальше только выбранные. В журнале при этом остаётся полный след для разбора ошибок, хотя рабочий контекст от неудачных попыток очищается.
Проверенные ветки использовали только инструменты, которые не меняют внешнее состояние. Для оплаты, публикации, удаления данных или оформления заказа понадобятся изолированная среда либо откат непринятых действий. Поэтому ближайшее применение метода — агенты, которые читают и сопоставляют данные; перенос на операции с побочными эффектами потребует дополнительного слоя безопасности.
Источники
Похоже на вашу задачу?
Расскажите, что собираете. За полчаса разложим на этапы и назовём сроки — это бесплатно и ни к чему не обязывает.
