Последние модели и обновления API OpenAI GPT 2026: какие изменения произошли в Function Calling, Structured Outputs и JSON Schema?

Первое действие на этой неделе — не менять модель вслепую, а провести аудит по четырём слоям: модель, API-оркестрация, выполнение инструментов и структурированный контракт. Для нового Agent-проекта выбирайте Responses API и оценивайте Agents SDK; существующий проект на Function Calling можно оставить на прежнем интерфейсе, если ему не нужны встроенные инструменты, длительные задачи и управление состоянием. Это и есть практический вывод для обновления API OpenAI GPT 2026.

Кому стоит читать эту статью: разработчикам, которые поддерживают OpenAI API и должны понять, какие участки кода действительно требуют миграции. Командам, создающим Agent-сценарии, которым нужно выбрать API и среду выполнения. Техническим руководителям, контролирующим JSON Schema, права доступа, аудит и стоимость поддержки нескольких моделей.

Последнее обновление: 18 августа 2026 года. Данные проверены по официальным страницам OpenAI с моделями, документации API, руководствам по инструментам и публикациям о Responses API и Agents SDK. Перед релизом проверьте состояние конкретной модели через официальную документацию и endpoint /v1/models.

Сначала разделите обновление на четыре технических слоя

Название новой модели не означает автоматического изменения всех интерфейсов. Модель может появиться в каталоге, но иметь другой набор доступных API, инструментов, режимов потоковой передачи или структурированного вывода. Поэтому сравнивайте не только идентификатор вроде gpt-5, а полный контракт вызова.

Слой	Что проверять	Главный риск	Решение для проекта
Модель	Доступность, контекст, режимы рассуждения, поддерживаемые endpoint	Код привязан к неподходящему snapshot	Проверить модель через официальный каталог моделей OpenAI
API-оркестрация	Responses API, Chat Completions, Agents SDK, состояние и streaming	Миграция меняет формат событий и обработку ошибок	Для нового Agent — Responses API; для простого запроса — текущий стабильный интерфейс
Инструменты	Function Calling, встроенный поиск, файловые и компьютерные инструменты, MCP	Модель формирует запрос, но приложение неправильно его исполняет	Разделить генерацию вызова, авторизацию, исполнение и проверку результата
Контракт данных	Structured Outputs, `strict`, JSON Schema, отказ и обрыв ответа	Валидный JSON ошибочно принимают за правильные бизнес-данные	Ввести JSON Schema, серверную валидацию и семантические проверки

Проверять следует именно связку «модель — endpoint — инструмент — схема». В официальном API Reference список доступных моделей и их идентификаторы меняются, поэтому статический список из старой статьи нельзя считать источником истины. OpenAI отдельно указывает, что поведение snapshot-моделей может изменяться, а для воспроизводимости стоит использовать зафиксированные версии и собственные eval-тесты. (platform.openai.com)

Оценка по критериям

Responses API для нового Agent: 9/10.
Chat Completions для простого стабильного приложения: 8/10.
Function Calling без серверной проверки: 3/10.
Structured Outputs вместе с JSON Schema и семантической валидацией: 9/10.
Длительный Agent без изолированной среды: 2/10.

Эти оценки не являются официальным бенчмарком. Это инженерная шкала риска миграции и эксплуатации.

Первый шаг: выберите API по обязанностям, а не по моде

Какой интерфейс выбрать для нового OpenAI Agent в 2026 году

Для нового проекта с несколькими ходами модели, встроенными инструментами, трассировкой или долгими задачами начинайте с Responses API. OpenAI описывает его как более широкий примитив по сравнению с Chat Completions: он рассчитан на объединение текстовых ответов, вызовов инструментов и нескольких шагов выполнения в одном рабочем потоке. В Agents SDK добавляются маршрутизация, handoff между Agent-компонентами, guardrails и наблюдаемость. (openai.com)

Chat Completions не становится автоматически бесполезным. Если приложение отправляет сообщения, получает текст или вызывает одну-две собственные функции, а встроенные инструменты и длительное состояние не нужны, полноценная миграция может не дать заметной выгоды. В таком случае разумнее сначала стабилизировать схемы, логи и обработку ошибок.

Сценарий	Рекомендуемый старт	Почему	Оценка миграционного риска
Новое приложение с web search, file search или несколькими инструментами	Responses API	Единая модель событий и встроенные инструменты	Средний
Новый многошаговый Agent	Responses API + Agents SDK	Оркестрация, handoff, guardrails и tracing	Средний
Простая генерация текста	Chat Completions или Responses API	Нет сложного цикла инструментов	Низкий
Существующий Function Calling с одной функцией	Оставить текущий интерфейс	Перенос не решает бизнес-проблему	Низкий
Долгая задача с файлами, Shell и восстановлением состояния	Responses API + изолированная среда	Нужны отдельные compute, состояние и контроль секретов	Высокий

Responses API не следует трактовать как приказ немедленно переписать каждый старый сервис. Правильнее считать его предпочтительной точкой входа для нового Agent-кода. Это соответствует исходной позиции OpenAI: новые интеграции рекомендуется начинать с Responses API, а Chat Completions сохранять там, где не требуются встроенные инструменты. (openai.com)

