OpenAI Agents API: что изменилось для разработки сайтов и автоматизации

Большая часть интеграций с языковыми моделями начиналась одинаково: приложение формирует запрос, отправляет его модели и получает ответ. Для генерации описания товара, классификации заявки или исправления небольшого фрагмента текста этого зачастую достаточно.

Но задачи веб-разработки и бизнеса часто устроены иначе. Чтобы проверить проект, нужно открыть десятки файлов, выполнить команды, сравнить результаты, запросить данные из внешнего сервиса, проверить несколько гипотез и только после этого сформировать итог. Если процесс занимает много шагов, разработчик начинает самостоятельно строить вокруг модели цикл оркестрации.

Agents API переносит значительную часть этого цикла в управляемую инфраструктуру OpenAI.

10 сентября 2026 года OpenAI выпустила Agents API в public beta. API предоставляет разработчикам тот же тип managed Codex harness, который отвечает за многошаговую работу агента: сессии, использование инструментов, управление контекстом, восстановление после прерываний и координацию subagents.

Это не «API полной автономности». Скорее это следующий уровень абстракции между моделью и прикладным процессом.

От одного model call к полноценному агентному процессу

Удобнее всего понять Agents API не через список функций, а через последовательное усложнение архитектуры.

Уровень 1 — обычный model call. Приложение отправляет вводные и получает ответ. Хороший вариант для перевода, классификации, извлечения данных, генерации короткого текста или другого ограниченного преобразования.

Уровень 2 — model call с tools. Модель уже может запросить функцию, web search или другой инструмент. Приложение выполняет действие, возвращает результат и продолжает диалог. Такой процесс можно построить непосредственно через Responses API.

Уровень 3 — agent. Появляется долго живущая сессия, среда выполнения, возможность последовательно использовать инструменты, работать с файлами, выполнять команды и сохранять промежуточное состояние.

Уровень 4 — agent + subagents. Основной агент делегирует независимые части работы специализированным подагентам и затем объединяет выводы.

Уровень 5 — long-running task. Задача может переживать отдельный HTTP-запрос, продолжаться через множество шагов, требовать дополнительного ввода и возобновляться после прерывания. OpenAI изначально позиционировала инфраструктуру Agents API для процессов, которые способны работать длительное время, включая многочасовые и многодневные задачи.

Это различие важно, потому что само наличие tool calling ещё не означает необходимость Agents API.

Responses API уже позволяет вызывать инструменты и строить собственные agent loops. В официальном сравнении OpenAI рекомендует Responses API, когда разработчику нужен прямой контроль над моделью и интеграцией; Agents SDK — когда agent loop должен работать внутри приложения; Agents API — для длительных задач, где OpenAI управляет harness и сохраняет прогресс сессии.

Поэтому вопрос должен звучать не «может ли модель вызвать функцию?», а кто будет управлять состоянием, контекстом и многошаговым исполнением процесса.

Что именно берёт на себя Agents API

В центре архитектуры находится harness — управляемый OpenAI экземпляр Codex, который запускает модель и цикл использования инструментов.

Рядом с ним появляются ещё три сущности.

Agent определяет модель, инструкции, доступные инструменты и MCP-серверы.

Environment определяет, где агент получает доступ к файлам и вычислениям. Это может быть OpenAI-hosted sandbox, собственная среда разработчика или режим без отдельного окружения.

Session хранит продолжительное состояние конкретной работы. В неё можно отправлять следующие задания, продолжать уже начатую работу и получать события выполнения.

OpenAI управляет session orchestration, context compaction и recovery, тогда как приложение определяет инструменты и уровень доступа к окружению.

Для OpenAI-hosted environment предоставляется Linux workspace с Python, Node.js и командными инструментами. В среду можно передавать входные файлы, устанавливать нужные пакеты и ограничивать сетевой доступ. Если требуется собственный образ, приватная сеть или специфическая инфраструктура, можно подключить self-hosted environment.

Из этого уже получается существенно более практичная конструкция, чем «спросить модель и получить JSON».

Subagents: зачем одному агенту помощники

Multi-agent orchestration позволяет главному агенту создавать независимые subagents. Каждый получает собственный контекст и может параллельно выполнять выделенную часть задачи, после чего координатор объединяет результаты.

Например, при аудите проекта один subagent может разбирать PHP-код, второй — JavaScript, третий — техническую документацию, а основной агент сопоставит найденные проблемы.

Но subagents не следует создавать просто потому, что такая возможность есть.

OpenAI рекомендует делегировать им независимые направления. Если второй шаг зависит от результатов первого, последовательная работа основного агента часто проще и надёжнее. Кроме того, агенты, которые изменяют одни и те же файлы, должны координировать изменения.

Для веб-разработчика это важное архитектурное правило: multi-agent полезен прежде всего там, где работу реально можно разделить.

Что можно построить для веб-проектов уже сейчас

Практическая ценность Agents API становится понятнее на конкретных процессах.

