Multi-Agent-Deliberation: Wenn Übereinstimmung der Fehler ist

Die gefährlichste Ausgabe meines KI-Agenten ist kein Fehler. Fehler sind einfach. Linter fangen Syntaxfehler ab, Testsuiten fangen Regressionen ab, und die 95 Hooks, die ich gebaut habe, fangen except: pass und Force-Pushes ab. Die gefährliche Ausgabe ist eine selbstbewusste, gut begründete Empfehlung, die zufällig falsch ist.

Ich bat einen einzelnen Agenten, einen API-Endpunkt auf Sicherheitsprobleme zu überprüfen. Der Agent prüfte die Authentifizierung, validierte die Eingabebereinigung und verifizierte die CORS-Header. Einwandfreies Ergebnis. Ein zweiter Agent, separat als Penetrationstester beauftragt, stellte fest, dass der Endpunkt unbegrenzte Abfrageparameter akzeptierte, die über Datenbank-Abfrageverstärkung einen Denial-of-Service auslösen konnten. Der erste Agent hatte das nie geprüft, weil nichts in seinem Bewertungsrahmen Abfragekomplexität als Sicherheitsoberfläche behandelte.

Diese Lücke ist strukturell. Kein noch so gutes Prompt-Engineering behebt sie, weil die Einschränkung nicht im Prompt liegt. Die Einschränkung liegt darin, dass eine einzige Perspektive ein mehrdimensionales Problem bewertet.

Ich habe ein Multi-Agent-Deliberationssystem gebaut, um diese Lücke zu schließen. Agenten mit verschiedenen Personas recherchieren unabhängig, debattieren Ergebnisse und erreichen Konsens durch strukturierte Abstimmung. Das System führt 141 Tests aus, erzwingt Kontextisolation zwischen Agenten und verwendet eine Zwei-Gate-Validierungsarchitektur, die voreilige Übereinstimmung blockiert.

TL;DR

Einzelagenten-KI-Systeme haben einen strukturellen blinden Fleck: Sie können ihre eigenen Annahmen nicht hinterfragen. Eine Ralph-Schleife mit Sonnet produziert Code für 10 $/Stunde, aber jeder blinde Fleck im Modell wird mit derselben Geschwindigkeit ausgeliefert. Multi-Agent-Deliberation erzwingt eine unabhängige Bewertung aus mehreren Perspektiven, bevor eine Entscheidung feststeht. Meine Implementierung verwendet 10 Recherche-Personas, eine 7-Phasen-Zustandsmaschine und zwei Validierungsgates (Konsens + Pride Check), die auf Claude Code Hooks laufen. Das System wird bei Entscheidungen mit niedriger Konfidenz (unter 0,70) ausgelöst und verursacht ungefähr die dreifachen Token-Kosten pro Deliberation. Für Sicherheitsentscheidungen, Architekturwahlen und alles Irreversible zahlt sich dieser Aufwand beim ersten Mal aus, wenn etwas erkannt wird, das ein einzelner Agent übersehen hat. Für Dokumentationskorrekturen und Routineänderungen überspringen Sie die Deliberation vollständig.

Die Nacht, in der meine Agenten beschlossen, alles kaputtzumachen

Februar 2026. Ein Dienstag. Ich bat meinen Agenten, „die Verbesserung des Hook-Dispatch-Systems zu untersuchen”, und ging Kaffee kochen. Der Agent bewertete seine eigene Konfidenz mit 0,58 (unter der Schwelle von 0,70), was die Deliberation auslöste. Das System erzeugte 3 Recherche-Agenten. Jeder Recherche-Agent bewertete das Problem, fand Teilprobleme und erzeugte eigene Recherche-Agenten. Diese Agenten erzeugten weitere.

Sieben Minuten später: 23 aktive Agentenprozesse. 4,80 $ an API-Guthaben verbrannt. Das Verzeichnis ~/.claude/state/ füllte sich mit JSON-Zustandsdateien, da jeder Agent pflichtbewusst seine Ergebnisse persistierte. Der Token-Verbrauch stieg mit etwa 0,70 $ pro Minute ohne Anzeichen einer Konvergenz.