Заменяет ли Responses API Chat Completions полностью

Нет, не во всех проектах. Функционально Responses API шире, но «шире» не значит «обязателен для любого запроса». Замена оправдана, если вы планируете:

несколько последовательных ходов модели и инструментов;
встроенный web search, file search, computer use или MCP;
фоновые и длительные операции;
унифицированные события streaming;
трассировку Agent-цикла;
единый слой для будущих функций платформы.

Если приложение представляет собой тонкий прокси над текстовой генерацией, смена endpoint может увеличить объём тестирования без пропорциональной пользы. Сначала зафиксируйте входные и выходные контракты, затем перенесите один маршрут в параллельный режим и сравните логи.

Второй шаг: переделайте Function Calling как цикл исполнения

Главное изменение в Function Calling происходит не в названии параметра, а в архитектуре цикла:

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

Function Calling не выполняет функцию сам. Модель генерирует структурированный запрос, а доступ к базе, платежам, файлам или Shell остаётся ответственностью приложения. В документации OpenAI также указано, что аргументы необходимо валидировать до исполнения. Для функции доступны strict и настройка параллельных вызовов; имя функции ограничено 64 символами, а в отдельных API-сценариях поддерживается до 128 функций в списке инструментов. (platform.openai.com)

Что даёт strict-режим Function Calling

strict: true требует соответствия аргументов заявленной схеме, но не превращает вызов в безопасную бизнес-операцию. Режим полезен для устранения типичных проблем:

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

Но даже строгая схема не отвечает на вопросы:

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

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

Параллельные и последовательные вызовы

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

Используйте последовательный цикл, если:

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

Для каждой функции задайте тайм-аут, лимит повторов и отдельную политику отказа. Не отправляйте модели необработанный stack trace, токены доступа или полный ответ внутреннего сервиса.

Третий шаг: отделите Structured Outputs от параметров инструментов

В проекте обычно существуют два разных JSON-контракта.

Контракт инструмента описывает аргументы функции. Он отвечает на вопрос: «Какие параметры может получить мой обработчик?»

Финальный контракт ответа описывает результат, который должна получить ваша программа или пользовательский интерфейс. Он отвечает на вопрос: «В каком формате модель вернёт итоговые данные?»

Оба контракта могут использовать JSON Schema и strict, но это разные точки контроля. Нельзя исправить плохой финальный ответ только тем, что вы строго описали параметры функции.

Structured Outputs предназначен для соответствия заданной схеме. В то же время документация OpenAI подчёркивает, что при строгом режиме поддерживается только подмножество JSON Schema. Кроме того, нужно обрабатывать отказ модели и неполный ответ из-за ограничения длины. Старый JSON mode гарантирует корректный JSON, но не соответствие вашей схеме; для поддерживаемых моделей предпочтительнее формат json_schema. (platform.openai.com)

Поддерживает ли Structured Outputs полный JSON Schema

Нет. Нельзя считать, что любой документ JSON Schema будет принят без адаптации. Перед миграцией проверьте:

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

Безопасный рабочий процесс выглядит так:

Составьте минимальную схему без редко используемых конструкций.
Добавьте additionalProperties: false, если это соответствует вашему контракту.
Явно перечислите обязательные поля.
Проверьте схему на тестовом наборе входных данных.
Отдельно протестируйте отказ модели.
Отдельно протестируйте искусственное ограничение выходных токенов.
После разбора выполните бизнес-валидацию.

Форматная корректность — это только первый барьер. Строка "status": "paid" может быть допустимой по JSON Schema, но фактически не соответствовать состоянию заказа. Число может иметь правильный тип, но неправильную валюту. Идентификатор может соответствовать шаблону, но принадлежать другому пользователю.

Четвёртый шаг: сделайте JSON Schema единым контрактом платформы

Если в компании используются несколько моделей или разные API-обёртки, не храните схемы внутри отдельных prompt-шаблонов. Вынесите их в версионируемый слой.

Минимальная структура репозитория:

schemas/
  invoice.v1.json
  invoice.v2.json
tools/
  create_invoice.ts
  cancel_invoice.ts
validators/
  business-rules.ts
tests/
  schema-contracts/
  tool-execution/

Для каждой схемы зафиксируйте:

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

Не меняйте существующую схему «на месте», если downstream-сервисы зависят от её поведения. Создайте v2, поддерживайте чтение обеих версий и удаляйте старую только после проверки реальных логов.

В журнале сохраняйте не секреты, а технический контекст:

идентификатор модели;
версию схемы;
тип endpoint;
имя инструмента;
результат валидации;
причину отказа;
длительность вызова;
число повторов;
идентификатор корреляции.

OpenAI рекомендует использовать уникальный идентификатор запроса для диагностики, а собственные eval-тесты — для контроля изменений поведения snapshot-моделей. (platform.openai.com)

Пятый шаг: вынесите Agent-исполнение в отдельный архитектурный слой

Длинная задача с файлами, Shell, установкой зависимостей и тестами — это уже не обычный API-запрос. Ей нужна среда выполнения.

Проверьте пять границ:

