Sprievodca vývojára k multiagentovým vzorom s ADK

Domov » Pytón » Sprievodca vývojára k multiagentovým vzorom s ADK

Agentové aplikácie rýchlo prerastajú klasický vzorec „jednej mega výzvy“ a vývojári potrebujú solídny mentálny model na štruktúrovanie viacerých agentov bez toho, aby upadli do chaosu. Sada pre vývoj agentov (ADK) od spoločnosti Google bola navrhnutá práve na tento účel: umožňuje vám zostavovať spoľahlivé multiagentové systémy, prepájať nástroje a pamäť a nasadzovať všetko v službe Google Cloud s pozorovateľnosťou, zabezpečením a kontrolou nákladov na produkčnej úrovni.

Táto príručka vás prevedie hlavnými multiagentovými vzormi podporovanými službou ADK – od jednoduchých hierarchií rodič/dieťa až po sekvenčné, cyklické a paralelné agenty pracovných postupov – a ukazuje, ako zapadajú do širšej referenčnej architektúry v službe Google Cloud. Budeme sa venovať aj zdieľanému stavu relácie, mechanizmom delegovania, bežným multiagentovým plánom a praktickým aspektom nasadenia, zabezpečenia a prevádzky týchto systémov v reálnych prostrediach.

Prečo multiagentové systémy v ADK?

Keď je aplikácia riadená jedným monolitickým výzvou agenta, rýchlo sa stáva ťažké o nej uvažovať, testovať ju a vyvíjať. Obrovské výzvy sú krehké, zložité na ladenie a ich údržba je bolestivá s rastúcimi požiadavkami. ADK vás núti budovať Multiagentový systém (MAS) kde každý agent má cielenú zodpovednosť a orchestrácia je explicitná.

Štruktúrovanie vašej aplikácie ako niekoľkých spolupracujúcich agentov prináša modularitu, špecializáciu a opätovnú použiteľnosť. Môžete mať výskumného agenta, kritika, zapisovača súborov, smerovača, agenta pre prístup k údajom a opätovne ich používať v rôznych projektoch alebo pracovných postupoch namiesto opätovného vkladania tej istej logiky do jedného veľkého príkazového riadka.

ADK vám poskytuje konkrétne stavebné bloky na dosiahnutie tohto cieľa: agentov zameraných na LLM, agentov pracovných postupov (sekvenčných, paralelných, cyklických) a vlastných agentov, ktorí zapuzdrujú logiku mimo LLM. Všetky dedia zo spoločného BaseAgent, takže sa pripájajú k rovnakému modelu orchestrácie, protokolovaniu, spracovaniu stavu a systému nástrojov.

S rastom systémov sa tento kompozičný model škáluje lepšie ako ad-hoc orchestračný kód alebo hlboko vnorené reťazce volaní funkcií okolo jedného modelu. Udržujete kognitívnu záťaž zvládnuteľnú: každý agent má jasný mandát a dobre definovanú interakčnú plochu s ostatnými.

ADK primitívy pre skladanie agentov

ADK sprístupňuje malú sadu primitív, ktoré môžete kombinovať na vyjadrenie prekvapivo bohatých multiagentových architektúr. Pochopenie týchto základných konceptov značne uľahčuje neskoršie uvažovanie o vzorcoch na vyššej úrovni.

Prvým primitívom je hierarchia agentov: každý agent môže deklarovať zoznam sub_agents, tvoriaci strom s jedným root_agent na vrchu. Keď odovzdávate deti do sub_agents, ADK automaticky prepojí ich parent_agent referencia a vynucuje, aby daná inštancia mala iba jedného rodiča (inak ValueError je zvýšený).

Táto hierarchia je viac než len dekorácia: definuje, ktorí agenti môžu delegovať na ktoré úlohy a predstavuje rozsah používaný agentmi pracovného postupu a prenosom riadeným LLM. Z ľubovoľného agenta sa môžete pohybovať smerom nahor cez agent.parent_agent alebo nájsť potomkov s agent.find_agent(name), čo je mimoriadne užitočné pri ladení.

