Материал подготовлен автоматически по первоисточникам: ссылки на них — в конце статьи.
Полезные находки одного LLM-агента теперь можно передавать другому ровно в момент, когда они нужны, а не заранее складывать в общую память. На WebShop метод Ask on Demand сократил относительный расход токенов с 1,00 до 0,92 и одновременно улучшил обе метрики качества, хотя препринт пока не рецензировали, а числа получили сами авторы. Для архитектуры параллельных агентов это аргумент в пользу адресных запросов вместо постоянного обмена историями.
Запрос привязан к решению, которое агент принимает сейчас
Работу подготовили специалисты Beihang University, China Telecom Artificial Intelligence Technology и Tsinghua University. Их метод AOD рассчитан на команду агентов, которые решают одну задачу в отдельных средах: проверяют разные товары, вызывают разные методы API или пробуют разные последовательности действий.
Обычная общая память требует заранее решить, какую часть истории сохранить и как её сократить. Полезная деталь при этом может исчезнуть, потому что её значение станет понятно только позже. Полный обмен историями сохраняет детали, но раздувает контекст и подталкивает агентов повторять один маршрут.
AOD добавляет агенту инструмент ask_peer. Запрос содержит три части: какого факта не хватает, что агент уже знает и какое решение зависит от ответа. Сам агент формулирует вопрос, но перед отправкой его проверяет отдельная модель-шлюз Qwen3-0.6B.
Шлюз видит только запрос и локальную историю отправителя. Если он разрешает обращение, система ищет подходящие фрагменты в завершённых записях других агентов через ранжирование BM25, выбирает одного собеседника и просит его составить короткий ответ. Ответ опирается на найденные фрагменты, цитирует их и не запускает новых действий в среде.
Такой порядок сохраняет независимость маршрутов. Агенты не получают постоянную сводку чужих действий, а выбранный собеседник не прерывает свою работу. Если подходящей записи нет, система возвращает сообщение о недостатке сведений.
Шлюз учится на последствиях каждого обращения
Разрешать все запросы невыгодно: даже содержательный ответ может не изменить итог задачи. Поэтому шлюз обучали не по оценке формулировки вопроса, а по результату дальнейшей работы команды.
Для каждого сохранённого состояния запускали парные продолжения. В одном и тот же запрос разрешали, в другом отклоняли; затем сравнивали итоговый результат команды и расход токенов. Если обращение улучшало результат, оно получало метку APPROVE. При одинаковом результате предпочтение отдавали варианту с меньшими затратами.
На AppWorld обученный шлюз повысил долю выполненных целей на 5,28 процентного пункта по сравнению с исходной моделью без такого обучения. Выбор собеседника по релевантным записям вместо случайного агента добавил 8,33 пункта к доле полностью завершённых заданий.
Генерировать отдельный ответ полезно не всегда. На одной из метрик AppWorld прямой возврат найденных BM25 фрагментов оказался лучше, чем пересказ выбранного агента. Это важная деталь для реализации: дополнительная генерация может упростить использование свидетельств, но не гарантирует прирост на каждой метрике.
Что менять в архитектуре агентной команды
Работа меняет планы команд, которые уже запускают несколько агентов параллельно. Вместо общей сводки после каждого шага стоит хранить полные локальные записи, индексировать завершённые фрагменты и открывать доступ к ним через структурированный запрос.
- Отделить вопрос от разрешения. Основная модель решает, что спросить, а дешёвый шлюз определяет, стоит ли выполнять запрос.
- Сначала возвращать свидетельства. Поиск по необработанным записям проще проверить, чем свободный пересказ всей истории. Генерацию ответа можно добавить там, где агенту трудно применить найденные фрагменты напрямую.
- Обучать шлюз на собственных задачах. Ценность обращения зависит от инструментов, среды и правила выбора финального результата. В работе для одной обучающей точки требовалось от пяти до двадцати парных продолжений, поэтому сбор таких меток сам по себе расходует вычисления.
Метод проверяли на AppWorld с межсервисными сценариями и на WebShop с поиском товаров. Основной разбор проводили с Qwen3.5-35B-A3B, а размер команды меняли от трёх до девяти агентов; шлюз при расширении команды не переобучали. Финальный ответ выбирали из траекторий по уверенности, которую агенты назначали себе сами.
Эти условия очерчивают область применения результата. AOD отвечает на вопрос, как обмениваться находками при параллельном исследовании одной задачи, но не показывает преимущества для последовательного процесса с одним агентом. Если параллельные ветки уже есть, адресный запрос можно внедрять как отдельный слой, не меняя основную модель и её инструменты.
Источники
Похоже на вашу задачу?
Расскажите, что собираете. За полчаса разложим на этапы и назовём сроки — это бесплатно и ни к чему не обязывает.