Сценарий	Что может выполнять агент	Где нужен контроль
Анализ большого набора файлов	Получить файлы проекта, разделить анализ между subagents, выполнить вспомогательные скрипты, собрать проблемы и сформировать отчёт	Проверить полноту входных данных, критерии анализа и критичные выводы
Проверка сайта	Исследовать код, конфигурацию, логи и при необходимости браузерный интерфейс, сопоставить ошибки между уровнями	Не разрешать самостоятельные изменения production; проверять найденные дефекты и предлагаемые исправления
Подготовка контента с фактчекингом	Исследовать источники, анализировать исходные документы, собирать структуру, проверять утверждения и готовить черновик	Редактор проверяет факты, трактовки, юридически чувствительные утверждения и публикацию
Обработка заявок	Получить данные формы, классифицировать обращение, запросить CRM или базу знаний, подготовить ответ и следующую операцию	Ограничить доступ к персональным данным; отправку, изменение CRM и коммерческие решения валидировать
Внутренний research	Параллельно исследовать несколько источников или документов и собрать сравнительный отчёт	Проверить источники, актуальность данных и отсутствие необоснованной причинности
Developer workflow	Исследовать issue, воспроизвести ошибку, проверить файлы, запустить тесты, предложить patch и подготовить отчёт	Merge, deployment, изменение production и потенциально разрушительные команды должны иметь отдельный контроль

OpenAI сама приводит среди примеров Agents API incident-response agent, data analyst с read-only SQL, GitHub issue investigator и document reviewer. Это хорошо показывает направление технологии: API предназначен не только для диалога, а для исполняемой исследовательской работы внутри заданных границ.

Для WordPress-проекта, например, можно построить процесс, который получает архив темы и логи, изучает PHP и JavaScript, запускает статические проверки, делегирует анализ разных подсистем, формирует список рисков и подготавливает patch. Но отправлять этот patch прямо на production без отдельной проверки — уже другое решение и другой уровень риска.

Именно здесь проходит граница между автоматизацией работы и передачей ответственности.

Computer use: агент получил управляемый браузер

29 сентября 2026 года OpenAI добавила computer use непосредственно в Agents API. Агент может работать в OpenAI-hosted browser: открывать сайты, взаимодействовать с интерфейсами, тестировать пользовательские сценарии и собирать информацию через UI.

Для веб-разработки это особенно интересно.

Агент может не только проанализировать HTML или API, но и пройти реальный пользовательский путь: открыть страницу, найти форму, взаимодействовать с интерфейсом и проверить состояние приложения.

Однако hosted browser имеет важную модель разрешений. Перед посещением нового origin требуется approval, а авторизацию пользователя обрабатывает приложение. OpenAI отдельно предупреждает: разрешение открыть домен не является подтверждением каждого последующего действия. Если приложение должно гарантированно спрашивать человека перед покупкой, удалением данных или другим необратимым действием, это ограничение необходимо обеспечивать на уровне собственной архитектуры.

То есть computer use — это не аргумент в пользу того, чтобы дать агенту пароль от WordPress и сказать «почини всё».

Long-running task — не значит бесконтрольная задача

Один из самых заметных сдвигов Agents API — durable session.

Сессия способна переживать отдельный запрос приложения. Прогресс можно получать через streaming или webhooks, а после остановки или необходимости дополнительных данных продолжать работу той же сессии. OpenAI предоставляет события, в том числе состояния action_required, in_progress, idle и failed.

Это позволяет строить процессы другого класса.

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

Но длительность процесса не отменяет ограничений по стоимости, времени и доступу.

Для production-сценариев разумно задавать лимиты шагов, времени и расходов, позволять отменять выполнение и проверять фактический результат, а не доверять только финальному тексту модели. Именно такой подход OpenAI рекомендует и для computer-use процессов.

Где обязательно оставлять человека

Самая важная часть production-архитектуры агента находится не в prompt, а в permissions.

Агенту не следует давать больше ресурсов, чем необходимо для задачи. OpenAI рекомендует изолировать workload, ограничивать исходящий network access разрешёнными адресами и держать долгоживущие credentials вне среды, где агент выполняет сгенерированный код.

Для функций, которые изменяют внешнее состояние, полезно разделять «решить, что действие необходимо» и «разрешить его выполнить».

Например, агент может определить, что карточка товара устарела. Но сама публикация изменений в CMS должна проходить через отдельную функцию с permissions и валидацией.

Он может найти ошибку в базе. Но массовое UPDATE — не естественное продолжение анализа, а отдельная операция с другим уровнем допуска.

Он может подготовить коммерческое предложение. Но цену, скидку или отправку клиенту не обязательно отдавать его самостоятельному решению.

Для computer use OpenAI прямо рекомендует сохранять человеческий контроль над покупками, передачей чувствительных данных, разрушительными изменениями и другими трудно обратимыми действиями.

Human-in-the-loop в таком проекте — не признак слабого AI. Это нормальный уровень архитектуры.

Валидация результата важнее красивого финального ответа

Агент способен последовательно выполнить много работы и при этом ошибиться на одном из промежуточных шагов.

Поэтому хороший workflow заканчивается не фразой модели «задача выполнена», а проверяемым условием.

Для кода это могут быть тесты, lint, статический анализ и review diff.

