От модел към агент: Оборудване на 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 команди — моделите GPT‑5.2 и по-нови са обучени за това. С целия този контекст моделът след това решава следващото действие. Ако избере изпълнение в обвивката, връща една или повече shell команди към услугата Responses API. API услугата препраща тези команди към средата за изпълнение на контейнера, стриймва обратно изходните данни към обвивката и ги подава към модела в контекста на следващата заявка. След това моделът може да прегледа резултатите, да издаде последващи команди или да предостави финален отговор. Responses API повтаря този цикъл, докато моделът не върне завършване без допълнителни shell команди.

КогатоResponses API изпълнява shell команда, той поддържа поточна връзка към услугата на контейнера. Докато се генерира изходът, API го препраща към модела почти в реално време, за да може моделът да реши дали да изчака още изходни данни, да изпълни друга команда или да премине към окончателен отговор.

Моделът може да предложи множество shell команди в една стъпка, а Responses API може да ги изпълни едновременно, като използва отделни сесии на контейнера. Всяка сесия предава изходните данни независимо, а API мултиплексира тези потоци обратно в структурирани изходи на инструмента като контекст. С други думи, цикълът на агента може да паралелизира работата, като например търсене на файлове, извличане на данни и валидиране на междинни резултати.

Когато командата включва операции с файлове или обработка на данни, изходът на shell команда може да стане много голям и да изразходва бюджети за контекст, без да добавя полезни сигнали. За да се контролира това, моделът задава ограничение на изхода за всяка команда. Responses API налага това ограничение и връща ограничен резултат, който запазва както началото, така и края на изхода, като същевременно маркира пропуснатото съдържание. Например може да ограничите изхода до 1 000 знака със запазено начало и край:

текст в началото ... 1000 знака са съкратени ... текст в края

Заедно с това едновременното изпълнение и ограничените изходни данни правят цикъла на агента бърз и ефективен по отношение на контекста, така че моделът може да продължи структурирано анализиране върху съответните резултати, вместо да се претоварва с необработени крайни записи.

Един потенциален проблем с циклите на агентите е, че задачите могат да се изпълняват дълго време. Дългосрочните задачи запълват контекстния прозорец, който е важен за осигуряване на контекст между ходовете и агентите. Представете си агент, който заявява умение, получава отговор, добавя извиквания на инструменти и обобщения на структурирано анализиране — ограниченият контекстен прозорец бързо се запълва. За да избегнем загубата на важния контекст, докато агентът продължава да работи, ни е необходим начин да запазим ключовите подробности и да премахнем всичко излишно. Вместо да изискваме от разработчиците да проектират и поддържат персонализирани системи за обобщаване или пренасяне на състояние, добавихме вградена компакция в Responses API, проектирана да е в съответствие на поведението на модела и на начина, по който е обучен.

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

Компресирането е налично или вградено на сървъра, или чрез самостоятелна крайна точка `/compact`. Компресирането от страна на сървъра Ви позволява да конфигурирате праг, а системата обработва времето за компресиране автоматично, като елиминира нуждата от сложна логика от страна на клиента. Това позволява малко по-голям ефективен контекстен прозорец за входни данни, за да се толерират малки превишения точно преди компресирането, така че заявки близо до лимита все още да могат да бъдат обработени и уплътнени, вместо да бъдат отхвърлени. Тъй като обучението на моделите се развива, собственото решение за компресиране се развива заедно с него за всяка версия на модела на OpenAI.

Codex ни помогна да изградим системата за компресиране, като същевременно служеше като неин ранен потребител. Когато един екземпляр на Codex срещне грешка при компактиране, стартирахме втори екземпляр, за да го изследваме. Резултатът беше, че Codex получи собствена, ефективна система за компактиране само като работеше по проблема. Тази способност на Codex да се самоанализира и усъвършенства се превърна в особено интересна част от работата в OpenAI. Повечето инструменти изискват само потребителят да се научи да ги използва. Codex се учи заедно с нас.

Сега нека разгледаме състоянието и ресурсите. Контейнерът не е само място за изпълнение на команди, но и работният контекст за модела. В контейнера моделът може да чете файлове, да прави заявки към бази данни и да осъществява достъп до външни системи под контрола на мрежовите политики.

Първата част от контекста на контейнера е файловата система за качване, организиране и управление на ресурси. Създадохме API за контейнер и файл⁠(отваря се в нов прозорец), за да дадем на модела карта на наличните данни и да му помогнем да избира целеви операции с файлове, вместо да извършва широки, шумни сканирания.

Често срещан антишаблон е да се вкарва целият вход директно в контекста на подканата. С нарастването на входните данни препълването на подкана става скъпо и за модела е трудно да се ориентира. По-добър модел е да подготвите ресурсите във файловата система на контейнера и да оставите модела да реши какво да отвори, анализира или трансформира с shell команди. Подобно на хората, моделите работят по-добре с организирана информация.

