OpenAI Agents SDK apo Google ADK: ku ekzekutohet agjenti

Për një agjent që duhet të ruajë gjendje, të përdorë mjete dhe të vendoset në infrastrukturë të kontrolluar, vendimi i parë është ku do të ekzekutohet dhe kush do ta ruajë sesionin. Me OpenAI Agents SDK, aplikacioni thërret Runner dhe mund t’i japë një Session; dokumentacioni i sesioneve të OpenAI shpjegon se Runner e merr historikun para ekzekutimit dhe i ruan elementet e reja pas tij. Ekipi zgjedh magazinën e historikut dhe e lidh atë me shërbimin e vet.

Google ADK e organizon ekzekutimin rreth Runner, SessionService, Events dhe State. Përshkrimi teknik i ADK dallon historikun e ngjarjeve nga gjendja e punës brenda sesionit dhe përfshin mjete e rrjedha me agjentë të specializuar. Kjo strukturë ka peshë kur agjenti duhet të ndahet në hapa të qartë; vendi ku ekzekutohet kodi dhe shërbimi që mban gjendjen përcaktojnë çfarë duhet të operojë vetë ekipi.

I njëjti agjent në dy skema

Merrni një shembull hipotetik: një agjent merr kërkesën e klientit, kërkon të dhëna përmes një mjeti, mban statusin e çështjes dhe kërkon miratim para se të ndryshojë një regjistrim. Kërkesa dhe veprimi i lejuar janë të njëjtë në të dyja skemat. Ndryshon lidhja mes procesit që ekzekuton agjentin, ruajtjes së gjendjes dhe pikës ku ndalet veprimi për miratim.

Me OpenAI Agents SDK, shërbimi i aplikacionit pranon kërkesën, gjen identifikuesin e sesionit dhe thërret Runner. Agjenti përdor një funksion të aplikacionit për kërkimin; sesioni ruan historikun që i duhet ekzekutimit pasues. Nëse një specialist duhet të marrë drejtimin e bisedës, përdoret handoff. Nëse specialisti duhet të kryejë vetëm një detyrë të kufizuar, agjenti kryesor mund ta thërrasë si mjet dhe të mbajë përgjegjësinë për përgjigjen përfundimtare.

Me ADK, Runner ekzekuton agjentin duke bashkëpunuar me SessionService, ndërsa State mban vlerat e punës së atij sesioni. Kërkimi mund të përfaqësohet si FunctionTool; një specialist mund të thirret si AgentTool ose të marrë kontrollin përmes transferimit mes agjentëve. ADK ka edhe SequentialAgent dhe ParallelAgent për hapa me rend të përcaktuar ose punë paralele. Këto pjesë e bëjnë të dukshme në arkitekturë se ku zhvillohet secila detyrë, por nuk e zgjedhin vetë magazinën e përshtatshme për prodhim.

Çfarë duhet të mbetet në sesion?

Te OpenAI Agents SDK, Session mban historikun e bisedës, përfshirë thirrjet e mjeteve. Zgjedhjet e dokumentuara për ruajtje përfshijnë SQLite, Redis, SQLAlchemy dhe një variant ku historiku mbahet përmes OpenAI Conversations API. Për shembullin hipotetik, identifikuesi i sesionit duhet të rikthejë bisedën e duhur kur klienti kthehet, ndërsa zgjidhja e magazinës varet nga mënyra si shpërndahet aplikacioni.

Një sesion SQLite vetëm në memorie humbet kur përfundon procesi; një magazinë e përbashkët u jep proceseve të ndryshme qasje te i njëjti historik. Kjo ka rëndësi nëse shërbimi riniset ose kërkesat e një klienti kalojnë te instanca të ndryshme. Statusi i çështjes në shembull mund të jetë gjithashtu e dhënë biznesi që aplikacioni duhet ta ruajë sipas rregullave të veta, jo vetëm si fjali në historikun që i dërgohet modelit.

ADK e dallon Session, që përfshin historikun e Events, nga State, ku mbahen vlerat e punës për atë sesion. Memory është mekanizëm tjetër për informacion që mund të kërkohet përtej një sesioni. Në shembull, përgjigjja e mëparshme e agjentit i përket historikut; statusi që ndryshon gjatë trajtimit të kërkesës mund të mbahet në State. Nëse statusi është regjistrim zyrtar i klientit, aplikacioni duhet ta përditësojë edhe në sistemin përkatës të të dhënave.

Mjetet, miratimi dhe specialistët

