Управление компьютером с GPT-6 Astra начинается не с команды «нажми кнопку», а с ответа на более важный вопрос: по какому наблюдаемому признаку приложение поймёт, что задача действительно выполнена? Статус ответа API этого не доказывает. Модель может правильно выбрать элемент, а браузер — потерять сессию; форма может принять нажатие, но отклонить данные; интерфейс может показать успех, хотя запись на сервере не изменилась.
Поэтому рабочая интеграция состоит как минимум из четырёх участников: GPT-6 Astra планирует следующий шаг, Responses API передаёт вызовы и результаты, ваша изолированная среда исполняет разрешённые действия, а отдельная проверка подтверждает итог в целевой системе. Человек остаётся участником процесса там, где действие передаёт данные, меняет права, удаляет информацию, создаёт покупку или плохо поддаётся отмене.
Такое устройство не уменьшает возможности модели. Оно превращает зрелищную демонстрацию работы в браузере в систему, которую можно ограничить, остановить, расследовать и принять по чётким критериям.
Сначала задайте результат, который можно проверить
Фраза «обработать заявку в CRM» слишком расплывчата для управления компьютером. Она не говорит, разрешено ли редактирование, кто должен подтвердить отправку, какой объект считается нужным и где искать окончательное подтверждение. Полезное задание описывает не только действие, но и пределы:
- открыть конкретную тестовую CRM и найти заявку с заданным идентификатором;
- прочитать статус и имя ответственного, ничего не меняя;
- если заявка не найдена или сессия истекла, остановиться;
- вернуть наблюдаемые значения и ссылку на карточку;
- считать задачу успешной только после повторного чтения той же карточки либо проверки через отдельный интерфейс чтения.
Для сценария с изменением данных критерий должен быть ещё точнее. Например: заполнить черновик ответа, показать его человеку, отправить только после подтверждения, затем проверить отметку времени и идентификатор отправленного сообщения. «Модель закончила рассуждать» и «сообщение доставлено адресату» — разные события.
До выбора инструмента запишите пять параметров: разрешённые сайты и приложения, допустимые виды действий, операции с обязательным подтверждением, предел шагов/времени/стоимости и источник финальной проверки. Если эти параметры невозможно сформулировать, автоматизация ещё не готова к доступу к реальному аккаунту.
Доступ к Astra нужно проверять в нужном продукте
По состоянию на 4 сентября 2026 года доступ всё ещё развёртывался поэтапно. OpenAI сообщала о начале запуска для корпоративных участников Trusted Access Program и о расширении доступа через API, а также для планов Plus, Pro, Business и Enterprise в последующие дни. Это формулировка о процессе запуска, а не обещание, что модель уже видна каждому пользователю перечисленных планов. Актуальный статус нужно сверять с датированным сообщением OpenAI и фактическим интерфейсом своего аккаунта.
Особенно важно не смешивать две системы прав. Наличие Astra в рабочем пространстве ChatGPT не открывает её для API-ключа. Доступ API определяется организацией и проектом, к которым относится ключ; для раннего доступа по API-ключу также может потребоваться отдельная настройка клиента. Обратное тоже верно: доступность модели в проекте API не гарантирует, что сотрудник увидит её в ChatGPT Work или Codex. Эти границы прямо описаны в руководстве по доступности моделей в рабочих пространствах.
Документация ChatGPT говорит, что функция Computer Use доступна в поддерживаемых регионах на macOS и Windows в ChatGPT Work и Codex. Формулировка «в поддерживаемых регионах» не позволяет делать вывод о конкретной стране, организации или учётной записи. Для интеграции разработчика решающей проверкой остаётся пробный запрос из того проекта API, который будет обслуживать приложение.
Точный идентификатор модели — gpt-6-astra. Согласно текущей странице модели, контекст составляет 1 050 000 токенов, максимум входа — 922 000 токенов, а выхода — 128 000; модель принимает текст и изображения и выдаёт текст. На странице перечислены Responses, Chat Completions и Batch, но для вызова инструментов с Astra нужен именно Responses API. Поддержка Chat Completions не распространяется на рассматриваемые здесь вызовы инструментов.
Допустимые значения глубины рассуждения — low, medium, high, xhigh и max. Для первого прототипа разумно сравнить low и medium на собственной выборке задач, а не ставить максимальный режим по умолчанию. Более высокий уровень может помочь со сложным планом, но не заменит ограничения среды и проверку результата. В руководстве по GPT-6 Astra также указано, что при переходе с none или minimal следует начать с low; параметры temperature и top_p для Astra нужно убрать.
Есть два разных механизма работы с интерфейсом
OpenAI предлагает для Astra два варианта. Они используют один API, но по-разному делят работу между моделью и вашим приложением.
| Механизм | Что выдаёт модель | Что исполняет ваше приложение | Когда подходит |
|---|---|---|---|
Исполнение кода (code execution) | Вызов собственной функции со сценарием для Playwright, PyAutoGUI или аналогичной среды | Сценарий в изолированной постоянной среде, затем возврат текста и снимков экрана | Новый проект, сложная навигация, проверки по DOM, короткие циклы и условные действия |
Инструмент computer | computer_call с упорядоченным массивом computer_call.actions[] | Отдельные действия мыши и клавиатуры, затем новый снимок интерфейса | Уже существует обработчик фиксированных UI-действий или нужен подробный журнал каждого действия |
Для GPT-6 Astra OpenAI рекомендует исполнение кода. Это не встроенный удалённый доступ OpenAI к машине разработчика. Вы регистрируете собственную функцию, а затем сами решаете, где и с какими правами выполнить полученный сценарий.
Инструмент computer при этом не объявлен устаревшим и остаётся поддерживаемой альтернативой. Он удобен, если система безопасности уже умеет разбирать ограниченный набор действий: щелчок, ввод текста, нажатие клавиш, прокрутку, перетаскивание, ожидание и запрос снимка экрана. Поддержка инструмента не означает, что для Astra он предпочтительнее исполнения кода.
Есть и третий практический выбор: оставить собственные узкие функции или MCP-инструменты. Операция get_customer_status(id) обычно безопаснее и легче проверяется, чем визуальный поиск той же информации. Работа в браузере оправдана, когда важен отрисованный интерфейс, структурированного метода нет или нужно проверить именно пользовательский путь.

