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 может казаться старомодным выбором рядом с векторным поиском, но для этой задачи он работает быстрее, детерминированнее и не требует эмбеддинг-инфраструктуры. Прагматичное инженерное решение — и именно такие решения живут долго.