Vodič za razvojne programere za višeagentne obrasce s ADK-om

Zadnje ažuriranje: 12/24/2025
  • Višeagentni sustavi u ADK-u zamjenjuju monolitne prompte modularnim, surađujućim agentima.
  • Agenti tijeka rada (sekvencijalni, petlja, paralelni) orkestriraju LLM i prilagođene agente putem dijeljenog stanja sesije.
  • Google Cloud pruža referentnu arhitekturu, sigurnosni i nadzorni paket za implementaciju ADK MAS-a.
  • Uzorci poput koordinatora, cjevovoda, raspodele/skupljanja i iterativnog poboljšanja prirodno se pojavljuju iz ADK primitiva.

vodič za višeagentne oglase

Agentske aplikacije brzo prerastaju klasični obrazac "jednog mega-prompta", a programerima je potreban solidan mentalni model za strukturiranje više agenata bez upadanja u kaos. Googleov Agent Development Kit (ADK) dizajniran je upravo za to: omogućuje vam sastavljanje pouzdanih višeagentskih sustava, povezivanje alata i memorije te implementaciju svega na Google Cloudu s vidljivošću, sigurnošću i kontrolom troškova na produkcijskoj razini.

Ovaj vodič vas vodi kroz glavne obrasce više agenata koje podržava ADK – od jednostavnih hijerarhija roditelj/dijete do sekvencijalnih, petlji i paralelnih agenata za tijek rada – i pokazuje kako se oni uklapaju u širu referentnu arhitekturu na Google Cloudu. Također ćemo obraditi stanje dijeljene sesije, mehanizme delegiranja, uobičajene nacrte za više agenata i praktične aspekte implementacije, osiguranja i rada tih sustava u stvarnim okruženjima.

Zašto višeagentni sustavi u ADK-u?

Kada aplikaciju pokreće jedan, monolitni prompt agenta, brzo postaje teško o njoj razmišljati, testirati je i razvijati. Ogromni upiti su krhki, teško ih je otkloniti i teško ih je održavati kako zahtjevi rastu. ADK vas potiče na izgradnju Višeagentni sustav (MAS) gdje svaki agent ima usmjerenu odgovornost, a orkestracija je eksplicitna.

Strukturiranje vaše aplikacije kao nekoliko surađujućih agenata donosi modularnost, specijalizaciju i mogućnost ponovne upotrebe. Možete imati istraživačkog agenta, kritičara, program za pisanje datoteka, usmjerivač, agenta za pristup podacima i ponovno ih koristiti u različitim projektima ili tijekovima rada umjesto ponovnog ugrađivanja iste logike u jedan jumbo prompt.

ADK vam pruža konkretne gradivne blokove za ostvarenje ovoga: agente usmjerene na LLM, agente tijeka rada (sekvencijalne, paralelne, petlje) i prilagođene agente koji obuhvaćaju logiku koja nije LLM. Svi nasljeđuju od zajedničkog BaseAgent, pa se uključuju u isti model orkestracije, bilježenja, rukovanja stanjem i sustav alata.

Kako sustavi rastu, ovaj model kompozicije se bolje skalira od ad-hoc orkestracionog koda ili duboko ugniježđenih lanaca poziva funkcija oko jednog modela. Kognitivno opterećenje održavate upravljivim: svaki agent ima jasan mandat i dobro definiranu površinu interakcije s drugima.

ADK primitivi za sastavljanje agenata

ADK nudi mali skup primitiva koje možete kombinirati za izražavanje iznenađujuće bogatih višeagentskih arhitektura. Razumijevanje ovih temeljnih koncepata znatno olakšava kasnije razmišljanje o obrascima više razine.

Prva primitiva je hijerarhija agenata: svaki agent može deklarirati popis sub_agents, formirajući stablo s jednim root_agent na vrhu. Kada predate djecu u sub_agents, ADK automatski povezuje svoje parent_agent referenca i nameće da dana instanca ima samo jednog roditelja (inače ValueError je podignut).

