Wieloagentowość jako FLP: granice koordynacji AI

Rozwój wieloagentowy jako problem konsensusu rozproszonego: FLP i Lamport w działaniu

Proces rozwoju wieloagentowego formalizuje się poprzez zbiór poprawnych programów Φ(P), generowanych przez prompt P. Każdy agent generuje ulepszenie φ_i, a konsensus jest osiągnięty, jeśli wszystkie φ_i ulepszają jedno φ ∈ Φ(P):

C(φ_1, ..., φ_n) := ∃ φ ∈ Φ(P), ∀i, φ_i refines φ

Bez protokołu agenci rywalizują o rozwiązania projektowe: jeden wybiera API z callbackami, drugi — async/await, co prowadzi do konfliktów w Git. Nadzorowanie mergowania PR nie rozwiązuje problemu, tylko go maskuje, tracąc pracę przy rebase.

Kluczowe założenia FLP:

• Asynchroniczna dostawa: agent decyduje, kiedy przetworzyć wiadomość po wywołaniu narzędzia.
• Awarie typu crash: procesy zginają, pętle zawieszały się, pkill zerwało komunikację.

Twierdzenie FLP: niemożliwość idealnego konsensusu

FLP (Fischer-Lynch-Paterson, 1985) dowodzi: w systemie asynchronicznym z jednym awarią typu crash nie da się zagwarantować bezpieczeństwa (safety), żywotności (liveness) i odporności na błędy jednocześnie. Wybierz dowolne dwa — trzeci zostaje utracony.

W przypadku agentów to cykl cofania: agent A ustala projekt, B cofa się, A reaguje. Bez detektora awarii (Chandra-Toth, 1996) żywotność jest niemożliwa do osiągnięcia. Praktyka: polecenia ps | grep do sprawdzania żywotności sąsiadów rozszerzają model do częściowej synchroniczności.

Wizantyjskie awarie spowodowane błędnie sformułowaniem promptów

Lamport (1982): przy f agencie wizantyjskich (niepoprawnie interpretujących prompt, generując niezgodne φ_i) wymagane jest n > 3f + 1 agentów do osiągnięcia konsensusu. Agent wizantyjski fałszuje rozwiązania, jak generał kłamiący o głosowaniu.

Głosowanie LLM jest nieefektywne z powodu ogromnego zbioru Φ(P). Rozwiązanie: zewnętrzni walidatorzy (testy, linterzy, weryfikacja) zamieniają awarie wizantyjskie na awarie typu crash, redukując system do trybu FLP z znanymi algorytmami (typu Paxos).

Zalety i koszty walidatorów:

• Zwiększają bezpieczeństwo, ofiarowując żywotność (dłuższy pipeline).
• Zmniejszają ryzyko wizantyjskie, ale nie eliminują ograniczeń FLP.
• Skalują się z n, gdzie f < (n-1)/3.

Prawa praktyczne projektowania pipeline'ów

• Detektory awarii są obowiązkowe: agenci sprawdzają postęp sąsiadów, unikając zawieszeń.
• Podział zadań: minimalizuj nakładanie się plików (worktree-pattern jako tolerancja partycji z CAP).
• Timeouty i restarty: częściowa synchroniczność (Dwork-Lynch-Stockmeyer, 1988) z górnymi granicami opóźnień.
• Sprawdzanie zewnętrzne jako priorytet: testy > koordynacja, zamieniają awarie.
• Unikaj ad-hoc: stosuj Paxos/Raft dla jawnej koordynacji.

Twierdzenie CAP ma zastosowanie: w rozwoju wieloagentowym często ofiarowuje się tolerancję partycji, by zachować CA (spójność + dostępność).

Zaawansowane koncepcje dla skalowania

Common Knowledge (Halpern-Moses, 1990): «wszyscy wiedzą, że wszyscy wiedzą» jest niemożliwe bez protokołów — tłumaczy porażki dokumentów współdzielonych (CLAUDE.md).

Częściowa synchroniczność: timeouty zwiększają złożoność komunikacji, ale zapewniają konsensus.

Te narzędzia z 40-letniej teorii pozwalają budować niezawodne pipeline'y, nie polegając na haju AGI.

Co ważne

• Rozwój wieloagentowy to konsensus rozproszony z ograniczeniami FLP/CAP, niezależnym od modelu.
• Walidatory (testy, linterzy) zamieniają awarie wizantyjskie na awarie typu crash, czyniąc system zarządzalny.
• Detektory awarii i podział zadań to minimalny zestaw do środowiska produkcyjnego.
• n > 3f + 1 dla odporności na niepoprawne interpretacje promptów.
• AGI poprawi stałe, ale nie zmieni granic niemożliwości.

— Editorial Team