Podręcznik programisty dotyczący wzorców wieloagentowych z pakietem ADK

Strona Główna » Python » Podręcznik programisty dotyczący wzorców wieloagentowych z pakietem ADK

Aplikacje agentowe szybko wychodzą poza klasyczny schemat „pojedynczego megamonitu”, a programiści potrzebują solidnego modelu mentalnego, aby móc strukturyzować wiele agentów, nie popadając w chaos. Zestaw narzędzi Google Agent Development Kit (ADK) został zaprojektowany właśnie w tym celu: umożliwia tworzenie niezawodnych systemów wieloagentowych, podłączanie narzędzi i pamięci oraz wdrażanie wszystkiego w chmurze Google Cloud z zachowaniem możliwości obserwacji, bezpieczeństwa i kontroli kosztów na poziomie produkcyjnym.

W tym przewodniku omówiono główne wzorce wieloagentowe obsługiwane przez ADK — od prostych hierarchii nadrzędny/podrzędny po agentów przepływów pracy sekwencyjnych, pętlowych i równoległych — i pokazano, jak wpisują się one w szerszą architekturę referencyjną w Google Cloud. Omówimy również współdzielony stan sesji, mechanizmy delegowania, typowe plany wieloagentowe oraz praktyczne aspekty wdrażania, zabezpieczania i obsługiwania tych systemów w rzeczywistych środowiskach.

Dlaczego w ADK stosuje się systemy wieloagentowe?

Gdy aplikacją steruje pojedynczy, monolityczny agent, szybko staje się trudno ją analizować, testować i rozwijać. Ogromne monity są delikatne, trudne do debugowania i uciążliwe w utrzymaniu w miarę wzrostu wymagań. ADK motywuje Cię do budowania System wieloagentowy (MAS) gdzie każdy agent ma skupioną odpowiedzialność, a orkiestracja jest jawna.

Strukturyzacja aplikacji w oparciu o współpracę kilku agentów zapewnia modułowość, specjalizację i możliwość ponownego wykorzystania. Możesz mieć agenta badawczego, krytyka, autora plików, routera, agenta dostępu do danych i używać ich ponownie w różnych projektach lub przepływach pracy zamiast osadzać tę samą logikę w jednym ogromnym monicie.

ADK udostępnia konkretne elementy niezbędne do realizacji tego celu: agentów skoncentrowanych na LLM, agentów przepływu pracy (sekwencyjnych, równoległych, pętlowych) oraz agentów niestandardowych, którzy hermetyzują logikę inną niż LLM. Wszystkie dziedziczą po jednym wspólnym BaseAgent, dzięki czemu można je podłączyć do tego samego modelu orkiestracji, rejestrowania, obsługi stanu i systemu narzędzi.

W miarę rozwoju systemów ten model kompozycji skaluje się lepiej niż doraźny kod orkiestracji lub głęboko zagnieżdżone łańcuchy wywołań funkcji wokół pojedynczego modelu. Utrzymujesz obciążenie poznawcze na rozsądnym poziomie: każdy agent ma jasno określone zadanie i dobrze zdefiniowaną powierzchnię interakcji z innymi.

Prymitywy ADK do tworzenia agentów

ADK udostępnia niewielki zestaw prymitywów, które można łączyć w celu tworzenia zaskakująco bogatych architektur wieloagentowych. Zrozumienie tych podstawowych koncepcji znacznie ułatwia późniejsze rozumowanie na temat wzorców wyższego poziomu.

Pierwszym prymitywem jest hierarchia agentów: każdy agent może zadeklarować listę sub_agents, tworząc drzewo z jednym root_agent na górze. Kiedy przekazujesz dzieci sub_agents, ADK automatycznie podłącza swoje parent_agent odniesienie i wymusza, aby dana instancja miała tylko jednego rodzica (w przeciwnym razie ValueError jest podniesiony).

Hierarchia ta jest czymś więcej niż tylko elementem dekoracyjnym: definiuje ona, którzy agenci mogą delegować zadania do których osób, i stanowi zakres wykorzystywany przez agentów przepływu pracy i transfery sterowane przez LLM. Z dowolnego agenta możesz przejść w górę przez agent.parent_agent lub znajdź potomków z agent.find_agent(name), co jest niezwykle przydatne przy debugowaniu.

Oprócz podstawowych agentów LLM, ADK wprowadza dedykowanych agentów przepływu pracy – SequentialAgent, ParallelAgent oraz LoopAgent – którego zadaniem nie jest „myślenie”, lecz organizowanie podagentów. Wszystkie korzystają z tego samego interfejsu, ale implementują różne strategie wykonywania: działają w kolejności, rozchodzą się równolegle lub powtarzają się w pętli z jawnymi regułami kończenia.

Trzecim podstawowym elementem pierwotnym jest warstwa komunikacyjna, skupiona na współdzielonych Session i jego state słownik. Stan sesji działa jak zwykła tablica: dowolny agent lub narzędzie może zapisywać wyniki pośrednie lub flagi, a inni agenci w tym samym wywołaniu mogą je odczytać, często za pomocą szablonów kluczy w swoich instrukcjach (na przykład {PLOT_OUTLINE?}).

Jak agenci komunikują się ze sobą w ADK

ADK obsługuje trzy uzupełniające się tryby komunikacji między agentami: współdzielony stan sesji, transfer sterowany przez LLM i jawne wywołanie za pośrednictwem AgentTool. Wybierając właściwą opcję dla każdej interakcji, sprawisz, że Twój system będzie zarówno ekspresyjny, jak i przewidywalny.

Stan sesji współdzielonej (session.state) jest najprostszym i najbardziej rozpowszechnionym mechanizmem. W ramach jednego wywołania wszyscy agenci widzą to samo Session obiekt przez InvocationContextNarzędzie lub wywołanie zwrotne może to zrobić context.state = valuei późniejszy agent może go odzyskać context.state.get("data_key"). Dla agentów LLM ustawienie output_key automatycznie zapisuje swoją ostateczną odpowiedź pod tym kluczem.

Delegowanie na poziomie LLM, czasami nazywane „przeniesieniem agenta”, pozwala LLM decydować, kiedy przekazać zadanie innemu agentowi, na podstawie instrukcji i opisów agenta. Wewnętrznie model wydaje specjalne wywołanie funkcji, takie jak transfer_to_agent(agent_name="screenwriter"). ADK-i AutoFlow przechwytuje to połączenie i przekierowuje wykonanie do wybranego agenta w zakresie dozwolonym (nadrzędny, podrzędny, rodzeństwo w zależności od konfiguracji).

Jawne wywołanie z AgentTool zapewnia bardziej kontrolowany i funkcjonalny sposób dzwonienia do jednego agenta od drugiego. Owijasz instancję agenta docelowego w AgentTool, dodaj to do numeru dzwoniącego tools listę, a LLM może następnie wybrać to narzędzie, jak każdą inną funkcję. Po wywołaniu AgentTool.run_async wykonuje podagenta, łączy stan i artefakty z powrotem i zwraca odpowiedź podagenta jako wynik narzędzia.

Te trzy kanały zaspokajają większość potrzeb związanych z obsługą wielu agentów: asynchroniczne przesyłanie danych za pośrednictwem stanu, elastyczne kierowanie za pośrednictwem transferu i ścisłe synchroniczne wywołania za pośrednictwem narzędzi. W bardziej złożonych projektach często miesza się je w ramach jednego drzewa: router, który przekazuje połączenia do elementów podrzędnych, specjalistów, którzy wykorzystują stan do komunikacji, oraz jednego lub dwóch agentów dostępnych jako narzędzia do doraźnego delegowania.

Bloki konstrukcyjne: agenci LLM, agenci przepływu pracy i agenci niestandardowi

Większość topologii MAS w pakiecie ADK to kombinacja trzech typów agentów: agentów opartych na LLM, agentów przepływu pracy i agentów niestandardowych. Każda kategoria rozwiązuje inny fragment problemu orkiestracji.

Agenci LLM łączą w sobie duży model języka i opcjonalne narzędzia, wywołania zwrotne i routing wyjściowy BaseAgent. Można je traktować jako komponenty „myślące”: interpretują one dane wprowadzane przez użytkownika, wywołują narzędzia, aktualizują stan i albo odpowiadają użytkownikowi, albo przekazują zadanie innemu agentowi.

Agenci przepływu pracy działają raczej jako menedżerowie niż pracownicy: nie rozumują samodzielnie, ale kontrolują kolejność, paralelizm i powtarzalność wykonywania zadań przez podagentów. SequentialAgent prowadzi swoje dzieci jedno po drugim, dzieląc się tym samym InvocationContext, ParallelAgent rozgałęzia się na wiele gałęzi, które dzielą stan, ale mają odrębne gałęzie historii i LoopAgent wykonuje sekwencję wielokrotnie, aż do momentu spełnienia warunku zatrzymania.

Rozszerzenie agentów niestandardowych BaseAgent z dowolną logiką inną niż LLM, gdy wbudowane strategie orkiestracji nie wystarczają. Można na przykład wdrożyć niestandardowy harmonogram, który warunkowo uruchamia agentów na podstawie metryk, lub zintegrować moduł reguł biznesowych, który określa, który podprzepływ uruchomić w zależności od ograniczeń regulacyjnych.

To połączenie podstawowych funkcji orkiestracji i wtykowej logiki sprawia, że ​​pakiet ADK nadaje się do obsługi poważnych obciążeń korporacyjnych, a nie tylko do zastosowań demonstracyjnych. Możesz zacząć od standardowych agentów przepływu pracy i dopiero gdy wymagania staną się egzotyczne, sięgniesz po nie. CustomAgent.

Stan sesji i wzorce pamięci

Stan sesji w ADK stanowi podstawę zarówno krótkotrwałej pamięci konwersacyjnej, jak i przesyłania ustrukturyzowanych danych pomiędzy agentami. Każda rozmowa wykorzystuje Session obiekt przechowujący historię wiadomości i zmienną state słownik dostępny dla wszystkich agentów w danym wywołaniu.

Zapis do stanu zwykle odbywa się wewnątrz narzędzi lub wywołań zwrotnych, przy użyciu ToolContext or CallbackContext obiekt. Na przykład narzędzie takie jak save_attractions_to_state(tool_context, attractions: List) można łączyć nowe atrakcje z tymi, które już są zapisane state, zwracając agentowi prostą wiadomość o stanie, podczas gdy ADK utrzymuje różnicę stanu w sesji.

Odczyt ze stanu odbywa się ergonomicznie dzięki kluczowym szablonom osadzonym w instrukcjach. Gdy instrukcja zawiera {my_key?}, ADK wstrzyknie state Jeśli istnieje; znak zapytania oznacza, że ​​jest opcjonalny, dzięki czemu agent nie zawiedzie w przypadku braku klucza. Jest to kluczowe w przepływach pracy takich jak „badanie → pisanie → przeglądanie”, gdzie każdy krok odczytuje to, co zapisał poprzedni krok.

Kluczowym pomysłem w przypadku pamięci konwersacyjnej w różnych turach jest ponowne wykorzystanie tych samych Session na kolejne wiadomości użytkownika zamiast za każdym razem tworzyć nową. W sesji współdzielonej agent widzi poprzednie tury i może obsługiwać pytania uzupełniające, poprawki i planowanie wieloetapowe. Jeśli przypadkowo utworzysz nową sesję w każdej turze, agent zachowuje się tak, jakby miał amnezję: nie może powiązać kolejnych tur z poprzednim kontekstem.

Stan odgrywa również dużą rolę w przepływie pracy agentów, takich jak LoopAgent, które opierają się na trwałych kluczach, takich jak liczniki, listy opinii lub flagi, aby zdecydować, czy potrzebne są dalsze iteracje. Agent krytykujący może dodawać komentarze do CRITICAL_FEEDBACK przy każdym przejściu, podczas gdy planista lub osoba dokonująca udoskonaleń odczytuje ten klucz, aby udoskonalić plan w kolejnej iteracji.

SequentialAgent: liniowe przepływy pracy przedstawione jawnie

SequentialAgent to Twój wzorzec postępowania, gdy masz do czynienia z serią kroków, które muszą wystąpić w ustalonej kolejności. Można to porównać do schematu „analiza zapytania → badanie → szkic → zapisanie do pliku” lub „określenie celu → zaplanowanie trasy → rezerwacja transportu”.

W ADK, SequentialAgent posiada listę sub_agents i uruchamia je jeden po drugim, mijając to samo InvocationContext przez cały łańcuch. Ponieważ Session oraz state są współdzielone, możesz sprawić, że pierwszy agent będzie przechowywał swój wynik pod output_key="destination" a następny agent przeczytał to przez {destination} w instrukcji bez żadnego kodu kleju.

Klasycznym przykładem jest generator propozycji filmowych: główny agent powitalny rozmawia z użytkownikiem, a następnie przekazuje pracę SequentialAgent wzywa się najpierw badacza, potem scenarzystę, a potem autora plików. Użytkownik widzi tylko ostateczny wynik, ale wykres zdarzeń w ADK Web ukazuje wewnętrzne drzewo: greeter → film_concept_team → .

W porównaniu do ręcznej orkiestracji z jawnymi if/elif bloki i wywołania funkcji, SequentialAgent zachowuje deklaratywny charakter przepływu sterowania i minimalizuje ilość szablonów. Deklarujesz sekwencję raz i traktujesz ją jako pojedynczego wywoływalnego agenta w swoim programie uruchamiającym lub interfejsie użytkownika, jednocześnie wykorzystując stan sesji do przesyłania danych między krokami.

Sekwencyjne przepływy pracy dobrze łączą się także z innymi agentami przepływu pracy: można osadzić pętlę lub równoległe rozgałęzienie jako jeden z kroków dłuższego łańcucha. W ten sposób powstają bardziej zaawansowane procesy, takie jak „weryfikacja jakości historii, następnie analiza box office’u i obsady, a na końcu spisanie skonsolidowanego raportu”.

LoopAgent: iteracyjne udoskonalanie i pokoje pisarzy

LoopAgent jest przeznaczony do zadań wymagających kilku przebiegów pracy aż do osiągnięcia progu jakości. Zamiast pojedynczego podejścia „wygeneruj raz i miej nadzieję na najlepsze”, możesz wdrożyć proces składania propozycji, krytyki i udoskonalania.

Typowa konfiguracja pętli obejmuje agentów, takich jak badacz, generator (np. scenarzysta) i krytyk, którzy współpracują w wielu rundach. W każdej iteracji badacz może aktualizować fakty dotyczące tła, scenarzysta dostosowuje zarys lub plan, a krytyk ocenia wszystko w oparciu o wyraźne wytyczne, decydując, czy konieczne są kolejne iteracje.

Pętle zatrzymują się w dwóch warunkach: po osiągnięciu max_iterations lub podagent sygnalizujący, że praca została wykonana. ADK udostępnia wbudowane narzędzie, takie jak exit_loop do którego krytyk może zadzwonić, gdy plan, zarys lub projekt spełni wymagania jego wewnętrznej listy kontrolnej. LoopAgent szanuje również escalate=True flaga w Event działania, dając Ci kolejny sposób na wcześniejsze wyjście.

Kluczowy jest tutaj trwały stan sesji: agenci odczytują klucze takie jak PLOT_OUTLINE, research or CRITICAL_FEEDBACK i pisać ulepszone wersje lub dodatkowe komentarze na temat każdego przejścia. Ten schemat w praktyce symuluje „pokój scenarzystów”, w którym specjaliści wymieniają się pomysłami, krytykują i dopracowują tekst, aż ktoś uzna dzieło za gotowe.

Poprzez połączenie LoopAgent w SequentialAgent, możesz umieścić całą pętlę iteracyjną jako tylko jeden krok w większym, kompleksowym przepływie pracy. Na przykład, writers_room (LoopAgent) może zostać uruchomiony jako pierwszy, aby wygenerować solidny zarys fabuły, po czym file_writer agent zapisuje wynik i dołącza inne raporty.

ParallelAgent: rozgałęzianie i gromadzenie zadań niezależnych

ParallelAgent wdraża klasyczny wzorzec „rozdzielania/zbierania” dla zadań, które są niezależne, ale współdzielą kontekst. Zamiast wykonywać N kroków badawczych jeden po drugim, wykonujesz je wszystkie naraz i czekasz, aż wszystkie się zakończą, a następnie agregujesz ich wyniki.

Wewnętrznie, ParallelAgent nadaje każdemu podagentowi odrębny InvocationContext.branch - lubić ParentBranch.ChildName – nadal dzieląc to samo session.state. Oznacza to, że wszyscy potrafią odczytać początkowy kontekst, taki jak PLOT_OUTLINE, ale powinien zapisywać dane wyjściowe do odrębnych kluczy stanu (na przykład box_office_report, casting_report) aby uniknąć konfliktów.

Typowym przykładem jest „zespół przedprodukcyjny” przygotowujący propozycję filmową: jeden agent szacuje potencjał kasowy na podstawie porównywalnych filmów, drugi proponuje opcje obsady, obie realizowane równolegle. Kolejny file_writer następnie tworzy raport, używając kluczowych szablonów dla każdego podwyniku i zapisuje go na dysku.

Równoległe przepływy pracy znacznie zmniejszają opóźnienia w przypadku szerokich zapytań i scenariuszy analiza danych w czasie rzeczywistym:jeśli potrzebujesz sugestii odnośnie muzeów, opcji koncertów czy pomysłów na restauracje na weekend, kontakt z trzema specjalistycznymi agentami równolegle jest szybszy niż wysyłanie zapytań po kolei. Po zakończeniu przetwarzania agent syntezy odczytuje wszystkie wyniki ze stanu i generuje ujednoliconą odpowiedź dla użytkownika.

Równoległe kroki są prawie zawsze osadzone wewnątrz SequentialAgent który najpierw przygotowuje kontekst, a następnie uruchamia ParallelAgent, a następnie kontynuuje agregację i raportowanie. Ten wzorzec będzie łatwy do rozpoznania i ponownego wykorzystania, gdy już zapoznasz się z agentami przepływu pracy ADK.

Wzorce orkiestracji z prymitywami ADK

Po zrozumieniu hierarchii, agentów przepływu pracy i stanu można wdrożyć kilka klasycznych wzorców wieloagentowych bezpośrednio w pakiecie ADK. Wzorce te nie są zakodowanymi na stałe prymitywami, lecz kompozycjami zbudowanymi z tych samych podstawowych elementów.

Wzorzec koordynatora/dyspozytora wykorzystuje centralnego agenta LLM jako „routera” dla zapytań użytkowników, wspieranego przez wielu wyspecjalizowanych podagentów. Koordynator odczytuje żądanie, a następnie przekazuje kontrolę podagentowi za pośrednictwem delegacji opartej na LLM lub dzwoni do specjalistów w sposób jawny za pomocą AgentToolTypowymi przykładami są agenci zajmujący się jedzeniem, transportem lub przewodnikami weekendowymi.

Sekwencyjny wzorzec potoku to po prostu SequentialAgent których dzieci wdrażają szczegółowo określony etap procesu. Przepływy generatora i krytyka to klasyczna odmiana: pierwszy agent pisze wersję roboczą i zapisuje ją pod output_key, drugi agent analizuje je i zapisuje opinię, a trzeci agent może dopracować wynik na podstawie tej opinii.

Wzór równoległego rozprowadzania/zbierania jest wyrażony jako ParallelAgent zagnieżdżone w sekwencyjnym przepływie pracy. Równoległe dzieci zapisują wyniki w oddzielnych kluczach stanu; późniejszy agent syntezatora odczytuje je i przedstawia połączoną odpowiedź.

Hierarchiczny podział zadań następuje naturalnie na podstawie drzewa nadrzędny/podrzędny. Agenci wyższego poziomu dzielą cele na podcele i delegują je do celów podrzędnych (poprzez delegowanie lub narzędzia), a wyniki są przekazywane w górę drzewa. Jest to szczególnie przydatne w przypadku asystentów badawczych, optymalizatorów łańcucha dostaw lub systemów doradztwa finansowego, gdzie każda poddomena ma własnego agenta specjalistycznego.

Iteracyjne udoskonalanie z LoopAgent formalizuje pętlę generator-krytyk w sposób umożliwiający ponowne wykorzystanie. Pętla wykonuje agentów planisty, krytyka i rafinera wielokrotnie, używając kluczy stanu do zapisania najnowszego planu i odpowiadającej mu informacji zwrotnej, zatrzymując się po osiągnięciu kryterium jakości lub limitu iteracji.

Architektura referencyjna dla systemów wieloagentowych w Google Cloud

Oprócz logiki agenta nadal musisz gdzieś uruchomić swój system, a Google Cloud oferuje dobrze zdefiniowaną architekturę referencyjną na potrzeby wdrożeń wieloagentowych klasy produkcyjnej. Ogólnie rzecz biorąc, rozwiązanie łączy w sobie front-end, środowiska uruchomieniowe agentów, modele Vertex AI, usługi bezpieczeństwa i opcjonalne struktury narzędzi, takie jak MCP.

Typowa konfiguracja zaczyna się od front-endu – często interfejsu czatu – uruchomionego na platformie Cloud Run. Użytkownicy komunikują się z tym interfejsem użytkownika, który przekazuje żądania do agenta koordynatora, udostępnianego jako usługa. Koordynator następnie wybiera między różnymi przepływami pracy agenta w oparciu o intencje użytkownika, w tym opcjonalnymi ścieżkami z udziałem człowieka, gdzie użytkownicy mogą weryfikować lub ignorować decyzje agenta.

Agenci mogą działać w różnych środowiskach: usługach Cloud Run, Google Kubernetes Engine (GKE) lub Vertex AI Agent Engine. ADK obejmuje te opcje, abstrahując od niektórych szczegółów środowiska wykonawczego, dzięki czemu programista może skupić się na logice agenta, a nie na funkcjonowaniu infrastruktury.

Wszystkie wywołania agentów wykorzystują Vertex AI lub inne środowiska uruchomieniowe modeli do wnioskowania, często w pakiecie z Model Armor w celu oczyszczania monitów i odpowiedzi. Model Armor pomaga filtrować próby wstrzyknięcia kodu, wycieki poufnych danych lub szkodliwe treści przed lub po wywołaniu modelu, działając jako bariera zabezpieczająca wokół komponentów generatywnych.

Narzędzia i serwery MCP (Model Context Protocol) wkraczają do akcji, gdy agenci muszą komunikować się z systemami zewnętrznymi – bazami danych, systemami plików lub interfejsami API SaaS – w ujednolicony sposób. MCP definiuje wspólną umowę między agentem a serwerem narzędzi, dzięki czemu pojedynczy klient MCP w agencie może uzyskać dostęp do wielu narzędzi opracowanych przez różne zespoły bez ścisłego powiązania. systemy przechowywania danych y cómo exponerlos de forma segura.

Bezpieczeństwo i zarządzanie aplikacjami agentowymi

Systemy agentowe stwarzają wyzwania w zakresie bezpieczeństwa wykraczające poza kwestie związane z tradycyjnymi mikrousługami, ponieważ systemy LLM można oszukać i nakłonić do niewłaściwego użycia narzędzi lub wycieku danych, jeśli nie zachowa się ostrożności. Zalecane przez Google podejście łączy deterministyczne kontrole bezpieczeństwa z mechanizmami obronnymi opartymi na zasadach LLM. limites, sesgos y riesgos de los modelos al diseñar estas defensas.

Nadzór ludzki nadal ma kluczowe znaczenie: przepływy o dużym wpływie powinny obejmować etapy zatwierdzania, w których człowiek może wstrzymać, przejrzeć lub zawetować proponowane działanie agenta. Można to zmodelować jako dedykowane narzędzie „potwierdzania przez człowieka”, które wyświetla żądania w interfejsie użytkownika i wznawia wykonywanie dopiero po udzieleniu odpowiedzi przez człowieka.

Kontrola dostępu agentów odbywa się za pośrednictwem IAM: każdy agent lub konto usługi powinno mieć tylko minimalne uprawnienia wymagane do wykonywania swoich obowiązków. Jeśli dany agent zostanie naruszony lub użyty niewłaściwie, promień rażenia zostanie ograniczony, ponieważ jego konto usługi nie będzie miało dostępu do niepowiązanych zasobów ani narzędzi.

Bramkowanie narzędzi oparte na zasadach, wdrażane przy użyciu komponentów takich jak SecurityPlugin plus PolicyEngine, umożliwia żądanie potwierdzenia przez użytkownika przed uruchomieniem niektórych narzędzi. Gdy polityka oznaczy wrażliwe wywołanie, wtyczka przechwytuje je, emituje specjalne wywołanie funkcji „prośby o potwierdzenie” i czeka na odpowiedź aplikacji, skutecznie włączając człowieka do pętli w przypadku operacji wysokiego ryzyka.

Obrazu dopełniają standardowe funkcje zabezpieczeń Google Cloud: VPC Service Controls redukujące ryzyko wycieku danych, CMEK do kluczy szyfrujących zarządzanych przez klienta, Cloud Armor do ochrony WAF i DDoS, IAP lub Identity Platform do uwierzytelniania użytkowników oraz szczegółowe IAM do dostępu do zasobów. Do komunikacji między agentami za pośrednictwem protokołu A2A w środowisku produkcyjnym wymagane lub zalecane jest uwierzytelnianie oparte na protokole TLS 1.2+ i OAuth.