Ova hijerarhija je više od dekora: ona definira kojim agentima je dopušteno delegirati čemu, i to je opseg koji koriste agenti tijeka rada i prijenos vođen LLM-om. Iz bilo kojeg agenta možete se kretati prema gore putem agent.parent_agent ili pronaći potomke s agent.find_agent(name), što je izuzetno praktično za otklanjanje pogrešaka.

Uz osnovne LLM agente, ADK uvodi namjenske agente za tijek rada – SequentialAgent, ParallelAgent i LoopAgent – čiji posao nije „misliti“ već orkestrirati podagente. Svi dijele isto sučelje, ali implementiraju različite strategije izvršavanja: izvršavaju se redom, paralelno se šire ili iteriraju u petlji s eksplicitnim pravilima završetka.

Treći bitni primitiv je komunikacijski sloj, usredotočen na dijeljeni Session i njegova state rječnik. Stanje sesije ponaša se poput obične bijele ploče: bilo koji agent ili alat može pisati međurezultate ili zastavice, a drugi agenti u istom pozivu mogu ih čitati, često putem predloška ključeva unutar svojih instrukcija (na primjer {PLOT_OUTLINE?}).

Kako agenti međusobno komuniciraju u ADK-u

ADK podržava tri komplementarna načina komunikacije između agenata: dijeljeno stanje sesije, prijenos vođen LLM-om i eksplicitno pozivanje putem AgentTool. Odabir pravog za svaku interakciju održava vaš sustav i ekspresivnim i predvidljivim.

Stanje dijeljene sesije (session.state) je najjednostavniji i najrašireniji mehanizam. Unutar jednog poziva, svi agenti vide isti Session objekt putem InvocationContextAlat ili povratni poziv mogu učiniti context.state = value, a kasniji agent ga može dohvatiti pomoću context.state.get("data_key")Za LLM agente, postavljanje output_key automatski pohranjuje svoj konačni odgovor pod tim ključem.

Delegiranje vođeno LLM-om, ponekad nazvano "prijenos agenta", omogućuje LLM-u da odluči kada će predati zadatak drugom agentu na temelju uputa i opisa agenata. Interno, model izdaje poseban poziv funkcije kao što je transfer_to_agent(agent_name="screenwriter")ADK-ovi AutoFlow presreće ovaj poziv i preusmjerava izvršenje odabranom agentu unutar dopuštenog opsega (roditelj, djeca, braća i sestre, ovisno o konfiguraciji).

Eksplicitno pozivanje s AgentTool pruža vam kontroliraniji, funkcijski sličniji način pozivanja jednog agenta od drugog. Omotavate instancu ciljnog agenta u AgentTool, dodajte ga pozivatelju tools popis, a LLM tada može odabrati taj alat kao i bilo koju drugu funkciju. Kada se pozove, AgentTool.run_async izvršava podagent, spaja stanje i artefakte natrag i vraća odgovor podagenta kao rezultat alata.

Ova tri kanala pokrivaju većinu potreba više agenata: asinkroni prijenos podataka putem stanja, fleksibilno usmjeravanje putem prijenosa i uski sinkroni pozivi putem alata. U složenijim dizajnima, često ih miješate unutar jednog stabla: usmjerivač koji prenosi podatke djeci, specijaliste koji koriste stanje za komunikaciju i jednog ili dva agenta dostupna kao alati za ad-hoc delegiranje.

Gradivni blokovi: LLM agenti, agenti tijeka rada i prilagođeni agenti

Većina MAS topologija u ADK-u su kombinacije triju vrsta agenata: agenata temeljenih na LLM-u, agenata temeljenih na tijeku rada i prilagođenih agenata. Svaka kategorija rješava drugačiji dio problema orkestracije.

LLM agenti omataju veliki jezični model i opcionalne alate, povratne pozive i usmjeravanje izlaza u BaseAgent. Zamislite ih kao svoje „komponente za razmišljanje“: one interpretiraju korisnički unos, pozivaju alate, ažuriraju stanje i ili odgovaraju korisniku ili prenose zadatak drugom agentu.

