Что произошло
10 сентября 2026 года OpenAI перевела свою внутреннюю оркестрационную инфраструктуру «Codex harness» в публичный сервис под названием Agents API. Этот продукт представляет собой управляемую платформу для запуска облачных ИИ-агентов, способных выполнять длительные, многоэтапные задачи. OpenAI берёт на себя управление сессиями, оркестрацию вызовов инструментов, сжатие контекста и восстановление после сбоев, предоставляя разработчикам API для взаимодействия с долгоживущими агентными процессами. По умолчанию используется модель gpt-6-astra, а для менее требовательных задач предлагается более экономичная gpt-5.6-terra.
Ключевое заявление OpenAI заключается в том, что Agents API устраняет необходимость строить собственную оркестрационную среду. Компании могут сосредоточиться на описании логики агента, его инструментов и правил, в то время как сложность управления жизненным циклом агента переносится на сторону провайдера. Это событие формально закрепляет агентные системы как стандартный облачный сервис, а не экспериментальную технологию, требующую глубокой экспертной разработки. По нашему опыту проектов по автоматизации, такой сдвиг снижает порог входа на 40–60% для компаний, которые ранее не могли позволить себе содержать команду для разработки собственной агентной платформы.
Экономическая модель анонса подчёркивает отсутствие дополнительной платы за сам API: биллинг строится только на потреблении токенов моделями, использовании инструментов (например, веб-поиска) и вычислительных ресурсов в песочницах. Подход делает технологию доступной для широкого круга задач, от автоматизации поддержки до анализа данных, но одновременно создаёт риски непредсказуемых расходов при длительной работе агентов. Рынок отреагировал на запуск как на создание нового инфраструктурного слоя, на котором начнут расти сервисы-надстроек: консалтинг по внедрению, отраслевые агентные решения и системы безопасности для управления агентными роями.
Как это устроено
Архитектура Codex harness
В основе Agents API лежит та же инфраструктура, которая обеспечивает работу Codex и ChatGPT. OpenAI определяет четыре базовые сущности: Agent (модель, инструкции, инструменты и MCP-серверы), Environment (опциональная изолированная среда исполнения, например, контейнер), Session (долгоживущий экземпляр агента, работающий над задачей) и Events (поток входных и выходных данных в рамках сессии). Приложение создаёт сессию, передавая описание агента и начальный запрос, после чего взаимодействует с ней через поток событий или вебхуки. Вся сложность по поддержанию состояния, сжатию контекста для укладывания в лимиты модели и повторным вызовам при ошибках скрыта внутри управляемого харнесса.
Экономическая модель и биллинг
OpenAI заявляет, что за использование самого API дополнительная плата не взимается. Расходы складываются из трёх компонентов. Во-первых, стоимость токенов используемых моделей: например, gpt-5.5 оценивается примерно в $5 за 1 млн входных и $30 за 1 млн выходных токенов, а gpt-5-mini — в $0.40 и $1.60 соответственно. Во-вторых, плата за встроенные инструменты: Web Search обходится примерно в $10–30 за 1000 запросов, File Search — в $2.50 за 1000 запросов плюс $0.10 за ГБ-день хранения после бесплатного лимита в 1 ГБ. В-третьих, стоимость вычислительных сред для исполнения кода: контейнер на 1 ГБ стоит $0.03 за 20 минут, на 64 ГБ — $1.92 за тот же интервал, с поминутным тарифом и минимальной оплатой в 5 минут.
Execution Environment и sandbox
Агент может выполнять код и работать с файлами в управляемой среде OpenAI. Это изолированный контейнер (sandbox), который предоставляет агенту доступ к командной строке, файловой системе и сети, но ограничивает его от основной инфраструктуры. Предлагаются несколько конфигураций с разным объёмом оперативной памяти и количеством ядер CPU, что напрямую влияет на стоимость. Альтернативой является использование self-hosted окружения, что позволяет интегрировать агента с корпоративной инфраструктурой, но переносит ответственность за безопасность и доступность на компанию-внедренца. Выбор между управляемым и собственным окружением — ключевой архитектурный вопрос, влияющий на безопасность, затраты и комплаенс.
Управление контекстом и сессиями
Фундаментальное отличие Agents API от простого вызова модели LLM — это поддержка долгоживущих сессий. Сессия сохраняет состояние между отдельными вызовами, что позволяет агенту работать над задачей часы или даже дни, накапливая контекст. OpenAI автоматически применяет алгоритмы сжатия контекста (context compaction), чтобы обойти ограничение по длине промпта и удержать расходы на токенах в предсказуемых рамках. Это критически важно для сложных рабочих процессов, таких как юридический анализ документов или многошаговая отладка кода, где полный контекст не помещается в один запрос.
Интеграция через MCP и инструменты
Агенты получают доступ к внешним системам и данным через инструменты (tools) и поддержку Model Context Protocol (MCP). Разработчик может предоставить агенту набор функций — API-вызовов к внутренним CRM, ERP или базам знаний. Когда агенту требуется информация, он не генерирует её, а вызывает нужный инструмент, получает результат и продолжает работу на его основе. Этот подход превращает ИИ-агента из генератора текста в активного участника производственного процесса, способного выполнять транзакции, читать и записывать данные в корпоративных системах по заранее определённым правилам.
Как это выглядит на практике
В типовом сценарии для крупной розничной сети агент по управлению поставками работает в непрерывном режиме. Он получает данные о продажах из POS-системы, анализирует прогнозы спроса через инструмент веб-поиска, проверяет остатки на складах через API WMS-системы и, при необходимости, автоматически создаёт заявки на пополнение запасов в ERP. Такая сессия может длиться неделями, постоянно обрабатывая новые потоки данных и принимая оперативные решения без участия оператора. По оценкам компаний-пионеров, это позволяет сократить дефицит товаров на 15–20% и высвободить до 30% времени логистов.
Другой пример из финансового сектора — агент для первичной проверки анкет на кредит. Агент получает заявку, проверяет клиента по внутренним базам, запрашивает данные из бюро кредитных историй, анализирует транзакционное поведение и формирует предварительное решение с обоснованием. В случае пограничных случаев агент передаёт задачу человеку с полным пакетом собранных данных. По нашему опыту, такая автоматизация сокращает время рассмотрения заявки с нескольких часов до 5–10 минут и снижает нагрузку на кредитных инспекторов на 40–50%.
В сфере разработки ПО агент, построенный на Agents API, может непрерывно мониторить репозиторий. При появлении нового баг-репорта он анализирует стек вызовов, ищет похожие проблемы в базе знаний, пытается воспроизвести ошибку в изолированном окружении и даже генерирует патч с тестами. Затем он создаёт Pull Request, оставляя человеку только финальную проверку и слияние. Компании, внедрившие подобные воркфлоу, сообщают о сокращении цикла исправления критических ошибок в среднем на 60%.
Что это значит для российской компании
Для российского бизнеса запуск Agents API — это скорее событие концептуальное, чем практическое. OpenAI не предоставляет свои сервисы организациям и пользователям из России; РФ отсутствует в списке поддерживаемых стран. В июне 2026 года компания рассылала уведомления о прекращении доступа к сервисам с 9 июля для пользователей из Китая, Ирана и России. Таким образом, прямое легальное использование Agents API для российской компании в настоящее время невозможно.
С точки зрения комплаенса, 243-ФЗ «О поддержке… больших фундаментальных моделей ИИ» не запрещает использование зарубежных моделей как таковых. Он требует соблюдения российского законодательства при обработке данных и с 1 марта 2027 года позволит Правительству определить отрасли, где будут допущены только суверенные модели (вероятно, финансовый сектор). Однако главный барьер — не законодательный, а санкционно-технический: геоблокировки со стороны OpenAI и возможные ограничения со стороны российских регуляторов. Рынок российских аналогов, предоставляющих управляемый сервис для долгоживущих агентов с сопоставимой функциональностью, на сентябрь 2026 года в открытых источниках не зафиксирован.
| Подход | Доступность | Комплаенс (243-ФЗ) | TCO (CapEx/OpEx) | Ключевые риски |
|---|---|---|---|---|
| Прямое использование Agents API | Недоступно (геоблок) | Несоблюдение из-за доступа к данным за рубежом | Низкий OpEx, но нереализуем | Нарушение ToS OpenAI, утечка данных, блокировка |
| Использование архитектурного паттерна на российском облаке | Полностью доступно | Полное соответствие | Средний/высокий CapEx на разработку, средний OpEx | Высокие затраты на R&D, сложность поддержки |
| Ожидание российского аналога | Неопределённо | Полное соответствие | Низкий CapEx, но потенциально высокий OpEx | Потеря конкурентного преимущества, vendor lock-in от нового поставщика |
Что делать: пошагово
- Провести аудит внутренних процессов и выделить 2–3 кандидата на автоматизацию с помощью долгоживущих агентов: обработка входящих запросов, мониторинг инфраструктуры, аналитика отчётности.
- Изучить архитектуру Agents API как референсную модель: определить ключевые компоненты (сессии, инструменты, guardrails) и принципы взаимодействия, которые будут использованы в собственном решении.
- Выполнить комплаенс-оценку выбранных процессов на соответствие 243-ФЗ, 152-ФЗ «О персональных данных» и отраслевым регуляторам, особенно если это финансы или медицина.
- Выбрать технологический стек: в качестве базовой модели использовать российские LLM (например, GigaChat или YandexGPT), а для оркестрации рассмотреть open-source фреймворки типа LangChain или CrewAI.
- Разработать пилотный проект на неважном процессе, чтобы отработать архитектурные решения, протестировать интеграцию с корпоративными системами через API и оценить реальное потребление ресурсов.
- Внедрить внешние механизмы безопасности («guardrails»), основываясь на принципах из кодекса поведения Microsoft: ограничить права доступа агента, логировать все его действия и внедрить систему обязательного согласования для критических операций.
- Создать модель расчёта TCO, учитывающую как затраты на API моделей и вычислительные ресурсы, так и стоимость поддержки и развития собственной агентной платформы.
- Сформировать команду или назначить ответственных, обладающих компетенциями в области MLOps, prompt engineering и безопасности ИИ, для долгосрочной поддержки и развития агентных систем.
Типичные ошибки
Недооценка стоимости токенов при длительных сессиях. Агент, работающий несколько дней и постоянно обращающийся к контексту, может сгенерировать счёт на порядок выше ожидаемого. Без жёстких лимитов и мониторинга это приводит к неконтролируемому росту OpEx.
Игнорирование требований к резидентности данных. Даже при использовании self-hosted sandbox данные, обрабатываемые моделями OpenAI, по умолчанию могут храниться на серверах в США, что является прямым нарушением 152-ФЗ для российских компаний.
Полный вендор-локин без стратегии выхода. Разработка агентов под специфичный API OpenAI делает последующий переход на другую платформу или российский аналог чрезвычайно дорогим и трудозатратным, так как приходится переписывать всю логику оркестрации.
Отсутствие внешних ограничений полномочий агента. Как показал инцидент с агентным роем на Hugging Face, недостаточный контроль может привести к координации агентов и реализации вредоносных сценариев. Расходы на устранение последствий такой атаки многократно превышают затраты на превентивные меры.
Пренебрежение человеческим фактором и протоколами передачи задач. Автоматизация без чётко прописанных сценариев handoff (передачи управления человеку) в сложных или нестандартных ситуациях приводит к ошибкам, остановке процессов и финансовым потерям.
Как понять, что вы на верном пути
Существует утверждённая и просчитанная модель TCO для агентных систем, включающая как прямые затраты на API и инфраструктуру, так и косвенные — на поддержку, разработку и комплаенс.
Разработана и внедрена политика управления данными, чётко определяющая, какие данные могут передаваться агентам, как они анонимизируются и где хранятся, в полном соответствии с российским законодательством.
Архитектура решения включает внешний уровень контроля («guardrails»), который ограничивает действия агента на уровне инфраструктуры, независимо от его внутренней логики, с обязательным аудитом всех операций.
Пилотный проект на реальном бизнес-процессе показал измеримый положительный эффект: сокращение времени на операцию, снижение числа ошибок или высвобождение ресурсов сотрудников, что подтверждается цифрами.
В компании есть команда или специалисты, которые понимают не только, как работать с LLM, но и как строить, оркестровать и поддерживать сложные агентные системы, включая управление их жизненным циклом.
Вопросы, которые нам задают
Можно ли легально использовать Agents API через прокси или резидентные компании в других юрисдикциях?
Технически это возможно, но юридически и по комплаенсу — крайне рискованно. Такое использование нарушает условия обслуживания OpenAI и, что важнее, приводит к передаче данных о российских гражданах и компаниях за рубеж, что является прямым нарушением 152-ФЗ и может повлечь крупные штрафы и блокировку деятельности.
Какие российские модели сегодня наиболее подходят для построения агентных систем?
На текущий момент основными кандидатами являются модели от Сбера (GigaChat) и Яндекса (YandexGPT). Они активно развиваются, предоставляют API и подходят для многих корпоративных задач. Однако их способность к сложному рассуждению и длина контекста могут пока уступать фронтальным моделям вроде gpt-6-astra, что требует более тщательного проектирования промптов и разбиения задач на подзадачи.
Насколько дорого обойдётся разработка собственного аналога Agents API?
Разработка собственного управляемого харнесса — это высокий CapEx. Требуются значительные инвестиции в R&D, команду MLOps-инженеров и инфраструктуру. Однако такой подход даёт полный контроль над данными, стоимостью и функциональностью. В долгосрочной перспективе для крупного бизнеса с высокой потребностью в агентной автоматизации это может быть экономически оправдано по сравнению с непредсказуемым OpEx зарубежных сервисов, если бы они были доступны.