Viele Teams, die Agenten-KI entwickeln, tendieren zu Multi-Agenten-Architekturen, da Spezialisierung und Koordination als elegante Methode zur Leistungssteigerung erscheinen. Akademische Forschung zeigt häufig komplexe Systeme, in denen 2 bis 5 Agenten verhandeln und abstimmen, um Probleme zu lösen

Einige dieser Designs schaffen es in die Produktion, doch viele werden schwer zu betreiben, sobald echter Kosten-, Latenz- und Debugging-Druck auftritt.

Das Fehlermuster ist konsistent. Ein Team entwirft ein Multi-Agenten-System, das in der Staging-Umgebung gut funktioniert, nur um dann festzustellen, dass Koordinationsaufwand, Token-Kosten und undurchsichtige Fehlerketten es im großen Maßstab unhandhabbar machen. Wenn der Bereitschaftsingenieur um 2 Uhr morgens alarmiert wird, kann niemand mehr nachvollziehen, welcher Agent die fehlerhafte Ausgabe verursacht hat. Das System wird zu etwas Einfacherem umgebaut, und die ursprüngliche Architektur wird zu einer teuren Lektion in selbst geschaffener Komplexität.

Dieser Artikel beleuchtet diesen Kompromiss aus einer spezifischen Perspektive: einem Workflow zur Überprüfung von Compliance-Dokumenten bei einem Series-B-Fintech-Unternehmen. Wir vergleichen Single-Agent- und Multi-Agent-Ansätze hinsichtlich Kosten, Latenz, Debugging-Fähigkeit und Teamkapazität. Ziel ist es, CTOs und technischen Führungskräften eine praktische Methode an die Hand zu geben, um zu beurteilen, wann Multi-Agent-Komplexität gerechtfertigt ist und wann sie mehr Wert zerstört als schafft. [SEG SEGMENT 7] Single-Agent- und Multi-Agent-Architektur in einem Compliance-Workflow

Eine professionelle Infografik, die die Komplexität und Kosten von „Single-Agent + Tools“ im Vergleich zu „Multi-Agent-Pipeline“ für die wöchentliche Bearbeitung von über 400 Kreditdokumenten veranschaulicht.

Single-Agent + Tools (Der Monolith)

Bei diesem monolithischen Ansatz übernimmt ein einziges LLM den gesamten Workflow. Es empfängt ein Dokument, klassifiziert es, ruft eine Extraktions-API auf, fragt eine Regeldatenbank ab und erstellt die Zusammenfassung. Ein System-Prompt. Ein Kontextfenster. Eine Ausführungsverfolgung.

Für das Entwicklungsteam ist dieses Design leicht nachvollziehbar. Wenn die Ausgabe falsch ist, liest ein Ingenieur den Prompt, überprüft die Tool-Aufrufe und findet die Lücke. Deployments betreffen einen Dienst. Das Monitoring deckt eine Pipeline ab. Die Kosten pro Dokument sind vorhersehbar, da jede Anfrage denselben Token-Pfad durchläuft.

Dieser Ansatz stößt jedoch an seine Grenzen, wenn der Anwendungsbereich erweitert wird. Wenn weitere Dokumenttypen und regulatorische Rahmenwerke hinzugefügt werden, wird der System-Prompt überladen. Dies führt oft zum „Lost in the Middle“-Effekt, bei dem das Modell Anweisungen ignoriert, die in der Mitte eines großen Kontextfensters vergraben sind. Teams mindern dies typischerweise, indem sie Retrieval-Augmented Generation (RAG) verwenden, um nur relevante Regeln einzuschleusen, oder indem sie eine Prompt-Dekomposition implementieren, um einen großen Prompt in fokussierte, geroutete Unteraufgaben zu zerlegen.

Multi-Agenten-Systeme (Die Microservices)

Wenn der Single-Agent-Ansatz einem Monolithen ähnelt, spiegelt dieser Ansatz eine Microservices-Architektur wider, indem die Arbeit auf spezialisierte Agenten aufgeteilt wird: einen Klassifizierungs-Agenten, einen Extraktions-Agenten, einen Regelabgleichs-Agenten und einen Zusammenfassungs-Agenten. Jeder Agent arbeitet mit seinem eigenen spezifischen Prompt, Kontextfenster und Tool-Zugriff.

CTOs, die eine Migration von einem Monolithen zu Microservices miterlebt haben, werden die folgende Struktur erkennen. Man gewinnt an Modularität. Man kann den Extraktions-Agenten aktualisieren, ohne den Klassifizierer zu berühren. Man kann das Regelabgleichsmodell unabhängig austauschen. Der Prompt jedes Agenten bleibt klein und fokussiert.

