OpenAI: ChatGPT Work — управляемый слой исполнения

· 6 минут чтения · Любовь Черемисина · OpenAI AI-агенты · СегодняПродвинутый

15 августа 2026 OpenAI обновила справочную документацию по модели работы ChatGPT Work и Codex: Work описывается как отдельный агент для длинной многошаговой работы в веб-версии, мобильном и настольном приложении, с контекстом Projects и запуском по расписанию или при событии. Для корпоративных клиентов администратор раздельно управляет облачным Work, локальным Work и локальным Codex, а голосовые задачи расходуют общий пул агентных кредитов.

Три связанных шестерёнчатых механизма на кремовой бумаге — чат, рабочий агент и кодовый контур — разделены красными переключателями и общим счётчиком кредитов, метафора трёх сред исполнения с разными правами

Коротко

  • Что уточнили: в документации OpenAI от 15 августа 2026 ChatGPT Work описан как отдельный агент для длинной многошаговой работы — не как режим обычного чата.
  • Где работает: веб, мобильные устройства, облако и настольное приложение; контекст берётся из Projects; задачи запускаются разово, по расписанию, при событии или как мониторинг изменений через задачи по расписанию.
  • Главное ограничение: облачные и локальные сценарии, доступ к браузеру и сети, а также локальный Codex — отдельные контуры с разными правами; не всё, что разрешено в чате, автоматически доступно в Work.
  • Главное последствие: у OpenAI оформляется трёхуровневая архитектура «чат → Work → Codex» — с раздельным контекстом, правами и режимом исполнения для бизнеса.

Что изменилось

15 августа 2026 OpenAI обновила справочную статью ChatGPT Work and Codex. Это не анонс новой функции с датой запуска, а формализация того, как компания видит модель работы своих агентных сред.

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

Запуск задач Work поддерживает несколько режимов:

  1. Разовый запуск — одна конкретная цель.
  2. По расписанию — регулярный прогон без ручного старта.
  3. При событии — реакция на внешний сигнал.
  4. Мониторинг изменений — когда агент отслеживает обновления источника.

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

Для корпоративных и образовательных рабочих пространств модель прав стала детальнее:

КонтурЧто управляет администраторЗачем разделять
Облачный WorkЗадачи Work в веб-версии, на мобильных и в настольном приложении через облакоДанные и инструменты остаются в периметре облака
Локальный WorkФайлы и приложения на рабочем ПКДоступ к диску и программам — отдельный риск
Локальный CodexРазработка через Codex на компьютереТехнический контур с терминалом и репозиториями
Браузер и сетьДоступ к сайтам и сетевым действиямОтдельный рычаг от «просто ответить в чате»

Дополнительно для Work и Codex администратор может централизованно задать стартовую модель, уровень рассуждения, скорость и ускоренный режим. Голос в Work и Codex на настольном ПК наследует доступные агенту инструменты и разрешения; задачи, запущенные голосом, расходуют тот же общий пул агентных кредитов, что Work, Codex и другие агентные функции на тарифе.

Почему это важно

Раньше ChatGPT воспринимался как один продукт с разными кнопками. Обновлённая документация фиксирует другую логику: три среды исполнения с разным контекстом и правами.

  1. Чат — вопрос, черновик, короткий анализ.
  2. Work — длинная цепочка до готового артефакта с расписаниями и мониторингом.
  3. Codex — инженерный контур с кодом, репозиториями и локальными инструментами.

Для бизнеса это правильная архитектурная модель. Аналитический агент, агент с доступом к файлам на диске и технический агент не должны автоматически получать одинаковые разрешения только потому, что работают внутри одной AI-платформы. Та же логика уже видна у конкурентов: у Anthropic Cowork и корпоративный слой с раздельными правами и облаком описываются как отдельный управляемый контур.

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

Что это означает для бизнеса

Три практических следствия для маркетинга и аналитики:

  1. Разделите роли агентов по риску. Ежедневная диагностика показателей только для чтения, черновик презентации и правка кода в репозитории — это разные контуры с разными правами. Не выдавайте локальный доступ и права на запись «на всякий случай».
  2. Задачи по расписанию — не замена дашборда, а слой оповещения. Мониторинг изменений через Work имеет смысл, когда нужен интерпретируемый отчёт с контекстом Projects, а не только алерт из системы аналитики.
  3. Голос — тот же агент, те же лимиты. Запуск Work голосом не «бесплатный вход»; он наследует инструменты и съедает тот же пул, что и текстовый запуск.
СценарийРазумный стартКогда расширять права
Ежедневный обзор метрикОблачный Work, только чтение, задача по расписаниюЕсли 10 прогонов стабильны и нужны записи в документ
Конкурентный мониторингWork + Projects с брифом, мониторинг измененийЕсли источники требуют локальных файлов
Техническая автоматизация отчётовЛокальный Codex отдельно от маркетингового WorkКогда цепочка включает код, а не только анализ

Что это значит для ваших данных

Если маркетинговая команда уже использует MCP-коннекторы к Метрике, CRM или рекламным кабинетам, логика OpenAI совпадает с тем, как стоит проектировать доступы: облачный контур только для чтения для регулярной диагностики, локальный контур или запись — только после журнала из 10+ успешных прогонов.

Work не заменяет коннектор: он оркестрирует задачу поверх уже подключённых источников. Но разделение облака, локального доступа и браузера напоминает, почему в MCP Panel права на коннектор и журнал вызовов инструментов задаются отдельно от «просто спросить модель».

Что протестировать

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

За 10 запусков фиксируйте в таблице:

ЗапускИсточникиВызовы инструментовДлительностьКредитыПринят результатПравки человека
1да/нет

После серии решите, какие шаги действительно требуют локального доступа или прав на запись, а какие можно оставить в облачном контуре. Если больше трёх прогонов из десяти потребовали ручной переделки — сначала уточните бриф в Projects, а не расширяйте права.

Что проверить сейчас

Хотите задавать такие же вопросы своим данным из Метрики, CRM или рекламных кабинетов? Подключите источники через MCP-коннекторы, зафиксируйте сценарий только для чтения и сравните его с пилотом Work на тех же метриках — так вы увидите, где хватает облачного агента, а где нужен отдельный контур с вашими системами.

Главный вывод

OpenAI оформляет ChatGPT не как единый чат, а как стек исполнения: чат для коротких задач, Work для длинных процессов с расписаниями, Codex для разработки — каждый со своими правами и лимитами. Для бизнеса выигрывает не «дать всем расширенный тариф», а спроектировать контуры доступа: сначала облако и режим только для чтения с журналом прогонов, потом локальный доступ и запись — только там, где это доказано серией запусков.

Источники

← Все новости AI и MCP