Tu agente necesita una tool — quizá tiene que crear un issue de GitHub, enviar un mensaje de Slack y buscar en la web, todo en una sola tarea. Con el sistema antiguo, eso eran tres llamadas separadas a tool_search, y si escribía mal una query («issuse» en lugar de «issues») o buscaba una palabra que no coincidía exactamente con el nombre de la tool, se quedaba vacío y tenía que volver a intentarlo. Cada fallo cuesta tokens y latencia. Hermes v0.20.6 lo arregla con una mejora seria de tool_search (commit e455e4afd0): búsqueda multi-query, describe por lotes y stemming de Snowball.

El cambio es pequeño en la forma y grande en el comportamiento: tool_search ahora acepta queries: string[] buscadas en paralelo contra el mismo catálogo; los resultados vuelven agrupados por query, con un único mapa compartido de tools que contiene la fuente, la descripción y los nombres de los parámetros requeridos de cada tool encontrada. tool_describe acepta names: string[] y devuelve un mapa indexado por nombre — de modo que un nombre incorrecto ya no hace fallar toda la llamada. Y el stemming de Snowball hace que una query de «issues» coincida con una tool llamada create_issue, y que «browsing» encuentre browser_exec. Veamos qué cambió y por qué importa.

El método antiguo frente al nuevo

Antes: una query por llamada, coincidencia aproximada, fallback por respuesta cuando una query fallaba:

tool_search("browser")        → una lista de coincidencias
tool_search("web search")     → otra llamada, otra lista
tool_search("read pdf")       → una tercera llamada

Después: una llamada, varias queries, resultados agrupados:

{ "queries": ["browser snapshot", "web search cache", "read pdf"] }

Cada query se busca de forma independiente contra el mismo catálogo, el límite se aplica por query (5 por defecto, recortado al máximo configurado de 25), y la respuesta agrupa los nombres de tools que coinciden por query, mientras que un único mapa compartido tools lleva la fuente, la descripción (límite de 400 caracteres) y los nombres de los parámetros requeridos de cada tool — cargados una sola vez, no repetidos por query. Cuando algunas queries fallan, un único bloque de available_sources + hint a nivel superior reemplaza el fallback antiguo por respuesta.

El schema, directamente de la definición de la tool:

• queries: array de strings, «cada una unas pocas keywords que describen una capacidad (p. ej. ['create github issue', 'send slack message']). Se buscan en paralelo; los resultados vuelven agrupados por query. También se acepta un string único, que se trata como una sola query».
• limit: «Número máximo de coincidencias por query. Por defecto es 5 y se recorta al máximo configurado (25 por defecto)».

Stemming: que coincida lo que quieres decir, no lo que tecleaste

El héroe silencioso de este cambio es el stemming de Snowball (inglés). El stemmer se aplica de forma idéntica tanto en la ruta del índice (cuando se construye el catálogo) como en la ruta de la query, de modo que una query de «issues» coincide con una tool llamada create_issue, «browsing» coincide con browser_exec y «searches» coincide con web_search. Ya no necesitas adivinar la forma verbal exacta ni el plural — el motor normaliza ambos lados.

Detalle de implementación que merece la pena anotar: las instancias del stemmer de Snowball mantienen estado de parseo mutable, así que no son seguras para compartir entre hilos — y el dispatch del bridge puede ejecutarse en hilos paralelos de llamadas a tools. Hermes crea un stemmer por hilo, de forma perezosa — una corrección pequeña pero real, escondida dentro de la funcionalidad.

tool_describe: nombres por lotes, fallo suave

tool_describe recibe el mismo tratamiento: ahora acepta names: string[] y devuelve un mapa indexado por nombre. Los nombres desconocidos se acumulan en not_found (con el hint de refresh), y los nombres no diferibles mantienen su error individual de comprobación ortográfica en errors — un nombre incorrecto ya no hace fallar toda la llamada. Los duplicados se deduplican en silencio. Así, después de un tool_search multi-query, el agente puede describir varios candidatos en una sola llamada, y un nombre con errata cuesta una nota, no un reintento.

Qué significa esto en la práctica

Tres beneficios concretos:

• Menos idas y vueltas. Una tarea que necesita tres capacidades recibe una llamada a tool_search en lugar de tres, y después un tool_describe por lotes. Menos llamadas = menor latencia y menos oportunidades de que el modelo pierda el hilo.
• Descubrimiento más barato. El mapa compartido de tools significa que los metadatos de cada tool encontrada se envían una sola vez, no repetidos por query — y en el cable, las propias definiciones de las tools adelgazaron junto con este cambio (el trabajo más amplio de dieta de schema en la misma ventana recortó browser_exec de 803 a 663 tokens/llamada). El descubrimiento es una de las partes que más tokens consume de una ejecución larga del agente; esto lo recorta.
• Mejor recall. El stemming elimina la clase de fallo de «cerca pero no exacto»: «issues» → create_issue, «browsing» → browser_exec, «searches» → web_search. El agente encuentra la tool correcta incluso cuando formula la query de forma ligeramente imprecisa.

Por qué importa para tus workflows

El descubrimiento de tools es fontanería invisible — nunca la ves salvo que falle, y cuando falla, el agente o se agita sin rumbo o elige una tool parecida pero equivocada. Multi-query + stemming + describe por lotes elimina la mayor parte de esa superficie de fallo. Es el tipo de mejora que hace que las ejecuciones autónomas largas (tareas por lotes, cron jobs, subtareas delegadas) sean notablemente menos frágiles: el agente necesita una tool de browser, una de búsqueda y un lector de PDF para una sola tarea, y encuentra las tres de una vez.

Para saber más sobre las propias tools, consulta nuestro panorama de comandos para la superficie completa de lo que tool_search puede encontrar, el presupuesto de snapshots del browser para ver cómo las sesiones de browser se mantienen baratas, y el post de la caché de búsqueda web para la mejora hermana de caché en la misma ventana. El resumen completo de v0.20.6 está en nuestras notas de la release.

Una llamada, tres queries, con stemming, agrupadas y deduplicadas — el agente encuentra la tool correcta más rápido y más barato, y el «no pude encontrar una tool para eso» se vuelve un poco más raro cada día.