# Multi-Agenten-Systeme: Praktischer Leitfaden für Ops-Teams URL: https://commandergpt.app/de/journal/multi-agenten-systeme-ops-teams Type: blog Locale: de Published: 2026-09-30 Updated: 2026-09-30 --- > Ein Multi-Agenten-System delegiert Aufgaben an spezialisierte KI-Agenten mit eigenem Kontext und Werkzeugen, koordiniert durch einen Lead-Agent. ## Was ist ein Multi-Agenten-System? Es ist eine Gruppe von KI-Agenten, die eine Aufgabe aufteilen: jeder mit eigenem Auftrag, Werkzeugen und Kontextfenster, koordiniert durch einen Lead-Agent oder eine feste Handoff-Reihenfolge. Wenn du bereits mit einem einzelnen Agenten an dessen Grenzen stößt, ist dies die nächste Architektur, die du verstehen musst. Unten: wie es in einem Ops-Stack funktioniert und wann es mehr kostet als es bringt. **Kurzbriefing (30 Sekunden):** Ein Agent macht alles in einem langen Kontext. Ein Multi-Agenten-System gibt jeden Schritt einem Spezialisten und fügt einen Koordinator hinzu. Du gewinnst parallele Arbeit und saubere Outputs. Du zahlst in Token, Latenz und Debug-Zeit. ## Was ist ein Multi-Agenten-System in praktischen Ops-Begriffen? Stelle dir vor, wie dein Team einen Deal-Review durchführt. Eine Person holt Kontodaten. Eine andere prüft die Passung zum Ideal Customer Profile (ICP). Eine dritte entwirft den Follow-up. Ein Lead liest alle drei Outputs und entscheidet, was versendet wird. Ein Multi-Agenten-System kopiert diese Form in Software. Jeder Agent ist ein Modellaufruf mit enger Anweisung, eigenem Werkzeugsatz und eigenem Arbeitsspeicher. Ein Koordinator teilt die Aufgabe auf, sendet die Teile raus und fasst die Ergebnisse zusammen. Ein konkreter Fall: Ein Customer Success Manager will eine wöchentliche Health Summary für 40 Konten. Ein Agent, der 40 Support-Historien, 40 Usage-Exporte und 40 Renewal-Notizen liest, verliert ab Konto 15 den Überblick. Vierzig kleine Worker, die je ein Konto lesen, plus ein Lead, der die Ergebnisse ranked, schaffen das. Das ist die Kernidee: breite Aufgabe in enge Aufgaben aufteilen, dann wieder zusammensetzen. Zwei Merkmale zählen. Erstens: Jeder Agent hält nur, was er braucht, sein Kontext bleibt klein und fokussiert. Zweitens: Agenten tauschen strukturierte Outputs aus, nicht freie Chat-Einträge. Lässt du eine der beiden Bedingungen fallen, hast du einen Gruppenchat, kein System. ![Whiteboard mit Sticky Notes und Pfeilen, die einen Handoff zwischen Spezialisten-Schritten darstellen](https://fdzlnqpwsaniezitwiuw.supabase.co/storage/v1/object/public/cms-media/commandergpt/2026-09/8ed860-i1.webp) ## Unterschied zu einem einzelnen Agenten oder Chatbot? Ein Chatbot antwortet auf einen Prompt. Ein einzelner Agent verfolgt ein Ziel über mehrere Schritte hinweg und ruft unterwegs Werkzeuge auf. Das haben wir im [Breakdown Agent vs. Chatbot](/journal/ai-agent-vs-chatbot-ops-stack) abgedeckt. Ein Multi-Agenten-System addiert eine dritte Schicht: mehrere Agenten, die je einen Slice des Ziels besitzen. Der Unterschied zeigt sich an drei Stellen. - **Kontext.** Ein einzelner Agent schleppt jedes Werkzeugergebnis durch ein Fenster. Spezialisten sehen nur ihren Slice. - **Parallelismus.** Ein Agent arbeitet sequenziell. Ein Lead kann fünf Worker gleichzeitig starten. - **Fehlerfall.** Ein Agent schlägt komplett fehl. In einem System schlägt ein Worker fehl, der Lead kann nur diesen Piece neu starten. Es gibt auch einen Governance-Aufside, den Ops-Teams oft unterschätzen. Da jeder Worker eine enge Rolle hat, kannst du ihm enge Berechtigungen geben. Der Research-Worker liest das CRM. Nur der finale Schritt schreibt hinein. Wenn etwas schiefgeht, ist die Blast Radius eine Rolle, nicht deine ganze Pipeline. Die Kosten dieser Flexibilität sind Koordination. Jeder Handoff ist ein Ort, wo Information verlorengeht oder verzerrt wird. ## Wie funktioniert ein Multi-Agenten-System wirklich? Meiste Produktions-Setups nutzen eines von drei Mustern. Wähle nach der Form deiner Aufgabe, nicht danach, was fortgeschritten klingt. **Orchestrator und Worker.** Ein Lead-Agent liest die Anfrage, plant, startet Worker und fasst Outputs zusammen. Der Lead entscheidet Subtasks zur Laufzeit. Das passt zu Research und Open-ended Prep. **Pipeline.** Agenten laufen in fester Reihenfolge: Agent-A-Output ist Agent-B-Input. Kein Koordinator nötig. Das passt zu Arbeit, die du bereits als Standard Operating Procedure (SOP) schreiben könntest: enrichen, scoren, draften. Jede Phase benötigt nur den Output der vorherigen Phase, nicht das volle Original-Kontextfenster. **Review Loop.** Ein Agent produziert, ein anderer kritisiert gegen eine Checkliste, der erste revidiert. Das passt zu allem, wo Qualitätsgates wichtiger sind als Speed, wie Outbound-Copy oder Contract-Zusammenfassungen. Die Review-Schleife ermöglicht mehrere Iterationen, bis der Qualitäts-Benchmark erreicht ist. Anthropics veröffentlichte den detailliertesten Public Write-up des ersten Musters. Im [Multi-Agent Research System Post](https://www.anthropic.com/engineering/multi-agent-research-system) übertraf ein Claude Opus 4 Lead mit Claude Sonnet 4 Subagents einen einzelnen Claude Opus 4 Agenten um 90,2% in Anthropics internem Research Benchmark. Lies diese Zahl als Ergebnis für Open-ended Research, nicht als Versprechen für dein CRM-Cleanup. Die Lektion ist relevant: spezialisierte Worker mit engen Kontexten produzieren bessere Ergebnisse. ![Mehrere Teamkollegen arbeiten parallel, während ein Lead das kombinierte Output review](https://fdzlnqpwsaniezitwiuw.supabase.co/storage/v1/object/public/cms-media/commandergpt/2026-09/88df63-i2.webp) ### Schritt 1: Den Delegation Brief vor allem schreiben Der häufigste Fehler ist ein vager Handoff. "Research dieses Konto" an drei Worker produziert drei überlappende Antworten und eine verschwendete Laufzeit. Gib jedem Worker vier Dinge: ein Ziel, ein Output-Format, die Werkzeuge und Quellen, die er nutzen darf, und eine Stoppregel. Das ist der ganze Vertrag. Hier ein Brief für einen Prospect Research Worker: - Ziel: Die drei neuesten Funding- oder Hiring-Signale für ein Konto auflisten. - Format: Eine Tabelle mit Signal, Datum, Source URL. - Werkzeuge: Web-Suche und das CRM-Datensatz nur. - Stop: Nach fünf Quellen oder zehn Minuten, was zuerst kommt. Schreib den Brief einmal auf, speicher ihn als Befehl und wiederhole ihn. In CommanderGPT heißt das ein `/research` Slash-Befehl mit dem Brief eingebaut, sodass niemand ihn neu tippt. HQ-Regeln: ein Befehl pro Worker-Rolle, keine Ad-hoc-Prompts. Ein sauberer Brief verhindert Missverständnisse und Token-Verschwendung. ## Wo schlägt es einen Agenten, wo verliert es? Multi-Agent verdient sein Geld bei Arbeit, die sich sauber aufteilt. Research über viele Quellen, Prep über viele Konten, Audits über viele Dokumente qualifizieren sich. Worker laufen nebeneinander, der Lead näht die Ergebnisse. Es verliert bei eng gekoppelter Arbeit. Wenn Schritt 4 alle Details aus Schritt 1-3 braucht, zwingt dich das Aufteilen, all diese Detail durch eine Zusammenfassung zu quetschen. Anthropic macht den gleichen Punkt über sein eigenes System: die meisten Coding-Tasks haben weniger echt parallelisierbare Teile als Research, und Agenten sind noch nicht großartig darin, sich gegenseitig real-time zu koordinieren und zu delegieren. Skip Multi-Agent wenn eines davon wahr ist: - Die Aufgabe passt komfortabel in ein Context Window. - Jeder Schritt braucht das volle Detail des vorherigen. - Du kannst die Rollen der Worker nicht in je einem Satz beschreiben. - Der Job läuft ein paar mal im Monat. Die Setup-Zeit zahlt sich nie aus. Wert aufzubauen, wenn die Aufgabe parallel ist, die Rollen unterschiedlich und du läufst es täglich. ![Eine Stoppuhr neben einem Stapel Münzen, die Zeit und Token-Kosten mehrerer Agenten darstellen](https://fdzlnqpwsaniezitwiuw.supabase.co/storage/v1/object/public/cms-media/commandergpt/2026-09/b8e937-i3.webp) ## Was kostet ein Multi-Agenten-System? Tokens, hauptsächlich. Anthropic berichtet, dass Agenten etwa 4-mal mehr Tokens als Chat verwenden, Multi-Agenten-Systeme etwa 15-mal mehr. Diese Zahlen stammen aus ihrem Research-Workload, behandle sie als eine Größenordnung, nicht als ein Angebot für deine Rechnung. Eine real-world Deployment hängt stark von den genutzten Modellen, der Komplexität der Subtasks und der Retry-Logik ab. Die praktische Regel: Rechne die Zahlen auf einer echten Aufgabe durch, bevor du sie skalierst. Zähle Tokens pro Run, multipliziere mit Runs pro Woche, vergleiche mit eingesparten Minuten. Wenn ein Prep-Workflow 20 Minuten spart und ein paar Dollar Model Usage kostet, ist das normalerweise ein guter Trade. Wenn er 2 Minuten spart und gleich viel kostet, nicht. Break even ist der Punkt, wo die zeitliche Einsparung die Model-Kosten rechtfertigt. Latenz ist die zweite Kosten. Jede Koordinator-Entscheidung addiert einen Round Trip. Begrenzen Sie die Anzahl der Worker, begrenzen Sie die Wiederholungen und setzen Sie ein hartes Timeout. Eine Orchestrierung mit zehn Agenten ist nicht schneller als ein einzelner Agent mit langen Context Windows. ## Welche Tools lassen dich eines ohne Code-Schreiben bauen? Du hast drei realistische Routen in 2026. **Agent-Builder:** No-Code-Tools lassen dich Agenten und Handoffs visuell definieren. Sie passen zu wiederkehrenden Business-Workflows und kleine Teams. Beispiele: Make, Zapier mit erweiterten Workflows, specialized Agent Builders wie n8n. **Command-based Chaining:** Slash-Befehle und Workflow-Ketten passen zu Teams, die wiederverwendbare, inspizierbare Schritte in Slack oder Command Palette wollen. Raycast deckt die Launcher-Seite, CommanderGPT addiert Chaining und geteilte Team Playbooks oben drauf. Diese Route ist ideal, wenn dein Team bereits Slash-Commands liebt. **Code-Frameworks:** Wenn dein Team Engineer hat, geben Frameworks volle Kontrolle über Orchestration, zum Preis von Wartung. Ops-Teams ohne diese Kapazität sollten mit den ersten zwei Routen starten. Python-basierte Frameworks wie Swarm von Anthropic oder LangGraph erlauben vollständige Kontrolle über Delegation und State Management. Welche Route du wählst, logge jeden Handoff. Wenn die Final Output falsch ist, musst du sehen, welcher Worker die schlechte Input geliefert hat. Logging ist der Schlüssel zu Debugging und Improvement. ## Was bricht zuerst in einem Multi-Agenten-System? Drei Dinge, in dieser Reihenfolge. **Stille, teilweise Outputs:** Ein Worker läuft Zeit ab und returnt nichts, der Lead schreibt die finale Antwort trotzdem. Fix: Require jeden Worker, einen expliziten Status zu returnen: done, partial oder failed. **Doppelte Arbeit:** Zwei Worker bekommen überlappende Briefs und versengen Tokens auf die gleichen Quellen. Fix: Enger stecke Aufgaben-Grenzen im Brief. **Drift auf langen Ketten:** Jeder Handoff verliert etwas Detail. Nach Schritt fünf ist das Ziel verschwommen. Fix: Das Original-Request zu jedem Worker passen, nicht nur das vorherige Output. Test die Fehlerfälle absichtlich während des Setups. Töte ein Werkzeug, returne ein leeres Ergebnis und schaue, was der Lead macht. Besser eine Dienstagnachmittag-Überraschung als eine vor einem Kunden. Produktive Systeme sind immer mit echten Fehlern getestet worden. ## Dein nächster Befehl: Mit zwei Agenten starten, nicht sieben Wähle einen Workflow, den du bereits jede Woche von Hand läufst. Teile ihn in zwei Rollen maximal: ein Produzent und ein Checker. Schreib einen vierzeiligen Brief für jeden. Lauf es zehn mal und logge, was bricht. Füge einen dritten Agenten nur hinzu, wenn die Zwei-Agent-Version einen klaren Engpass zeigt. Die meisten Ops-Workflows zahlen sich zwischen zwei und vier Agenten aus. Mission erfüllt, wenn der Two-Agent Run deinen manuellen Version in eingesparten Minuten und Fehlerquote schlägt. Bis dahin spielt nichts anderes in diesem Guide eine Rolle. ## FAQ ### Was ist ein Multi-Agenten-System in einfachen Worten? Ein Multi-Agenten-System ist eine Gruppe von KI-Agenten, die je einen Teil einer größeren Aufgabe übernehmen, koordiniert durch einen Lead-Agent oder eine feste Handoff-Reihenfolge. Jeder Agent hat seine eigenen Anweisungen, Werkzeuge und Kontext, sodass kein einzelnes Modell die ganze Aufgabe halten muss. ### Wie unterscheidet sich ein Multi-Agenten-System von einem einzelnen KI-Agenten? Ein einzelner Agent verfolgt das ganze Ziel in einem Kontext und einer Sequenz. Ein Multi-Agenten-System teilt das Ziel zwischen Spezialisten auf, die parallel laufen können, und ein Koordinator fasst ihre Outputs zusammen. Du gewinnst Fokus und Parallelismus, zahlst aber in Token, Latenz und Koordinations-Overhead. ### Wann sollte ein Ops-Team mehrere Agenten statt einen nutzen? Nutze mehrere Agenten, wenn sich die Arbeit sauber aufteilt, die Rollen unterschiedlich sind und der Workflow oft läuft, zum Beispiel Prospect Research über viele Konten. Bleib bei einem Agenten, wenn die Aufgabe in ein einzelnes Fenster passt oder jeder Schritt das volle Detail des letzten braucht. ### Sind Multi-Agenten-Systeme teurer zum Ausführen? Ja, normalerweise. Anthropic berichtet, dass Multi-Agenten-Systeme in ihrem Research Workload etwa 15-mal mehr Tokens verwenden als Chat, versus etwa 4-mal für einen einzelnen Agenten. Messe Tokens pro Run auf deiner Aufgabe und vergleiche mit eingesparten Minuten. ### Was sind die Haupt-Multi-Agent-Muster? Die drei gemeinen sind Orchestrator and Workers (ein Lead plant und delegiert zur Laufzeit), eine feste Pipeline (jeder Agent speist den nächsten) und eine Review Loop (ein Agent produziert, ein anderer kritisiert). Wähle nach der Form deiner Aufgabe. ### Kann ich einen Multi-Agent-Workflow ohne Code bauen? Ja. No-Code Agent-Builder und Slash-Command-Ketten lassen Ops-Teams Rollen und Handoffs ohne Engineering-Hilfe definieren. Starten Sie mit zwei Agenten, schreiben Sie einen kurzen Delegation Brief für jeden und loggen Sie jeden Handoff, sodass Fehler leicht zu tracen sind.