Kto zatwierdza działanie zespołu agentów?

Kilka współpracujących modeli może przygotować plan, zebrać dane i sprawdzić propozycję. Żaden z tych kroków sam w sobie nie wskazuje jednak, kto w organizacji zgadza się na skutek działania. Komunikat „kontroler zaakceptował” bywa mylący, jeśli kontroler jest kolejnym agentem, a jego sprawdzenie nie obejmuje uprawnień ani aktualności danych.

Praktyczna etyka AI zaczyna się od odpowiedzialności za skutek i możliwości odtworzenia decyzji. W zespole agentów warto przełożyć to na prostą zasadę: każda operacja zmieniająca sytuację użytkownika ma określonego właściciela, warunek wykonania i ścieżkę wyjaśnienia. Liczba modeli nie zastępuje żadnego z tych elementów.

Najpierw właściciel skutku, potem podział ról

Właścicielem nie jest nazwa komponentu w diagramie, lecz osoba lub rola organizacyjna, która może zdecydować o regule i przyjąć zgłoszenie problemu. Inna osoba może utrzymywać narzędzie, a inna oceniać poprawność danych. Te obowiązki trzeba rozdzielić, ale nie rozproszyć do punktu, w którym nikt nie odpowiada za końcowy rezultat.

Przed rozbudową architektury sprawdźcie, czy podział rzeczywiście pomaga. Poradnik o systemie multi-agent opisuje sytuacje, w których odrębne role mają sens. Tutaj zakładamy, że ten wybór już podjęto, i zajmujemy się konkretnym przejściem od propozycji kilku agentów do wykonania operacji.

Właściciel procesu powinien określić, które skutki wymagają indywidualnego zatwierdzenia, a które mogą wynikać z wcześniej przyjętej reguły. Zespół techniczny musi potem wskazać miejsce sprawdzania tych warunków. Sam podział agentów na planistę, wykonawcę i recenzenta nie dowodzi, że istnieje niezależna kontrola.

Przykład: zatwierdzenie przesyłki zastępczej

Rozważmy autorski przykład projektowy dotyczący uszkodzonego akcesorium. Pierwszy agent zbiera opis sprawy, drugi sprawdza dostępność zamiennika, a trzeci przygotowuje propozycję wysyłki. Operator zatwierdza wskazany produkt i adres. Przykład nie opisuje istniejącego wdrożenia ani rzeczywistych wyników organizacji.

Zgoda powinna dotyczyć konkretnej propozycji: sprawy, produktu, liczby sztuk i odbiorcy. Jeżeli po akceptacji zmieni się adres albo zamiennik, poprzednie potwierdzenie nie powinno bezwarunkowo obejmować nowej wersji. System musi rozpoznać zmianę i ponownie ocenić wymaganie zgody.

Właśnie tutaj ujawnia się różnica między zatwierdzeniem planu a zatwierdzeniem skutku. Zdanie „rozwiąż problem klienta” wyznacza cel, lecz nie daje dowolności w zamawianiu towaru. Osoba zatwierdzająca powinna zobaczyć, co zostanie wykonane, na podstawie jakich danych i czego wciąż nie udało się ustalić.

Karta przekazania między agentami

Przekazanie zadania warto opisać jako mały, sprawdzalny komunikat. Nie musi zawierać pełnej historii rozmowy. Powinno natomiast zachowywać informacje potrzebne do oceny następnego działania, wraz z ograniczeniami poprzedniego etapu.

• Cel: przygotowanie jednej przesyłki zastępczej w ramach wskazanej sprawy.
• Dowody: identyfikatory sprawdzonych rekordów i czas ich odczytu.
• Propozycja: konkretny produkt, ilość oraz odbiorca, bez niejawnych wartości domyślnych.
• Niepewność: brakujące potwierdzenia lub sprzeczności, których nie rozwiązano.
• Upoważnienie: rodzaj zgody, osoba zatwierdzająca i wersja propozycji objęta decyzją.
• Zakończenie: oczekiwane potwierdzenie zapisu oraz miejsce skierowania wyjątku.

Agent odbierający komunikat nie powinien dostawać szerszych praw tylko dlatego, że poprzedni agent poprosił o pomoc. Zakres uprawnień wynika z konfiguracji wykonania i zasad procesu. Instrukcja przekazana w treści sprawy nie jest równoważna z upoważnieniem do zmiany adresu czy wysłania towaru.

W karcie trzeba odróżnić fakt od interpretacji. „Magazyn potwierdził dostępność” powinno wskazywać odczyt źródłowy. „Prawdopodobnie można wysłać” jest oceną wymagającą dalszego sprawdzenia. Gdy te dwa rodzaje informacji zostaną połączone w gładkie podsumowanie, kolejny agent może potraktować przypuszczenie jak zatwierdzony warunek.

Co zrobić, gdy agenci się nie zgadzają

Spór powinien mieć znaną ścieżkę rozstrzygnięcia. Jeśli jeden agent widzi inny adres niż drugi, dodatkowa runda uzgadniania nie musi prowadzić do prawdy. Trzeba sprawdzić źródła, czas odczytu i regułę pierwszeństwa. Przy braku rozstrzygnięcia sprawa trafia do operatora z opisem rozbieżności, nie z pozornie ujednoliconym wynikiem.

Ustalcie również warunek zatrzymania, gdy nie ma postępu. Powtarzanie tego samego pytania kolejnym modelom może zwiększyć koszt, a nadal nie dostarczyć brakującego potwierdzenia. Ograniczenie liczby etapów oraz wskazanie odpowiedzialnego odbiorcy wyjątku daje pracownikowi jasny punkt przejęcia.

Zakres samodzielności warto odnieść do opisanych poziomów autonomii agentów AI. Nie trzeba nadawać całemu systemowi jednego poziomu. Odczyt danych, przygotowanie propozycji i wykonanie przesyłki mogą mieć różne warunki kontroli, odpowiednie do swoich skutków.

Ślad decyzji i przegląd po wykonaniu

Po zakończeniu sprawy powinno być możliwe ustalenie, jaka propozycja została zatwierdzona, kto miał do tego prawo i jaki wynik potwierdził system wykonawczy. Nie wymaga to gromadzenia wszystkich danych ani prywatnego toku rozumowania modeli. Potrzebny jest wystarczający, kontrolowany zapis zdarzeń, dostępny osobom obsługującym proces.

Przed uruchomieniem przejdźcie przez próbę zmiany adresu po akceptacji, wygaśnięcia zgody i braku potwierdzenia wysyłki. Sprawdźcie też, czy operator może zatrzymać oczekującą operację i rozpoznać te, które już wykonano. Cofnięcie zgody nie oznacza automatycznie cofnięcia skutku; obsługa takiej sytuacji wymaga osobnej procedury.

Na przeglądzie nie pytajcie wyłącznie, czy agenci byli zgodni. Zapytajcie, czy osoba zatwierdzająca miała dostateczne informacje i czy odbiorca może zgłosić błąd do właściwego zespołu. Odpowiedzialny układ wieloagentowy jest czytelny także dla człowieka stojącego poza jego architekturą: wiadomo, co zrobiono, dlaczego wolno było to zrobić i kto zajmie się korektą.