Multi-Agenten-Systeme: wann mehrere Agenten besser sind
Multi-Agenten-Diagramme sind das verführerischste Artefakt dieses Felds. Kästen mit Berufsbezeichnungen, Pfeile dazwischen, oben ein Koordinator — es sieht aus wie ein Organigramm, und Organigramme fühlen sich nach Fortschritt an.
Dann kommt die Produktion und mit ihr die Fragen: Welcher Agent hat diese falsche Zahl erzeugt, warum hat der Koordinator sie akzeptiert, und warum kostet eine Anfrage jetzt elf Modellaufrufe? Dieser Leitfaden handelt davon, wann es sich dennoch lohnt und wie man es debugbar baut.
Die drei Bedingungen#
Mehrere Agenten zahlen sich aus, wenn alle drei gelten. Die Teilaufgaben sind wirklich unabhängig — keine braucht das Ergebnis der anderen zum Start. Jede braucht andere Werkzeuge oder eine andere Modellstufe, sodass Spezialisierung etwas Reales kauft. Und die Arbeit ist langsam genug, dass Parallelität das Nutzererlebnis ändert. Gelten nur zwei, ist eine Schleife mit mehr Werkzeugen fast immer besser, billiger und leichter zu reparieren.
Zwei Agenten, die ständig miteinander reden müssen, sind ein Agent mit teurem Nachrichtenbus.
Topologien und ihre Kosten#
| Topologie | Wie sie arbeitet | Kostenprofil | Hauptfehler |
|---|---|---|---|
| Supervisor | Ein Agent delegiert an Spezialisten | N+1 Schleifen | Supervisor routet falsch |
| Pipeline | Feste Übergaben, spezialisierte Stufen | Vorhersehbar | Eine Stufe verschlechtert sich still |
| Paralleles Fan-out | Gleiche Aufgabe, mehrere Sichten, gemerged | Am höchsten | Merge wird zum Engpass |
| Debatte oder Kritiker | Einer schlägt vor, einer widerspricht | 2× pro Austausch | Zustimmung ohne Erkenntnis |
| Blackboard | Geteilter Zustand, alle lesen und schreiben | Unvorhersehbar | Races und Schleifen |
Regeln, die es debugbar halten#
- Jeder Agent bekommt einen schriftlichen Vertrag: Eingabe, Rückgabe und was er nie tun darf.
- Strukturierte Objekte zwischen Agenten weitergeben, nie freie Prosa.
- Eine Lauf-ID für die ganze Anfrage, an jedem Aufruf jedes Agenten.
- Kosten systemweit deckeln, nicht pro Agent.
- Zyklen verbieten, außer mit explizitem Zähler und Ausstiegsbedingung.
- Jeder Agent darf `konnte ich nicht` zurückgeben, und der Koordinator behandelt das.
Das ungeplante Evaluationsproblem#
Bei einem Agenten evaluieren Sie Ergebnisse. Bei mehreren zusätzlich die Übergaben, denn ein System kann falsch antworten, obwohl sich jeder Agent korrekt verhält — der Router wählte schlecht oder der Merge verlor die wichtige Hälfte. Bauen Sie Evaluation auf beiden Ebenen: Ende-zu-Ende-Ergebnisse und Ein-/Ausgabepaare pro Agent aus echten Läufen. Ohne das sagt eine Regression nur, dass es schlechter wurde, nicht wo.
Ein Beispiel, das sich lohnt#
Wettbewerbsrecherche passt wirklich: zu zehn Unternehmen öffentliche Informationen sammeln. Die Teilaufgaben sind unabhängig, jede ist langsam, und der Merge ist eine schlichte Aggregation. Zehn parallele Rechercheagenten brauchen so lange wie einer, ein Synthesizer schreibt die Zusammenfassung. Vergleichen Sie das mit einem Support-Agenten für eine Kundenfrage: dort hängen die Schritte in Reihe voneinander ab, und Aufteilung fügt nur Übergaben und Latenz hinzu.
Häufige Fragen
Verbessert ein Supervisor die Genauigkeit?
Nur wenn das Routing stimmt. 90 % Supervisor vor 95 % Spezialisten ergibt etwa 85 % Ende zu Ende, unsichtbar ohne getrennte Messung. Halten Sie die Zahl der Spezialisten so klein, dass ein Satz je genügt.
Lohnt sich Agentendebatte?
Manchmal, bei echt strittigen Urteilen, wenn der Kritiker Belege zum Prüfen bekommt. Bei Faktenabfragen erzeugt sie meist Zustimmung zum doppelten Preis. Messen Sie gegen eine Einzeldurchlauf-Baseline.
Wie debugge ich einen Multi-Agenten-Fehler?
Mit geteilter Lauf-ID an jedem Aufruf, gespeicherten Ein- und Ausgaben pro Agent und einer Darstellung der Übergaben in Reihenfolge. Wer nicht rekonstruieren kann, wer wem was sagte, schreibt Prompts nach Gefühl um.
multi agenten systemesupervisor agentagenten kooperationparallele agentenagenten übergabe
