Wieloagentowa deliberacja: kiedy zgoda jest błędem

Najniebezpieczniejsze dane wyjściowe mojego agenta AI to nie błąd. Błędy są łatwe. Lintery wyłapują pomyłki składniowe, zestawy testów wyłapują regresje, a 95 hooków, które zbudowałem, wyłapuje except: pass i wymuszone pushe. Niebezpieczne dane wyjściowe to pewna siebie, dobrze uzasadniona rekomendacja, która akurat jest błędna.

Poprosiłem pojedynczego agenta o przegląd endpointu API pod kątem bezpieczeństwa. Agent sprawdził uwierzytelnianie, zwalidował sanityzację danych wejściowych i zweryfikował nagłówki CORS. Czyste świadectwo zdrowia. Drugi agent, wywołany osobno jako tester penetracyjny, odkrył, że endpoint akceptuje nieograniczone parametry zapytania, które mogą wywołać odmowę usługi poprzez amplifikację zapytań do bazy danych. Pierwszy agent nigdy tego nie sprawdził, ponieważ nic w jego ramach ewaluacji nie traktowało złożoności zapytań jako powierzchni ataku.

Ta luka jest strukturalna. Żadna ilość inżynierii promptów jej nie naprawi, ponieważ ograniczenie nie tkwi w prompcie. Ograniczenie polega na tym, że jedna perspektywa ocenia wielowymiarowy problem.

Zbudowałem system wieloagentowej deliberacji, aby tę lukę zamknąć. Agenci z różnymi personami badają niezależnie, debatują nad ustaleniami i osiągają konsensus poprzez ustrukturyzowane głosowanie. System uruchamia 141 testów, wymusza izolację kontekstu między agentami i wykorzystuje dwubramową architekturę walidacji, która blokuje przedwczesną zgodę.

TL;DR

Jednoagentowe systemy AI mają strukturalny martwy punkt: nie potrafią zakwestionować własnych założeń. Pętla Ralph uruchamiająca Sonnet generuje kod za 10 dolarów na godzinę, ale każdy martwy punkt modelu jest dostarczany w tym samym tempie. Wieloagentowa deliberacja wymusza niezależną ewaluację z wielu perspektyw, zanim jakakolwiek decyzja zostanie zatwierdzona. Moja implementacja wykorzystuje 10 person badawczych, 7-fazową maszynę stanów i dwie bramy walidacyjne (konsensus + kontrola jakości) działające na hookach Claude Code. System uruchamia się przy decyzjach o niskiej pewności (poniżej 0,70) i dodaje mniej więcej 3-krotny koszt tokenów na deliberację. Dla decyzji bezpieczeństwa, wyborów architektonicznych i czegokolwiek nieodwracalnego ten koszt zwraca się za pierwszym razem, gdy system wyłapie coś, co umknęło pojedynczemu agentowi. Dla poprawek dokumentacji i rutynowych edycji deliberację można całkowicie pominąć.

Noc, kiedy moi agenci zgodzili się wszystko zepsuć

Luty 2026. Wtorek. Poprosiłem mojego agenta, aby „zbadał możliwości poprawy systemu dyspozycji hooków”, i poszedłem zrobić kawę. Agent ocenił własną pewność na 0,58 (poniżej progu 0,70), co uruchomiło deliberację. System uruchomił 3 agentów badawczych. Każdy agent badawczy ocenił problem, znalazł podproblemy i uruchomił własnych agentów badawczych. Ci agenci uruchomili kolejnych.

Siedem minut później: 23 aktywne procesy agentów. 4,80 dolara w kredytach API spalonych. Katalog ~/.claude/state/ zapełniający się plikami stanu JSON, ponieważ każdy agent sumiennie utrwalał swoje ustalenia. Zużycie tokenów rosnące w tempie około 0,70 dolara na minutę bez oznak konwergencji.

Zabezpieczenie przed rekurencją, które zbudowałem dla systemu jakości, śledziło głębokość (rodzic tworzy dziecko, dziecko tworzy wnuka), ale nie szerokość (rodzic tworzy 12 dzieci, z których każde tworzy kolejnych 12). Limit głębokości wynoszący 3 nigdy nie został wyzwolony, ponieważ agenci rozrastali się horyzontalnie. Zabiłem procesy ręcznie i wpatrzyłem się w pliki stanów.

Każdy agent zgadzał się, że system dyspozycji hooków wymaga poprawy. Każdy agent proponował rozsądnie brzmiące zmiany. Żaden agent nie zakwestionował, czy samo badanie było prawidłowo określone. Dwudziestu trzech agentów osiągających konsensus w niewłaściwej kwestii.

