OpenAI раскрыла, как работает AI-агент Codex для программирования

Разработка AI-инструментов для программирования: взгляд изнутри

По данным Ars Technica, инженер OpenAI Майкл Болин представил техническое описание внутренней работы кодирующего агента Codex CLI. Публикация охватывает детали реализации так называемого «агентного цикла» (agent loop), что делает её полезной для разработчиков, интересующихся возможностями ИИ в написании, тестировании и отладке кода. Это дополнение к предыдущему материалу, опубликованному в декабре, позволяет глубже понять, как OpenAI применяет модели GPT-5.2 в задачах программирования.

Внутренняя структура агентного цикла

Центральной частью описанного в публикации механизма является «агентный цикл», который управляет взаимодействием между пользователем, моделью ИИ и программными инструментами, вызываемыми моделью для выполнения задач. Этот цикл включает в себя повторяющийся процесс: модель получает запрос, формирует ответ, который может включать вызовы инструментов, таких как выполнение команд в оболочке или чтение файлов. После этого агент выполняет инструкции, добавляет результат к истории взаимодействия и запрашивает модель снова.

Болин описывает, как Codex строит начальный запрос для API OpenAI, который отвечает за выполнение модели. Запрос формируется из нескольких компонентов, каждому из которых присвоена роль и приоритет: system, developer, user, assistant. Инструкции могут поступать из файла конфигурации пользователя или из встроенных в CLI инструкций. Поле tools определяет, какие функции доступны модели, включая команды оболочки, планировщики, инструменты поиска и пользовательские функции через протокол MCP (Model Context Protocol).

Важной особенностью является то, что с каждым новым взаимодействием длина запроса увеличивается. Это связано с тем, что Codex не использует параметр previous_response_id, позволяющий API ссылаться на сохранённое состояние разговора. Вместо этого каждый запрос отправляется полностью, что делает процесс полностью бесшовным. Такой подход упрощает реализацию для поставщиков API и поддерживает политику Zero Data Retention, при которой OpenAI не хранит данные пользователей.

Проблемы масштабируемости и оптимизации

Рост длины запроса напрямую связан с ограничением контекстного окна модели, которое ограничивает объём обрабатываемого текста за один запрос. Чтобы смягчить эту проблему, Codex использует кэширование запросов. Однако, кэширование работает только для точных совпадений префиксов, что требует тщательного управления операциями, которые могут привести к потере кэша. Изменения доступных инструментов, смена моделей или изменение конфигурации песочницы в процессе взаимодействия могут негативно сказаться на производительности.

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

Открытость и доступность

Важным аспектом является открытость реализации Codex CLI. OpenAI разместила клиент CLI на GitHub, что позволяет разработчикам изучать его напрямую. Такой подход отличает Codex от других продуктов компании, таких как ChatGPT, детали внутренней работы которых остаются закрытыми. Это даёт возможность сообществу программистов анализировать и улучшать инструмент, основываясь на прозрачной архитектуре.

i

Создано специально для ASECTOR

Концептуальное изображение

Перспективы развития

Болин отметил, что в дальнейших публикациях он планирует описать архитектуру CLI, детали реализации инструментов и модель песочницы Codex. Такие материалы могут быть полезны для тех, кто разрабатывает или интегрирует ИИ-инструменты в свои процессы.

Открытость Codex CLI и реалии зависимости: где заканчивается прозрачность

Открытость клиента Codex CLI, размещённого на GitHub, может выглядеть как прорыв в доступности ИИ-инструментов для программистов. Однако, как показывает анализ, доступность кода не равна доступности модели, на которой он работает. Codex CLI, как и другие инструменты, построенные на основе моделей OpenAI, включает в себя лишь внешний слой — клиентский интерфейс и логику взаимодействия с API. Сама модель GPT-5.2, её внутренняя архитектура и алгоритмы остаются вне досягаемости. Это создаёт новую форму зависимости, которая может ограничивать возможности даже тех, кто имеет полный доступ к исходному коду.

