Wzorce projektowe systemu agenta

Tworzenie systemu agenta polega na organizowaniu przepływu wywołań LLM, pobierania danych i działań zewnętrznych, tak aby współdziałały ze sobą. Wzorce projektowe dla systemów agentów można traktować w kontinuum złożoności i autonomii: od łańcuchów deterministycznych, przez systemy jednego agenta, które mogą podejmować dynamiczne decyzje (i mogą obejmować wiele wywołań LLM pod maską), aż do architektur wieloagentowych, które koordynują wielu wyspecjalizowanych agentów.

Uruchamianie narzędzi

Przed rozpoczęciem opracowywania wzorców projektowych ważne jest, aby zrozumieć wywoływanie narzędzi jako podstawowe możliwości, które mogą być używane w dowolnym systemie agentów— od prostych do złożonych. Wywoływanie narzędzi to mechanizm, który umożliwia systemowi agentów interakcję z funkcjami zewnętrznymi, źródłami danych lub usługami. Może to umożliwić:

• Wyszukiwania danych na żywo, takie jak zapytania SQL, pobieranie danych z CRM lub pobieranie indeksu wektorowego.
• Akcje, takie jak wysyłanie wiadomości e-mail lub aktualizowanie rekordu.
• Dowolna logika lub przekształcenia za pomocą funkcji języka Python lub interfejsów API.

Wywoływanie narzędzi zapewnia potężny mechanizm, dzięki któremu LLM mogą "uzyskać świadomość" danych zewnętrznych lub interfejsów API, niezależnie od wybranego wzorca projektowego.

Aby dowiedzieć się więcej o narzędziach agenta, zobacz Narzędzia Agenta Sztucznej Inteligencji.

W poniższych sekcjach omówiono trzy wzorce projektowe systemu agentów, z których każdy może na różne sposoby korzystać z narzędzi wywoływania.

Porównanie wzorców projektowych aplikacji sztucznej inteligencji generatywnej

Wzorce projektowe aplikacji generatywnej AI (agenta) są przedstawiane w kolejności wzrastającej złożoności.

Wzorzec projektowy	Kiedy należy używać	Plusy	Minusy
łańcuch deterministyczny	Dobrze zdefiniowane zadania Statyczne rurociągi, takie jak podstawowy RAG Brak potrzeby podejmowania decyzji na bieżąco	Bardzo proste Łatwy w inspekcji	Nieelastyczny Wymaga zmian w kodzie w celu dostosowania
systemu pojedynczego agenta	Od umiarkowanych do złożonych zapytań w tej samej domenie Niektóre dynamiczne decyzje bez nakładu pracy wielu wyspecjalizowanych agentów.	Elastyczny Prostsze niż w przypadku wielu agentów Dobra wartość domyślna	Mniej przewidywalne Musi chronić przed powtarzającymi się lub nieprawidłowymi wywołaniami narzędzi
System wieloagentowy	Duże lub międzyfunkcjonalne domeny; wielu agentów "ekspertów"; odrębne konteksty logiki lub konwersacji; zaawansowane wzorce refleksji.	Wysoce modularne Skalowanie do dużych domen	Trudne do skoordynowania Trudniejsze do śledzenia i debugowania

system pojedynczego agenta

System jednego agenta charakteryzuje się jednym skoordynowanym przepływem logiki — często orkiestrującym wiele wywołań LLM — w celu obsługi przychodzących żądań. Agent może wykonywać następujące czynności:

1. Akceptuj żądania, takie jak zapytania użytkowników i dowolny odpowiedni kontekst, taki jak historia konwersacji.
2. Przemyśl, jak najlepiej odpowiedzieć, rozważając opcjonalnie, czy użyć narzędzi do pozyskiwania danych zewnętrznych lub wykonania działań.
3. W razie potrzeby należy wykonać iterację, wywołując narzędzie LLM (i/lub te same narzędzia) wielokrotnie do momentu osiągnięcia celu lub spełnienia określonego warunku (takiego jak odbieranie prawidłowych danych lub rozwiązywanie błędu).
4. Integruj dane wyjściowe narzędzia do rozmowy.
5. Zwraca spójną odpowiedź jako dane wyjściowe.

W wielu przypadkach użycia pojedyncza runda rozumowania LLM (często z wywoływaniem narzędzi) jest wystarczająca. Jednak bardziej zaawansowani agenci mogą przechodzić w pętli przez wiele kroków, dopóki nie dotrą do żądanego wyniku.