Втората част от контекста на контейнера са базите данни. В много случаи предлагаме на разработчиците да съхраняват структурирани данни в бази данни като SQLite и да правят заявки към тях. Вместо например да копирате цяла електронна таблица в подкана, можете да дадете на модела описание на таблиците — какви колони съществуват и какво означават — и да му позволите да извлече редовете, от които се нуждае.

Например, ако попитате „Кои продукти имаха спад в продажбите през това тримесечие?“, моделът може да направи заявка към само съответните редове, вместо да сканира цялата електронна таблица. Това е по-бързо, по-евтино, по-мащабируемо за по-големи набори от данни.

Третата част от контекста на контейнера е мрежовият достъп, съществена част от натоварванията на агентите. Работният процес на агента може да се наложи да извлича данни в реално време, да извиква външни API или да инсталира пакети. В същото време предоставянето на контейнери неограничен достъп до интернет може да бъде рисковано: може да изложи информация на външни уебсайтове, неволно да осъществи контакт с чувствителни вътрешни системи или системи на трети страни, или да направи изтичането на идентификационни данни и ексфилтрацията на данни по-трудни за предотвратяване.

За да отговорим на тези опасения, без да ограничаваме полезността на агентите, създадохме хоствани контейнери, които да използват страничен прокси сървър за изходящи данни. Всички изходящи мрежови заявки преминават през централизирано ниво на политики, което налага списъци с разрешени елементи и контроли за достъп, като същевременно поддържа трафика наблюдаем. За идентификационни данни използваме инжектиране на тайни с обхват на домейна при изходящ трафик. Моделът и контейнерът виждат само заместители, докато необработените стойности на тайните остават извън контекста, видим за модела, и се прилагат само за одобрени дестинации. Това намалява риска от изтичане, като същевременно позволява удостоверени външни повиквания.

Shell командите са мощни, но много задачи повтарят едни и същи многоетапни модели от няколко стъпки. Агентите трябва да преоткриват работния процес при всяко изпълнение — да планират наново, да издават повторно команди и да научават отново конвенциите — което води до непоследователни резултати и загуба на време. Умения на агента⁠(отваря се в нов прозорец) обединяват тези модели в градивни елементи за многократна употреба, които могат да се комбинират. По-конкретно, умението е пакет от папки, който включва „SKILL.md⁠(отваря се в нов прозорец)“ (съдържаща метаданни и инструкции), както и всички помощни ресурси, като спецификации на API и активи на потребителския интерфейс.

Тази структура естествено се съпоставя с архитектурата на изпълнение, която описахме по-рано. Контейнерът предоставя постоянни файлове и контекст за изпълнение, а инструментът за обвивка предоставя интерфейса за изпълнение. С наличието и на двете, моделът може да открива файлове с умения, използвайки shell команди („ls“, „cat“, и т.н.) когато е необходимо, да интерпретира указания и да изпълнява скриптове за умения — всичко това в рамките на един и същ цикъл на агента.

Предоставяме API⁠(отваря се в нов прозорец) за управление на умения в платформата на OpenAI. Разработчиците качват и съхраняват папки с умения като пакети с версии, които по-късно могат да бъдат извлечени по идентификатор на умението. Преди да изпрати подкана към модела, Responses API зарежда умението и го включва в контекста на модела. Тази последователност е определяща:

1. Извличане на метаданни за умение, включително име и описание.
2. Извлечете пакета с умения, копирайте го в контейнера и го разархивирайте.
3. Актуализирайте контекста на модела с метаданните за уменията и пътя до контейнера.

Когато решава дали дадено умение е подходящо, моделът постепенно проучва инструкциите му и изпълнява скриптовете му чрез shell команди в контейнера.

За да съберем всички части: Responses API осигурява оркестрация, инструментът за обвивка осигурява изпълними действия, хостваният контейнер осигурява постоянен контекст на средата за изпълнение, уменията осигуряват логика на работния процес за многократна употреба, а компактирането позволява на агент да работи дълго време с необходимия контекст.

С тези примитиви една-единствена подкана може да се превърне в цялостен работен процес от край до край: да открива правилното умение, да извлече данни, да ги преобразува в локално структурирано състояние, да ги заявява ефективно и да генерира трайни артефакти. 

Диаграмата по-долу показва как тази система работи за създаване на електронна таблица от данни в реално време.

За задълбочен пример за комбиниране на инструмента за обвивка и компютърната среда за работни процеси от край до край вижте нашата публикация в блога за разработчици⁠(отваря се в нов прозорец) и рецепти за код⁠(отваря се в нов прозорец), които показват стъпка по стъпка как да пакетирате умение и да го изпълните чрез Responses API.

С нетърпение очакваме да видим какво ще създадат разработчиците с този набор от примитиви. Езиковите модели са предназначени да правят повече от генерирането на текст, изображения и аудио – ще продължим да развиваме нашата платформа, за да стане по-способна да се справя със сложни задачи от реалния свят в голям мащаб.