Исполнение кода требует собственной постоянной среды
В рекомендуемой схеме модель вызывает функцию вроде exec_py. Её описание перечисляет доступные библиотеки и объясняет, как вернуть наблюдения. Ваш сервис запускает сценарий, хранит браузерную сессию между вызовами и возвращает function_call_output с исходным call_id. previous_response_id связывает следующий ответ с предыдущим, но не создаёт браузер и не восстанавливает вход в аккаунт.
Ниже показан сокращённый каркас на Python. Функция execute_in_sandbox здесь намеренно не реализована: это ваш защищённый сервис, а не метод SDK OpenAI.
pythonimport json import uuid from openai import OpenAI client = OpenAI() session_id = str(uuid.uuid4()) tools = [{ "type": "function", "name": "exec_py", "description": ( "Выполни Python в постоянном изолированном рабочем столе. " "Используй только разрешённый браузер. Сначала проверь экран, " "а после действий верни новое наблюдение." ), "parameters": { "type": "object", "properties": {"code": {"type": "string"}}, "required": ["code"], "additionalProperties": False, }, "strict": True, }] next_input = [{ "role": "user", "content": ( "Открой разрешённую тестовую CRM, найди заявку ORD-1042 " "и прочитай статус. Ничего не изменяй." ), }] previous_response_id = None for turn in range(20): response = client.responses.create( model="gpt-6-astra", reasoning={"effort": "low"}, tools=tools, input=next_input, previous_response_id=previous_response_id, ) if response.status != "completed": raise RuntimeError(f"Вызов остановлен: {response.status}") calls = [item for item in response.output if item.type == "function_call" and item.name == "exec_py"] if not calls: print(response.output_text) break next_input = [] for call in calls: code = json.loads(call.arguments)["code"] observation = execute_in_sandbox( code=code, session_id=session_id, allowed_hosts={"crm.test.example"}, deadline_seconds=30, ) next_input.append({ "type": "function_call_output", "call_id": call.call_id, "output": observation, }) previous_response_id = response.id else: raise RuntimeError("Достигнут предел ответов без завершения задачи")
Число 20 в этом примере — локальный предохранитель, а не универсальный лимит сервиса. В рабочем приложении нужны отдельные пределы времени, вызовов, переданных токенов и действий внутри одного сценария. Клиентский тайм-аут тоже недостаточен: он может прекратить ожидание, пока процесс в контейнере продолжит работу.
Сценарий нельзя выполнять через обычный eval рядом с API-ключом. Рецепт OpenAI для сервиса исполнения требует отдельного минимально привилегированного контейнера или виртуальной машины, проверки вызывающей стороны, ограничений сети и ресурсов. Node.js vm и урезанный набор глобальных переменных Python прямо названы недостаточной границей безопасности.
Инструмент computer работает через действия и снимки
В альтернативной схеме первый запрос передаёт tools: [{ type: "computer" }]. Ответ может содержать только просьбу сделать снимок текущего состояния или сразу вернуть несколько действий. Приложение проверяет их по порядку, исполняет разрешённую часть и делает новый снимок.
Продолжение запроса содержит результат такого вида:
json{ "model": "gpt-6-astra", "tools": [{ "type": "computer" }], "previous_response_id": "resp_...", "input": [{ "type": "computer_call_output", "call_id": "call_...", "output": { "type": "computer_screenshot", "image_url": "data:image/png;base64,...", "detail": "original" } }] }
Здесь нельзя подменять call_id: снимок должен отвечать именно тому computer_call, действия которого были обработаны. Цикл повторяется, пока модель возвращает полный вызов. При неполном или ошибочном ответе, частично сформированном действии, отмене пользователем либо достижении предела выполнение останавливается. Официальный каркас цикла специально требует возвращать каждую законченную группу действий с её исходным идентификатором.
Поле computer_call.status: "completed" говорит лишь о том, что модель закончила формировать вызов. Оно не подтверждает, что обработчик совершил щелчок, страница приняла ввод или задача достигла цели. Даже после последнего вызова нужен свежий взгляд на интерфейс и независимая проверка ожидаемого состояния.
В примерах OpenAI для computer сейчас используется gpt-5.6-sol, хотя руководство отдельно говорит, что инструмент поддерживается и Astra. Не следует превращать выбор модели в примере в правило прямой миграции или игнорировать рекомендацию code execution для нового проекта на Astra.
Для снимков OpenAI советует detail: "original": точность координат зависит от геометрии изображения. Большие снимки расходуют больше входных токенов и могут превысить ограничения. Если изображение уменьшается, координаты модели нужно пересчитать обратно в систему координат реального окна до исполнения действия.
Не объединяйте состояние разговора, среды и задания
Один идентификатор не может описать всё происходящее. Полезно вести три независимых состояния:
- Разговор с моделью. Здесь находятся ID ответов,
previous_response_id, вызовы инструментов,call_idи возвращённые наблюдения. - Среда выполнения. Здесь живут браузер, вкладки, cookies, вход в аккаунт, размер окна, переменные процесса, последний снимок и состояние контейнера.
- Внешняя задача. Здесь находится фактическая запись в CRM, отправленное сообщение, значение настройки, созданный заказ или отсутствие изменения при режиме чтения.
Продолжение через previous_response_id восстанавливает контекст разговора, но не второе состояние. Если браузер перезапустился, нельзя молча позволять модели опираться на старый экран. Среда должна сообщить о потере сессии, а приложение — либо безопасно восстановить её, либо остановить задачу.
Третье состояние нельзя выводить из первых двух. Видимое уведомление «Сохранено» может устареть или относиться к другой записи. Для значимой операции лучше перечитать объект через отдельный API в режиме только для чтения, проверить идентификатор и новое значение, найти событие аудита или заново открыть карточку по постоянной ссылке. Если существует только визуальная проверка, фиксируйте точный элемент и ожидаемое значение, а не общий факт загрузки страницы.
Журнал запуска должен связывать эти состояния, не смешивая их: какой ответ запросил действие, в какой сессии оно выполнялось и каким наблюдением подтверждён результат. При этом хранение снимков должно соответствовать требованиям приватности; секреты и персональные данные не следует сохранять только ради удобства отладки.
Подтверждение ставится перед последствием
Запрос модели выполнить действие не является разрешением пользователя. Правила OpenAI по подтверждению и согласию требуют проверять права в приложении и среде выполнения. Инструкция модели дополняет этот механизм, но не заменяет его.
Перед каждым эффектом обработчик отвечает на четыре вопроса:
- находится ли сайт, приложение или файл в списке разрешённых ресурсов;
- получено ли действие из исходной задачи пользователя, а не из текста на странице, письма, PDF или результата инструмента;
- передаёт ли действие данные третьей стороне, удаляет ли их, меняет ли права, совершает ли покупку или другое трудно отменяемое изменение;
- нужна ли для следующего шага чувствительная информация.
Текст на экране по умолчанию недоверенный. Он может быть полезными данными, но не может расширить полномочия. Если страница требует игнорировать исходное задание, загрузить неизвестный файл, раскрыть ключ или обойти предупреждение безопасности, исполнение нужно остановить и показать ситуацию человеку.
Подтверждение запрашивают не в начале «на всякий случай», а непосредственно перед понятным риском. До этого можно выполнить безопасные шаги: открыть разрешённую страницу, собрать данные для формы, подготовить черновик. Запрос должен назвать действие, получателя, передаваемые данные и последствие. Ввод чувствительного значения уже считается передачей, поэтому спрашивать только перед кнопкой «Отправить» поздно.
Для массива computer_call.actions[] обработчик идёт слева направо и останавливается перед первым действием, требующим согласия. Все последующие элементы ждут решения пользователя. Для code execution проверки должны действовать внутри предоставленных функций, браузерного контекста и сетевой политики: один короткий сценарий способен и ввести данные, и отправить форму.
Финальный шаг смены пароля и обход предупреждения HTTPS или другого барьера безопасности OpenAI относит к передаче управления человеку. Покупка, удаление, отправка сообщения от имени пользователя и изменение постоянных прав требуют подтверждения непосредственно перед действием. Отказ — нормальный результат: его следует вернуть модели как наблюдение и продолжать только то, что остаётся разрешённым.
Изоляция должна выдерживать ошибочный сценарий
Изоляция нужна не только против намеренно вредного кода. Модель может ошибиться в селекторе, зациклиться, перейти по непредусмотренной ссылке или запустить слишком широкую операцию. Поэтому безопасная среда строится так, будто любой сгенерированный сценарий может оказаться неверным.
Для браузера это означает отдельный профиль без личной истории, отключённые расширения и локальный доступ к файлам, пустое наследуемое окружение, разрешённый список доменов и тестовые учётные данные с минимальными правами. Для настольной программы лучше использовать отдельную виртуальную машину или контейнер с ограниченными папками и сетью. API-ключ и другие секреты управляющего сервиса не должны попадать внутрь пространства, доступного сценарию.
Ограничьте не только общий запуск, но и отдельное действие: максимальное время сценария, число переходов, объём вывода, размер снимков и допустимые направления сети. Предусмотрите немедленную отмену, которая завершает процесс в среде, а не просто закрывает ожидание на клиенте.
Рекомендации OpenAI по безопасному запуску также требуют проверять реальный итог вместо доверия финальному тексту модели. Асинхронный мониторинг несоответствий Astra может дополнительно выдать предупреждение или остановить поддерживаемое продолжение Responses, но не служит откатом транзакции: проблема может обнаружиться после уже совершённого действия. Поэтому он не заменяет разрешения, подтверждения и проверку.
Проверяйте не только успешный маршрут
Перед доступом к реальным данным прогоните сценарии, в которых компоненты расходятся между собой:
- модель выбрала правильное действие, но элемент сместился после снимка;
- сессия браузера истекла между двумя ответами Responses;
- безопасное действие и удаление оказались в одном массиве;
- страница содержит ложную инструкцию передать файл или секрет;
- интерфейс показал успех, но серверная запись осталась прежней;
- человек отменил выполнение во время длинного сценария;
- уменьшенный снимок вернул координаты, которые не пересчитаны к реальному окну;
- API завершил ответ, но среда перестала отвечать до исполнения.
Каждый тест должен проверять конкретный механизм защиты. При истекшей сессии ожидается остановка или контролируемое повторное получение доступа, а не продолжение по памяти. При удалении ожидается подтверждение до первого необратимого шага. При ложной инструкции ожидается отказ расширять полномочия. При визуальном успехе без серверного изменения итог задания должен быть отрицательным.
Такой набор полезнее усреднённой «доли успешных задач», потому что показывает, где именно система перестаёт быть управляемой. Публичные демонстрации и спецификация модели не предсказывают надёжность вашего сайта, сетевых условий, разрешений и критерия приёмки.
Миграция с computer-use-preview идёт не напрямую на Astra
Текущая таблица миграции OpenAI сопоставляет старую интеграцию с пометкой preview и общедоступный инструмент следующим образом:
| Было | Стало по официальной инструкции |
|---|---|
Модель computer-use-preview | Модель gpt-5.6-sol |
tools: [{ type: "computer_use_preview" }] | tools: [{ type: "computer" }] |
Одно поле action в каждом вызове | Массив computer_call.actions[] |
Обязательный truncation: "auto" | Явная настройка truncation не требуется |
Это самостоятельное обновление существующего обработчика. Нужно научить его группам действий, заново проверить остановку перед риском и убедиться, что скриншоты связываются с правильным call_id. Общая страница рецептов интеграции OpenAI содержит актуальный раздел миграции.
После стабилизации нового варианта можно отдельно оценить GPT-6 Astra. Сначала проверьте доступ проекта, затем сравните рекомендуемое исполнение кода с уже имеющимся обработчиком computer. Простая замена имени модели не доказывает одинаковую задержку, гранулярность действий, работу подтверждений или качество на ваших задачах.
Модели с пометкой preview могут выводиться из эксплуатации с более коротким уведомлением; OpenAI приводит срок порядка двух недель как возможный пример и не рекомендует такие модели для критически важных процессов без готовности быстро мигрировать. Это общая политика, а не объявленная дата отключения computer-use-preview.
Готовность определяется наблюдаемым доказательством
Управление компьютером с GPT-6 Astra подходит для задачи, если вы можете назвать среду исполнения, ограничить её полномочия, сохранить состояние между вызовами, остановить её независимо от модели и проверить изменение там, где оно действительно хранится.

Минимальная запись завершённого запуска должна отвечать на шесть вопросов: что было разрешено, какой ответ запросил действие, где оно исполнялось, какое подтверждение было получено перед рискованным шагом, почему цикл остановился и каким наблюдением доказан результат. Если последнего ответа нет, корректный статус — «не проверено», даже когда Responses API вернул completed и итоговый текст выглядит убедительно.



