Każdy chce zbudować zespół agentów AI. Demony wyglądają nieodparcie. Jeden agent prowadzi badania, drugi pisze kod, a trzeci uruchamia testy. Ale większość tych systemów skrywa brudny sekret: są kruche. Działają pięknie podczas pięciominutowej prezentacji, ale rozpadają się podczas rzeczywistego dochodzenia. Punktem awarii rzadko jest zdolność rozumowania modelu językowego lub liczba agentów w roju. Jest nim przestrzeń między nimi. Systemy wieloagentowe zawodzą na płaszczyźnie współpracy.
Pułapka nadzorcy
Domyślna architektura jest kusząco prosta. Agent nadzorujący otrzymuje cel, dzieli go na podzadania i deleguje je do agentów wykonawczych. Wykonawcy realizują zadania, zwracają wyniki, a nadzorca składa wszystko w ostateczną odpowiedź. Ten wzorzec sprawdza się, jeśli streszczasz dziesięć artykułów, transkrybujesz pliki audio lub wyciągasz dane ze stu jednolitych stron internetowych. Zadania są niezależne. Nie wchodzą w interakcję.
Złożone dochodzenia wyglądają inaczej. Kiedy agent odkryje zaskakujący fakt, cały kierunek prac może wymagać zmiany. Jeśli system nie posiada ustrukturyzowanego sposobu na ogłoszenie tej zmiany, pozostali agenci będą kontynuować działania w złym kierunku. Kończysz z kolekcją równoległych monologów zamiast rozmowy. Nadzorca staje się wąskim gardłem, a nie koordynatorem.
Co znika, gdy koordynacja zawodzi
Gdy dochodzenie wchodzi na głębszy poziom, musisz wiedzieć znacznie więcej niż tylko ostateczną odpowiedź. Musisz wiedzieć, kto co wiedział i kiedy. Musisz prześledzić, który fakt wpłynął na kierunek prac. Musisz zrozumieć, dlaczego agent zmienił swój plan dwie godziny temu. Bez płaszczyzny współpracy nic z tego nie jest widoczne. Masz logi. Logi to chronologiczny szum. Rejestrują, że Agent C nagle zaczął analizować transakcje bazy danych zamiast wywołań API, ale nie wyjaśniają dlaczego. Możesz obserwować to, co się dzieje, i zgadywać.
Wyobraź sobie reagowanie na incydent bezpieczeństwa. Agent A analizuje logi serwera i dochodzi do wniosku, że naruszenie nie zaczęło się w tym miejscu. Zwraca swój wynik do nadzorcy. Agent B, przydzielony do analizy ruchu sieciowego, nigdy nie widzi tego wniosku przedstawionego jako odrzucona hipoteza. Ponieważ jego pierwotny opis zadania wciąż traktuje serwer jako głównego podejrzanego, Agent B marnuje kolejny cykl na szukanie śladów w tych samych logach. System płaci dwa razy za tę samą pracę i nie uczy się niczego z pierwszego podejścia.
Płaszczyzna współpracy to nie pamięć
Płaszczyzna współpracy to nie tylko pojemnik na fakty w pamięci. Pamięć przechowuje informacje. Stan współpracy przechowuje prace w toku. Baza wektorowa pełna dokumentów dostarcza agentowi materiałów referencyjnych. Nie mówi jednak agentowi, że Agent X testuje obecnie hipotezę, która sprawiłaby, że obecne zadanie Agenta Y stałoby się zbędne. Pamięć to statyczny kontekst. Stan współpracy to żywa mapa operacji.
Jeśli pomylisz te dwie rzeczy, zbudujesz systemy, które potrafią przywołać każdy akapit podręcznika firmy, ale nie powiedzą ci, czy inny agent właśnie nie udowodnił, że twoje obecne zadanie jest nieistotne.
Pięć pojemników stanu współdzielonego
Prawdziwa płaszczyzna współpracy potrzebuje pięciu konkretnych pojemników.
Tezy (Claims). Są to aktywne hipotezy, które testuje agent. W dochodzeniu dotyczącym oszustw teza może brzmieć: „anomalia koreluje z zadaniami wsadowymi wykonywanymi w weekendy”. Każdy agent powinien mieć możliwość zobaczenia, które tezy są otwarte, które są testowane i kto za nie odpowiada. Bez