Спрощені системи harness та агенти, що виконують код, краще підходять для завдань із відкритим результатом, де надто жорстка оркестрація може обмежувати продуктивність моделі.
Тому виконання коду й ізоляція в пісочниці тепер є ключовими архітектурними аспектами агентних систем.
Agents SDK зменшує складність і обсяг коду, необхідного для створення агентів, що виконують код, — у наших тестах до 6 разів.
Тривалий час розвиток агентних систем забезпечувало вдосконалення оркестрації: кращі запити, інтерфейси інструментів, керування контекстом і суворіша логіка керування. Але зі зростанням можливостей агентів для програмування цей баланс починає змінюватися.
У багатьох робочих процесах із відкритим результатом вузьким місцем стає вже не сам цикл агента, а рівень виконання — пісочниця, де модель пише код, запускає команди, перевіряє результати й повторює ці дії. Що більше міркувань на рівні завдання переноситься в це середовище, то простішою має ставати навколишня оркестрація, щоб модель могла повністю розкрити свої можливості.
Саме такий перехід уможливлює нова версія Agents SDK. Під час тестування в межах раннього доступу ми з’ясували, що замість додавання ще одного рівня логіки фреймворку вона робить рівень виконання модульнішим і придатним до компонування, тож решта системи може залишатися простою.
У проєктуванні систем harness стало популярним зводити систему harness до мінімально ефективної форми. На загальному рівні система harness — це програмне забезпечення навколо моделі: рівень, що керує контекстом, інструментами, логікою керування та циклами зворотного зв’язку, щоб модель могла надійно виконувати роботу.
Протягом останніх кількох років продуктивність агентів часто зростала завдяки посиленню цього рівня. Кращі інструменти, пам’ять і пошук, чіткіша декомпозиція та суворіша оркестрація часто робили системи надійнішими й функціональнішими. У межах цієї парадигми прогрес здебільшого означав перенесення більшої частини логіки завдання в програмне забезпечення навколо моделі.
Тепер ця закономірність слабшає — принаймні для певного класу завдань із відкритим результатом. Дедалі більше проєктів і досліджень свідчать, що продуктивність не завжди зростає, коли система harness стає директивнішою. У програмуванні з підтримкою ШІ, тривалих завданнях, роботі з браузером і завданнях із великим контекстом знову й знову проявляється та сама закономірність: коли модель стає достатньо інтелектуальною, надмірно жорстка структура завдання в навколишньому програмному забезпеченні може перетворитися з переваги на обмеження.
Отже, роль системи harness змінюється. Замість того щоб заздалегідь передбачати хід завдання за допомогою жорсткої оркестрації, система harness дедалі частіше надає чисте середовище виконання: пісочницю, де модель може перевіряти стан, запускати код, відновлюватися після помилок і коригувати власний підхід, залишаючись у межах інтерфейсів і захисних механізмів системи. Це близько до зміни, яку Андрей Карпати описав у Software Engineer 3.0: частина логіки, що раніше містилася в програмному забезпеченні, переходить на вищий рівень — у «запит».
Це не означає, що з агентних систем потрібно повсюдно прибрати структуру. Для багатьох завдань і надалі корисні чіткі робочі процеси, евристики й детерміновані запобіжники, особливо якщо завдання вузьке, масове або має чіткий критерій успіху. Як ми зазначали в попередній публікації «Евристики проєктування агентних систем», ефективна оркестрація залишається важливою, коли надійний логічний процес і можливий, і бажаний.
Для завдань із відкритим результатом акцент зміщується. Завдання полягає вже не стільки в розробці дедалі складніших рівнів оркестрації, скільки у створенні простих, спостережуваних і достатньо модульних середовищ виконання, у яких модель зможе ефективно працювати.
Коли агент може читати файли, писати код, запускати команди оболонки й створювати тривалі завдання, характер інженерної проблеми змінюється. Найскладнішим стає вже не лише оптимізація запитів чи маршрутизація інструментів. Робота в реальній системі робить таких агентів значно потужнішими, але водночас і чутливішими, адже збільшує поверхню ризиків для безпеки та захисту. Наприклад, агент, здатний виконувати код, може вчинити шкідливі дії, якщо його середовище погано ізольоване (див. тест Sandbox Bench від AISI).
Тому ізоляція в пісочниці стає критично важливим аспектом агентних фреймворків. У ранніх системах виконання часто вважали додатковою функцією — інструментом, приєднаним до системи harness. Але щойно виконання потребує збереження стану, стає тривалим або віддаленим, цей підхід перестає працювати. Керування самою пісочницею, її життєвим циклом, станом, інтерфейсами та зв’язком із циклом агента швидко перетворюється на окрему проблему проєктування системи. Це одна з причин, чому дедалі більше постачальників пропонують керовані середовища для виконання коду, зокрема Container API та інструмент shell від OpenAI, а також Modal, Cloudflare, Daytona, E2B тощо.
Ця межа важлива, оскільки виконання коду потребує надійнішої ізоляції та суворішого контролю середовища виконання, ніж решта системи harness. На практиці неналежно реалізовані агенти, що виконують код, можуть створити три критичні для бізнесу ризики: неконтрольовані витрати на обчислення, руйнівні дії у внутрішніх системах і розкриття конфіденційної інформації. Завдяки належній контейнеризації, ізоляції та захисним механізмам середовища виконання ці ризики можна знизити до рівня, прийнятного для реального впровадження.
Це можна уявити так: ви надаєте агенту власний ізольований робочий простір, а не ключі від усього офісу. У цьому просторі він і далі може виконувати корисну роботу, але лише в чітко визначених межах. Ви можете обмежити обсяг доступних йому обчислень, визначити, з якими системами й файлами він може взаємодіяти, та контролювати, яка інформація буде доступна йому від самого початку.
Це не усуває ризик повністю, але перетворює проблему з «агента, що вільно діє у вашій інфраструктурі», на «агента, який працює в контрольованому середовищі». Якщо цей рівень має стати стандартною складовою агентних систем, фреймворк повинен безпосередньо його підтримувати. Так пісочниця стає модульним рівнем виконання з переносними примітивами, які розробники можуть швидко впроваджувати, переносити між постачальниками й масштабувати без постійної переробки логіки агента.
Коли агент виконує код, сама пісочниця також потребує оркестрації. Перехід від локального прототипу до віддаленого виконання, кількох бекендів або тривалих сеансів експоненційно збільшує операційне навантаження. Потрібен узгоджений спосіб створювати й зупиняти середовища, призупиняти та відновлювати їх, зберігати знімки стану, повторно підключатися згодом і керувати всім цим у різних постачальників.
Усе це не надто захопливо на рівні концепції, але важливо на практиці. Саме така інфраструктура стає джерелом проблем, коли кожна команда заново створює агентний конвеєр, особливо якщо його не інтегровано в агентний фреймворк…
Саме тут важливою стає краща підтримка з боку фреймворку. Ми отримали ранній доступ до новішої версії OpenAI Agents SDK і самі створили за її допомогою агентів у пісочницях. Найпомітнішою була зміна архітектурного акценту: SDK розглядає виконання як повноцінний рівень, а не допоміжний інструмент. На практиці це означає, що можна створити агента в пісочниці, зробити знімок пісочниці або відновити виконання з меншим обсягом коду (приблизно у 6 разів у деяких наших тестах), а потім змінити бекенд, не переписуючи навколишню логіку агента.
Такий чіткіший розподіл відповідальності дає системі harness змогу зосередитися на міркуванні, контексті та робочому процесі. Рівень виконання може зосередитися на ізоляції, переносності та стані середовища виконання. Ця абстракція спрощує створення агентів для програмування, які мають ширші можливості та легше розвиваються, можуть переходити між локальним і віддаленим виконанням, підтримувати тривалі завдання й змінювати бекенди виконання без перебудови всієї системи.
Що більше логіки на рівні завдання переходить із системи harness у модель, то більше системної складності переміщується разом із нею — на рівень виконання. Виконання коду й ізоляція в пісочниці тепер є ключовими архітектурними аспектами агентних систем, особливо для завдань, пов’язаних із програмуванням або відкритим результатом. Проєктувати середовище, у якому агент може діяти безпечно, надійно й тривалий час, тепер так само важливо, як і сам агентний конвеєр.
Саме тому важливі високорівневі абстракції для виконання в пісочниці. Новіша версія OpenAI Agents SDK рухається в цьому напрямі, розглядаючи виконання як модульний рівень системи: переносний між бекендами, зі збереженням стану протягом тривалих завдань і достатньо простий у використанні, щоб не доводилося заново створювати ту саму інфраструктуру для кожної нової конфігурації.
Загальний висновок такий: наступне покоління агентних фреймворків, імовірно, визначатиметься не стільки обсягом доданої логіки оркестрації, скільки якістю організації середовищ виконання, від яких агенти дедалі більше залежать.