Orkiestracja agentów AI to koordynowanie kilku wyspecjalizowanych agentów AI i stojących za nimi ludzi tak, aby jedna prośba klienta trafiła do właściwego agenta we właściwym momencie i z właściwym kontekstem. Orkiestrator, czyli agent prowadzący albo kod otaczający agentów, decyduje, kto działa jako następny, co zostaje przekazane dalej i kiedy praca jest zakończona.
W skrócie
- Orkiestracja decyduje, który agent obsługuje każdy krok rozmowy, jaki kontekst otrzymuje i kiedy przejmuje ją człowiek.
- Większość konfiguracji w obsłudze klienta łączy kilka wzorców: router lub nadzorcę na wejściu, kroki sekwencyjne dla działań regulowanych oraz przekazania między agentami i do ludzi.
- Rozmowy z wieloma agentami psują się na styku: utracony kontekst przy przekazaniu, pętle między agentami, działanie niewłaściwego agenta i rozmowy zamknięte przed załatwieniem sprawy.
- Dashboardy dla pojedynczych agentów ukrywają te błędy, bo każdy agent może wyglądać dobrze, podczas gdy ścieżka klienta zawodzi.
- Kontrola jakości powinna obejmować ścieżkę, a nie pojedynczą wypowiedź: połączyć wszystkie segmenty agentów i ludzi w jeden zapis, ocenić miejsca styku i przypisać każdy błąd do segmentu, który go spowodował.
Czym jest orkiestracja agentów AI?
Orkiestracja agentów AI to warstwa, która koordynuje wielu agentów AI w jednym systemie. IBM opisuje ją jako koordynowanie wyspecjalizowanych agentów w kierunku wspólnych celów, z orkiestratorem, którym może być centralny agent lub framework. W obsłudze klienta zamienia bota do triażu, agenta rozliczeń, agenta zwrotów i Państwa zespół konsultantów w jedno doświadczenie.
Agent AI (po angielsku) to jeden model z instrukcjami i narzędziami, pracujący na rzecz celu. Orkiestracja to sterowanie ruchem między kilkoma takimi agentami, które w każdej turze odpowiada na cztery pytania:
- Kto działa jako następny? Agent do triażu, specjalista, człowiek albo nikt (rozmowa jest zakończona).
- Co otrzymuje? Pełną transkrypcję, podsumowanie albo tylko potrzebne pola.
- Co może zrobić? Odczytać dane, zmienić zamówienie, wystawić zwrot albo tylko odpowiedzieć.
- Kiedy się zatrzymuje? Cel został osiągnięty, osiągnięto limit tur albo potrzebna jest zgoda człowieka.
Anthropic nazywa systemy, w których „LLMs and tools are orchestrated through predefined code paths” (LLM i narzędzia są orkiestrowane przez z góry zdefiniowane ścieżki w kodzie), workflows, a systemy, w których modele „dynamically direct their own processes and tool usage” (dynamicznie kierują własnymi procesami i użyciem narzędzi), agents. Większość orkiestracji w obsłudze klienta łączy jedno i drugie: stałe ścieżki dla zwrotów i weryfikacji tożsamości, osąd agenta dla pytań otwartych. Szerszą kategorię opisuje nasz artykuł o tym, czym jest agentic AI (po angielsku).
Kim jest orkiestrator AI? Technicznie to komponent (agent prowadzący lub framework), który rozdziela pracę. Organizacyjnie to osoba lub zespół, który odpowiada za to, jak agenci i ludzie dzielą się pracą: reguły routingu, wyzwalacze eskalacji i standard jakości całej ścieżki.
Jakie są główne wzorce orkiestracji agentów AI?
Kilka wzorców obejmuje niemal każdą konfigurację w obsłudze klienta: router, który kieruje każdą prośbę do jednego specjalisty, nadzorca, który zachowuje kontrolę i wywołuje specjalistów jak narzędzia, stała sekwencja kroków, agenci równoległi pracujący na tych samych danych, hierarchia nadzorców, przekazania między agentami i do ludzi oraz pętla twórca i weryfikator (maker-checker). Prawdziwe wdrożenia je łączą.
Dostawcy nazywają te wzorce różnie. Azure Architecture Center firmy Microsoft wymienia orkiestrację sekwencyjną, współbieżną, czat grupowy, handoff i magentic i zaznacza, że handoff bywa też nazywany routingiem, triażem, transferem, dyspozycją lub delegowaniem. OpenAI Agents SDK odróżnia „agents as tools”, gdzie menedżer zachowuje kontrolę, od „handoffs”, gdzie specjalista przejmuje rozmowę. IBM dodaje modele scentralizowany, zdecentralizowany, hierarchiczny i federacyjny. Słowa się różnią, pytania z perspektywy obsługi klienta nie. Tabela poniżej opisuje każdy wzorzec w kategoriach obsługi klienta.
Najważniejsze rozróżnienie dla lidera obsługi to kto odpowiada za klienta po zmianie. W konfiguracji z nadzorcą agent prowadzący pozostaje odpowiedzialny za końcową odpowiedź. Przy przekazaniu (handoff) agent przyjmujący przejmuje pełną odpowiedzialność, jak precyzuje dokumentacja handoff Microsoftu. To przesądza, kogo rozliczają Państwo, gdy QA znajdzie złą odpowiedź.
Tabela wzorców orkiestracji: błędy i kontrole w obsłudze klienta
Każdy wzorzec orkiestracji zawodzi na swój sposób, więc każdy wymaga własnej kontroli. Tabela przypisuje każdemu wzorcowi przykład z obsługi klienta, oczekiwany błąd i to, na co zwrócić uwagę w ocenie. Warto skopiować ją do planu QA i zostawić wiersze odpowiadające temu, jak dziś połączeni są Państwa agenci.
| Wzorzec | Jak działa | Przykład z obsługi klienta | Typowy błąd | Co sprawdzić |
|---|---|---|---|---|
| Router (triaż) | Agent do triażu klasyfikuje prośbę i przekazuje ją jednemu specjaliście | „Gdzie jest mój zwrot?” trafia do agenta Rozliczeń | Błędny kierunek: agent Zamówień z pewnością siebie odpowiada na pytanie o rozliczenia | Czy pierwsze skierowanie było właściwe? Czy specjalista pozostał w swoim zakresie? |
| Nadzorca (menedżer) | Agent prowadzący zachowuje rozmowę i wywołuje specjalistów jak narzędzia | Agent prowadzący pyta agenta Zasad, czy spóźniony zwrot jest dozwolony | Agent prowadzący ignoruje lub przepisuje odpowiedź specjalisty; klient dostaje mieszankę obu | Czy końcowa odpowiedź zgadza się z tym, co zwrócił specjalista? |
| Sekwencyjny (pipeline) | Stałe kroki, każdy korzysta z wyniku poprzedniego | Weryfikacja tożsamości, sprawdzenie uprawnień, zwrot, wysłanie podsumowania | Wczesny błąd przechodzi przez wszystkie kroki (błędny numer zamówienia prowadzi do błędnego zwrotu) | Czy wynik każdego kroku został zweryfikowany, zanim użył go kolejny krok? |
| Współbieżny (równoległy) | Kilku agentów pracuje jednocześnie nad tą samą wiadomością | Przygotowanie odpowiedzi i sprawdzenie zasad biegną równolegle | Sprzeczne wyniki źle połączone; klient widzi dwie odpowiedzi | Gdy agenci się nie zgadzali, który wygrał i czy była to właściwa reguła? |
| Hierarchiczny | Nadzorcy zarządzają zespołami agentów w swoich domenach | Nadzorca logistyki kieruje między agentami śledzenia przesyłek i zwrotów | Prośba trafia między dwóch nadzorców i nikt za nią nie odpowiada | Czy każda ścieżka ma jednego właściciela na każdym poziomie? |
| Przekazanie między agentami | Każdy agent decyduje, kiedy przekazać rozmowę dalej | Agent Zamówień przekazuje sprawę uszkodzonego produktu agentowi Zwrotów | Pętle (A do B do A), utracony kontekst, klient dwa razy pytany o te same dane | Ile było przekazań? Czy któryś agent pojawił się dwukrotnie? Czy klient powtarzał informacje? |
| Przekazanie do człowieka | Agent eskaluje do osoby wraz z podsumowaniem | Agent Zwrotów eskaluje sporne obciążenie do konsultanta | Eskalacja za późno albo bez podsumowania, więc człowiek zaczyna od zera | Właściwy wyzwalacz, właściwy moment i czy człowiek miał potrzebny kontekst? |
| Twórca i weryfikator (maker-checker) | Jeden agent przygotowuje projekt, drugi go zatwierdza lub odsyła | Agent przygotowuje propozycję gestu dobrej woli; weryfikator sprawdza ją pod kątem zasad | Weryfikator przepuszcza błędny projekt albo pętla trwa do limitu i i tak wysyłana jest ostatnia wersja | Co robi weryfikator, gdy osiągnie limit iteracji? |
Przekazania między agentami niosą największe ryzyko pętli i utraty kontekstu, a przekazania do ludzi to miejsce, w którym klienci najszybciej zauważają błędy. Nasz poradnik o ocenie przekazania rozmowy między AI a człowiekiem omawia ten wiersz dokładniej.
Gdzie psują się rozmowy z wieloma agentami w obsłudze klienta?
Rozmowy z wieloma agentami w obsłudze klienta psują się na styku agentów, a nie wewnątrz nich. Cztery najważniejsze błędy to utracony kontekst przy przekazaniu, pętle między agentami, działanie niewłaściwego agenta i rozmowa zamknięta przed rozwiązaniem problemu. Każdy z nich może wystąpić, gdy każdy pojedynczy agent wygląda na działającego poprawnie.
Utracony kontekst. Przekazania przenoszą mniej, niż zakłada większość zespołów. W orkiestracji handoff w Microsoft Agent Framework wiadomości użytkownika i agenta są synchronizowane między agentami, ale treści związane z narzędziami nie są rozsyłane. Kolejny agent widzi to, co zostało powiedziane, a niekoniecznie to, co poprzedni agent sprawdził lub zrobił. Jeśli agent Rozliczeń nie widzi zamówienia, które pobrał agent Zamówień, pyta klienta ponownie albo działa na podstawie założenia.
Pętle. Dwóch agentów może przerzucać się prośbą albo jeden agent może powtarzać ten sam krok. Przewodnik architektoniczny Microsoftu wymienia „infinite handoff loops” (nieskończone pętle przekazań) jako pułapkę wzorca handoff i zaleca limity iteracji dla pętli. W trybie autonomicznym jego framework handoff domyślnie pozwala każdemu agentowi wykonać do 50 tur, zanim będzie potrzebował danych od użytkownika, czyli znacznie więcej, niż zniesie jakikolwiek klient.
Działanie niewłaściwego agenta. Źle skierowana prośba trafia do agenta, który z pewnością siebie odpowiada poza swoją domeną. Odpowiedź brzmi płynnie, więc nikt tego nie zauważa, chyba że ktoś sprawdzi ją względem właściwej zasady.
Zbyt wczesne zamknięcie. Agenci mogą przestać działać przed zakończeniem pracy albo w ogóle nie wiedzieć, kiedy ją zakończyli.
Potwierdzają to badania. Artykuł z 2025 roku Why Do Multi-Agent LLM Systems Fail? przeanalizował 1 642 ślady wykonania z siedmiu frameworków i opisał 14 rodzajów błędów. Powtarzanie kroków wystąpiło w 15,7% śladów, nierozpoznanie zakończenia zadania w 12,4%, a utrata kontekstu w 2,8%. Autorzy stwierdzili też, że udane przebiegi nie są wolne od błędów. Ślady pochodziły z zadań programistycznych, matematycznych i ogólnych, a nie z obsługi klienta, więc te odsetki warto traktować jako ostrzeżenie, a nie benchmark. Wniosek się przenosi: wynik „rozwiązane” może ukrywać błędy po drodze, jak pokazuje nasz artykuł o cichych błędach agentów AI.
Co monitorować w obsłudze klienta opartej na orkiestracji?
Monitorować trzeba ścieżkę, a nie tylko każdego agenta. Wyniki pojedynczych agentów pokazują, czy agent Rozliczeń dobrze odpowiada na pytania o rozliczenia, ale nie to, że klienci krążyli między trzema agentami, zanim do niego trafili. Zamiast tego warto śledzić kilka sygnałów dotyczących ścieżki: przekazania, pętle, powtarzane dane klienta, trafność pierwszego skierowania, eskalacje z kontekstem i różnicę między rozwiązaniem na poziomie agenta a rozwiązaniem na poziomie ścieżki.
Poniższe reguły początkowe są nasze, a nie standardem branżowym: przez cztery tygodnie warto mierzyć własny poziom bazowy, a potem je dostroić.
| Sygnał | Jak go mierzyć | Reguła początkowa |
|---|---|---|
| Przekazania na rozmowę | Liczba zmian agenta w logu rozmowy | Ocenić każdą rozmowę z więcej niż 3 przekazaniami |
| Powtórzony agent (pętla) | Ten sam agent pojawia się w jednej rozmowie dwa razy, z innym agentem pomiędzy | Ocenić wszystkie takie rozmowy; każdy rosnący trend to błąd routingu |
| Odsetek ponownych pytań | Klient podaje ten sam identyfikator (numer zamówienia, e-mail) dwa razy | Analizować, jeśli przekracza 5% rozmów z wieloma agentami |
| Trafność pierwszego skierowania | Odsetek pierwszych skierowań, które oceniający uznał za właściwe | Przyjrzeć się routerowi, jeśli spada poniżej 90% |
| Eskalacja z kontekstem | Odsetek przekazań do człowieka, w których człowiek nie musiał pytać ponownie | Cel: 95% lub więcej |
| Luka w rozwiązaniu | Odsetek „rozwiązanych” na poziomie agenta minus odsetek poprawnie rozwiązanych na poziomie ścieżki | Luka powyżej 5 punktów oznacza, że błędy chowają się między agentami |
| Osiągnięty limit tur lub iteracji | Rozmowy zakończone, bo osiągnięto limit | Ocenić każdą; to zablokowane pętle |
Wytyczne Microsoftu mówią to samo od strony inżynierskiej: należy instrumentować wszystkie operacje agentów i przekazania oraz stosować rubryki oceny lub ewaluację z modelem jako sędzią zamiast testów dokładnego dopasowania, bo wyniki agentów się różnią. Dashboardy i alerty opisuje nasz poradnik o monitorowaniu agentów AI.
Jak prowadzić kontrolę jakości ścieżki obejmującej kilku agentów i ludzi?
Żeby prowadzić kontrolę jakości ścieżki z wieloma agentami, jednostką oceny musi być cała rozmowa. Należy połączyć wszystkie segmenty agentów i ludzi w jeden zapis, ocenić każdy segment względem jego zadania, ocenić miejsca styku kryteriami ścieżki i przypisać każdy błąd do segmentu, który go spowodował. Potem naprawić tę część i ocenić ponownie.
Krok 1: połączyć ścieżkę. Jeden identyfikator rozmowy towarzyszy klientowi przez wszystkich agentów i ludzi. Jeśli agenci zapisują logi w różnych miejscach, pierwszym zadaniem QA jest doprowadzenie pełnej transkrypcji, z nazwą agenta przy każdej turze, do helpdesku lub jednej kolejki ocen.
Krok 2: ocenić każdy segment względem jego zadania. Poprawność rozliczeń dla agenta Rozliczeń, routing dla agenta do triażu, rozwiązanie sprawy dla człowieka. Wspólny rdzeń kryteriów utrzymuje porównywalność segmentów ludzi i AI; nasz poradnik o wspólnej karcie oceny dla konsultantów i agentów AI pokazuje, jak ją zbudować.
Krok 3: dodać kryteria ścieżki. To pytania, na które nie odpowie żaden pojedynczy segment:
- Czy pierwsze skierowanie było właściwe?
- Czy klient musiał powtarzać jakiekolwiek dane?
- Czy któryś agent pojawił się dwukrotnie albo czy rozmowa wpadła w pętlę?
- Czy każde przekazanie przeniosło dane potrzebne kolejnemu agentowi?
- Jeśli rozmowę przejął człowiek, czy eskalacja nastąpiła przy właściwym wyzwalaczu i z użytecznym podsumowaniem?
- Czy faktyczny problem klienta został na końcu rozwiązany, niezależnie od tego, kto go rozwiązał?
Krok 4: przypisać błąd. Każda nieudana ścieżka dostaje jeden segment będący przyczyną źródłową: router, specjalistę, mechanizm przekazania lub człowieka. Bez przypisania błąd ścieżki jest problemem wszystkich i nikt go nie naprawia.
Krok 5: naprawić i ocenić ponownie. Wniosek trafia do właściciela danej części (prompt, reguła routingu, artykuł w bazie wiedzy, wyzwalacz eskalacji), a potem ponownie ocenia się ten sam typ ścieżki, żeby potwierdzić, że poprawka działa. Zmiany warto testować przed wdrożeniem; zob. nasz poradnik o testowaniu agentów AI.
Przykład liczbowy (ilustracja, liczby wymyślone, żeby pokazać obliczenia)
Zespół obsługi prowadzi 40 000 rozmów miesięcznie z agentem do triażu, trzema agentami specjalistami i zespołem konsultantów:
- 26 000 rozmów (65%) przechodzi od triażu do jednego specjalisty i tam się kończy.
- 10 000 (25%) przechodzi przez dwóch lub więcej agentów AI.
- 4 000 (10%) kończy się u człowieka.
Dashboardy pojedynczych agentów wyglądają dobrze: każdy specjalista spełnia ponad 90% własnych kryteriów. Następnie lider QA ocenia losową próbkę 200 ścieżek z wieloma agentami według powyższych kryteriów ścieżki. 34 nie przechodzą (17%): 14 klientów powtarzało numer zamówienia, 9 rozmów wróciło w pętli do triażu, 6 dostało odpowiedź od niewłaściwego specjalisty, a 5 zamknięto przed potwierdzeniem zwrotu.
W skali całości 17% z 10 000 to około 1 700 nieudanych ścieżek miesięcznie. Jeśli ścieżki z jednym agentem zawodzą w 5%, daje to 1 300 błędów z 26 000. Ćwierć rozmów, które przechodzą przez kilku agentów, generuje więcej błędów niż dwie trzecie, które tego nie robią.
Próbka pokazuje też granice próbkowania. Przy 200 rozmowach i 17% błędów margines błędu przy 95% ufności wynosi około plus minus 5,2 punktu (1,96 × √(0,17 × 0,83 / 200)). Przedział 95% obejmuje od około 1 200 do 2 200 nieudanych ścieżek. A 14 ponownych pytań wskazuje na jedną poprawkę: wynik wyszukiwania agenta Zamówień nie dociera do agenta Rozliczeń przy przekazaniu.
Proszę zobaczyć to na własnych rozmowach. Kaizo ocenia 100% Państwa rozmów z klientami, zarówno konsultantów, jak i agentów AI, według Państwa własnej karty oceny i wiąże każdy wynik z dowodem w rozmowie. Umów demo.
Jaki framework lub platformę do orkiestracji agentów AI wybrać?
Najlepszy framework do orkiestracji agentów AI to ten, który Państwa dostawca agentów lub zespół inżynierów już dobrze obsługuje; liderzy obsługi rzadko wybierają go sami. Powinni natomiast ustalić wymagania: widoczny routing dla każdej rozmowy, kontekst przekazywany przy przekazaniu, limity tur, eskalacja do człowieka z podsumowaniem i transkrypcje trafiające tam, gdzie pracuje Państwa zespół QA.
Opcje dzielą się na trzy grupy:
- Wbudowane w platformę agentów AI. Platformy agentów do obsługi klienta kierują rozmowy między własnymi agentami i do Państwa zespołu. Najmniej pracy, najmniej kontroli.
- Frameworki dla programistów. Między innymi Microsoft Agent Framework, OpenAI Agents SDK, LangChain i CrewAI. Pełna kontrola, a każdą regułą zarządzają Państwa inżynierowie.
- Warstwy orkiestracji klasy enterprise. Produkty takie jak IBM watsonx Orchestrate koordynują agentów, narzędzia i przepływy pracy z jednej centralnej warstwy w całej firmie.
Niezależnie od grupy przed uruchomieniem warto zadać pięć pytań:
- Czy dla każdej rozmowy widzimy, który agent działał w każdej turze i dlaczego przekazał rozmowę?
- Co dokładnie jest przekazywane: transkrypcja, podsumowanie, wyniki narzędzi, dane klienta?
- Jakie są limity tur i iteracji i co się dzieje po ich osiągnięciu?
- Jak człowiek przejmuje rozmowę i co widzi jako pierwsze?
- Gdzie trafia pełna transkrypcja i czy nasz zespół QA może ją tam ocenić?
Jeśli odpowiedź brzmi „nie możemy tego pokazać”, nie da się też ocenić jakości ścieżki.
Kiedy orkiestracja wielu agentów nie jest dla Państwa?
Orkiestracja wielu agentów nie jest dla Państwa, gdy jeden dobrze określony agent AI z właściwymi narzędziami i jasną ścieżką eskalacji poradzi sobie z Państwa wolumenem. Wytyczne Microsoftu mówią, by stosować najniższy poziom złożoności, który niezawodnie spełnia wymagania, i nazywają pojedynczego agenta z narzędziami często właściwym punktem wyjścia w zastosowaniach enterprise. Każdy dodatkowy agent dodaje przekazania, opóźnienia, koszty i rodzaje błędów.
Praktycy na forach customer success mówią podobnie: korzyści zwykle przynosi agent AI, który dobrze obsługuje wąski zakres pytań, a nie taki, który próbuje objąć wszystko. Jeśli Państwa agent AI obsługuje kilkaset rozmów miesięcznie w jednej domenie, można pominąć orkiestrację, co tydzień czytać transkrypcje, a wysiłek przeznaczyć na bazę wiedzy i wyzwalacz eskalacji.
Sam routing zapewnia Państwa platforma agentów lub jeden z powyższych frameworków. Rola Kaizo zaczyna się po rozmowie: ocenia zakończone rozmowy z Zendesk lub Salesforce według Państwa karty oceny.
Jak zacząć w tym tygodniu
Ocenę orkiestrowanych ścieżek można zacząć w tym tygodniu bez nowych narzędzi: narysować, jak połączeni są Państwa agenci, a potem ocenić niewielki zestaw ścieżek z wieloma agentami według kryteriów ścieżki. Celem pierwszego tygodnia nie jest dashboard, tylko znalezienie styku, który zawodzi najczęściej.
- Narysować połączenia. Wymienić każdego agenta AI, kto może przekazać rozmowę komu i gdzie wchodzą ludzie, z wzorcem z powyższej tabeli.
- Pobrać 30 ścieżek z wieloma agentami oraz 10, które zakończyły się u człowieka.
- Ocenić je według sześciu kryteriów ścieżki, zapisując dla każdego błędu segment będący przyczyną źródłową.
- Wybrać najgorszy styk. Zwykle jest to jedno przekazanie, które gubi kontekst, albo jedna reguła routingu, która działa błędnie.
- Wskazać właściciela każdego agenta i każdej reguły przekazania.
Gdy ręczna ocena potwierdzi wzorzec, warto ją zautomatyzować. Kontrola jakości agentów AI w Kaizo ocenia rozmowy agentów AI według tej samej karty oceny co rozmowy zespołu, łącznie z kryteriami przekazania, takimi jak to, czy agent eskalował przy właściwym wyzwalaczu i przekazał kontekst, a AutoPilot ocenia każdą rozmowę w chwili jej zakończenia. Szerszy obraz daje nasz przewodnik po agentowej obsłudze klienta; zasady, których przestrzegają ci agenci, opisuje artykuł o zarządzaniu agentami AI.
Najczęściej zadawane pytania
Czy ChatGPT to agent czy LLM?
ChatGPT to produkt zbudowany na dużych modelach językowych (LLM). Gdy odpowiada na pojedyncze pytanie, zachowuje się jak interfejs czatu do LLM. Gdy korzysta z narzędzi, przegląda internet albo samodzielnie wykonuje zadanie w wielu krokach, zachowuje się jak agent. Różnica polega na tym, co system może robić, a nie na modelu.
Czym różni się system wieloagentowy od agentic AI?
Agentic AI opisuje AI, która działa na rzecz celu z pewną autonomią. System wieloagentowy to jeden ze sposobów jej budowy: kilku wyspecjalizowanych agentów koordynowanych przez orkiestrację zamiast jednego agenta, który robi wszystko. Pojedynczy agent może być agentowy; system wieloagentowy dodaje przekazania, a wraz z nimi miejsca styku, które trzeba sprawdzać.
Czy Kubernetes to narzędzie do orkiestracji?
Tak, ale dla kontenerów, a nie agentów AI. Kubernetes planuje i skaluje oprogramowanie, na którym działają Państwa usługi. Orkiestracja agentów AI decyduje, który agent obsługuje którą część rozmowy i jaki kontekst otrzymuje. System agentów może działać na Kubernetes, ale Kubernetes nie kieruje próśb między agentami.
Czym jest warstwa orkiestracji agentów AI?
Warstwa orkiestracji znajduje się nad pojedynczymi agentami i decyduje o routingu, przekazywaniu kontekstu, uprawnieniach i zasadach zatrzymania. Może to być agent prowadzący, framework w Państwa własnym kodzie lub centralny produkt. Na potrzeby QA powinna też dostarczać zapis tego, kto działał i dlaczego.
Jak ocenić system wieloagentowy w obsłudze klienta?
Ocenia się go na dwóch poziomach: każdego agenta względem jego zadania oraz całą ścieżkę według kryteriów takich jak właściwe pierwsze skierowanie, brak powtarzanych danych, brak pętli i poprawny wynik końcowy. Nasz poradnik o ewaluacji agentów AI opisuje metody, od zestawów testowych po ocenę rozmów na żywo.
