Материал подготовлен автоматически по первоисточникам: ссылки на них — в конце статьи.
MCP-агента научили успешнее решать длинные задачи с поиском серверов и вызовом нескольких инструментов. У MCPDisCo доля выполненных задач выросла с 15,79% до 26,32%, но препринт не проходил рецензирование, а все числа получили сами авторы. Для команд, которые дообучают собственных агентов, работа предлагает способ не смешивать сигналы за качество плана и правильность вызова API.
Почему общая награда сталкивает рассуждение с вызовом инструментов
Model Context Protocol (MCP) стандартизирует подключение внешних сервисов к агенту. В длинной задаче модели недостаточно сформировать корректный JSON: ей нужно найти подходящий сервер, выбрать инструмент, обработать ответ и решить, продолжать работу или завершить её.
Обычно обучение с подкреплением сводит результат к одной награде и применяет её ко всей сгенерированной последовательности. Тогда удачный вызов инструмента повышает вероятность не только токенов действия, но и предшествующего рассуждения. Оценка хорошего плана, в свою очередь, влияет на токены вызова, хотя он мог содержать неверный сервер или аргументы.
Авторы называют такой конфликт «качелями»: один показатель улучшается, пока другой ухудшается. Это не означает, что рассуждение и инструменты несовместимы. Проблема возникает из-за того, что разные задачи получают общий обучающий сигнал и меняют одни и те же параметры модели.
MCPDisCo сначала разделяет токены на рассуждение и внешние действия. Первые получают награду за связь с запросом и последовательность текста. Вторые — за формат, выбор сервера и инструмента, аргументы вызова и итоговый ответ. Использованная оценка рассуждения проверяет ключевые слова и смысловую близость соседних предложений, поэтому служит дешёвым ориентиром, а не доказательством логической правильности.
Одного разделения наград недостаточно: обе части всё равно обновляют общую модель. Если их градиенты направлены друг против друга, MCPDisCo удаляет конфликтующую составляющую из обоих обновлений. Ни рассуждение, ни действие не становится главным; модель делает шаг, который не должен локально ухудшать вторую цель ради первой.
Эксперименты охватили 70 реальных MCP-серверов, 527 инструментов и шесть предметных областей. Метод сравнили с исходной моделью, общей наградой, одним только разделением по токенам и полным вариантом с коррекцией градиентов. Перенос проверяли на MCP-Atlas с другим набором серверов и на общих агентных задачах GAIA.
Агент заменил лишний текст дополнительными действиями
Рост доли выполненных задач не потребовал длиннее описывать план. Средняя цепочка рассуждений сократилась на 5,6%, хотя отдельного штрафа за её длину в награде не было.
Одновременно средняя цепочка вызовов инструментов выросла с 8,47 до 13,31. Модель стала тратить меньше токенов на повторение плана и чаще переходить к действиям, которые меняют состояние задачи. В большинстве предметных областей успех рос при сокращении рассуждения, поэтому общий результат не сводится к одному удачному типу задач.
На MCP-Atlas полный метод обошёл исходную модель и две модели, дообученные для обычного вызова инструментов. На GAIA он также превзошёл эти специализированные модели на первых двух уровнях сложности, однако относительно исходной модели улучшился только на самом простом уровне. Обучение на MCP помогает переносить маршрутизацию и многошаговую работу, но пока не показывает стабильного преимущества на более сложных общих задачах.
Диагностика градиентов обнаружила периодические конфликты между целями, а разделение по токенам уменьшило самые заметные отклонения. При этом добавление коррекции не снижало накопленный конфликт равномерно на всём протяжении обучения и не дало лучшего конечного показателя этой диагностики. Результаты подтверждают пользу полного метода по качеству задач, но не доказывают, что он полностью устраняет «качели».
Менять интеграцию MCP не нужно, план обучения — стоит
Работа не требует перестраивать серверы или отказываться от стандартного MCP-клиента. Она касается слоя обучения агента: журнал взаимодействия должен явно отделять внутреннее рассуждение от маршрутизации, вызовов и завершения задачи. Без такой разметки применить раздельные награды не получится.
Для команды, которая только подключает готовую модель к нескольким инструментам, MCPDisCo пока не меняет архитектурный выбор. Эффект показан после дообучения на длинных траекториях с реальными серверами, а не как приём для подсказки модели во время выполнения запроса.
Если команда собирает собственные данные и обучает агента, практический вывод уже применим: нельзя оценивать весь ответ одной суммой баллов. Стоит отдельно отслеживать качество плана, корректность маршрута, формат аргументов и успешность выполнения, а затем проверять, не улучшается ли один показатель за счёт другого.
Замеры на реальных серверах проводились по одному запуску и зависят от изменяющейся внешней инфраструктуры. Поэтому заявленный уровень успеха нельзя напрямую переносить на другой набор сервисов, но сам подход можно проверить на внутренних журналах и оценщиках команды.
Источники
Похоже на вашу задачу?
Расскажите, что собираете. За полчаса разложим на этапы и назовём сроки — это бесплатно и ни к чему не обязывает.