Der Rekursionsschutz, den ich für das Qualitätssystem gebaut hatte, verfolgte die Tiefe (Elternteil erzeugt Kind, Kind erzeugt Enkel), aber nicht die Breite (Elternteil erzeugt 12 Kinder, die jeweils 12 weitere erzeugen). Das Tiefenlimit von 3 wurde nie ausgelöst, weil sich die Agenten horizontal ausbreiteten. Ich beendete die Prozesse manuell und starrte auf die Zustandsdateien.

Jeder Agent stimmte zu, dass das Hook-Dispatch-System verbessert werden musste. Jeder Agent schlug vernünftig klingende Änderungen vor. Kein einziger Agent hinterfragte, ob die Untersuchung selbst korrekt eingegrenzt war. Dreiundzwanzig Agenten, die einen Konsens über die falsche Frage erzielten.

Die Korrektur dauerte 20 Minuten: ein Spawn-Budget, das die Gesamtzahl aktiver Kindprozesse pro Elternteil verfolgt, begrenzt auf 12. Die tiefere Erkenntnis brauchte länger. Die Infrastruktur-Beschleunigungskurve, die ich dokumentiert hatte, machte es möglich, das Deliberationssystem in 2 Wochen zu bauen – gerade weil die Hook-Infrastruktur bereits existierte. Aber schnelle Konstruktion verhindert keine strukturellen Fehler. Die Progression von Einzelagenten-RAG-Pipelines zu autonomen Systemen folgt einem vorhersehbaren Bogen. Multi-Agent-Deliberation steht aus gutem Grund am Ende: Sie wird erst gebaut, nachdem ein einzelner Agent selbstbewusst die falsche Antwort ausgeliefert hat.

Übereinstimmung, nicht Meinungsverschiedenheit, war der gefährliche Fehlermodus.

Anatomie einer Deliberation

Das System hat zwei strukturelle Komponenten: eine Zustandsmaschine, die die Arbeit sequenziert, und zwei Validierungsgates, die verhindern, dass schlechter Konsens ausgeliefert wird.

Die Zustandsmaschine

Sieben Phasen, jede abhängig von der vorherigen:

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

RESEARCH: Unabhängige Agenten untersuchen das Thema. Jeder Agent erhält eine andere Persona (Technical Architect, Security Analyst, Performance Engineer und 7 weitere). Kontextisolation stellt sicher, dass Agenten während der Recherche die Ergebnisse der anderen nicht einsehen können. L0 (Systemregeln) und L1 (Projektkontext) werden geteilt. L2 (agentenspezifischer Fokus) ist privat. L3 (Domänenmuster) lädt relevante Musterbibliotheken pro Persona.¹

DELIBERATION: Agenten sehen alle Rechercheergebnisse und generieren Alternativen. Der Debate-Agent identifiziert Konflikte zwischen Perspektiven. Der Synthesis-Agent kombiniert nicht-widersprüchliche Ergebnisse.

RANKING: Jeder Agent bewertet jeden vorgeschlagenen Ansatz anhand von 5 gewichteten Dimensionen:

Gewichtete Bewertungen werden zu einer Konsensbewertung aggregiert. Die Schwelle ist aufgabenadaptiv: 0,85 für Sicherheitsentscheidungen, 0,80 für Architektur, 0,70 Standard, 0,65 für Refactoring, 0,50 für Dokumentation.²

Die zwei Gates

Gate 1: Konsensvalidierung (PostToolUse:Task Hook). Vier Prüfungen laufen nach Abschluss jedes Deliberationsagenten:

1. Die Phase muss mindestens RANKING erreicht haben
2. Mindestens 2 Agenten abgeschlossen (konfigurierbar)
3. Konsensbewertung erreicht die aufgabenadaptive Schwelle
4. Falls ein Agent Einspruch erhoben hat, müssen seine Bedenken dokumentiert sein

Das Scheitern einer Prüfung blockiert das Fortschreiten der Deliberation.³

Gate 2: Pride Check (Stop Hook). Fünf Qualitätsprüfungen laufen, bevor die Sitzung geschlossen werden kann:

1. Methodenvielfalt: Mehrere einzigartige Personas vertreten
2. Widerspruchstransparenz: Einsprüche haben dokumentierte Gründe
3. Komplexitätsbehandlung: Mindestens 2 Alternativen generiert
4. Konsenzkonfidenz: Bewertung als stark (über 0,85) oder moderat (0,70-0,84) klassifiziert
5. Verbesserungsnachweis: Endkonfidenz übersteigt Anfangskonfidenz

Die Zwei-Gate-Architektur erkennt Probleme in verschiedenen Stadien. Gate 1 verhindert vorzeitige Konvergenz während des Prozesses. Gate 2 verhindert die Auslieferung von Ergebnissen, die vollständig aussehen, aber keine Gründlichkeit aufweisen.

Geheimdienstanalysten hatten dieses Problem zuerst

Ich baute das Deliberationssystem im Januar 2026. Zwei Wochen später fand ich Richards Heuers Psychology of Intelligence Analysis auf einer Leseliste über strukturierte Entscheidungsfindung. Kapitel 8 beschreibt die Analyse konkurrierender Hypothesen (ACH): Analysten bewerten Beweise gleichzeitig gegen mehrere Hypothesen, anstatt einen Fall für ihre bevorzugte Schlussfolgerung aufzubauen.⁴

Die Parallele war unbequem. Heuers Rahmenwerk, 1999 für die CIA veröffentlicht, adressierte denselben strukturellen Fehler, den ich debuggt hatte: Kluge Menschen konvergieren auf eine einzige Erklärung, weil sie sich nie gezwungen haben, Alternativen zu bewerten.

So sieht ACH in der Praxis aus. Ein Geheimdienstanalyst, der ein mutmaßliches Waffenprogramm untersucht, fragt nicht „Ist das ein Waffenprogramm?” (Bestätigungsfehler). Stattdessen listet der Analyst jede plausible Hypothese auf (Waffenprogramm, zivile Forschung, Dual-Use-Anlage), bewertet jedes Beweisstück gegen jede Hypothese und identifiziert, welche Beweise am besten zwischen den Hypothesen unterscheiden.

Mein System macht dasselbe mit anderem Vokabular. Drei Agenten bewerten eine vorgeschlagene Datenbankschemaänderung. Agent A (Technical Architect) schreibt: „Schema ist sauber, normalisiert auf 3NF.” Agent B (Performance Engineer) schreibt: „Abfragemuster erfordern Joins über 4 Tabellen bei jedem Lesevorgang.” Agent C (Security Analyst) schreibt: „PII-Felder sind im Ruhezustand nicht verschlüsselt.” Dasselbe Schema, drei verschiedene Bewertungen, drei unterscheidende Beweise. Die Ranking-Phase bewertet den vorgeschlagenen Ansatz anhand dieser unabhängigen Bewertungen, so wie ACH Hypothesen anhand von Beweisen bewertet.

Ich habe das System nicht aus Heuers Rahmenwerk heraus entworfen. Ich habe eine Teilmenge von ACH durch Versuch und Irrtum neu erfunden und dann herausgefunden, dass jemand bereits das Lehrbuch geschrieben hatte. Die ehrliche Version ist nützlicher als die schmeichelhafte: Unabhängig zur selben Architektur zu gelangen, bestätigt, dass das zugrunde liegende Problem real und nicht theoretisch ist.

Warum Übereinstimmung der gefährliche Fehlermodus ist

Charlan Nemeth untersuchte Minderheitsdissens von 1986 bis zu ihrem Buch In Defense of Troublemakers von 2018. Gruppen mit Abweichlern treffen bessere Entscheidungen als Gruppen, die schnell Übereinstimmung erreichen. Der Abweichler muss nicht recht haben. Allein der Akt der Meinungsverschiedenheit zwingt die Mehrheit, Annahmen zu überprüfen, die sie sonst überspringen würde.⁵

James Surowieckis The Wisdom of Crowds identifiziert vier Bedingungen für kluge Gruppenentscheidungen: Meinungsvielfalt, Unabhängigkeit des Urteils, Dezentralisierung und einen Mechanismus zur Aggregation.⁶ Wird die Unabhängigkeit verletzt (Agenten sehen während der Recherche die Arbeit der anderen), entsteht Herdenverhalten. Wird die Vielfalt verletzt (identische Prompts für jeden Agenten), entstehen Echokammern.

Ich habe die Unabhängigkeitsbedingung direkt getestet. Zwei Agenten, die dieselbe Deployment-Strategie mit Einsicht in die Ergebnisse des jeweils anderen bewerteten: Agent A bewertete das Risiko mit 0,45. Agent B sah diese Bewertung und produzierte 0,48. Dieselben Agenten ohne Einsicht: 0,45 und 0,72. Die Differenz zwischen 0,48 und 0,72 sind die Kosten des Herdenverhaltens. Agent Bs unabhängige Bewertung markierte ein Container-Orchestrierungsrisiko, das verschwand, als sozialer Druck in die Bewertung eintrat.

Neuere Forschung bestätigt, dass beide Muster für LLM-Agenten gelten. Choi et al. fanden auf der NeurIPS 2025, dass Mehrheitsabstimmung unter unabhängig beauftragten Agenten den Großteil der Qualitätsgewinne von Multi-Agent-Systemen erfasst.⁷ Kaesberg et al. quantifizierten auf der ACL 2025 die Aufteilung: Abstimmung verbessert Reasoning-Aufgaben um 13,2 %, während Konsensprotokolle Wissensaufgaben um 2,8 % verbessern.⁸ Dies legt nahe, dass die Wahl vom Aufgabentyp abhängen sollte. Deshalb verwendet mein System aufgabenadaptive Schwellen statt einer einzelnen Konsenszahl.

Wu et al. testeten, ob LLM-Agenten wirklich debattieren können, und stellten fest, dass Agenten ohne strukturelle Anreize für Meinungsverschiedenheit zur selbstbewusstesten klingenden Erstantwort konvergieren, unabhängig von deren Korrektheit.⁹ Wynn et al. gingen weiter: Debatte kann aktiv schädlich sein. Modelle wechseln von korrekten zu inkorrekten Antworten als Reaktion auf Peer-Reasoning, selbst wenn stärkere Modelle schwächere zahlenmäßig übertreffen.¹⁰ Liang et al. identifizierten die Ursache als „Degeneration-of-Thought”: Sobald ein LLM Vertrauen in eine Position aufgebaut hat, kann Selbstreflexion keine neuartigen Gegenargumente generieren, was Multi-Agent-Bewertung strukturell notwendig macht.¹¹

Mein System adressiert Unabhängigkeit durch Kontextisolation (L2-Schichten sind während der Recherche agentenprivat). Vielfalt entsteht durch 10 verschiedene Personas mit unterschiedlichen Bewertungsprioritäten. Aggregation verwendet gewichtete Bewertung über 5 Dimensionen statt einfacher Abstimmung. Der strukturelle Anreiz für Meinungsverschiedenheit ist schwächer: Ich verfolge, ob Einspruch dokumentiert wird, belohne Agenten aber nicht für Widerspruch. Das Konformitätserkennungsmodul versucht, diese Lücke zu adressieren – mit gemischten Ergebnissen.

Vorgetäuschte Meinungsverschiedenheit erkennen

