La búsqueda se ha convertido en una de las capacidades externas más importantes disponibles para los agentes de IA. Los modelos potentes pue...
La búsqueda se ha convertido en una de las capacidades externas más importantes disponibles para los agentes de IA. Los modelos potentes pueden razonar bien, pero no pueden recuperar hechos que nunca han visto, no pueden distinguir información actual de informes desactualizados basándose en evidencia, ni deducir de manera confiable registros corporativos faltantes.
AnySearch aborda este problema como una infraestructura orientada a agentes, no como una página de búsqueda orientada al usuario. En lugar de devolver solo enlaces, títulos y extractos breves, enruta las consultas a fuentes web o verticales relevantes, elimina contenido duplicado y de bajo valor, extrae información útil y entrega una respuesta estructurada que puede ingresar directamente al contexto de razonamiento del modelo.
Este producto ocupó el primer lugar en Product Hunt tanto el día de su lanzamiento como durante la semana del 6 de julio de 2026. Su presentación destacó que ofrece información en tiempo real, filtrada, deduplicada y estructurada a través de API, servidores MCP o habilidades de agente instalables.
Este artículo explica las diferencias entre este flujo de trabajo de búsqueda orientado a agentes y las API de búsqueda tradicionales, analiza en detalle los ejemplos mostrados en el informe original y proporciona una guía práctica de instalación y evaluación.
Nota sobre la referencia de evaluación: Los datos de precisión y latencia a continuación provienen de los resultados comparativos de AnySearch replicados en el artículo fuente. Los materiales públicos revisados en esta versión no incluyen el código de evaluación completo, las salidas originales, las instrucciones de evaluación o el análisis estadístico. Considere estos datos como resultados reportados por el proveedor, no como evaluaciones de referencia replicadas de manera independiente.
Los humanos pueden navegar por las páginas de resultados, ignorar anuncios, identificar artículos duplicados y juzgar qué enlaces merecen atención.
Los agentes, en cambio, suelen recibir cada resultado como entrada, lo que genera múltiples costos:
El problema no es solo la precisión de la recuperación, sino también la forma y densidad de la información devuelta.
Por lo tanto, un sistema de búsqueda práctico para agentes debe responder tres preguntas antes de pasar la información al modelo:
AnySearch está diseñado en torno a estos pasos.
AnySearch obtuvo el primer lugar del día y de la semana en Product Hunt el 6 de julio de 2026. Product Hunt lo describió como
Búsqueda estructurada en tiempo real confiable para agentes y desarrolladores, que obtiene información filtrada y deduplicada de fuentes de búsqueda paralelas.
El artículo fuente también presentó un sistema de evaluación de 300 preguntas construido a partir de tres conjuntos de referencia:
El artículo indicó que AnySearch, Brave Search y Parallel utilizaron el mismo modelo de lenguaje, por lo que la capa de búsqueda (y no la selección del modelo) fue la variable principal.
| Sistema de búsqueda | Precisión general | FreshQA | WebWalkerQA |
|---|---|---|---|
| AnySearch | 76.4% | 80.0% | 65.2% |
| Brave Search | 64.0% | 74.0% | 46.8% |
| Parallel | 72.2% | 78.0% | 61.0% |
FreshQA evalúa preguntas que dependen de información actual o cambiante. WebWalkerQA se centra en navegar por sitios web a través de múltiples páginas y localizar evidencia. La combinación de ambos tiene una fuerte relevancia para agentes que no solo necesitan listas superficiales de enlaces.
FRAMES se incluyó en la evaluación general del artículo fuente, pero el gráfico desglosado por conjuntos de referencia solo mostró FreshQA y WebWalkerQA además de la puntuación general.
El gráfico de latencia muestra que AnySearch tiene valores más bajos tanto en la comparación promedio como en el subconjunto de WebWalkerQA.
| Sistema de búsqueda | Valor de latencia promedio | Valor de latencia en WebWalkerQA |
|---|---|---|
| AnySearch | 48.0 | 76.5 |
| Brave Search | 68.9 | 133.0 |
| Parallel | 77.4 | 145.6 |
La imagen fuente no especifica claramente las unidades, por lo que la tabla mantiene intencionadamente los valores reportados sin convertirlos a segundos o milisegundos.
AnySearch actualmente admite tres métodos principales de integración:
El repositorio oficial de GitHub proporciona una habilidad y un servidor MCP bajo la licencia Apache-2.0. Ambos admiten búsqueda web general, búsqueda vertical, búsqueda por lotes en paralelo y extracción de URL de páginas completas.
Esta imagen está relacionada con el contenido de AnySearch presentado en el documento, y ofrece una representación visual de sus funciones y características, ayudando a los lectores a comprender mejor los tipos de búsqueda que admite, entre otra información.](https://we0-cms.oss-cn-beijing.aliyuncs.com/cms-assets/image/2026/07/80912d0a-73aa-4f80-bbab-eb6f0779cd63-e96fb0d4-000e-4288-ae1b-bf3c078c578f.png)
El repositorio oficial recomienda descargar una versión fija (pinned release) en lugar de obtener cambios no publicados directamente desde la rama principal.
Rama.
# Descargar la versión especificada de AnySearch Skill.
# Consulta la página de versiones y reemplaza v2.1.0 cuando haya una versión estable más reciente.
curl -L -o anysearch-skill.zip \
https://github.com/anysearch-ai/anysearch-skill/archive/refs/tags/v2.1.0.zip
# Descomprimir la versión.
unzip anysearch-skill.zip
Mueve el directorio descomprimido a la ubicación correspondiente utilizada por tu agente:
# Claude Code
mv anysearch-skill-2.1.0 ~/.claude/skills/anysearch
# OpenCode
mv anysearch-skill-2.1.0 ~/.config/opencode/skills/anysearch
# Proyecto Cursor o Windsurf
mv anysearch-skill-2.1.0 /.skills/anysearch
# Ubicación compartida del agente
mv anysearch-skill-2.1.0 ~/.agents/skills/anysearch
El directorio exacto depende de la plataforma del agente y sus reglas actuales de descubrimiento de skills.
La documentación oficial de skills y MCP indica que el acceso anónimo tiene límites de velocidad más bajos. La clave API es opcional, pero se recomienda para un uso más estable o de mayor volumen.
No subas la clave API a repositorios públicos. Almacénala en variables de entorno, gestores de claves o archivos de configuración local ignorados.
La primera prueba del artículo fuente pide al agente que encuentre una implementación real de limitador de velocidad API en Go, orientada a producción, y no un tutorial introductorio.
El prompt es:
Estoy construyendo un proyecto y necesito implementar un limitador de velocidad API en Go. No necesito tutoriales. Encuentra código de producción de proyectos reales de código abierto.
Sin un flujo de trabajo de búsqueda dedicado, se reporta que el agente devolvió enlaces comunes y fragmentos de código aislados. Aunque este resultado puede explicar conceptos, resulta de ayuda limitada cuando los desarrolladores necesitan un contexto completo de implementación.
Una ejecución asistida por AnySearch devolvió resultados más estructurados y orientados al código, con cadenas de llamadas más claras y materiales provenientes de bases de código reales.
Esta diferencia es crucial, porque el código de producción no es solo algoritmo. Los resultados útiles de búsqueda deben ayudar al agente a examinar:
Una búsqueda de código que extraiga una función bonita pero ignore sus supuestos contextuales puede desorientar al agente de implementación.
Independientemente del proveedor de búsqueda, consultas más explícitas pueden mejorar los resultados:
Busca proyectos Go de código abierto y mantenidos que implementen limitadores de velocidad API en código de producción.
Requisitos:
- Devuelve repositorios y rutas de archivos precisas.
- Prioriza código utilizado en servidores o pasarelas reales.
- Incluye contexto de inicialización y flujo de solicitudes.
- Indica algoritmo, almacenamiento backend, pruebas y licencia.
- Excluye bases de código de tutoriales y fragmentos copiados.
- Señala la fecha de confirmaciones recientes relevantes.
El sistema de búsqueda debe proporcionar evidencia. El agente de codificación aún debe verificar el repositorio, la licencia, las pruebas, los supuestos de seguridad y el estado de mantenimiento actual antes de adaptar el código.
Segunda prueba
Compara AnySearch y Exa en la misma necesidad de investigación corporativa.
Ambos informes se desempeñaron bien en información básica pública de la empresa. Las diferencias se manifiestan principalmente en la sección de riesgos.
Se reporta que AnySearch encontró registros de cumplimiento publicados localmente y anuncios de plataforma que faltaban en el informe generado por Exa. La fuente atribuye esta diferencia al acceso a fuentes de datos verticales chinos, no al modelo de lenguaje en sí.
Este ejemplo resalta una limitación común en la investigación corporativa: un índice web global puede cubrir bien el sitio web oficial de la organización, informes internacionales y bases de datos en inglés, pero puede omitir registros regulatorios, judiciales, de quejas o de plataforma locales.
Un agente de debida diligencia debe buscar explícitamente en múltiples categorías:
Aviso importante: La debida diligencia asistida por búsqueda no sustituye la revisión profesional legal, financiera o de cumplimiento. Los registros pueden estar incompletos, los nombres pueden generar confusión y los resúmenes automáticos pueden malinterpretar la evidencia.
La tercera prueba pide a AnySearch generar un informe del mercado energético global que incluya:
Los resultados de la fuente mostraban detalles de reservas regionales, comparativas de precios eléctricos europeos y datos de emisiones. El informe citaba información reciente, como datos de la Administración de Información Energética de EE. UU. del 9 de julio y precios intradiarios europeos del 12 de julio.
Esta figura está relacionada con el contenido de la tercera prueba del documento, presentando los datos de precios eléctricos day-ahead de múltiples países europeos, y forma parte del informe del mercado energético global generado por AnySearch.](https://we0-cms.oss-cn-beijing.aliyuncs.com/cms-assets/image/2026/07/3f5432f8-0641-4e6e-b8aa-62b6a50e7d18-f18fcac7-52c7-4efa-a066-9c9722c9cea9.jpeg)
Este es un ejemplo típico de consulta en múltiples áreas, que requiere que el sistema identifique que una sola solicitud contiene múltiples rutas de datos independientes, en lugar de una única búsqueda web convencional.
Una implementación fiable debería:
Los datos actuales deben incluir siempre una marca de tiempo. Si el informe no indica la hora de publicación de las mediciones subyacentes ni su período de cobertura, el término "más reciente" carece de significado.
El planteamiento central del diseño es que AnySearch reestructura el proceso de recuperación en torno al comportamiento de los agentes.
El flujo mostrado en el código fuente consta de cinco fases:
El sistema primero identifica qué tipo de evidencia requiere la consulta.
Las consultas de antecedentes empresariales pueden necesitar registros mercantiles, patentes, bases de datos legales y plataformas de quejas. Los problemas relacionados con código deben dirigirse a repositorios de código y documentación. Las consultas sobre el mercado energético pueden necesitar datos oficiales de inventarios y del mercado eléctrico.
Describe tu idea una vez y We0 AI puede generar un sitio de presentacion, paginas y CMS, y ayudarte a atraer clientes y trafico tras el lanzamiento.
Una generación completa de proyectos para registro gratuito
Lo mejor para probar un flujo de generación completo y ver rápidamente el primer borrador del proyecto.
Esto difiere de tratar todas las solicitudes a través de un índice genérico.
AnySearch afirma que, además de la búsqueda genérica, admite más de 20 categorías verticales, que abarcan los siguientes ámbitos:
La interfaz MCP pública incluye un método de catálogo de dominios. El agente debe solicitar los dominios y patrones de parámetros válidos, en lugar de crear filtros no soportados por su cuenta.
Una pregunta que abarca múltiples dominios puede iniciar varias búsquedas independientes. El servidor MCP admite la ejecución por lotes de 1 a 5 objetos de consulta, y el fallo de una rama no bloquea la ejecución de las demás.
La recuperación en paralelo puede reducir el tiempo total de espera, pero solo si la capa de agregación evita que los resultados rápidos y de baja calidad desplacen a los resultados autorizados pero más lentos.
Evidencia.
El texto original propone tres ideas de ordenación:
Su objetivo previsto es filtrar más contenido antes de que este llegue al modelo de lenguaje.
Esto difiere de los procesos que devuelven un gran conjunto de resultados y dejan que el modelo se encargue de la deduplicación. El prefiltrar puede ahorrar tokens, pero introduce otra responsabilidad: el sistema de ordenación no debe eliminar silenciosamente registros de fuentes minoritarias o contradictorios clave.
Tras la ordenación, AnySearch extrae el contenido principal, elimina el ruido de la página y convierte los resultados al formato Markdown.
El servidor MCP oficial también ofrece una operación de extracción de URL, que devuelve el contenido de la página en Markdown con un límite de truncamiento claro de 50.000 caracteres.
La salida estructurada puede reducir el trabajo necesario para el modelo, especialmente cuando los resultados incluyen:
¿Por qué la deduplicación reduce el desperdicio de tokens?
Supongamos que un agente recibe diez resultados sobre el mismo evento. Si siete de ellos son reescrituras del mismo informe original, entonces el contexto contiene afirmaciones repetidas, en lugar de siete confirmaciones independientes.
Esto genera tres problemas:
La deduplicación basada en fuentes busca conservar evidencia única, no simplemente retener las páginas mejor posicionadas.
Una respuesta práctica de búsqueda para agentes debería hacer visibles las fuentes. El desarrollador necesita saber si cinco resultados representan cinco fuentes originales, cinco republicaciones de la misma fuente, o una combinación de evidencia principal y secundaria.
El texto original describe un menor consumo de tokens como una ventaja de AnySearch, pero no publica un porcentaje general de reducción de tokens.
Esto es razonable, ya que el ahorro depende de:
Una evaluación justa debe medir toda la tarea, no solo la respuesta de la primera búsqueda.
Las métricas útiles incluyen:
| Métrica | Lo que mide |
|---|---|
| Tokens de entrada de búsqueda | Cuánto contexto consume el material recuperado |
| Tokens totales del agente | Búsqueda, razonamiento, acciones posteriores, |
| generación final |
| Número de llamadas de búsqueda por ronda | Si la recuperación débil provoca búsquedas repetidas |
| Número de fuentes distintas | Diversidad de evidencia tras la deduplicación |
| Precisión de las citas | Si las fuentes citadas respaldan las afirmaciones |
| Integridad de la respuesta | Si la respuesta cubre las dimensiones requeridas |
| Latencia de extremo a extremo | Tiempo necesario para completar la tarea |
| Tasa de éxito de la tarea | Si el agente logra el objetivo esperado |
Una respuesta breve que omite evidencia clave no es una estrategia óptima. La reducción de tokens solo tiene valor si se mantiene la calidad de la respuesta y la trazabilidad.
Los componentes de búsqueda utilizados en entornos de producción deben manejar problemas de fallos que rara vez aparecen en demostraciones de productos.
La fuente de recursos destaca las siguientes características:
La documentación pública de MCP también admite las siguientes funciones:
Los equipos de producción aún deben agregar sus propios controles:
La salida de búsqueda es entrada externa no confiable. Incluso el texto Markdown limpio puede contener instrucciones maliciosas, afirmaciones falsas o contenido comprometido.
La búsqueda tradicional ayuda a los usuarios a localizar páginas. La búsqueda para agentes tiene un objetivo diferente: proporcionar evidencia utilizable por máquinas para razonamiento y ejecución.
Esto cambia las prioridades de diseño.
| Búsqueda orientada a humanos | Búsqueda orientada a agentes |
|---|---|
| Optimizada para navegación rápida | Optimizada para ingesta por máquinas |
| Enlaces y resúmenes | Evidencia estructurada |
| El usuario deduce la repetición | El sistema debe reducir contenido repetido |
| El usuario verifica fechas de vigencia | Las fechas deben estar claramente marcadas |
| El usuario decide en quién confiar | Se requieren señales de fuente y calidad |
| La navegación puede ser exploratoria | La búsqueda repetida consume tiempo y tokens |
| El diseño visual es importante | La arquitectura estable y Markdown son importantes |
El modelo determina la capacidad del agente para razonar con la evidencia. La capa de búsqueda determina qué evidencia está disponible inicialmente.
A medida que mejoran las capacidades del modelo, la importancia de la calidad de la recuperación solo aumenta. Los modelos potentes pueden generar respuestas convincentes incluso a partir de contextos débiles. Esto convierte la selección de fuentes, la actualidad y la trazabilidad en parte del sistema de seguridad y fiabilidad del agente.
Los desarrolladores no deberían elegir un proveedor de búsqueda basándose únicamente en un benchmark público o en una demostración impresionante de seguridad.
En su lugar, deben construir conjuntos de evaluación basados en escenarios reales.
Las tareas que realiza su agente.
Cubrir casos simples y difíciles:
Usar el mismo modelo, indicaciones, estrategia de herramientas y patrón de salida para cada proveedor.
Almacenar las fuentes devueltas antes de que el modelo las resuma. De lo contrario, no se puede determinar si el error proviene del proceso de recuperación o del razonamiento.
Medir latencia, tokens totales, número de llamadas de búsqueda repetidas, cobertura, respaldo de citas, actualidad y tasa de fallos.
Las tareas financieras, legales, de seguridad, médicas y de cumplimiento requieren revisión de expertos. La API de búsqueda puede mejorar la recopilación de pruebas, pero no puede asumir la responsabilidad profesional.
Deshabilitar una fuente, ralentizar una ruta, devolver contenido con formato incorrecto o inyectar resultados duplicados. La fiabilidad en producción depende del rendimiento del sistema cuando la recuperación es imperfecta.
AnySearch es un servicio de infraestructura de búsqueda en tiempo real diseñado para agentes de IA y desarrolladores. Ofrece búsqueda web, búsqueda vertical, búsqueda por lotes y extracción de texto completo con resultados estructurados.
Tiene un sitio web donde los usuarios pueden probar la búsqueda, pero su enfoque principal es la infraestructura para agentes. Las formas principales de integración incluyen API, MCP y un Skill instalable.
La documentación oficial del Skill y MCP indica que el acceso anónimo tiene límites de velocidad y cuotas reducidas. La clave API es opcional, pero se recomienda para un uso más habitual.
La documentación pública menciona finanzas, investigación académica, seguridad, información legal, código y otras categorías. Los agentes deben consultar el directorio de dominios admitidos antes de usar parámetros específicos.
Intenta enrutar las consultas antes de la recuperación, reducir fuentes duplicadas, priorizar resultados con alta densidad de información, eliminar ruido de página y devolver el contenido en formato Markdown estructurado. El ahorro real de tokens depende del contenido de la consulta y del flujo de trabajo más amplio del agente.
Esa puntuación fue reportada por AnySearch y replicada en el artículo original. Durante la verificación no se encontró un paquete de evaluación pública completo, por lo que el resultado debe considerarse como dato comparativo reportado por el proveedor.
No. Puede ayudar a recopilar información corporativa, legal, financiera y de riesgos públicos, pero los profesionales deben verificar identidad, autoridad de las fuentes, integridad, jurisdicción e interpretación.
El código base del Skill de AnySearch y del servidor MCP se publica bajo la licencia Apache-2.0. El backend alojado de la API es un servicio independiente que no está cubierto por la licencia de esos repositorios.
AnySearch trata la búsqueda como una capa de entrada para los agentes, no como una lista de páginas para que los humanos naveguen. Enruta consultas a través de fuentes generales y verticales, busca múltiples caminos, ordena y deduplica pruebas, elimina el ruido de la página y devuelve contenido estructurado a través de API, MCP o integración con Skill.
Los ejemplos del código fuente muestran por qué este diseño es fundamental para el descubrimiento de código en producción, la debida diligencia de empresas locales y los datos actuales de múltiples mercados. En cada caso, el agente necesita pruebas completas, oportunas y rastreables, no solo enlaces relevantes.
Su clasificación en Product Hunt y los resultados de pruebas comparativas reportados por el proveedor hacen que AnySearch merezca una prueba, pero los equipos deben reproducir los resultados comparativos con sus propias consultas, modelos, contabilidad de tokens y estándares de calidad antes de reemplazar su pila de recuperación en producción.
En los flujos de trabajo de agentes, el modelo decide cómo procesar las pruebas; la capa de búsqueda determina si las pruebas correctas llegan al modelo.
Empieza con una sola frase y obtén un sitio completo en minutos.