Në të dyja kornizat, një funksion i aplikacionit mund t’i jepet agjentit si mjet. Për kërkimin e të dhënave, kjo lidh modelin me një burim informacioni; për ndryshimin e një regjistrimi, i jep mundësi të shkaktojë një veprim me pasoja. Prandaj aplikacioni duhet të përcaktojë cilat të dhëna mund të lexohen, cilat ndryshime lejohen dhe si lidhet veprimi me përdoruesin që e ka kërkuar. Kalimi te një specialist ndryshon rrjedhën e punës, por nuk zëvendëson këto kontrolle te mjeti.

OpenAI Agents SDK mund ta ndërpresë ekzekutimin për miratim dhe ta rifillojë me të njëjtin sesion pasi kërkesa të pranohet ose të refuzohet. Te ADK, konfirmimi i veprimeve të mjeteve mund të marrë përgjigje nga një njeri ose sistem mbikëqyrës, por funksioni shënohet si eksperimental dhe nuk mbështet DatabaseSessionService ose VertexAiSessionService. Nëse agjenti i shembullit kërkon njëkohësisht miratim dhe njërin prej këtyre shërbimeve të sesionit, ekipi duhet të projektojë një rrjedhë tjetër për atë kombinim.

Vendimi mes handoff-it dhe thirrjes së specialistit si mjet lidhet me pronësinë e përgjigjes. Nëse specialisti merr bisedën dhe e çon deri në përgjigje, transferimi është i natyrshëm. Nëse agjenti kryesor duhet të mbledhë rezultatin e kërkimit, të kërkojë miratimin dhe të japë përgjigjen përfundimtare, delegimi i një detyre të kufizuar e mban atë në kontroll. Ky dallim është më i rëndësishëm për rrjedhën e klientit sesa numri i agjentëve të përfshirë.

Ku vendoset agjenti dhe nga cili cloud varet?

OpenAI Agents SDK është bibliotekë që ekzekutohet në procesin e aplikacionit që e thërret. Kështu, ekipi mund ta vendosë atë proces dhe magazinën e sesionit në infrastrukturën që përdor tashmë. Kjo zgjedhje i lë ekipit përgjegjësinë për vendosjen, shkallëzimin dhe funksionimin e tyre. Ajo duhet dalluar nga vendi ku kryhet inferenca e modelit: përdorimi i një API-je të jashtme sjell varësi nga ofruesi i asaj API-je.

ADK nuk e kufizon vendosjen te një shërbim i vetëm. Udhëzimi i vendosjes së ADK përfshin Agent Runtime, Cloud Run, Google Kubernetes Engine dhe një imazh kontejneri që mund të ekzekutohet në infrastrukturë tjetër. Agent Runtime merr përsipër një pjesë të operimit si shërbim i menaxhuar; me një kontejner të ekzekutuar nga vetë ekipi, ruajtja, shpërndarja dhe monitorimi mbeten detyra të tij. Ekzekutimi i kontejnerit jashtë Google Cloud është i mundshëm, por nuk e bën automatikisht lokale inferencën e modelit të zgjedhur.

Prandaj krahasimi i modeleve vjen pas dy pyetjeve arkitekturore: ku ekzekutohet procesi i agjentit dhe ku mbahet gjendja që duhet të mbijetojë pas një kërkese. Më pas mund të vlerësohet nëse modeli i zgjedhur i përmbush kërkesat për cilësi, vonesë dhe kosto në atë rrjedhë. Një model i përshtatshëm nuk e zgjidh vetë vazhdimësinë e sesionit ose miratimin e ndryshimeve në të dhënat e klientit.

Çfarë matin kostot e ADK Arena?

Studimi ADK Arena vlerësoi 51 korniza Python në 204 çifte agjent–benchmark dhe raportoi se kostoja e gjenerimit të agjentit ndryshonte 5,6 herë mes kornizave, nga 0,6 në 3,4 dollarë për agjent. Autorët përdorën të njëjtin zhvillues të bazuar në model gjuhësor dhe ndryshuan kornizën, ndaj kjo kosto shërben si tregues i përpjekjes së gjenerimit sipas metodës së studimit. Ata gjetën gjithashtu se asnjë kornizë nuk dominoi të gjitha benchmark-et.

Këto vlera matin ndërtimin e agjentëve në kushtet e eksperimentit, jo faturën e operimit, mirëmbajtjes apo thirrjeve të modelit për një shërbim në prodhim. Ato nuk shpallin fitues për agjentin hipotetik të kërkesave të klientëve: detyrat e benchmark-ut dhe kufijtë e atij aplikacioni janë të ndryshëm. Për këtë zgjedhje, kërkesa për sesion të qëndrueshëm, mënyra e miratimit dhe përgjegjësia për vendosjen përcaktojnë arkitekturën; matjet e Arena tregojnë se edhe korniza mund të ndikojë në përpjekjen për ta ndërtuar atë.

Lexoni gjithashtu: