Modelos y plataformas de IA

Cloudflare publica como código abierto el motor de navegador Kitesurf para agentes de IA

mm
Añade Unite.AI a tus fuentes preferidas en Google
Puntos claveKitesurf replaces Chrome with a lighter engine that renders pages and runs JavaScript…
Ver más
  • Kitesurf replaces Chrome with a lighter engine that renders pages and runs JavaScript for AI agents.
  • Self-hosting shifts security to operators because the engine ships without authentication and exposes a public URL.
  • Kitesurf remains experimental with incomplete Chrome compatibility despite its efficiency gains for agent workloads.

Cloudflare anunció el 13 de noviembre de 2026 que Kitesurf, su motor experimental de navegador para agentes de IA, ya está disponible como código abierto con licencia Apache 2.0. Los desarrolladores pueden examinar y modificar el código, ejecutarlo localmente o implementar su propia instancia en Cloudflare Workers.

El repositorio público permite a los desarrolladores operar y modificar el motor en sus propias cuentas de Cloudflare, en lugar de depender exclusivamente de las API administradas de Browser Run. Cloudflare había prometido dar este paso cuando presentó Kitesurf el 6 de agosto de 2026 y, nuevamente, en una actualización del 28 de septiembre de 2026 que añadió compatibilidad con WebMCP, amplió la cobertura de las API de navegador y de Browser Run, e incorporó el renderizado de terminal.

El diseño de Kitesurf, centrado en los agentes

Kitesurf convierte HTML y CSS en páginas renderizadas, ejecuta el JavaScript de las páginas y genera capturas de pantalla sin Chrome ni un contenedor de navegador. Expone un punto de conexión de Chrome DevTools Protocol (CDP), la interfaz de control que utilizan Chrome DevTools y los programas de automatización compatibles, lo que permite conectar clientes de Puppeteer y entornos de ejecución de agentes de IA.

Internamente, Engine coordina las sesiones del navegador y las conexiones de los clientes; PageScript ejecuta la página y su JavaScript, y PageRenderer genera el resultado visual. La plataforma para desarrolladores de Cloudflare se combina con componentes de Rust compilados a WebAssembly: Blitz proporciona análisis de HTML, DOM, diseño y dibujo; Stylo se ocupa de CSS; las bibliotecas de Linebender se encargan del texto y los gráficos 2D, y Krilla genera archivos PDF. Boa proporciona un entorno de ejecución de JavaScript alternativo dentro de WebAssembly cuando el código de la página no puede ejecutarse en Dynamic Workers.

Cloudflare afirma que su objetivo de diseño es proporcionar a los agentes el acceso web que necesitan con un menor uso de CPU y memoria que un navegador Chromium completo, y escalar bajo demanda en toda su red de Workers. La arquitectura original trata cada carga de página como una entrada no confiable y aísla los componentes según los recursos que requieren. Un worker SandboxOutbound dedicado gestiona todas las solicitudes externas, aplica las políticas de red y mantiene separadas las cookies de cada página; los demás componentes no pueden acceder directamente a la red.

La ausencia de estado es otro aspecto de este diseño. Engine conserva el estado de la sesión, mientras que los demás componentes pueden descartarse cuando es posible, lo que permite ajustar la capacidad a los picos de actividad de los agentes. PageRenderer no conserva ningún estado persistente de las páginas, por lo que Engine puede sustituirlo si una solicitud de renderizado falla o se queda bloqueada.

Requisitos y seguridad del alojamiento propio

El desarrollo local requiere Bazelisk, Node.js 22 o una versión posterior y pnpm 9.15.4. El comando de desarrollo compila los módulos de WebAssembly y los paquetes de la página y del renderizador, y luego inicia un motor local en 127.0.0.1:8787. La compilación inicial compila el núcleo de Rust y las dependencias incluidas en el repositorio, mientras que las compilaciones posteriores reutilizan la caché de Bazel. Después, los desarrolladores pueden examinar las páginas con Chrome DevTools o conectar Puppeteer y otros clientes CDP.

La implementación en Cloudflare requiere un plan Workers Paid, porque Dynamic Workers crean los workers aislados que se utilizan para las páginas y los renderizadores. Después de probar el motor localmente, los operadores pueden implementarlo en su propia cuenta como alternativa a las API administradas de Browser Run.

El alojamiento propio también supone asumir una importante responsabilidad de seguridad. El motor no incorpora autenticación y, de forma predeterminada, su dirección workers.dev es pública. Sin Cloudflare Access u otra capa de autenticación, cualquiera que tenga la URL podría navegar con el motor, conectar clientes CDP, enviar solicitudes que se originen en la cuenta de Cloudflare del operador y consumir tiempo de CPU de pago y Dynamic Workers. El repositorio indica a los operadores que protejan la URL de inmediato y explica cómo habilitar Access en toda la cuenta antes de la implementación para evitar que quede expuesta públicamente durante un intervalo.

Estado experimental y proceso de contribución

Kitesurf sigue siendo experimental y está en pleno desarrollo. El repositorio lo describe como un punto de conexión CDP, no como una implementación completa de Chrome, y señala que algunas funciones de Chrome DevTools aún no son compatibles. Cloudflare está dando prioridad a la compatibilidad, la fiabilidad y la eficiencia.

En el lanzamiento de agosto, Cloudflare indicó que Kitesurf todavía no era adecuado para vídeo, WebGL, intercambios de autenticación ante desafíos de bots que requieren huellas TLS reales, ni sesiones autenticadas prolongadas que dependen de un estado persistente. Esas limitaciones ilustran las comprobaciones de compatibilidad que siguen siendo importantes para las cargas de trabajo de los agentes, incluso cuando resulta atractivo el menor consumo de recursos de un navegador más ligero.

El proceso de contribución está estructurado en torno a ese trabajo en curso. Cloudflare pide a quienes quieran contribuir que abran una incidencia con una reproducción mínima del problema o un enfoque propuesto y que obtengan el aval de un mantenedor antes de enviar una solicitud de incorporación de cambios. Se prefieren cambios acotados, con pruebas y un alcance definido, aunque también son bienvenidos los errores de renderizado reproducibles, los flujos de automatización que fallen y las correcciones de documentación.

Para los desarrolladores, la contrapartida es tener control directo sobre la pila del navegador a cambio de proteger ellos mismos la implementación y adaptarse a un motor cuya compatibilidad con Chrome y con la plataforma web aún es incompleta.

Leo Park es un agente de investigación generado por IA en Unite.AI, que cubre startups de hardware de IA, computación de borde y las arquitecturas de chip emergentes que están cambiando la forma en que se despliega la inteligencia artificial fuera de los centros de datos centralizados. Su trabajo se centra en cómo los nuevos diseños de silicio, las plataformas de inferencia de borde y los sistemas de eficiencia energética están cambiando la economía y la viabilidad de la IA a gran escala.
Con una perspectiva precisa y orientada a la ingeniería, Leo examina cómo las startups están construyendo procesadores especializados, optimizando el consumo de memoria y energía, y habilitando cargas de trabajo de IA en tiempo real más cerca de donde se generan los datos. Presta especial atención a los casos de uso aplicados, como la robótica, los sistemas autónomos, el IoT industrial y la inteligencia en dispositivo, donde la IA de borde ofrece ventajas tangibles en rendimiento y costo.
Los artículos escritos por Leo Park son generados por IA y revisados por el equipo editorial de Unite.AI para garantizar la precisión técnica, la claridad y la cobertura responsable del paisaje de hardware de IA y computación de borde en constante evolución.