Naprawa zajęła 20 minut: budżet spawnowania, który śledzi łączną liczbę aktywnych dzieci na rodzica, ograniczony do 12. Głębsza lekcja wymagała więcej czasu. Krzywa przyspieszenia infrastruktury, którą udokumentowałem, umożliwiła zbudowanie systemu deliberacji w 2 tygodnie, właśnie dlatego, że infrastruktura hooków już istniała. Ale szybka konstrukcja nie zapobiega awariom strukturalnym. Progresja od jednoagentowych pipeline’ów RAG do systemów autonomicznych podąża przewidywalnym łukiem. Wieloagentowa deliberacja znajduje się na końcu nie bez powodu: buduje się ją dopiero po tym, jak pojedynczy agent z pewnością dostarczy błędną odpowiedź.

Zgoda, a nie niezgoda, była niebezpiecznym trybem awarii.

Anatomia deliberacji

System ma dwa komponenty strukturalne: maszynę stanów, która sekwencjonuje pracę, oraz dwie bramy walidacyjne, które zapobiegają dostarczeniu błędnego konsensusu.

Maszyna stanów

Siedem faz, każda uzależniona od poprzedniej:

IDLE -> RESEARCH -> DELIBERATION -> RANKING -> PRD_GENERATION -> COMPLETE
                                                                    |
                                                              (or FAILED)

RESEARCH: Niezależni agenci badają temat. Każdy agent otrzymuje inną personę (Architekt Techniczny, Analityk Bezpieczeństwa, Inżynier Wydajności i 7 innych). Izolacja kontekstu zapewnia, że agenci nie mogą widzieć wzajemnych ustaleń podczas badania. L0 (reguły systemowe) i L1 (kontekst projektu) są współdzielone. L2 (specyficzny fokus agenta) jest prywatny. L3 (wzorce domenowe) ładuje odpowiednie biblioteki wzorców dla każdej persony.¹

DELIBERATION: Agenci widzą wszystkie ustalenia badawcze i generują alternatywy. Agent Debaty identyfikuje konflikty między perspektywami. Agent Syntezy łączy niesprzeczne ustalenia.

RANKING: Każdy agent ocenia każde proponowane podejście w 5 ważonych wymiarach:

Ważone oceny agregują się w wynik konsensusu. Próg jest adaptowany do zadania: 0,85 dla decyzji bezpieczeństwa, 0,80 dla architektury, 0,70 domyślnie, 0,65 dla refaktoryzacji, 0,50 dla dokumentacji.²

Dwie bramy

Brama 1: Walidacja konsensusu (hook PostToolUse:Task). Cztery kontrole uruchamiają się po zakończeniu pracy każdego agenta deliberacji:

1. Faza musi osiągnąć co najmniej RANKING
2. Minimum 2 agentów zakończonych (konfigurowalne)
3. Wynik konsensusu spełnia próg adaptowany do zadania
4. Jeśli któryś agent wyraził sprzeciw, jego obawy muszą być udokumentowane

Niezdanie którejkolwiek kontroli blokuje postęp deliberacji.³

Brama 2: Kontrola jakości (hook Stop). Pięć kontroli jakości uruchamia się przed zamknięciem sesji:

1. Różnorodność metod: Reprezentacja wielu unikalnych person
2. Transparentność sprzeczności: Sprzeciwy mają udokumentowane powody
3. Obsługa złożoności: Wygenerowano co najmniej 2 alternatywy
4. Pewność konsensusu: Wynik sklasyfikowany jako silny (powyżej 0,85) lub umiarkowany (0,70-0,84)
5. Dowody poprawy: Końcowa pewność przewyższa początkową pewność

Dwubramowa architektura wychwytuje problemy na różnych etapach. Brama 1 zapobiega przedwczesnej konwergencji podczas procesu. Brama 2 zapobiega dostarczeniu wyników, które wyglądają na kompletne, ale brakuje im rygorystyczności.

Analitycy wywiadu mieli ten problem jako pierwsi

Zbudowałem system deliberacji w styczniu 2026. Dwa tygodnie później znalazłem książkę Richardsa Heuera Psychology of Intelligence Analysis na liście lektur o ustrukturyzowanym podejmowaniu decyzji. Rozdział 8 opisuje Analysis of Competing Hypotheses (ACH): analitycy oceniają dowody względem wielu hipotez jednocześnie, zamiast budować argumentację na rzecz preferowanego wniosku.⁴