Man erbt auch die Betriebskosten, die mit verteilten Systemen einhergehen. Vier Agenten bedeuten, dass man nun mehrere Prompts pflegen und ein komplexes Koordinationsprotokoll sowie eine Nachrichtenübertragungsschicht verwalten muss.

Das größte Risiko sind Vertragsabhängigkeiten. Das Ausgabeschema des Klassifizierungs-Agenten ist der Eingabevertrag des Extraktions-Agenten. Ändert man dieses Schema, fallen die nachgeschalteten Agenten aus. In einem traditionellen Microservices-Stack verwalten Teams dies mit API-Versionierung und Integrationstests. In einer Agenten-Pipeline dient die Ausgabe des Klassifizierungs-Agenten als „Vertrag“ für die nachgeschalteten Extraktions- und Regel-Agenten. Eine einzige Schemaänderung kann sich kaskadenartig durch das gesamte System ziehen und erfordert eine koordinierte Aktualisierung aller Agenten-Prompts und -Logik. 

Diese Abhängigkeiten sind wichtig, weil sie nicht nur die Komplexität erhöhen, sondern auch die Betriebskosten des Systems steigern.

Kosten von Multi-Agenten-KI: Die Koordinationsabgabe auf Tokens und Entwicklungszeit

Kehren wir zum Fintech-Szenario zurück. Das Single-Agent-System verarbeitet ein Compliance-Dokument, indem es nacheinander vier Tool-Aufrufe tätigt: klassifizieren, extrahieren, Regeln abgleichen und zusammenfassen. Jedes Dokument kostet etwa 0,30 $ an API-Tokens. Bei 400 Dokumenten pro Woche sind das etwa 6.200 $ pro Jahr. Vorhersehbar und budgetierbar.

Lassen Sie uns denselben Workflow durch eine Vier-Agenten-Pipeline laufen. Jeder Agent hat seinen eigenen System-Prompt, was bedeutet, dass jeder Agent den Kontext unabhängig neu aufnimmt. Jede Übergabe zwischen Agenten erzeugt Koordinations-Tokens: Statusprüfungen, Ausgabevalidierung und Kontextübergabe. Diese Tokens verbessern nicht die nutzerseitige Ausgabe. Sie sind Koordinationsaufwand, der sich hauptsächlich in den Systemkosten niederschlägt.

In der Praxis verbrauchen Multi-Agenten-Systeme bis zu 15-mal mehr Tokens als ihre Single-Agent-Äquivalente. Im Fintech-Beispiel werden aus 6.200 $ pro Jahr 93.000 $. Ein Series-B-Unternehmen, das seine Mittel schnell aufbraucht, wird diese Zahl in den vierteljährlichen Vorstandssitzungen zu spüren bekommen.

Das Verhältnis von Genauigkeit zu Kosten ist bei Standard-Produktions-Workloads oft schwer zu rechtfertigen. Kontrollierte Experimente haben gezeigt, dass der Übergang von einem Single-Agent- zu einem Multi-Agent-Setup die Wahrheitsgetreue bei Q&A-Aufgaben um etwa 28 % verbessern kann, dies jedoch häufig zu einer 3,7-fachen Erhöhung der API-Kosten führt. 

Wenn Ihr Single-Agent-System Dokumente bereits mit 94 % Genauigkeit klassifiziert und die Multi-Agent-Version 97 % erreicht, zahlen Sie 3,7-mal mehr, um eine Lücke von 3 Prozentpunkten zu schließen. Wenn der Gewinn nur drei Prozentpunkte beträgt, könnten viele Teams feststellen, dass eine gezielte menschliche Überprüfung günstiger ist, als den Koordinationsaufwand eines Multi-Agent-Designs zu tragen.

Darüber hinaus sind die Kosten, die Teams oft überraschen, die Entwicklungszeit. Unserer Erfahrung nach erfordert der Aufbau eines Multi-Agent-Systems typischerweise das 3- bis 5-fache der Ingenieurstunden eines Single-Agent-Äquivalents, bedingt durch die Komplexität des Zustandsmanagements und der Fehlerbehandlung.

Latenz von Agenten in der Produktion: Von 18 Sekunden auf 3

In der Produktion wird nicht jede Anfrage von Multi-Agent-Systemen in einer angemessenen Zeit abgeschlossen.