Niezawodność, obserwowalność i optymalizacja kosztów

Wdrożenia produkcyjne MAS muszą być niezawodne, możliwe do zaobserwowania i opłacalne; ADK dobrze integruje się z narzędziami operacyjnymi Google Cloud, aby to umożliwić. Można instrumentować agentów, sesje i narzędzia w taki sposób, aby ich logi i ślady były widoczne w Cloud Logging i Cloud Trace.

Z punktu widzenia niezawodności zaprojektuj graf agenta tak, aby tolerował awarie poszczególnych komponentów. W miarę możliwości należy unikać pojedynczego, niezastąpionego centralnego mózgu; należy pozwolić niezależnym agentom wykonywać zlokalizowane zadania, aby awaria na jednej ścieżce nie spowodowała awarii całej aplikacji; pracownicy techniczni powinni być tak samo Balanceo de carga en búsqueda distribuida para distribuir carga y reducir puntos de fallo. Symuluj niepowodzenia w fazie etapowej, aby zweryfikować zachowanie koordynacji pod wpływem stresu.

W przypadku wywołań modeli Vertex AI obsługuje dynamiczne współdzielone kwoty i przydzieloną przepustowość. Współdzielone limity pozwalają uniknąć sztywnych limitów na projekt w scenariuszach płatności za rzeczywiste wykorzystanie, a gwarantowana przepustowość jest niezbędna w przypadku obciążeń o wysokiej liczbie zapytań na sekundę (QPS) i wrażliwych na opóźnienia, których nie wolno ograniczać. Monitorowanie liczby żądań i wykorzystania tokenów pomaga zdecydować, kiedy przejść z pojemności na żądanie na gwarantowaną.

Kontrola kosztów w dużej mierze zależy od mądrego wyboru modelu, ostrożnego i szybkiego projektowania oraz unikania zbędnych tokenów. Zacznij od ekonomicznych modeli, jeśli to możliwe, zadbaj o to, aby monity były zwięzłe, ale treściwe, proś o krótkie wyniki, gdy to możliwe, wykorzystuj buforowanie kontekstu w przypadku powtarzających się, obszernych monitów i rozważ predykcję wsadową, gdy obciążenia na to pozwalają.

Optymalizacja zasobów Cloud Run i długoterminowe rabaty dodatkowo optymalizują koszty środowiska uruchomieniowego. Zacznij od domyślnego procesora/pamięci, obserwuj rzeczywiste wykorzystanie i dostosuj. W przypadku przewidywalnych obciążeń, rabaty za zaplanowane wykorzystanie znacząco obniżają wydatki.

Jeśli chodzi o możliwość obserwacji, w ramach strategii monitorowania należy traktować agentów jako jednostki pierwszej klasy. Rejestruj ich dane wejściowe, decyzje (np. z jakich narzędzi korzystają, do którego agenta delegują) i zmiany stanu. Korzystaj z wykresów zdarzeń ADK w interfejsie internetowym do debugowania poszczególnych sesji, a także z funkcji Cloud Logging i niestandardowych pulpitów nawigacyjnych do śledzenia trendów w całej flocie.

Dobrze wykonane praktyki zapewniają przejrzysty obraz systemu MAS: można zobaczyć, którzy agenci są powolni, które narzędzia są nadużywane, gdzie monity są zbyt długie i gdzie występują pętle kontroli jakości, takie jak LoopAgent powtarzać więcej niż oczekiwano. Ta pętla sprzężenia zwrotnego jest kluczowa dla udoskonalenia zarówno jakości, jak i kosztów w dłuższej perspektywie.

Łącząc prymitywy agentów, wzorce przepływu pracy i mechanizmy stanu pakietu ADK z referencyjną architekturą, stosem zabezpieczeń i narzędziami operacyjnymi Google Cloud, można projektować systemy wieloagentowe, które są nie tylko inteligentne na papierze, ale także łatwe do wdrożenia, zarządzania i ekonomicznie opłacalne w środowisku produkcyjnym. Zaczynając od prostych agentów nadrzędnych/podrzędnych i przechodząc przez orkiestracje sekwencyjne, pętlowe i równoległe, zyskujesz zestaw narzędzi do przekształcania pomysłów agentowych w solidne, łatwe w utrzymaniu aplikacje, które faktycznie przynoszą wartość biznesową.