Podobieństwo było niekomfortowe. Framework Heuera, opublikowany w 1999 roku dla CIA, adresował tę samą strukturalną awarię, którą debugowałem: inteligentni ludzie zbiegający się ku jednemu wyjaśnieniu, ponieważ nigdy nie zmusili się do ewaluacji alternatyw.

Oto jak ACH wygląda w praktyce. Analityk wywiadu badający podejrzany program zbrojeniowy nie pyta „czy to jest program zbrojeniowy?” (błąd konfirmacji). Zamiast tego analityk wymienia każdą wiarygodną hipotezę (program zbrojeniowy, badania cywilne, obiekt podwójnego zastosowania), ocenia każdy element dowodowy względem każdej hipotezy i identyfikuje, które dowody najlepiej odróżniają poszczególne hipotezy.

Mój system robi to samo innymi słowami. Trzech agentów ocenia proponowaną zmianę schematu bazy danych. Agent A (Architekt Techniczny) pisze: „Schemat jest czysty, znormalizowany do 3NF.” Agent B (Inżynier Wydajności) pisze: „Wzorce zapytań będą wymagać złączeń przez 4 tabele przy każdym odczycie.” Agent C (Analityk Bezpieczeństwa) pisze: „Pola PII nie są szyfrowane w spoczynku.” Ten sam schemat, trzy różne oceny, trzy elementy dowodowe rozróżniające. Faza rankingu ocenia proponowane podejście względem tych niezależnych ocen, tak jak ACH ocenia hipotezy względem dowodów.

Nie zaprojektowałem systemu na podstawie frameworku Heuera. Odkryłem podzbiór ACH metodą prób i błędów, a potem dowiedziałem się, że ktoś już napisał podręcznik. Uczciwa wersja jest bardziej użyteczna niż pochlebna: niezależne dojście do tej samej architektury potwierdza, że problem leżący u podstaw jest realny, nie teoretyczny.

Dlaczego zgoda jest niebezpiecznym trybem awarii

Charlan Nemeth badała sprzeciw mniejszości od 1986 roku aż po swoją książkę z 2018 roku In Defense of Troublemakers. Grupy z osobami wyrażającymi sprzeciw podejmują lepsze decyzje niż grupy, które szybko osiągają zgodę. Osoba wyrażająca sprzeciw nie musi mieć racji. Sam akt niezgody zmusza większość do zbadania założeń, które w przeciwnym razie zostałyby pominięte.⁵

James Surowiecki w The Wisdom of Crowds identyfikuje cztery warunki mądrych decyzji grupowych: różnorodność opinii, niezależność osądu, decentralizację i mechanizm agregacji.⁶ Naruszenie niezależności (pozwolenie agentom na widzenie wzajemnej pracy podczas badań) prowadzi do stadności. Naruszenie różnorodności (użycie identycznych promptów dla każdego agenta) prowadzi do komór echa.

Przetestowałem warunek niezależności bezpośrednio. Dwóch agentów oceniających tę samą strategię wdrożenia z widocznością wzajemnych ustaleń: Agent A ocenił ryzyko na 0,45. Agent B zobaczył tę ocenę i wygenerował 0,48. Ci sami agenci bez widoczności: 0,45 i 0,72. Różnica między 0,48 a 0,72 to koszt stadności. Niezależna ocena Agenta B sygnalizowała ryzyko orkiestracji kontenerów, które zniknęło, gdy presja społeczna wkroczyła do ewaluacji.

Najnowsze badania potwierdzają, że oba wzorce dotyczą agentów LLM. Choi i in. na NeurIPS 2025 stwierdzili, że głosowanie większościowe wśród niezależnie promptowanych agentów wychwytuje większość zysków jakościowych z systemów wieloagentowych.⁷ Kaesberg i in. na ACL 2025 skwantyfikowali podział: głosowanie poprawia zadania rozumowania o 13,2%, podczas gdy protokoły konsensusu poprawiają zadania wiedzy o 2,8%.⁸ Sugeruje to, że wybór powinien zależeć od typu zadania. Dlatego mój system używa progów adaptowanych do zadania zamiast jednej liczby konsensusu.

