GPT-6 Astra прошла Portal без помощи человека: что этот эксперимент говорит о будущем универсальных AI-агентов
GPT-6 Astra прошла Portal за 23 часа 43 минуты, используя скриншоты, координаты и управляемые команды. Разбираем 3336 обращений к инструментам, MCP, SourcePauseTool, стоимость эксперимента и границы вывода о будущем универсальных AI-агентов.
GPT-6 Astra действительно прошла Portal от начала игры до финальных титров. На это ушло примерно 23 часа 43 минуты, включая ожидание ответа модели, паузы и ограничения мощности сервиса. За время эксперимента система обратилась к игровым инструментам 3336 раз.
Задачу поставил энтузиаст CozyBlaze. Во время прохождения Astra получала скриншоты, координаты персонажа и угол обзора камеры, после чего выбирала управляемые игровые команды. Человек заранее подготовил Portal, инструменты и техническую связку, но не управлял персонажем вручную на каждом шаге.
Главный смысл эксперимента связан с длительным циклом работы AI-агента: получить состояние среды, выбрать действие, выполнить его, проверить результат и скорректировать следующий шаг. Это сильная демонстрация для одной игры, но не доказательство универсального интеллекта или готовности модели самостоятельно решать любые задачи.
GPT-6 Astra прошла Portal без человека: что произошло на самом деле
Portal от Valve стала тестовой средой для GPT-6 Astra. Модель дошла до финальных титров, сохраняя цель прохождения на протяжении длинной последовательности игровых действий. Система не получила возможность свободно действовать в реальном времени: эксперимент проходил через подготовленный набор инструментов и повторяющиеся циклы наблюдения.
Продолжительность 23 часа 43 минуты описывает весь процесс, а не непрерывную игру. Значительную часть времени заняли ожидание ответа Astra, паузы и ограничения сервиса. Если убрать продолжительные задержки, запись самого прохождения занимает около двух часов.
Что означает «без помощи человека»
Фраза «без помощи человека» относится к управлению игрой во время активного прохождения. После запуска цикла человек не выбирал за модель направление движения, момент выстрела порталом или порядок решения очередной головоломки. Эти шаги Astra формировала по доступному состоянию игры.
Участие человека осталось на уровне постановки и подготовки. CozyBlaze выбрал Portal, сформулировал цель, подготовил игровую среду, подключил инструменты и запустил модель. Критерий успеха тоже был задан заранее: достижение финальных титров.
Поэтому эксперимент показывает автономность модели внутри ограниченного контура. Он не доказывает, что Astra самостоятельно выбрала задачу, создала подходящий интерфейс, оценила риски и организовала весь процесс без внешней настройки.
Как ИИ прошёл Portal от начала до конца
Прохождение строилось как последовательность коротких циклов. Astra наблюдала за текущим состоянием, формировала план, передавала команды и получала обновлённые данные. Для успеха требовалась устойчивая цепочка решений, поскольку ошибка в одной головоломке могла изменить положение персонажа и доступные варианты следующего шага.
Какие данные получала GPT-6 Astra
В описании эксперимента названы три основных типа входных данных:
- Скриншот показывал расположение объектов, порталов, стен, платформ и других элементов сцены.
- Координаты персонажа помогали определить положение игрока в пространстве и оценить, достигнута ли нужная точка.
- Угол обзора камеры указывал, куда направлен взгляд и какие объекты находятся перед моделью.
Каждый сигнал решал отдельную часть задачи. Изображение давало визуальный контекст, координаты помогали связать этот контекст с положением персонажа, а направление камеры уточняло, какие поверхности и проходы доступны для следующего действия.
Модели требовалось связать эти данные с целью текущей головоломки. Одно дело увидеть кнопку на скриншоте. Другое, определить, как добраться до неё, какой портал создать, в какой момент нажать кнопку и где окажется персонаж после перемещения.
Цикл «пауза - решение - команда - проверка»
Схема эксперимента напоминала пошаговое управление:
- Игра ставилась на паузу, чтобы Astra могла обработать доступное состояние.
- Модель выбирала следующий шаг или короткую последовательность действий.
- Инструмент передавал команды игре.
- Portal возобновлялась на несколько секунд, чтобы действие выполнилось.
- Система снова получала состояние игры и сравнивала результат с ожидаемым направлением.
Такой режим отличается от заранее записанного сценария. Команды формировались в ходе прохождения, а новое состояние могло изменить следующий план. Если персонаж оказывался не там, где ожидала модель, ей приходилось перестраивать дальнейшие действия.
Почему прохождение растянулось почти на сутки
23 часа 43 минуты нельзя читать как 23 часа непрерывной игры. В это число вошли ожидание ответа Astra, паузы между циклами и задержки, связанные с ограничениями мощности сервиса. Активное прохождение без продолжительных остановок заняло около двух часов.
Такое расхождение важно для оценки AI-агентов. Агент может решить задачу за короткое активное время, но календарный срок окажется намного больше из-за обмена данными, повторных проверок и ожидания вычислений. Проблемы с оценкой времени и контролем длинных процессов разобраны в статье почему AI-агенты плохо понимают время в длинных задачах.
Техническая схема эксперимента: MCP и модифицированный SourcePauseTool
В технической связке упоминаются MCP и модифицированный SourcePauseTool. Их удобно разделить по ролям: MCP задаёт способ связи модели с внешними инструментами, а SourcePauseTool связывает принятие решения с паузой, выполнением команд и получением нового состояния игры.
Какую роль MCP выполняет в связке
MCP, или Model Context Protocol, можно описать как согласованный слой обмена между моделью и внешними функциями. Модель не получает прямой контроль над игрой на уровне операционной системы. Она обращается к доступным инструментам через интерфейс, который передаёт команды и возвращает результат.
В таком сценарии MCP помогает разделить роли. Astra отвечает за интерпретацию состояния и выбор следующего шага. Игровой инструмент отвечает за выполнение команды. Промежуточный протокол передаёт запрос в нужном формате и возвращает модели обновлённые данные.
Доступное описание не раскрывает полный перечень функций и все параметры их работы. Поэтому MCP стоит воспринимать как архитектурный слой связи, а не как готовое объяснение каждой строки проекта. Точные детали нужно сверять с опубликованным кодом.
Что делал модифицированный SourcePauseTool
По наблюдаемой схеме SourcePauseTool связывал модель с управлением состоянием Portal. Его задача состояла в том, чтобы остановить игру на время принятия решения, передать ограниченную последовательность команд, возобновить игру и вернуть обновлённые данные для следующего цикла.
Такой инструмент снижает сложность эксперимента. Модели не приходится непрерывно реагировать на каждый кадр. Она работает с отдельными срезами состояния и получает время на планирование между короткими отрезками игрового процесса.
Точное поведение модифицированного SourcePauseTool зависит от его настроек: длительности паузы, состава команд, длительности выполнения и формата возвращаемых данных. Название инструмента описывает его назначение, но не заменяет проверку исходного кода.
Что даёт публикация описания и кода на GitHub
Описание эксперимента и исходный код опубликованы на GitHub. Это позволяет другим разработчикам изучить связку, проверить способ передачи состояния и повторить отдельные этапы запуска.
Открытый код помогает обсуждать результат предметно. Можно отдельно оценить, какие данные видела модель, какие команды ей разрешали отправлять и где находились ограничения среды. Публичность повышает проверяемость эксперимента, но сама по себе не превращает его в независимый бенчмарк.
Почему Portal подходит для проверки агентных способностей
Portal удобна для такого эксперимента по нескольким причинам. Игра работает в понятной среде, имеет ясную цель и требует решать пространственные головоломки через последовательность действий. Успех зависит от состояния уровня, положения персонажа, направления взгляда и последствий предыдущей команды.
Задача требует длинной цепочки действий
Игроку нужно перемещаться по уровню, создавать порталы, использовать кнопки, активировать механизмы и выбирать подходящий момент для следующего шага. Отдельная команда редко решает всю головоломку. Результат появляется после серии связанных действий.
Ошибка на одном этапе меняет дальнейшую ситуацию. Персонаж может оказаться в другом месте, портал появится на неподходящей поверхности, а доступный путь окажется закрыт. Агенту приходится сохранять общую цель и одновременно учитывать ближайшее действие.
Именно поэтому прохождение Portal проверяет устойчивость поведения во времени. Модель должна продолжать работу после десятков и сотен промежуточных решений, а не ограничиваться удачным ответом на один запрос.
Модель должна анализировать последствия своих решений
После выполнения команды Astra получала новое состояние игры. Она могла сопоставить ожидаемый результат с фактическим: переместился ли персонаж, открылся ли проход, сработала ли кнопка, изменился ли угол обзора.
Если положение не совпадало с планом, следующий шаг приходилось менять. Такой механизм создаёт обратную связь. Модель действует, наблюдает результат и обновляет план, вместо того чтобы один раз сгенерировать полный сценарий и выполнять его независимо от происходящего на экране.
Для AI-агента это базовый рабочий контур. В цифровом сервисе на месте игрового действия может оказаться нажатие кнопки, отправка формы или запуск вычисления. В обоих случаях качество зависит от проверки результата.
Почему успех не сводится к распознаванию картинки
Одного скриншота недостаточно для прохождения Portal. Модели нужно связать визуальные признаки с координатами, направлением камеры, целью головоломки и набором разрешённых команд.
Система должна определить, какая поверхность подходит для портала, куда переместится персонаж после входа, какую кнопку нужно активировать и что изменится после этого действия. Ошибка в пространственной оценке может привести к повторным попыткам или потере нужной позиции.
При этом такой навык не переносится автоматически на другие игры или реальные задачи. Portal остаётся заранее заданной средой с известными правилами и понятным критерием завершения.
23 часа 43 минуты, около двух часов и 3336 вызовов: как читать цифры эксперимента
У эксперимента есть несколько показателей, которые описывают разные стороны результата. Календарная длительность отражает ожидания и паузы, активное время показывает работу игры, количество вызовов характеризует дробность взаимодействия, а стоимость зависит от способа оплаты.
| Показатель | Значение | Что он описывает |
|---|---|---|
| Полная длительность | 23 часа 43 минуты | Весь процесс с ожиданиями, паузами и ограничениями сервиса |
| Активное прохождение | Около 2 часов | Запись без продолжительных остановок |
| Обращения к инструментам | 3336 | Количество циклов взаимодействия модели с игровой средой |
| Расчёт по API-тарифам | 571,18 доллара | Оценка стоимости использованных токенов |
| Подписка автора | 200 долларов | Codex Pro, через который запускалась модель |
Время на часах и активное время - не одно и то же
Полные 23 часа 43 минуты показывают, сколько длился эксперимент в календаре. Около двух часов показывают продолжительность самой записи без долгих ожиданий. Эти значения нельзя использовать как взаимозаменяемые оценки скорости модели.
Для длинных задач нужно фиксировать хотя бы три времени: момент запуска, время активной работы и время ожидания. Без такого разделения агент может выглядеть медленным из-за инфраструктуры или быстрым из-за того, что паузы не попали в отчёт.
571,18 доллара по API-тарифам и 200 долларов за Codex Pro
Расчётная стоимость использованных токенов по API-тарифам составила 571,18 доллара. CozyBlaze уточнил, что запускал модель через подписку Codex Pro стоимостью 200 долларов и отдельно сумму 571,18 доллара не платил.
Эти цифры описывают разные вещи. 571,18 доллара показывают, сколько могли бы стоить токены при пересчёте по API-тарифам. 200 долларов описывают фактическую подписку, через которую автор получил доступ к запуску. Называть одну из сумм окончательной ценой прохождения некорректно.
Что означает 3336 обращений к инструментам
3336 обращений показывают, что прохождение состояло из большого количества коротких циклов наблюдения и управления. Для агента это означает постоянный обмен состоянием с внешней средой: получить данные, выбрать действие, выполнить его и проверить результат.
Большое число вызовов указывает на ресурсную неэффективность подхода. Каждая проверка требует времени и вычислений. При переносе такого режима в рабочие системы к стоимости модели добавятся задержки, лимиты инструментов и контроль ошибочных действий.
Число вызовов не измеряет качество планирования само по себе. Агент может часто обращаться к инструменту и всё равно ошибаться. Это показатель масштаба взаимодействия, а не готовая оценка способностей модели.
Что эксперимент доказывает - и чего не доказывает
Результат заслуживает внимания, потому что модель прошла длинную цепочку действий в интерактивной среде. Его сила ограничена условиями эксперимента: одной игрой, заранее подготовленными инструментами и понятным критерием успеха.
Что можно считать подтверждённым
- GPT-6 Astra дошла в Portal до финальных титров.
- Во время прохождения модель получала скриншоты, координаты персонажа и угол обзора камеры.
- Astra отправляла последовательности управляемых игровых команд.
- Система использовала повторную проверку состояния после выполнения действий.
- Эксперимент включал 3336 обращений к инструментам.
- Полный процесс занял 23 часа 43 минуты с учётом ожиданий и пауз.
- Описание и исходный код проекта опубликованы на GitHub.
Эти факты подтверждают длительное автономное управление в одной подготовленной игровой среде. Модель удерживала цель, интерпретировала входные данные и продолжала цепочку решений до заданного результата.
Почему автор не считает прохождение полноценным бенчмарком
CozyBlaze сам не предлагает воспринимать прохождение как полноценный бенчмарк возможностей ИИ. Для строгого сравнения потребовались бы несколько игр, одинаковые условия для разных моделей, повторные запуски, заранее определённые метрики и независимый контроль результата.
Здесь остаются вопросы о переносимости навыка. Неизвестно, как Astra справится с другой игрой, изменённым интерфейсом, неполными данными или неоднозначной целью. Неясно и то, насколько результат зависит от конкретной технической связки.
Похожую осторожность полезно сохранять при оценке автономных исследований. В разборе эксперимента с AI-агентами и NeurIPS 2026 отдельно показано, почему успешное выполнение инженерных операций ещё не гарантирует качественного научного суждения.
Какую роль сыграли человек и подготовленная среда
Человек определил задачу, выбрал игру, подготовил доступные инструменты, настроил паузы и задал критерий успеха. Эти решения сформировали границы поведения модели ещё до первого игрового шага.
Portal тоже создаёт удобные условия для проверки. Правила игры известны, пространство ограничено, а финальные титры дают однозначный ответ о завершении. В реальной работе цели часто сформулированы расплывчато, данные неполны, а ошибка может повлечь финансовые, юридические или репутационные последствия.
Автономность внутри такой среды не равна независимости всей системы. Модель прошла подготовленный маршрут взаимодействия, а не самостоятельно построила универсальный способ решения любых задач.
Приближает ли эксперимент идею одного универсального AI-агента
Эксперимент показывает элементы поведения, которые могут пригодиться универсальному агенту. Модель получает состояние среды, планирует следующий шаг, работает с инструментом, проверяет результат и обновляет план. Этот контур применим к разным цифровым процессам.
Что в этом поведении может быть основой универсального агента
Общий принцип легко перенести на интерфейсы. Агент может открыть рабочую систему, найти нужный раздел, заполнить поля, проверить итог и перейти к следующему шагу. В Portal такими действиями выступают перемещение и управление порталами, в офисной программе - работа с документом или формой.
Сильная сторона подхода связана с обратной связью. Агент не обязан заранее знать каждый шаг, если умеет получать новое состояние среды и корректировать план. Это расширяет область автоматизации по сравнению с жёстким скриптом, который ломается после небольшого изменения интерфейса.
Исследования кодовых агентов показывают похожую структуру: написать действие, проверить результат, запустить следующий шаг и снова оценить состояние. В разборе работы кодовых агентов внутри OpenAI этот цикл объясняется на примерах инженерных задач.
Чего пока не хватает до универсальности
Между прохождением одной игры и надёжным агентом общего назначения остаются несколько пробелов:
- Перенос навыков. Успех в Portal не показывает, как модель будет действовать в незнакомом приложении или физической среде.
- Неоднозначные цели. В игре нужно дойти до финальных титров, а в работе заказчик может не сформулировать критерий хорошего результата.
- Устойчивость к сбоям. Реальные интерфейсы меняются, сервисы отвечают с ошибками, данные бывают неполными или противоречивыми.
- Память. Длинные проекты требуют хранить решения, ограничения, договорённости и историю ошибок.
- Безопасность. Агенту нужны ограниченные права, подтверждения перед критичными действиями и возможность немедленной остановки.
- Скорость и стоимость. 3336 обращений и почти сутки календарного времени показывают цену частого обмена с внешней средой.
Пока ни один из этих вопросов не получает полного ответа в эксперименте с Portal. Успешное прохождение даёт полезный сигнал о возможностях связки, но не закрывает задачу создания надёжного агента для разных областей.
Как понимать фразу о «худшей модели, которую мы когда-либо получим»
Фраза о том, что Astra - «худшая модель из тех, что мы когда-либо получим», звучит как прогноз быстрого развития AI. Это не доказанный факт и не гарантия, что следующая модель автоматически станет универсальным агентом.
Оптимистичная трактовка опирается на заметный прогресс: Astra воспринимает несколько типов данных, пользуется инструментами и сохраняет цель в длинном цикле. Осторожная трактовка учитывает другую сторону результата: специальную настройку, ограниченную среду, 3336 обращений, длительное ожидание и высокую расчётную стоимость токенов.
Будущие модели могут стать быстрее, дешевле и устойчивее. Но это потребует улучшений в планировании, памяти, контроле ошибок, безопасности и переносе навыков. Один игровой эксперимент не может подтвердить весь такой прогноз.
Что этот кейс меняет для работы и повседневных задач
Portal интересна читателю, который никогда не играл в эту головоломку, потому что показывает механику будущих цифровых помощников. Агент может работать с интерфейсом по многошаговой задаче, а после каждого действия проверять, что произошло.
От игровых команд к цифровым рабочим процессам
В браузере аналогичный цикл может выглядеть так: найти письмо, извлечь из него данные, заполнить карточку клиента, проверить поля и передать задачу сотруднику. В аналитической системе агент может собрать таблицу, запустить расчёт, сравнить результат с правилами и запросить подтверждение перед публикацией.
Перенос требует отдельной настройки. Рабочее приложение должно отдавать понятное состояние, инструменты должны ограничивать доступ, а критерий успеха нужно формулировать заранее. Успех в Portal сам по себе не превращает Astra в готового помощника для любой компании.
Практическую связь между агентами и рабочей продуктивностью можно увидеть в разборе внутреннего использования Astra в OpenAI. Там отдельно разделены скорость отдельных действий и ускорение всего рабочего процесса, поскольку эти показатели нельзя смешивать.
Почему человек ещё долго останется в контуре управления
Человеку нужно ставить цель, разрешать неоднозначные ситуации, проверять критичные действия и останавливать систему при отклонении от плана. Это особенно важно для платежей, доступа к данным, юридических документов и решений, которые влияют на клиентов.
Разумная схема для ближайших лет выглядит как совместная работа. Агент выполняет повторяющиеся шаги и собирает промежуточные результаты. Человек задаёт ограничения, подтверждает рискованные операции и оценивает итог.
Эксперимент с Portal показывает направление развития AI-агентов: восприятие состояния, планирование, работа с инструментами и проверка результата. До универсальной системы, которая надёжно действует в незнакомых задачах без специальной подготовки, остаётся существенная дистанция.
Для оценки подобных новостей полезно разделять демонстрацию и доказательство. GPT-6 Astra прошла Portal, и это заметный пример длительного агентного цикла. Он помогает понять технологию, но не отменяет вопросов о стоимости, скорости, безопасности и контроле.