Когда у ИИ слишком много инструментов, на саму работу почти не остаётся места

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

Поэтому в XTester.McpHost готовим Progressive Tool Discovery и планируем применять его в XTester Studio. Хост хранит полный список. Модель сначала видит узкий поиск и подгружает только инструмент текущего шага.

Что происходит, если отдать агенту весь каталог

MCP (Model Context Protocol) даёт ИИ вызывать функции среды: загрузить историю, запустить тест, открыть график. Каждая функция приходит с именем, описанием и схемой аргументов. На одну схему легко уходит сотни токенов. На десятки инструментов уходят тысячи, ещё до вопроса пользователя.

Дальше ломается не только место. Модель хуже выбирает нужный вызов, когда перед ней одновременно «похожие» действия: несколько способов прочитать сделки, несколько способов запустить тест. В торговой IDE это особенно заметно, потому что предметных операций много, а задача часто узкая: проверить один вход на одном участке истории.

Как работает Progressive Tool Discovery

Хост по-прежнему знает весь каталог. В контекст модели он не выгружает его целиком.

Обычный цикл такой:

1. Модель получает маленький поисковый инструмент.
2. Она описывает, что нужно сейчас: например, прогнать бэктест или открыть сделки за период.
3. Хост возвращает несколько подходящих имён с короткими описаниями.
4. Полная схема подгружается только для выбранного вызова.

Так устроен рекомендуемый клиентский приём в документации MCP: tools/list остаётся у хоста, а в модель попадает search_tools и точечная подгрузка. Это не уменьшает возможности среды. Это меняет момент, когда описание попадает в окно.

Что это даёт при разработке стратегии

Представьте шаг «почему стратегия вошла здесь». Агенту нужны график, список сделок и, возможно, параметры прогона. Ему не нужны одновременно инструменты экспорта, облачной очереди, всех биржевых коннекторов и всей справки.

В XTester Studio как раз такой цикл: код, сборка, тест на истории, затем разбор результата. Progressive Tool Discovery совпадает с этим циклом. На шаге отладки входа подгружается узкий набор. На шаге сравнения прогонов подгружается другой.

XTester.McpHost уже отдельный процесс, через который агент работает с движком и проектом. Обнаружение инструментов по мере надобности будет в этом хосте, затем в Studio. Это план внедрения, не заявление, что функция уже в публичной сборке Studio.

Когда полный список всё же уместен

Если инструментов мало и их описания короткие, проще отдать весь набор сразу. Поиск добавляет шаг и небольшую задержку.

Полный список уместен, когда набор фиксированный и узкий: например, три read-only вызова для одного сценария. Progressive discovery нужен, когда каталог растёт вместе со средой: данные, тесты, графики, журнал, ордера, сравнение прогонов.

Способ	Что видит модель в начале	Когда выбирать
Весь каталог сразу	Все имена и схемы	Мало инструментов, стабильный набор
Явный короткий набор	Только заранее выбранные вызовы	Известный сценарий, без поиска
Progressive Tool Discovery	Поиск, затем 1–несколько схем	Большой и растущий каталог торговой IDE

Цифры экономии токенов у чужих продуктов в эту статью не переносим: у каждого каталога своя длина описаний. Смысл один: контекст должен оставаться работе, а не меню.

Ограничения

Статья объясняет механизм, а не даёт торговых рекомендаций. Подгрузка инструмента не делает бэктест честнее сама по себе: комиссии, проскальзывание, выбор периода и подгонка никуда не деваются. Точный состав вызовов MCP и момент появления функции в Studio зависят от реализации в McpHost; здесь описан принцип, который туда закладываем.

Если вы пишете стратегии и подключаете к ним агента, смотрите не сколько инструментов «есть в системе», а сколько их в текущем промпте. Для следующего шага обычно нужен один вызов, а не весь верстак.

Связанные материалы: кроссплатформенная Studio на Code - OSS, walk-forward и проверка вне выборки.