Wu i in. przetestowali, czy agenci LLM potrafią naprawdę debatować, i stwierdzili, że bez strukturalnych zachęt do niezgody agenci zbiegają się ku najbardziej pewnie brzmiącej początkowej odpowiedzi, niezależnie od jej poprawności.⁹ Wynn i in. poszli dalej: debata może być aktywnie szkodliwa. Modele zmieniają zdanie z poprawnych na niepoprawne odpowiedzi w reakcji na rozumowanie partnerów, nawet gdy silniejsze modele przewyższają liczebnością słabsze.¹⁰ Liang i in. zidentyfikowali pierwotną przyczynę jako „Degenerację Myśli”: gdy LLM utrwali pewność co do stanowiska, autorefleksja nie jest w stanie wygenerować nowych kontrargumentów, co sprawia, że wieloagentowa ewaluacja jest strukturalnie niezbędna.¹¹

Mój system adresuje niezależność poprzez izolację kontekstu (warstwy L2 są prywatne dla agenta podczas badań). Różnorodność pochodzi z 10 odrębnych person o różnych priorytetach ewaluacji. Agregacja wykorzystuje ważone oceny w 5 wymiarach zamiast prostego głosowania. Strukturalna zachęta do niezgody jest słabsza: śledzę, czy sprzeciw jest udokumentowany, ale nie nagradzam agentów za wyrażanie sprzeciwu. Moduł wykrywania konformizmu próbuje adresować tę lukę, z mieszanymi wynikami.

Wykrywanie fałszywej niezgody

Moduł konformizmu śledzi wzorce sugerujące, że agenci zgadzają się bez rzeczywistej ewaluacji. Udokumentowane obawy powtarzające ten sam język u różnych agentów, oceny podejrzanie skupione blisko progu lub jednomyślne poparcie ze strony każdej persony (Analityk Bezpieczeństwa i Inżynier Wydajności rzadko zgadzają się we wszystkim) wyzwalają ostrzeżenia.

Co wyłapuje: szablonowy sprzeciw (agenci kopiujący nawzajem język obaw), klasteryzacja ocen (każdy agent oceniający w zakresie 0,3 punktu na 10-punktowej skali) i brak perspektyw mniejszościowych (jednomyślna aprobata od person o sprzecznych priorytetach).

Przykład z moich logów: pięciu agentów oceniało refaktoryzację uwierzytelniania. Wszyscy pięciu oceniło ryzyko bezpieczeństwa między 7,1 a 7,4. Detektor konformizmu oznaczył klaster. Gdy ponownie uruchomiłem ze świeżą izolacją kontekstu (czyszcząc pamięci podręczne L2), oceny rozłożyły się na 5,8-8,9. Oryginalny klaster odzwierciedlał zanieczyszczenie wspólnym kontekstem, a nie rzeczywistą zgodę.

Czego nie wyłapuje: wyrafinowaną zgodę, w której agenci naprawdę oceniają z perspektywy swojej persony, ale przypadkiem dochodzą do tego samego wniosku z różnych powodów. Moduł nie potrafi odróżnić realnego konsensusu od stadności, gdy rozumowanie wygląda na niezależne. Próbowałem wytrenować klasyfikator na przykładach prawdziwej vs. sztucznie wytworzonej zgody, ale dane treningowe były zbyt małe (poniżej 50 sesji deliberacji), a sygnał zbyt słaby. Detektor konformizmu wyłapuje oczywiste przypadki i pomija subtelne.

Uczciwa ocena: wykrywanie konformizmu dodaje użyteczną kontrolę rozsądku w 10-15% deliberacji, w których agenci zbiegają się zbyt szybko. W pozostałych 85-90% bramy konsensusu i kontroli jakości zapewniają wystarczającą walidację. Rozważałem budowę bardziej wyrafinowanego systemu konformizmu i zdecydowałem, że nakład inżynieryjny nie odpowiadałby marginalnemu usprawnieniu.

Co nie zadziałało

Ślepy zaułek 1: Swobodne rundy debat

Pierwsza wersja pozwalała agentom pisać długie odpowiedzi na ustalenia innych: 3 rundy wymiany tekstów. Obserwowałem deliberację na temat strategii indeksowania bazy danych rozgrywającą się na przestrzeni 7 500 tokenów debaty. Runda 1: prawdziwa niezgoda co do indeksów złożonych vs. jednokolumnowych. Runda 2: powtórzone stanowiska z niewielkim rozwinięciem. Runda 3: niemal identyczne argumenty opakowane w inne słowa. Sygnał osiągnął szczyt w rundzie 1 i od tego momentu degradował.