In der Single-Agent-Compliance-Pipeline tätigt ein LLM nacheinander vier Tool-Aufrufe. Jeder Aufruf erhöht die Latenz, aber die Gesamtzeit bleibt vorhersehbar, da das Modell den Kontext über den gesamten Workflow hinweg beibehält. 

In einem Multi-Agent-System tätigt jeder Agent seinen eigenen LLM-Aufruf, und jeder Aufruf beginnt „kalt“. Der Klassifizierungs-Agent erzeugt eine strukturierte Ausgabe. Der Extraktions-Agent nimmt diese Ausgabe auf, lädt seinen eigenen System-Prompt und Kontext neu und erzeugt seine eigene Ausgabe. Der Regeln-Agent und der Zusammenfassungs-Agent tun dasselbe. Vier separate Inferenzaufrufe, jeder mit seinem eigenen Prompt-Overhead, jeder wartet darauf, dass der vorherige Agent fertig wird. In diesem Szenario summiert sich die Latenz.

In einem Produktionsfallimplementierte das Unternehmen eine Sechs-Agenten-Mesh-Architektur, bei der Agenten debattierten und zusammenarbeiteten. Das System funktionierte und führte zu einer P95-Latenz von 18 Sekunden und Kosten von 8-12 $ pro Abfrage. Für einen Workflow, dessen Abschluss ihre Nutzer viel schneller erwarteten, verhinderten diese Zahlen die Akzeptanz, noch bevor das Produktteam die Genauigkeit messen konnte.

Das Team baute das System mit nur zwei Agenten und einer strikten Zustandsmaschine neu auf. Anstatt die Agenten durch unstrukturierte Nachrichtenübermittlung koordinieren zu lassen, setzte die Zustandsmaschine eine feste Reihenfolge durch: Agent A schließt Schritt 1 ab und übergibt ein validiertes Schema an Agent B, der die Schritte 2 bis 4 ohne Verhandlung und konkurrierende Ausgaben abschließt.

Die Latenz sank auf 3 Sekunden, und die Kosten fielen auf 0,40 $ pro Abfrage. Der Genauigkeitsunterschied war vernachlässigbar. Der Genauigkeitsunterschied zwischen der Sechs-Agenten-Version und der Zwei-Agenten-Version betrug weniger als 1 %.

Das ist der entscheidende Kompromiss. Das Team verbrachte Monate damit, ein System zu entwickeln, das 30-mal teurer und 6-mal langsamer war, um eine Genauigkeitsverbesserung zu erzielen, die ihre Nutzer nicht wahrnehmen konnten. Der Neuaufbau, der sechs Wochen und zwei Ingenieure in Anspruch nahm, lieferte ein System, das die SLOs vom ersten Tag an erfüllte.

Multi-Agenten-Systeme können in Bereichen gerechtfertigt sein, in denen selbst eine Genauigkeitslücke von 1 % ein echtes regulatorisches oder klinisches Risiko birgt. Das Problem ist, dass viele Teams sich dieser Komplexität verschreiben, bevor sie messen, ob die Lücke tatsächlich existiert.

Fehlerbehebung bei Single-Agent- vs. Multi-Agent-Fehlern

Das größte Risiko für einen Bereitschaftsingenieur ist ein verteilter Fehler. In einer Single-Agent-Architektur sind Fehler linear: Ein Ingenieur kann die Eingabeaufforderung lesen, die Ausgabe prüfen und die Lücke innerhalb von Minuten identifizieren.

In einem Multi-Agenten-Netzwerk sind Fehler dezentralisiert. Wenn ein System eine falsche Antwort liefert, erfordert die Fehlersuche das Nachverfolgen einer Konversation über mehrere LLM-Aufrufe hinweg, um festzustellen, welcher Agent den Widerspruch eingeführt hat. Ohne eine starre Zustandsmaschine ist dieser Prozess unter Produktionsdruck oft unlösbar.

In dieser Art von Architektur kann die Fehlersuche leicht 45 Minuten bis zwei Stunden dauern.

Zwei Eigenschaften machen dieses Fehlermuster gefährlich:

• Die Ausgabe sah korrekt aus. Jeder Agent validierte nur gegen seinen eigenen Kontext. Die abschließende Zusammenfassung wirkte glaubwürdig, obwohl sie falsch war. Ein Compliance-Beauftragter, der große Mengen prüft, hätte keinen Grund gehabt, sie in Frage zu stellen.
• Der Fehler verlief unbemerkt. Kein Agent meldete einen Fehler. Kein Schema wurde verletzt. Eine selbstbewusste Fehlklassifizierung kaskadierte unangefochten durch drei nachgeschaltete Agenten.