Agenti tijeka rada djeluju kao upravitelji, a ne kao radnici: oni sami ne razmišljaju, ali kontroliraju redoslijed, paralelizam i ponavljanje izvršavanja podagenta. SequentialAgent pokreće svoju djecu jedno za drugim dok dijele iste InvocationContext, ParallelAgent šire se preko više grana koje dijele stanje, ali imaju različite grane povijesti i LoopAgent izvršava niz više puta dok se ne ispuni uvjet zaustavljanja.

Prilagođeni agenti se produžuju BaseAgent s proizvoljnom logikom koja nije LLM kada ugrađene strategije orkestracije nisu dovoljne. Na primjer, možete implementirati prilagođeni planer koji uvjetno izvršava agente na temelju metrike ili integrirati mehanizam poslovnih pravila koji određuje koji podtok će se pokrenuti ovisno o regulatornim ograničenjima.

Ova mješavina generičkih orkestracijskih primitiva i priključne logike čini ADK prikladnim za ozbiljna poslovna opterećenja, ne samo za demo verzije. Možete početi sa standardnim agentima za tijek rada, a tek kada zahtjevi postanu egzotični, posežete za njima. CustomAgent.

Stanje sesije i obrasci memorije

Stanje sesije u ADK-u podupire i kratkoročnu konverzacijsku memoriju i strukturirane podatke koji se prenose između agenata. Svaki razgovor koristi Session objekt koji sadrži povijest poruka i promjenjivu vrijednost state rječnik dostupan svim agentima u tom pozivu.

Pisanje u stanje se obično vrši unutar alata ili povratnih poziva, korištenjem ToolContext or CallbackContext objekt. Na primjer, alat poput save_attractions_to_state(tool_context, attractions: List) može spojiti nove atrakcije s onima koje su već pohranjene pod state, vraćajući jednostavnu poruku o statusu agentu dok ADK održava deltu stanja u sesiji.

Čitanje iz stanja je ergonomskije putem ključnih predložaka ugrađenih u upute. Kada instrukcija sadrži {my_key?}, ADK će ubrizgati state ako postoji; upitnik ga čini opcionalnim kako agent ne bi zakazao kada ključ nedostaje. To je ključno u tijekovima rada poput „istraživanje → pisanje → pregled“ gdje svaki korak čita ono što je prethodni korak spremio.

Za konverzacijsko pamćenje kroz naizmjenično, ključna ideja je ponovno koristiti iste Session za sljedeće korisničke poruke umjesto da se svaki put stvara nova. S dijeljenom sesijom, agent vidi prethodne poteze i može rješavati dodatna pitanja, ispravke i višekoračno planiranje. Ako slučajno stvorite potpuno novu sesiju po potezu, agent se ponaša kao da ima amneziju: ne može povezati dodatna pitanja s prethodnim kontekstom.

Država također igra veliku ulogu u agentima tijeka rada kao što su LoopAgent, koji se oslanjaju na trajne ključeve poput brojača, popisa povratnih informacija ili zastavica kako bi odlučili jesu li potrebne dodatne iteracije. Kritički agent može dodati komentare u CRITICAL_FEEDBACK u svakom prolazu, dok planer ili pročišćavač čita taj ključ kako bi poboljšao plan u sljedećoj iteraciji.

SequentialAgent: linearni tijekovi rada eksplicitno definirani

SequentialAgent je vaš uobičajeni obrazac kada imate niz koraka koji se moraju dogoditi fiksnim redoslijedom. Zamislite cjevovode poput „analiziraj zahtjev → istraživanje → nacrt → spremi u datoteku“ ili „identificiraj odredište → isplaniraj rutu → rezerviraj prijevoz“.

U ADK-u, a SequentialAgent drži popis sub_agents i pokreće ih jedan po jedan, prolazeći pored istih InvocationContext kroz cijeli lanac. Zbog Session i state dijele se, prvi agent može pohraniti svoj rezultat pod output_key="destination" i sljedeći agent ga je pročitao putem {destination} u svojim uputama bez ikakvog koda za lijepljenje.

Klasičan primjer je generator tona filma: glavni agent pozdravljača razgovara s korisnikom, a zatim ručno radi s njim. SequentialAgent to poziva istraživača, zatim scenarista, pa onda pisca datoteka. Korisnik vidi samo konačni ishod, ali graf događaja u ADK Webu otkriva interno stablo: greeter → film_concept_team → .

U usporedbi s ručnom orkestracijom s eksplicitnim if/elif blokovi i pozivi funkcija, SequentialAgent održava deklarativnim protok kontrole i minimizira standardne postavke. Slijed deklarirate jednom i tretirate ga kao jednog pozivajućeg agenta u svom runneru ili korisničkom sučelju, dok istovremeno koristite stanje sesije za prijenos podataka između koraka.

Sekvencijalni tijekovi rada također se lijepo kombiniraju s drugim agentima tijeka rada: možete ugraditi petlju ili paralelno širenje kao jedan od koraka u duljem lancu. Ovako se grade napredniji tokovi poput „ponavljanja kvalitete priče, zatim analize blagajni i glumačke postave, a zatim pisanja konsolidiranog izvješća“.

LoopAgent: iterativno usavršavanje i sobe za pisanje

LoopAgent je dizajniran za zadatke koji imaju koristi od nekoliko prolaza kroz rad dok se ne dostigne prag kvalitete. Umjesto jednog pristupa "generiraj jednom i nadaj se najboljem", možete kodirati proces predlaganja, kritike i usavršavanja.

Tipična konfiguracija petlje uključuje agente poput istraživača, generatora (npr. scenarista) i kritičara koji surađuju tijekom više rundi. U svakoj iteraciji istraživač može ažurirati pozadinske činjenice, scenarist prilagođava nacrt ili plan, a kritičar ga procjenjuje u odnosu na eksplicitne smjernice, odlučujući jesu li potrebne daljnje iteracije.

Petlje se zaustavljaju pod dva uvjeta: postizanjem max_iterations ili podagent koji signalizira da je posao obavljen. ADK nudi ugrađeni alat poput exit_loop koje kritičar može pozvati kada plan, nacrt ili dizajn prođe svoju internu kontrolnu listu. LoopAgent također poštuje escalate=True zastava u Event akcije, što vam daje još jedan način da se rano probudite.

Trajno stanje sesije je ovdje ključno: agenti čitaju ključeve poput PLOT_OUTLINE, research or CRITICAL_FEEDBACK i napišite poboljšane verzije ili dodatne komentare za svaki prolaz. Ovaj obrazac učinkovito simulira „sobu za pisce“ gdje stručnjaci razmišljaju, kritiziraju i poliraju dok netko ne proglasi rad spremnim.

Kombinacijom LoopAgent sa SequentialAgent, cijelu iterativnu petlju možete postaviti kao samo jedan korak u većem cjelovitom tijeku rada. Na primjer, writers_room (LoopAgent) bi se mogao prvo pokrenuti kako bi se stvorio čvrsti obris grafa, nakon čega bi file_writer Agent sprema rezultat i prilaže ostala izvješća.

ParallelAgent: raširi i okupi za neovisne zadatke

ParallelAgent implementira klasični obrazac „raspodjele / prikupljanja“ za zadatke koji su neovisni, ali dijele kontekst. Umjesto da se N istraživačkih koraka izvršava serijski, pokrećete ih sve odjednom i čekate da se svi završe, a zatim agregirate njihove rezultate.

Interno, ParallelAgent daje svakom podagentu zaseban InvocationContext.branch - Kao ParentBranch.ChildName – dok i dalje dijelimo isto session.state. To znači da svi mogu pročitati početni kontekst poput PLOT_OUTLINE, ali bi trebao zapisivati ​​izlaze u različite ključeve stanja (na primjer box_office_report, casting_report) kako bi se izbjegli sukobi.

Uobičajen primjer je „predprodukcijski tim“ za filmsku prezentaciju: jedan agent procjenjuje potencijal na kino blagajnama na temelju usporedivih filmova, drugi predlaže opcije za glumu, oboje se odvija paralelno. Kasnije file_writer zatim sastavlja izvješće koristeći ključne predloške za svaki podrezultat i pohranjuje ga na disk.

Paralelni tijekovi rada značajno smanjuju latenciju za široke upite i u scenarijima... analiza podataka u stvarnom vremenuAko vam trebaju prijedlozi za muzeje, opcije za koncerte i ideje za restorane za vikend, paralelno pokretanje triju specijaliziranih agenata brže je od sekvencijalnog slanja upita. Nakon raščlanjivanja, agent za sintezu čita sve rezultate iz stanja i proizvodi objedinjeni odgovor za korisnika.

Paralelni koraci su gotovo uvijek ugrađeni unutar SequentialAgent koji prvo priprema kontekst, a zatim pokreće ParallelAgent, zatim nastavlja s agregacijom i izvještavanjem. Ovaj obrazac je lako prepoznati i ponovno upotrijebiti nakon što se upoznate s ADK-ovim agentima za tijek rada.

Orkestracijski obrasci s ADK primitivima

Nakon što shvatite hijerarhiju, agente tijeka rada i stanje, možete implementirati nekoliko klasičnih obrazaca više agenata izravno u ADK-u. Ovi uzorci nisu čvrsto kodirani primitivi, već kompozicije izgrađene od istih osnovnih građevnih blokova.

Uzorak koordinatora/dispečera koristi središnjeg LLM agenta kao "usmjerivač" za korisničke upite, uz potporu više specijaliziranih podagenta. Koordinator čita zahtjev, a zatim ili prenosi kontrolu na podagenta putem delegiranja vođenog LLM-om ili eksplicitno poziva stručnjake koristeći AgentToolUobičajeni primjeri su agenti za gurmane, prijevoz ili vikend vodiči.

Sekvencijalni uzorak cjevovoda je jednostavno SequentialAgent čija djeca implementiraju dobro definiran korak procesa. Tokovi generatora i kritičara su klasična varijanta: prvi agent piše nacrt i sprema ga pod output_key, drugi agent ga analizira i sprema povratne informacije, a možda treći agent poboljšava rezultat na temelju tih povratnih informacija.

Paralelni uzorak raspoređivanja/skupljanja izražava se kao ParallelAgent ugniježđeno unutar sekvencijalnog tijeka rada. Paralelna djeca zapisuju rezultate u odvojene ključeve stanja; kasniji sintetički agent ih čita natrag i predstavlja kombinirani odgovor.

Hijerarhijska dekompozicija zadataka prirodno proizlazi iz stabla roditelj/dijete. Agenti više razine dijele ciljeve na podciljeve i delegiraju ih djeci (bilo putem delegiranja ili alata), s rezultatima koji se vraćaju unatrag kroz stablo. To je posebno korisno kod istraživačkih asistenata, optimizatora lanca opskrbe ili sustava financijskih savjetnika gdje svaka poddomena ima svog specijaliziranog agenta.

Iterativno usavršavanje s LoopAgent formalizira petlju generator-kritik u obrazac koji se može ponovno koristiti. Petlja izvršava agente planera, kritičara i pročišćavača više puta, koristeći ključeve stanja za pohranjivanje najnovijeg plana i odgovarajućih povratnih informacija, zaustavljajući se kada se dosegne kriterij kvalitete ili ograničenje iteracije.

Referentna arhitektura za višeagentske sustave na Google Cloudu

Osim logike agenta, i dalje morate negdje pokretati svoj sustav, a Google Cloud nudi dobro definiranu referentnu arhitekturu za implementacije s više agenata produkcijske razine. Na visokoj razini, rješenje kombinira frontend, agentska vremena izvođenja, Vertex AI modele, sigurnosne usluge i opcionalne okvire alata poput MCP-a.

