Cloudflare Dynamic Workers: быстрые песочницы AI агентов

Cloudflare выпустил Dynamic Workers - изолированные среды для выполнения кода AI-агентов. Запуск за 5 мс, в 100 раз быстрее контейнеров.

Денис Расулев · Mar 30, 2026 ·

/images/2026/cloudflare-dynamic-workers.jpg

Cloudflare Dynamic Workers Explained

Cloudflare недавно выпустил в открытую бету Dynamic Workers - быстрые песочницы для AI агентов. Компания утверждает, что они работают в 100 раз быстрее обычных контейнеров при выполнении кода, сгенерированного AI-агентами. Заявление довольно серьёзное. Давай разберёмся, что за ним стоит.

Контейнеры слишком тяжёлые для AI-агентов

Современные AI агенты не просто отвечают на вопросы, они могут писать и выполнять код на лету. Агент может сгенерировать небольшой скрипт, чтобы вызвать API, обработать данные или выполнить задачу. Этот код нужно где-то запустить на выполнение. С точки зрения безопасности, делать это лучше в sandbox, изолированно от всей остальной системы.

Стандартный подход, используемый сегодня: поднять свой контейнер для каждой задачи. Контейнеры работают, но при этом имеют некоторые проблемы:

Холодный запуск (cold start) занимает сотни миллисекунд.
Каждый такой контейнер потребляет очень много памяти.
Чтобы избежать задержек, контейнеры держат «прогретыми», но тогда приходится платить за них, даже когда они простаивают.
Чтобы сэкономить, контейнеры переиспользуют между задачами, а это ослабляет изоляцию и создает проблемы с безопасностью.

Когда у твоей системы несколько десятков пользователей, то обычно это не проблема. Но если ты строишь продукт, где миллионы запросов от людей одновременно запускают множество AI агентов, вот тогда контейнеры становятся узким местом.

V8 Isolates вместо контейнеров

Cloudflare Dynamic Workers обходятся без контейнеров вообще. Вместо них используются V8 isolates. Это тот же движок JavaScript, на котором работает Google Chrome и вся платформа Cloudflare Workers (которая крутится на этой технологии уже восемь лет).

Немного цифр для понимания:

	Контейнер	Dynamic Worker
Время запуска	~500 мс	~5 мс
Потребление памяти	Сотни МБ	Несколько МБ
Лимиты на параллельность	Часто ограничены	Без ограничений
Расположение	Отдельная машина	Та же машина, тот же поток

Dynamic Worker поднимается за миллисекунды, выполняет код, возвращает результат и исчезает. Никаких прогретых пулов, никаких расходов на простой, никаких компромиссов с переиспользованием.

Вот простая аналогия, которая поможет понять суть: запускать полноценный контейнер для быстрой AI-задачи, это как снимать пятикомнатную квартиру, чтобы сделать один телефонный звонок. Dynamic Worker, это телефонная будка. Зашёл, позвонил, вышел, всё.

Как это работает

У тебя есть родительский Worker (основное приложение), который принимает запросы. Когда ему нужно выполнить код, сгенерированный AI, он вызывает Dynamic Worker Loader API, который создаёт изолированную среду на лету.

Допустим, ты делаешь чат-бота для поддержки клиентов. Клиент задаёт сложный вопрос, для ответа на который нужно обратиться к нескольким API. LLM генерирует короткую TypeScript-функцию, а родительский Worker запускает её в sandbox:

// Родительский Worker получает запрос клиента
const worker = env.LOADER.load({
  compatibilityDate: "2026-03-01",
  mainModule: "agent.js",
  modules: { "agent.js": llmGeneratedCode },

  // Даём sandbox доступ только к API заказов
  env: { ORDER_API: env.ORDER_SERVICE },

  // Блокируем весь остальной доступ в интернет
  globalOutbound: null,
});

// Выполняем и получаем результат
const result = await worker.getEntrypoint().handleQuery(customerId);

Sandbox получает доступ только к тому, что ты явно ему передал. Никакого доступа в интернет, никаких учётных данных от базы, никакой возможности выйти за пределы определённого интерфейса. Даже если кто-то заставит LLM сгенерировать вредоносный код, sandbox ограничит его возможности.

Зачем вообще генерировать код?

Конечно, для простого запроса типа “где мой заказ?” можно заранее написать обработчик. Готовый код быстрее, дешевле и гораздо предсказуемее. Тогда в каких случаях имеет смысл именно динамическая генерация кода? Вот несколько примеров:

Непредсказуемые запросы. Клиент спрашивает: “Я заказал синюю куртку во вторник, потом поменял на чёрную и ещё добавил шарф, можешь проверить, прошли ли эти изменения, и сказать, когда всё приедет?” Ни один заранее написанный обработчик не покроет такую комбинацию. А вот LLM сможет сама определить нужную последовательность API вызовов и собрать их на месте.

Большая поверхность API. Если у платформы 200+ эндпоинтов, покрывающих заказы, возвраты, платежи, подписки и программы лояльности, поддерживать готовые обработчики для каждого возможного запроса, это огромный объём инженерной работы. С генерацией кода ты просто описываешь типизированный API, а LLM собирает нужные вызовы по запросу.

Мультитенантная логика. У разных клиентов разные правила. Один ритейлер принимает возвраты 30 дней, другой 14, третий только для определённых категорий. Вместо построения сложного движка правил, покрывающего все варианты, LLM генерирует код, который применяет нужные правила для конкретного контекста.

Меняющиеся интеграции. Ты подключаешь нового перевозчика или платёжного провайдера. С готовыми обработчиками это значит обновлять код, тестировать, деплоить. С генерацией кода ты обновляешь TypeScript-определение API, и LLM подхватывает изменения сразу.

