OpenAI продовжує перетворювати агентів з демонстраційних прототипів на інструменти для реальних продуктів. На черговому Build Hour інженер API-команди Стів Коффі розповів про оновлений Agents SDK — зокрема про те, як він працює з ізольованими пісочницями, файловою системою та довготривалим станом. Саме ця інфраструктурна частина часто виявляється найболючішою для команд, які намагаються запустити агентів у продакшн.
Пісочниці як перший клас: від ноутбука до Modal і Cloudflare
Класичний сценарій «агента-програміста» виглядав просто: модель запускається локально, має доступ до файлової системи ноутбука, виконує shell-команди, редагує код. Для експериментів цього достатньо, але в продакшні така схема швидко ламається: потрібна ізоляція, контроль ресурсів, безпека секретів, масштабування, відновлення після падінь контейнерів.
Оновлений Agents SDK вводить поняття «sandbox-using agents» — агентів, які завжди працюють у пісочниці, а сама пісочниця стає окремим, першокласним бекендом. Ключовий зсув у дизайні полягає в тому, що:
агентний «harness» (логіка циклу, виклики моделей, оркестрація інструментів) відділений від обчислювальної пісочниці, де виконуються команди й живе файлова система.
Це дозволяє запускати пісочниці там, де це зручно інфраструктурі компанії. Agents SDK підтримує низку бекендів як «first-class citizens»: Modal, E2B, Cloudflare, Vercel, Daytona, Blackwell, Docker, а також локальні ноутбуки для розробки й тестування. Для команд, які вже будують обчислювальні воркфлоу на цих платформах, це означає, що агенти можуть «вписатися» в існуючу інфраструктуру, а не вимагати окремого стека.
Розділення harness і compute вирішує одразу кілька типових проблем:
по-перше, пісочниця перестає бути «несучою конструкцією». Вона може вільно створюватися, завершуватися, перезапускатися — без втрати всієї логіки агента;
по-друге, секрети можна тримати поза пісочницею, у середовищі, де працює harness, знижуючи ризики витоку через prompt injection або скомпрометовані контейнери;
по-третє, з’являється можливість централізовано керувати станом пісочниці — через снапшоти файлової системи, а не через «живі» довгоживучі контейнери.
У результаті пісочниця стає тим, чим і має бути в сучасних хмарних системах: короткоживучим, відновлюваним середовищем виконання, а не єдиною точкою істини.
Стан, що переживає контейнери: снапшоти та реґідратація
Як тільки агенти починають працювати над завданнями, що тривають години чи дні, виникає питання: де зберігається їхній «робочий стіл»? Код, проміжні артефакти, завантажені документи, результати скриптів — усе це не повинно зникати лише тому, що контейнер завершився або платформа перезапустила пісочницю.
Agents SDK відповідає на це автоматичним механізмом снапшотів файлової системи пісочниці та її реґідратації між запусками. Після завершення чергового кроку або сесії SDK може зняти «знімок» файлової системи пісочниці, а при наступному запуску агента — відновити її до цього стану.
За замовчуванням снапшоти зберігаються як tarball-архіви на локальній файловій системі. Це найпростіший варіант: не потребує додаткових сервісів, добре підходить для розробки, тестів або невеликих інсталяцій. Але дизайн не обмежується локальним диском. SDK вміє інтегруватися з провайдер-специфічними механізмами збереження стану — наприклад, з volumes у Modal або з Cloudflare R2.
Такий підхід дозволяє вирівняти поведінку агентів із уже наявною інфраструктурою зберігання. Якщо команда вже використовує R2 як об’єктне сховище або volumes як персистентні диски для контейнерів, снапшоти пісочниць можуть лягти в ті самі патерни бекопу, моніторингу й політик доступу. З точки зору SRE та безпеки це критично: стан агентів перестає бути «особливим випадком» і вписується в загальну картину.
Автоматична реґідратація означає, що для агента довготривале завдання виглядає як безперервна робота, навіть якщо під капотом пісочниця створюється й знищується багато разів. Для розробників це зменшує кількість ручного коду навколо відновлення стану, а для продуктів — відкриває можливість будувати сценарії на кшталт багатоденних кодових рефакторингів або глибинного аудиту великих репозиторіїв.
Маніфест пісочниці: як задати стартове середовище для агента
Як тільки з’являється персистентний стан, виникає ще одне питання: з чого починається життя пісочниці? Які файли, каталоги, ресурси мають бути доступні агенту до першої команди? Відповідь Agents SDK — маніфест файлової системи.
Маніфест — це об’єкт, який описує початкове розташування файлів і структуру директорій у пісочниці перед стартом агента. Він визначає, які ресурси будуть змонтовані або скопійовані в середовище виконання, щоб агент одразу мав усе необхідне для роботи.
SDK підтримує завантаження файлів у пісочниці з різних джерел. Серед них локальна файлова система, S3, Cloudflare R2, Azure Blob Storage, а також GitHub-репозиторії. Це дозволяє будувати досить різні сценарії:
агент-програміст, який стартує з повною копією репозиторію з GitHub;
аналітичний агент, що отримує доступ до набору CSV-файлів з S3 або R2;
документний асистент, який працює з колекцією PDF з Azure Blob.
Маніфест стає контрактом між інфраструктурою та агентом: перша гарантує, що до старту сесії в пісочниці буде певний набір файлів, друга може покладатися на їхню наявність у своїй логіці. Це спрощує відтворюваність: одна й та сама конфігурація маніфесту може використовуватися в тестах, staging і продакшні, забезпечуючи однакове початкове середовище.
Важливо, що маніфест не існує у вакуумі. У новому дизайні Agents SDK з’явилася абстракція «capability» — можливості, які об’єднують інструменти, інструкції для моделі та внесок у маніфест. Наприклад, capability, що додає підтримку певного набору файлів або інструментів, може одночасно:
зареєструвати нові tools для агента;
дописати інструкції в системні промпти;
розширити маніфест, додаючи потрібні ресурси в пісочницю.
Таким чином, маніфест стає не лише статичним описом, а й точкою розширення, через яку різні можливості можуть «підмонтовувати» свої залежності.
Файлова система як інтерфейс: перегляд зображень і безпечне редагування
Сучасні агенти — це не лише текстові чат-боти. Вони працюють із кодом, документами, зображеннями, конфігураціями. Тому файлову систему пісочниці в Agents SDK перетворюють на повноцінну capability з власними інструментами.
Файлова capability дає агенту змогу переглядати файли, включно з зображеннями, а також змінювати їх у контрольований спосіб. Ключовий інструмент тут — apply_patch, який дозволяє вносити зміни у файли не через «перезапис цілого вмісту», а через структуровані патчі.
Це важливо з кількох причин. По-перше, патчі легше аналізувати й логувати: можна відстежити, які саме зміни вніс агент, порівняти їх із попереднім станом, при потребі відкотити. По-друге, це знижує ризик руйнівних помилок, коли модель через неточність у промпті або обмеження контексту переписує файл повністю, втрачаючи важливі фрагменти. По-третє, патчовий підхід краще масштабується на великі файли, де повний перезапис стає дорогим.
Можливість переглядати зображення в пісочниці відкриває додаткові сценарії: від генерації й подальшого редагування графіки до аналізу скріншотів, діаграм чи UI-макетів у рамках одного агентного воркфлоу. Оскільки все це відбувається в ізольованому середовищі, ризики для основної інфраструктури зменшуються, а експерименти з новими типами даних стають безпечнішими.
У поєднанні зі снапшотами файлової системи файловий capability перетворює пісочницю на щось дуже схоже на робоче середовище розробника або аналітика, але кероване моделлю й відтворюване в будь-який момент.
Безпечні довготривалі агенти як новий базовий рівень
Оновлення Agents SDK навколо пісочниць, снапшотів і маніфестів виглядають як суто інфраструктурні деталі, але саме вони визначають, чи зможе агент вийти за межі демо й стати частиною реального продукту.
Поєднання кількох принципів — ізоляції виконання, автоматичного збереження стану, конфігурованого стартового середовища й структурованого доступу до файлової системи — створює новий базовий рівень для «комп’ютер-використовуючих» агентів. Вони можуть працювати з великими кодовими базами, документами, зображеннями, виконувати складні багатокрокові завдання, при цьому залишаючись керованими, відтворюваними й безпечними для інфраструктури.
Для команд, які будують власні агентні системи, це означає менше коду навколо оркестрації контейнерів, снапшотів і файлових операцій, і більше — навколо бізнес-логіки, доменних знань і інтеграцій із внутрішніми системами. А для екосистеми загалом — рух до того, щоб «агент, який тиждень працює над вашим кодом у хмарі», був не екзотикою, а звичайною практикою.