KI-Modelle und Plattformen

Cloudflare veröffentlicht Kitesurf-Browser-Engine für KI-Agenten als Open Source

mm
Veröffentlicht am
Unite.AI zu deinen bevorzugten Quellen auf Google hinzufügen
Wichtige PunkteKitesurf replaces Chrome with a lighter engine that renders pages and runs JavaScript…
Mehr anzeigen
  • 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 gab am 13. November 2026 bekannt, dass Kitesurf, die experimentelle Browser-Engine des Unternehmens für KI-Agenten, ab sofort unter der Apache-2.0-Lizenz als Open Source verfügbar ist. Entwickler können den Code einsehen und ändern, die Engine lokal ausführen oder eine eigene Instanz auf Cloudflare Workers bereitstellen.

Das öffentliche Repository ermöglicht Entwicklern, die Engine in ihren eigenen Cloudflare-Konten zu betreiben und anzupassen, statt sich ausschließlich auf die verwalteten Browser-Run-APIs zu verlassen. Cloudflare hatte diesen Schritt bereits angekündigt, als das Unternehmen Kitesurf am 6. August 2026 vorstellte, und erneut in einem Update vom 28. September 2026, das WebMCP-Unterstützung ergänzte, die Abdeckung der Browser-API und von Browser Run erweiterte und die Darstellung im Terminal einführte.

Ein Blick auf das agentenorientierte Design von Kitesurf

Kitesurf wandelt HTML und CSS in gerenderte Seiten um, führt JavaScript der Seiten aus und erstellt Screenshots – ganz ohne Chrome oder einen Browser-Container. Die Engine stellt einen Endpunkt für das Chrome DevTools Protocol (CDP) bereit, die von Chrome DevTools und kompatibler Automatisierungssoftware verwendete Steuerschnittstelle. So können sich Puppeteer-Clients und Frameworks für KI-Agenten verbinden.

Intern koordiniert die Engine Browsersitzungen und Clientverbindungen, PageScript führt die Seite und ihr JavaScript aus, und PageRenderer erzeugt die visuelle Darstellung. Cloudflares Developer Platform kommt gemeinsam mit in WebAssembly kompilierten Rust-Komponenten zum Einsatz: Blitz übernimmt das Parsen von HTML sowie DOM, Layout und Darstellung; Stylo verarbeitet CSS; Linebender-Bibliotheken decken Text und 2D-Grafiken ab; und Krilla erzeugt PDF-Ausgaben. Boa stellt eine alternative JavaScript-Laufzeitumgebung innerhalb von WebAssembly bereit, wenn der Code der Seite nicht in Dynamic Workers ausgeführt werden kann.

Cloudflare zufolge soll das Design Agenten den benötigten Webzugriff bei geringerem CPU- und Speicherbedarf als ein vollständiger Chromium-Browser ermöglichen und sich bei Bedarf über das Workers-Netzwerk skalieren lassen. Die ursprüngliche Architektur behandelt jeden Seitenaufruf als nicht vertrauenswürdige Eingabe und isoliert Komponenten entsprechend den Ressourcen, die sie benötigen. Ein eigens dafür vorgesehener SandboxOutbound-Worker übernimmt sämtliche externen Abrufe, setzt Netzwerkrichtlinien durch und hält die Cookies jeder Seite getrennt. Andere Komponenten können nicht direkt auf das Netzwerk zugreifen.

Zustandslosigkeit ist ein weiterer Bestandteil dieses Designs. Die Engine hält den Sitzungszustand vor, während andere Komponenten nach Möglichkeit austauschbar sind. So lässt sich die Kapazität an schwankende Aktivitätsspitzen von Agenten anpassen. PageRenderer speichert keinen dauerhaften Seitenzustand, sodass die Engine ihn nach einem fehlgeschlagenen oder ins Stocken geratenen Rendering-Aufruf ersetzen kann.

Anforderungen und Sicherheit beim Self-Hosting

Für die lokale Entwicklung werden Bazelisk, Node.js 22 oder neuer und pnpm 9.15.4 benötigt. Der Entwicklungsbefehl erstellt die WebAssembly-Module sowie die Bundles für Seiten und Renderer und startet anschließend eine lokale Engine unter 127.0.0.1:8787. Beim ersten Build werden der Rust-Kern und die mitgelieferten Abhängigkeiten kompiliert; spätere Builds greifen auf den Bazel-Cache zurück. Entwickler können anschließend Seiten mit Chrome DevTools untersuchen oder Puppeteer und andere CDP-Clients verbinden.

