Cloudflare открывает исходный код браузерного движка Kitesurf для ИИ-агентов

13 ноября 2026 года Cloudflare объявила, что экспериментальный браузерный движок Kitesurf для ИИ-агентов теперь доступен с открытым исходным кодом по лицензии Apache 2.0. Разработчики могут изучать и изменять код, запускать его локально или развернуть собственный экземпляр на Cloudflare Workers.

Публичный репозиторий позволяет разработчикам запускать движок и вносить в него изменения в своих аккаунтах Cloudflare, не полагаясь исключительно на управляемые API Browser Run. Cloudflare обещала сделать этот шаг, когда представила Kitesurf 6 августа 2026 года, а затем подтвердила это в обновлении от 28 сентября 2026 года, в котором добавила поддержку WebMCP, расширила охват браузерных API и Browser Run и реализовала вывод в терминал.

Архитектура Kitesurf, ориентированная на ИИ-агентов

Kitesurf преобразует HTML и CSS в отображаемые страницы, выполняет JavaScript-код страниц и создаёт снимки экрана без Chrome и контейнера браузера. Движок предоставляет конечную точку Chrome DevTools Protocol (CDP) — интерфейс управления, используемый Chrome DevTools и совместимыми программами автоматизации. К ней могут подключаться клиенты Puppeteer и среды запуска ИИ-агентов.

Внутри системы Engine координирует сеансы браузера и подключения клиентов, PageScript выполняет код страницы и её JavaScript, а PageRenderer формирует визуальный результат. Платформа разработчика Cloudflare объединена с компонентами на Rust, скомпилированными в WebAssembly: Blitz обеспечивает разбор HTML, работу с DOM, компоновку и отрисовку; Stylo обрабатывает CSS; библиотеки Linebender отвечают за текст и двухмерную графику; Krilla создаёт файлы PDF. Boa предоставляет резервную среду выполнения JavaScript в WebAssembly, если код страницы не может выполняться в Dynamic Workers.

По словам Cloudflare, цель этой разработки — предоставить агентам необходимый доступ к вебу при меньшем потреблении ресурсов процессора и памяти, чем у полноценного браузера Chromium, и при этом масштабировать систему по мере необходимости в сети Workers. Изначальная архитектура рассматривает каждую загрузку страницы как недоверенные входные данные и изолирует компоненты в соответствии с необходимыми им ресурсами. Специальный обработчик SandboxOutbound выполняет все внешние запросы, соблюдая сетевые политики и обеспечивая раздельное хранение файлов cookie каждой страницы; остальные компоненты не могут напрямую обращаться к сети.

Ещё одна особенность этой архитектуры — отсутствие сохранения состояния. Engine хранит состояние сеансов, тогда как остальные компоненты по возможности можно удалять и создавать заново, благодаря чему производительность системы можно подстраивать под всплески активности агентов. PageRenderer не хранит постоянное состояние страниц, поэтому после сбоя или зависания запроса на отрисовку Engine может заменить его.

Требования к самостоятельному размещению и безопасность

Для локальной разработки необходимы Bazelisk, Node.js версии 22 или новее и pnpm версии 9.15.4. Команда разработки собирает модули WebAssembly, а также пакеты страницы и средства визуализации, после чего запускает локальный движок по адресу 127.0.0.1:8787. При первой сборке компилируются ядро на Rust и включённые в проект зависимости, а последующие сборки используют кэш Bazel. Затем разработчики могут просматривать страницы в Chrome DevTools или подключать Puppeteer и другие клиенты CDP.

Для развёртывания на Cloudflare требуется платный тариф Workers, поскольку Dynamic Workers создают изолированные рабочие процессы, используемые для страниц и средств визуализации. После локального тестирования операторы могут развернуть движок в своём аккаунте как альтернативу управляемым API Browser Run.

Самостоятельное размещение также возлагает на пользователя важную ответственность за безопасность. У движка нет собственной аутентификации, а его адрес workers.dev по умолчанию общедоступен. Без Cloudflare Access или другого уровня аутентификации любой, у кого есть URL, сможет просматривать веб-страницы через движок, подключать клиенты CDP, отправлять запросы от имени аккаунта Cloudflare оператора и расходовать оплачиваемое процессорное время и ресурсы Dynamic Workers. В репозитории операторам настоятельно рекомендуют немедленно защитить URL и объясняют, как включить Access для всего аккаунта до развёртывания, чтобы адрес не оставался общедоступным ни на какое время.

Экспериментальный статус и процесс внесения изменений

Kitesurf остаётся экспериментальным проектом, который активно развивается. В репозитории он описан как конечная точка CDP, а не полноценная реализация Chrome; некоторые функции Chrome DevTools пока не поддерживаются. Cloudflare уделяет приоритетное внимание совместимости, надёжности и эффективности.

Во время августовского запуска Cloudflare сообщила, что Kitesurf пока не подходит для работы с видео и WebGL, рукопожатий при проверке на ботов, требующих настоящих TLS-отпечатков, а также длительных аутентифицированных сеансов, зависящих от сохранения состояния. Эти ограничения показывают, какие проверки совместимости по-прежнему важны для задач с участием агентов, даже если меньшая ресурсоёмкость облегчённого браузера выглядит привлекательной.

Процесс внесения изменений организован с учётом этой продолжающейся работы. Cloudflare просит потенциальных участников сначала создать issue с минимальным примером для воспроизведения проблемы или предлагаемым подходом, а перед отправкой запроса на включение изменений получить одобрение сопровождающего проекта. Предпочтительны точечные изменения с тестами и чётко определённым объёмом, однако Cloudflare также приветствует ошибки отрисовки, которые можно воспроизвести, сбои сценариев автоматизации и исправления документации.

Для разработчиков компромисс заключается в том, что они получают прямой контроль над браузерным стеком, но должны самостоятельно обеспечивать безопасность развёртывания и учитывать, что совместимость движка с Chrome и веб-платформой пока неполная.