Okrem základných agentov LLM predstavuje ADK špecializovaných agentov pracovných postupov – SequentialAgent, ParallelAgent a LoopAgent – ktorých úlohou nie je „myslieť“, ale riadiť subagentov. Všetky zdieľajú rovnaké rozhranie, ale implementujú rôzne stratégie vykonávania: spúšťajú sa postupne, rozdeľujú sa paralelne alebo iterujú v slučke s explicitnými pravidlami ukončenia.

Treťou základnou primitívnou vrstvou je komunikačná vrstva, zameraná na zdieľané Session a jeho state slovník. Stav relácie funguje ako bežná biela tabuľa: ktorýkoľvek agent alebo nástroj môže zapisovať medzivýsledky alebo príznaky a ostatní agenti v tom istom volaní ich môžu čítať, často prostredníctvom šablón kľúčov vo svojich inštrukciách (napríklad {PLOT_OUTLINE?}).

Ako agenti medzi sebou komunikujú v ADK

ADK podporuje tri doplnkové komunikačné režimy medzi agentmi: zdieľaný stav relácie, prenos riadený LLM a explicitné vyvolanie prostredníctvom AgentTool. Výber správneho pre každú interakciu udrží váš systém expresívny aj predvídateľný.

Stav zdieľanej relácie (session.state) je najjednoduchší a najrozšírenejší mechanizmus. V rámci jedného volania všetci agenti vidia to isté Session objekt prostredníctvom InvocationContextNástroj alebo spätné volanie to dokáže context.state = valuea neskorší agent ho môže získať pomocou context.state.get("data_key")Pre agentov LLM, nastavenie output_key automaticky uchová svoju konečnú odpoveď pod týmto kľúčom.

Delegovanie riadené LLM, niekedy nazývané „prenos agenta“, umožňuje LLM rozhodnúť sa, kedy odovzdať úlohu inému agentovi na základe pokynov a popisov agentov. Interne model vydáva špeciálne volanie funkcie, ako napríklad transfer_to_agent(agent_name="screenwriter")ADK AutoFlow zachytí toto volanie a presmeruje vykonanie na vybraného agenta v rámci povoleného rozsahu (rodič, deti, súrodenci v závislosti od konfigurácie).

Explicitné volanie s AgentTool poskytuje vám kontrolovanejší, funkčnejší spôsob volania jedného agenta z druhého. Inštanciu cieľového agenta zabalíte do AgentTool, pridajte ho k volajúcemu tools zoznam a LLM potom môže vybrať tento nástroj ako akúkoľvek inú funkciu. Po vyvolaní, AgentTool.run_async spustí subagenta, zlúči stav a artefakty späť a vráti odpoveď subagenta ako výsledok nástroja.

Tieto tri kanály pokrývajú väčšinu potrieb viacerých agentov: asynchrónne prenášanie dát prostredníctvom stavu, flexibilné smerovanie prostredníctvom prenosu a úzke synchrónne volania prostredníctvom nástrojov. V zložitejších návrhoch ich často miešate v rámci jedného stromu: smerovač, ktorý prenáša dáta k podradeným systémom, špecialistov, ktorí používajú stav na komunikáciu, a jedného alebo dvoch agentov dostupných ako nástroje na ad-hoc delegovanie.

Stavebné bloky: agenti LLM, agenti pracovných postupov a zákaznícki agenti

Väčšina topológií MAS v ADK je kombináciou troch typov agentov: agenti založené na LLM, agenti založené na pracovných postupoch a agenti zameraní na vlastné agenty. Každá kategória rieši inú časť problému orchestrácie.

Agenti LLM zabalia rozsiahly jazykový model a voliteľné nástroje, spätné volania a smerovanie výstupu do BaseAgent. Predstavte si ich ako vaše „mysliace“ komponenty: interpretujú vstup používateľa, volajú nástroje, aktualizujú stav a buď odpovedajú používateľovi, alebo odovzdávajú príkaz inému agentovi.

Agenti pracovného postupu fungujú skôr ako manažéri než ako pracovníci: sami neuvažujú, ale riadia poradie, paralelizmus a opakovanie vykonávania subagentov. SequentialAgent spúšťa svoje deti jedno po druhom a zároveň zdieľa to isté InvocationContext, ParallelAgent rozvetvené naprieč viacerými vetvami, ktoré zdieľajú stav, ale majú odlišné vetvy histórie a LoopAgent opakovane vykonáva sekvenciu, kým nie je splnená podmienka zastavenia.

