AI API интеграция след Hermes Tool Search
AI API интеграцията се чупи по предвидим начин, когато един агент получи твърде много инструменти. Виждал съм добри агентни процеси да тръгват в грешна посока не защото моделът е слаб, а защото му показахме всеки конектор, всяка схема и всяка опция на всяка стъпка. Резултатът обикновено е един и същ: по-големи prompt-и, по-бавен старт, по-висока цена и модел, който избира грешния инструмент по-често, отколкото екипът очаква.
Затова новата версия на Hermes Agent Tool Search има значение. Според анализа на MarkTechPost, който цитира документацията на Nous Research и eval данни от Anthropic, Hermes вече отлага MCP схемите на инструментите, докато моделът действително не се нуждае от тях. В практически deployment план това е корекция в AI integration architecture за много реален failure mode.
Какво е AI API интеграция?
AI API интеграцията е свързването на модели, инструменти и бизнес системи така, че един агент да извлича данни и да изпълнява действия надеждно. В този случай трудната част не е да добавите още AI конектори. Тя е да покажете само правилните инструменти в правилния момент, така че моделът да остане точен, рентабилен и оперативно управляем.
Когато екипите говорят за enterprise AI integrations, те често се фокусират върху това моделът да комуникира с GitHub, Slack, Jira или вътрешни системи. Това е по-лесната част. По-трудната е да решите колко от този набор от инструменти моделът трябва да вижда едновременно.
Hermes Tool Search разглежда това като retrieval проблем, а не като проблем на статичен prompt design. За AI agent development това е полезна промяна. Спирате да питате как да натъпчете всеки инструмент в контекста и започвате да питате как да покажете минималния необходим набор на всяка стъпка.
Защо MCP каталозите с инструменти раздуват контекстния прозорец?
Основният проблем е прост. В стандартна Model Context Protocol конфигурация всеки свързан MCP сървър може да подава схеми на инструменти в масива с видими за модела tools на всяка стъпка. Ако свържете достатъчно системи, описанията на инструментите започват да се конкурират със самата задача.
Числата в източниците не са малки. Примерът с Hermes, цитиран от MarkTechPost, показва deployment с пет сървъра и 34 инструмента, който средно използва около 45 000 токена на стъпка, като приблизително 22 000 токена отиват само за overhead от схемите на инструментите. Engineering данните на Anthropic, както са обобщени в статията, показват, че описанията на инструментите са достигали 134 000 токена преди оптимизация. Статията Tool Attention в arXiv поставя MCP tools tax между 15 000 и 60 000 токена на стъпка в типични multi-server конфигурации.
Виждал съм версия на този проблем при custom AI agents, свързани едновременно към ticketing и code системи. Първият симптом невинаги е цената. По-често е колебанието. Моделът започва да избира близки по смисъл инструменти, да задава излишни уточняващи въпроси или да се проваля при прости действия, защото твърде много описания изглеждат семантично сходни.
Точно тук AI конекторите се превръщат в архитектурен проблем, а не просто в отметка по имплементацията. Ако GitHub каталог, Slack каталог и Jira каталог са видими едновременно, моделът трябва да подреди всяка възможност по релевантност, преди да действа. Това създава описаната от Anthropic decision paralysis в материалите им за advanced tool use. На практика виждате повече false positives и по-шумен избор на инструмент.
Как Hermes извлича правилния инструмент при нужда?
Hermes заменя отложените инструменти с три bridge инструмента:
tool_search(query, limit?)tool_describe(name)tool_call(name, arguments)
Моделът първо търси в отложения каталог, после зарежда схемата на вероятния инструмент и накрая извиква реалния инструмент. Звучи като малка промяна, но тя променя икономиката на AI integration services в среди с много инструменти.
Под капака Hermes използва BM25, за да търси в имената на инструментите, описанията им и имената на параметрите. Ако няма резултати с положителен score, системата преминава към буквално substring съвпадение по име на инструмент. Този fallback е по-важен, отколкото изглежда. В една среда, подобна на клиентска, всички вътрешни developer инструменти имаха един и същ продуктов префикс. Без fallback-а качеството на търсенето спадна, защото очевидният разграничителен термин присъстваше навсякъде.
Има и още едно решение в дизайна, което ми харесва: каталогът се изгражда наново от live дефинициите на инструментите при всяко assembly, вместо да се пази между отделните стъпки. Това предотвратява drift. При AI process automation остарелите registry записи са от онези скучни оперативни проблеми, които губят цели следобеди. Инструментът съществува, но моделът вижда стара схема; извикването се проваля; екипът обвинява модела, а реалният проблем е разминаване в registry-то.
Ако изграждате подобен модел в production системи, най-близката услуга по приложение е AI integration for business efficiency, защото тук оперативният проблем е надеждно свързване на инструменти и контролиран execution, а не само избор на модел.
Какво всъщност означават eval подобренията на Anthropic?
Основният резултат е лесен за повтаряне: Claude Opus 4 според данните се е подобрил от 49% до 74% на MCP evals с включен Tool Search, а Claude Opus 4.5 — от 79.5% до 88.1%.
По-полезната интерпретация е, че Tool Search не е просто трик за token compression. Той е и механизъм за по-добро подреждане на опциите. Когато моделът вижда по-малко нерелевантни инструменти, вероятността да извика грешния е по-ниска.
Това обаче не бива да се продава прекалено агресивно. Седемдесет и четири процента все още означава, че retrieval или selection failure се случват достатъчно често, за да имат значение. А 88.1% е силен резултат, но не е перфектен — особено ако задачата има права за запис или последствия за клиента. При enterprise AI integrations това означава, че все още са нужни approval потоци, логове и ясно поведение при отказ.
Има и зависимост от качеството на модела. Tool Search предполага, че моделът може да създаде добра search заявка. По-добрите модели обикновено могат. По-малките или по-евтини модели често се затрудняват да формулират правилните query terms, особено когато вътрешните имена на инструментите са непоследователни. Аз бих третирал качеството на заявките като измерима част от AI integration architecture, а не като невидим детайл.
Кога трябва да включите Tool Search?
Използвайте го, когато са налице следните условия:
- имате приблизително 15 или повече свързани инструмента
- на дадена стъпка се използва само малка част от тях
- схемите заемат съществен дял от контекста
- инструментите идват от множество MCP сървъри или plugin източници
Пропуснете го или го ограничете, когато важат следните условия:
- наборът от инструменти е малък
- едни и същи инструменти се използват почти на всяка стъпка
- latency е по-важна от размера на prompt-а
- моделът ви се затруднява с формулиране на retrieval-style заявки
Hermes по подразбиране използва enabled: auto, което активира Tool Search, когато отложените схеми биха заели поне 10% от активния context window на модела. Това е добра настройка по подразбиране, защото третира progressive disclosure като условен подход, а не като догма.
Бих следил и един по-неочевиден компромис: отложените инструменти губят част от предимствата на cache-а на system prompt, защото схемите им се зареждат по-късно. Затова, ако процесът ви многократно използва едни и същи пет инструмента в кратък цикъл, директната видимост може да остане по-проста и по-евтина като цяло.
Според документацията на Hermes, обобщена в оригиналната статия, основни инструменти като terminal, file access, web search и messaging остават директно видими. Само MCP и non-core plugin инструментите се отлагат. Това е правилното разделение. Дръжте често използваните примитиви „топли“, а long-tail каталога — търсим.
Как се конфигурира Tool Search в hermes.yaml?
Базовата конфигурация е ясна:
tools:
tool_search:
enabled: auto
threshold_pct: 10
search_default_limit: 5
max_search_limit: 20
Има и кратък вариант:
tools:
tool_search: true
Ето как бих гледал на тези настройки:
enabled: autoе сигурна начална точка за AI integration services, защото се включва само когато overhead-ът от схемите е достатъчно голям, за да го оправдае.threshold_pctтрябва да остане консервативен, освен ако моделите ви нямат необичайно малки context window-и или инструментите ви не са прекалено многословни.search_default_limitтрябва да остане нисък. Ако връщате твърде много съвпадения, пресъздавате същия ranking проблем, само в по-малък мащаб.max_search_limitе оперативен guardrail. Ако моделът може да иска по 50 кандидата всеки път, постепенно ще върнете същия clutter, който се опитвате да премахнете.
За software и B2B SaaS екипи бих комбинирал това с логване на три неща: текста на search заявката, върнатите top инструменти и крайно избрания инструмент. Без такава следа дебъгването на custom AI agents се превръща в догадки.
Какво означава това за екипите по AI интеграции?
Практическият извод е по-голям от самия Hermes. AI API интеграцията не се проваля само на ниво endpoint. Тя се проваля и на ниво choice architecture. Ако покажете твърде много инструменти твърде рано, плащате и в токени, и в точност.
За екипите, които внедряват AI process automation в enterprise операции, progressive disclosure се превръща в стандартен модел. Търсите в каталога, преглеждате схемата, извиквате инструмента, записвате резултата. Това е по-чист подход от това да натъпчете всяка интеграция в контекста и да се надявате моделът сам да се ориентира.
По-неочевидният извод за операторите е следният: измервайте качеството на избора на инструмент като first-class метрика. Не само latency, не само token cost. Следете wrong-tool извиквания, near-match извиквания и повторни опити след неуспешни заявки. По мой опит точно тези числа казват повече за production readiness, отколкото който и да е демо успех.
FAQ
Какво е Hermes Agent Tool Search на прост език?
Това е слой, който скрива повечето MCP схеми на инструменти, докато моделът не се нуждае от конкретен инструмент. Вместо да показва всяка дефиниция на всяка стъпка, Hermes позволява на модела да търси, да преглежда и да извиква правилния инструмент при нужда.
Как Tool Search подобрява точността?
Той намалява нерелевантните избори на инструменти в активния контекст. Така се понижава вероятността моделът да избере близък, но грешен инструмент или да блокира при сравняване на твърде много опции, което е и причината Anthropic да отчете по-добри резултати в MCP evals.
Полезен ли е Tool Search при малки MCP конфигурации?
Обикновено не. Ако имате само няколко инструмента, допълнителните bridge извиквания и retrieval стъпката могат да добавят overhead без съществена икономия на токени. Най-голяма полза има при големи каталози с рядка употреба на отделните инструменти.
Добавя ли Tool Search latency?
Да. При „студен“ инструмент обикновено е нужна допълнителна последователност от search и describe преди самото извикване. Това е добра размяна, когато избягвате десетки хиляди токени схемен шум, но не винаги при малки стекове.
Какво прави auto режимът в Hermes?
Auto режимът включва Tool Search само когато отложените схеми биха заели поне 10% от context window-а на модела. Hermes проверява това условие на всяка стъпка, така че поведението се адаптира според промяната в набора от инструменти.
Основни изводи
- AI API интеграцията става по-надеждна, когато големите каталози от инструменти са searchable, вместо да са изцяло видими на всяка стъпка.
- Hermes Tool Search адресира както token cost, така и точността при избор на инструмент в multi-server MCP среди.
- BM25 retrieval плюс fallback matching е практичен модел за AI integration architecture, особено когато имената на инструментите се припокриват.
- Auto режимът е полезен, защото прилага progressive disclosure само когато overhead-ът от схемите е съществен.
- Екипите трябва да измерват wrong-tool извикванията и повторните опити, а не само latency и общия token spend.
Martin Kuvandzhiev
CEO and Founder of Encorp.io with expertise in AI and business transformation