Koszt tokenów na deliberację osiągnął 2-4 dolary, a użyteczna gęstość informacji spadała z każdą rundą. Rozwiązanie: ustrukturyzowane oceny wymiarowe zastąpiły swobodną debatę. Agenci oceniają propozycje w 5 wymiarach wartościami numerycznymi zamiast pisać eseje. Koszt i czas spadły o około 60%, a jakość końcowego rankingu faktycznie się poprawiła, ponieważ oceny numeryczne wymuszają precyzję, którą proza zamazuje.

Ślepy zaułek 2: Rekurencja oparta na głębokości dla deliberacji

Incydent z nieskończonym spawnowaniem ujawnił fundamentalny błąd modelowania. Zabezpieczenie przed rekurencją śledziło głębokość: rodzic na głębokości 0 tworzy dziecko na głębokości 1, dziecko tworzy wnuka na głębokości 2, maksymalna głębokość 3. Ale agenci deliberacji powinni rozgałęziać się szeroko (10 agentów badawczych na tym samym poziomie), a nie głęboko (jeden agent tworzący jedno dziecko tworzące jednego wnuka). Limit głębokości wynoszący 3 nigdy nie został wyzwolony, ponieważ 23 agentów na głębokości 1 to nadal „głębokość 1”.

Rozwiązaniem był model budżetu spawnowania: agenci deliberacji dziedziczą głębokość rodzica zamiast ją inkrementować i współdzielą łączny budżet spawnów dzieci ograniczony do 12. Model budżetowy mapuje się do rzeczywistego trybu awarii (zbyt wiele agentów łącznie), a nie do metryki zastępczej (zbyt wiele poziomów zagnieżdżenia). Rodowód agentów jest śledzony w pliku JSON, aby budżet przetrwał asynchroniczne zakończenia agentów.¹²

Ślepy zaułek 3: Pojedyncza brama walidacji

Pierwsza implementacja uruchamiała jeden hook walidacyjny na końcu sesji, łącząc kontrole konsensusu z kontrolami jakości. Tryb awarii pojawił się w ciągu pierwszego tygodnia. Agent zakończył deliberację z wynikiem konsensusu 0,52 — poniżej progu 0,70. Następnie kontynuował niepowiązane zadania przez 20 minut, zanim hook końca sesji oznaczył awarię. Dwadzieścia minut pracy zbudowanej na fundamencie, który nie przeszedł walidacji.

Podział na dwie bramy rozwiązał problem chronometrażu. Brama 1 (walidacja konsensusu) uruchamia się jako hook PostToolUse:Task, wyłapując zły konsensus natychmiast po zakończeniu pracy agenta deliberacji. Brama 2 (kontrola jakości) uruchamia się na końcu sesji, wyłapując problemy jakościowe, które nagromadziły się w kolejnych krokach. Dwa hooki w różnych punktach cyklu życia odpowiadają temu, jak awarie faktycznie występują: niektóre są natychmiastowe (zły wynik), a inne stopniowe (niska różnorodność, brak dokumentacji sprzeciwu).

Uczciwa matematyka

Deliberacja kosztuje tokeny. Każdy agent badawczy przetwarza około 5 000 tokenów kontekstu i generuje 2 000-3 000 tokenów ustaleń. Przy 3 agentach (minimum dla użytecznej deliberacji) to 15 000-24 000 dodatkowych tokenów na decyzję. Przy 10 agentach (pełny panel badawczy) około 50 000-80 000 tokenów.

Przy cenach Opus (15/75 dolarów za milion tokenów) deliberacja 3 agentów kosztuje około 0,68-0,90 dolara. Deliberacja 10 agentów kosztuje 2,25-3,00 dolary. Mój system uruchamia deliberację przy około 10% decyzji (tych z oceną poniżej 0,70 pewności), więc zamortyzowany koszt wszystkich decyzji wynosi 0,23-0,30 dolara na sesję.

Czy to się opłaca, zależy od tego, ile kosztuje zła decyzja. Przeoczona luka bezpieczeństwa we wdrożeniu produkcyjnym kosztuje godziny reakcji na incydent. Zły wybór architektoniczny kosztuje tygodnie refaktoryzacji. Literówka w dokumentacji nie kosztuje nic.

Moduł pewności określa, które decyzje uruchamiają deliberację. Cztery wymiary (niejednoznaczność, złożoność, stawka i zależność kontekstowa) generują po ocenie w skali 0-1. Wiele wymiarów musi uzyskać wysokie oceny, aby ogólna pewność spadła poniżej 0,70 i uruchomiła deliberację. Problemy jednowymiarowe („to jest złożone, ale jednoznaczne”) pozostają powyżej progu i pomijają deliberację.¹³

Dwóch agentów, jedna reguła