Vlastní agenti sa rozširujú BaseAgent s ľubovoľnou logikou inej ako LLM, keď vstavané stratégie orchestrácie nestačia. Napríklad môžete implementovať vlastný plánovač, ktorý spúšťa agentov podmienečne na základe metrík, alebo integrovať systém obchodných pravidiel, ktorý určuje, ktorý podtok sa má spustiť v závislosti od regulačných obmedzení.

Táto kombinácia generických orchestračných primitív a zásuvnej logiky robí ADK vhodným pre seriózne podnikové záťaže, nielen pre demá. Môžete začať so štandardnými agentmi pracovného postupu a až keď sa požiadavky stanú exotickými, siahnete po nich. CustomAgent.

Stav relácie a vzory pamäte

Stav relácie v ADK je základom krátkodobej konverzačnej pamäte aj štruktúrovaných dát, ktoré si agenti prenášajú. Každá konverzácia používa Session objekt obsahujúci históriu správ a meniteľný state slovník dostupný všetkým agentom v danom volaní.

Zápis do stavu sa zvyčajne vykonáva vo vnútri nástrojov alebo spätných volaní pomocou ToolContext or CallbackContext objekt. Napríklad nástroj ako save_attractions_to_state(tool_context, attractions: List) môže zlúčiť nové atrakcie s tými, ktoré sú už uložené pod state, pričom sa agentovi vráti jednoduchá stavová správa, zatiaľ čo ADK zachová rozdiel medzi stavmi v relácii.

Čítanie zo stavu je ergonomické vďaka kľúčovým šablónam vloženým do inštrukcií. Keď inštrukcia obsahuje {my_key?}, ADK vstrekne state Ak existuje, otáznik ho označuje ako voliteľný, aby agent nezlyhal, keď kľúč chýba. Toto je kľúčové v pracovných postupoch ako „výskum → písanie → kontrola“, kde každý krok načíta, čo uložil predchádzajúci krok.

Pre konverzačnú pamäť naprieč striedavými vecami je kľúčovou myšlienkou opätovné použitie toho istého Session pre následné používateľské správy namiesto vytvárania novej zakaždým. Vďaka zdieľanej relácii agent vidí predchádzajúce kroky a môže spracovať následné otázky, opravy a viackrokové plánovanie. Ak omylom vytvoríte úplne novú reláciu za každé kolo, agent sa bude správať, akoby mal amnéziu: nedokáže prepojiť následné kroky s predchádzajúcim kontextom.

Štát tiež zohráva veľkú úlohu v agentoch pracovného postupu, ako napríklad LoopAgent, ktoré sa spoliehajú na perzistentné kľúče, ako sú počítadlá, zoznamy spätnej väzby alebo príznaky, aby rozhodli, či sú potrebné ďalšie iterácie. Kritický agent môže pridávať komentáre do CRITICAL_FEEDBACK pri každom prechode, zatiaľ čo plánovač alebo spresňovač prečíta tento kľúč, aby v ďalšej iterácii vylepšil plán.

SequentialAgent: explicitne definované lineárne pracovné postupy

SequentialAgent je váš preferovaný vzor, ​​keď máte sériu krokov, ktoré sa musia vykonať v pevne stanovenom poradí. Predstavte si postupy ako „analýza požiadavky → výskum → návrh → uloženie do súboru“ alebo „identifikácia cieľa → plánovanie trasy → rezervácia prepravy“.

V ADK, a SequentialAgent má zoznam sub_agents a spúšťa ich jeden po druhom, míňajúc to isté InvocationContext cez celý reťazec. Vzhľadom k tomu, Session a state sú zdieľané, prvý agent môže uložiť svoj výsledok pod output_key="destination" a ďalší agent si to prečítal cez {destination} v jeho návode bez akéhokoľvek lepidla.

Klasickým príkladom je generátor tónov filmu: koreňový agent pre uvítanie hovorí s používateľom a potom pracuje s... SequentialAgent to si vyžaduje najprv výskumníka, potom scenáristu a nakoniec zapisovateľa súborov. Používateľ vidí iba konečný výsledok, ale graf udalostí v ADK Web odhaľuje interný strom: greeter → film_concept_team → .

V porovnaní s manuálnou orchestráciou s explicitným if/elif bloky a volania funkcií, SequentialAgent zachováva deklaratívny tok riadenia a minimalizuje štandardné postupy. Sekvenciu deklarujete raz a vo svojom runneri alebo používateľskom rozhraní s ňou zaobchádzate ako s jedným volateľným agentom, pričom na prenos údajov medzi krokmi využívate stav relácie.

Sekvenčné pracovné postupy sa tiež dobre kombinujú s inými agentmi pracovných postupov: ako jeden z krokov v dlhšom reťazci môžete vložiť slučku alebo paralelné rozdelenie. Takto sa budujú pokročilejšie postupy, ako napríklad „iterácia kvality príbehu, následná analýza pokladničných tržieb a obsadenia a nakoniec napísanie konsolidovanej správy“.

LoopAgent: iteratívne zdokonaľovanie a miestnosti pre písanie

LoopAgent je určený pre úlohy, ktoré profitujú z niekoľkých prechodov práce, kým sa nedosiahne prahová hodnota kvality. Namiesto jediného prístupu „vygeneruj raz a dúfaj v to najlepšie“ môžete zakódovať proces návrhu, kritiky a vylepšovania.

Typická konfigurácia slučky zahŕňa agentov, ako sú výskumník, generátor (napr. scenárista) a kritik, ktorí spolupracujú vo viacerých kolách. Pri každej iterácii môže výskumník aktualizovať základné fakty, scenárista upraví osnovu alebo plán a kritik ho vyhodnotí podľa explicitných pokynov a rozhodne, či sú potrebné ďalšie iterácie.

Slučky sa zastavia za dvoch podmienok: dosiahnutím max_iterations alebo subagent signalizujúci, že práca je vykonaná. ADK sprístupňuje vstavaný nástroj ako napríklad exit_loop na ktoré sa kritik môže odvolať, keď plán, náčrt alebo návrh prejde interným kontrolným zoznamom. LoopAgent tiež rešpektuje escalate=True vlajka v Event akcie, čo vám dáva ďalší spôsob, ako sa prebudiť skôr.

Kľúčový je tu trvalý stav relácie: agenti čítajú kľúče ako PLOT_OUTLINE, research or CRITICAL_FEEDBACK a ku každému prechodu napísať vylepšené verzie alebo ďalšie komentáre. Tento vzor efektívne simuluje „miestnosť pre spisovateľov“, kde špecialisti brainstormujú, kritizujú a leštia, kým niekto nevyhlási prácu za hotovú.

Kombináciou LoopAgent s SequentialAgent, môžete celú iteratívnu slučku umiestniť ako jeden krok v rámci rozsiahlejšieho komplexného pracovného postupu. Napríklad, writers_room (LoopAgent) sa môže spustiť ako prvý, aby vytvoril súvislý obrys grafu, po ktorom file_writer Agent uloží výsledok a pripojí ďalšie správy.

ParallelAgent: rozdeľovanie a zhromažďovanie pre nezávislé úlohy

ParallelAgent implementuje klasický vzorec „rozptyľovania / zhromažďovania“ pre úlohy, ktoré sú nezávislé, ale zdieľajú kontext. Namiesto spustenia N výskumných krokov za sebou ich spustíte všetky naraz a počkáte, kým sa všetky dokončia, a potom ich výstupy agregujete.

interne ParallelAgent dáva každému subagentovi odlišný InvocationContext.branch - Páči sa mi to ParentBranch.ChildName – pričom stále zdieľajú to isté session.state. To znamená, že všetci dokážu prečítať počiatočný kontext, ako napríklad PLOT_OUTLINE, ale mal by zapisovať výstupy do odlišných stavových kľúčov (napríklad box_office_report, casting_report) aby sa predišlo konfliktom.

