Multi-Agenten-Systeme: Was in der Produktion bricht
Die interessante Frage zu einem KI-Agenten ist nicht, ob er denken kann. Sondern was passiert, wenn Schritt vier von sieben um 2 Uhr nachts scheitert und kein Mensch zusieht. Koordination, Wiederherstellung und Beobachtbarkeit unter Last zeigt eine Sprint-Review-Demo nie, und genau sie entscheiden, ob das Ganze den Kontakt mit echten Systemen übersteht.
Warum einzelne Agenten nicht reichen
Ein einzelner Agent mit einer langen Tool-Liste wird schnell unzuverlässig. Je mehr Tools er hat, desto häufiger greift er zum falschen. Die Antwortqualität sinkt, die Latenz steigt, und Debugging wird zum Albtraum. Multi-Agenten-Architekturen lösen das durch Spezialisierung.
Spezialisierte Agenten
Jeder Agent bekommt eine klar abgegrenzte Aufgabe mit einer kleinen Menge relevanter Tools. Ein Recherche-Agent sucht Informationen, ein Analyse-Agent wertet Daten aus, ein Schreib-Agent erstellt Berichte. Weniger Tools pro Agent = bessere Tool-Auswahl = zuverlässigere Ergebnisse.
Orchestrator als Dirigent
Ein übergeordneter Orchestrator-Agent entscheidet, welche Spezialagenten in welcher Reihenfolge aufgerufen werden. Er verwaltet den Gesamtzustand, fasst Teilergebnisse zusammen und entscheidet, wann die Aufgabe abgeschlossen ist.
Architektur eines Multi-Agenten-Systems
Tool-Design
Tools sind die Schnittstelle zwischen Agent und Außenwelt. Jedes Tool braucht drei Dinge:
Klare Beschreibung
Die Tool-Beschreibung ist der wichtigste Faktor für korrekte Tool-Auswahl. Nicht "Suche im Internet", sondern "Sucht aktuelle technische Dokumentation zu Software-Bibliotheken und Frameworks über die offizielle Dokumentation".
Typisierte Parameter
Jeder Parameter mit Typ, Beschreibung und Validierung. JSON Schema eignet sich gut dafür. Optionale Parameter mit sinnvollen Standardwerten versehen.
Strukturierte Rückgabe
Tools geben strukturierte Daten zurück, keine Prosa. JSON mit klar definierten Feldern. Der Agent kann strukturierte Daten wesentlich besser verarbeiten als Fließtext.
Parallele Ausführung
Viele Aufgaben lassen sich parallelisieren. Wenn ein Agent drei verschiedene Datenquellen abfragen muss, sollten diese Aufrufe gleichzeitig laufen, nicht nacheinander. Die Architektur muss das unterstützen:
result_a = await agent_research(query_a) # 3s
result_b = await agent_research(query_b) # 3s
result_c = await agent_research(query_c) # 3s
# Parallel: 3 Sekunden
results = await Promise.all([
agent_research(query_a),
agent_research(query_b),
agent_research(query_c)
])
Persistenter Speicher
Agenten brauchen Gedächtnis über einzelne Aufrufe hinaus. Kurzzeitspeicher (aktueller Konversationskontext), Arbeitsspeicher (Zwischenergebnisse der aktuellen Aufgabe) und Langzeitspeicher (gelernte Fakten und Entscheidungen aus früheren Sessions). Ohne persistenten Speicher wiederholt ein Agent dieselben Fehler in jeder Session.
Fehlerbehandlung
In der Produktion schlagen Tool-Aufrufe fehl. APIs sind nicht erreichbar, Daten haben unerwartete Formate, Rate Limits greifen. Ein produktives System braucht:
Retry mit Backoff
Automatische Wiederholung bei transienten Fehlern (Netzwerk-Timeouts, 429 Rate Limits). Exponentielles Backoff verhindert Overload.
Fallback-Strategien
Wenn ein primäres Tool fehlschlägt, steht ein alternatives Tool bereit. Wenn die Web-Suche nicht funktioniert, greift der Agent auf eine lokale Wissensbasis zurück.
Graceful Degradation
Teilfehler führen nicht zum Gesamtausfall. Wenn ein Agent von drei Quellen nur zwei erfolgreich abfragt, arbeitet er mit den vorhandenen Daten weiter und markiert die Lücke.
MCP: Model Context Protocol
MCP standardisiert die Kommunikation zwischen Agenten und externen Tools. Statt für jede API eine eigene Integration zu bauen, definiert MCP ein einheitliches Protokoll: Tool-Beschreibungen, Parametervalidierung, Ergebnis-Streaming und Fehlerbehandlung sind standardisiert. Das reduziert den Integrationsaufwand pro Tool von Stunden auf Minuten.
In der Praxis bedeutet das: Ein Agent, der mit 10 MCP-Servern verbunden ist, hat Zugriff auf Datenbanken, Web-Suche, Browser- Automatisierung, GitHub und mehr, ohne dass für jede Integration eigener Code geschrieben werden muss.
Sicherheit und Grenzen
Multi-Agenten-Systeme haben größere Angriffsflächen als einzelne Agenten. Jedes Tool ist ein potenzieller Vektor. Produktive Systeme brauchen Tool-Level-Berechtigungen (welcher Agent darf welches Tool aufrufen), Eingabevalidierung auf jeder Ebene, und Audit-Logs für alle Aktionen. Destruktive Operationen (Daten löschen, externe Systeme ändern) sollten immer eine Bestätigung erfordern.
Fazit
Multi-Agenten-Systeme sind kein Buzzword, sondern eine notwendige Architektur, sobald die Anforderungen über einen einzelnen Assistenten hinausgehen. Der Schlüssel liegt in klarer Spezialisierung, robuster Fehlerbehandlung und standardisierter Tool-Kommunikation über Protokolle wie MCP. Wer diese Grundlagen richtig implementiert, bekommt Systeme, die auch nach Monaten im Produktivbetrieb zuverlässig arbeiten.