Das Konformitätsmodul verfolgt Muster, die darauf hindeuten, dass Agenten ohne echte Bewertung zustimmen. Dokumentierte Bedenken, die dieselbe Sprache über Agenten hinweg wiederholen, Bewertungen, die verdächtig nahe an der Schwelle clustern, oder einstimmige Unterstützung von jeder Persona (ein Security Analyst und ein Performance Engineer stimmen selten in allem überein) lösen Warnungen aus.

Was es erkennt: Standardeinspruch (Agenten kopieren die Bedenkenformulierungen der anderen), Bewertungsclustering (jeder Agent bewertet innerhalb von 0,3 Punkten auf einer 10-Punkte-Skala) und fehlende Minderheitsperspektiven (einstimmige Zustimmung von Personas mit widersprüchlichen Prioritäten).

Ein Beispiel aus meinen Logs: Fünf Agenten bewerteten ein Authentifizierungs-Refactoring. Alle fünf bewerteten das Sicherheitsrisiko zwischen 7,1 und 7,4. Der Konformitätsdetektor markierte den Cluster. Als ich mit frischer Kontextisolation (Löschen der L2-Caches) erneut lief, verteilten sich die Bewertungen auf 5,8-8,9. Der ursprüngliche Cluster spiegelte eine gemeinsame Kontextkontamination wider, keine echte Übereinstimmung.

Was er nicht erkennt: Ausgefeilte Übereinstimmung, bei der Agenten wirklich aus der Perspektive ihrer Persona bewerten, aber zufällig aus verschiedenen Gründen zum selben Schluss kommen. Das Modul kann echten Konsens nicht von Herdenverhalten unterscheiden, wenn die Begründung unabhängig aussieht. Ich habe versucht, einen Klassifikator mit Beispielen von echter vs. vorgetäuschter Übereinstimmung zu trainieren, aber die Trainingsdaten waren zu klein (unter 50 Deliberationssitzungen) und das Signal zu schwach. Der Konformitätsdetektor erkennt die offensichtlichen Fälle und verpasst die subtilen.

Die ehrliche Einschätzung: Konformitätserkennung fügt eine nützliche Plausibilitätsprüfung für die 10-15 % der Deliberationen hinzu, bei denen Agenten zu schnell konvergieren. Für die anderen 85-90 % bieten die Konsens- und Pride-Check-Gates ausreichende Validierung. Ich habe erwogen, ein ausgereifteres Konformitätssystem zu bauen, und entschied, dass der Entwicklungsaufwand nicht der marginalen Verbesserung entsprechen würde.

Was nicht funktionierte

Sackgasse 1: Freiformdebattenrunden

Die erste Version ließ Agenten ausführliche Erwiderungen auf die Ergebnisse der anderen schreiben: 3 Runden Textaustausch. Ich beobachtete eine Deliberation über Datenbankindexierungsstrategien, die sich über 7.500 Token Debatte erstreckte. Runde 1: echte Meinungsverschiedenheit über zusammengesetzte vs. einzelne Spaltenindizes. Runde 2: wiederholte Positionen mit geringfügiger Ausarbeitung. Runde 3: nahezu identische Argumente in anderen Worten verpackt. Das Signal erreichte seinen Höhepunkt in Runde 1 und verschlechterte sich danach.

Die Token-Kosten pro Deliberation erreichten 2-4 $, und die nützliche Informationsdichte sank mit jeder Runde. Die Lösung: Strukturierte Dimensionsbewertung ersetzte die Freiformdebatte. Agenten bewerten Vorschläge über 5 Dimensionen mit numerischen Werten, anstatt Aufsätze zu schreiben. Kosten und Zeit sanken um etwa 60 %, und die Qualität des endgültigen Rankings verbesserte sich tatsächlich, weil numerische Bewertungen eine Präzision erzwingen, die Prosa verschleiert.

Sackgasse 2: Tiefenbasierte Rekursion für Deliberation

