TL;DR
Исследование показывает, что упаковка инструмента сама меняет поведение агента. Одни и те же действия можно показать модели как именованные инструменты со схемой (MCP) или как команды с флагами (CLI). От этого меняются выбор действий, число сбоев, расход токенов и итоговый результат. В статье же предложен приём DART: выбор действия и его запись в формате инструмента разделены на два шага. Если вызов упал, а решение было верным, чинится только запись, а новое решение не выбирается.
Универсального победителя нет. У Qwen3-14B в ALFWorld MCP сильно проиграл CLI: 20 баллов против 57. В WebShop у той же модели MCP выиграл: 64 против 60. Токены шли так же вразнобой. Поэтому «MCP лучше» или «CLI лучше» — плохое общее правило. Всё зависит от модели и задачи. Расхождения возникают рано: почти в 94% парных прогонов траектории разошлись, обычно в начале. После первого расхождения история и состояние уже разные, и всё дальше идёт по другой дороге. Самым чувствительным местом оказалась запись вызова: формат, флаги, аргументы.
DART работает в два шага. Сначала модель выбирает операцию и аргументы в нейтральном виде, и это решение фиксируется. Потом она записывает его в нужный формат. Если запись упала с ошибкой, модель получает одну поправку: «то же действие, исправь только запись». Без такого разделения агент часто после ошибки передумывает всё решение целиком. В статье DART улучшил результат во всех шести проверенных связках «бенчмарк × интерфейс», а в MCP ещё и снизил расход токенов.
Схема метода
Диагностика (MICA)
ШАГ 1: Один набор возможностей → в двух упаковках (MCP и CLI)
ШАГ 2: Одинаковые модель, задача, бюджет, исполнение → сравнить результат и токены
ШАГ 3: Найти первый шаг, где траектории разошлись → что именно разошлось: выбор действия или его запись
Починка (DART)
ШАГ 1 (выбор): модель называет операцию + аргументы без привязки к формату → «обязательство»
ШАГ 2 (запись): модель записывает это обязательство в формате MCP или CLI
ШАГ 3 (ремонт): запись упала, а обязательство валидно → ОДНА поправка: меняется только запись
ШАГ 4 (выход): поправка не прошла → обычная повторная попытка
В статье шаги выполняет контроллер в коде. Одна и та же модель получает разные инструкции для каждой фазы.
Пример применения
Задача: Вы делаете агента для отдела продаж в Claude Code. Он заводит сделки в amoCRM через CLI-утилиту. Типичная беда: агент ошибся в формате даты в одном флаге. Получив ошибку, он вместо исправления даты начинает искать другого клиента, создаёт другую сделку или меняет весь план.
Промпт (фрагмент в CLAUDE.md или системный промпт агента):
Работа с командами CRM делится на два шага. Не смешивай их.
ШАГ 1. РЕШЕНИЕ.
Сначала сформулируй действие без синтаксиса:
- операция: создать_сделку
- аргументы: клиент = «ООО Ромашка», сумма = 350 000 ₽, дедлайн = 15 ноября
Проверь по задаче: это действительно нужное действие? Если да — решение зафиксировано.
ШАГ 2. ЗАПИСЬ.
Запиши зафиксированное решение командой CLI (флаги, формат дат, кавычки).
ЕСЛИ КОМАНДА УПАЛА С ОШИБКОЙ ФОРМАТА:
- Решение из шага 1 НЕ пересматривай.
- Не меняй операцию и значения аргументов.
- Исправь только запись: флаги, порядок, формат даты, экранирование.
- Сделай ровно одну такую поправку.
- Если и она не сработала — остановись и покажи мне: решение, команду, ошибку.
- Если ошибка говорит о бизнес-проблеме (клиент не найден, нет прав) — это не ошибка записи.
Тогда реши заново и объясни почему.
Результат: Агент перед вызовом коротко проговорит решение: операция и аргументы. Потом выдаст команду. При сбое формата он повторит то же действие с исправленным синтаксисом, а не начнёт новый план. Если поправка не помогла, он остановится и покажет три вещи: решение, команду и ошибку.
Почему это работает
Слабость. Интерфейс для модели — не нейтральная обёртка, а часть контекста, из которого она выбирает следующий шаг. Названия, схемы и формат ошибок подталкивают к разным действиям. В WebShop у Qwen3-14B из-за MCP сдвинулись доли действий: примерно на 6 пунктов больше click и на 6 меньше search. Первое расхождение запускает цепочку. История и состояние меняются, и дальше агент идёт другим путём.
Сильная сторона. Модель обычно правильно понимает, что надо сделать. Она спотыкается на том, как это записать. В статье запись дала самые большие локальные сдвиги: до 84 пунктов по частоте сбоев записи у отдельных связок. Сдвиг по сбоям записи не означает, что решение было плохим.
Как метод это использует. DART отделяет «что делать» от «как записать». Проверенное решение превращается в обязательство, и ошибка формата не заставляет агента его пересматривать. Без разделения ошибка записи легко превращается в смену стратегии. Так мелкая проблема синтаксиса портит всю траекторию.
Рычаги управления: - Число поправок (в статье одна) → увеличь до 2, если синтаксис сложный. Но тогда растёт риск зацикливания. - Что считается «ошибкой записи» → пропиши список явно (флаги, даты, кавычки). Всё остальное по умолчанию означает «решай заново». - Условие остановки → «покажи мне» подходит для критичных действий. Для рутины можно заменить на «пропусти и запиши в лог». - Фиксация решения → чем конкретнее поля (операция, аргументы), тем жёстче «обязательство».
Шаблон промпта
Работай с инструментом {название_инструмента} в два шага.
ШАГ 1. РЕШЕНИЕ (без синтаксиса)
Опиши действие так:
- операция: {одна из: список_операций}
- аргументы: {имя = значение, …}
Проверь по цели «{цель_задачи}»: действие правильное? Если да — оно зафиксировано как РЕШЕНИЕ.
ШАГ 2. ЗАПИСЬ
Запиши РЕШЕНИЕ в формате {MCP-вызов | CLI-команда}.
Формат: {пример_корректной_записи}
ЕСЛИ ВЫЗОВ УПАЛ:
1. Определи: это ошибка ЗАПИСИ ({типы_ошибок_записи}) или ошибка РЕШЕНИЯ ({типы_ошибок_решения})?
2. Если ЗАПИСИ: операцию и значения аргументов НЕ меняй. Исправь только форму.
Сделай ровно одну поправку.
3. Если поправка не помогла — {действие_при_неудаче}.
4. Если РЕШЕНИЯ: пересмотри решение и объясни, что изменилось.
Что подставлять:
- {название_инструмента} — ваша CRM, трекер, облачная CLI.
- {типы_ошибок_записи} — неверный флаг, формат даты, кавычки, порядок аргументов.
- {типы_ошибок_решения} — объект не найден, нет прав, конфликт состояния.
- {действие_при_неудаче} — остановиться и показать, записать в лог, спросить человека.
🚀 Быстрый старт — вставь в чат:
Вот шаблон двухшагового вызова инструмента (решение → запись → ремонт только записи).
Адаптируй под мою задачу: [опиши инструмент, как агент им пользуется, какие ошибки случаются].
Задавай вопросы, чтобы заполнить поля.
[вставить шаблон выше]
LLM спросит, какие операции доступны, как выглядит корректный вызов и какие ошибки бывают. Это нужно, чтобы разделить ошибки записи и ошибки решения. Это граница метода: чинить можно только первые.
Ограничения
⚠️ Это не готовый промпт, а перенос. В статье DART — контроллер в коде с отдельными промптами для каждой фазы. Они в приложениях, которых в тексте нет. Шаблон выше — текстовая версия принципа. В одном промпте модель может смешать шаги. Эффект такой версии авторы не проверяли.
⚠️ Игровые среды. Проверяли на симуляторах: домашние задачи (ALFWorld), покупки (WebShop), научные опыты (ScienceWorld). Это не рабочие CRM, код или документы.
⚠️ Модели. Большинство моделей малые (Qwen3 от 4B до 32B), плюс DeepSeek-v4-Flash и Gemini-2.5-Flash. На флагманских моделях картина может быть другой. Это видно и по таблице: у DeepSeek в ALFWorld разрыв между интерфейсами малый.
⚠️ DART проверен на одной модели. Только на Gemini-2.5-Flash, на шести связках. В доступной части текста величина эффекта не видна, виден только факт улучшения.
⚠️ Нет рецепта выбора. Статья не говорит, что выбрать: MCP или CLI. Она говорит, что это нужно проверять на своей модели и задаче.
Как исследовали
Главная проблема прежних сравнений MCP и CLI в том, что вместе с интерфейсом менялось всё остальное: набор инструментов, промпты, проверки. Победу нельзя было приписать упаковке. Авторы построили оба интерфейса из одного контракта действий. Модель, стартовое состояние, бюджет и исполнение были одинаковыми, менялось только то, как это показано модели. Тестировали шесть моделей на трёх средах.
Результат вышел разнонаправленным. У Qwen3-14B в ALFWorld MCP отстал от CLI на 36,6 балла (20,1 против 56,7) и потратил на 54,9 тыс. токенов больше. В WebShop тот же MCP выиграл по баллам и сэкономил 35 тыс. токенов. После ошибки у Qwen3-4B в WebShop повторная попытка принималась в 50% случаев при CLI и в 77% при MCP. Успех задачи после этого: 18% и 34%.
Затем авторы разложили интерфейс на три части: как показаны возможности, как записывается ответ и как приходит обратная связь. Части меняли по одной и в сочетаниях (схема 2×2×2). Самый большой эффект дала запись ответа. Части влияют не по отдельности: в одной связке тройное взаимодействие сдвинуло приём вызовов на 37,8 пункта. Из 2 004 парных прогонов 1 889 (94,3%) разошлись, чаще всего из-за разных выбранных действий, а на втором месте были различия в записи. Этот второй источник авторы и взяли в DART.
Адаптации и экстраполяции
💡 Адаптация для файла инструкций (AGENTS.md / CLAUDE.md). Статья этого не проверяла, это перенос принципа «чини запись, не решение»:
## Правило сбоев вызова Если команда или вызов инструмента упали из-за формата (флаг, дата, кавычки, JSON): повтори то же действие с исправленной записью. Не меняй цель и не выбирай другое действие. Если ошибка по существу (нет объекта, нет прав) — остановись и спроси.
🔧 Техника: свой мини-тест интерфейсов. Идея из MICA, упрощённая, вывод в статье не проверялся. Возьмите 10 типовых задач, прогоните агента с MCP-описанием и CLI-описанием. Сравните первые шаги: выбрал ли он то же действие? Первое расхождение, как показала статья, определяет всю траекторию. Если расходятся в основном выбор действий, нужно править описания инструментов. Если расходится только запись, помогает правило из шаблона выше.
Ресурсы
- Работа: Matched Capabilities, Different Behaviors: A Controlled Study of MCP and CLI Interfaces for Language Agents (MICA + DART)
- Авторы: Zhenning Shi, Liang Pang, Yongqi Li. Hong Kong Polytechnic University; Institute of Computing Technology, Chinese Academy of Sciences
- Среды: ALFWorld, WebShop, ScienceWorld
- Связанное: Model Context Protocol; InterCode, Terminal-Bench; работы об агент-компьютерных интерфейсах (SWE-agent)