Bežným príkladom je „predprodukčný tím“ pre filmovú prezentáciu: jeden agent odhaduje potenciálny zisk na základe porovnateľných filmov, iný navrhuje možnosti obsadenia, pričom obe činnosti prebiehajú paralelne. Nasledujúci file_writer potom zostaví správu s použitím kľúčových šablón pre každý čiastkový výsledok a uloží ju na disk.

Paralelné pracovné postupy výrazne znižujú latenciu pre rozsiahle dotazy a v rôznych scenároch. analýza údajov v reálnom časeAk potrebujete tipy na múzeá, možnosti koncertov a nápady na reštaurácie na víkend, spustenie troch špecializovaných agentov paralelne je rýchlejšie ako ich postupné vyhľadávanie. Po rozdelení na viacero úrovní syntézny agent prečíta všetky výsledky zo stavu a vygeneruje jednotnú odpoveď pre používateľa.

Paralelné kroky sú takmer vždy zabudované vo vnútri SequentialAgent ktorý najprv pripraví kontext a potom spustí ParallelAgent, potom pokračuje agregáciou a reportovaním. Tento vzor sa dá ľahko rozpoznať a znova použiť, keď sa zoznámite s agentmi pracovného postupu ADK.

Orchestračné vzory s primitívami ADK

Keď pochopíte hierarchiu, agentov pracovného postupu a stav, môžete priamo v ADK implementovať niekoľko klasických multiagentových vzorov. Tieto vzory nie sú pevne zakódované primitívy, ale kompozície vytvorené z rovnakých základných stavebných blokov.

Vzor koordinátor/dispečer používa centrálneho agenta LLM ako „smerovač“ pre používateľské dotazy, ktorého podporujú viaceré špecializované subagenty. Koordinátor si prečíta požiadavku a potom buď odovzdá riadenie subagentovi prostredníctvom delegovania riadeného LLM, alebo explicitne zavolá špecialistov pomocou AgentToolBežnými príkladmi sú gurmáni, dopravní agenti alebo agenti víkendových sprievodcov.

Sekvenčný vzorec pipeline je jednoducho SequentialAgent ktorých deti implementujú dobre vymedzený krok procesu. Toky generátor-kritik sú klasickým variantom: prvý agent napíše koncept a uloží ho pod output_key, druhý agent to analyzuje a ukladá spätnú väzbu a prípadne tretí agent na základe tejto spätnej väzby výsledok spresní.

Paralelný vzor rozvetvenia/zhromažďovania je vyjadrený ako ParallelAgent vnorené v rámci sekvenčného pracovného postupu. Paralelné deti zapisujú výsledky do samostatných stavových kľúčov; neskorší syntetizátor ich prečíta a prezentuje kombinovanú odpoveď.

Hierarchická dekompozícia úloh prirodzene vyplýva zo stromu rodič/dieťa. Agenti vyššej úrovne rozdeľujú ciele na podciele a delegujú ich na podradené objekty (buď prostredníctvom delegovania, alebo nástrojov), pričom výsledky sa postupne zobrazujú v stromovej štruktúre. Toto je obzvlášť užitočné pre výskumných asistentov, optimalizátorov dodávateľského reťazca alebo systémov finančných poradcov, kde každá poddoména má svojho vlastného špecializovaného agenta.

Iteratívne zdokonaľovanie s LoopAgent formalizuje slučku generátor-kritik do opakovane použiteľného vzoru. Slučka vykoná agentov plánovača, kritika a spresňovača viackrát, pričom pomocou stavových kľúčov uchová najnovší plán a zodpovedajúcu spätnú väzbu a zastaví sa, keď sa dosiahne kritérium kvality alebo limit iteracií.

Referenčná architektúra pre multiagentové systémy v službe Google Cloud

Okrem logiky agentov musíte svoj systém stále niekde spúšťať a Google Cloud ponúka dobre definovanú referenčnú architektúru pre nasadenie viacerých agentov na produkčnej úrovni. Na vysokej úrovni riešenie kombinuje frontend, runtime agentov, modely umelej inteligencie Vertex, bezpečnostné služby a voliteľné frameworky nástrojov ako MCP.

