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

Početna » piton » Vodič za razvojne programere za višeagentne obrasce s ADK-om

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 haos. Googleov Agent Development Kit (ADK) je dizajniran upravo za ovo: omogućava vam da sastavite pouzdane multi-agentske sisteme, povežete alate i memoriju i implementirate sve na Google Cloudu uz vidljivost, sigurnost i kontrolu troškova produkcijskog nivoa.

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 radni tok – 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 ovih sistema u stvarnim okruženjima.

Zašto koristiti multiagentske sisteme u ADK-u?

Kada aplikaciju pokreće jedan, monolitni prompt agenta, brzo postaje teško o njoj razmišljati, testirati je i razvijati. Ogromni prompti su krhki, teški za otklanjanje grešaka i bolni za održavanje kako zahtjevi rastu. ADK vas gura ka izgradnji Višeagentni sistem (MAS) gdje svaki agent ima fokusiranu odgovornost, a orkestracija je eksplicitna.

Strukturiranje vaše aplikacije kao nekoliko kooperativnih agenata donosi modularnost, specijalizaciju i mogućnost ponovne upotrebe. Možete imati istraživačkog agenta, kritičara, program za pisanje datoteka, ruter, agenta za pristup podacima i ponovo ih koristiti u različitim projektima ili tokovima 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 radnog toka (sekvencijalne, paralelne, petlje) i prilagođene agente koji enkapsuliraju logiku koja nije LLM. Svi oni nasljeđuju od zajedničkog BaseAgent, tako da se uključuju u isti model orkestracije, evidentiranja, rukovanja stanjem i sistema alata.

Kako sistemi rastu, ovaj model kompozicije se skalira bolje od ad-hoc orkestracionog koda ili duboko ugniježđenih lanaca poziva funkcija oko jednog modela. Održavate kognitivno opterećenje 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 kombinovati da biste izrazili iznenađujuće bogate multiagentske arhitekture. Razumijevanje ovih osnovnih koncepata znatno olakšava kasnije razmišljanje o obrascima višeg nivoa.

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

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

Pored osnovnih LLM agenata, ADK uvodi i namjenske agente za tok rada – SequentialAgent, ParallelAgent i LoopAgent – čiji posao nije da „misle“ već da orkestriraju podagente. Svi oni dijele isti interfejs, ali implementiraju različite strategije izvršavanja: izvršavaju se po redoslijedu, paralelno širenje ili iteriraju u petlji s eksplicitnim pravilima završetka.

Treći osnovni primitiv je komunikacijski sloj, usmjeren na zajedničko Session i njegove state rječnik. Stanje sesije se ponaša kao obična bijela ploča: bilo koji agent ili alat može pisati međurezultate ili zastavice, a drugi agenti u istom pozivu mogu ih čitati, često putem šabloniranja 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š sistem i ekspresivnim i predvidljivim.

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

Delegiranje vođeno LLM-om, ponekad nazvano "prijenos agenta", omogućava LLM-u da odluči kada će predati zadatak drugom agentu na osnovu instrukcija i opisa agenata. Interno, model poziva posebnu funkciju kao što je transfer_to_agent(agent_name="screenwriter")ADK-ovi AutoFlow presreće ovaj poziv i preusmjerava izvršenje na odabranog agenta unutar dozvoljenog opsega (roditelj, djeca, braća i sestre, ovisno o konfiguraciji).

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

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

Gradivni blokovi: LLM agenti, agenti radnog procesa i prilagođeni agenti

Većina MAS topologija u ADK-u su kombinacije tri tipa agenata: agenti zasnovani na LLM-u, agenti zasnovani na radnom toku i prilagođeni agenti. Svaka kategorija rješava drugačiji dio problema orkestracije.

LLM agenti obuhvataju veliki jezički 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 radnog toka djeluju kao menadžeri, a ne kao radnici: oni sami ne razmišljaju, ali kontrolišu 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 historije, i LoopAgent izvršava sekvencu više puta dok se ne ispuni uslov 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 izvršava agente uvjetno na temelju metrike ili integrirati mehanizam poslovnih pravila koji određuje koji podtok treba pokrenuti ovisno o regulatornim ograničenjima.

Ova mješavina generičkih orkestracijskih primitiva i priključne logike čini ADK pogodnim za ozbiljna poslovna opterećenja, ne samo za demonstracije. Možete početi sa standardnim agentima za radni tok, 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 objekat koji sadrži historiju 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 objekat. 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 instrukcije. Kada instrukcija sadrži {my_key?}, ADK će ubrizgati state Ako postoji; upitnik ga čini opcionalnim kako agent ne bi doživio grešku kada ključ nedostaje. Ovo je ključno u radnim procesima poput „istraživanje → pisanje → pregled“ gdje svaki korak čita ono što je prethodni korak sačuvao.

