Multi-Agent Intelligence: Zusammenarbeit von KI-Agenten

Was ist Multi-Agent Intelligence?

Multi-Agent Intelligence bezeichnet hier die koordinierte Bearbeitung einer Aufgabe durch mehrere eigenständig aufrufbare KI-Agenten mit definierten Rollen, Werkzeugrechten, Übergaben und Prüfpunkten. Entscheidend ist nicht die Anzahl der Modelle, sondern ob eine Aufteilung tatsächlich zu überprüfbar besseren Ergebnissen führt. Ein System kann mehrere Agenten nacheinander, gleichzeitig oder als kontrolliertes Netzwerk ausführen. Ein leistungsfähiges Modell mit mehreren internen Gedankenschritten ist dagegen noch kein nachweisbar verteiltes Multi-Agent-System.

Ein KI-Modell erzeugt Ausgaben aus einem Kontext. Ein Agent setzt ein Modell in einen Ablauf mit Zielen, Werkzeugen, Zustand und Grenzen ein. Ein Orchestrator steuert Reihenfolge, Zuständigkeit und Eskalation. Ein Framework stellt Bausteine zur Implementierung solcher Abläufe bereit. Eine Plattform ergänzt beispielsweise Hosting, Berechtigungen und Betriebsfunktionen. Die Begriffe sagen für sich genommen noch nichts über Zuverlässigkeit, Sicherheit oder tatsächliche Leistungsgewinne aus.

Wie mehrere Agenten zusammenarbeiten

Ein belastbarer Ablauf beginnt mit einem Auftragsvertrag: Eingaben, erwartete Ausgabe, zulässige Daten und klarer Abbruchzustand. Ein Planer darf Teilaufgaben definieren. Fachagenten bearbeiten diese nur innerhalb ihrer Berechtigungen; ein Prüfer kontrolliert Quellen oder Tests. Anschließend entscheidet die Orchestrierung, ob die Ergebnisse zusammengeführt, erneut bearbeitet oder einem Menschen zur Freigabe vorgelegt werden.

Die zentrale technische Frage lautet: Welcher Zustand wird geteilt? Gemeinsamer Speicher vereinfacht die Zusammenarbeit, kann aber fehlerhafte oder unberechtigte Inhalte weitergeben. Isolierte Agentenkontexte schützen Schnittstellen besser, benötigen dafür eindeutige Nachrichtenformate und Übergabeprotokolle. Eine robustere Architektur benennt verantwortliche Rollen und verhindert, dass ein Agent stillschweigend die Rechte eines anderen erhält.

Beispiel: Ein quellenkritischer Unternehmensbericht

1. Die Nutzerin nennt Fragestellung, zulässige Informationsquellen und Abgabetermin.
2. Ein Orchestrator zerlegt den Auftrag in Marktdaten, technische Risiken und rechtliche Fragestellungen. Diese Aufgaben sind bei begrenzter gegenseitiger Abhängigkeit parallel bearbeitbar.
3. Die Spezialisten liefern strukturierte Ergebnisse mit Quellen, Unsicherheiten und Zeitstempeln – nicht nur frei formulierte Zusammenfassungen.
4. Ein unabhängiger Prüfagent markiert Widersprüche, fehlende Fundstellen und nicht vergleichbare Angaben. Dieser Prüfschritt ersetzt keine menschliche Verantwortung.
5. Bei vertraulichen Informationen, externen Aktionen oder strittigen Ergebnissen stoppt der Workflow und fordert eine Freigabe an.
6. Der Bericht enthält nachvollziehbare Verweise auf Entscheidungen, Quellen und nicht aufgelöste Fragen.

Das ist ein Referenzprozess, kein AgentenCode-Benchmark. Ob er in einer konkreten Anwendung schneller oder besser ist, müsste gegen einen einzelnen Agenten unter identischen Testbedingungen gemessen werden.