Mimo że istnieje tylko "jeden" agent, nadal można mieć wiele wywołań LLM i narzędzi pod maską (na potrzeby planowania, generowania, weryfikacji itd.), wszystkie zarządzane przez ten pojedynczy, ujednolicony przepływ.

Przykład: Asystent pomocy technicznej

• Jeśli użytkownik zadaje proste pytanie ("Jaka jest nasza polityka zwrotów?"), agent może odpowiedzieć bezpośrednio z wiedzy LLM.
• Jeśli użytkownik chce mieć stan zamówienia, agent wywołuje funkcję lookup_order(customer_id, order_id). Jeśli to narzędzie odpowie za pomocą "nieprawidłowego numeru zamówienia", agent może ponowić próbę lub poprosić użytkownika o prawidłowy identyfikator, kontynuując, aż będzie mógł podać ostateczną odpowiedź.

Kiedy należy używać:

• Oczekujesz różnych zapytań użytkowników, ale nadal w obrębie wspólnej domeny lub obszaru produktu.
• Niektóre zapytania lub warunki mogą uzasadniać użycie narzędzi, takie jak podjęcie decyzji o tym, kiedy pobrać dane klienta.
• Potrzebujesz większej elastyczności niż łańcuch deterministyczny, ale nie wymaga oddzielnych wyspecjalizowanych agentów dla różnych zadań.

Zalety :

• Agent może dostosować się do nowych lub nieoczekiwanych zapytań, wybierając narzędzia (jeśli istnieją) do wywołania.
• Agent może iterować przez powtarzające się wywołania LLM lub użycie narzędzi w celu poprawienia wyników — bez konieczności stosowania pełnej struktury wielu agentów.
• Ten wzorzec projektowy często okazuje się optymalnym rozwiązaniem dla przypadków użycia w przedsiębiorstwach — debugowanie jest prostsze niż w konfiguracjach z wieloma agentami, a jednocześnie możliwa jest dynamiczna logika i ograniczona autonomia.

Rozważania

• Porównując ze sztywno zakodowanym ciągiem, trzeba zabezpieczyć się przed powtarzającymi się lub nieprawidłowymi wywołaniami narzędzi. (Nieskończone pętle mogą występować w dowolnym scenariuszu wywoływania narzędzi, więc ustaw limity iteracji lub ograniczenia czasowe).
• Jeśli aplikacja obejmuje radykalnie różne domeny podrzędne (finanse, devops, marketing itp.), pojedynczy agent może stać się niewygodny lub przeciążony wymaganiami dotyczącymi funkcjonalności.
• Nadal potrzebujesz starannie zaprojektowanych podpowiedzi i ograniczeń, aby zapewnić jego skoncentrowanie i odpowiednie działanie agenta.

łańcuch deterministyczny (kroki zakodowane na sztywno)

W tym wzorcu deweloper definiuje, które składniki są wywoływane, w jakiej kolejności i z jakimi parametrami. Nie ma dynamicznego podejmowania decyzji o tym, które narzędzia wywołać ani w jakiej kolejności. System jest zgodny ze wstępnie zdefiniowanym przepływem pracy dla wszystkich żądań, dzięki czemu jest wysoce przewidywalny.

Często nazywany "łańcuchem", przepływ jest zasadniczo stałym łańcuchem kroków, takich jak:

1. Zawsze pobieraj żądanie użytkownika i odczytuj je z indeksu wektorowego w celu uzyskania odpowiedniego kontekstu.
2. Połącz ten kontekst z żądaniem użytkownika w końcowe wezwanie LLM.
3. Wywołaj LLM i zwróć odpowiedź.

Przykład: podstawowy łańcuch RAG

Determinizowany łańcuch RAG może zawsze:

1. Pobieranie wyników top-k z indeksu wektorowego przy użyciu żądania przychodzącego użytkownika (pobieranie).
2. Formatuj pobrane fragmenty do szablonu monitu (z poprawkami).
3. Przekaż ten rozszerzony monit do modułu LLM (generowanie).
4. Zwróć odpowiedź LLM.

Kiedy należy używać:

• W przypadku dobrze zdefiniowanych zadań z przewidywalnymi przepływami pracy.
• Gdy spójność i inspekcja są najwyższymi priorytetami.
• Jeśli chcesz zminimalizować opóźnienie, unikając wielu wywołań LLM do podejmowania decyzji dotyczących aranżacji.

Zalety :

• Najwyższa przewidywalność i możliwość inspekcji.
• Zazwyczaj mniejsze opóźnienie (mniej wywołań LLM na potrzeby orkiestracji).
• Łatwiejsze do testowania i weryfikowania.

Rozważania

• Ograniczona elastyczność obsługi różnych lub nieoczekiwanych żądań.
• Może stać się skomplikowane i trudne do utrzymania w miarę wzrostu gałęzi logiki.
• Może wymagać znacznej refaktoryzacji, aby obsłużyć nowe możliwości.

system wieloagentowy

System wielu agentów obejmuje co najmniej dwóch wyspecjalizowanych agentów, którzy wymieniają komunikaty i/lub współpracują nad zadaniami. Każdy agent ma własną wiedzę na temat domeny lub zadań, kontekstu i potencjalnie odrębnych zestawów narzędzi. Oddzielny koordynator — który może być innym LLM lub routerem opartym na regułach — kieruje żądania do odpowiedniego agenta lub decyduje, kiedy przekazać je do innego.

Przykład: Asystent przedsiębiorstwa z wyspecjalizowanymi agentami

• Agent obsługi klienta: obsługuje wyszukiwania, zwroty i wysyłkę CRM.
• Agent analizy: Koncentruje się na zapytaniach SQL i podsumowaniu danych.
• Nadzorca/router: Wybiera, który agent jest najlepszy dla danego zapytania użytkownika lub kiedy ma się przełączyć.

Każdy agent podrzędny może wykonywać wywołania narzędzi w ramach własnej domeny (np. lookup_customer_account lub run_sql_query) często wymagających unikatowych monitów lub historii konwersacji.

Kiedy należy używać:

• Masz różne obszary problemów lub zestawy umiejętności, takie jak agent kodowania lub agent finansowy.
• Każdy agent musi mieć dostęp do historii konwersacji lub monitów specyficznych dla domeny.
• Masz tak wiele narzędzi, że upchanie ich wszystkich w schemacie jednego agenta jest niepraktyczne; każdy agent może zarządzać podzbiorem.
• Chcesz zaimplementować refleksję, krytykę lub dwukierunkową współpracę między wyspecjalizowanymi agentami.

Zalety :

• Takie podejście modułowe oznacza, że każdy agent może być opracowywany lub utrzymywany przez oddzielne zespoły, specjalizujące się w wąskiej domenie.
• Może obsługiwać duże, złożone przepływy pracy przedsiębiorstwa, które pojedynczy agent może mieć trudności z zarządzaniem spójnie.
• Ułatwia zaawansowane rozumowanie wieloetapowe lub z wieloma perspektywami — na przykład, jeden agent generuje odpowiedź, a inny ją weryfikuje.

Rozważania

• Wymaga strategii routingu między agentami oraz obciążeń związanych z rejestrowaniem, śledzeniem i debugowaniem w wielu punktach końcowych.
• Jeśli masz wielu agentów podrzędnych i narzędzi, może to być skomplikowane, aby zdecydować, który agent ma dostęp do jakich danych lub interfejsów API.
• Agenci mogą nieskończenie przerzucać między sobą zadania bez rozwiązywania, jeśli nie są starannie ograniczeni.
  • Ryzyko nieskończonych pętli istnieje również w wywoływaniu narzędzi przez pojedynczego agenta, ale ustawienia wieloagentowe dodają kolejną warstwę złożoności debugowania.

Praktyczne porady

Niezależnie od wybranego wzorca projektowego należy wziąć pod uwagę następujące najlepsze rozwiązania dotyczące tworzenia stabilnych, konserwowalnych systemów agentów.

1. Rozpocznij proste: Jeśli potrzebujesz tylko prostego łańcucha, łańcuch deterministyczny jest szybko kompilowany.
2. Stopniowo zwiększaj złożoność: W miarę potrzeby bardziej dynamicznych zapytań lub elastycznych źródeł danych, przejdź do systemu pojedynczego agenta z wywoływaniem narzędzi.
3. Przejdź do wielu agentów: Tylko wtedy, gdy masz wyraźnie różne domeny lub zadania, wiele kontekstów konwersacji lub duży zestaw narzędzi, który jest zbyt duży dla monitu pojedynczego agenta.

Jeśli twój przypadek użycia jest niewielki, na przykład prosty łańcuch RAG, rozpocznij od zakodowanego łańcucha. W miarę rozwoju wymagań można dodać logikę wywoływania narzędzi na potrzeby dynamicznego podejmowania decyzji, a nawet podzielić zadania na wielu wyspecjalizowanych agentów. W praktyce wiele rzeczywistych systemów agentowych łączy wzorce. Na przykład użyj głównie łańcucha deterministycznego, ale w razie potrzeby zezwól usłudze LLM na dynamiczne wywoływanie niektórych interfejsów API w jednym kroku.

Struktura agentów mozaiki sztucznej inteligencji jest niezależna od wybranego wzorca, co ułatwia rozwijanie wzorców projektowych w miarę rozwoju aplikacji.

Wskazówki dotyczące programowania

• podpowiedzi
  • Zadbaj o to, aby polecenia były jasne i zwięzłe, aby uniknąć sprzecznych instrukcji, rozpraszających informacji i zmniejszyć ryzyko wystąpienia halucynacji.
  • Podaj tylko narzędzia i kontekst wymagany przez agenta, a nie niezawiązany zestaw interfejsów API lub duży nieistotny kontekst.
• logowanie & obserwowalność
  • Wdroż szczegółowe rejestrowanie każdego żądania użytkownika, planu działania agenta oraz wywołania narzędzia. Śledzenie MLflow może pomóc w przechwytywaniu dzienników strukturalnych na potrzeby debugowania.
  • Bezpiecznie przechowuj dzienniki i należy pamiętać o danych osobowych (PII) w danych konwersacji.
• Aktualizacje modelu przypinanie wersji &
  • Zachowania LLM mogą się zmieniać, gdy dostawcy aktualizują modele w tle. Użyj przypisywania wersji i częstych testów regresji, aby upewnić się, że logika agenta pozostaje niezawodna i stabilna.
  • Połączenie MLflow z Mosaic AI Agent Evaluation zapewnia usprawniony sposób wersjonowania agentów i regularnego oceniania jakości oraz wydajności.

Wskazówki dotyczące testowania i iteracji

• obsługa błędów & logiki rezerwowej
  • Przygotowanie się na awarie narzędzi lub LLM. Limity czasu, źle sformułowane odpowiedzi lub puste wyniki mogą przerwać przepływ pracy. Uwzględnij strategie ponawiania, logikę powrotu lub prostszy łańcuch rezerwowy, gdy funkcje zaawansowane kończą się niepowodzeniem.
• Iteracyjne inżynieria podpowiedzi
  • Oczekuj, że z czasem będziesz udoskonalać instrukcje i logikę łańcuchową. Wersjonuj każdą zmianę (przy użyciu Git i MLflow), aby móc cofać zmiany lub porównywać wydajność między wersjami.
  • Rozważ użycie struktur, takich jak DSPy do programistycznego optymalizowania poleceń i innych komponentów w systemie agenta.

Wskazówki dotyczące produkcji

• opóźnienie a optymalizacja kosztów
  • Każde dodatkowe wywołanie usługi LLM lub narzędzia zwiększa użycie tokenu i czas odpowiedzi. Jeśli to możliwe, połącz kroki lub buforuj powtarzające się zapytania, aby zapewnić wydajność i zarządzanie kosztami.
• Zabezpieczenia i piaskownica
  • Jeśli agent może zaktualizować rekordy lub uruchomić kod, otocz te działania w piaskownicy lub, w razie potrzeby, wymuś zatwierdzenie przez człowieka. Ma to kluczowe znaczenie w środowiskach korporacyjnych lub regulowanych, aby uniknąć niezamierzonych szkód.
  • Usługa Databricks zaleca narzędzia katalogu Unity do wykonywania w środowisku piaskownicy. Zobacz narzędzia funkcji Unity Catalog vs. narzędzia kodu agenta. Unity Catalog umożliwia izolację dowolnego wykonania kodu i uniemożliwia złośliwym podmiotom nakłanianie agenta do generowania i uruchamiania kodu, który zakłóca lub podsłuchuje inne żądania.

Postępując zgodnie z tymi wytycznymi, można ograniczyć wiele typowych trybów awarii, takich jak błędy narzędzi, dryfujące wydajność usługi LLM lub nieoczekiwane wzrosty kosztów, a także tworzyć bardziej niezawodne, skalowalne systemy agentów.