Для аудита сайта — воспроизводимые HTTP-проверки, конкретные URL и технические доказательства.

Для контента — список первичных источников и проверка утверждений.

Для заявок — схема валидации обязательных полей и допустимых действий.

Для research — ссылки на документы, даты и явное разделение факта и интерпретации.

OpenAI рекомендует человеческую проверку результатов особенно для практического применения и генерации кода.

Чем длиннее agent workflow, тем полезнее иметь промежуточные контрольные точки.

Agents API и безопасность данных

Среда агента имеет ровно те возможности, которые ей предоставили.

Сгенерированный агентом код способен видеть файлы, credentials и сеть, доступные внутри environment. Поэтому секреты нельзя просто складывать в рабочую директорию рядом с кодом. OpenAI рекомендует хранить application API key вне среды, использовать ограниченные environment keys и для внешних сервисов передавать credentials через контролируемый proxy или secrets-механизм.

OpenAI-hosted sandbox также позволяет ограничивать outbound network: полностью запретить его либо разрешить только заранее указанные домены.

Это особенно важно для бизнеса.

Если агент анализирует клиентские документы, CRM или исходный код проекта, безопасность должна проектироваться на уровне инфраструктуры, а не только фразой в system prompt «не раскрывай данные».

Prompt — инструкция модели. Permissions — реальная техническая граница.

Когда Agents API вообще не нужен

Появление новой инфраструктуры не превращает каждый AI-процесс в агентный.

Если задача выглядит как:

входные данные → одно преобразование → структурированный ответ

то часто достаточно Responses API.

Например, определить категорию заявки, извлечь поля из текста, сделать краткое резюме, переписать описание, классифицировать страницу или сгенерировать несколько вариантов заголовка.

Если процесс строго детерминирован:

проверить HTTP-код → если 301, проверить Location → записать результат

обычный PHP, Python или JavaScript будет дешевле, быстрее и предсказуемее агента.

Если модель должна сделать несколько контролируемых tool calls, но приложение само хочет управлять циклом и состоянием, Responses API тоже может быть достаточен. OpenAI прямо позиционирует его как вариант для прямой работы с ответами модели и собственной оркестрацией.

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

Иными словами, агент нужен там, где заранее известна цель, но не обязательно известна вся последовательность действий.

Не вся автоматизация должна быть агентной

Есть ещё одна практическая граница.

Предположим, после отправки формы сайт должен создать запись в CRM, отправить письмо и поставить задачу менеджеру.

Это классический детерминированный workflow:

форма → валидация → CRM → email → task

Здесь агент может оказаться лишней точкой неопределённости.

Но если поступающую заявку нужно понять, сопоставить с историей клиента, изучить документы, определить нужного специалиста, запросить недостающие данные и подготовить краткий briefing — агентная часть уже становится обоснованной.

Лучший вариант часто гибридный:

детерминированный код → агентная обработка сложной части → детерминированная проверка → подтверждённое действие

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

Что Agents API меняет для бизнеса

Для бизнеса главный эффект находится не в том, что «AI стал умнее», а в уменьшении объёма собственной агентной инфраструктуры, которую раньше приходилось проектировать вокруг модели.

Agents API может управлять состоянием сессии, harness, контекстом, tools и multi-agent orchestration. Это потенциально снижает объём собственного glue code в сложных процессах.

Но стоимость разработки никуда не исчезает.

По-прежнему нужно определить бизнес-процесс, подключить данные, спроектировать permissions, написать function handlers, настроить среду, обработать ошибки, вести логи, проверять результаты и измерять качество.

Кроме того, managed infrastructure не означает бесплатное выполнение. В документации OpenAI указано, что использование модели оплачивается по тарифу выбранной модели, инструменты — по своим стандартным ставкам, а OpenAI-hosted sandboxes — по тарифам контейнеров.

Поэтому бизнес-кейс следует считать не по принципу «агент может это сделать», а по формуле:

стоимость человеческого процесса
против
разработка + model/tool/container usage + контроль + обработка ошибок.

Что изменилось для веб-разработчика

До Agents API сложный агент часто означал, что значительную часть инфраструктуры нужно было собирать самостоятельно: хранить прогресс, решать вопрос с контекстом, строить agent loop, поднимать sandbox, координировать инструменты и продумывать восстановление.

Теперь для части проектов этот уровень можно передать управляемому Codex harness.

Разработчик по-прежнему отвечает за главное:

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

Это гораздо практичнее разговоров о «полностью автономных сотрудниках».

Agents API не убирает инженера из процесса. Он меняет уровень, на котором инженер строит автоматизацию.

Вместо ручного программирования каждого промежуточного шага можно определить цель, инструменты и ограничения, а последовательность части работы передать агентному harness.

Но чем ближе workflow подходит к production, деньгам, клиентским данным и необратимым изменениям, тем важнее снова становится обычная инженерия: permissions, validation, observability, rollback и человеческое решение.

Именно поэтому наиболее интересный сценарий Agents API для веб-проектов — не «AI сам управляет сайтом», а агент выполняет большую часть исследовательской и исполнительной рутины внутри чётко заданных технических границ, а критические решения остаются контролируемыми.