Изоляция. Код, созданный моделью, не должен работать рядом с production-секретами.
Состояние. После остановки контейнера нужно восстановить рабочий каталог и прогресс.
Сеть. Разрешите только необходимые домены и порты.
Учётные данные. Передавайте краткоживущие токены через контролируемый прокси.
Аудит. Логируйте команды, изменения файлов и обращения к инструментам.

В апреле 2026 года OpenAI описала для Agents SDK модель, где harness отделён от compute. Такой подход позволяет восстанавливать Agent после сбоя среды, использовать snapshot и не помещать секреты непосредственно в окружение, где выполняется сгенерированный код. В публикации также указана поддержка подключаемых провайдеров изолированных сред и собственной изолированной среды. (openai.com)

Responses API также развивает компьютерное окружение для задач с файлами и командами: промежуточные файлы остаются в рабочем пространстве, а результаты выполнения возвращаются модели для следующего шага. Это снижает необходимость передавать большие таблицы целиком в prompt, но не отменяет контроль разрешений и сетевой политики. (openai.com)

Когда достаточно управляемой среды

Выбирайте управляемую среду, если задача:

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

Собственный или удалённый Mac-узел оправдан, если Agent должен работать с macOS-специфичными инструментами, Xcode, iOS-симуляторами, подписанием приложений или физическими сценариями разработки. В таком случае API остаётся слоем рассуждения и оркестрации, а вычислительный узел нужно защищать отдельно.

Для оценки временной среды сравните не только цену API. Учитывайте запуск окружения, хранение артефактов, сетевой трафик, время простоя, доступ к приватным репозиториям и стоимость повторного выполнения. В официальном прайсинге OpenAI отдельно указано, что контейнерные сессии могут тарифицироваться по минутам и иметь минимальную длительность сессии; конкретные значения нужно проверять на странице цен перед расчётом бюджета. (platform.openai.com)

Шестой шаг: мигрируйте по ожидаемой отдаче

Новый проект

Начинайте с Responses API. Если есть несколько Agent-ролей, handoff, guardrails или трассировка, добавляйте Agents SDK. Сразу вынесите JSON Schema в отдельный пакет и установите серверную валидацию.

Не начинайте с миграции модели. Сначала докажите, что цикл инструмента, состояние и обработка отказов работают независимо от конкретного snapshot.

Простой старый проект на Function Calling

Не переносите его полностью только из-за даты 2026 года. Оставьте текущий endpoint, если:

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

При этом обновите strict, JSON Schema, проверку аргументов, разрешения и аудит. Такой порядок обычно дешевле и безопаснее, чем замена API-входа без изменения эксплуатационного слоя.

Длинный Agent с файлами и командами

Сначала проектируйте execution plane: sandbox, persistent workspace, секреты, сетевые ограничения, checkpoint и восстановление. Затем подключайте Responses API и оценивайте Agents SDK. Если перенести только API, но оставить команды на общем сервере, вы получите новый интерфейс поверх старой зоны риска.

Что проверить перед выпуском в production

Используйте этот набор как приёмочный тест:

[ ] конкретная модель подтверждена через актуальную документацию и /v1/models;
[ ] endpoint соответствует сценарию, а не выбран по названию модели;
[ ] каждая функция имеет JSON Schema и ограниченный набор аргументов;
[ ] strict включён там, где схема совместима с поддерживаемым подмножеством;
[ ] аргументы проверяются до исполнения;
[ ] права пользователя проверяются отдельно от решения модели;
[ ] параллельные вызовы запрещены для зависимых или изменяющих операций;
[ ] обработаны refusal, timeout, обрыв ответа и повтор;
[ ] финальный Structured Outputs проходит семантическую проверку;
[ ] секреты не попадают в prompt, логи и sandbox;
[ ] состояние длинной задачи можно восстановить;
[ ] есть eval-набор для смены модели и версии схемы;
[ ] стоимость повторов и длительных сессий включена в расчёт.

Если не проходят первые четыре пункта, смену модели откладывайте. Если не проходят пункты про права и sandbox, выпуск Agent в production откладывайте независимо от качества ответа.

Текущая схема «сервер с Function Calling и несколькими ручными обработчиками» может казаться дешевле, но у неё есть реальные недостатки: разрозненная обработка состояния, слабый аудит, ручное восстановление после тайм-аута и риск запуска команд рядом с секретами. Для задач, где нужен временный Shell, работа с файлами или macOS-специфичная среда, аренда удалённого Mac может быть аккуратнее, чем покупка отдельного узла или постоянная переделка существующего сервера. У VPSSpark можно начать с изучения условий и возможностей сервиса, а затем оценить удалённый Mac-узел в регионе US East под конкретный срок и сценарий. Если требуется проверить совместимость окружения до запуска, запросите детали через контакт с VPSSpark.

Такой вариант не универсален: для постоянной тяжёлой нагрузки, требований к физическим портам или долгосрочной эксплуатации собственный сервер может быть рациональнее. Но для короткого теста Agent, миграционного стенда, сборки и проверки файлового workflow важнее быстро получить изолированное рабочее окружение, чем навсегда закреплять инфраструктуру за одним проектом.