Од модел до агент: Опремување на одговорите на API со компјутерска средина

Моментално сме во премин од користење модели, кои се истакнуваат во одредени задачи, кон користење агенти способни да се справуваат со сложени работни процеси. Со промптирање на модели, може да пристапите само до обучена интелигенција. Сепак, давањето на модел компјутерска средина може да постигне многу поширок спектар на случаи на употреба, како извршување услуги, барање податоци од API или генерирање покорисни артефакти како електронски табели или извештаи.

Неколку практични проблеми се појавуваат кога се обидувате да изградите агенти: каде да ги ставите меѓуфазните датотеки, како да избегнете вметнување големи табели во промпт, како да му дадете на работниот процес мрежен пристап без да создадете безбедносна главоболка и како да се справите со истекувања на време и повторни обиди без самите да изградите систем за работни процеси.

Наместо да им оставиме на програмерите да создаваат свои околини за извршување, ги создадовме потребните компоненти за да ги опремиме одговорите на API⁠(се отвора во нов прозорец) со компјутерска околина за сигурно извршување на задачи од реалниот свет.

Одговорите на API на OpenAI, заедно со shell алатката и хостиран работен простор во контејнер, е дизајниран да ги реши овие практични проблеми. Моделот предлага чекори и команди; платформата ги извршува во изолирана средина со датотечен систем за влезни и излезни податоци, опционално структурирано складирање (како SQLite) и ограничен пристап до мрежата. 

Во оваа објава, ќе објасниме како изградивме компјутерска средина за агенти и ќе споделиме некои рани лекции за тоа како да ја користиме за побрзи, поповторливи и побезбедни работни процеси во продукција.

Добар работен процес на агент започнува со тесен циклус на извршување: моделот предлага дејство, како што е читање датотеки или преземање податоци преку API, платформата го извршува, а резултатот се влева во следниот чекор. Ќе започнеме со shell алатката – наједноставниот начин да ја видите овој циклус во акција – а потоа ќе ги опфатиме работен простор на контејнерот, мрежното поврзување, повторно употребливите вештини и компактирањето на контекстот.

За да ја разберете shell алатката, прво е корисно да разберете како јазичниот модел користи алатки воопшто: за да прави работи како повикување функција или интеракција со компјутер. За време на обуката, на моделот му се прикажуваат примери за тоа како се користат алатките и какви се резултатите, чекор по чекор. Ова му помага на моделот да научи да одлучува кога да користи алатка и како да ја користи. Кога велиме „користење алатка“, мислиме дека моделот всушност само предлага повик на алатка. Не може сам по себе да го изврши повикот.

Shell алатката го прави моделот драматично помоќен: комуницира со компјутер преку командната линија за да извршува широк спектар на задачи, од пребарување текст до испраќање API барања на вашиот компјутер. Изградена врз познати Unix алатки, нашата shell алатка може да направи сè што би очекувале, со алатки како grep, curl и awk достапни веднаш.

Во споредба со нашиот постоечки толкувач на кодови, кој извршува само Python, shell алатката овозможува многу поширок спектар на случаи на употреба, како извршување Go или Java програми или стартување NodeJS сервер. Оваа флексибилност му овозможува на моделот да извршува сложени агентски задачи.

Сам по себе, моделот може само да предлага shell команди, но како се извршуваат овие команди? Ни треба оркестратор за да го добиеме излезот од моделот, да повикуваме алатки и да го проследуваме одговорот од алатката назад до моделот во циклус, сè додека задачата не биде завршена.

Одговорите на API е начинот на кој програмерите комуницираат со модел на OpenAI. Кога се користи со сопствени алатки, одговорите на API ја враќа контролата назад на клиентот, а клиентот бара сопствен систем за извршување на алатките. Сепак, овој API може и веднаш да оркестрира помеѓу моделот и хостираните алатки. 

Кога Responses API ќе прими промпт, го составува контекстот на модел: кориснички промпт, претходна состојба на разговорот и инструкции за алатки. За извршувањето на shell да функционира, промптот мора да спомене користење на shell алатката and избраниот модел мора да биде обучен да предлага shell команди – моделите GPT‑5.2 и понови се обучени за ова. Со целиот овој контекст, моделот потоа го одлучува следното дејство. Ако избере извршување на shell, враќа една или повеќе shell команди до сервисот одговорите на API. API услугата ги проследува тие команди до runtime-от на контејнерот, стримува назад shell резултат и го доставува до моделот во контекстот на следното барање. Моделот потоа може да ги прегледа резултатите, да издаде дополнителни команди или да произведе конечен одговор. Одговорите на API го повторува овој циклус додека модел не врати завршување без дополнителни shell команди.

