Multiagentní vývoj jako problém distribuovaného konsenzu: FLP a Lamport v akci
Proces multiagentního vývoje se formálně vyjadřuje prostřednictvím množiny platných programů Φ(P), které jsou generovány promptem P. Každý agent generuje úpravu φ_i, a konsenzus je dosažen, pokud všechny φ_i upřesňují jediný φ ∈ Φ(P):
C(φ_1, ..., φ_n) := ∃ φ ∈ Φ(P), ∀i, φ_i refines φBez protokolu agenti soutěží o návrhy: jeden zvolí callback-API, druhý async/await, což vede ke konfliktům v Gitu. Supervizor pro mergování PR problém neřeší, ale jen zakrývá, přičemž ztrácí práci při rebase.
Klíčové podmínky pro FLP:
- Asynchronní doručení: agent rozhoduje, kdy zpracovat zprávu po volání nástroje.
- Crashové selhání: procesy zemřou, cykly visí, pkill přeruší komunikaci.
Věta FLP: nemožnost ideálního konsenzu
FLP (Fischer-Lynch-Paterson, 1985) dokazuje: v asynchronní systému s jedním crashovým selháním nelze zaručit současně bezpečnost (správnost), životaschopnost (pokrok k řešení) a odolnost vůči chybám. Vyberte libovolné dvě — třetí je ztracena.
U agentů se to projevuje cyklem zpětných kroků: agent A pevně stanoví návrh, B jej vrátí zpět, A reaguje. Bez detektoru selhání (Chandra-Toth, 1996) je životaschopnost nedosažitelná. Praxe: příkazy ps | grep pro ověření životnosti sousedů rozšiřují model na částečnou synchronizaci.
Byzantská selhání z důvodu nesprávných promptů
Lamport (1982): při f byzantských agentech (špatně interpretují prompt, generují neslučitelné φ_i) je potřeba n > 3f + 1 agentů pro dosažení konsenzu. Byzantský agent podvodně předstírá řešení, jako generál lžící o hlasování.
Hlasování LLM není efektivní kvůli obrovskému prostoru Φ(P). Řešení: vnější validátory (testy, lintery, verifikace) převádějí byzantská selhání na crashová, snižují systém do FLP-režimu s dobře známými algoritmy (Paxos-like).
Oběti u validátorů:
- Zvyšují bezpečnost, obětují životaschopnost (delší pipeline).
- Sníží byzantské rizika, ale neeliminují FLP.
- Měří se s n, kde f < (n-1)/3.
Praktická pravidla návrhu pipeline
- Detektory selhání jsou povinné: agenty kontrolují pokrok sousedů, aby se vyhnuly zacyklení.
- Rozdělení úkolů: minimalizujte překryvy souborů (worktree-pattern jako tolerance k particii z CAP).
- Časové limity a restarty: částečná synchronizace (Dwork-Lynch-Stockmeyer, 1988) s horními mezemi zpoždění.
- Vnější kontroly mají přednost: testy > koordinace, převádějí selhání.
- Vyhněte se ad-hoc řešením: používejte Paxos/Raft pro explicitní konsenzus.
CAP-věta je aplikovatelná: v multiagentní architektuře je často tolerance k particii obětována za CA (konzistence + dostupnost).
Pokročilé koncepty pro škálování
Společné vědomosti (Halpern-Moses, 1990): «všichni vědí, že všichni vědí» je nedosažitelné bez protokolů – vysvětluje selhání sdílených dokumentů (CLAUDE.md).
Částečná synchronizace: časové limity zvyšují složitost zpráv, ale zajišťují konsenzus.
Tyto nástroje z 40leté teorie umožňují stavět spolehlivé pipeline bez závislosti na AGI-hype.
— Editorial Team
Zatím žádné komentáře.