Od modelu k agentovi: Vybavení rozhraní Responses API počítačovým prostředím

V současné době přecházíme od používání modelů, které vynikají v konkrétních úkolech, k používání agentů schopných zvládat složité pracovní postupy. Pomocí promptování modelů můžeš získat přístup pouze k natrénované inteligenci. Poskytnutí počítačového prostředí modelu ale může umožnit mnohem širší škálu případů použití, jako je spouštění služeb, žádání dat z rozhraní API nebo generování užitečnějších artefaktů, jako jsou tabulky nebo reporty.

Při pokusu o vytváření agentů se objeví několik praktických problémů: kam ukládat dočasné soubory, jak se vyhnout vkládání velkých tabulek do promptu, jak dát pracovnímu postupu přístup k síti, aniž by to způsobilo bezpečnostní noční můru, a jak řešit časové limity a opakované pokusy bez nutnosti vybudovat vlastní systém pracovního postupu.

Místo toho, abychom vývojářům přenechali vytváření vlastních prostředí provádění, jsme vytvořili potřebné komponenty, které vybaví rozhraní Responses API⁠(otevře se v novém okně) počítačovým prostředím pro spolehlivé vykonávání reálných úloh.

Rozhraní Responses API od OpenAI je spolu s nástrojem shell a hostovaným pracovním prostorem kontejneru navrženo tak, aby tyto praktické problémy řešilo. Model navrhuje kroky a příkazy, platforma je spouští v izolovaném prostředí se souborovým systémem pro vstupy a výstupy, volitelným strukturovaným úložištěm (jako SQLite) a omezeným přístupem k síti. 

V tomto příspěvku rozebereme, jak jsme vytvořili počítačové prostředí pro agenty, a podělíme se o první poznatky o tom, jak ho používat pro rychlejší, opakovatelnější a bezpečnější produkční pracovní postupy.

Dobrý pracovní postup agenta začíná těsnou prováděcí smyčkou: model navrhne akci, jako je čtení souborů nebo načítání dat pomocí rozhraní API, platforma ji spustí a výsledek se promítne do dalšího kroku. Začneme s nástrojem shell – nejjednodušším způsobem, jak vidět tuto smyčku v akci – a poté se budeme zabývat pracovním prostorem kontejneru, sítí, opakovaně použitelnými dovednostmi a zhutňováním kontextu.

Abychom porozuměli nástroji shell, je nejprve užitečné pochopit, jak jazykový model obecně používá nástroje: aby dělal věci jako volání funkce nebo interakci s počítačem. Během trénování se modelu krok za krokem ukazují příklady toho, jak se nástroje používají a jaký to má výsledný efekt. To pomáhá modelu naučit se rozhodovat, kdy a jak nástroj použít. Když říkáme „používání nástroje“, myslíme tím, že model ve skutečnosti pouze navrhuje volání nástroje. Nemůže sám o sobě provést volání.

Nástroj shell dramaticky zvyšuje výkon modelu: prostřednictvím příkazového řádku interaguje s počítačem a provádí širokou škálu úloh, od vyhledávání textu až po odesílání požadavků rozhraní API na počítači. Náš nástroj, shell postavený na známých unixových nástrojích, dokáže cokoli, co byste očekávali, s nástroji jako grep, curl a awk dostupnými hned ve výchozím nastavení.

Ve srovnání s naším stávajícím interpretem kódu, který spouští pouze Python, umožňuje nástroj shell mnohem širší škálu případů použití, jako je spouštění programů v jazyce Go nebo Java nebo spuštění serveru NodeJS. Tato flexibilita umožňuje modelu plnit složité agentní úkoly.

Sám o sobě může model pouze navrhovat příkazy shell, ale jak se tyto příkazy vykonávají? Potřebujeme orchestrátor, který získá výstup modelu, vyvolá nástroje a ve smyčce bude předávat odpovědi nástroje zpět modelu, dokud nebude úloha dokončena.