Tipična postavka započinje s frontendom – često sučeljem za chat – koji radi na Cloud Runu. Korisnici razgovaraju s ovim korisničkim sučeljem, koje prosljeđuje zahtjeve koordinatorskom agentu izloženom kao usluga. Ovaj koordinator zatim bira između različitih tijekova rada agenta na temelju namjere korisnika, uključujući opcionalne putanje s ljudskim djelovanjem gdje ljudi mogu potvrditi ili poništiti odluke agenta.

Sami agenti mogu se pokretati u nekoliko okruženja: Cloud Run servisi, Google Kubernetes Engine (GKE) ili Vertex AI Agent Engine. ADK obuhvaća ove opcije, apstrahirajući neke od detalja izvođenja kako bi se programer usredotočio na logiku agenta, a ne na infrastrukturne instalacije.

Svi pozivi agenata oslanjaju se na Vertex AI ili druga okruženja za izvođenje modela za inferenciju, često omotana Model Armorom za sanitizaciju upita i odgovora. Model Armor pomaže u filtriranju pokušaja ubrizgavanja prompta, curenja osjetljivih podataka ili štetnog sadržaja prije ili nakon poziva modela, djelujući kao sigurnosna ograda oko generativnih komponenti.

MCP (Model Context Protocol) alati i poslužitelji dolaze do izražaja kada agenti moraju komunicirati s vanjskim sustavima – bazama podataka, datotečnim sustavima ili SaaS API-jima – na standardizirani način. MCP definira zajednički ugovor između agenta i poslužitelja alata, tako da jedan MCP klijent u vašem agentu može pristupiti mnogim alatima koje su izgradili različiti timovi bez uske povezanosti; to uključuje razmatranja o Sustavi za pohranu podataka y cómo exponerlos de forma segura.

Sigurnost i upravljanje za agentske aplikacije

Agentski sustavi uvode sigurnosne izazove koji nadilaze tradicionalne mikroservise, jer se LLM-ovi mogu prevariti u zlouporabu alata ili curenje podataka ako se ne pazi. Googleov preporučeni pristup spaja determinističke sigurnosne kontrole s obranama koje su svjesne LLM-a i vođene pravilima; također je ključno za njih. ograničenja, ograničenja i ograničenja de los modelos al diseñar estas defensas.

Ljudski nadzor ostaje najvažniji: tokovi s velikim utjecajem trebali bi uključivati ​​korake odobravanja u kojima osoba može pauzirati, pregledati ili staviti veto na predloženu radnju agenta. To se može modelirati kao namjenski alat za „ljudsku potvrdu“ koji šalje zahtjeve korisničkom sučelju i nastavlja izvršavanje tek nakon što čovjek odgovori.

Kontrola pristupa za agente obavlja se putem IAM-a: svaki agent ili servisni račun trebao bi imati samo minimalne dozvole potrebne za obavljanje svojih dužnosti. Ako je određeni agent kompromitiran ili zloupotrijebljen, radijus eksplozije je ograničen jer njegov servisni račun ne može pristupiti nepovezanim resursima ili alatima.

Ograničenje alata vođeno politikama, implementirano s komponentama poput SecurityPlugin plus PolicyEngine, omogućuje vam da zahtijevate potvrdu korisnika prije pokretanja određenih alata. Kada pravilo označi osjetljivi poziv, dodatak ga presreće, emitira poseban poziv funkcije "zatraži potvrdu" i čeka da vaša aplikacija vrati presudu, čime se učinkovito uključuje čovjek u proces visokorizičnih operacija.

Standardne sigurnosne značajke Google Clouda upotpunjuju sliku: VPC Service Controls za smanjenje rizika od krađe podataka, CMEK za ključeve za šifriranje kojima upravljaju korisnici, Cloud Armor za WAF i DDoS zaštitu, IAP ili Identity Platform za autentifikaciju korisnika i granularni IAM za pristup resursima. Za komunikaciju između agenata putem A2A, u produkciji su potrebni ili preporučeni TLS 1.2+ i OAuth-bazirana autentifikacija.

