Zespoły agentów Claude Code: Kiedy używać wielu agentów i jak to zrobić

Zaawansowane zespoły agentów, które mogą ze sobą komunikować się w ekosystemie Claude Code, są już dostępne, a ich ukończona wersja może dobrze funkcjonować. Jednak uruchomienie takiego systemu jest trudniejsze, niż się wydaje, a wielu ludzi angażuje się w prace z takimi zespołami bez rozważenia konsekwencji. Zespoły agentów wydają się oczywistym krokiem naprzód, gdy tylko podagenty zaczną sprawnie działać. W rzeczywistości tak nie jest automatycznie. Zespół to warstwa koordynacyjna, która wiąże się z rzeczywistymi kosztami w postaci tokenów, określonymi sposobami awarii oraz ograniczonym zakresem problemów, które potrafi skutecznie rozwiązywać.

Najmniej efektowna lekcja wynikająca z miesięcy rzeczywistego stosowania systemów wielu agentów jest jednocześnie najprzydatniejsza: zacznij od dobrze skonfigurowanego agenta, dobrych narzędzi oraz zdyscyplinowanego zarządzania kontekstem. Dodawaj kolejne agenty tylko wtedy, gdy masz konkretny powód. Wskazówki Anthropic dotyczące tworzenia skutecznych agentów mówią to samo, zalecając zespołom szukanie najprostszej możliwej rozwiązania i dodawanie złożoności wyłącznie wtedy, gdy jest to konieczne.

Poniżej znajduje się sposób na przemyślenie tej decyzji oraz kroki do podjęcia po jej podjęciu. Zakłada on, że znasz subagenty, różnice między nimi a umiejętnościami oraz to, dlaczego izolacja kontekstu jest głównym powodem ich stosowania. Otwartym pytaniem pozostaje to, kiedy jeden subagent przekazujący informacje nie jest już wystarczający i co należy zbudować w jego miejsce.

Materiał obejmuje następujące obszary:

• Dlaczego większość zespołów nie potrzebuje jeszcze kilku agentów oraz typowy błąd polegający na wyborze zespołów tylko dlatego, że wydają się potężniejsze.
• Cztery konkretne sygnały wskazujące, że jeden agent ma już ograniczone możliwości.
• Cztery wzorce łączenia agentów w taksonomii neutralnej pod względem dostawcy: orkiestrator, pipeline, specjaliści równolegli i rój.
• Stack Anthropic dla zespołów agentów, który oddziela to, co stabilne, od tego, co eksperymentalne lub dostępne tylko w wersji przeglądowej.
• Czym są zespoły agentów Claude Code i w czym różnią się one od subagentów.
• Jak agenty komunikują się ze sobą: trzy formy, cztery wzorce czasowe oraz co należy przekazywać między nimi.
• Osiem sposobów awarii wraz z praktycznymi metodami ich łagodzenia.
• Ramy decyzyjne dotyczące wyboru między orkiestracją natywną, samodzielną a hybrydową.

Większość zespołów nie potrzebuje więcej niż jednego agenta

Wielu ludzi, którzy szukają zespołów agentów, rozwiązuje niewłaściwy problem. Powszechnym uzasadnieniem jest to, że subagenci sprawdzili się, system staje się coraz bardziej skomplikowany, więc zespoły są następnym krokiem. Ta logika myli możliwości z złożonością. Zespół nie czyni systemu bardziej zdolnym; sprawia, że staje się on bardziej rozproszony, a rozproszenie to koszt, a nie ulepszenie.

Post firmy Anthropic na temat tworzenia skutecznych agentów szczegółowo opisuje aspekty ekonomiczne. Przepływy pracy, które nie wykorzystują agentów, są bardziej przewidywalne, tańsze i łatwiejsze do debugowania, a rada sprowadza się do tego: gdy zwykła funkcja może wykonać zadanie, należy napisać tę funkcję zamiast zwoływać komitet z rozkładów prawdopodobieństwa. Ten punkt jest łatwy do przeoczenia przez osoby, które nie zdają sobie sprawy, że modele językowe są probabilistyczne. Nawet wyraźna instrukcja może być lub nie być poprawnie wykonana. Każdy dodany agent to kolejny komponent, który może zawieść, tworzyć halucynacje lub wytwarzać dane, które następny agent błędnie zinterpretuje, więc dodawanie agentów zwiększa szanse na błędy w skali masowej.

Granica możliwości pojedynczego agenta jest wyższa, niż ludzie przypuszczają. Agentowi wyposażonemu we odpowiednie narzędzia, precyzyjne instrukcje, uporządkowaną delegację ciężkich zadań na podagenty oraz staranną obsługę kontekstu można powierzyć zaskakująco dużą ilość pracy. Granica ta zostaje osiągnięta, gdy zachodzi przynajmniej jedna z czterech sytuacji:

1. Praca jest zbyt obszerna dla jednego okna kontekstowego, nawet przy delegacji na podagenty.
2. Różne części wymagają zupełnie innych specjalizacji, co oznacza różny dostęp do narzędzi i ograniczenia behawioralne, a nie tylko różne instrukcje.
3. Część pracy może być wykonywana równolegle, a czas trwania ma znaczenie.
4. Jakość wyniku wymaga niezależnej oceny, na przykład przez drugiego agenta, który nie widział rozumowania pierwszego.

Żadne z nich nie stanowi stwierdzenia dotyczącego możliwości. Wszystkie odnoszą się do architektury. Gdy stosuje się dodatkowe agenty, jest to uzasadnione. Gdy tego nie robi się, one jedynie powodują opóźnienia, a jeśli nie można wskazać konkretnego przypadku, opcja jednego agenta pozostaje otwarta.

Cztery czynniki wyzwalające, z przykładami

Izolacja kontekstu. Załóżmy, że zadanie polega na czytaniu dziesiątek plików, przeprowadzaniu rozległych wyszukiwań i przechowywaniu dużych tymczasowych wyników, z których żaden nie musi pozostać w głównej sesji. To może obsłużyć podagent. Ale jeśli badanie jest tak rozległe, że wypełnia nawet kontekst podagenta, lub zadanie dzieli się na niezależne, równoległe badania, konieczne są liczne agenty. To najczęstszy uzasadniony czynnik wyzwalający.

Specjalizacja. Ta praca wymaga czegoś więcej niż zwykłych instrukcji; potrzebuje dostępu do różnych narzędzi oraz odmiennych ograniczeń behawioralnych. Przeglądający kod, który nie potrafi tworzyć plików ani uruchamiać poleceń w shellu, ma zupełnie inny profil ryzyka niż generator kodu. Mimo to różnice te często można zapisać jako odrębne podagenty, z których każdy ma swój własny prompt systemowy oraz ograniczony zestaw narzędzi, więc sama specjalizacja nie powinna być powodem przechodzenia do zespołów. Sama dokumentacja dotycząca agentów-zespołów wskazuje, że to właśnie tutaj podagenty sprawdzają się najlepiej: izolowane konteksty, streszczenia przekazywane osobie, która je wywołała, oraz instrukcje specyficzne dla danej zadania.

Praca równoległa. Zadanie dzieli się na niezależne podzadania, które nie mają wspólnego stanu zmiennej: trzy agenty jednocześnie badające różne aspekty błędu w bazie kodu lub cztery agenty, z których każdy przegląda inny rozdział dokumentu. To właśnie w takich sytuacjach systemy wieloagentowe przynoszą rzeczywiste oszczędności czasu, ponieważ agenci działają jednocześnie. Kosztem jest większa liczba tokenów, więc taka transakcja jest opłacalna tylko wtedy, gdy czas spędzony ma większe znaczenie niż wydane środki.

Niezależna ocena. Wynik musi zostać sprawdzony przez drugą opinię, która nie była zaburzona rozumowaniem pierwszej. Wyobraź sobie oceniacza, który czyta tylko ostateczny wynik, a nie żadne uzasadnienie za nim, albo agenta z zespołu atakującego, który szuka wad zamiast weryfikować twierdzenia. To właśnie leży u podstaw systemu badawczego Anthropic opartego na wielu agentach, w którym równolegle działają podagenty badające różne aspekty, a główny agent syntetyzuje informacje niezależnie.

Gdy jedno z tych stwierdzeń jest wyraźnie prawdziwe i można określić, które to, dodawanie agentów uzasadnia swoją cenę.

Cztery sposoby łączenia agentów

Załóżmy, że decyzja została podjęta. Badania szybko ujawniają zamieszanie, ponieważ poszczególne laboratoria na froncie rozwinęły wzorce wieloagentowe w różny sposób, chociaż istnieją kilka wspólnych elementów. Poniżej znajduje się syntetyczna taksonomia opracowana na podstawie dokumentacji dotyczącej procesu pracy Anthropic oraz doświadczeń zespołu inżynierskiego w praktyce. Nie jest to oficjalna klasyfikacja Anthropic; jest to podsumowanie analityczne odnoszące się do tego, co opisują te źródła.

Sekwencyjny pipeline

Agenty lub etapy są wykonywane w ustalonej kolejności, a późniejsze etapy wykorzystują wyniki wcześniejszych. Ze wszystkich czterech ten jest najłatwiejszy do wyjaśnienia inżynierom, ponieważ przypomina zwykłe oprogramowanie: najpierw badania, potem synteza, następnie opracowanie projektu i krytyka, a na końcu wydobywanie informacji oraz weryfikacja.

Jego zaletą są wyraźne umowy pomiędzy poszczególnymi etapami. Jego wadą są błędy kaskadowe, ponieważ błąd podczas wyodrębniania danych na pierwszym etapie może spowodować błędy w późniejszych etapach, co wiąże się z dużymi kosztami. Bramy walidacyjne pomiędzy etapami są obowiązkowe, ponieważ zapobiegają dalszemu postępowaniu procesu w niewłaściwym kierunku. Najlepszymi bramami są schematy umów JSON oraz inne elementy, które zachowują ciągłość procesu podczas jego wykonywania.

Centralny orkiestrator lub planer-wykonawca

Główny agent dzieli zadanie na części, deleguje je pracownikom i łączy uzyskane wyniki. Pracownicy nie koordynują się między sobą; składają raporty bezpośrednio do orkiestratora. Jest to najczęstszy i najpraktyczniejszy standard. Używaj go wtedy, gdy struktura podzadań nie jest znana z góry, ale ważna jest jasna odpowiedzialność na najwyższym poziomie. Funkcja Research w Anthropicie działa dokładnie według tej zasady: główny agent analizuje zapytanie, uruchamia równolegle specjalistyczne podagenty, a następnie łączy uzyskane informacje.

Nie używaj jej, jeśli proces pracy jest już na tyle ustalony, że można go zapisać w postaci skryptu – w takim przypadku pipeline będzie prostszy i bardziej przewidywalny.

Jego charakterystycznym problemem jest awaria orkiestratora: lider, którego instrukcje delegacji są niejasne, zmusza pracowników do powtarzania wzajemnych poszukiwań, pomijania granic lub tworzenia wyników, które nie pasują do siebie. Rozwiązaniem jest przyznanie każdemu pracownikowi celu, określonego formatu wyniku, wskazówek dotyczących źródeł oraz jasnych granic zadań.

Specialiści pracujący równolegle, debaty i zespół atakujący

Tutaj kilku agentów podejmuje się tego samego zadania lub sąsiadujących z nim podzadań jednocześnie, a ich wyniki są następnie głosowane, krytykowane lub agregowane. Metoda ta nadaje się w sytuacjach, gdy odporność jest ważniejsza niż schludność: konkurencyjne wyjaśnienia błędu, adwersarialna ocena decyzji politycznej, analiza bezpieczeństwa z różnych perspektyw.

Koszt jest oczywisty. Więcej agentów oznacza znacznie więcej tokenów, większą ilość pracy związanej z agregacją oraz ryzyko fałszywej pewności siebie wynikającej z konsensusu. Podobno system badawczy Anthropic musiał wprowadzić budżety nakładów pracy oraz bardziej precyzyjną delegację, aby zapobiec rozproszeniu pracowników bez żadnej dyscypliny. Używaj tego podejścia tylko wtedy, gdy dziedzina naprawdę tego wymaga.

Rój, czyli zdecentralizowany wspólny kontekst

Koordynacja powstaje z powodu wspólnego stanu, wspólnych wątków komunikacyjnych lub zmian w środowisku, a nie dzięki ściśle określonemu liderowi. W tym przypadku systemy wieloagentowe zaczynają przekształcać się w systemy rozproszone, co niesie ze sobą takie problemy jak niejasna przynależność własności, sytuacje wyścigu zegara dotyczące wspólnego stanu oraz trudności w debugowaniu. Nadaje się to do naprawdę otwartych problemów, w których agenci muszą współpracować pomimo różnic w sesjach lub czasie działania. Unikaj go tam, gdzie potrzebna jest prosta rozliczalność lub ścisłe przestrzeganie zasad.

Dla większości praktyków pierwsze dwa wzorce obejmują niemal wszystko.

Co oferuje obecnie Anthropic

Zanim zbudujesz własny zestaw narzędzi, warto sprawdzić, co Anthropic już dostarcza oraz czego uczą jego rozwiązania. Istnieje kilka sposobów na wykonywanie zadań agentywnych, a one nie są wzajemnie zamienne. Wyobraź sobie drabinę prowadzącą od surowego sterowania do zarządzania przez platformę. Obraz poniżej przedstawia sytuację z około kwietnia 2026 roku, a te produkty szybko się zmieniają.

1. Messages API. Masz pełną kontrolę nad całym procesem. Choć istnieją narzędzia pomocnicze, to ty piszesz logikę wykonywania zadań, a nie ma wbudowanego wsparcia dla wielu agentów. To najbardziej elastyczny poziom, ale też wymagający najwięcej pracy.

Claude Agent SDK. Pętla agenta, narzędzia, obsługa kontekstu, podagenty, hooki oraz śledzenie kosztów pochodzą od Anthropic, ale działają na infrastrukturze, którą sam zarządzasz. Podagenty są wbudowane, a wszystko, co dotyczy wielu agentów, jest w większości wynikiem twojego projektu. Autoryzacja odbywa się za pośrednictwem Bedrock, Vertex AI i Azure Foundry, więc to najbardziej przenośny poziom.

Claude Managed Agents. Anthropic zarządza dla ciebie środowiskiem działania: kontenerami, procesem kompresji, buforowaniem promptów, historią zdarzeń, sesjami z stanem oraz zestawem wbudowanych narzędzi. Zastosowanie pojedynczego agenta jest już rozwinięte, natomiast sesje wielu agentów znajdują się w oddzielnym, dostępnym tylko w wersji przeglądowej rozwiązaniu.

Zarządzane agenty wieloagentowe. Wersja robocza przeznaczona do badań, dostępna tylko z ograniczeniami; projekt obsługuje wyłącznie jeden poziom koordynatora. Koordynator może wzywać inne agenty, ale te z kolei nie mogą wzywać kolejnych agentów. To jest orkiestracja wieloagentowa, choć jeszcze nie stanowi ogólnej, rekurencyjnej struktury społeczności agentów.

Podagenty Claude Code. Izolowane konteksty robocze w ramach jednej głównej sesji, które przekazują wyniki z powrotem. To oficjalna funkcja, ale nie dotyczy zespołów typu peer-to-peer.

Zespoły agentów Claude Code. Od aktualizacji z kwietnia 2026 roku funkcja ta jest eksperymentalna i domyślnie wyłączona; można ją włączyć za pomocą specjalnej zmiennej środowiskowej. Do znanych ograniczeń należą zachowanie przy wznowieniu sesji, przypadki krawędziowe w koordynacji zadań oraz sesje wznowione, które odnoszą się do członków zespołu, którzy już nie istnieją.

W praktyce stwierdzenie „Claude wspiera zespoły agentów” jest prawdziwe, natomiast „Claude oferuje orkiestrację wielu agentów o poziomie produkcyjnym i uniwersalnego zastosowania na każdej platformie” nie jest prawdziwe.

Zespoły agentów Claude Code w praktyce

• Podagenty działają w ramach jednej głównej sesji. Główna instancja Claude Code je tworzy, każdy z nich pracuje samodzielnie w swoim własnym oknie kontekstowym i wysyła wyniki z powrotem; to ty zajmujesz się orkiestracją, a główna sesja nigdy nie przyswaja pracy wykonywanej w celu uzyskania wyniku.

Zespoły agentów to oddzielne sesje Claude Code, które ze sobą komunikują się. Każdy członek zespołu ma własne okno kontekstu i stan sesji, a także wspólną listę zadań oraz skrzynkę pocztową do przesyłania wiadomości bezpośrednich. Członkowie zespołu mogą przekazywać sobie zadania i koordynować działania bez konieczności czekania, aż lider przekaże każdą instrukcję. Lider określa kierunek działań, a członkowie zespołu mogą na nie reagować i rozmawiać między sobą.

Konfiguracja

1. Konfiguracja zespołu znajduje się w pliku ~/.claude/teams/{name}/config.json.
2. Wspólna lista zadań znajduje się w katalogu ~/.claude/tasks/{name}/.
3. Członkowie zespołu są definiowani w plikach agentów wielokrotnego użycia, czyli w istocie definicjach podagentów, którym przypisane są role członków zespołu.
4. Hooki mogą pełnić rolę bramek jakościowych pomiędzy przechodzeniami między zadaniami.

Dwa aspekty architektury są istotne dla projektu. Po pierwsze, podagenty mogą mieć własną pamięć automatyczną. To ułatwia specjalizację, ale gdy praca jest rozdzielona między kilka agentów z odrębnymi pamięciami, trzeba podjąć decyzję architektoniczną dotyczącą tego, która wiedza pozostanie lokalna, która będzie udostępniana, a która zostanie podsumowana. To jest pytanie z zakresu projektowania systemu.

Po drugie, dokumentacja jasno wskazuje, kiedy zespoły radzą sobie gorzej niż podagenty: przy zadaniach sekwencyjnych, edycjach tego samego pliku oraz pracy z wieloma zależnościami między poszczególnymi krokami. Jeśli agenci muszą przekazywać ten sam produkt kolejno, bez pracy równoległej, podagenty w pipeline sekwencyjnym są prostsze i bardziej przewidywalne.

Ponieważ zespoły były wtedy nadal eksperymentalne i domyślnie wyłączone, włączaj je tylko z wyraźnego powodu z powyższej listy i spodziewaj się niedoskonałości.

Jak agenci ze sobą komunikują się

Komunikacja między agentami jest często traktowana jako problem związany z formułowaniem zapytań. Na większą skalę jest to problem systemowy. Istnieją trzy główne formy takiej komunikacji.

1. Wiadomości w języku potocznym. Najbardziej oczywista forma, ale najmniej niezawodna w dużych skali. Członkowie zespołu Claude Code komunikują się ze sobą bezpośrednio przez skrzynkę pocztową. Jest to elastyczne rozwiązanie, ale język naturalny jest mniej precyzyjny niż strukturyzowane zapytania, co stwarza większe ryzyko błędnej interpretacji między agentami.
2. Strukturyzowane zapytania. Definicje narzędzi w formacie JSON Schema oraz ścisłe przestrzeganie zasad ich używania. Definicje narzędzi dostarczane przez Anthropic gwarantują, że argumenty są zgodne ze schematem. Ta warstwa sprawia, że komunikacja między agentem a narzędziem jest niezawodna, a ten sam mechanizm sprawia, że połączenia między agentami stają się bardziej precyzyjne, gdy są modelowane jako zapytania do narzędzi zamiast wiadomości w formie otwartej.

Wspólny stan lub artefakty. Najmniej doceniana forma. W opracowaniu badawczym Anthropic dotyczącym wielu agentów zaleca się, aby podagenty zapisywały wyniki do systemu plików lub zewnętrznego systemu i zwracały lekkie odniesienia, zamiast kierować wszystko przez kontekst głównego agenta. Powód jest prosty: plik można audytować, wersjonować i badać bezpośrednio, natomiast wiadomość podsumowująca plik może nie spełniać żadnej z tych cech.

Czas jest równie ważny jak format. Wyróżnia się cztery wzorce:

• Wezwania synchroniczne. Menedżer dzwoni do specjalisty, czeka, a następnie kontynuuje. Łatwe do zrozumienia, ale mogą stanowić wąskie gardło. Zgodnie z doniesieniami, zespół badawczy Anthropic stwierdził, że synchroniczna realizacja przez głównego agenta była blokowana przez wolne agenty, dlatego odrzucono możliwość kierowania procesem w trakcie jego trwania.

Sekwencyjne przekazywanie obowiązków. Odpowiedzialność przechodzi od jednego agenta do następnego – jeden tworzy wynik, a drugi go przejmuje. OpenAI wyraźnie rozróżnia dwa takie podejścia: przy przekazywaniu obowiązków specjalista bierze na siebie odpowiedzialność za dalsze działania, natomiast agent używany jako narzędzie pozostawia decyzje menedżerowi. To, kto jest odpowiedzialny, zależy od wybranego sposobu.

Prowadzone przez zdarzenia lub strumieniowe. Agenci reagują na zdarzenia zamiast na synchroniczne wywołania. Są lepsze do długotrwałych zadań, ale trudniejsze w debugowaniu i testowaniu; czasami pomocne okazują się specjalne elementy łączące.

Szukanie stanu współdzielonego. Nie jest to najprzyjemniejsze rozwiązanie, ale często stanowi najbardziej niezawodną opcję. Agenty sprawdzają postępy w wspólnym pliku lub bazie danych, zapisują tam swoje aktualizacje i przechodzą dalej. Długo trwające projekty Anthropic wykorzystują pliki JSON z listą funkcji, pliki z informacjami o postępach oraz komitety git jako trwały stan współdzielony, a punkty kontrolne realizowane przez ludzi wpisują się w to naturalnie.

To, jak agenci przekazują sobie dane, wpływa na niezawodność całego systemu. Przekazywanie pełnej historii rozmowy maksymalizuje ciągłość, ale liniowo zwiększa koszty i opóźnienia. Zwykle lepszy jest skompresowany streszczenie, co jest właśnie tym, co subagenci Claude Code robią zgodnie z projektem. Przekazywanie specyficznych dla zadania plików, takich jak strukturyzowane pliki wyjściowe, poprawki kodu, listy cech w formacie JSON oraz przechowywane raporty, stanowi zazwyczaj optymalne rozwiązanie. Agent odbierający może bezpośrednio przejrzeć te pliki zamiast polegać na streszczeniu, co sprawia, że system jest bardziej poddawalny audytowi w sposób, którego nie mogą osiągnąć przekazywania danych w formie rozmowy.

To, co jest przekazywane, określa również sposób i moment jego przekazania, co potwierdza kluczowy punkt: budowa zespołów agentów to problem projektowania systemów, a jego rozwiązanie jest trudniejsze niż w przypadku liniowego, zorganizowanego przepływu.

Osiem sposobów, w jakie zespoły agentów zawodzą

Większość tutoriali dotyczących wielu agentów pomija tę część. Notatki inżynieryjne Anthropic stanowią dobry źródło informacji. Przypominają one bardziej dziennik zespołu, który krok po kroku odkrywał, że dodatkowi agenci powiększają problemy z zarządzaniem, niż artykuł naukowy. Można z nich wyciągnąć osiem lekcji.

• Dryf koordynacji. Niejasne delegowanie zadań sprawia, że pracownicy powtarzają wzajemnie swoje poszukiwania, pomijają określone granice lub zwracają wyniki, które nie są spójne. W artykule badawczym Anthropic bezpośrednio to zaobserwowano, a rozwiązaniem było nauczenie systemu orkiestratora określania celu, formatu wyniku, wskazówek dotyczących źródeł oraz zakresu zadań dla każdego pracownika. Tam, gdzie nie jest określona odpowiedzialność, agenci sami ją wymyślają, często w niewłaściwy sposób, podobnie jak ludzie.

Halucynowane poczucie własności. Agent A uważa, że agent B zweryfikował coś, czego nikt tak naprawdę nie sprawdził. Rozwiązaniem są wyraźne artefakty zakończenia zadania: elementy do przymocowania zadań, weryfikacja od początku do końca przed oznaczeniem zadania jako zakończonego oraz trwałe pliki stanu, które rejestrują to, co faktycznie zostało potwierdzone, a nie to, co zakładano.

Ciche awarie pośrednie. Debugowanie wymagało pełnego śledzenia w środowisku produkcyjnym, ponieważ nic nie wskazywało, czy awaria wynikała z kiepskich zapytań wyszukiwawczych, słabych źródeł danych czy błędu w narzędziach. Górny poziom strumienia sesji to jedynie skrócona wersja, a zrozumienie tego, co faktycznie zrobił agent, wymaga analizy historii na poziomie pracowników. Należy wdrożyć system śledzenia od samego początku, na długo przed pierwszym incydentem w środowisku produkcyjnym.

Rozprzestrzenianie się kontekstu i zanieczyszczenie pamięci. Okno kontekstowe to ograniczony zasób, a współdzielona pamięć, która staje się przestarzała lub zanieczyszczona, pogarsza funkcjonowanie całego systemu. Każde wezwanie narzędzia, odczyt pliku oraz częściowa analiza trafia do kontekstu i pozostaje tam, a w zespole sytuacja ta się pogłębia. Znane sposoby łagodzenia tego problemu to podsumowywanie zakończonych etapów, izolowanie intensywnych operacji w podagentach oraz preferowanie małych, skoncentrowanych plików pamięciowych zamiast dużych, współdzielonych.

Niespójność schematów i kruche umowy dotyczące zapytań. Agenci wymieniający dane w języku naturalnym są podatni na błędy. Drugi agent błędnie interpretuje podsumowanie pierwszego, a błąd rozprzestrzenia się bez żadnych objawów. Istnieją ścisłe zasady używania narzędzi, ponieważ nieścisłe wezwania mogą prowadzić do niekompatybilnych typów danych lub braku niektórych pól. Wąskie umowy między agentami a narzędziami zmniejszają obszar, w którym mogą wystąpić takie problemy – co stanowi ironiczną rolę tradycyjnych umów inżynieryjnych w środowisku AI.

Nieprawidłowe użycie narzędzi i problemy z bezpieczeństwem. Im więcej otwartych środowisk, tym więcej punktów wejścia dla iniekcji promptów, a im więcej narzędzi, tym więcej sposobów, jakimi atakujący może działać po dostaniu się do środka. Badania Anthropic nad wiarygodnymi agentami określają iniekcję promptów jako wektor ataku cybernetycznego, a nie jako przypadek szczególny. Zgodnie z doniesieniami, testy zespołu METR na systemie monitoringu agentów wewnętrznych Anthropic wykazały nowe słabości nawet w dobrze zasobowanym systemie wewnętrznym. Aby temu zapobiec, należy stosować ograniczone uprawnienia, narzędzia dostosowane do potrzeb konkretnego zadania oraz ludzką aprobatę przy podejmowaniu decyzji o znaczących działaniach.

Eksplodowanie kosztów i skumulowany opóźnienie. Zespoły wykorzystują znacznie więcej tokenów niż w ramach jednej sesji. Paralelizm może skrócić czas pracy, ale zwiększa łączne zużycie tokenów zamiast je zmniejszyć, ponieważ przyspieszenie wynika z poświęcenia większej ilości uporządkowanych wysiłków jednocześnie. Chyba że zadanie wymaga takiego nakładu zasobów, pojedynczy, starannie zaprojektowany agent sprawdzi się szybciej i taniej.

Trudność oceny. Różne wewnętrzne ścieżki mogą prowadzić do wyniku, który wygląda na udany. Jeśli jedynym kryterium jest to, czy ostateczny tekst brzmi wiarygodnie, system jest podziwiany zamiast oceniany. Zaleceniem Anthropic jest sprawdzanie, czy osiągnięto prawidłowy stan końcowy, a nie tylko to, czy postępowano zgodnie z zamierzonym procesem. Proces może się różnić, a tym, co można zweryfikować, jest wynik.

Natywny, samodzielny czy hybrydowy

Zatem kluczowe pytanie brzmi: zbudować orkiestrację samodzielnie, czy skorzystać z gotowej rozwiązania? Jest to kwestia kompromisu architektonicznego pomiędzy trzema opcjami, a z pewnością istnieje ich więcej, więc potraktuj to jako jedno z możliwych ujęć tematu.

1. Natywne rozwiązania zarządzane oznaczają, że Anthropic posiada warstwę wykonawczą oraz mechanizmy koordynacji: Claude Managed Agents, a ściślej mówiąc, Managed Agents multiagent lub zespoły agentów Claude Code. Zaletami są mniejsze obciążenia inżynieryjne oraz hostowana infrastruktura, której nie trzeba utrzymywać. Wadami są ograniczona przenośność (Managed Agents są dostępne tylko przez bezpośredni API Claude), eksperymentalna lub ograniczona wersja interfejsu wieloagentowego oraz zależność od third party. Wybierz to rozwiązanie, gdy problemem jest infrastruktura, a specyficzne ograniczenia Anthropic są do przyjęcia.

DIY oznacza, że posiadasz logikę orkiestracji, a zazwyczaj także warstwę wykonawczą – najczystszym przykładem jest tu API Messages. Zapewnia ono największą kontrolę, ale wiąże się z najwyższymi kosztami inżynieryjnymi. Wybierz tę opcję, jeśli twoja logika biznesowa jest nietypowa, zasady przestrzegania regulacji są ścisłe, routowanie jest specyficzne dla twojej dziedziny lub przenoszenie usług u dostawcy stanowi rzeczywisty wymóg.

Hybrydowy oznacza, że Anthropic dostarcza pętlę i narzędzia, podczas gdy ty projektujesz system, a najwyraźniejszym przykładem jest Claude Agent SDK. Otrzymujesz pętlę agenta, zarządzanie kontekstem, elementy typu hook, podagenty oraz funkcje obserwowalności od Anthropic, przy czym nadal kontrolujesz projekt na wyższym poziomie. Autoryzacja poprzez Bedrock, Vertex AI i Azure Foundry stanowi istotną zaletę pod względem przenoszalności w porównaniu z rozwiązaniami zarządzanymi w sposób natywny. Wybierz ten model, gdy chcesz korzystać z pętli agenta od Anthropic, ale nie chcesz, aby cała architektura była dostosowana do obecnego podejścia tej firmy do funkcjonowania systemów wieloagentowych.

Krótko mówiąc: rozwiązania zarządzane w sposób natywny, gdy problemem jest infrastruktura; rozwiązania typu DIY, gdy problemem są topologia i zasady działania; a rozwiązania hybrydowe, gdy chcesz korzystać z elementów dostarczanych przez Anthropic, ale potrzebujesz swobody w podejmowaniu własnych decyzji architektonicznych.

Pytanie o architekturę

Powszechnie przyjętym podejściem w zespołach agentów jest skupienie się na ich możliwościach, w założeniu, że im więcej agentów, tym większe możliwości. Skutecznym podejściem jest natomiast architektura: jaki problem rozwiązuje dodatkowy agent i jakie to ma koszty?

Podagenty decydują o tym, kto wykona pracę, w jakim kontekście i przy użyciu jakich narzędzi. Zespoły agentów dodają na wierzch warstwę koordynacji, obejmującą wspólny stan zadań, kolegów z zespołu, którzy mogą bezpośrednio do siebie wysyłać wiadomości, oraz równoległe procesy, które same się organizują. Taka warstwa jest opłacalna tylko w przypadku problemów, które rzeczywiście wymagają takiego podejścia.

Jedna dobrze skonfigurowana grupa agentów do rzeczywistego zastosowania to rozsądny zakres pracy na tydzień. Złożoność może się od tego zwiększać, ale nie musi tak być od początku. Powyższy katalog błędów i wzorce komunikacji służą jako materiały referencyjne, a nie jako plan budowy wszystkiego naraz. Zacznij od określenia, który z czterech wyzwalaczy faktycznie jest prawdziwy; jeśli żaden z nich nie występuje, droga z jednym agentem nadal jest właściwa.