Die architektonische Lösung ist die Schema-Validierung an jeder Agenten-Grenze. Wenn eine Übergabe die Validierung nicht besteht, stoppt die Pipeline und protokolliert genau, wo der Vertrag gebrochen wurde. Doch der Aufbau und die Wartung dieser Validierungsschicht konkurriert mit der Produktentwicklung um die Zeit Ihrer Ingenieure.

Das wirft die Frage auf, auf die dieser Artikel hinausläuft: Kann Ihr Team die Multi-Agenten-Komplexität aufnehmen, ohne die Roadmap zu verzögern?

Framework: Wann sich eine Multi-Agenten-Architektur trotz ihrer Komplexität lohnt

Dieser Abschnitt wandelt die frühere Analyse in ein Framework um, das Sie auf Ihr eigenes System anwenden können.

Beginnen Sie mit der Baseline, nicht mit der Architektur.

Bevor Sie Multi-Agenten-Designs bewerten, messen Sie, was ein Single-Agent-System leistet. Die meisten Teams überspringen diesen Schritt. Sie planen zuerst die Multi-Agenten-Version, weil sie sich sauber auf die logische Zerlegung des Problems abbilden lässt: ein Agent pro Unteraufgabe. Diese Abbildung wirkt sauber, aber sie verlagert die Koordinationskosten nach vorne, bevor sie wissen, ob die einfachere Version nicht ausreicht.

Die Bewertungsreihenfolge ist:

Beginnen Sie mit der Optimierung des Single-Agent-Workflows und messen Sie Genauigkeit, Latenz und Stückkosten. Verbessern Sie dann die Retrieval-Funktion. Straffen Sie dann die Tool-Schicht. Messen Sie nach jeder Änderung erneut.

Wenn sich die Qualitätslücke schließt, haben Sie Monate an Multi-Agenten-Entwicklung gespart. Wenn nicht, haben Sie nun eine quantifizierte Lücke: „Unser Single-Agent-System klassifiziert Dokumente mit einer Genauigkeit von 89 %. Unser Compliance-Team benötigt 97 %. Prompt Engineering und Verbesserungen bei der Retrieval-Funktion brachten uns auf 93 %. Die verbleibenden 4 % kosten uns X Dollar pro Monat an manueller Überprüfung.“

Eine quantifizierte Leistungslücke ist die stärkste Rechtfertigung für das Hinzufügen von Agenten. Ohne sie bauen Sie eine Multi-Agenten-Infrastruktur auf, um ein Problem zu lösen, dessen Existenz Sie nicht bewiesen haben.

Bewerten Sie die operative Obergrenze Ihres Teams.

Multi-Agenten-Systeme erfordern spezifische technische Fähigkeiten, die Ein-Agenten-Systeme nicht benötigen. Bevor Sie sich für die Architektur entscheiden, prüfen Sie, ob Ihr Team diese Funktionen besetzen kann:

• Verantwortung für Schnittstellenverträge. Jemand pflegt Datenschemata zwischen Agenten und testet jeden nachgeschalteten Agenten, wenn sich Formate ändern.
• Verteiltes Debugging. Ihre Bereitschaftsingenieure müssen Fehler über mehrere Agenten-Logs hinweg innerhalb Ihrer Incident-SLA verfolgen.
• Prompt-Regressionstests. Jedes Modell-Update erfordert Tests über alle Agenten hinweg. Eine kleine Anpassung eines Prompts in einem Agenten kann andere Agenten unbemerkt beeinträchtigen.

Ein 15-köpfiges Team ohne dedizierte ML-Ingenieure kann ein Ein-Agenten-System mit Standard-DevOps-Praktiken betreiben. Der Betrieb einer Vier-Agenten-Pipeline mit Vertragstests, verteiltem Tracing und Prompt-Regression erfordert mindestens zwei bis drei Ingenieure, die einen erheblichen Teil ihrer Zeit für die Agenten-Infrastruktur anstatt für Produktarbeit aufwenden. Für viele Series-B-Teams bedeutet das eine Umleitung von 15-20 % der Ingenieurskapazität weg von der Roadmap.

Prüfen Sie die Domänentiefe, bevor Sie Reflexion hinzufügen.

Eines der häufigsten Verkaufsargumente für Multi-Agenten-Systeme sind „selbstkorrigierende Agenten“: Agent A generiert eine Antwort, Agent B kritisiert sie, Agent A überarbeitet sie. Das Argument impliziert, dass mehr Agenten durch iterative Verfeinerung genauere Ergebnisse liefern.