Wann Parallelität sinnvoll ist – und wann nicht

Ein seriöser Vergleich erfasst Task-Success, Quellen-/Antwortqualität, Gesamtlatenz, Anzahl der Aufrufe, Token- bzw. Laufzeitkosten, menschliche Eingriffe und Sicherheitsvorfälle. Eine Architektur gewinnt nicht automatisch, weil sie bei einer einzigen dieser Größen vorn liegt. Relevant sind die für das konkrete Einsatzszenario vorher definierten Anforderungen.

Kommunikation, A2A und MCP

Agenten können über interne Nachrichten eines Frameworks oder über standardisierte Grenzen hinweg kommunizieren. A2A beschreibt Agent-zu-Agent-Interaktionen einschließlich Aufgaben, Nachrichten, Fähigkeiten und Versionsaushandlung. MCP beschreibt dagegen vor allem die Anbindung von Werkzeugen, Ressourcen und Kontext an Anwendungen bzw. Agenten. A2A und MCP können sich ergänzen, sind aber nicht austauschbar. Die im Oktober 2026 eingesehene A2A-Spezifikation beschreibt die Protokollversion 1.0; bei einer späteren Aktualisierung muss die tatsächlich eingesetzte Version protokolliert werden. A2A-Spezifikation · MCP-Spezifikation 2025-06-18.

Fehler- und Sicherheitsmodell

Prompt Injection: Inhalte aus externen Quellen können versuchen, Rollen oder Toolanweisungen zu überschreiben. Berechtigungsüberschreitung: Ein delegierter Agent darf nur die ausdrücklich zugewiesenen Aktionen ausführen. Kontextverlust: Eine Übergabe kann Quellen, Einschränkungen oder Zwischenergebnisse verlieren. Endlosschleifen: Wiederholte Delegationen können Kosten und Laufzeit unkontrolliert steigern. Scheinkonsens: Mehrere Agenten können denselben Fehler reproduzieren, insbesondere wenn sie gleiche Quellen oder Modelle verwenden. Daher gehören technische Limits, unabhängige Prüfung, Protokollierung und Eskalation in die Architektur – nicht nur in einen erklärenden Disclaimer.

Was die Forschung tatsächlich stützt

Die peer-reviewte Arbeit MultiAgentBench (Zhu et al., ACL 2025) untersucht kooperierende bzw. konkurrierende Agenten unter definierten Szenarien und berichtet über Koordinationsmuster wie Stern, Kette, Baum und Graph. Die im Abstract genannte Stärke einer Graphstruktur bezieht sich ausdrücklich auf das Forschungsszenario der Studie, nicht auf jedes produktive Multi-Agent-System. ACL Anthology.

Das begleitende MARBLE-Repository dokumentiert Implementierung und Forschungsumgebung. Ein GitHub-Repository ist keine automatisch laufende Replikation durch AgentenCode. Unsere Benchmark-Einordnung erläutert Messgegenstand, Grenzen und Vergleichbarkeit.

Praktische Auswahlhilfe

Beginnen Sie mit einer reproduzierbaren Single-Agent-Baseline. Prüfen Sie, ob Teilaufgaben unabhängig sind und der erwartete Nutzen die Mehrkosten rechtfertigt. Legen Sie vor dem Test Rollen, Eingabe-/Ausgabeformate, Toolrechte, Zustandsübergänge, Erfolgsmetriken und Abbruchgrenzen fest. Testen Sie anschließend ein klar benanntes Orchestrierungsmuster unter denselben Aufgaben und Randbedingungen. Im Architekturleitfaden werden dafür sieben Muster mit Fehlerbildern und Beispielen verglichen.

Unternehmensanforderungen lassen sich zusätzlich mit AgentenTrust, dem Evidence-Check und den konkreten Agentenprofilen untersuchen. Ein fehlender Beleg bleibt Unknown; daraus folgt weder ein positives noch ein negatives Testergebnis.