Za konverzacijsko pamćenje kroz naizmjenične pokrete, ključna ideja je ponovna upotreba istih Session za sljedeće korisničke poruke umjesto kreiranja nove svaki put. Sa dijeljenom sesijom, agent vidi prethodne poteze i može rješavati dodatna pitanja, ispravke i višekoračno planiranje. Ako slučajno kreirate 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 radnog procesa kao što su LoopAgent, koji se oslanjaju na perzistentne ključeve kao što su brojači, liste povratnih informacija ili zastavice kako bi odlučili da li su potrebne dodatne iteracije. Kritički agent može dodati komentare u CRITICAL_FEEDBACK u svakom prolazu, dok planer ili stručnjak za poboljšanje očitava taj ključ kako bi poboljšao plan u sljedećoj iteraciji.

SequentialAgent: linearni tokovi 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 „identifikuj odredište → isplaniraj rutu → rezerviraj prijevoz“.

U ADK-u, a SequentialAgent drži listu sub_agents i pokreće ih jednog po jednog, prolazeći pored istih InvocationContext kroz cijeli lanac. Zbog Session i state se dijele, možete podesiti da prvi agent pohrani 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 za pozdrav razgovara s korisnikom, a zatim ručno radi na... SequentialAgent to poziva istraživača, zatim scenaristu, 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 poređenju sa ručnom orkestracijom sa eksplicitnim if/elif blokovi i pozivi funkcija, SequentialAgent održava deklarativnim tok kontrole i minimizira standardne postavke. Sekvencu deklarišete jednom i tretirate je kao jednog pozivajućeg agenta u vašem runneru ili korisničkom interfejsu, dok istovremeno koristite stanje sesije za prenos podataka između koraka.

Sekvencijalni tokovi rada se također lijepo kombiniraju s drugim agentima toka rada: možete ugraditi petlju ili paralelno širenje kao jedan od koraka u dužem lancu. Ovako se grade napredniji tokovi poput „ponavljanja kvaliteta priče, zatim analize blagajni i kastinga, a zatim pisanja konsolidovanog izvještaja“.

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 kao što su istraživač, generator (npr. scenarist) i kritičar koji sarađuju tokom 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 da li su potrebne daljnje iteracije.

Petlje se zaustavljaju pod dva uslova: dostizanjem max_iterations ili podagent koji signalizira da je posao završen. ADK nudi ugrađeni alat kao što je exit_loop koje kritičar može pozvati kada plan, nacrt ili dizajn prođe svoju internu listu provjere. LoopAgent također poštuje escalate=True zastava u Event akcije, što vam daje još jedan način da se ranije 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 efektivno simulira „sobu za pisce“ gdje stručnjaci razmišljaju, kritikuju i dotjeruju dok neko ne proglasi rad spremnim.

Kombinovanjem LoopAgent sa SequentialAgent, možete smjestiti cijelu iterativnu petlju kao samo jedan korak u većem cjelokupnom radnom procesu. 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 ostale izvještaje.

ParallelAgent: raširivanje i prikupljanje za nezavisne zadatke

ParallelAgent implementira klasični obrazac „raspodjele / prikupljanja“ za zadatke koji su nezavisni, 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 trebalo da zapisuje 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 blagajnama na osnovu uporedivih filmova, drugi predlaže opcije za kasting, a oboje se odvija paralelno. Naknadni file_writer zatim sastavlja izvještaj koristeći ključne predloške za svaki podrezultat i pohranjuje ga na disk.

Paralelni tokovi rada značajno smanjuju latenciju za široke upite i u nekim scenarijima... analiza podataka u realnom vremenuAko vam trebaju prijedlozi za muzeje, opcije za koncerte i ideje za restorane za vikend, paralelno pokretanje tri specijalizovana agenta je brže od sekvencijalnog slanja upita. Nakon raspodele, 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 sa agregacijom i izvještavanjem. Ovaj obrazac je lako prepoznati i ponovo upotrijebiti kada se upoznate s ADK-ovim agentima za radni tok.

Orkestracijski obrasci s ADK primitivima

Kada shvatite hijerarhiju, agente radnog procesa i stanje, možete implementirati nekoliko klasičnih multi-agentskih obrazaca direktno u ADK-u. Ovi obrasci nisu čvrsto kodirani primitivi, već kompozicije izgrađene od istih osnovnih gradivnih blokova.

Koordinator/dispečerski obrazac koristi centralnog LLM agenta kao "ruter" za korisničke upite, podržanog od strane više specijalizovanih 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 vodiči za vikend.

Sekvencijalni obrazac 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 precizira rezultat na osnovu tih povratnih informacija.

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

Hijerarhijska dekompozicija zadataka prirodno proizilazi iz stabla roditelj/dijete. Agenti višeg nivoa dijele ciljeve na podciljeve i delegiraju ih djeci (bilo putem delegiranja ili alata), s rezultatima koji se vraćaju unazad kroz stablo. Ovo je posebno korisno kod istraživačkih asistenata, optimizatora lanca snabdijevanja ili sistema finansijskih savjetnika gdje svaki poddomen ima svog specijaliziranog agenta.

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

Referentna arhitektura za multiagentske sisteme na Google Cloudu

Pored logike agenta, i dalje morate negdje pokrenuti svoj sistem, a Google Cloud nudi dobro definiranu referentnu arhitekturu za implementacije više agenata produkcijskog nivoa. Na visokom nivou, rješenje kombinuje frontend, agentska okruženja, Vertex AI modele, sigurnosne usluge i opcionalne alatne okvire poput MCP-a.

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

