Jednodušší harnessy a agenti spouštějící kód se lépe hodí pro otevřené úlohy, u nichž může příliš rigidní orchestrace omezovat výkon modelu.
Spouštění kódu a sandboxing se proto stávají klíčovými architektonickými aspekty agentních systémů.
Agents SDK snižuje složitost i množství kódu potřebného k vytváření agentů spouštějících kód – v našich testech až šestkrát.
Pokrok v agentních systémech dlouho spočíval ve zdokonalování orchestrace: lepších promptech, rozhraních nástrojů, správě kontextu a přesnějším řízení toku. S rostoucími schopnostmi programovacích agentů se však tato rovnováha začíná měnit.
V mnoha otevřených pracovních postupech už není úzkým hrdlem samotná smyčka agenta, ale prováděcí vrstva: sandbox, ve kterém model píše kód, spouští příkazy, kontroluje výstupy a postup opakuje. S tím, jak se do tohoto prostředí přesouvá více uvažování na úrovni úloh, musí se okolní orchestrace zjednodušit, aby mohl model naplno využít své schopnosti.
Právě tento posun umožňuje nová verze Agents SDK. Při testování v rámci předběžného přístupu jsme zjistili, že namísto přidávání další vrstvy logiky frameworku činí prováděcí vrstvu modulárnější a lépe kombinovatelnou, takže zbytek systému může zůstat jednoduchý.
V návrhu harnessů se prosazuje trend omezit harness na jeho nejjednodušší účinnou podobu. Obecně řečeno je harness software obklopující model: vrstva, která spravuje kontext, nástroje, tok řízení a zpětnovazební smyčky, aby mohl model spolehlivě pracovat.
V posledních několika letech přineslo mnoho zlepšení výkonu agentů právě posilování této vrstvy. Lepší nástroje, paměť a vyhledávání, explicitnější rozklad úloh a přesnější orchestrace často zvyšovaly spolehlivost i schopnosti systémů. V tomto paradigmatu znamenal pokrok především zakódování větší části logiky úloh do softwaru obklopujícího model.
Tento přístup nyní ztrácí na významu, alespoň u určité skupiny otevřených úloh. Rostoucí počet projektů a odborných prací naznačuje, že přísnější pravidla v harnessu nevedou vždy k lepšímu výkonu. U asistovaného programování, dlouhotrvajících úloh, používání prohlížeče a úloh s dlouhým kontextem se opakuje stejný vzorec: jakmile je model dostatečně inteligentní, příliš mnoho struktury úlohy v okolním softwaru se může stát spíše omezením než výhodou.
Úloha harnessu se proto mění. Namísto snahy předvídat úlohu pomocí rigidní orchestrace poskytuje harness stále častěji čisté prováděcí prostředí: sandbox, v němž může model kontrolovat stav, spouštět kód, zotavovat se z chyb a přizpůsobovat vlastní postup, přičemž zůstává omezen rozhraními a bezpečnostními opatřeními systému. Tento vývoj se blíží posunu, který Andrej Karpathy popsal v přednášce Softwarový inženýr 3.0: část logiky, jež dříve sídlila v softwaru, se přesouvá výše do „promptu“.
Neznamená to, že by agentní systémy měly odstranit veškerou strukturu. Mnoha úlohám stále prospívají explicitní pracovní postupy, heuristiky a deterministická ochranná pravidla, zejména pokud jsou úzce vymezené, zpracovávají se ve velkém nebo mají jasné kritérium úspěchu. Jak jsme uvedli v předchozím článku Heuristiky návrhu agentních systémů, důkladná orchestrace zůstává důležitá tam, kde je spolehlivý tok logiky možný i žádoucí.
U otevřených úloh se však pozornost přesouvá jinam. Hlavní výzvou už není navrhovat stále propracovanější vrstvy orchestrace, ale vytvářet prováděcí prostředí, která jsou dostatečně jednoduchá, pozorovatelná a modulární, aby v nich mohl model efektivně pracovat.
Jakmile agent dokáže číst soubory, psát kód, spouštět příkazy shellu a zahajovat dlouhotrvající úlohy, mění se i technické výzvy. Nejobtížnější už není pouze optimalizace promptu nebo směrování nástrojů. Díky práci se skutečným systémem jsou tito agenti výrazně výkonnější, ale také citlivější, protože rozšiřují prostor bezpečnostních rizik. Agent schopný spouštět kód může například provést škodlivé akce, pokud jeho prostředí není dobře izolované (viz Sandbox Bench od AISI).
Sandboxing se proto stává zásadním tématem agentních frameworků. V dřívějších systémech se spouštění často považovalo za doplněk: nástroj dodatečně připojený k harnessu. Jakmile však spouštění začne pracovat se stavem, trvá dlouho nebo probíhá vzdáleně, tento přístup přestává fungovat. Správa samotného sandboxu, jeho životního cyklu, stavu, rozhraní a napojení na smyčku agenta se rychle stává samostatným problémem návrhu systému. To je jeden z důvodů, proč stále více poskytovatelů nabízí spravovaná prostředí pro spouštění kódu, například Container API a nástroj shell od OpenAI, Modal, Cloudflare, Daytona či E2B.
Tato hranice je důležitá, protože spouštění kódu vyžaduje silnější izolaci a přísnější řízení běhového prostředí než zbytek harnessu. Špatně implementovaní agenti spouštějící kód mohou v praxi přinést tři zásadní obchodní rizika: nekontrolované výdaje za výpočetní prostředky, destruktivní zásahy do interních systémů a únik citlivých informací. Správná kontejnerizace, izolace a ochranná opatření běhového prostředí mohou tato rizika omezit na úroveň přijatelnou pro reálné nasazení.
Lze si to představit tak, že agentovi dáte vlastní uzavřený pracovní prostor namísto klíčů od celé kanceláře. Uvnitř může stále odvádět užitečnou práci, ale pouze v jasně vymezených mezích. Můžete omezit množství využitých výpočetních prostředků, určit, ke kterým systémům a souborům smí přistupovat, a řídit, jaké informace má vůbec k dispozici.
Riziko tím zcela nezmizí, ale problém se změní z „agenta volně působícího ve vaší infrastruktuře“ na „agenta pracujícího v řízeném prostředí“. Má-li se tato vrstva stát běžnou součástí agentních systémů, musí mít nativní podporu přímo ve frameworku. Sandbox se tak stává modulární prováděcí vrstvou s přenositelnými stavebními prvky, které mohou vývojáři rychle nasadit, měnit mezi poskytovateli a škálovat bez neustálého přepracovávání logiky agenta.
Jakmile agent spouští kód, potřebuje orchestraci i samotný sandbox. Přechod z lokálního ověření konceptu ke vzdálenému spouštění, několika backendům nebo dlouhotrvajícím relacím exponenciálně zvyšuje provozní zátěž. Potřebujete jednotný způsob vytváření a zastavování prostředí, jejich pozastavení a obnovení, pořizování snímků stavu, pozdějšího opětovného připojení a správy všech těchto funkcí u různých poskytovatelů.
Nic z toho nepůsobí koncepčně oslnivě, ale v praxi je to důležité. Právě tento druh infrastruktury působí potíže, když každý tým znovu vytváří agentní pipeline od nuly, zvlášť pokud není integrovaná do agentního frameworku…
Zde začíná být důležitá lepší podpora frameworku. Získali jsme předběžný přístup k novější verzi OpenAI Agents SDK a sami jsme s ní vytvořili agenty v sandboxu. Nejvýraznější byl posun v architektonických prioritách: SDK považuje spouštění za plnohodnotnou vrstvu, nikoli za okrajový nástroj. V praxi to znamená, že můžete spustit agenta v sandboxu, pořídit snímek sandboxu nebo obnovit běh s menším množstvím kódu – v některých našich testech přibližně šestkrát menším – a poté změnit backend bez přepisování okolní logiky agenta.
Toto čistší oddělení odpovědností umožňuje harnessu soustředit se na uvažování, kontext a pracovní postup. Prováděcí vrstva se může zaměřit na izolaci, přenositelnost a stav běhového prostředí. Tato abstrakce usnadňuje vytváření programovacích agentů, kteří mají větší schopnosti a lze je snadněji rozvíjet, přecházejí mezi lokálním a vzdáleným spouštěním, podporují dlouhotrvající úlohy a umožňují měnit prováděcí backendy bez nutnosti přepracovat celý systém.
S tím, jak se více logiky na úrovni úloh přesouvá z harnessu do modelu, přesouvá se s ní část složitosti systému – níže do prováděcí vrstvy. Spouštění kódu a sandboxing jsou nyní klíčovými architektonickými aspekty agentních systémů, zejména u otevřených úloh a úloh náročných na programování. Návrh prostředí, v němž může agent bezpečně, spolehlivě a dlouhodobě pracovat, je nyní stejně důležitý jako návrh agentní pipeline.
Proto jsou důležité vysokoúrovňové abstrakce pro spouštění v sandboxu. Novější OpenAI Agents SDK se vydává tímto směrem a chápe spouštění jako modulární vrstvu systému: přenositelnou mezi backendy, zachovávající stav během dlouhotrvajících úloh a dostatečně jednoduchou na použití bez opakovaného budování stejné infrastruktury pro každou novou konfiguraci.
Obecnějším závěrem je, že příští generaci agentních frameworků bude pravděpodobně určovat méně množství přidané orchestrační logiky a více kvalita struktury prováděcích prostředí, na nichž jsou agenti stále závislejší.