Агенты по-разному работают через MCP и CLI, а метод DART дал до +9 баллов

Когда ИИ-агент пользуется инструментами, он видит не «чистые» возможности, а их описание: либо как набор функций по протоколу MCP (Model Context Protocol, стандарт подключения инструментов к языковой модели), либо как команды в терминале, то есть CLI. Команда исследователей из ModalityDance (Zhenning Shi, Liang Pang, Yongqi Li) задала прямой вопрос: если возможности абсолютно одинаковые, а меняется только способ их показать модели, поведение агента изменится? Ответ: да, и сильно. Разошлись качество решения задач, расход токенов (единиц текста, за которые платят при работе с моделью) и даже то, как агент ошибается и выбирается из ошибок. Заодно авторы предложили метод DART, который поднял результаты во всех шести проверенных конфигурациях на величину до 9,0 балла.

Как сделать сравнение честным

Обычно MCP и CLI сравнивают «как есть». Но тогда непонятно, что именно повлияло на результат: сам интерфейс или то, что у одного инструменты богаче, а у другого реализованы иначе. Чтобы убрать эту путаницу, авторы построили стенд MICA (Matched Interface Comparison and Analysis, «сопоставление и анализ равных интерфейсов»).

Устроен он так:

• есть единый контракт семантических действий: список того, что агент вообще может сделать; • из этого контракта автоматически строятся две версии: MCP и CLI; • что бы агент ни выбрал, действие декодируется и уходит в один и тот же исполняющий код.

Получается, что под капотом возможности совпадают полностью. Различие остаётся только в «витрине»: как действия описаны, как их нужно записывать и как выглядит ответ среды. Тесты прогнали на шести моделях и в трёх интерактивных средах.

Где пути агента расходятся

Первый результат: производительность и стоимость взаимодействия различаются заметно. Причём дело не только в синтаксических опечатках, когда агент неверно записал вызов. Интерфейс влияет на то, какое действие агент выбирает по смыслу, как он проваливается и как восстанавливается после сбоя.

Чтобы найти источник чувствительности, исследователи использовали два приёма.

• Пробы с одинаковым состоянием. Агента ставили в одну и ту же ситуацию и меняли по отдельности три вещи: как представлены возможности, как записывается действие и как возвращается обратная связь. Так удалось увидеть, какая из трёх частей сильнее всего сбивает модель. • Парные естественные траектории. Одну и ту же задачу агент решал через MCP и через CLI. Из 2004 эпизодов структурное расхождение нашлось в 94,3%, то есть примерно в 1890. Ранние различия не гасились, а тянулись дальше: один неудачный шаг в начале менял весь остальной ход взаимодействия.

Вывод авторов: интерфейс входит в замкнутый контур принятия решений. Агент действует, получает ответ, решает снова, и форма ответа и записи влияет на каждый следующий шаг. Это не нейтральная обёртка вокруг модели.

DART: чинить запись команды, а не решение

Раз расхождение возникает на этапе «реализации» действия, именно там его можно исправлять. Метод DART (Decoupled Action Realization and Targeted Repair, «разделение реализации действия и точечная починка») делит работу на две части. Сначала агент определяет, что именно хочет сделать. Это семантическое решение проверяется и сохраняется. Затем отдельный шаг отвечает за то, как это решение записать на языке конкретного интерфейса, и при ошибках чинит только эту запись. Смысл выбранного действия не пересматривается.

Эффект по заявленным цифрам:

• балл в бенчмарках вырос во всех шести проверенных конфигурациях (модель плюс среда), максимум на 9,0 пункта; • стоимость MCP снизилась во всех трёх средах, максимум на 27,1 тыс. токенов на одну задачу.

Вторая цифра важна для бюджета. MCP-описания инструментов и ответы нередко многословны, а их приходится гонять через контекст на каждом шаге. Если часть работы не повторять, расход заметно падает.

Что из этого следует инженерам

Спор «MCP против CLI» в такой постановке теряет смысл: победителя вообще нельзя определить без контроля над тем, как реализован интерфейс. Одна и та же модель с одними и теми же инструментами может выглядеть сильнее или слабее в зависимости от формы подачи.

Практические выводы:

• при сравнении моделей и агентных фреймворков фиксируйте интерфейс и описывайте его в отчёте, иначе цифры нельзя сопоставлять; • сбои агента стоит разбирать по уровням: ошибся ли он в выборе действия или только в записи вызова; • если вы строите агента на MCP и платите за токены, имеет смысл отделить смысловое решение от его оформления и исправлять только оформление.

Ограничения тоже видны: исследование охватывает шесть моделей и три среды, так что переносить цифры на любой другой набор задач нужно осторожно. Код и страница проекта открыты (репозиторий ModalityDance/MICA на GitHub), так что результаты можно проверить на собственных агентах.