Автор оставил ИИ четыре инструмента вместо пятнадцати. Что изменилось?
У ИИ-помощника может быть доступ ко всем нужным данным, а простой вопрос всё равно потребует длинной цепочки действий. Одна из причин — инструменты повторяют устройство сервисов, тогда как пользователь спрашивает о результате работы.
Разработчик Сарвар Надаф описал такой опыт на сервере для поиска лишних расходов в AWS. В первой версии было 15 инструментов, во второй — четыре. На одном аккаунте и одном вопросе число вызовов сократилось с семи до двух. Автор изменил и набор операций, и данные, которые они возвращают. Поэтому интереснее разобраться, какую работу удалось убрать с модели, чем пытаться скопировать число «четыре».
Пользователь ищет лишние расходы, а получает набор технических команд
В исходной версии отдельные инструменты возвращали сведения о разных облачных ресурсах. Чтобы ответить на общий вопрос о расходах, помощнику нужно было выбрать функции, получить данные и сопоставить их самостоятельно.
Подключение устроено через MCP — протокол, который позволяет ИИ вызывать внешние инструменты. Для самой модели инструмент выглядит как название операции, описание и список входных данных. Чем больше похожих операций, тем важнее, насколько понятно они различаются.
Сокращение числа инструментов в опыте автора сопровождалось изменением их устройства и объёма возвращаемых данных. Поэтому нельзя приписать результат одному действию «удалили одиннадцать функций». Изменилось то, какую работу выполнял сервер до передачи ответа модели.
Как это выглядит на более привычном примере
Представим помощника для интернет-магазина. Сотрудник спрашивает: «Почему покупателю ещё не вернули деньги?»
Можно дать помощнику отдельные операции для поиска заказа, платежа, возврата товара, проверки склада и получения истории выплат. Тогда он сам собирает цепочку, решает, какие идентификаторы использовать, и может пропустить нужный шаг.
Другой вариант — операция «проверить состояние возврата по заказу». Программа сама получает связанные записи и возвращает нужные сведения: товар получен складом, возврат одобрен, выплата ожидается. Помощнику остаётся объяснить результат сотруднику и назвать источник статуса.
Второй вариант удобнее для этого вопроса. Но если сотруднику нужно расследовать необычное расхождение, одной готовой сводки может не хватить. Слишком крупный инструмент способен скрыть детали, которые понадобятся для проверки.
Меньше не всегда лучше
AWS в разборе проектирования MCP-инструментов рассматривает компромиссы между размером каталога, понятностью выбора и устройством операций. Из этого не следует обязательное число функций для каждого помощника.
Для магазина полезно сохранить отдельные операции там, где различаются права и последствия. Просмотр возврата и отправка денег не должны сливаться в одно действие только ради короткого списка. Получить информацию и изменить её — разные полномочия.
Не стоит и прятать все операции в универсальную команду «выполни действие». Краткий каталог станет хуже, если модель будет гадать, какие параметры туда передать, а разработчик потеряет возможность ясно ограничить доступ.
Цель — уменьшить ненужные развилки на пути к конкретной задаче, сохранив понятные границы.
Что автор действительно измерил
В опыте Надафа сравнивались две версии одного сервера, работающего только на чтение. Это не проверка всех видов агентов. Отдельная метрика объёма описаний была приближением по числу символов, а не точным замером оплаченных токенов.
Поэтому сокращение описаний нельзя напрямую переводить в такой же процент экономии денег. В счёт могут входить ответы инструментов, история переписки и особенности обработки повторяющегося текста. Кроме того, меньше вызовов не всегда означает меньше переданных данных.
Для магазина из нашего примера полезнее сравнить полный ответ на один и тот же вопрос: правильность статуса, число лишних действий, задержку и фактический расход. Если новая сводка короче, но скрывает причину задержки выплаты, инструмент стал компактнее, а сотруднику не помог.
С чего начать у себя
Возьмите несколько частых вопросов к помощнику и посмотрите реальные последовательности вызовов. Повторяющаяся цепочка может подсказать, что стоит объединить на уровне программы. Случайные ошибки выбора — что нужно лучше назвать и описать.
Для сравнения поведения разных моделей можно использовать каталог provod.ai, сохранив одинаковые задачи, права и инструменты. Сравнивать расходы лучше по фактическому использованию, а не по длине названий или числу функций в списке.
Для магазина успех будет выглядеть просто: на вопрос о возврате помощник покажет его состояние и причину задержки, а сотрудник сможет сверить ответ с записями. Сколько инструментов понадобится для этого — четыре или пятнадцать — решается уже по устройству магазина, правам доступа и частым вопросам.