Mas angkop sa mga bukas na gawain ang mas magaang mga harness at mga agent na nagpapatakbo ng code, dahil maaaring limitahan ng sobrang higpit na orkestrasyon ang pagganap ng modelo.
Dahil dito, pangunahing usaping pang-arkitektura na ngayon para sa mga agentic system ang pagpapatakbo ng code at sandboxing.
Binabawasan ng Agents SDK ang pagiging kumplikado at dami ng code na kailangan sa paggawa ng mga agent na nagpapatakbo ng code—hanggang 6x sa aming mga pagsubok.
Sa loob ng mahabang panahon, nagmula ang pag-unlad sa mga agent system sa pagpapahusay ng orkestrasyon: mas mahusay na prompting, mga interface ng tool, pamamahala ng konteksto, at mas mahigpit na control flow. Ngunit habang humuhusay ang mga coding agent, nagsisimula nang magbago ang balanseng iyon.
Sa maraming bukas na workflow, hindi na ang agent loop mismo ang bottleneck kundi ang layer ng pagpapatakbo: ang sandbox kung saan nagsusulat ng code ang modelo, nagpapatakbo ng mga command, sumusuri ng mga output, at paulit-ulit na nagpapahusay. Habang mas maraming pangangatwiran sa antas ng gawain ang inililipat sa environment na iyon, kailangang gawing mas simple ang nakapaligid na orkestrasyon upang lubos na maipamalas ng modelo ang kakayahan nito.
Ang pagbabagong iyon mismo ang binibigyang-daan ng bagong bersyon ng Agents SDK. Sa aming pagsubok noong early access, nalaman naming sa halip na magdagdag ng isa pang layer ng framework logic, ginagawa nitong mas modular at madaling pagsama-samahin ang layer ng pagpapatakbo upang manatiling magaang ang natitirang bahagi ng system.
Nagiging uso sa harness engineering ang pagpapasimple sa harness hanggang sa pinakamaliit ngunit epektibong anyo nito. Sa pangkalahatan, ang harness ang software sa paligid ng modelo: ang layer na namamahala sa konteksto, mga tool, control flow, at mga feedback loop upang mapagkakatiwalaang makagawa ang modelo.
Sa nakalipas na ilang taon, maraming paghusay sa pagganap ng agent ang nagmula sa pagpapatibay sa layer na iyon. Madalas na mas pinahusay at ginawang mas maaasahan ng mas mahuhusay na tool, memory at retrieval, mas malinaw na paghahati-hati ng gawain, at mas mahigpit na orkestrasyon ang mga system. Sa paradigmang iyon, pangunahing nangangahulugan ang pag-unlad ng paglalagay ng higit pang task logic sa software sa paligid ng modelo.
Humihina na ngayon ang pattern na iyon, kahit man lang para sa isang uri ng bukas na gawain. Ipinahihiwatig ng dumaraming proyekto at papel na hindi laging gumaganda ang pagganap kapag nagiging mas mapag-atas ang harness. Sa assisted coding, mga matagalang gawain, paggamit ng browser, at mga gawaing may mahabang konteksto, paulit-ulit na lumilitaw ang parehong pattern: kapag sapat na ang talino ng modelo, maaaring maging hadlang sa halip na bentahe ang sapilitang paglalagay ng napakaraming istruktura ng gawain sa nakapaligid na software.
Samakatuwid, nagbabago ang papel ng harness. Sa halip na hulaan nang maaga ang gawain sa pamamagitan ng mahigpit na orkestrasyon, lalo nang nagsisilbi ang harness bilang malinis na execution surface: isang sandbox kung saan maaaring suriin ng modelo ang estado, magpatakbo ng code, makabawi sa mga error, at iangkop ang sarili nitong diskarte habang nananatili sa mga hangganan ng mga interface at pananggalang ng system. Malapit ito sa pagbabagong inilarawan ni Andrej Karpathy sa Software Engineer 3.0: ang ilan sa logic na dating nasa software ay umaakyat patungo sa “prompt.”
Hindi nangangahulugan ang aral na dapat alisin ng mga agent system ang istruktura sa lahat ng lugar. Maraming gawain ang nakikinabang pa rin sa malinaw na mga workflow, heuristic, at tiyak na guardrail, lalo na kapag makitid ang saklaw, napakarami, o may malinaw na pamantayan ng tagumpay ang gawain. Gaya ng ipinunto namin sa nauna naming post tungkol sa Mga Heuristic para sa Disenyo ng Agentic System, mahalaga pa rin ang matatag na orkestrasyon kapag parehong posible at kanais-nais ang maaasahang daloy ng logic.
Nagbabago ang pokus para sa mga bukas na gawain. Ang hamon ay hindi na gaanong tungkol sa pagdidisenyo ng mas masalimuot na layer ng orkestrasyon, kundi sa pagbuo ng mga environment sa pagpapatakbo na sapat na simple, naoobserbahan, at modular upang epektibong makagawa ang modelo sa loob ng mga ito.
Kapag nakakabasa na ng mga file, nakasusulat ng code, nakapagpapatakbo ng mga shell command, at nakapagsisimula ng matagalang gawain ang isang agent, nagbabago ang hamon sa engineering. Hindi na prompt optimization o tool routing lamang ang mahirap na bahagi. Dahil gumagana na ngayon ang agent sa isang tunay na system, higit na mas makapangyarihan ang mga agent na ito. Gayunman, mas sensitibo rin ang mga ito dahil lumalaki ang saklaw ng mga panganib sa kaligtasan at seguridad. Halimbawa, maaaring gumawa ng mapaminsalang aksyon ang isang agent na nakapagpapatakbo ng code kung hindi maayos ang isolation ng environment nito (tingnan ang Sandbox Bench ng AISI).
Kaya nagiging kritikal na usapin ang sandboxing sa mga agent framework. Sa mga naunang system, madalas ituring na karagdagang bahagi ang pagpapatakbo: isang tool na ikinabit lamang sa harness. Ngunit kapag nagkaroon na ng state, naging matagal, o naging remote ang pagpapatakbo, nagsisimulang pumalya ang diskarteng iyon. Ang pamamahala sa sandbox mismo—sa lifecycle, state, mga interface, at pagkakaugnay nito sa agent loop—ay mabilis na nagiging hiwalay na problema sa pagdidisenyo ng system. Isa ito sa mga dahilan kung bakit dumarami ang mga provider na nag-aalok ngayon ng mga pinamamahalaang environment para sa pagpapatakbo ng code, kabilang ang Container API at shell tool ng OpenAI, Modal, Cloudflare, Daytona, E2B, at iba pa.
Mahalaga ang hangganang ito dahil nangangailangan ang pagpapatakbo ng code ng mas matibay na isolation at mas mahigpit na runtime control kaysa sa natitirang bahagi ng harness. Sa aktuwal na paggamit, maaaring magdulot ang mga agent na nagpapatakbo ng code ngunit hindi maayos ang implementasyon ng tatlong panganib na kritikal sa negosyo: hindi makontrol na gastos sa compute, mapaminsalang aksyon sa mga internal system, at pagkalantad ng sensitibong impormasyon. Sa wastong containerisation, isolation, at mga runtime safeguard, maaaring mapigil ang mga panganib na ito sa antas na katanggap-tanggap para sa aktuwal na deployment.
Isang paraan upang maunawaan ito ang pag-iisip na binibigyan ang agent ng sarili nitong selyadong workspace sa halip na mga susi sa buong opisina. Makagagawa pa rin ito ng kapaki-pakinabang na gawain sa loob ng espasyong iyon, ngunit sa malinaw na itinakdang mga hangganan lamang. Maaari mong limitahan ang compute na ginagamit nito, ang mga system at file na maa-access nito, at ang impormasyong maaaring makuha nito sa simula pa lamang.
Hindi nito ganap na inaalis ang panganib, ngunit binabago nito ang problema mula sa “isang agent na malayang gumagala sa iyong imprastraktura” tungo sa “isang agent na gumagana sa loob ng kontroladong environment.” Kung magiging karaniwang bahagi ng mga agent system ang layer na ito, kailangan itong direktang suportahan ng framework. Dahil dito, nagiging modular na layer ng pagpapatakbo ang sandbox, na may mga portable primitive na mabilis na magagamit ng mga developer, maililipat sa iba’t ibang provider, at mai-scale nang hindi laging binabago ang agent logic.
Kapag nagpapatakbo na ng code ang isang agent, kailangan ding iorkestra ang sandbox mismo. Lubhang pinabibigat ng paglipat mula sa lokal na proof of concept tungo sa remote execution, maraming backend, o matagalang session ang mga operasyonal na gawain. Kailangan mo ng pare-parehong paraan upang gumawa at huminto ng mga environment, i-pause at ipagpatuloy ang mga ito, kumuha ng snapshot ng state, muling kumonekta sa ibang pagkakataon, at pamahalaan ang lahat ng ito sa iba’t ibang provider.
Hindi man kapana-panabik sa konsepto ang alinman dito, mahalaga naman ang mga ito sa aktuwal na paggamit. Ito mismo ang uri ng imprastrakturang nagiging mahirap kapag muling binubuo ng bawat team mula sa simula ang isang agentic pipeline, lalo na kung hindi ito nakapaloob sa agent framework…
Dito nagiging mahalaga ang mas mahusay na suporta ng framework. Nagkaroon kami ng early access sa mas bagong OpenAI Agents SDK at ginamit namin ito upang kami mismo ang bumuo ng mga sandboxed agent. Ang kapansin-pansin ay ang pagbabago sa arkitektural na pokus: itinuturing ng SDK ang pagpapatakbo bilang pangunahing layer sa halip na pandagdag na tool lamang. Sa aktuwal na paggamit, nangangahulugan itong maaari kang magsimula ng sandboxed agent, kumuha ng snapshot ng sandbox, o ipagpatuloy ang pagpapatakbo gamit ang mas kaunting code (~6 na beses sa ilan sa aming mga pagsubok), at pagkatapos ay magpalit ng backend nang hindi muling isinusulat ang nakapaligid na agent logic.
Dahil sa mas malinaw na paghihiwalay na ito ng mga responsibilidad, makapagtutuon ang harness sa pangangatwiran, konteksto, at workflow. Makapagtutuon naman ang layer ng pagpapatakbo sa isolation, portability, at runtime state. Pinadadali ng abstraction na ito ang pagbuo ng mga coding agent na mas may kakayahan at mas madaling paunlarin—mga agent na maaaring lumipat sa pagitan ng lokal at remote na pagpapatakbo, sumuporta sa mas matagal na gawain, at magpalit ng execution backend nang hindi kailangang muling idisenyo ang buong system.
Habang mas maraming task-level logic ang lumilipat mula sa harness patungo sa modelo, sumasama rito ang ilan sa pagiging kumplikado ng system—pababa sa layer ng pagpapatakbo. Pangunahing usaping pang-arkitektura na ngayon para sa mga agentic system ang pagpapatakbo ng code at sandboxing, lalo na sa mga gawaing maraming coding at bukas ang saklaw. Kasinghalaga na ngayon ng pagdidisenyo ng agentic pipeline ang pagdidisenyo ng environment kung saan ligtas, maaasahan, at tuloy-tuloy na makakakilos ang agent.
Ito ang dahilan kung bakit mahalaga ang mga higher-level abstraction para sa sandboxed execution. Sumusulong sa direksiyong iyon ang mas bagong OpenAI Agents SDK sa pamamagitan ng pagtrato sa pagpapatakbo bilang modular na layer ng system: portable sa iba’t ibang backend, may state sa kabuuan ng matagalang gawain, at sapat na simpleng gamitin nang hindi muling binubuo ang parehong imprastraktura para sa bawat bagong setup.
Ang mas malawak na aral ay malamang na hindi ibabatay ang susunod na henerasyon ng mga agent framework sa dami ng idinaragdag nilang orchestration logic, kundi sa husay ng pagkakaayos nila sa mga environment ng pagpapatakbo na lalo nang inaasahan ng mga agent.