Orkiestrator i pracownicy

We wzorcu orkiestrator–agenty wykonawcze pojedynczy agent orkiestrator odpowiada za plan i cel, a agenty wykonawcze realizują ograniczone zakresowo podzadania i przekazują wyniki. Orkiestrator dzieli zadanie, przydziela podzadania, integruje wyniki i decyduje, kiedy zadanie jest ukończone.

• Orkiestrator: planowanie, kierowanie, synteza i sterowanie przepływem.
• Agenty wykonawcze: skoncentrowana realizacja w ramach ścisłego kontraktu.

Ta hierarchia skupia podejmowanie decyzji w jednym miejscu, a pracę możliwą do wykonywania równolegle rozdziela między wiele agentów.

Najważniejsza zasada polega na oddzieleniu planowania od wykonywania. Orkiestrator rozumuje o strategii, korzystając z niewielkiego kontekstu wysokiego poziomu, a agenty wykonawcze działają na szczegółowym, lecz wąskim kontekście. Połączenie obu tych zadań odtwarza przeciążonego agenta ogólnego.

Orkiestrator powinien rzadko przetwarzać bezpośrednio surowe wyniki narzędzi — powinien rozumować na podstawie podsumowań agentów wykonawczych.

System jest tak dobry, jak dobra jest dekompozycja orkiestratora. Podzadania muszą być wystarczająco niezależne, aby można je było wykonywać równolegle, mieć na tyle precyzyjnie określony zakres, by można je było bezproblemowo przekazać, i razem obejmować całość zadania. Zanim uruchomisz któregokolwiek agenta wykonawczego, każ orkiestratorowi wygenerować jawny plan, który można sprawdzić.

• Niezależne podzadania -> wykonywanie równoległe.
• Kompletny zakres -> brak luk w odpowiedzi końcowej.

Każde zlecenie przekazuje agentowi wykonawczemu dokładnie jego cel, dane wejściowe i oczekiwany schemat wyjścia — nic więcej. Agent wykonawczy, który zna tylko swój wycinek zadania, nie rozprasza się szerszym celem i zwraca przewidywalny wynik, który orkiestrator może zintegrować.

Komunikat zlecający jest kontraktem: jasno określony rezultat, format i kryteria ukończenia.

Agentom wykonawczym nie należy domyślnie udostępniać pełnego kontekstu pozostałych agentów. Izolacja zapobiega przenoszeniu błędów lub halucynacji jednego agenta na inne i utrzymuje prompt każdego agenta w niewielkim, możliwym do cache'owania rozmiarze. Tylko orkiestrator ma pełny obraz sytuacji.

Udostępniaj agentom informacje wyłącznie za pośrednictwem zweryfikowanych podsumowań orkiestratora, nigdy przez surową komunikację między nimi.

Niezależne podzadania uruchamia się równolegle, aby zmniejszyć opóźnienie, natomiast podzadania zależne muszą zachowywać kolejność. Plan orkiestratora koduje graf zależności, a środowisko wykonawcze odpowiednio planuje zadania — rozdziel niezależne elementy, a następnie je scal.

• Rozgałęzienie (fan-out): zleć jednocześnie wszystkie gotowe podzadania.
• Scalenie (join): zaczekaj na zależności przed zleceniem zadania zależnego.

Integracja nie polega na konkatenacji. Orkiestrator musi uzgodnić nakładające się, sprzeczne lub mało wiarygodne wyniki agentów wykonawczych w jeden spójny rezultat, zdecydować, którym wynikom zaufać, i ujawnić nierozstrzygnięte konflikty.

Dodaj do orkiestratora wyraźny etap uzgadniania z określonymi regułami: preferuj wyniki o większej wiarygodności, oznaczaj sprzeczności i żądaj ponownego uruchomienia, gdy zakres jest niekompletny.

Orkiestrator odpowiada również za sterowanie przepływem: decyduje, kiedy przerwać działanie, kiedy ponowić nieudanego agenta wykonawczego, kiedy ponownie zaplanować zadania i kiedy eskalować problem. To właśnie tutaj należy egzekwować limity — maksymalną liczbę iteracji, maksymalny koszt i maksymalną głębokość — aby zapobiegać niekontrolowanym pętlom.

Bez orkiestratora sprawującego kontrolę systemy wieloagentowe wymykają się spod kontroli.

Agent wykonawczy może sam stać się orkiestratorem podproblemu, tworząc hierarchię. Ułatwia to obsługę złożonych zadań, ale zwiększa opóźnienie i głębokość propagacji błędów. Ogranicz głębokość rekurencji i wymagaj, aby każdy poziom zwracał zwięzłe podsumowanie, tak aby wyższe poziomy nie utonęły w szczegółach z niższych poziomów.

Zaprojektuj system tak, aby awaria pojedynczego agenta wykonawczego powodowała jedynie łagodne pogorszenie działania. Orkiestrator powinien wykrywać niepoprawne lub puste wyniki, ponawiać próbę z doprecyzowanym kontraktem i stosować ścieżkę awaryjną zamiast się zatrzymać. Agenty wykonawcze zawodzą w izolacji, a orkiestrator absorbuje awarię i omija uszkodzony element.

• Sprawdzaj każdy wynik agenta wykonawczego względem jego schematu.
• Najpierw ponów próbę, potem zastosuj ścieżkę awaryjną — nigdy nie przekazuj surowej awarii wyżej.

Schemat wygląda następująco: orkiestrator dzieli zadanie na możliwy do sprawdzenia plan oparty na grafie zależności, przekazuje ścisłe kontrakty odizolowanym agentom wykonawczym, uruchamia niezależne podzadania równolegle, sprawdza i uzgadnia wyniki zgodnie z wyraźnymi regułami rozwiązywania konfliktów, egzekwuje limity i warunki zakończenia oraz izoluje awarie agentów wykonawczych, stosując ponowienie próby, a następnie ścieżkę awaryjną. Podejmowanie decyzji pozostaje scentralizowane, a praca — rozproszona.

Projektuje Pan/Pani system orkiestrator–pracownicy na potrzeby zadania badawczego obejmującego kilka niezależnych podtematów.

Skup planowanie, routing, integrację i kontrolę w jednym orkiestratorze, a ukierunkowane wykonywanie zadań przekaż odizolowanym pracownikom działającym na podstawie ścisłych kontraktów. Rozłóż zadanie na możliwy do sprawdzenia graf zależności, zrównoleglaj niezależne podzadania, uzgadniaj wyniki za pomocą jawnych reguł rozwiązywania konfliktów, egzekwuj budżety i warunki zatrzymania oraz ograniczaj awarie pracowników za pomocą mechanizmu validate-retry-fallback. Orkiestrator rozumuje na podstawie podsumowań, nigdy surowej komunikacji między agentami, dzięki czemu hierarchia pozostaje spójna i możliwa do kontrolowania.