Der Endlos-Spawn-Vorfall enthüllte einen grundlegenden Modellierungsfehler. Der Rekursionsschutz verfolgte die Tiefe: Elternteil auf Tiefe 0 erzeugt Kind auf Tiefe 1, Kind erzeugt Enkel auf Tiefe 2, maximale Tiefe 3. Aber Deliberationsagenten sollten sich breit auffächern (10 Recherche-Agenten auf derselben Ebene), nicht tief (ein Agent erzeugt ein Kind, das ein Enkelkind erzeugt). Das Tiefenlimit von 3 wurde nie ausgelöst, weil 23 Agenten auf Tiefe 1 immer noch „Tiefe 1” sind.

Die Lösung war ein Spawn-Budget-Modell: Deliberationsagenten erben die Tiefe des Elternteils, anstatt sie zu inkrementieren, und teilen sich ein Gesamtbudget von Kind-Spawns, begrenzt auf 12. Das Budget-Modell bildet den tatsächlichen Fehlermodus ab (zu viele Agenten insgesamt) anstatt einer Proxy-Metrik (zu viele Verschachtelungsebenen). Die Agenten-Abstammung wird in einer JSON-Datei verfolgt, damit das Budget über asynchrone Agentenabschlüsse hinweg bestehen bleibt.¹²

Sackgasse 3: Einzelnes Validierungsgate

Die erste Implementierung führte einen einzelnen Validierungshook am Sitzungsende aus, der Konsensprüfungen mit Qualitätsprüfungen kombinierte. Der Fehlermodus zeigte sich innerhalb der ersten Woche. Ein Agent schloss die Deliberation mit einer Konsensbewertung von 0,52 ab – unter der Schwelle von 0,70. Er arbeitete dann 20 Minuten an nicht verwandten Aufgaben weiter, bevor der Sitzungsende-Hook den Fehler markierte. Zwanzig Minuten Arbeit, die auf einem Fundament aufbauten, das die Validierung nicht bestanden hatte.

Die Aufteilung in zwei Gates behob das Timing-Problem. Gate 1 (Konsensvalidierung) läuft als PostToolUse:Task Hook und erkennt schlechten Konsens sofort nach Abschluss des Deliberationsagenten. Gate 2 (Pride Check) läuft am Sitzungsende und erkennt Qualitätsprobleme, die sich über Schritte hinweg angesammelt haben. Zwei Hooks an verschiedenen Lebenszykluspunkten entsprechen dem tatsächlichen Auftreten von Fehlern: Einige sind sofortig (schlechte Bewertung) und einige sind graduell (geringe Vielfalt, fehlende Einspruchsdokumentation).

Die ehrliche Mathematik

Deliberation kostet Token. Jeder Recherche-Agent verarbeitet etwa 5.000 Token Kontext und generiert 2.000-3.000 Token Ergebnisse. Bei 3 Agenten (Minimum für nützliche Deliberation) sind das 15.000-24.000 zusätzliche Token pro Entscheidung. Bei 10 Agenten (volles Recherchepanel) etwa 50.000-80.000 Token.

Bei Opus-Preisen (15 $/75 $ pro Million Token) kostet eine 3-Agenten-Deliberation ungefähr 0,68-0,90 $. Eine 10-Agenten-Deliberation kostet 2,25-3,00 $. Mein System löst Deliberation bei ungefähr 10 % der Entscheidungen aus (diejenigen, die unter 0,70 Konfidenz liegen), sodass die amortisierten Kosten über alle Entscheidungen hinweg bei 0,23-0,30 $ pro Sitzung liegen.

Ob sich das lohnt, hängt davon ab, was eine falsche Entscheidung kostet. Eine übersehene Sicherheitslücke in einem Produktions-Deployment kostet Stunden an Incident Response. Eine schlechte Architekturentscheidung kostet Wochen an Refactoring. Ein Tippfehler in der Dokumentation kostet nichts.

Das Konfidenzmodul bestimmt, welche Entscheidungen Deliberation auslösen. Vier Dimensionen (Mehrdeutigkeit, Komplexität, Tragweite und Kontextabhängigkeit) produzieren jeweils eine Bewertung von 0-1. Mehrere Dimensionen müssen hoch bewerten, damit die Gesamtkonfidenz unter 0,70 fällt und Deliberation ausgelöst wird. Eindimensionale Probleme („das ist komplex, aber eindeutig”) bleiben über der Schwelle und überspringen die Deliberation.¹³

