Від моделі до агента: оснащення Responses API комп’ютерним середовищем

Наразі ми переходимо від використання моделей, які чудово справляються з окремими завданнями, до використання агентів, здатних опрацьовувати складні робочі процеси. Створюючи запити для моделей, ви можете отримати доступ лише до навченого інтелекту. Однак надання моделі середовища обчислення може забезпечити значно ширший спектр сценаріїв застосування, як-от запуск сервісів, запит даних через API або створення корисніших інформаційних продуктів, як-от електронні таблиці чи звіти.

У процесі створення агентів виникає кілька практичних питань: де зберігати проміжні файли, як уникнути вставляння великих таблиць у запит, як надати робочому процесу доступ до мережі, не створюючи проблем із безпекою, та як обробляти тайм-аути та повторні спроби, не створюючи власноруч систему робочих процесів.

Замість того, щоб покладати створення власних середовищ виконання на розробників, ми створили необхідні компоненти, аби забезпечити Responses API⁠(відкривається у новому вікні) середовищем для надійного виконання реальних завдань.

Responses API від OpenAI разом із командним процесором і розміщеним робочим простором контейнера призначені для розв’язання цих практичних проблем. Модель пропонує кроки та команди — платформа виконує їх в ізольованому середовищі з файловою системою для вхідних і вихідних даних, необов’язковим структурованим сховищем (наприклад, SQLite) та обмеженим доступом до мережі. 

У цьому дописі ми розповімо, як створили комп’ютерне середовище для агентів, і поділимося першими уроками щодо його використання для швидших, повторюваних і безпечних робочих процесів у продакшні.

Якісний робочий процес агента починається з щільного циклу виконання: модель пропонує дію, наприклад читання файлів або отримання даних через API, платформа виконує її, а результат переходить до наступного кроку. Почнемо з командного процесора — найпростішого способу побачити цей цикл у дії — а потім розглянемо робочий простір контейнера, мережеві можливості, повторно використовувані навички та ущільнення контексту.

Щоб зрозуміти командний процесор, спершу корисно зрозуміти, як мовна модель загалом використовує інструменти щоб робити такі речі, як виклик функції чи взаємодія з комп'ютером. Під час навчання моделі показують приклади того, як використовуються інструменти та які результати це дає, крок за кроком. Це допомагає моделі навчитися вирішувати, коли використовувати інструмент і як ним користуватися. Коли ми кажемо «використання інструмента», ми маємо на увазі, що модель насправді лише пропонує виклик інструмента. Вона не може виконати виклик сама по собі.

Командний процесор робить модель набагато потужнішою: він взаємодіє з комп’ютером через командний рядок, щоб виконувати широкий спектр завдань — від пошуку тексту до надсилання API-запитів на вашому комп’ютері. Створений на основі знайомих Unix-інструментів, наш командний процесор може робити все, чого ви очікуєте, з утилітами на кшталт grep, curl і awk, доступними одразу після встановлення.

Порівняно з нашим наявним інтерпретатором коду, який працює лише з Python, командний процесор забезпечує значно ширший спектр сценаріїв застосування, як-от запуск програм на Go або Java чи запуск сервера NodeJS. Така гнучкість дає змогу моделі виконувати складні агентні завдання.

Сама по собі модель може лише пропонувати shell-команди, але як ці команди виконуються? Нам потрібен оркестратор — координатор, який буде отримувати вихідні дані моделі, викликати інструменти та передавати відповідь інструмента назад до моделі в циклі, доки завдання не буде виконано.

Responses API — це спосіб, у який розробники взаємодіють із моделями OpenAI. Під час використання з користувацькими інструментами Responses API повертає керування клієнту, а клієнту потрібна власна система для запуску інструментів. Однак цей API також може одразу координувати взаємодію між моделлю та розміщеними інструментами. 

Коли Responses API отримує запит, він збирає контекст моделі: запит користувача, попередній стан розмови та інструкції інструментів. Щоб виконання shell працювало, у запиті має бути згадано використання командного процесора, А ТАКОЖ вибрана модель має бути навчена пропонувати shell-команди (цьому навчені моделі, починаючи від GPT‑5.2). З урахуванням усього цього контексту модель визначає наступну дію. Якщо вона вибирає виконання в процесорі, вона повертає одну або кілька shell-команд до сервісу Responses API. Сервіс API пересилає ці команди до середовища виконання контейнерів, передає назад потоком вивід shell і подає його моделі в контексті наступного запиту. Потім модель може перевірити результати, видати подальші команди або сформувати остаточну відповідь. Responses API повторює цей цикл, доки модель не поверне запит на завершення без додаткових shell-команд.