Кога одговорите на API извршуваат shell команда, одржува стриминг врска со услугата за контејнери. Како што се произведува излезот, API-то го пренесува до моделот речиси во реално време за да може моделот да одлучи дали да почека за повеќе резултати, да изврши друга команда или да продолжи кон конечен одговор.

Моделот може да предложи повеќе shell команди во еден чекор, а одговорите на API може да ги изврши истовремено користејќи одделни сесии на контејнер. Секоја сесија независно пренесува резултати, а API ги мултиплексира тие стримови назад во структурирани резултати на алатката како контекст. Со други зборови, циклусот на агентот може да ја паралелизира работата, како што се пребарување датотеки, преземање податоци и валидација на средни резултати.

Кога командата вклучува операции со датотеки или обработка на податоци, резултатите од shell може да стане многу голем и да ги троши буџетите за контекст без да додава корисни сигнали. За да се контролира ова, моделот наведува ограничување на резултатите по команда. Одговорите на API го наметнува тој лимит и враќа ограничен резултат што ги зачувува и почетокот и крајот на резултатот, притоа означувајќи ја изоставената содржина. На пример, можеш да го ограничиш резултатот на 1.000 знаци, со зачуван почеток и крај:

текст на почетокот ... 1.000 знаци скратени ... текст на крајот

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

Еден потенцијален проблем со циклусите на агентот е дека задачите може да се извршуваат долго време. Долготрајните задачи го исполнуваат прозорецот за контекст, што е важно за обезбедување контекст низ повеќе чекори и низ повеќе агенти. Замисли агент што повикува вештина, добива одговор, додава повици на алатки и резимеа на расудување – ограничениот контекстуален прозорец брзо се полни. За да избегнеме губење на важниот контекст додека агентот продолжува да работи, ни треба начин да ги задржиме клучните детали и да отстраниме сè што е непотребно. Наместо да бараме од развивачите да дизајнираат и одржуваат сопствени системи за сумирање или системи што носат состојба, додадовме вградена компакција во одговорите на API, дизајнирана да се усогласи со тоа како се однесува моделот и како е обучен.

Нашите најнови модели се обучени да ја анализираат претходната состојба на разговорот и да произведат елемент за компактирање што ја зачувува клучната претходна состојба во шифрирана токен-ефикасна репрезентација. По компактирањето, следниот прозорец за контекст се состои од оваа ставка за компактирање и делови со висока вредност од претходниот прозорец. Ова им овозможува на работните процеси да продолжат кохерентно низ границите на прозорците, дури и во продолжени повеќечекорни сесии и сесии водени од алатки. Codex се потпира на овој механизам за да одржува долготрајни задачи за кодирање и итеративно извршување на алатки без да се наруши квалитетот.

Компактирањето е достапно или вградено на серверот или преку самостојна крајна точка `/compact`. Компактирањето на серверската страна ви овозможува да конфигурирате праг, а системот автоматски го управува времето на компактирање, елиминирајќи ја потребата од сложена логика на клиентската страна. Овозможува малку поголем ефективен прозорец за контекст на внесување за да толерира мали пречекорувања непосредно пред компактирање, па барањата близу до ограничувањето сè уште може да се обработат и компактираат наместо да се одбијат. Како што се развива обуката за модел, природното решение за компактирање се развива со него за секое издание на модел на OpenAI.

Codex ни помогна да го изградиме системот за компактирање, додека служеше како ран корисник на него. Кога една инстанца на Codex ќе наидеше на грешка при компактирање, ќе стартувавме втора инстанца за да истражиме. Резултатот беше дека Codex доби изворен, ефикасен систем за компактирање само со работа на проблемот. Оваа способност на Codex да се проверува и усовршува себеси стана особено интересен дел од работата во OpenAI. Повеќето алатки бараат од корисникот само да научи како да ги користи; Codex учи заедно со нас.

Сега, да ги опфатиме состојбата и ресурсите. Контејнерот не е само место за извршување команди, туку и работниот контекст за моделот. Во контејнерот, моделот може да чита датотеки, да прави пребарувања во бази на податоци и да пристапува до надворешни системи под контроли на мрежни политики.

Првиот дел од контекстот на контејнерот е датотечниот систем за поставување, организирање и управување со ресурси. Изградивме API за контејнер и датотека⁠(се отвора во нов прозорец) за да му дадеме на моделот мапа на достапните податоци и да му помогнеме да избере насочени операции со датотеки наместо да извршува широки, бучни скенирања.

