OpenAI продовжує перетворювати «агентів» з експериментальної іграшки на реальний інструмент для довготривалої роботи в продуктах. На черговій сесії Build Hour інженер API-команди OpenAI Стів Коффі розповів про оновлену архітектуру Agents SDK: від кодексного (Codex-style) хернеса для довгих сесій до ізольованих sandbox-середовищ і набору базових можливостей, які тепер доступні «з коробки».
Це не просто ще одна обгортка над LLM. Agents SDK намагається вирішити одразу кілька болючих проблем: як дати моделям інструменти для реальної роботи з файлами й системами, не прив’язуючись до одного постачальника моделей, і водночас не перетворити продакшн на хаос із контейнерів, що постійно падають.
Від ручних циклів до модель-нативного хернеса
Ще рік-півтора тому типовий «агент» у застосунку виглядав як саморобний цикл навколо LLM API. Розробник будував петлю: зробити запит до моделі, прочитати відповідь, подивитися, чи модель викликала інструмент, виконати цей інструмент, оновити контекст, повторити. До цього додавалися веб-пошук, робота з файлами, власні тулінги — і більшість часу йшла не на продукт, а на підтримку цієї оркестрації.
Оновлений Agents SDK пропонує іншу точку входу: модель-нативний хернес, натхненний Codex. Ідея в тому, що сам цикл агента — як він викликає інструменти, як управляє довгими задачами, як тримає в голові стан — стає стандартною, перевіреною частиною фреймворку, а не кастомним кодом кожної команди.
Цей хернес розроблений для довготривалих агентів, які можуть працювати хвилини, години, а в окремих сценаріях — і днями. Він уміє:
- керувати багатокроковими завданнями, де потрібні десятки викликів інструментів;
- працювати з різними джерелами — файлами, вебом, зовнішніми системами;
- тримати в фокусі довгу «траєкторію» роботи, а не один-єдиний запит-відповідь.
Важливо, що Agents SDK при цьому залишається відкритим і модель-агностичним. Він не прив’язаний до одного конкретного LLM: будь-яка модель, яка підтримує формат Responses API, може стати «двигуном» агента. Це дозволяє будувати інфраструктуру, яка не зашита на одного провайдера, але водночас користується тими ж патернами, на яких працюють внутрішні агенти OpenAI на кшталт Codex.
Відкритий код і модель-агностика як стратегічне рішення
OpenAI зберігає Agents SDK відкритим і кастомізованим. Це не дрібна деталь, а ключовий елемент стратегії. Розробники можуть:
- переглядати й змінювати реалізацію хернеса;
- підключати будь-яку модель, що відповідає Responses API;
- інтегрувати SDK у власну інфраструктуру без жорсткої прив’язки до одного стеку.
Модель-агностика тут не означає «байдуже, яку модель ви використовуєте» в технічному сенсі. Навпаки, OpenAI явно орієнтує хернес на те, щоб він був «у розподілі» з їхніми моделями — тобто використовував ті ж патерни інструментального виклику, що й Codex. Але водночас API побудований так, щоб сторонні моделі, які вміють працювати з Responses API, могли безболісно підключатися до того ж циклу.
Для великих команд це означає можливість міксувати моделі: наприклад, використовувати одну для коду, іншу — для аналізу тексту, третю — для спеціалізованих доменів, не переписуючи при цьому логіку агента. Для стартапів — шанс не опинитися в пастці одного постачальника, зберігши при цьому доступ до перевірених патернів Codex-подібної роботи.
Sandbox-агенти: ізоляція як базова властивість
Одна з головних проблем «комп’ютер-використовуючих» агентів — де саме вони виконують код і що відбувається, коли це середовище падає. У ранніх реалізаціях Codex часто працював просто на локальному ноутбуці користувача: хернес і обчислювальне середовище були одним цілим. У продакшні це швидко перетворюється на проблему.
Оновлений Agents SDK вводить чітке поняття sandbox-агентів, які працюють в ізольованих середовищах, відокремлених від хоста. Агент бачить файлову систему, може запускати команди, писати код, але все це відбувається в окремому «пісочному ящику», який можна створити, знищити й відновити незалежно від основного застосунку.
SDK одразу підтримує низку sandbox-бекендів як «першокласних» громадян: Modal, E2B, Cloudflare, Vercel, Daytona, Blackwell, Docker, а також локальний ноутбук для розробки й тестування. Це важливий сигнал: OpenAI не намагається замкнути екосистему на власному хостингу, а радше інтегрується з уже популярними платформами контейнеризації та віддаленого виконання.
Для команд це означає можливість обрати той бекенд, який найкраще вписується в їхню інфраструктуру, не змінюючи логіку агента. Один і той самий агент може працювати локально під час розробки, у Docker-контейнері на staging і, наприклад, у Modal чи Cloudflare на продакшні — без переписування хернеса.
Розділення хернеса й sandbox: чому це важливо для продакшну
Ключова архітектурна зміна в Agents SDK — явне розділення хернеса (орchestrator агента) і обчислювального sandbox. У старій моделі, коли все крутилося в одному контейнері, виникали одразу кілька проблем.
По-перше, sandbox ставав «несучим елементом» системи. Якщо контейнер падав або його потрібно було перезапустити, губився не лише стан файлової системи, а й сам агентний цикл. Відновлення вимагало складної логіки, а іноді було просто неможливим.
По-друге, питання безпеки. Якщо в sandbox потрапляють секрети (ключі до баз даних, API-токени тощо), він стає вразливим до prompt-injection та ексфільтрації. Будь-який зловмисний вхідний контент, який змусить модель «витягнути» секрети, може скомпрометувати систему.
Розділивши хернес і sandbox, OpenAI фактично пропонує іншу модель: sandbox стає повністю ефемерним. Він може зникнути в будь-який момент, і це не має ламати логіку агента. Хернес, який працює у вашій основній інфраструктурі — у job-системі на кшталт Temporal, у AWS чи іншому середовищі, — відповідає за створення sandbox, передачу туди потрібних файлів, керування його життєвим циклом і, за потреби, відновлення.
Такий поділ дозволяє:
- тримати секрети й критичну логіку поза межами sandbox;
- сприймати sandbox як витратний ресурс, який можна безболісно перезапускати;
- масштабувати обчислення, не переписуючи агентний цикл.
Для розробників це означає, що Agents SDK можна вбудувати в уже існуючу інфраструктуру завдань і черг, а sandbox-бекенд розглядати як змінний компонент, який легко замінити або налаштувати під конкретні навантаження.
Вбудовані можливості: від веб-пошуку до пам’яті агента
Ще одна важлива зміна в Agents SDK — набір можливостей, які тепер доступні як «першокласні» компоненти, а не як кастомні надбудови. Фреймворк надає вбудовану підтримку веб-пошуку, пошуку по файлах, MCP (Model Context Protocol), code interpreter, skills і пам’яті агента.
Це означає, що типовий агент може:
- шукати інформацію в інтернеті, коли йому бракує контексту;
- індексувати й переглядати локальні файли, а не покладатися лише на вхідний prompt;
- виконувати код у контрольованому середовищі, використовуючи code interpreter;
- підключати «навички» як повторно використовувані блоки логіки;
- накопичувати досвід і покращуватися з часом завдяки пам’яті.
Підхід із «першокласними» можливостями зменшує кількість інфраструктурного коду, який доводиться писати командам. Замість того, щоб щоразу винаходити власний спосіб інтегрувати веб-пошук чи файловий індекс, розробник працює з уніфікованими абстракціями, які вже узгоджені з модельним хернесом.
При цьому SDK залишається відкритим до розширення: можна додавати власні інструменти й логіку, але базовий набір покриває більшість типових сценаріїв — від аналізу документів до напівавтоматизованої розробки ПЗ.
Кодексний хернес і асинхронний shell-цикл
Серцем оновленого Agents SDK є кодексний хернес, який переносить у відкритий фреймворк патерни, обкатані на Codex. Один із найважливіших елементів — асинхронний цикл взаємодії з shell, побудований на інструментах exec_command і write_stdin.
У цій моделі агент не просто «викликає команду й чекає результат». Він може:
- запускати bash-подібні команди через exec_command;
- передавати дані в стандартний вхід процесу через write_stdin;
- відстежувати кілька одночасно запущених команд;
- повертатися до вже запущених процесів пізніше, не блокуючи всю роботу.
Такий асинхронний підхід ближчий до того, як працює реальний розробник: запустити довгу команду, переключитися на редагування файлів, перевірити логи, повернутися до результатів. Хернес тримає в голові, які процеси запущені, які завершилися, які потребують уваги, і дає моделі інтерфейс для керування цим.
Цей же цикл тісно пов’язаний із можливістю «комп’ютер-використання»: модель пише shell-команди, запускає Python-скрипти, працює з файловою системою — усе в межах sandbox. Для розробників це означає, що агент може виконувати складні командні сценарії, не вимагаючи від людини постійного ручного втручання.
Базові можливості за замовчуванням: файловий простір, shell і компакція
Щоб агенти були корисними «з коробки», Agents SDK визначає набір дефолтних можливостей, які підключаються автоматично. Серед них — файловий простір, shell і компакція.
Файлова можливість дає агенту змогу переглядати зображення й редагувати файли через інструмент apply_patch. Замість того, щоб переписувати файл цілком, агент може застосовувати патчі — додавати, змінювати чи видаляти фрагменти. Це набагато ближче до того, як працюють системи контролю версій на кшталт Git, і зменшує ризик руйнівних змін.
Shell-можливість відкриває асинхронне виконання bash-подібних команд через exec_command і write_stdin. У поєднанні з файловою системою це дозволяє агенту:
- збирати й запускати програми;
- запускати тести;
- аналізувати логи;
- виконувати довгі обчислення, не блокуючи інші дії.
Компакція — менш помітна, але критично важлива можливість. Вона дозволяє агенту продовжувати роботу за межами контекстного вікна моделі. Замість того, щоб тримати всю історію сесії в prompt, хернес може «стискати» минулі кроки, зберігаючи важливу інформацію й викидаючи зайве. Це дає змогу будувати агенти, які працюють годинами й днями, не впираючись у жорсткі ліміти контексту.
У сукупності ці можливості формують стандартний базис: будь-який агент, створений на Agents SDK, уже вміє працювати з файлами, виконувати команди й управляти довгими сесіями. Далі розробник може додавати спеціалізовані інструменти й логіку під конкретний домен.
Навіщо все це розробникам
Оновлений Agents SDK намагається відповісти на кілька практичних запитань, з якими стикаються команди, що будують агентні системи.
По-перше, як отримати переваги Codex-подібних агентів — здатних працювати довго, з великою кількістю файлів і інструментів — не будуючи власну оркестрацію з нуля. Модель-нативний хернес, асинхронний shell-цикл і вбудовані можливості знімають значну частину цього тягаря.
По-друге, як не опинитися в пастці одного провайдера моделей чи інфраструктури. Відкритий код, модель-агностика й підтримка різних sandbox-бекендів дають простір для маневру: можна експериментувати з моделями й хостингом, не переписуючи агентний шар.
По-третє, як зробити агентів безпечними й керованими в продакшні. Розділення хернеса й sandbox, ізольовані середовища виконання й відсутність необхідності тримати секрети всередині sandbox знижують ризики й спрощують відповідність внутрішнім політикам безпеки.
І нарешті, як скоротити час від ідеї до робочого прототипу. Наявність дефолтних можливостей — файлової системи, shell, компакції, веб-пошуку, роботи з файлами, MCP, code interpreter, skills і пам’яті — дозволяє швидко зібрати агента, який уже вміє робити щось корисне, а не лише відповідати на запитання в чаті.
Висновок: від демо до інфраструктури
Agents SDK у новій версії виглядає як спроба перетворити агентів із демонстраційної технології на інфраструктурний шар. Кодексний хернес, ізольовані sandbox-середовища, модель-агностика й багатий набір вбудованих можливостей створюють основу, на якій можна будувати довготривалі, багатокрокові агенти, здатні працювати з реальними системами й кодовими базами.
Для розробників це шанс перестати писати нескінченні «обгортки» навколо LLM і зосередитися на тому, що робить продукт унікальним: доменній логіці, інтеграціях, UX. А для індустрії загалом — крок до того, щоб агентні системи стали не окремими експериментами, а звичайною частиною стеку сучасного застосунку.