Sami agenti mogu raditi u nekoliko okruženja: Cloud Run servisi, Google Kubernetes Engine (GKE) ili Vertex AI Agent Engine. ADK obuhvata ove opcije, apstrahujući neke od detalja vremena izvršavanja tako da se programer fokusira na logiku agenta, a ne na infrastrukturne instalacije.

Svi pozivi agenata oslanjaju se na Vertex AI ili druga okruženja za izvršavanje modela za inferenciju, često obavijena 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 serveri dolaze do izražaja kada agenti moraju komunicirati s vanjskim sistemima – bazama podataka, datotečnim sistemima ili SaaS API-jima – na standardiziran način. MCP definira zajednički ugovor između agenta i servera alata, tako da jedan MCP klijent u vašem agentu može pristupiti mnogim alatima koje su izgradili različiti timovi bez uske povezanosti; ovo uključuje razmatranja o Sistemi za skladištenje podataka y cómo exponerlos de forma segura.

Sigurnost i upravljanje za agentske aplikacije

Agentski sistemi uvode sigurnosne izazove koji prevazilaze tradicionalne mikroservise, jer LLM-ovi mogu biti prevareni da zloupotrebljavaju alate ili cure podatke ako niste oprezni. Googleov preporučeni pristup spaja determinističke sigurnosne kontrole s odbranama koje su svjesne LLM-a i vođene politikama; 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. Ovo se može modelirati kao namjenski alat za „ljudsku potvrdu“ koji šalje zahtjeve korisničkom interfejsu i nastavlja izvršavanje tek kada čovjek odgovori.

Kontrola pristupa za agente se obavlja putem IAM-a: svaki agent ili servisni račun treba imati samo minimalne dozvole potrebne za obavljanje svojih dužnosti. Ako je određeni agent kompromitovan ili zloupotrebljen, 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ćava vam da zahtijevate potvrdu korisnika prije pokretanja određenih alata. Kada politika označi osjetljiv poziv, dodatak ga presreće, emitira poseban poziv funkcije „zatraži potvrdu“ i čeka da vaša aplikacija vrati presudu, efektivno stavljajući čovjeka u petlju za visokorizične operacije.

Standardne sigurnosne funkcije 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 agenta putem A2A, u produkciji su obavezni ili preporučeni TLS 1.2+ i OAuth-bazirana autentifikacija.

Pouzdanost, vidljivost i optimizacija troškova

Implementacije MAS sistema u produkciji moraju biti pouzdane, lako uočljive i isplative; ADK se dobro integriše sa operativnim alatima Google Clouda kako bi to omogućio. Možete instrumentirati agente, sesije i alate tako da se njihovi logovi i tragovi pojavljuju u Cloud Logging-u i Cloud Trace-u.

Sa stanovišta pouzdanosti, dizajnirajte graf agenta tako da toleriše kvarove u pojedinačnim komponentama. Gdje god je to moguće, izbjegavajte jedan, nezamjenjiv centralni mozak; dopustite nezavisnim agentima da obavljaju lokalizirane zadatke tako da prekid rada na jednoj putanji ne sruši 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 obezbjeđeni protok. Dijeljene kvote izbjegavaju stroga ograničenja po projektu u scenarijima plaćanja po korištenju, dok je osigurani protok ključan 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 uveliko zavisi od pametnog odabira modela, pažljivog i brzog dizajna i izbjegavanja nepotrebnih tokena. Počnite s isplativim modelima gdje je to moguće, neka upiti budu koncizni, ali informativni, eksplicitno tražite kratke izlaze kada je to moguće, iskoristite keširanje konteksta za ponovljene velike upite i razmotrite predviđanje serija kada to radna opterećenja dozvoljavaju.

Podešavanje resursa Cloud Run-a i dugoročni popusti dodatno optimiziraju troškove izvršavanja. Počnite sa zadanim CPU/memorijom, posmatrajte stvarnu upotrebu i prilagodite je. Za predvidljiva opterećenja, popusti za obaveznu upotrebu značajno smanjuju troškove.

Sa strane vidljivosti, u svojoj strategiji praćenja trebali biste tretirati agente kao entitete prve klase. Zabilježite njihove unose, odluke (npr. koje alate pozivaju, kojem agentu delegiraju) i promjene stanja. Koristite ADK-ove grafikone događaja u web korisničkom interfejsu za otklanjanje grešaka u pojedinačnim sesijama i Cloud Logging plus prilagođene kontrolne ploče za trendove na nivou cijelog voznog parka.

Ako se dobro urade, 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 je ključna za fino podešavanje i kvalitete i troškova tokom vremena.

Kombinovanjem ADK-ovih primitiva agenata, obrazaca radnog toka i mehanizama stanja sa referentnom arhitekturom, sigurnosnim paketom i operativnim alatima Google Clouda, možete dizajnirati višeagentske sisteme 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, dobijate set alata za pretvaranje agentskih ideja u robusne, održive aplikacije koje zapravo pružaju poslovnu vrijednost.