Схемы инструментов MCP и бюджеты
Инструменты MCP
Каждый инструмент, который может вызвать агент, поставляется со схемой: имя, описание, параметры. Встроенные инструменты (Read, Edit, Bash) сравнительно компактны — примерно 50–1000 токенов каждый. С MCP-серверами история совсем другая.
Влияние на контекст: предварительная загрузка помещает все схемы в фиксированный префикс запроса ещё до того, как модель спланирует первое действие. Отложенная загрузка поначалу оставляет большинство схем за пределами контекста, но добавляет точку принятия решения Tool Search: модель должна выполнить поиск, выбрать кандидата, загрузить его схему, затем вызвать инструмент. При выборе похожего, но неподходящего кандидата в контекст могут добавиться неверная схема, вызов и результат, прежде чем ошибка будет исправлена. Эти артефакты не удаляются: они остаются и могут смещаться в середину контекста, где внимания меньше.
Стоимость заложена в структуре: каждая схема инструмента сериализуется в JSON с повторяющимися аннотациями типов, вложенными массивами required и многословными описаниями на естественном языке. Типичный инструмент занимает 300–600 токенов; сложные инструменты API вроде файловых операций GitHub доходят до 1000–2000. При подключении нескольких серверов эти расходы быстро складываются. Основное правило простое: небольшие часто используемые наборы инструментов выигрывают от предварительной загрузки; большие широкие каталоги — от отложенной.
pi 1.0 применяет это правило к каждому серверу, а не ко всему клиенту. Встроенный MCP-клиент задаёт каждому серверу режим exposure: codemode (по умолчанию) оставляет схемы за пределами промпта и позволяет скриптам вызывать инструменты напрямую; отложено скрывает их, пока tool_search не загрузит подходящую; direct заранее объявляет небольшой часто используемый набор; hidden делает инструменты недоступными (используй его только для экспериментальных или внутренних серверов, которые никогда не должны появляться в промпте). Сервер в режиме codemode или отложено всё же присутствует в системном промпте — в виде краткого описания в одну строку, а не полного каталога.
Предварительная и отложенная загрузка
Предварительная загрузка упрощает вызовы, поскольку схема уже есть у модели, когда она начинает планировать. Отложенная загрузка защищает начальный промпт, но каждый отложенный инструмент зависит от вероятностного выбора кандидата. Широта каталога определяет, какой объём заранее загруженных схем попадает в префикс; широта задачи — сколько схем действительно нужно работе; качество выбора — свернёт ли поиск на неверный путь. Это отдельные переменные.
Управление контекстом
Отложенная загрузка добавляет точку решения Tool Search
мало и часто — без поиска.
много и редко — остальное отложить.
В этой показательной задаче используются две возможности. При предварительной загрузке 20 схем находятся между базовыми инструментами и запросом пользователя, в середине со слабым вниманием. При загрузке по требованию добавляются определение поиска инструментов, два раунда поиска и один цикл восстановления после неточных совпадений и неудачных попыток. Затем загружаются две схемы, выполняется та же обычная работа инструментов и выдаётся итоговый ответ. Остальные 18 схем остаются за пределами контекста. Предварительная загрузка занимает на 14 единиц контекста больше.
Перемещай регулятор каталога: он меняет широту установленного набора, а не потребности показательной задачи. Задаче всегда нужны две схемы. Предварительная загрузка помещает весь каталог в фиксированный префикс; отложенная показывает только схемы, выбранные во время выполнения, и оставляет остальные вне запроса.
Переключай исход Tool Search. Точное совпадение ведёт по короткому пути. Похожее совпадение загружает неверную схему, создаёт ошибочный вызов и результат, затем запускает повторную попытку. Артефакты неверного пути остаются в истории и занимают впадину внимания даже после загрузки правильных схем. Поэтому точка, где один подход становится выгоднее другого, зависит от размера схем, широты задачи, объёма результатов и качества выбора, а не только от размера каталога.
Вывод: чем больше твой каталог похож на инфраструктуру, тем важнее оптимизировать то, что не попадает во впадину внимания, вместо мгновенной видимости инструментов. Та же логика действует уровнем выше, для повторно используемых процедур: если библиотека процессов велика, обеспечь дешёвый поиск, а полные инструкции загружай лишь по необходимости. Здесь действует тот же компромисс между автоматизацией и надёжностью.