Pouzdanost, vidljivost i optimizacija troškova

Implementacije MAS-a u produkciji moraju biti pouzdane, vidljive i isplative; ADK se dobro integrira s operativnim alatima Google Clouda kako bi to omogućio. Možete instrumentirati agente, sesije i alate tako da se njihovi zapisnici i tragovi pojavljuju u Cloud Loggingu i Cloud Traceu.

S gledišta pouzdanosti, dizajnirajte graf agenta tako da tolerira kvarove u pojedinačnim komponentama. Gdje god je to moguće, izbjegavajte jedan, nezamjenjiv središnji mozak; dopustite neovisnim agentima da obavljaju lokalizirane zadatke kako prekid rada u jednom putu ne bi srušio cijelu aplikaciju; također, tehnički poslovi kao što su balanceo de carga en búsqueda distribuida para distribuir carga y reducir puntos de fallo. Simulirajte neuspjehe u postavljanju kako biste potvrdili ponašanje koordinacije pod stresom.

Za pozive modela, Vertex AI podržava dinamičke dijeljene kvote i osiguranu propusnost. Dijeljene kvote izbjegavaju stroga ograničenja po projektu u scenarijima plaćanja po korištenju, dok je osigurana propusnost ključna za opterećenja s visokim QPS-om i osjetljiva na latenciju koja se ne smiju ograničavati. Praćenje stopa zahtjeva i korištenja tokena pomaže vam da odlučite kada prijeći s kapaciteta na zahtjev na osigurani kapacitet.

Kontrola troškova uvelike ovisi o pametnom odabiru modela, pažljivom i brzom dizajnu i izbjegavanju nepotrebnih tokena. Započnite s isplativim modelima gdje je to moguće, neka upiti budu sažeti, ali informativni, eksplicitno tražite kratke izlaze kada je to moguće, iskoristite predmemoriranje konteksta za ponovljene velike upite i razmotrite predviđanje serija kada to radna opterećenja dopuštaju.

Podešavanje resursa Cloud Runa i dugoročni popusti dodatno optimiziraju troškove izvođenja. Započnite s zadanim CPU-om/memorijom, promatrajte stvarnu upotrebu i prilagodite je. Za predvidljiva opterećenja, popusti za obveznu upotrebu značajno smanjuju troškove.

Što se tiče uočljivosti, u svojoj strategiji praćenja trebali biste tretirati agente kao entitete prve klase. Bilježite njihove unose, odluke (npr. koje alate pozivaju, kojem agentu delegiraju) i promjene stanja. Koristite ADK-ove grafove događaja u web sučelju za otklanjanje pogrešaka u pojedinačnim sesijama i Cloud Logging plus prilagođene nadzorne ploče za trendove na razini cijelog voznog parka.

Ako se dobro izvede, ove prakse vam daju transparentan pregled vašeg MAS-a: možete vidjeti koji su agenti spori, koji se alati prekomjerno koriste, gdje su upute preduge i gdje su petlje kontrole kvalitete poput LoopAgent ponavljati više nego što se očekivalo. Ta povratna sprega ključna je za fino podešavanje kvalitete i troškova tijekom vremena.

Kombiniranjem ADK-ovih primitiva agenata, obrazaca tijeka rada i mehanizama stanja s referentnom arhitekturom, sigurnosnim paketom i operativnim alatima Google Clouda, možete dizajnirati višeagentske sustave koji su ne samo pametni na papiru, već i prilagodljivi, upravljivi i ekonomski isplativi u produkciji. Počevši od jednostavnih roditelj/dijete agenata i napredujući kroz sekvencijalne, petlje i paralelne orkestracije, dobivate skup alata za pretvaranje agentskih ideja u robusne, održive aplikacije koje zapravo pružaju poslovnu vrijednost.

API
Povezani članak:
Evolucija API-ja: Nove granice u integraciji, sigurnosti i agentskoj umjetnoj inteligenciji
Povezani postovi: