Una herramienta de búsqueda web para agentes de IA que devuelve el texto de la página

¿Por qué un agente necesita el texto de la página y no solo los fragmentos?

Porque la respuesta rara vez está en el fragmento. Una página de resultados ofrece un título y una o dos líneas elegidas por el buscador. El número, la fecha o la regla por la que preguntó tu usuario aparecen más abajo en la página.

Un agente que solo ve fragmentos tiene dos malas opciones. Puede responder a partir de un fragmento y arriesgarse a equivocarse, o puede llamar a una segunda herramienta para obtener cada página. La segunda opción duplica los viajes de ida y vuelta y las definiciones de herramientas.

Con LLMWebSearch, las primeras páginas llegan ya leídas. Se eliminan la navegación, los anuncios y los banners de cookies, así que el modelo gasta sus tokens en el contenido. Los resultados restantes conservan sus fragmentos, que ayudan al modelo a decidir si vuelve a buscar.

¿Cómo debería definirse la herramienta de búsqueda?

Mantén el esquema pequeño: un query obligatorio y, como mucho, uno o dos conmutadores. Los modelos llaman de forma más fiable a herramientas sencillas. El ejemplo de abajo expone un flag recent que se corresponde con time_range=month; todo lo demás queda fijado en tu código.

La función devuelve texto plano, no JSON. Cada fuente empieza con un número, un título y una URL, seguidos de su Markdown. Ese formato hace que las citas como [2] sean naturales para el modelo.

Si tu agente ya incluye una herramienta llamada web_search, como hacen Claude Code y OpenClaw, dale otro nombre a la tuya, por ejemplo search_web. Dos herramientas con el mismo nombre confunden al modelo.

¿Cuándo debe buscar un agente y con qué frecuencia?

Busca cuando la respuesta dependa de hechos que cambian o que el modelo no puede conocer. Los precios, versiones, leyes, horarios y eventos recientes entran en esa categoría. Las definiciones y el conocimiento estable normalmente no.

Escribe esa regla en el system prompt y añade un presupuesto. Tres hábitos ayudan:

• Planifica antes de buscar. Pide al modelo que escriba primero sus consultas. Dos consultas precisas superan a cinco vagas.
• Limita las llamadas. Permite, por ejemplo, cuatro búsquedas por turno del usuario. Sube el límite solo para tareas de investigación.
• Detente cuando las fuentes coincidan. Si tres páginas independientes dicen lo mismo, el agente puede responder.

¿Cómo mantengo controlada la ventana de contexto?

Tres parámetros deciden cuánto texto llega al modelo. read fija cuántas páginas se leen, de 0 a 10. max_chars limita cada página, de 500 a 50 000 caracteres. max_results fija cuántos resultados se listan, de 1 a 20.

Para un agente de chat, read=3 con max_chars=4000 devuelve unos 12 000 caracteres de texto de página por búsqueda. Eso deja espacio para varias búsquedas en una conversación. Para una tarea de investigación que resume sobre la marcha, las páginas más largas van bien.

El campo word_count te indica cuánto medía la página completa antes del corte. El agente puede usarlo para decidir si obtiene más con el endpoint extract.

¿Qué pasa cuando no se puede leer una página?

El resultado sigue llegando, con su título, URL y fragmento, pero sin contenido. Un campo content_status explica por qué.

• blocked_by_robots: el robots.txt del sitio no permite nuestro lector.
• blocked_by_site_policy: Un sitio que establece Content-Signal: ai-input=no en su robots.txt mantiene las páginas de su sitio fuera del contenido de tus resultados.
• target_refused: el sitio respondió con una negativa; su estado está en target_status.
• fetch_failed o fetch_timeout: la página no cargó a tiempo.

Cuando un sitio rechaza a nuestro lector, el resultado vuelve sin contenido y con el estado del sitio: nunca resolvemos CAPTCHAs, iniciamos sesión en cuentas ni sorteamos un bloqueo o un paywall. Indica al agente que use el fragmento, u otra fuente, cuando una página vuelva vacía. La búsqueda en sí sigue siendo un crédito, pase lo que pase con cada página.

¿Por qué no usar la herramienta de búsqueda integrada en el modelo?

Las herramientas integradas son cómodas, pero te dan menos control. A 22 de octubre de 2026, la herramienta web_search de OpenAI cuesta $10 por 1000 llamadas más el contenido de búsqueda facturado como tokens de entrada. La búsqueda web de Claude de Anthropic también cuesta $10 por 1000 búsquedas más los costes de tokens. El grounding de Gemini 3 incluye 5000 búsquedas gratis al mes en el plan de pago y luego cuesta $14 por 1000.

Estas herramientas devuelven sobre todo una respuesta escrita con citas, no las páginas en bruto. Además, atan tu búsqueda a un único proveedor de modelo. Una herramienta independiente funciona con cualquier modelo y te deja fijar la longitud de cada página. La comparativa de herramientas integradas tiene la tabla completa.

¿Cuánto cuesta ejecutar un agente en LLMWebSearch?

Un crédito por búsqueda cuando read es 3 o menos. Un asistente usado por un equipo, que responde 100 preguntas al día con 4 búsquedas cada una, hace unas 12 000 búsquedas al mes. 25.000 búsquedas por 41,25 US$ cubre ese mes y buena parte del siguiente.

Un agente de programación usado por un desarrollador puede buscar 20 veces al día, o unas 600 veces al mes. 5.000 búsquedas por 9,25 US$ entonces dura varios meses, porque los créditos no caducan. La guía de costes muestra las cuentas para cargas de trabajo mayores.