Коли Responses API виконує команду оболонки, він підтримує потокове з’єднання зі службою контейнерів. У міру формування виводу API передає його моделі майже в реальному часі, щоб модель могла вирішити: чекати на подальший вивід, виконати ще одну команду або перейти до остаточної відповіді.

Модель може запропонувати кілька shell-команд за один крок, а Responses API може виконувати їх одночасно, використовуючи окремі сеанси контейнерів. Кожен сеанс передає вихідні дані незалежно, а API мультиплексує ці потоки у структуровані виводи інструментів як контекст. Іншими словами, цикл роботи агента може розпаралелювати завдання, наприклад, пошук файлів, отримання даних і перевірку проміжних результатів.

Якщо команда передбачає операції з файлами або обробку даних, вивід shell може стати дуже великим і витрачати бюджети контексту, не додаючи корисних сигналів. Щоб контролювати це, модель задає обмеження вихідного результату для кожної команди. Responses API забезпечує дотримання цього обмеження та повертає обмежений результат, який зберігає і початок, і кінець виводу, водночас позначаючи пропущений вміст. Наприклад, ви можете обмежити вихідні дані до 1000 символів, зі збереженим початком і кінцем:

текст на початку ... скорочено до 1000 символів ... текст у кінці

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

Одна з потенційних проблем із циклами роботи агента полягає в тому, що завдання можуть виконуватися дуже довго. Довготривалі завдання заповнюють контекстне вікно, що важливо для надання контексту між ходами та між агентами. Агент викликає навичку, отримує відповідь, додає виклики інструментів і підсумки міркувань тощо — і обмежене контекстне вікно швидко заповнюється. Аби уникнути втрати важливого контексту, поки агент продовжує працювати, нам потрібен спосіб зберігати ключові деталі та прибирати все зайве. Замість того, аби вимагати від розробників проєктування та підтримки власних систем узагальнення або перенесення стану, ми додали нативне ущільнення в Responses API, розроблене таким чином, щоб узгоджуватися з тим, як поводиться модель і як її було навчено.

Наші новітні моделі навчені аналізувати попередній стан розмови та створювати елемент ущільнення, який зберігає ключовий попередній стан в зашифрованому, вигідному в плані використання токенів представленні. Після ущільнення наступне контекстне вікно складається з цього елемента ущільнення та високовартісних частин попереднього вікна. Це дає змогу робочим процесам зв’язно продовжуватися через межі вікон, навіть у розширених багатокрокових сеансах і сеансах, керованих інструментами. Codex покладається на цей механізм, щоб підтримувати тривалі завдання кодування та ітеративне виконання інструментів без погіршення якості.

Ущільнення доступне або вбудоване на сервері або через окрему кінцеву точку `/compact`. Ущільнення на стороні сервера дає змогу налаштувати порогове значення, а система автоматично керує часом ущільнення, усуваючи потребу в складній логіці на стороні клієнта. Це дає змогу мати трохи більше ефективне вікно контексту, щоб витримувати невеликі перевищення безпосередньо перед ущільненням, тож запити біля ліміту все ще можна обробити й ущільнити, а не відхилити. У міру розвитку навчання моделей нативне рішення для ущільнення розвивається разом із ними для кожного випуску моделі OpenAI.

Codex допоміг нам створити систему ущільнення, водночас виступивши її раннім користувачем. Коли один екземпляр Codex натрапляв на помилку ущільнення, ми запускали другий екземпляр для її розслідування. У результаті Codex отримав нативну, ефективну систему ущільнення, просто працюючи над проблемами. Ця здатність Codex аналізувати й удосконалювати самого себе стала особливо цікавою частиною роботи в OpenAI. Більшість інструментів лише вимагають від користувача навчитися ними користуватися; Codex же навчається разом із нами.

Тепер розгляньмо стан і ресурси. Контейнер — це не лише місце для виконання команд, а й робочий контекст для моделі. Усередині контейнера модель може читати файли, запитувати бази даних та отримувати доступ до зовнішніх систем під контролем мережевих політик.

Перша частина контексту контейнера — це файлова система для завантаження, упорядкування та керування ресурсами. Ми створили API контейнера та файлу⁠(відкривається у новому вікні), щоб надати моделі мапу доступних даних і допомогти їй вибирати цільові операції з файлами замість виконання широких, зашумлених сканувань.

Поширений контрпродуктивний патерн — пакувати всі вхідні дані безпосередньо в контекст запиту. У міру зростання вхідних даних переповнення запиту стає дорогим, і моделі важко в ньому орієнтуватися. Кращий варіант — підготувати ресурси у файловій системі контейнера й дозволити моделі вирішити, що відкривати, парсити або трансформувати за допомогою shell-команд. Як і люди, моделі краще працюють з упорядкованою інформацією.

Друга частина контексту контейнера — це бази даних. У багатьох випадках ми пропонуємо розробникам зберігати структуровані дані в базах даних, таких як SQLite, і виконувати до них запити. Замість того, щоб, наприклад, копіювати цілу електронну таблицю в запит, ви можете надати моделі опис таблиць (які стовпці існують і що вони означають) і дозволити їй витягувати потрібні їй рядки.

Наприклад, якщо ви поставите питання: «Продажі яких товарів цього кварталу знизилися?», модель може запитати лише відповідні рядки замість сканування всієї таблиці. Це швидше, дешевше, та зручніше для масштабування для більших наборів даних.

Третьою частиною контексту контейнера є доступ до мережі — важлива складова робочих навантажень агента. Робочі процеси агента можуть потребувати отримання актуальних даних, виклику зовнішніх API або встановлення пакетів. Водночас надання контейнерам необмеженого доступу до Інтернету може бути ризикованим: це може розкрити інформацію зовнішнім вебсайтам, ненавмисно зачепити чутливі внутрішні або сторонні системи чи ускладнити захист від витоків облікових даних і ексфільтрації даних.

Щоб вирішити ці проблеми, не обмежуючи корисність агентів, ми побудували hosted containers для використання sidecar egress proxy. Усі вихідні мережеві запити проходять через централізований рівень політик, який забезпечує списки дозволів і контроль доступу, водночас зберігаючи спостережуваність трафіку. Для облікових даних ми використовуємо ін’єкцію секретів з обмеженням доменом на виході. Модель і контейнер бачать лише заповнювачі, тоді як необроблені секретні значення залишаються поза контекстом, видимим для моделі, і застосовуються лише для схвалених призначень. Це зменшує ризик витоку, водночас даючи змогу виконувати автентифіковані зовнішні виклики.

Shell-команди потужні, але багато завдань повторюють одні й ті самі багатокрокові шаблони з кількох кроків. Агенти змушені щоразу заново відкривати для себе робочий процес — переплановувати, повторно віддавати команди та заново вивчати домовленості — що призводить до непослідовних результатів і марного виконання. Навички агента⁠(відкривається у новому вікні) об’єднують ці патерни в багаторазові, компоновані будівельні блоки. Конкретно, навичка — це пакет папок, який містить ‘SKILL.md⁠(відкривається у новому вікні)’ (що містять метадані та інструкції) плюс будь-які допоміжні ресурси, такі як специфікації API та UI-ресурси.

Ця структура природно відповідає архітектурі середовища виконання, яку ми описали раніше. Контейнер надає постійні файли та контекст виконання, а командний процесор (shell-інструмент) надає інтерфейс виконання. Коли присутні обидва компоненти, модель може за потреби знаходити файли навичок за допомогою shell-команд (`ls`, `cat` тощо), інтерпретувати інструкції та запускати скрипти навичок — і все це в межах одного й того самого циклу агента.

Ми надаємо API⁠(відкривається у новому вікні) для керування навичками на платформі OpenAI. Розробники завантажують і зберігають папки навичок як версіоновані пакети, які згодом можна отримати за ідентифікатором навички. Перед надсиланням запиту до моделі Responses API завантажує навичку та включає її в контекст моделі. Ця послідовність є детермінованою:

1. Отримати метадані навичок, зокрема назву й опис.
2. Завантажити пакет навичок, скопіювати його в контейнер і розпакувати.
3. Оновити контекст моделі метаданими навичок і шляхом до контейнера.

Коли модель вирішує, чи є навичка релевантною, вона поступово досліджує свої інструкції та виконує свої скрипти за допомогою shell-команд у контейнері.

Щоб зібрати все докупи: Responses API забезпечує координацію, командний процесор забезпечує виконувані дії, hosted container забезпечує стійкий контекст середовища виконання, навички нашаровують повторно використовувану логіку робочих процесів, а ущільнення дає змогу агенту працювати тривалий час із потрібним йому контекстом.

На основі цього один запит може розгорнутися у повноцінний робочий процес: знайти потрібну навичку, отримати дані, перетворити їх на локальний структурований стан, ефективно виконувати запити до нього та генерувати довговічні інформаційні продукти. 

Схема нижче показує, як ця система працює для створення електронної таблиці з даних у реальному часі.

Щоб ознайомитися з детальним прикладом поєднання командного процесора й середовища обчислення для наскрізних робочих процесів, перегляньте наш допис у блозі для розробників⁠(відкривається у новому вікні) і посібник⁠(відкривається у новому вікні), у яких покроково показано пакування навички та її виконання через Responses API.

Ми з нетерпінням чекаємо на рішення, які зможуть створити розробники із цим базовим набором. Мовні моделі призначені для більшого, ніж просто генерування тексту, зображень і аудіо. Ми й надалі розвиватимемо нашу платформу, аби вона ставала більш спроможною виконувати складні реальні завдання в масштабі.