Hermes Agent решил проблему раздутого контекста MCP: +74% точности

Когда инструменты становятся проблемой

Есть такой парадокс в мире AI-агентов: чем больше инструментов ты подключаешь, тем тупее становится модель. Звучит контринтуитивно, но любой, кто строил реальные агентные системы поверх MCP, это уже прочувствовал на своем кошельке и нервах. Nous Research наконец-то признала проблему публично и выкатила решение - Tool Search в Hermes Agent. И цифры впечатляют.

Представьте: вы подключили пять MCP-серверов к своему агенту. Казалось бы, отлично - богатая экосистема, 34 инструмента под рукой. Но на каждом обращении к модели в контекст летят JSON-схемы ВСЕХ 34 инструментов. Каждого. Всегда. Даже если агенту нужно просто создать задачу в GitHub.

Результат? Средний размер промпта - 45 000 токенов за ход, из которых ~22 000 токенов - это чистый "налог" на схемы инструментов. То есть половина контекста сгорает впустую. Anthropic в своих инженерных данных зафиксировала случаи, где определения инструментов съедали 134 000 токенов до оптимизации. Это не просто дорого - это катастрофически дорого: каждый промах кэша на старте сессии обходится в $0.07 - $0.10 за ход.

Но деньги - это еще полбеды. Хуже то, что модель начинает "тупить". Когда перед ней одновременно лежат сотни нерелевантных вариантов инструментов, возникает эффект, который исследователи называют decision paralysis - паралич выбора. Модель теряется, выбирает не то или вовсе отказывается принимать решение.

Как работает Tool Search: три инструмента вместо ста

Решение Nous Research элегантно своей простотой. Вместо того чтобы грузить в контекст все схемы сразу, Tool Search заменяет весь зоопарк MCP-инструментов тремя мета-инструментами:

- `tool_search(query, limit?)` - ищет нужный инструмент в каталоге - `tool_describe(name)` - загружает полную схему конкретного инструмента - `tool_call(name, arguments)` - вызывает инструмент с аргументами

Это классический паттерн прогрессивного раскрытия информации, только примененный к инструментальному слою. Модель сначала ищет, что ей нужно, потом узнает детали, потом действует. Никакого лишнего шума.

Поисковый движок под капотом - BM25, классический алгоритм информационного поиска, который многие незаслуженно считают устаревшим. Здесь он работает отлично: матчит запрос модели против названий инструментов, их описаний и параметров. Если BM25 не находит ничего с положительным скором - система падает на буквальный substring-поиск по имени инструмента. Это страховка от вырожденных случаев, когда, например, все инструменты в каталоге содержат слово "github" и TF-IDF просто обнуляется.

Одна деталь, которую я считаю особенно умной: каталог инструментов пересобирается с нуля на каждом ходу. Никакого хранения состояния между вызовами. Это предотвращает классическую проблему дрейфа - когда закэшированный каталог расходится с реальным состоянием реестра инструментов. Звучит как мелочь, но в продакшне именно такие "мелочи" приводят к часам отладки.

Цифры, которые заставляют задуматься

Антропик прогнал собственные MCP-эвалюации с включенным и выключенным Tool Search - и результаты говорят сами за себя.

Claude Opus 4 без Tool Search: 49% точности. С Tool Search: 74%. Прирост - 25 процентных пунктов, больше чем в полтора раза.

Claude Opus 4.5: с 79.5% до 88.1%. Здесь прирост скромнее, но базовая точность уже была высокой - и все равно значимый рост.

При этом Anthropic фиксирует 85% сокращение токенов на определения инструментов при сохранении полного доступа к библиотеке. То есть вы не теряете функциональность - вы просто перестаете платить за то, чем не пользуетесь прямо сейчас.

Для понимания масштаба: прирост с 49% до 74% для Opus 4 - это разница между "агент иногда справляется" и "агент реально работает". На таком уровне точности уже можно строить продукты.

Контекст: почему это важно именно сейчас

MCP-экосистема растет со скоростью, которую никто не предсказывал год назад. Каждый крупный сервис выкатывает свой MCP-сервер, агентные фреймворки интегрируют их пачками, и проблема контекстного раздутия становится все острее. То, что сегодня выглядит как 34 инструмента, через полгода превратится в 340.

Сравните с тем, как эту проблему решают другие. LangChain и LlamaIndex предлагают ручной выбор инструментов через retrieval-слои, но это требует явной конфигурации от разработчика. OpenAI в своих агентных SDK пока не имеет встроенного механизма прогрессивного раскрытия инструментов. Hermes Agent делает это автоматически - функция работает в режиме auto по умолчанию.

Для российских разработчиков: Hermes Agent - это open-source проект Nous Research, доступный на GitHub. Никаких географических ограничений нет, API-ключи не нужны для самого фреймворка. Если вы используете Claude через API - нужен будет доступ к Anthropic API, что в РФ требует либо иностранной карты, либо посредника. Но сам Hermes можно развернуть локально с любой совместимой моделью.

Что это меняет на практике

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

Для бизнеса важнее другое: рост точности с 49% до 74% означает, что агенты перестают быть демо-игрушками и становятся рабочими инструментами. Именно на таком пороге точности клиенты начинают доверять автоматизации реальных задач.

Я слежу за развитием MCP с самого начала, и Tool Search - это первое по-настоящему системное решение проблемы, которая тормозила всю экосистему. BM25 может казаться старомодным выбором рядом с векторным поиском, но для этой задачи он работает быстрее, детерминированнее и не требует эмбеддинг-инфраструктуры. Прагматичное инженерное решение - и именно такие решения живут долго.