Zwei Agenten, eine Regel

Sie brauchen keine 10 Recherche-Personas, 8 Python-Module oder 141 Tests, um Mehrwert aus Multi-Agent-Deliberation zu ziehen. Beginnen Sie mit 2 Agenten und 1 Regel: Agenten müssen unabhängig bewerten, bevor sie die Arbeit des anderen sehen.

Minimal funktionsfähige Deliberation

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

Das obige Entscheidungsflussdiagramm deckt 80 % des Mehrwerts ab. Hier ist die minimale Implementierung:

# 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."

Alles Weitere bringt inkrementelle Verbesserung: das 5-Dimensionen-Ranking, aufgabenadaptive Schwellen, Konformitätserkennung. Die zentrale Erkenntnis bleibt einfach: Zwei unabhängige Perspektiven erkennen Fehler, die eine einzelne Perspektive übersieht.

Einzelagent vs. Multi-Agent: Was sich ändert

Wann deliberieren

Deliberation testen

Das System führt 141 Tests über drei Schichten aus:¹⁴

• 48 Bash-Integrationstests: Hook-Syntaxvalidierung, Konsensablauf, Pride-Check-Gates, Rekursionsschutz-Durchsetzung und konfigurationsübergreifende Kompatibilität
• 81 Python-Unit-Tests: Alle 7 Bibliotheksmodule (Zustandsmaschine, Konfidenz, Kontextisolation, Ranking, Agenten, Konformität, PRD-Generierung)
• 12 End-to-End-Tests: Vollständige Pipeline-Simulation von der Konfidenzbewertung bis zur PRD-Ausgabe

Das Testen eines Systems für Meinungsverschiedenheit erfordert das Testen zweier Kategorien. Der Erfolgsfall: Agenten sind produktiv unterschiedlicher Meinung und erreichen Konsens. Die Fehlerfälle: Agenten konvergieren zu schnell, konvergieren nie oder überschreiten Spawn-Budgets. Die E2E-Tests simulieren jedes Szenario mit deterministischen Agentenantworten und verifizieren, dass die beiden Gates jeden dokumentierten Fehlermodus erkennen.

Beginnen Sie mit dem 2-Agenten-Muster. Fügen Sie Komplexität hinzu, wenn die 2-Agenten-Version etwas Bestimmtes verfehlt. Jeder zusätzliche Agent, jede Schwelle und jedes Validierungsgate in meinem System existiert, weil die einfachere Version bei einer bestimmten Aufgabe versagte. Ihre Fehler werden andere sein, und das System, das Sie bauen, um sie zu erkennen, sollte Ihre Fehler widerspiegeln, nicht meine.

Kernerkenntnisse

• Übereinstimmung ist der gefährliche Fehlermodus. Einzelagenten können ihre eigenen Annahmen nicht hinterfragen. Zwei unabhängige Agenten mit unterschiedlichen Bewertungsprioritäten erkennen strukturelle blinde Flecken, die Qualitätsgates und Philosophie nicht adressieren können.
• Zwei Gates schlagen eines. Konsensvalidierung während des Prozesses erkennt Probleme frühzeitig. Der Pride Check am Sitzungsende erkennt Probleme, die sich über Schritte hinweg angesammelt haben. Die Aufteilung der Validierung in zwei Hooks an verschiedenen Lebenszykluspunkten entspricht dem tatsächlichen Auftreten von Fehlern.
• Selektiv deliberieren. Das Konfidenzmodul löst Deliberation bei ungefähr 10 % der Entscheidungen aus. Alles zu deliberieren verschwendet Token. Nichts zu deliberieren verpasst die Entscheidungen, bei denen unabhängige Perspektiven am wichtigsten sind.

FAQ

Referenzen