Rozhraní API Responses je způsob, jakým vývojáři komunikují s modely OpenAI. Při použití s vlastními nástroji rozhraní Responses API předá řízení zpět klientovi a klient si vyžádá vlastní harness pro spouštění nástrojů. Toto rozhraní API však dokáže také hned ve výchozím nastavení orchestrovat mezi modelem a hostovanými nástroji. 

Když rozhraní Responses API obdrží prompt, sestaví kontext modelu: prompt uživatele, předchozí stav konverzace a pokyny pro nástroje. Aby provádění shell fungovalo, prompt musí zmiňovat použití nástroje shell a vybraný model musí být natrénovaný tak, aby navrhoval příkazy shell – modely GPT‑5.2 a novější jsou na to natrénované. S ohledem na celý tento kontext se model poté rozhodne o dalším kroku. Pokud zvolí spuštění nástroje shell, vrátí službě rozhraní Responses API jeden nebo více příkazů shell. Služba rozhraní API předá tyto příkazy běhovému prostředí kontejneru, streamuje zpět výstup shell a v dalším kontextu požadavku ho předá modelu. Model pak může zkontrolovat výsledky, vydat doplňující příkazy nebo vytvořit konečnou odpověď. Rozhraní Responses API opakuje tuto smyčku, dokud model nevrátí dokončení bez dalších příkazů shell.

Když rozhraní Responses API spustí příkaz shell, udržuje streamované připojení ke službě kontejneru. Jakmile je vytvořen výstup, rozhraní API ho předá modelu téměř v reálném čase, aby se model mohl rozhodnout, zda počkat na další výstup, spustit další příkaz, nebo přejít k finální odpovědi.

Model dokáže v jednom kroku navrhnout více příkazů shell a rozhraní Responses API je dokáže spustit souběžně pomocí samostatných relací kontejneru. Každá relace streamuje výstup nezávisle a rozhraní API tyto streamy multiplexuje zpět do strukturovaných výstupů nástrojů jako kontext. Jinými slovy, smyčka agenta dokáže paralelizovat práci, například prohledávání souborů, načítání dat a ověřování průběžných výsledků.

Když příkaz zahrnuje operace se soubory nebo zpracování dat, výstup shell může být velmi rozsáhlý a spotřebovávat rozpočty kontextu, aniž by přidal užitečné signály. Aby to model řídil, určuje limit výstupu pro každý příkaz. Rozhraní Responses API tento limit vynucuje a vrací ohraničený výsledek, který zachovává jak začátek, tak konec výstupu, a zároveň označuje vynechaný obsah. Například můžeš omezit výstup na 1000 znaků se zachovaným začátkem a koncem:

text na začátku... 1000 znaků zkráceno... text na konci

Dohromady je díky souběžnému provádění a omezenému výstupu smyčka agenta rychlá i kontextově efektivní, takže model může dál uvažovat nad relevantními výsledky, místo aby ho zahltily nezpracované protokoly terminálu.

Jedním z možných problémů se smyčkami agenta je, že úlohy mohou běžet dlouho. Dlouhotrvající úlohy zaplňují kontextové okno, což je důležité k poskytování kontextu napříč obraty a agenty. Představ si agenta, který zavolá dovednost, dostane odpověď, přidá volání nástrojů a shrnutí uvažování – omezené kontextové okno se rychle zaplní. Abychom se vyhnuli ztrátě důležitého kontextu, zatímco agent nadále běží, potřebujeme způsob, jak zachovat klíčové údaje a odstranit vše nadbytečné. Místo toho, abychom po vývojářích vyžadovali návrh a údržbu vlastních systémů pro sumarizaci nebo přenášení stavu, přidali jsme do rozhraní Responses API nativní kompakci, navrženou tak, aby odpovídala tomu, jak se model chová a jak byl trénován.