Открытые поля и закрытые модели: технические детали

Внутренняя структура Codex CLI включает четыре ключевых поля: system, developer, user, assistant. Каждое из них играет свою роль в формировании запроса и управлении контекстом. Поле system определяет базовые инструкции модели, developer — настройки пользователя, user — входные данные, assistant — ответ модели. Такая сегментация позволяет управлять поведением агента, но не даёт возможности влиять на внутреннюю логику модели. Это особенно важно для российских разработчиков, поскольку, даже при наличии локального доступа к клиенту, качество работы Codex CLI напрямую зависит от стабильности и доступности API OpenAI.

Важный нюанс: Кроме того, Codex CLI использует протокол MCP (Model Context Protocol), который определяет, как агент взаимодействует с внешними системами. MCP позволяет интегрировать модель с командами оболочки, планировщиками и пользовательскими функциями. Однако, поскольку сама модель остаётся закрытой, протокол не может стать основой для полной автономии — он лишь улучшает взаимодействие, но не даёт возможности изменить поведение модели.

Политика Zero Data Retention: безопасность или ограничение?

OpenAI придерживается политики Zero Data Retention, при которой данные пользователей не сохраняются. Это может восприниматься как позитивный шаг в плане безопасности, но в реальности создаёт технические сложности. Codex CLI не использует параметр previous_response_id, что означает, что каждый запрос отправляется полностью. Это делает процесс бесшовным, но увеличивает объём передаваемых данных. Для российских компаний, где доступ к иностранным технологическим ресурсам ограничен, это может стать дополнительным барьером.

Зависимость от HBM: новые технические ограничения

Открытость клиента Codex CLI не устраняет зависимость от закрытых компонентов, включая физическую инфраструктуру. OpenAI сотрудничает с SK Hynix в рамках проекта Stargate, что подчёркивает важность высокополосной памяти HBM для работы ИИ-моделей. Рост спроса на HBM привёл к увеличению цен на память, что, в свою очередь, влияет на стоимость использования таких моделей. Для небольших компаний и развивающихся рынков это может стать серьёзным ограничением, поскольку доступ к дорогостоящей инфраструктуре остаётся вне их возможностей.

Утечки данных и уязвимости: риски открытости

Публичная доступность Codex CLI на GitHub, как и других проектов, связанных с разработкой ИИ, не исключает рисков. Исследования показывают, что утечки данных через онлайн-инструменты, такие как сервисы форматирования кода и NPM, могут привести к компрометации конфиденциальной информации. Для российских разработчиков это означает, что даже при наличии открытого кода, использование Codex CLI требует повышенной осторожности. Утечка токенов GitHub, API-ключей или других данных может стать следствием неправильного подхода к безопасности.

Перспективы развития и стратегия для российского бизнеса

Для российских компаний, заинтересованных в использовании Codex CLI и аналогичных инструментов, ключевым становится поиск баланса между открытостью и независимостью. Открытость клиента может быть полезной для изучения и адаптации, но не решает проблему зависимости от закрытых моделей и дорогостоящей инфраструктуры. В долгосрочной перспективе, для минимизации рисков, целесообразно развивать локальные ИИ-инструменты, которые позволят управлять поведением модели и инфраструктурой без привязки к внешним поставщикам.

Выводы

Открытость Codex CLI — это первый шаг к прозрачности, но не решение всех проблем. Даже при наличии доступа к коду, зависимость от закрытых моделей, дорогостоящей памяти HBM и уязвимостей в экосистеме разработки остаётся. Для российского бизнеса это требует стратегического подхода: изучение открытых инструментов, параллельное развитие собственных решений и усиление мер безопасности при работе с ИИ-инструментами. Только так можно добиться устойчивости и гибкости в условиях быстро меняющегося технологического ландшафта.