Что анонсировал Vercel 10 сентября 2026
10 сентября 2026 Vercel опубликовал в changelog запись о новой возможности: разработчики теперь могут строить и разворачивать долгоживущих, использующих инструменты агентов на базе OpenAI Agents API прямо на Vercel. Ключевая идея архитектуры - разделение ответственности: OpenAI управляет циклом рассуждений агента и состоянием сессии, а Vercel хостит само приложение и инфраструктуру, которая управляет жизненным циклом Sandbox.
По официальному описанию, решение объединяет Next.js, Vercel Functions, Vercel Queues и Vercel Sandbox для изолированного и персистентного выполнения кода. Архитектура заявлена как масштабируемая до нуля - без постоянно работающего воркера, который бы ждал запросов от агента.
Роли компонентов: кто за что отвечает
OpenAI Agents API хостит рантайм агента Codex, ведёт состояние сессии и оркестрирует цикл рассуждений. Когда агенту нужен исполнитель кода, OpenAI отправляет подписанный вебхук о необходимости запуска.
Vercel Functions создают сессии, принимают пользовательский ввод, стримят события разговора обратно клиенту и проверяют подпись входящих вебхуков. Приложению не нужно самому реализовывать логику агента - только принимать и передавать события.
Vercel Sandbox даёт каждой сессии персистентную изолированную среду выполнения - отдельную microVM, которая может выполнять код, устанавливать пакеты и сохранять файлы между возобновлениями сессии.
Vercel Queues отвечают за надёжность сигналов пробуждения инфраструктуры: когда OpenAI присылает вебхук о необходимости исполнителя, обработчик вебхука публикует сообщение в очередь, а отдельный приватный обработчик уже разворачивает Sandbox.
Как хранится состояние сессии и файлы
Интеграция использует ID сессии OpenAI, чтобы детерминированно именовать соответствующий Sandbox. При включённом параметре persistent: true Sandbox сохраняет файловую систему в /workspace при остановке и возобновлении сессии - это позволяет агенту обращаться к файлам, созданным на предыдущих шагах того же диалога, даже спустя несколько ходов разговора.
Технический процесс работы
Последовательность работы устроена так: приложение создаёт сессию с типом окружения self_hosted; OpenAI присылает подписанный вебхук, когда требуется исполнитель; обработчик вебхука публикует ID сессии в очередь вместе с ID события в качестве ключа идемпотентности; обработчик очереди запрашивает у OpenAI актуальное состояние сессии, не полагаясь на содержимое самого вебхука; затем он запускает или возобновляет Sandbox, используя ID сессии как детерминированное имя. Codex CLI внутри Sandbox запускает exec-server и подключается по WebSocket наружу к OpenAI; OpenAI присылает операции по этому соединению, а исполнитель возвращает результаты. Далее OpenAI стримит события сессии обратно в приложение.
Что нужно для настройки
Для работы требуются: ключ приложения с правами api.agents.read, api.agents.write, api.webhooks.write и api.responses.write; ключ окружения, созданный на вкладке Agents - только для подключений исполнителя; и секрет подписи вебхука, который выдаётся после регистрации URL вебхука.
Из предварительных требований официально указаны Node.js версии 24 или новее, Vercel CLI, аккаунт Vercel с доступом к Sandbox и Queues, а также проект OpenAI с включённым Agents API.
Из Sandbox разрешён исходящий сетевой доступ только к трём хостам: api.openai.com для регистрации исполнителя, codex-cloud-environments.chatgpt.com для файловых и shell-операций, и registry.npmjs.org для установки CLI.
Шаги деплоя
Официальный гайд описывает деплой в восемь шагов: склонировать пример приложения и выполнить pnpm install; создать переиспользуемого агента командой OPENAI_API_KEY=... pnpm create:agent; связать проект с Vercel через vercel link; настроить учётные данные в .env.local; протестировать локально через pnpm dev; задеплоить командой vercel deploy --prod; зарегистрировать URL вебхука в панели проекта OpenAI; добавить секрет вебхука командой vercel env add OPENAI_WEBHOOK_SECRET и передеплоить.
Защитные механизмы и почему Queue, а не Workflow
Официальный гайд прямо отмечает, что доставка через очередь гарантирована минимум один раз (at least once), поэтому предусмотрены четыре защитных механизма: дедупликация по ID события, чтение актуального состояния сессии перед выполнением действия вместо доверия содержимому вебхука, детерминированное именование Sandbox и блокировки на уровне операционной системы, предотвращающие параллельные процессы настройки.
Выбор в пользу Queue, а не Vercel Workflow, объясняется разделением ответственности: очередь не запускает агента и не хранит пользовательские промпты, она только делает надёжной доставку сигнала пробуждения инфраструктуры. Workflow подходит для последовательностей, которыми управляет само приложение, а в этом случае долгоживущей сессией уже управляет OpenAI.