У changelog Cloudflare описано підхід авторів Exo: як запускати Exo агентів поверх Cloudflare, використовуючи Durable Objects для координації діалогу і Cloudflare Sandboxes для запуску Linux-утиліт. Нижче — практичний розбір цього мінімального прикладу.
Що саме змінилося
Exo тепер можна запускати не тільки локально або на власній інфраструктурі, а й через Cloudflare:
- розмови агента координуються в Durable Objects
- Linux-інструменти виконуються в Cloudflare Sandboxes
- поведінку агента ви описуєте у Markdown файлі
- запуск — через CLI Exo або HTTP API
Важлива деталь з матеріалу: Cloudflare адаптер для Exo розвиває сам проєкт Exo, він не потребує Cloudflare Agents SDK і підтримується незалежно від Cloudflare.
Підготовка Cloudflare адаптера і провайдера Exo
Перед тим як запускати агента, у матеріалі вимагається два кроки налаштування:
- Розгорнути Cloudflare адаптер для Exo.
- Сконфігурувати Exo provider, який вказує на це розгортання.
Інструкції автори дають у репозиторії Exo: github.com/exoharness/exo/tree/main/exoharness/cloudflare#authentication-and-cli. Там описані:
- як налаштувати автентифікацію до Cloudflare
- як зареєструвати провайдера для CLI Exo
- які параметри потрібні для звернення до вашого деплойменту
Без цих налаштувань команда запуску агента з прикладу просто не зможе підключитися до Cloudflare.
Створення мінімального Exo агента в Markdown
Після розгортання адаптера автори пропонують додати облікові дані до моделі в Exo через «vault credential» з ім'ям openai. Коли credential налаштований, можна описати агента в Markdown файлі agent.md.
У прикладі використовується YAML front matter з параметрами harness та моделі, а нижче — проста текстова інструкція для агента:
---
harness: basic
model:
name: gpt-6.1-sol
credential: openai
---
Help the user with their task.
Ключові моменти цього визначення:
harness: basic— використовується базова обв'язка Exo, без додаткових сценаріїв чи складної логікиmodel.name: gpt-6.1-sol— конкретна назва моделі, яка, за описом авторів, доступна через credentialopenaimodel.credential: openai— посилання на раніше доданий vault credential- нижній текст «Help the user with their task.» — рольова інструкція для агента, що визначає його призначення
У цьому мінімумі немає ні інструментів, ні складних правил відновлення — лише базова схема, яка показує, як описати агента для запуску на Cloudflare.
Запуск агента через Exo CLI з провайдером cloudflare
Коли файл agent.md збережений і провайдер Exo налаштований, автори демонструють запуск через CLI:
exo --provider cloudflare agent run --agent-file agent.md
Ця команда робить кілька речей:
--provider cloudflare— вказує, що агент має працювати через раніше налаштований Cloudflare провайдер, а не локальноagent run— запускає діалоговий сеанс агента--agent-file agent.md— підтягує опис агента з Markdown файлу
CLI Exo далі вже звертається до вашого Cloudflare деплойменту через адаптер: Durable Objects обробляють стан розмови, а Sandboxes — можливі виклики Linux-інструментів, якщо вони будуть додані в розширених конфігураціях агента.
Що важливо врахувати з обмежень і архітектури
У матеріалі окремо зазначено, що Cloudflare адаптер підтримує Exo проєкт, а не сама Cloudflare. Це означає:
- API і поведінка адаптера можуть змінюватися відповідно до релізів Exo
- для діагностики й оновлень потрібно орієнтуватися на документацію Exo
- Cloudflare Agents SDK для цього сценарію не потрібен, отже інтеграція йде власним шляхом Exo
За деталями архітектури, поведінки при відновленні та налаштування upstream автори відсилають до окремого гіда: developers.cloudflare.com/agents/harnesses/exo/. Там описано, як саме розмови агента розкладаються по Durable Objects, як поводиться система при збоях і як правильно організувати підключення до моделей через upstream.
Практичний мінімум з changelog — це зв'язка з трьох кроків: налаштувати провайдера cloudflare в Exo, описати агента в Markdown з потрібною моделлю та запустити його однією CLI командою. Далі поведінку агента можна ускладнювати, спираючись на повний Exo guide.
Джерело: Cloudflare Changelog