Typické nastavenie začína s frontendom – často chatovacím rozhraním – bežiacim na Cloud Run. Používatelia komunikujú s týmto používateľským rozhraním, ktoré preposiela požiadavky koordinačnému agentovi, ktorý je vystavený ako služba. Tento koordinátor si potom vyberá medzi rôznymi pracovnými postupmi agenta na základe zámeru používateľa vrátane voliteľných ciest s ľudskou prítomnosťou, kde môžu ľudia overovať alebo prepisovať rozhodnutia agenta.

Samotní agenti môžu bežať v niekoľkých prostrediach: cloudové služby, Google Kubernetes Engine (GKE) alebo Vertex AI Agent Engine. ADK pokrýva tieto možnosti a abstrahuje niektoré detaily runtime prostredia, takže sa vývojár zameriava na logiku agenta a nie na infraštruktúrne rozvody.

Všetky volania agentov sa spoliehajú na Vertex AI alebo iné runtime modely pre inferenciu, často obalené Model Armorom na dezinfekciu výziev a odpovedí. Model Armor pomáha filtrovať pokusy o vloženie prompt-injection, úniky citlivých údajov alebo škodlivý obsah pred alebo po volaniach modelu a pôsobí ako bezpečnostná ochrana okolo generatívnych komponentov.

Nástroje a servery MCP (Model Context Protocol) vstupujú do hry, keď agenti musia štandardizovaným spôsobom komunikovať s externými systémami – databázami, súborovými systémami alebo SaaS API. MCP definuje spoločnú zmluvu medzi agentom a serverom nástrojov, takže jeden klient MCP vo vašom agentovi môže pristupovať k mnohým nástrojom vytvoreným rôznymi tímami bez úzkeho prepojenia; toto zahŕňa aj aspekty týkajúce sa... Systémy na ukladanie dát y cómo exponerlos de forma segura.

Bezpečnosť a riadenie pre agentové aplikácie

Agentové systémy predstavujú bezpečnostné výzvy, ktoré idú nad rámec tradičných mikroslužieb, pretože LLM môžu byť oklamané a zneužívajú nástroje alebo unikajú dáta, ak nie sú opatrní. Odporúčaný prístup spoločnosti Google spája deterministické bezpečnostné kontroly s obrannými mechanizmami riadenými pravidlami, ktoré zohľadňujú LLM; obmedzenia, záväzky a záväzky de los modelos al diseñar estas defensas.

Ľudský dohľad zostáva prvoradý: postupy s vysokým dopadom by mali zahŕňať kroky schvaľovania, v ktorých môže osoba pozastaviť, skontrolovať alebo vetovať navrhovaný krok agenta. Toto sa dá modelovať ako špecializovaný nástroj na „potvrdzovanie človekom“, ktorý zobrazuje požiadavky v používateľskom rozhraní a obnoví ich vykonávanie až po ľudskej odpovedi.

Riadenie prístupu agentov sa vykonáva prostredníctvom IAM: každý agent alebo servisný účet by mal mať iba minimálne povolenia potrebné na vykonávanie svojich povinností. Ak je daný agent ohrozený alebo zneužitý, dosah útoku je obmedzený, pretože jeho servisný účet nemôže pristupovať k nesúvisiacim zdrojom alebo nástrojom.

Nástrojové brány riadené politikami, implementované s komponentmi ako SecurityPlugin plus PolicyEngine, umožňuje vyžadovať potvrdenie používateľa pred spustením určitých nástrojov. Keď politika označí citlivé volanie, doplnok ho zachytí, vydá špeciálne volanie funkcie „požiadať o potvrdenie“ a čaká na odpoveď od vašej aplikácie, čím efektívne zabezpečí ľudský zásah pre vysoko rizikové operácie.

Štandardné bezpečnostné funkcie služby Google Cloud dopĺňajú celkový obraz: VPC Service Controls na zníženie rizika úniku údajov, CMEK pre šifrovacie kľúče spravované zákazníkom, Cloud Armor na ochranu pred WAF a DDoS, IAP alebo Identity Platform na overovanie používateľov a podrobná IAM pre prístup k zdrojom. Pre komunikáciu medzi agentmi prostredníctvom A2A sa v produkčnom prostredí vyžaduje alebo odporúča autentifikácia založená na TLS 1.2+ a OAuth.