„Selbstkorrigierende Agenten“ funktionieren in Domänen, in denen das Basismodell eine starke Abdeckung hat. In spezialisierten Domänen kann eine Reflexionsschleife die bestehenden blinden Flecken des Modells verstärken, anstatt sie zu korrigieren. Ein Reflexionsagent kann Formatierung und interne Konsistenz prüfen. Er kann Fakten nicht anhand von Vorschriften überprüfen, die er nicht kennt. 

Bevor Sie in Multi-Agenten-Reflexion investieren, testen Sie, ob das Basismodell domänenspezifische Fragen genau beantworten kann, wenn es den richtigen Kontext durch Retrieval erhält. Wenn Retrieval ausreicht, um das Basismodell zuverlässig zu machen, ist ein Ein-Agenten-Design in der Regel die bessere Wahl. Wenn Retrieval die Lücke immer noch nicht schließt, ist es unwahrscheinlich, dass zusätzliche Agenten das zugrunde liegende Wissensproblem lösen.

Die Bewertung im Fintech-Fall.

Der Compliance-CTO aus Abschnitt II würde dieses Framework wie folgt durchgehen. Das Ein-Agenten-System klassifiziert Dokumente nach Prompt-Optimierung und Retrieval-Verbesserungen mit einer Genauigkeit von 93 %. Das Compliance-Team benötigt 97 % für die Audit-Bereitschaft. Die 4 %-Lücke kostet monatlich etwa 4.200 US-Dollar für die manuelle Überprüfung falsch klassifizierter Dokumente. Ein Multi-Agenten-System mit einem dedizierten Klassifizierungsagenten könnte diese Lücke schließen, würde aber die API-Kosten von 6.200 US-Dollar auf geschätzte 40.000-60.000 US-Dollar pro Jahr erhöhen, 6-8 Wochen Entwicklungszeit hinzufügen, zwei Ingenieure für die laufende Wartung der Agenten-Infrastruktur erfordern und die Debugging-Zeit von Minuten auf Stunden verlängern.

Die Entscheidung des CTO: Lohnt es sich, eine Genauigkeitslücke von 4 % für 35.000-55.000 US-Dollar zusätzliche jährliche API-Kosten, 15 % der Ingenieurskapazität, die für die Agentenwartung umgeleitet wird, und eine Vervierfachung der Incident-Lösungszeit zu schließen? Für einige Compliance-Umgebungen lautet die Antwort ja. Für die meisten Series-B-Unternehmen, die ihre Mittel aufbrauchen, lautet die Antwort noch nicht.

Dieses „noch nicht“ ist wichtig. Das Framework besagt nicht, dass Multi-Agenten-Systeme falsch sind. Es besagt, dass sie das letzte Werkzeug sein sollten, zu dem man greift, nachdem einfachere Verbesserungen gemessen und ausgeschöpft wurden.

Fazit

Entwerfen Sie das System unter der Annahme, dass jede Modellausgabe falsch sein kann. Dies gilt, egal ob Sie einen oder zehn Agenten betreiben. Die Frage ändert sich von „Wie intelligent ist mein Agent?“ zu „Was passiert, wenn dieser Agent Unsinn produziert?“ Teams, die Modellfehler einplanen, bauen eher Systeme, die in der Produktion bestehen, nicht nur in Demos.

Die Beweise in diesem Artikel weisen in eine Richtung. Eine Multi-Agenten-Compliance-Pipeline kostet 93.000 US-Dollar pro Jahr, während eine Ein-Agenten-Version 6.200 US-Dollar kostet. Sie fügt Sekunden an Latenz hinzu, die die Benutzerakzeptanz zunichtemachen. Sie verwandelt eine 10-minütige Debugging-Sitzung in eine zweistündige Verfolgung über vier Agenten-Logs hinweg. Und die Genauigkeitsverbesserung, die all diesen Mehraufwand rechtfertigt, ist oft geringer als das, was bessere Prompts und Retrieval allein liefern können.

Bevor Sie sich für ein Multi-Agenten-Design entscheiden, vergleichen Sie die Ausgangsbasis mit der Alternative hinsichtlich Leistung, Betriebskosten, Ingenieursaufwand und Belastung durch Incident Response. Die Teams, die zuverlässige KI-Systeme liefern, sind nicht diejenigen mit den meisten Agenten. Es sind diejenigen, die sich jeden hinzugefügten Agenten verdient haben.