Вообичаена анти-шема е да се спакуваат сите сите влезни податоци директно во контекстот на промпт. Како што влезовите растат, преполнувањето на промптот станува скапо и тешко за моделот да се снајде. Подобар образец е да се постават ресурсите во датотечниот систем на контејнерот и да му се дозволи на моделот да одлучи што да отвори, парсира или трансформира со shell команди. Слично како и луѓето, и моделот работи подобро со организирани информации.

Вториот дел од контекстот на контејнерот се базите на податоци. Во многу случаи, им предлагаме на развивачите да складираат структурирани податоци во бази на податоци како SQLite и да ги пребаруваат. Наместо да копираш цела електронска табела во промптот, на пример, можеш да му дадеш на моделот опис на табелите – кои колони постојат и што значат – и да му дозволиш да ги извлече редовите што му се потребни.

На пример, ако прашаш: „Кои производи имаа опаѓачка продажба ова тримесечје?“, моделот може да ги пребара само релевантните редови наместо да ја скенира целата табела. Ова е побрзо, поевтино, поскалибилно за поголеми бази на податоци.

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

За да ги решиме овие проблеми без да ја ограничиме корисноста на агентите, изградивме хостирани контејнери за да користиме прокси за излез преку спореден прокси за излезен пристап. Сите излезни мрежни барања течат низ централизиран слој за политики што спроведува листи на дозволи и контроли на пристап, додека го одржува сообраќајот видлив. За акредитиви, користиме вметнување тајни со опсег на домен на излезен пристап. Моделот и контејнерот гледаат само резервирани места, додека необработените тајни вредности остануваат надвор од контекстот видлив за моделот и се применуваат само за одобрени дестинации. Ова го намалува ризикот од протекување информации, додека сè уште овозможува автентицирани надворешни повици.

Shell командите се моќни, но многу задачи ги повторуваат истите шеми со повеќе чекори. Агентите мора да го откриваат работниот процес одново при секое извршување – повторно планирање, повторно издавање команди и повторно учење конвенции – што води до неконзистентни резултати и залудно извршување. Вештини на агентот⁠(се отвора во нов прозорец) ги пакуваат тие шаблони во повторно употребливи, составливи градежни блокови. Конкретно, вештината е пакет папки што го вклучува „SKILL.md⁠(се отвора во нов прозорец)“ (што содржи метаподатоци и инструкции) плус сите придружни ресурси, како што се API спецификации и средства за кориснички интерфејс.

Оваа структура природно се поврзува со архитектурата на извршување што ја опишавме претходно. Контејнерот обезбедува трајни датотеки и контекст за извршување, а алатката shell го обезбедува интерфејсот за извршување. Со двете на место, моделот може да открива датотеки со вештини користејќи команди на shell („ls“, „cat“, итн.) кога му е потребно, да ги толкува инструкциите и да извршува скрипти за вештини, сè во истиот циклус на агентот.

Нудиме API-ја⁠(се отвора во нов прозорец) за управување со вештини на платформата OpenAI. Програмерите прикачуваат и складираат папки со вештини како верзионирани пакети, кои подоцна може да се преземат по ID на вештина. Пред да го испрати промптот до моделот, одговорите на API ја вчитуваат вештината и ја вклучуваат во контекстот на модел. Оваа секвенца е детерминистичка:

1. Преземете метаподатоци за вештините, вклучувајќи име и опис.
2. Преземете го пакетот со вештини, копирајте го во контејнерот и распакувајте го.
3. Ажурирај го контекстот на моделот со метаподатоци за вештините и патеката на контејнерот.

Кога одлучува дали некоја вештина е релевантна, моделот прогресивно ги истражува нејзините упатства и ги извршува нејзините скрипти преку shell команди во контејнерот.

За да ги составиме сите делови: одговорите на API обезбедува оркестрација, алаткатка shellобезбедува извршливи дејства, хостираниот контејнер обезбедува постојан контекст на извршување, слојот вештини додава повторно употреблива логика за работни процеси, а компактирањето му овозможува на агентот да работи долго време со контекстот што му е потребен.

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

Дијаграмот подолу прикажува како функционира овој систем за креирање електронска табела од податоци во живо.

За подетален пример за комбинирање на shell алатката и компјутерската средина за работни текови од крај до крај, погледнете ја нашата објава на блогот за развивачи⁠(се отвора во нов прозорец) и готварска книга⁠(се отвора во нов прозорец) што ве водат низ пакувањето на вештина и нејзиното извршување преку одговорите на API.

Возбудени сме да видиме што ќе изградат програмерите со овој сет на примитиви. Јазичните модели се наменети да прават повеќе од само генерирање текст, слики и аудио – ќе продолжиме да ја развиваме нашата платформа за да стане поспособна во справувањето со сложени задачи од реалниот свет во голем обем.