Spoľahlivosť, pozorovateľnosť a optimalizácia nákladov

Nasadenia produkčných MAS musia byť spoľahlivé, pozorovateľné a nákladovo efektívne; ADK sa dobre integruje s prevádzkovými nástrojmi služby Google Cloud, aby to bolo možné. Agenta, relácie a nástroje môžete instrumentalizovať tak, aby sa ich protokoly a stopy zobrazovali v Cloud Logging a Cloud Trace.

Z hľadiska spoľahlivosti navrhnite graf agentov tak, aby toleroval zlyhania v jednotlivých komponentoch. Pokiaľ je to možné, vyhnite sa jedinému, nenahraditeľnému centrálnemu mozgu; nechajte nezávislých agentov vykonávať lokalizované úlohy, aby výpadok v jednej ceste nespôsobil výpadok celej aplikácie; okrem toho, technické práce ako balanceo de carga en búsqueda distribuida para distribuir carga y reducir puntos de fallo. Simulujte zlyhania v inscenácii, aby ste potvrdili koordinačné správanie pri strese.

Pre volania modelov Vertex AI podporuje dynamické zdieľané kvóty a zriadenú priepustnosť. Zdieľané kvóty zabraňujú prísnym limitom na projekt v scenároch predplatného podľa spotreby, zatiaľ čo zriadená priepustnosť je nevyhnutná pre úlohy s vysokým QPS a citlivé na latenciu, ktoré nesmú byť obmedzené. Monitorovanie miery požiadaviek a používania tokenov vám pomáha rozhodnúť sa, kedy prejsť z kapacity na požiadanie na zriadenú kapacitu.

Kontrola nákladov do značnej miery závisí od inteligentného výberu modelu, starostlivého a rýchleho návrhu a vyhýbania sa nepotrebným tokenom. Začnite s nákladovo efektívnymi modelmi, kde je to možné, udržujte výzvy stručné, ale informatívne, explicitne požadujte krátke výstupy, keď je to možné, využívajte ukladanie kontextu do vyrovnávacej pamäte pre opakované rozsiahle výzvy a zvážte dávkovú predikciu, keď to pracovné zaťaženie umožňuje.

Ladenie zdrojov cloudového spustenia a dlhodobé zľavy ďalej optimalizujú náklady na spustenie. Začnite s predvoleným CPU/pamäťou, pozorujte skutočné využitie a upravte ho. Pri predvídateľných pracovných zaťaženiach zľavy za viazané používanie výrazne znižujú výdavky.

Z hľadiska pozorovateľnosti by ste mali vo svojej stratégii monitorovania zaobchádzať s agentmi ako s entitami prvej triedy. Zaznamenávajte ich vstupy, rozhodnutia (napr. ktoré nástroje volajú, ktorého agenta delegujú) a zmeny stavu. Na ladenie jednotlivých relácií použite grafy udalostí ADK vo webovom rozhraní a cloudové protokolovanie a vlastné dashboardy pre trendy v rámci celého vozového parku.

Ak sa tieto postupy dobre vykonajú, poskytnú vám transparentný pohľad na váš MAS: môžete vidieť, ktorí agenti sú pomalí, ktoré nástroje sa nadmerne používajú, kde sú výzvy príliš dlhé a kde sa nachádzajú slučky kontroly kvality, ako napríklad LoopAgent iterovať viac, ako sa očakávalo. Táto spätná väzba je kľúčová pre doladenie kvality aj nákladov v priebehu času.

Kombináciou primitív agentov, vzorov pracovných postupov a mechanizmov stavov od ADK s referenčnou architektúrou, bezpečnostným balíkom a operačnými nástrojmi od Google Cloud môžete navrhnúť multiagentové systémy, ktoré sú nielen inteligentné na papieri, ale aj nasaditeľné, spravovateľné a ekonomicky životaschopné v produkčnom prostredí. Počnúc jednoduchými nadradenými/podradenými agentmi a postupne cez sekvenčné, cyklické a paralelné orchestrácie získate sadu nástrojov na premenu agentických nápadov na robustné a udržiavateľné aplikácie, ktoré skutočne prinášajú obchodnú hodnotu.