Naše nejnovější modely jsou vytrénované k analýze předchozího stavu konverzace a k vytvoření položky kompakce, která zachovává klíčový předchozí stav v šifrované reprezentaci, která je efektivní z pohledu množství tokenů. Po kompakci se další kontextové okno skládá z této položky kompakce a částí předchozího okna s vysokou hodnotou. To umožňuje, aby pracovní postupy pokračovaly koherentně napříč hranicemi oken, a to i v rozšířených vícekrokových relacích řízených nástroji. Codex spoléhá na tento mechanismus při provádění dlouhotrvajících úkolů kódování a iterativním spouštění nástrojů bez zhoršení kvality.

Kompakce je k dispozici buď integrovaná na serveru, nebo prostřednictvím samostatného koncového bodu `/compact`. Kompakce na straně serveru umožňuje nakonfigurovat prahovou hodnotu a systém automaticky zajišťuje načasování kompakce, čímž eliminuje potřebu složité logiky na straně klienta. Umožňuje o něco větší efektivní okno vstupního kontextu, které toleruje malé překročení limitu těsně před kompakcí, takže požadavky blízké limitu lze stále zpracovat a provést jejich kompakci, a ne je odmítnout. S tím, jak se vyvíjí trénování modelů, se vyvíjí i nativní řešení pro kompakci pro každé vydání modelu OpenAI.

Codex nám pomohl vybudovat systém kompakce a zároveň sloužil jako jeden z jeho prvních uživatelů. Když u jedné instance Codex došlo k chybě kompakce, spustili jsme druhou instanci, abychom to prošetřili. Výsledkem bylo, že Codex získal nativní, efektivní systém kompakce pouhou prací na problému. Tato schopnost nástroje Codex zkoumat a zdokonalovat sám sebe se stala obzvláště zajímavou součástí práce v OpenAI. Většina nástrojů po uživateli vyžaduje jen to, aby se naučil je používat, Codex se učí spolu s námi.

Teď se pojďme věnovat stavu a prostředkům. Kontejner není jen místo pro spouštění příkazů, ale také pracovní kontext pro model. Uvnitř kontejneru může model číst soubory, dotazovat databáze a přistupovat k externím systémům v rámci kontrol zásad sítě.

První část kontextu kontejneru je souborový systém pro nahrávání, organizování a správu prostředků. Vytvořili jsme rozhraní API pro kontejnery a soubory⁠(otevře se v novém okně), abychom modelu poskytli mapu dostupných dat a pomohli mu zvolit cílené operace se soubory namísto provádění rozsáhlých, hlučných skenů.

Běžným nevhodným vzorem je zahrnout všechny vstupy přímo do kontextu promptu. S tím, jak se vstupy zvětšují, se přeplňování promptu stává nákladným a pro model je obtížné se v něm orientovat. Lepší vzor je připravit prostředky v souborovém systému kontejneru a nechat model rozhodnout, co otevřít, analyzovat nebo transformovat pomocí příkazů shell. Modely, podobně jako lidé, pracují lépe s uspořádanými informacemi.

Druhou částí kontextu kontejneru jsou databáze. V mnoha případech doporučujeme vývojářům ukládat strukturovaná data do databází jako SQLite a dotazovat se na ně. Místo kopírování celé tabulky do promptu můžeš například modelu dát popis tabulek – jaké sloupce existují a co znamenají – a nechat ho vzít řádky, které potřebuje.

Například pokud se zeptáš: „Které produkty měly v tomto čtvrtletí klesající prodeje?“, model může dotazovat jen relevantní řádky místo procházení celé tabulky. Je to rychlejší, levnější a lépe škálovatelné pro větší datové sady.

Třetí část kontextu kontejneru je síťový přístup, což je nezbytná součást úloh agenta. Pracovní postup agenta může potřebovat načítat živá data, volat externí rozhraní API nebo instalovat balíčky. Zároveň může být poskytnutí neomezeného přístupu kontejnerů k internetu riskantní: může to způsobit zpřístupnění informací externím webům, neúmyslně přistupovat k citlivým interním systémům nebo systémům třetích stran nebo ztížit ochranu před úniky přihlašovacích údajů a exfiltrací dat.

