Wzorce orkiestracji wieloagentowej i najlepsze praktyki

Orkiestracja generatywna obsługuje również systemy wieloagentowe, w których jeden agent wywołuje innych agentów. Gdy podzielisz problemy między wielu wyspecjalizowanych agentów, Twoja aplikacja stanie się bardziej modułowa, skalowalna i łatwiejsza w zarządzaniu.

Agenci w linii

Agenci inline, znani również jako agenci potomni, to małe, wielokrotnego użytku przepływy pracy w obrębie tego samego agenta. Często są to po prostu tematy, które główny agent używa jako podprogramów. Na przykład główny agent może wywołać temat „Translate Text” jako jeden z kroków większego planu. Inline agenci dzielą się kontekstem z głównym agentem, więc przekazywanie danych między nimi jest proste.

Najlepsze rozwiązanie: Zachowaj agentów wbudowanych skoncentrowanych na jednej odpowiedzialności i przetestuj je dobrze.

Połączoni agenci

Agenci połączeni to oddzielni agenci posiadający własne skoordynowane działania, narzędzia i wiedzę. Główny agent deleguje część żądania agentowi podrzędnemu. Na przykład agent IT wywołuje agenta sprzedaży, aby uzyskać informacje o cenach. Połączeni agenci umożliwiają modułowość i separację domeny oraz mogą pomijać limity planu. Mogą mieć inne przywileje lub wiedzę, więc stosuj kontrolę zarządzania i audytu.

Jednak korzystanie z połączonych agentów wymaga starannego zarządzania:

  • Orkiestracja: Nadrzędny orkiestrator powinien mieć jasne kryteria, kiedy przekazać zadanie podłączonemu agentowi. Orkiestrator zwykle przekazuje się, gdy intencja użytkownika jest zgodna z domeną połączonego agenta. Aby ułatwić ten proces, jasno opisz cel połączonego agenta w konfiguracji nadrzędnej. Traktuj całego połączonego agenta jako agentowe „narzędzie” z opisem, z perspektywy agenta nadrzędnego.

  • Przekazywanie danych: Musisz zarządzać przekazywaniem danych. Zdecyduj, jaki kontekst od nadrzędnego przekazać powiązanemu agentowi. Połączony agent ma ustawienie uwzględniania kontekstu, które kontroluje, czy otrzymuje historię rozmów, więc potwierdza to ustawienie, zamiast zakładać, że historia jest przekazywana automatycznie. Agent potomny natomiast zawsze otrzymuje kontekst rodzica. Możesz też potrzebować przekazać określone parametry. Na przykład, jeśli główny agent zna już wcześniejsze imię użytkownika, może wysłać je do powiązanego agenta, aby uniknąć ponownego pytania.

  • Bezpieczeństwo: Połączony agent może mieć dostęp do rzeczy, których agent nadrzędny nie ma. Upewnij się, że dzwonienie do połączonego agenta nie omija przypadkowo ograniczeń. Na przykład, jeśli agent nadrzędny nie może usuwać rekordów, ale agent połączony może, agent nadrzędny nie powinien wzywać agenta połączonego w sytuacjach, gdy usunięcie może nastąpić bez odpowiedniej zgody. Traktuj rozmowę z podłączonym agentem tak jak każdą inną silną akcję. Jeśli robi coś wrażliwego, poddaj to wymaganym kontrolom lub zgodie użytkownika.

  • Audyt i monitoring: Rejestruj, kiedy połączony agent został wywołany i co robił. Ponieważ to osobny agent, masz dla niego osobne transkrypty. Ważne jest, aby podczas debugowania powiązać sesje nadrzędne i połączone. Zazwyczaj identyfikatory w telemetrii łączą oba elementy.

Kiedy oddzielić agentów

Nie twórz osobnego agenta dla każdego podzadania. Używaj oddzielnych agentów, jeśli podzadanie:

  • Jest na tyle złożony, że posiada własny zestaw narzędzi lub wiedzy (inna dziedzina specjalizacji)
  • Wymaga innych reguł zarządzania lub kontroli dostępu niż główny agent
  • Może być ponownie wykorzystywany w wielu różnych głównych agentach (czyli działa jak agent usługowy)

Jeśli żaden z tych warunków nie ma zastosowania, prosty agent wbudowany może obsługiwać zadanie, a jednocześnie jest prostszy niż pełny połączony agent. Oddzielni agenci wprowadzają narzut na system. Istnieje nieco dłuższy czas wykonywania ze względu na przełączanie kontekstu i złożoność obsługi wielu agentów. Więc korzystaj z nich rozsądnie. Aby uzyskać praktyczne podejście, zacznij od jednego agenta. Dopiero wtedy podzielić go na wielu agentów, gdy wyraźnie widać potrzebę wprowadzenia modułowości lub granicę, której pojedynczy agent nie powinien przekraczać.

Najlepsze rozwiązania dotyczące orkiestracji wielu agentów

Poniższe najlepsze rozwiązania mają zastosowanie podczas tworzenia instrukcji dotyczących agentów nadrzędnych i podrzędnych w konfiguracji wielu agentów.

1. Pojedyncza zasada odpowiedzi

Upewnij się, że tylko jeden agent rozmawia z użytkownikiem na kolei. W konfiguracji obejmującej wiele agentów agent nadrzędny jest jedynym, który powinien dostarczyć ostateczną odpowiedź. Subagenty są naukowcami, a nie osobami reagującymi.

  • Do: Dodaj do instrukcji nadrzędnych: "Jesteś jedynym agentem, który komunikuje się z użytkownikiem. Połącz wyniki ze wszystkich agentów podrzędnych w jedną odpowiedź".
  • Nie: Pozostaw to niejednoznaczne. Bez jawnych wskazówek subagenty odpowiadają bezpośrednio użytkownikowi, powodując zduplikowane lub częściowe komunikaty.

Note

Kierowanie całej komunikacji użytkownika za pośrednictwem obiektu nadrzędnego to poprawne rozwiązanie, ale nie jedyne. Dziecko lub powiązany agent może również odpowiedzieć użytkownikowi bezpośrednio, gdy jest to świadomy wybór. Tak czy inaczej, ryzyko, przed którym należy zabezpieczyć projekt, jest takie samo: agent nadrzędny odpowiada na żądanie, które subagent już obsłużył. Dowiedz się więcej o kontrakcie kontekstowym, który zapobiega duplikatowi wiadomości w obu projektach w subagentach projektowych, które zapobiegają duplikatem wiadomości.

2. Instrukcje podrzędne muszą zadeklarować swoją rolę

Zawsze poinformuj subagentów, że są subagentami. Subagenty same z siebie nie wiedzą, że są częścią orkiestracji. Bez wyraźnych wskazówek zachowują się jako agenci autonomiczni i wysyłają komunikaty bezpośrednio do użytkownika.

  • Do: Dodaj do instrukcji każdego subagenta: "Jesteś subagentem. Nie odpowiadaj bezpośrednio użytkownikowi. Twoim zadaniem jest wyszukiwanie informacji i przekazywanie wyników agentowi nadrzędnemu. Agent nadrzędny obsługuje całą komunikację z użytkownikiem".
  • Nie: Załóżmy, że subagenty wymyślają wzorzec aranżacji samodzielnie.

3. Użyj jasnego, bezpośredniego języka w instrukcjach

Zawsze używaj języka dyrektywy. Unikaj miękkich lub uprzejmych fraz. Platforma wprowadza instrukcje na poziomie systemu przy użyciu silnego języka (MUST, DO NOT, NEVER). Instrukcje napisane za pomocą języka miękkiego ("proszę spróbować", "powinieneś", "dobrze byłoby") stracić priorytet, gdy powodują konflikt.

  • Zrób: "NIGDY nie odpowiadaj bezpośrednio użytkownikowi. Tylko zwrócić swoje ustalenia."
  • Do: "Musi istnieć dokładnie jedna ostateczna odpowiedź na pytanie użytkownika".
  • Nie: "Staraj się unikać wysyłania wiadomości do użytkownika i zamiast tego zwracać wyniki.
  • Nie rób tego: „Idealnie byłoby, gdybyśmy otrzymali jedną, łączną odpowiedź.”

4. Użyj jednego źródła wiedzy na podagent (bez nakładania się)

Przypisz każdemu subagentowi odrębne, nienakładające się źródła wiedzy. Jeśli dwa podagenty przeszukuje tę samą bazę wiedzy, jeden podagent znajdzie najpierw odpowiedź. Drugi podagent zwraca zduplikowane wyniki lub całkowicie pomija wyszukiwanie, nie wnosząc żadnej wartości.

  • Do: CA-1 wyszukuje źródło wiedzy A (na przykład zasady kadr). CA-2 wyszukuje źródło wiedzy B (na przykład dokumentację IT).
  • Don't: Nie przyznawaj obu podagentom dostępu do tych samych dokumentów, tabel usługi Dataverse ani witryn SharePoint.
  • Uwaga: jeśli masz tylko jedno źródło wiedzy, użyj jednego agenta z wiedzą zamiast dzielenia na dwa podagenty. Multi-agent dodaje wartość tylko wtedy, gdy źródła są naprawdę różne.

5. Używanie dokładnych i odrębnych opisów dla podagentów

Napisz jasne, odrębne opisy dla każdego subagentu widocznego dla elementu nadrzędnego. Agent nadrzędny używa opisów podagentów do określania trasowania. Jeśli opisy są niejasne, identyczne lub niedokładne, moduł nadrzędny nie może podejmować właściwych decyzji dotyczących trasowania.

  • Do: CA-1: "Wyszukuje dokumenty zasad kadr dla pytań związanych z pracownikami". CA-2: "Wyszukuje bazę wiedzy IT pod kątem pytań dotyczących pomocy technicznej".
  • Nie: nadaj obu agentom ten sam opis, gdy obsługują różne domeny.
  • Nie: użyj ogólnych opisów, takich jak "Ten agent może pomóc w zadawaniu pytań".

6. Instrukcje nadrzędne muszą definiować wzorzec aranżacji

Powiedz agentowi nadrzędnemu, jak koordynować działanie. Nie mów tylko: „użyj agentów podrzędnych”. Agent nadrzędny potrzebuje jasnych instrukcji dotyczących tego schematu: wywołać agentów, poczekać na wyniki, połączyć je, a następnie odpowiedzieć.

  • Wykonaj: "Kiedy użytkownik zadaje pytanie: 1. Wywołaj obu agentów podrzędnych, aby zebrać informacje. 2. Poczekaj, aż obaj agenci podrzędni przekażą swoje ustalenia. 3. Połącz wyniki w jedną, ujednoliconą odpowiedź. 4. Dostarczaj dokładnie jedną odpowiedź użytkownikowi. Agenci podrzędni nie mogą bezpośrednio odpowiadać użytkownikowi".
  • Nie rób tego: „Gdy użytkownik zada pytanie, wywołaj podagentów, pobierz odpowiedzi z obu źródeł i przedstaw jedną zbiorczą odpowiedź.” (Zbyt niejasne. Instrukcja nie mówi podagentom, żeby milczeli.)

7. Uwzględnij dyrektywę "brak bezpośredniej odpowiedzi" w delegowaniu zadań

Nawet przy jasno określonych instrukcjach dla subagenta dodatkowe wzmocnienie w delegowanym zadaniu stanowi zabezpieczenie.

  • Do: Dodaj do instrukcji nadrzędnych: „Gdy delegujesz zadanie agentowi podrzędnemu, zawsze uwzględnij w zadaniu: „Zwróć wyłącznie swoje ustalenia.”” Nie odpowiadaj użytkownikowi".
  • Nie: polegaj wyłącznie na własnych instrukcjach subagenta. Kontekst zadania daje subagent więcej sygnałów, które wzmacniają wzorzec.

8. Testowanie przy użyciu kwerend niezgodności domeny

Zawsze testuj przy użyciu pytań, które nie są zgodne z domeną subagenta. To testowanie ujawnia, czy subagenci poprawnie zwracają komunikat „nie znaleziono informacji”, zamiast zwracać informacje, które mogą być nieprawidłowe, zawieszać się lub wysyłać mylące komunikaty.

  • Zrób: Przetestuj zapytania spoza domen wszystkich podagentów (na przykład zadaj pytanie o pogodę, gdy podagenci obsługują kadry i IT).
  • Do: Sprawdź, czy element nadrzędny poprawnie obsługuje sytuację, gdy „obaj agenci nic nie znaleźli”.
  • Nie: przetestuj tylko przy użyciu najprostszych zapytań przypadków, które idealnie pasują do domeny jednego subagenta.

9. Wybieraj pytanie zamiast informowania, gdy spodziewasz się dalszych pytań

Gdy oczekujesz odpowiedzi od użytkownika, stosuj interakcje w formie pytań. Używaj stylu inform/send tylko w przypadku końcowych komunikatów jednokierunkowych. Jeśli agent zada użytkownikowi pytanie, używając komunikatu jednokierunkowego (inform), odpowiedź użytkownika wraca do nadrzędnego planera jako zupełnie nowe zapytanie. W takim przypadku lepiej kontynuować tę samą rozmowę z subagentem.

  • Do: Napisz instrukcje, takie jak: "Jeśli potrzebujesz wyjaśnień, zadaj użytkownikowi pytanie i poczekaj na odpowiedź".
  • Nie: Napisz instrukcje, takie jak: "Poinformuj użytkownika o opcjach i pozwól im wybrać". Komunikat "Inform" sygnalizuje jednokierunkową wiadomość, podczas gdy "zapytaj" sygnalizuje dwukierunkową wymianę.

Lista kontrolna szybkich odwołań

# Sprawdzanie
1 Instrukcje nadrzędne wyraźnie stanowią: „tylko ja odpowiadam użytkownikowi”
2 Każda instrukcja podrzędna mówi "nie odpowiadaj bezpośrednio użytkownikowi"
3 Instrukcje używają kategorycznych sformułowań (MUST, NEVER, ONLY)
4 Każdy podagent ma unikalne, nienakładające się źródło wiedzy
5 Opisy subagentów są dokładne, wyraźnie odróżnialne i szczegółowe
6 Instrukcje nadrzędne definiują pełny wzorzec orkiestracji (wywołanie → oczekiwanie → scalanie → odpowiedź)
7 Element nadrzędny przekazuje "brak bezpośredniej odpowiedzi" w kontekście zadania delegowanego
8 Przetestowano zapytania dotyczące niezgodności domeny
9 Rozróżnienie między zadawaniem pytań a informowaniem jest poprawne w instrukcjach podagentów