Nie potrzeba 10 person badawczych, 8 modułów Python ani 141 testów, aby czerpać wartość z wieloagentowej deliberacji. Wystarczy zacząć od 2 agentów i 1 reguły: agenci muszą oceniać niezależnie, zanim zobaczą nawzajem swoją pracę.

Minimalna użyteczna deliberacja

Decision arrives
  |
  v
Confidence check: is this risky, ambiguous, or irreversible?
  |
  ├── NO  -> Single agent decides (normal flow)
  |
  └── YES -> Spawn 2 agents with different system prompts
             Agent A: "Argue FOR this approach"
             Agent B: "Argue AGAINST this approach"
             |
             v
             Compare findings
             |
             ├── Agreement with different reasoning -> Proceed
             ├── Genuine disagreement -> Investigate the conflict
             └── Agreement with same reasoning -> Suspect herding

Powyższy schemat decyzyjny obejmuje 80% wartości. Oto minimalna implementacja:

# Minimum viable deliberation: 2 agents, 1 rule
def deliberate(decision_description):
    agent_for = spawn_agent(
        f"Argue FOR this approach: {decision_description}",
        persona="advocate"
    )
    agent_against = spawn_agent(
        f"Argue AGAINST this approach: {decision_description}",
        persona="critic"
    )

    if same_reasoning(agent_for, agent_against):
        return "WARNING: Suspect herding. Verify independently."
    elif genuine_conflict(agent_for, agent_against):
        return "Investigate the specific disagreement."
    else:
        return "Proceed. Independent agreement with different reasoning."

Wszystko inne dodaje przyrostowe usprawnienia: ranking 5-wymiarowy, progi adaptowane do zadania, wykrywanie konformizmu. Kluczowa myśl pozostaje prosta: dwie niezależne perspektywy wyłapują awarie, których jedna perspektywa nie zauważy.

Pojedynczy agent vs. wielu agentów: co się zmienia

Co poddawać deliberacji

Testowanie deliberacji

System uruchamia 141 testów w trzech warstwach:¹⁴

• 48 bashowych testów integracyjnych: Walidacja składni hooków, przepływ konsensusu, bramy kontroli jakości, egzekwowanie zabezpieczeń przed rekurencją i kompatybilność między konfiguracjami
• 81 testów jednostkowych Python: Wszystkie 7 modułów biblioteki (maszyna stanów, pewność, izolacja kontekstu, ranking, agenci, konformizm, generowanie PRD)
• 12 testów end-to-end: Pełna symulacja pipeline’u od oceny pewności do wyjścia PRD

Testowanie systemu zaprojektowanego do generowania niezgody wymaga testowania dwóch kategorii. Ścieżka sukcesu: agenci nie zgadzają się produktywnie i osiągają konsensus. Ścieżki awarii: agenci zbiegają się zbyt szybko, nigdy nie zbiegają się lub przekraczają budżety spawnowania. Testy E2E symulują każdy scenariusz z deterministycznymi odpowiedziami agentów, weryfikując, że dwie bramy wyłapują każdy udokumentowany tryb awarii.

Zacznij od wzorca 2 agentów. Dodawaj złożoność, gdy wersja 2-agentowa nie wyłapie czegoś konkretnego. Każdy dodatkowy agent, próg i brama walidacyjna w moim systemie istnieje, ponieważ prostsza wersja zawiodła przy konkretnym zadaniu. Twoje awarie będą inne, a system, który zbudujesz, aby je wyłapywać, powinien odzwierciedlać Twoje awarie, nie moje.

Kluczowe wnioski

• Zgoda jest niebezpiecznym trybem awarii. Pojedyncze agenty nie potrafią zakwestionować własnych założeń. Dwóch niezależnych agentów z różnymi priorytetami ewaluacji wyłapuje strukturalne martwe punkty, których bramy jakości i filozofia nie są w stanie zaadresować.
• Dwie bramy biją jedną. Walidacja konsensusu podczas procesu wyłapuje problemy wcześnie. Kontrola jakości na końcu sesji wyłapuje problemy, które nagromadziły się w kolejnych krokach. Podział walidacji na dwa hooki w różnych punktach cyklu życia odpowiada temu, jak awarie faktycznie występują.
• Deliberuj selektywnie. Moduł pewności uruchamia deliberację przy około 10% decyzji. Deliberowanie nad wszystkim marnuje tokeny. Brak deliberacji pomija decyzje, w których niezależne perspektywy mają największe znaczenie.

FAQ

Źródła