На практике большинство команд будут использовать оба подхода: типовые запросы обрабатываются готовым кодом, а сложные или нестандартные уходят на LLM. Ты платишь за генерацию кода только тогда, когда она действительно нужна.

Идея “Code Mode”

Dynamic Workers, это часть более широкой концепции, которую Cloudflare называет “Code Mode”. Вместо того чтобы LLM делала множество последовательных tool calls (вызвать API A, подождать, вызвать API B, подождать, вызвать API C), агент пишет один скрипт, который связывает всё вместе, выполняет все за один проход и возвращает только финальный результат.

Cloudflare утверждает, что такой подход сокращает потребление токенов на 81% по сравнению с последовательными tool calls. Их собственный MCP сервер работает именно так: он открывает доступ ко всему Cloudflare API всего через два инструмента (search и execute), работа с которыми стоит менее чем 1 000 токенов. Агент пишет TypeScript против типизированного API, запускает его в Dynamic Worker, и только результат возвращается в контекстное окно. Промежуточные шаги до LLM не доходят.

TypeScript вместо OpenAPI

Cloudflare использует TypeScript интерфейсы вместо OpenAPI спецификаций для описания API, доступных агенту.

API чат-комнаты в виде TypeScript интерфейса занимает около 15 строк. Эквивалентная OpenAPI спецификация, это более 60 строк YAML. TypeScript компактнее, легче читается и для людей, и для LLM, и расходует меньше токенов на каждый вызов API. Если у тебя миллионы взаимодействий агентов, эта разница становится очень заметна в конечном итоге.

Вспомогательные библиотеки

Вместе с runtime Cloudflare выпустил три npm пакета:

@cloudflare/codemode оборачивает создание sandbox и интеграцию с MCP серверами; он может взять существующий MCP сервер и свернуть все его инструменты в единственный code() tool.
@cloudflare/worker-bundler разрешает npm зависимости прямо в runtime, так что код, сгенерированный агентом, может импортировать сторонние библиотеки вроде Hono или Stripe SDK без предварительной настройки.
@cloudflare/shell предоставляет виртуальную файловую систему внутри Dynamic Worker (на базе SQLite и R2) с типизированными методами для работы с файлами. Файловая система поддерживает транзакционную пакетную запись: если любая операция в пакете падает, все остальные откатываются.

Модель безопасности

Cloudflare вполне открыто говорит и о том, где им пришлось пойти на компромиссы. Дело в том, что уязвимости в V8 встречаются чаще, чем в гипервизорах. Так что их план защиты состоит из нескольких уровней:

Патчи безопасности V8 попадают в продакшен за считанные часы (быстрее, чем в самом Chrome).
Кастомный второй слой sandbox с динамическим разделением арендаторов по уровню риска.
Аппаратная защита памяти через MPK (Memory Protection Keys).
Защита от Spectre, разработанная совместно с исследователями.
Автоматическое сканирование кода, блокирующее вредоносные паттерны.

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

Ограничения

Пока Dynamic Workers эффективно работают только с JavaScript. Python и WebAssembly технически поддерживаются, но они существенно медленнее для коротких фрагментов кода. Большая часть AI экосистемы живёт на Python, особенно data science и ML-пайплайны. Для таких задач это не подходит.

Кроме того, слой выполнения кода привязан к Cloudflare. Твои базы данных, API и LLM провайдеры могут быть где угодно, но sandbox для выполнения кода работает только на инфраструктуре Cloudflare. Так что для их использования будет нужен платный Workers plan.

Стоимость

Dynamic Workers стоят $0.002 в день за каждый уникальный загруженный Worker, плюс стандартные расходы на CPU и вызовы. Но на время беты плата за Worker не взимается, так что можно экспериментировать. Начать рекомендую с раздела “Документация и начало работы”.

Для разовой генерации кода стоимость выполнения ничтожна по сравнению со стоимостью инференса для генерации самого кода. Вызов LLM может стоить несколько центов. Выполнение в sandbox - доли цента.

Кому это нужно?

Не всем.

Высоконагруженные потребительские продукты - это главная целевая аудитория. E-commerce-платформы, потребительский SaaS, мессенджеры, крупные маркетплейсы, финтех-приложения с миллионами пользователей. Паттерн: множество мелких независимых AI-задач, которые пользователи запускают одновременно.

Мультитенантные платформы - вторая возможная аудитория. Компании, которые дают своим клиентам строить кастомные автоматизации. Даже если нагрузка от каждого отдельного клиента невелика, тысячи арендаторов с собственным кодом суммарно дают серьёзную нагрузку. Контейнеры на таких объёмах становятся дорогими. Так что изоляты вполне помогут сэкономить ресурсы.

Корпоративные AI-инструменты с умеренным числом пользователей? Скорее всего, не целевая аудитория. Если твои параллельные выполнения агентов измеряются сотнями, а не сотнями тысяч, разница между 5 мс и 500 мс cold start не имеет значения. Контейнер, serverless функция или даже выполнение логики прямо в workflow engine, вполне прекрасно будут работать и без Dynamic Workers.

Общая картина

Рынок AI-инфраструктуры разделяется по типу нагрузки. Одни вендоры строят долгоживущие среды для агентов с постоянной памятью и stateful выполнением. Cloudflare движется в противоположном направлении: одноразовое выполнение, которое появляется мгновенно и исчезает после использования.

Думаю, оба подхода будут сосуществовать, но Cloudflare делает конкретную ставку: что компаний, которым нужны миллионы параллельных короткоживущих выполнений агентов, будет становиться всё больше. Если они правы, Dynamic Workers могут незаметно стать стандартным строительным блоком для следующей волны AI продуктов.

Но даже если и нет, это всё равно красивая технология в поисках более широкой аудитории.