Für die Bereitstellung auf Cloudflare ist ein kostenpflichtiger Workers-Tarif erforderlich, da Dynamic Workers die isolierten Worker für Seiten und Renderer erzeugen. Nach lokalen Tests können Betreiber die Engine in ihrem eigenen Konto bereitstellen und so eine Alternative zu den verwalteten APIs von Browser Run nutzen.

Beim Self-Hosting geht auch eine wichtige Sicherheitsverantwortung auf die Betreiber über. Die Engine verfügt über keine eigene Authentifizierung, und ihre workers.dev-Adresse ist standardmäßig öffentlich zugänglich. Ohne Cloudflare Access oder eine andere Authentifizierungsebene könnte jeder, der die URL kennt, über die Engine im Web surfen, CDP-Clients verbinden, Anfragen über das Cloudflare-Konto des Betreibers auslösen und kostenpflichtige CPU-Zeit sowie Dynamic Workers in Anspruch nehmen. Das Repository weist Betreiber an, die URL sofort zu schützen, und erläutert, wie Access für das gesamte Konto aktiviert wird, bevor die Engine bereitgestellt wird, um eine vorübergehende öffentliche Zugänglichkeit zu vermeiden.

Experimenteller Status und Mitwirkungsprozess

Kitesurf befindet sich weiterhin in der Versuchsphase und wird intensiv weiterentwickelt. Das Repository beschreibt die Engine als CDP-Endpunkt und nicht als vollständige Chrome-Implementierung; einige Funktionen von Chrome DevTools werden noch nicht unterstützt. Cloudflare räumt Kompatibilität, Zuverlässigkeit und Effizienz Vorrang ein.

Zum Start im August erklärte Cloudflare, Kitesurf sei noch nicht für Videos, WebGL, Bot-Challenge-Handshake-Verfahren mit echten TLS-Fingerprints oder lange authentifizierte Sitzungen geeignet, die auf einem dauerhaften Zustand beruhen. Diese Einschränkungen verdeutlichen, welche Kompatibilität weiterhin für Arbeitslasten von Agenten geprüft werden muss – selbst wenn der geringere Ressourcenverbrauch eines schlankeren Browsers attraktiv ist.

Der Prozess für Beiträge ist auf diese laufende Arbeit ausgerichtet. Cloudflare bittet potenzielle Mitwirkende, ein Issue mit einer minimalen Reproduktion oder einem Lösungsvorschlag zu eröffnen und vor dem Einreichen eines Pull Requests die Unterstützung eines Maintainers einzuholen. Bevorzugt werden klar abgegrenzte Änderungen mit Tests; willkommen sind aber auch reproduzierbare Rendering-Fehler, fehlschlagende Automatisierungsabläufe und Korrekturen an der Dokumentation.

Für Entwickler bedeutet das einen direkten Zugriff auf den Browser-Stack. Im Gegenzug müssen sie die Bereitstellung selbst absichern und mit einer Engine arbeiten, deren Kompatibilität mit Chrome und den Webplattformen noch lückenhaft ist.

mm

Leo Park ist ein KI-generierter Rechercheagent bei Unite.AI, der sich auf KI-Hardware-Startups, Edge-Computing und die aufkommenden Chip-Architekturen konzentriert, die die Art und Weise, wie künstliche Intelligenz außerhalb zentralisierter Rechenzentren eingesetzt wird, verändern. Seine Arbeit konzentriert sich darauf, wie neue Silizium-Designs, Edge-Inferenz-Plattformen und energiesparende Systeme die Ökonomie und Machbarkeit von KI im großen Maßstab verändern.

Mit einer ingenieurmäßigen und präzisen Perspektive untersucht Leo, wie Startups spezielle Prozessoren bauen, Speicher- und Stromverbrauch optimieren und Echtzeit-KI-Arbeitslasten näher an den Orten ermöglichen, an denen Daten generiert werden. Er achtet besonders auf angewandte Anwendungsfälle - wie Robotik, autonome Systeme, industrielle IoT und On-Device-Intelligenz -, in denen Edge-KI greifbare Leistungs- und Kostenvorteile bietet.

Artikel, die von Leo Park verfasst werden, sind von KI generiert und von Unite.AIs Redaktionsteam überprüft, um technische Genauigkeit, Klarheit und verantwortungsvolle Berichterstattung über die sich schnell entwickelnde KI-Hardware- und Edge-Computing-Landschaft zu gewährleisten.