One Man Band

Der Newsletter für technische Entscheider, Business-Strategen und KI-Interessierte.

Heute auf der Setlist: Wann sich der Einsatz von mehr als einem Agenten lohnt, und wann nicht.

🎚️ Soundcheck

In Ausgabe #010 ging es um die Frage, an welchen konkreten Systemgrenzen ein standardisiertes Protokoll zwischen Agenten nötig wird. Diese Ausgabe geht an dieser Stelle einen Schritt zurück und beantwortet die Frage: Braucht es überhaupt einen zweiten Agenten?

Ein Recherche-Agent, ein Schreib-Agent, ein Prüf-Agent… So werden aktuell viele agentische Systeme konzipiert. Und das Ergebnis muss natürlich viel besser sein als das eines einzelnen Agenten, der alles allein macht. Die Studienlage der letzten Monate widerspricht dieser Erwartung ziemlich deutlich, allerdings aber auch nicht pauschal. Ob Multi-Agent hilft oder schadet, hängt von der Form der Aufgabe ab, und genau diese Form lässt sich vorher natürlich bestimmen.

🎤 Main Set: Was aktuelle Studien zeigen

Zwei Aufgabenformen, zwei gegensätzliche Ergebnisse

Die umfangreichste Untersuchung stammt aus Princeton („Single-agent or Multi-agent Systems? Why Not Both?“) und vergleicht beide Ansätze über mehrere typische Agenten-Anwendungen hinweg. Im Kern besagt sie folgendes: Bei Aufgaben, die sich in voneinander unabhängige Teile zerlegen lassen, etwa eine Analyse, in der Markt, Kosten und Umsatz getrennt betrachtet werden können, bringt eine zentral koordinierte Multi-Agent-Struktur klare Verbesserungen. Bei sequenziellen Aufgaben dagegen, in denen jeder Schritt auf dem Ergebnis des vorigen aufbaut, schnitten alle getesteten Multi-Agent-Architekturen schlechter ab als ein einzelner Agent, je nach Variante um 39 bis 70 Prozent.

Eine weitere Studie legt darüber hinaus den Fokus auch auf die Wirtschaftlichkeit und dementsprechend auf das Budget an Reasoning-Token. Hält man es konstant, erreicht ein einzelner Agent auf Multi-Hop-Aufgaben durchgängig dasselbe Niveau wie die Multi-Agent-Varianten oder übertrifft sie, und das über drei verschiedene Modellfamilien hinweg. Dass Multi-Agenten-Systeme augenscheinlich besser performten war also schlicht ein Effekt des größeren Gesamtbudgets, welches über die Agenten verteilt lag.

Die Kosten der „Übergabe“

Der Grund für das schwache Abschneiden bei sequenziellen Aufgaben liegt in der Übergabe selbst. Wenn Agent A an Agent B übergibt, muss der Kontext mitwandern, und dafür gibt es nur zwei Wege. Entweder wird der vollständige Kontext übergeben, was teuer ist und irgendwann das Fenster sprengt, oder er wird zusammengefasst, was dazu führt, das Kontext verloren geht, und diese Verluste summieren sich mit jeder weiteren Übergabe, quasi wie bei dem Spiel „Stille Post“. Dazu kommt, dass Fehler in Ketten sich super fortpflanzen.

Multi-Agent-Systeme verbrauchen darüber hinaus ein Vielfaches an Token, eine Messung der University of Illinois kommt je nach Muster auf das 4- bis 220-Fache (!!!!) eines einzelnen Agenten. Eine weitere aktuelle Studie zeigt, dass ein einzelnes Modell in einem mehrstufigen Gespräch mehrere Rollen selbst spielen kann, denselben Zwischenspeicher wiederverwendet und dabei die Qualität eines echten Multi-Agent-Aufbaus erreicht oder leicht übertrifft, zu deutlich geringeren Kosten.

🥁 Track 2: Welche Fragen man sich vor dem Multi-Agent System stellen sollte

• Ist die Aufgabe in unabhängige Teile zerlegbar? Wenn mehrere Teilaufgaben ohne Kenntnis der jeweils anderen bearbeitet werden können, lohnt sich die Parallelisierung über Sub-Agenten, koordiniert von einem übergeordneten Agenten, der die Orchestrierung (Aufteilung & Zusammenführung) übernimmt. Die Sub-Agenten arbeiten also auf getrennten Teilaufgaben und sehen die Ergebnisse der anderen während der Bearbeitung nicht.
• Ist die Aufgabe eine Kette? Wenn jeder Schritt das Ergebnis des vorigen braucht, ist ein einzelner Agent mit guten Tools und ausreichendem Budget sowie Kontextfenster die bessere Wahl.
• Gibt es eine Sicherheitsgrenze? Wenn ein Teil des Workflows nicht vertrauenswürdige Inhalte liest und ein anderer Teil kritische Aktionen ausführt, ist die Trennung in eigene Agenten ein Sicherheitsinstrument (siehe Trifecta-Regel aus Ausgabe #012).

🎯 Encore: Der eine Gedanke für Entscheider

Multi-Agent Systeme nicht als Qualitätsgarant ansehen. Parallelität über unabhängige Teilaufgaben, oder eine Grenze, die aus Verantwortungs- oder Sicherheitsgründen bestehen muss, entscheiden darüber, ob es mehrere Agenten sein sollten. Fehlt beides, kostet die Aufteilung nur Kontext, Token und Zuverlässigkeit, ohne wirklich erkennbaren Mehrwert.

Die Prüffrage für Entscheider: Haben wir einen einzelnen Agenten mit denselben Tools und demselben Token/Kontext-Budget als Vergleichsbasis herangezogen, bevor wir die Multi-Agent-Architektur gebaut haben?

💿 B-Side

Anti-Pattern: Eine lineare Aufgabe auf einen Recherche-, einen Schreib- und einen Prüf-Agenten verteilen, alle drei mit demselben Modell. Das erzeugt zwei Übergaben mit Kontextverlust und den dreifachen Token-Verbrauch für eine Arbeit, die ein einzelner Agent in einem Durchlauf mit vollständigem Kontext erledigen kann. Der Prüfschritt lässt sich hier dabei natürlich behalten (entsprechend auch ohne Multi-Agent System), nämlich als zweiten Aufruf desselben Agenten mit klarer Prüfanweisung.

Es lohnt sich also: Vor jeder Aufteilung den einzelnen Agenten als Baseline bauen, ihm dieselben Tools und dasselbe Gesamtbudget geben und beide Varianten am selben Testset messen.

---

Das war Rag'n'Roll #014.

Weiterleiten erwünscht🤘