У Cloudflare намагаються відповісти на просте, але фундаментальне запитання: як дати AI-агентам «руки», щоб вони могли безпечно й ефективно працювати з реальними сервісами та великими API. Інженер Cloudflare Метт Кері, який займається MCP та агентами, описує еволюцію від класичного function calling до нового підходу, який у компанії назвали codemode. Його суть — замість тисяч окремих інструментів агент пише TypeScript-код проти типізованого SDK, а цей код виконується в ізольованих sandbox-оточеннях на базі V8 Workers.
Цей зсув — від «агент викликає інструменти» до «агент генерує й запускає код» — може радикально змінити те, як AI-системи інтегруються з інфраструктурою, але водночас вимагає нових безпекових примітивів і способів обмеження доступу.
Від вибуху тулів до codemode: чому SDK перемагає тисячі інструментів
Початкова спроба Cloudflare зробити «кожен API — інструментом для агентів» виглядала цілком логічно: взяти OpenAPI-специфікацію, перетворити кожен endpoint на MCP tool і віддати це агенту. На практиці це виявилося глухим кутом.
OpenAPI Cloudflare — це приблизно 2,3 млн токенів і близько 2600 endpoint’ів. Наївна конверсія всього цього у схеми MCP-інструментів дала близько 1,1 млн токенів описів тулів. Навіть для найбільших сучасних моделей це фактично руйнує контекстне вікно: агент просто не може одночасно «тримати в голові» таку кількість структурованих описів.
Щоб обійти цю межу, Cloudflare пішла шляхом, який сьогодні обрали багато провайдерів: розбила API на продуктові MCP-сервери. У компанії швидко з’явилося 16 таких серверів, які разом покривали приблизно 2500 endpoint’ів. Але кожен сервер давав лише частковий доступ: наприклад, продуктова група могла мати шість інструментів у MCP, тоді як реальний API для цього продукту містив 30 endpoint’ів. Користувачам доводилося вручну обирати потрібний MCP-сервер, а повного покриття все одно не було.
Цей досвід привів Cloudflare до висновку: проблема не стільки в MCP як протоколі, скільки в тому, як агенти використовують контекст. Завантажувати сотні чи тисячі тулів у prompt — хибний шлях. Потрібен інший інтерфейс між агентом і сервісом.
Codemode став відповіддю на це: замість того, щоб описувати кожен endpoint як окремий інструмент, Cloudflare генерує компактний типізований SDK з OpenAPI, а агенту пропонується писати TypeScript-код проти цього SDK.
Типи виявилися надзвичайно стислим способом описати вхідні й вихідні дані. Замість сотень тисяч токенів схем інструментів агент отримує:
- короткий набір інструкцій, як користуватися SDK;
- сам SDK з типами для всіх endpoint’ів.
У публічному блозі про codemode Cloudflare показала, що таким чином можна дати агенту доступ до всього API приблизно в межах 1000 токенів. Для порівняння: повний набір MCP-інструментів для того ж API займав би понад мільйон токенів.
З погляду агента це виглядає так: замість того, щоб обирати з довгого списку інструментів на кшталт create_worker, list_workers, update_route, він бачить типізований клієнт, наприклад cloudflare.workers.list() чи cloudflare.workers.create(), і просто пише код, який викликає потрібні методи.
Як працює codemode: агент як програміст TypeScript
У codemode агент отримує роль умовного junior-розробника, який вміє читати типи й писати код за їхньою підказкою. Cloudflare генерує TypeScript SDK з OpenAPI-специфікації: кожен endpoint перетворюється на типізований метод з чітко визначеними параметрами та структурою відповіді.
Далі сценарій виглядає так. Користувач формулює запит, наприклад: «Покажи всі мої Workers» або «Створи новий Worker і захисти його через Access». Агент отримує цей запит, бачить типи SDK і генерує невеликий TypeScript-фрагмент, який:
- імпортує клієнт Cloudflare;
- викликає потрібні методи, наприклад
listWorkersабоcreateWorker; - обробляє результат і повертає його у зручному для користувача вигляді.
У демонстраціях Cloudflare агент міг, наприклад, згенерувати код для переліку всіх Workers в акаунті, а потім — для деплою нового «Hello world» Worker’а й додавання до нього політики доступу через Cloudflare Access. Усе це — без ручного написання коду людиною, лише на основі типів SDK.
Ключовий момент: агенту не потрібно знати напам’ять тисячі endpoint’ів. Він бачить типи, назви методів, сигнатури параметрів і вчиться будувати правильні виклики. Поліпшення якості моделей чи OpenAPI-специфікацій автоматично покращує й якість згенерованого коду, без необхідності переписувати MCP-інструменти.
Цей підхід дозволяє Cloudflare надати через один клієнт read-only доступ до всього API — понад 2000 endpoint’ів — не розбиваючи його на десятки серверів і не змушуючи користувача думати про структуру MCP-сервісів.
Але як тільки агент починає писати й виконувати код, постає головне запитання: де й як безпечно запускати цей код?
WorkerD: V8-сендбокс як безпечний двигун для агентського коду
Ідея «просто дати агенту писати код і виконувати його» виглядає привабливо, але з точки зору безпеки це майже кошмарний сценарій. Мова йде про неоглянутий, згенерований LLM код, який потенційно має доступ до секретів, файлової системи, мережі та ресурсів інфраструктури.
Cloudflare перераховує ризики, які тут виникають:
код може читати файли й секрети, до яких не мав би мати доступ;
може ексфільтрувати ці секрети через мережеві запити;
може запускати нескінченні цикли й виснажувати ресурси;
може виконувати небажані обчислення, аж до запуску криптомайнерів.
Традиційні способи пом’якшення цих ризиків — власні DSL, складні JSON-специфікації замість коду, важкі віртуальні машини, ручний code review — або обмежують виразність, або надто дорогі й повільні для інтерактивних агентів.
Cloudflare робить ставку на власну інфраструктурну «цеглинку» — V8 Workers. У компанії є можливість виконувати JavaScript/TypeScript-код у ізольованих V8-ізолятах, які працюють як легковагові sandbox-оточення. Для сценарію з агентами Cloudflare використовує так звані динамічні воркери, або WorkerD: це можливість створити й запустити Worker безпосередньо зі строкового коду.
По суті, агент генерує TypeScript (який компілюється до JavaScript), а Cloudflare запускає цей код у WorkerD — ізольованому середовищі, яке можна тонко налаштувати. Це дозволяє:
обмежити те, що код бачить у змінних середовища;
контролювати, чи має він доступ до мережі;
гарантувати, що код не може вийти за межі свого sandbox’у й торкнутися іншої інфраструктури.
V8-ізоляти добре вивчені й широко використовуються в індустрії, тож Cloudflare може спиратися на вже існуючу модель безпеки, замість винаходити власну віртуальну машину для агентів.
Тонкі налаштування sandbox: process.env, мережа й «радіус ураження»
Справжня сила WorkerD для агентських сценаріїв — у можливості дуже детально налаштовувати середовище виконання для кожного окремого воркера. Cloudflare описує кілька ключових важелів контролю.
По-перше, це доступ до process.env. Динамічний воркер може бути сконфігурований так, щоб:
повністю приховати змінні середовища від згенерованого коду;
або, навпаки, надати доступ лише до обмеженого набору секретів, які потрібні для конкретного сценарію.
Це дозволяє, наприклад, дати агенту можливість працювати з певним API-ключем, не відкриваючи йому всі секрети, які існують у системі.
По-друге, це мережевий доступ. За замовчуванням Cloudflare обмежує outbound-трафік для динамічних воркерів. Код, згенерований агентом, не може довільно звертатися до будь-яких доменів в інтернеті. У контексті MCP-налаштувань компанія може явно вказати whitelist доменів, до яких дозволено робити запити.
Це суттєво зменшує «радіус ураження» у разі, якщо агентський код виявиться скомпрометованим або просто багованим. Навіть якщо код спробує ексфільтрувати секрети, він зможе відправити їх лише на заздалегідь дозволені домени, а не куди завгодно.
По-третє, кожен воркер — це окремий ізолят. Це означає, що навіть якщо один динамічний воркер поводиться некоректно, він не може напряму вплинути на інші воркери чи на основну інфраструктуру. У поєднанні з лімітами на ресурси це створює досить надійний бар’єр проти нескінченних циклів, надмірного споживання CPU чи пам’яті.
Усе це разом робить сценарій «агент генерує й запускає код» не просто теоретично можливим, а практично придатним для продакшн-середовищ, де є реальні секрети, реальні користувачі й реальні ризики.
Новий інтерфейс для агентів: від інструментів до коду
Codemode — це не лише оптимізація використання контексту. Це зміна парадигми взаємодії агентів із сервісами. Замість того, щоб розглядати API як набір окремих інструментів, які потрібно описати й подати моделі, Cloudflare пропонує дивитися на API як на програмну бібліотеку, з якою агент працює як розробник.
У цьому підході є кілька важливих наслідків.
По-перше, інтерфейс стає значно більш виразним. Агент може комбінувати кілька викликів API у складні сценарії, додавати умовну логіку, цикли, обробку помилок — усе те, що важко або незручно виразити через послідовність окремих tool calls.
По-друге, зменшується потреба в ручному дизайні інструментів. Замість того, щоб вирішувати, які саме endpoint’и варто винести як MCP-інструменти, розробники можуть зосередитися на якісній OpenAPI-специфікації й генерації SDK. Агент сам «знаходить» потрібні методи через типи.
По-третє, з’являється можливість масштабувати доступ до API без вибуху контексту. Один компактний SDK плюс інструкції замінюють тисячі описів інструментів. Це особливо важливо для великих платформ, де кількість endpoint’ів вимірюється тисячами.
Cloudflare очікує, що з часом саме такий підхід стане домінуючим: агенти дедалі частіше взаємодіятимуть із сервісами через генерацію й виконання коду, а не через велику кількість окремих tool calls. У цьому сценарії «головним інструментом» для агента стає примітив виконання коду, а все інше — це вже питання SDK і sandbox-оточення.
Інфраструктура майбутнього: WorkerD, Deno, Monty та інші sandbox-примітиви
Щоб codemode став масовою практикою, потрібні не лише хороші SDK, а й надійні інфраструктурні примітиви для безпечного виконання коду. Cloudflare має WorkerD, але компанія не розглядає його як єдиний можливий варіант.
У Cloudflare очікують, що в різних екосистемах з’являтимуться власні аналоги WorkerD — легковагові sandbox-оточення, оптимізовані під запуск не довіреного коду, згенерованого агентами. Серед уже помітних напрямів:
Deno-сендбокси, які пропонують модель безпеки з явними дозволами на файлову систему, мережу й інші ресурси;
Monty від Pydantic — інструмент, який також рухається в бік безпечного виконання коду з чітко визначеними контрактами.
Спільною рисою цих рішень є прагнення поєднати виразність повноцінного коду з контрольованістю DSL-підходів. Агент отримує свободу писати логіку, але ця логіка виконується в середовищі, де кожен канал доступу — до файлів, мережі, секретів — має бути явно дозволений і обмежений.
Cloudflare бачить у цьому загальний тренд: по мірі того, як агенти стають більш автономними й здатними до складних дій, інфраструктура має навчитися безпечно виконувати їхній код. WorkerD — один із перших таких примітивів, але, ймовірно, не останній.
Безпека API в епоху агентів: rate limiting як обов’язкова умова
Є ще один аспект, який стає критичним у світі codemode: навантаження на API. Якщо агент може генерувати й запускати код у паралельних sandbox-оточеннях, він здатен створювати значно більше запитів, ніж типовий користувач чи навіть звичайний сервіс.
Cloudflare прямо попереджає: API, які відкриваються для агентів через подібні механізми, мають мати сильні обмеження швидкості — rate limiting. Інакше один агент, що генерує код, який масово викликає endpoint’и в паралельних воркерах, може легко перевантажити сервіс.
У цьому сенсі codemode не скасовує класичних принципів захисту API, а радше робить їх ще важливішими. Rate limiting, квоти, моніторинг аномальної активності — усе це стає базовою вимогою, якщо ви дозволяєте агентам працювати з вашим API через код, а не лише через обмежений набір інструментів.
Висновок: codemode як міст між агентами й інфраструктурою
Codemode від Cloudflare демонструє, як можна перетворити величезний, важкий для сприйняття API на зручний інтерфейс для AI-агентів, не розриваючи його на десятки часткових MCP-серверів і не перевантажуючи контекстне вікно моделей. Ключові інгредієнти цього підходу — типізований SDK, який стисло описує всі можливості API, і безпечний механізм виконання згенерованого коду в ізольованих V8-воркерах.
Цей підхід змінює саму модель взаємодії: агенти перестають бути просто «викликачами інструментів» і стають повноцінними користувачами програмних бібліотек, які пишуть код, комбінують виклики, будують складні сценарії. Водночас інфраструктура має відповідати цьому рівню автономності — через sandbox-примітиви на кшталт WorkerD, Deno-сендбоксів чи Monty та через класичні механізми захисту API.
Якщо очікування Cloudflare справдяться, у найближчі роки головним інтерфейсом між агентами й сервісами стане не список інструментів, а можливість генерувати й безпечно виконувати код. А SDK і sandbox-и стануть такою ж невід’ємною частиною AI-інфраструктури, як сьогодні REST чи gRPC для звичайних сервісів.