K řešení těchto problémů bez omezení užitečnosti agentů jsme vytvořili hostované kontejnery, které používají odchozí proxy v sidecar. Všechny odchozí síťové požadavky procházejí centralizovanou vrstvou zásad, která vynucuje seznamy povolených položek a řízení přístupu a zároveň zachovává pozorovatelnost provozu. Pro přihlašovací údaje používáme na výstupu injektáž tajných údajů s rozsahem domény. Model a kontejner vidí pouze zástupné symboly, zatímco nezpracované tajné hodnoty zůstávají mimo kontext viditelný pro model a použijí se pouze pro schválené cíle. Tím se snižuje riziko úniku a zároveň jsou přesto možná ověřená externí volání.

Příkazy shell jsou výkonné, ale mnoho úloh opakuje stejné vícestupňové vzory. Agenti musí při každém spuštění znovu objevovat pracovní postup – znovu plánovat, znovu vydávat příkazy a znovu se učit konvence – což vede k nekonzistentním výsledkům a zbytečně promarněnému času při provádění. Dovednosti agenta⁠(otevře se v novém okně) balí tyto vzorce do opakovaně použitelných, kombinovatelných stavebních bloků. Konkrétně je dovednost balíček složky, který obsahuje soubor „SKILL.md⁠(otevře se v novém okně)“ (obsahující metadata a instrukce) plus veškeré podpůrné zdroje, jako jsou specifikace rozhraní API a prostředky uživatelského rozhraní.

Tato struktura se přirozeně mapuje na běhovou architekturu, kterou jsme popsali dříve. Kontejner poskytuje trvalé soubory a kontext provádění a nástroj shell poskytuje rozhraní pro spouštění. Když jsou obě věci na svém místě, model může podle potřeby objevovat soubory dovedností pomocí příkazů shell (`ls`, `cat` atd.), interpretovat pokyny a spouštět skripty dovedností, a to vše v rámci stejné smyčky agenta.

Na platformě OpenAI poskytujeme rozhraní API⁠(otevře se v novém okně) ke správě dovedností. Vývojáři nahrávají a ukládají složky dovedností jako verzované balíčky, které lze později načíst pomocí ID dovednosti. Před odesláním promptu do modelu rozhraní Responses API načte dovednost a zahrne ji do kontextu modelu. Tato sekvence je deterministická:

1. Načíst metadata dovednosti, včetně názvu a popisu.
2. Načíst balík dovedností, zkopírovat ho do kontejneru a rozbalit ho.
3. Aktualizovat kontext modelu o metadata dovedností a cestu ke kontejneru.

Při rozhodování o tom, zda je dovednost relevantní, model postupně prochází její pokyny a spouští její skripty prostřednictvím příkazů shell v kontejneru.

Abychom to všechno dali dohromady: Responses API poskytuje orchestraci, nástroj shell poskytuje spustitelné akce, hostovaný kontejner poskytuje perzistentní běhový kontext, dovednosti vrství znovupoužitelnou logiku pracovních postupů a kompakce umožňuje agentovi běžet dlouhodobě s kontextem, který potřebuje.

S těmito základy se může jediný prompt rozšířit do komplexního pracovního postupu: objevit správnou dovednost, načíst data, transformovat je do lokálního strukturovaného stavu, efektivně je dotazovat a generovat trvalé artefakty. 

Níže uvedený diagram znázorňuje, jak tento systém funguje při vytváření tabulky z živých dat.

Podrobný příklad kombinace nástroje shell a prostředí počítače pro kompletní pracovní postupy najdeš v našem příspěvku na blogu pro vývojáře⁠(otevře se v novém okně) a v kuchařce⁠(otevře se v novém okně), které vás provedou zabalením dovednosti a jejím spuštěním prostřednictvím rozhraní Responses API.

Těšíme se, co vývojáři s touto sadou základních prvků vytvoří. Jazykové modely mají dělat víc než jen generovat text, obrázky a zvuk – naši platformu budeme i nadále vyvíjet, aby byla schopnější zvládat složité úkoly z reálného světa ve velkém měřítku.