{"author":{"@type":"Person","name":"Alexander Bock","url":"https://abxk.ai/de/autor/alexander-bock/"},"categories":["AI Development"],"content":{"markdown":"Ein Agent mit guten Tools kann viel leisten. Manche Aufgaben sind aber zu breit für ein Kontextfenster, oder sie brauchen unterschiedliche Fähigkeiten und Rechte. Dann teilen Teams die Arbeit auf: Ein Agent plant, mehrere recherchieren parallel, ein weiterer prüft das Ergebnis. Gut gemacht, steigt die Qualität. Schlecht gemacht, vervielfachen sich Kosten, Fehler und Verwirrung.\n\nDies ist Teil 3 von Level 4 (Experte) im Lernpfad AI Development. Sie lernen vier bewährte Muster kennen, erfahren, wann mehrere Agenten helfen und wann sie schaden, wie sich Fehler und Kosten aufschaukeln, wie Sie einen Multi-Agenten-Lauf nachverfolgen und wo Menschen prüfen müssen. Der Teil baut auf [KI-Agenten mit Tools, Schleifen und Gedächtnis](/de/ai-development/learn/build-ai-agents-tools-loops-memory/) aus Level 3 auf.\n\n## Was ein System zum Multi-Agenten-System macht\n\nEin **Multi-Agenten-System** besteht aus mehreren Agenten mit jeweils eigenen Anweisungen, eigenem Kontext, eigenen Tools und Rechten, die einander Arbeit übergeben. Entweder koordiniert Ihr Code sie über feste Wege, oder ein Agent entscheidet zur Laufzeit, wer was erledigt. Anthropic nennt die erste Form einen **Workflow** und die zweite einen **Agenten** im engeren Sinn (Quelle: Anthropic, „Building effective agents“, 2024). Viele Systeme, die als Multi-Agenten-System gelten, sind eigentlich Workflows — oft eine gute Nachricht, denn feste Wege lassen sich leichter testen.\n\nMehrere Agenten können echte Vorteile bringen:\n\n- **Saubere Kontexte.** Jeder Agent sieht nur, was seine Teilaufgabe braucht, statt eines überquellenden Kontexts.\n- **Parallele Arbeit.** Unabhängige Teilaufgaben laufen gleichzeitig, das verkürzt die Wartezeit.\n- **Spezialisierung.** Jede Rolle bekommt eigenen Prompt, eigene Tools und bei Bedarf ein eigenes Modell.\n- **Geringste Rechte.** Ein Recherche-Agent darf lesen, aber nichts verschicken; schreiben darf nur einer.\n- **Unabhängige Prüfung.** Ein zweiter Agent mit eigenen Anweisungen prüft die Arbeit des ersten.\n\nZwei offene Protokolle verbinden die Teile. Das **Model Context Protocol** (MCP), von Anthropic im November 2024 veröffentlicht, vereinheitlicht, wie Agenten auf Tools und Daten zugreifen. Das Protokoll **Agent2Agent** (A2A), von Google im April 2025 vorgestellt, beschreibt, wie Agenten verschiedener Systeme Aufgaben austauschen.\n\n## Vier bewährte Muster\n\nDie meisten echten Systeme bestehen aus wenigen Grundmustern:\n\n![Vier Felder mit kleinen Diagrammen: ein Orchestrator-Agent, der Aufgaben an drei Worker verteilt, eine Pipeline aus drei Agenten in Reihe, ein Erzeuger und ein Prüfer in einer Schleife sowie drei Agenten um einen gemeinsamen Speicher, jeweils mit Einsatzzweck und Hauptrisiko](/images/learn/de/multi-agent-systems-patterns.webp \"Vier Grundmuster. Viele echte Systeme kombinieren zwei davon.\")\n\nDie Tabelle nennt die vier Muster und ergänzt die Debatte, eine Forschungsvariante des Prüfer-Musters:\n\n| Muster | Gut für | Hauptrisiko | Kontrolle |\n|---|---|---|---|\n| Orchestrator und Worker | Breite Recherche, parallele Teilaufgaben | Doppelte Arbeit, vage Aufträge | Ein genauer Auftrag je Worker: Ziel, Ausgabeformat, Grenzen, Tools |\n| Pipeline | Feste Stufen wie auslesen, prüfen, schreiben | Fehler wandern nach hinten weiter | Schema-Validierung zwischen den Stufen |\n| Erzeuger und Prüfer | Entwürfe mit klaren Qualitätskriterien | Endlosschleifen, gleiche blinde Flecken | Rundenlimit; Bewertungsraster oder anderes Modell für den Prüfer |\n| Debatte oder Abstimmung | Schwierige Fragen mit überprüfbarer Antwort | Kosten wachsen mit jedem Agenten; Einigung auf eine falsche Antwort | Nur dort, wo Ihre Evals einen Gewinn zeigen |\n| Gemeinsamer Speicher | Lange Aufgaben, die auf Funden aufbauen | Widersprüchliche Einträge; eine falsche Notiz führt alle in die Irre | Nur einer schreibt, versionierte Einträge mit Quellen |\n\nAm besten dokumentiert ist das Muster aus Orchestrator und Workern. Im Recherchesystem von Anthropic plant ein Lead-Agent die Recherche, startet Subagenten, die parallel suchen, und führt ihre Funde zusammen. Mit Claude Opus 4 als Lead und Claude Sonnet 4 als Subagenten übertraf es einen einzelnen Agenten mit Claude Opus 4 auf Anthropics interner Recherche-Evaluation um 90,2 Prozent. Die Analyse erklärt auch einen großen Teil des Gewinns: Auf einem Browsing-Benchmark erklärte allein der Token-Verbrauch 80 Prozent der Unterschiede in den Ergebnissen. Mehrere Agenten funktionieren also zum Teil deshalb, weil sie parallel mehr Tokens einsetzen können (Quelle: Anthropic, „How we built our multi-agent research system“, 2025).\n\nIn einer Debatte antworten mehrere Instanzen eines Modells, lesen die Antworten der anderen und überarbeiten ihre eigene über mehrere Runden. In Experimenten von Forschenden des MIT und von Google Brain verbesserte das die faktische Genauigkeit und das logische Schließen (Quelle: „Improving Factuality and Reasoning in Language Models through Multiagent Debate“, 2023, arxiv.org).\n\n## Wann mehrere Agenten helfen — und wann sie schaden\n\nZwei Fragen entscheiden: Wie viele Teile der Aufgabe können parallel laufen, und wie unabhängig sind diese Teile?\n\n![Vier-Felder-Matrix mit der Zahl paralleler Teilaufgaben auf der waagerechten und ihrer Unabhängigkeit auf der senkrechten Achse: Workflow oder Pipeline bei wenigen unabhängigen Teilaufgaben, Orchestrator und Worker bei vielen unabhängigen, ein Agent bei wenigen gekoppelten und viele Leser mit einem Schreiber bei vielen gekoppelten](/images/learn/de/multi-agent-systems-decide.webp \"Parallele, unabhängige Teilaufgaben sprechen für mehrere Agenten. Gekoppelte Arbeit spricht für einen Agenten — oder für viele Leser mit einem Schreiber.\")\n\nEng gekoppelte Arbeit ist die klassische Falle. Anthropic weist darauf hin, dass die meisten Programmieraufgaben weniger echt parallele Teile enthalten als Recherche. Cognition, der Hersteller des Coding-Agenten Devin, argumentiert, dass jede Aktion verdeckte Entscheidungen zu Stil, Namen oder Sonderfällen enthält. Parallele Agenten, die die Entscheidungen der anderen nicht sehen, liefern dann Teile, die nicht zusammenpassen (Quelle: Cognition, „Don't Build Multi-Agents“, 2025). 2026 berichtete dasselbe Unternehmen, dass Multi-Agenten-Aufbauten heute am besten funktionieren, wenn Schreibvorgänge in einem einzigen Strang bleiben („writes stay single-threaded“): Mehrere Agenten dürfen analysieren oder prüfen, aber nur einer ändert den Code (Quelle: Cognition, „Multi-Agents: What's Actually Working“, 2026).\n\nDie Forschung bestätigt, dass die Koordination selbst eine Fehlerquelle ist. Eine Studie zu verbreiteten Multi-Agenten-Frameworks ordnete 14 Fehlerarten drei Kategorien zu: schwache Systementwürfe und Aufgabenbeschreibungen, mangelnde Abstimmung zwischen den Agenten sowie unzureichende Prüfung und fehlerhaftes Beenden (Quelle: Cemri et al., „Why Do Multi-Agent LLM Systems Fail?“, 2025, arxiv.org). Daraus folgt die Regel: Beginnen Sie mit einem Agenten, messen Sie eine Basislinie mit Ihrem Eval-Satz, und fügen Sie Agenten nur hinzu, wenn der gemessene Gewinn die Mehrkosten rechtfertigt.\n\n## Fehler und Kosten schaukeln sich auf\n\nJeder Schritt und jede Übergabe kann scheitern. Gelingt jeder Schritt unabhängig in 95 Prozent der Fälle, gelingt eine Kette aus zehn Schritten nur noch in etwa 60 Prozent der Fälle:\n\n![Liniendiagramm: Die Chance, dass alle Schritte gelingen, sinkt mit der Zahl der Schritte; bei zehn Schritten liegt sie bei etwa 90 Prozent mit 99 Prozent Erfolg je Schritt, bei etwa 60 Prozent mit 95 Prozent und bei etwa 35 Prozent mit 90 Prozent](/images/learn/de/multi-agent-systems-compounding.webp \"Fehlerfortpflanzung in einer Kette unabhängiger Schritte. Eine Rechnung, keine Messung.\")\n\nEchte Fehler sind nicht völlig unabhängig, die Richtung stimmt aber: Lange Ketten brauchen Prüfungen zwischen den Schritten. Validieren Sie jede Übergabe gegen ein Schema, lassen Sie einen Schritt erst selbst wiederholen, bevor die ganze Aufgabe neu startet, und speichern Sie Zwischenergebnisse, damit ein Lauf fortgesetzt werden kann.\n\nAuch die Kosten schaukeln sich auf. Jeder Agent liest seinen eigenen Kontext, und viele lesen erneut, was andere geschrieben haben. In Anthropics Daten verbrauchten Agenten etwa viermal so viele Tokens wie Chat-Interaktionen, Multi-Agenten-Systeme etwa 15-mal so viele (Quelle: Anthropic, 2025, siehe oben). Legen Sie ein Token-Budget je Aufgabe und je Agent fest, und erwägen Sie leichtere Modelle für Worker mit einfachen Aufgaben.\n\nHalten Sie die Aufgabe jedes Workers klein. Der METR-Zeithorizont misst die Länge der Aufgaben, die ein Modell in etwa der Hälfte der Versuche löst — Aufgaben dieser Länge scheitern also noch in jedem zweiten Fall. Das sind die aktuellen Spitzenreiter in unseren Daten:\n\n{{\u003c llm-top bench=\"metr-time-horizon\" n=\"5\" \u003e}}\n\nGeben Sie Workern Aufgaben, die deutlich kürzer sind als dieser Horizont, und lassen Sie den Orchestrator viele kurze Erfolge zusammensetzen, statt auf einen langen zu hoffen.\n\n## Einen Multi-Agenten-Lauf nachverfolgen\n\nScheitert eine Multi-Agenten-Aufgabe, müssen Sie wissen, welcher Agent welchen Auftrag bekam, was er tat und was er zurückgab. Zeichnen Sie jede Aufgabe als einen **Trace** auf, mit einem **Span** für jeden Agenten und jeden Tool-Aufruf und einem Verweis auf den Eltern-Span:\n\n![Trace einer Beispielaufgabe mit Spans für den Plan des Lead-Agenten, drei parallele Worker, davon einer mit Timeout und neuem Versuch, das Zusammenführen, eine Freigabe durch Menschen und den Abschlussbericht, jeweils mit Token-Zahl](/images/learn/de/multi-agent-systems-trace.webp \"Eine Aufgabe, ein Trace: Der neue Versuch von Worker C und die Wartezeit für die Freigabe sind auf einen Blick sichtbar. Beispiel mit erfundenen Werten.\")\n\nDas Projekt OpenTelemetry hat semantische Konventionen für generative KI. Sie vereinheitlichen Attribute wie den Modellnamen und die Token-Zahlen, sodass Traces aus verschiedenen Frameworks in ein Werkzeug passen. Level 3 zeigt, wie Sie [Observability für LLM-Apps](/de/ai-development/learn/observability-for-llm-apps/) aufsetzen. Bei Multi-Agenten-Systemen beobachten Sie je Aufgabe vier Zahlen: Erfolgsquote, Kosten je erfolgreicher Aufgabe, Zahl der Übergaben und wiederholte Schleifen. Bewerten Sie das System dann als Ganzes und je Rolle; Level 2 zeigt, wie Sie [KI-Funktionen mit Evals testen](/de/ai-development/learn/test-ai-features-with-evals/).\n\n## Prüfpunkte für Menschen\n\nMehr Agenten bedeuten mehr Aktionen, die niemand in Echtzeit verfolgt. Setzen Sie Menschen dort ein, wo ein Fehler teuer wird:\n\n- **Vor dem Auffächern:** Den Plan freigeben, bevor der Orchestrator Dutzende Worker startet.\n- **Vor Aktionen nach außen:** Senden, Bezahlen, Löschen oder Ausrollen braucht immer eine Freigabe.\n- **Beim Ergebnis:** Bei folgenreichen Ergebnissen zeichnet ein Mensch die Antwort ab.\n- **Bei Uneinigkeit:** Finden Erzeuger und Prüfer nicht zusammen, eskalieren Sie, statt weiter zu kreisen.\n\nAgenten reichen sich auch Inhalte weiter. Ein Worker, der Webseiten liest, kann versteckte Anweisungen in den Kontext des Orchestrators tragen — eine Form von Prompt Injection. Behandeln Sie jedes Worker-Ergebnis als Daten, nie als Anweisung, und geben Sie Workern nur Leserechte. Unser Bereich [AI Security](/de/ai-security/) erklärt den Angriff.\n\n{{\u003c callout type=\"tip\" title=\"Viele lesen, einer schreibt\" \u003e}}\nWenn Sie unsicher sind, welches Muster passt, beginnen Sie hier: Lassen Sie mehrere Agenten parallel recherchieren, analysieren oder prüfen, aber nur einen Agenten — oder einen Menschen — Dateien, Datensätze oder Texte für Kunden ändern.\n{{\u003c /callout \u003e}}\n\n## Checkliste für den Entwurf\n\nBeantworten Sie diese Fragen, bevor Sie bauen:\n\n| Frage | Eine gute Antwort |\n|---|---|\n| Würde ein Agent mit besseren Tools genügen? | Sie haben eine Basislinie mit einem Agenten auf demselben Eval-Satz gemessen |\n| Sind die Teilaufgaben unabhängig? | Ja — oder nur ein Agent schreibt |\n| Hat jede Übergabe einen Vertrag? | Ziel, Eingaben, Ausgabeschema, Grenzen |\n| Wo liegen die Grenzen? | Höchstzahl an Agenten, Runden und Tokens je Aufgabe |\n| Wo prüfen Menschen? | Den Plan, Aktionen nach außen, das Endergebnis |\n| Sehen Sie alles? | Ein Trace je Aufgabe, ein Span je Agent |\n\nDie Orchestrierung müssen Sie nicht selbst programmieren. Nach Angaben der Anbieter baut MindStudio KI-Agenten ohne Code, Turbotic erstellt Automatisierungen aus einer Beschreibung in Alltagssprache, mit Devs.ai bauen und betreiben Teams Agenten auf eigenen Daten, und Dry Ground AI erledigt Routinearbeit über angebundene Tools:\n\n{{\u003c tools \"mindstudio turbotic devs-ai dry-ground-ai\" \u003e}}\n\nEgal mit welcher Plattform: Messen Sie weiter. Ein Multi-Agenten-System verdient seinen Platz nur, wenn es die Basislinie mit einem Agenten bei der Qualität je Kosteneinheit schlägt.","text":"Ein Agent mit guten Tools kann viel leisten. Manche Aufgaben sind aber zu breit für ein Kontextfenster, oder sie brauchen unterschiedliche Fähigkeiten und Rechte. Dann teilen Teams die Arbeit auf: Ein Agent plant, mehrere recherchieren parallel, ein weiterer prüft das Ergebnis. Gut gemacht, steigt die Qualität. Schlecht gemacht, vervielfachen sich Kosten, Fehler und Verwirrung.\nDies ist Teil 3 von Level 4 (Experte) im Lernpfad AI Development. Sie lernen vier bewährte Muster kennen, erfahren, wann mehrere Agenten helfen und wann sie schaden, wie sich Fehler und Kosten aufschaukeln, wie Sie einen Multi-Agenten-Lauf nachverfolgen und wo Menschen prüfen müssen. Der Teil baut auf KI-Agenten mit Tools, Schleifen und Gedächtnis aus Level 3 auf.\nWas ein System zum Multi-Agenten-System macht Ein Multi-Agenten-System besteht aus mehreren Agenten mit jeweils eigenen Anweisungen, eigenem Kontext, eigenen Tools und Rechten, die einander Arbeit übergeben. Entweder koordiniert Ihr Code sie über feste Wege, oder ein Agent entscheidet zur Laufzeit, wer was erledigt. Anthropic nennt die erste Form einen Workflow und die zweite einen Agenten im engeren Sinn (Quelle: Anthropic, „Building effective agents“, 2024). Viele Systeme, die als Multi-Agenten-System gelten, sind eigentlich Workflows — oft eine gute Nachricht, denn feste Wege lassen sich leichter testen.\nMehrere Agenten können echte Vorteile bringen:\nSaubere Kontexte. Jeder Agent sieht nur, was seine Teilaufgabe braucht, statt eines überquellenden Kontexts. Parallele Arbeit. Unabhängige Teilaufgaben laufen gleichzeitig, das verkürzt die Wartezeit. Spezialisierung. Jede Rolle bekommt eigenen Prompt, eigene Tools und bei Bedarf ein eigenes Modell. Geringste Rechte. Ein Recherche-Agent darf lesen, aber nichts verschicken; schreiben darf nur einer. Unabhängige Prüfung. Ein zweiter Agent mit eigenen Anweisungen prüft die Arbeit des ersten. Zwei offene Protokolle verbinden die Teile. Das Model Context Protocol (MCP), von Anthropic im November 2024 veröffentlicht, vereinheitlicht, wie Agenten auf Tools und Daten zugreifen. Das Protokoll Agent2Agent (A2A), von Google im April 2025 vorgestellt, beschreibt, wie Agenten verschiedener Systeme Aufgaben austauschen.\nVier bewährte Muster Die meisten echten Systeme bestehen aus wenigen Grundmustern:\nVier Grundmuster. Viele echte Systeme kombinieren zwei davon. Die Tabelle nennt die vier Muster und ergänzt die Debatte, eine Forschungsvariante des Prüfer-Musters:\nMulti-Agenten-Systeme: Muster und Fallstricke Muster Gut für Hauptrisiko Kontrolle Orchestrator und Worker Breite Recherche, parallele Teilaufgaben Doppelte Arbeit, vage Aufträge Ein genauer Auftrag je Worker: Ziel, Ausgabeformat, Grenzen, Tools Pipeline Feste Stufen wie auslesen, prüfen, schreiben Fehler wandern nach hinten weiter Schema-Validierung zwischen den Stufen Erzeuger und Prüfer Entwürfe mit klaren Qualitätskriterien Endlosschleifen, gleiche blinde Flecken Rundenlimit; Bewertungsraster oder anderes Modell für den Prüfer Debatte oder Abstimmung Schwierige Fragen mit überprüfbarer Antwort Kosten wachsen mit jedem Agenten; Einigung auf eine falsche Antwort Nur dort, wo Ihre Evals einen Gewinn zeigen Gemeinsamer Speicher Lange Aufgaben, die auf Funden aufbauen Widersprüchliche Einträge; eine falsche Notiz führt alle in die Irre Nur einer schreibt, versionierte Einträge mit Quellen Am besten dokumentiert ist das Muster aus Orchestrator und Workern. Im Recherchesystem von Anthropic plant ein Lead-Agent die Recherche, startet Subagenten, die parallel suchen, und führt ihre Funde zusammen. Mit Claude Opus 4 als Lead und Claude Sonnet 4 als Subagenten übertraf es einen einzelnen Agenten mit Claude Opus 4 auf Anthropics interner Recherche-Evaluation um 90,2 Prozent. Die Analyse erklärt auch einen großen Teil des Gewinns: Auf einem Browsing-Benchmark erklärte allein der Token-Verbrauch 80 Prozent der Unterschiede in den Ergebnissen. Mehrere Agenten funktionieren also zum Teil deshalb, weil sie parallel mehr Tokens einsetzen können (Quelle: Anthropic, „How we built our multi-agent research system“, 2025).\nIn einer Debatte antworten mehrere Instanzen eines Modells, lesen die Antworten der anderen und überarbeiten ihre eigene über mehrere Runden. In Experimenten von Forschenden des MIT und von Google Brain verbesserte das die faktische Genauigkeit und das logische Schließen (Quelle: „Improving Factuality and Reasoning in Language Models through Multiagent Debate“, 2023, arxiv.org).\nWann mehrere Agenten helfen — und wann sie schaden Zwei Fragen entscheiden: Wie viele Teile der Aufgabe können parallel laufen, und wie unabhängig sind diese Teile?\nParallele, unabhängige Teilaufgaben sprechen für mehrere Agenten. Gekoppelte Arbeit spricht für einen Agenten — oder für viele Leser mit einem Schreiber. Eng gekoppelte Arbeit ist die klassische Falle. Anthropic weist darauf hin, dass die meisten Programmieraufgaben weniger echt parallele Teile enthalten als Recherche. Cognition, der Hersteller des Coding-Agenten Devin, argumentiert, dass jede Aktion verdeckte Entscheidungen zu Stil, Namen oder Sonderfällen enthält. Parallele Agenten, die die Entscheidungen der anderen nicht sehen, liefern dann Teile, die nicht zusammenpassen (Quelle: Cognition, „Don\u0026rsquo;t Build Multi-Agents“, 2025). 2026 berichtete dasselbe Unternehmen, dass Multi-Agenten-Aufbauten heute am besten funktionieren, wenn Schreibvorgänge in einem einzigen Strang bleiben („writes stay single-threaded“): Mehrere Agenten dürfen analysieren oder prüfen, aber nur einer ändert den Code (Quelle: Cognition, „Multi-Agents: What\u0026rsquo;s Actually Working“, 2026).\nDie Forschung bestätigt, dass die Koordination selbst eine Fehlerquelle ist. Eine Studie zu verbreiteten Multi-Agenten-Frameworks ordnete 14 Fehlerarten drei Kategorien zu: schwache Systementwürfe und Aufgabenbeschreibungen, mangelnde Abstimmung zwischen den Agenten sowie unzureichende Prüfung und fehlerhaftes Beenden (Quelle: Cemri et al., „Why Do Multi-Agent LLM Systems Fail?“, 2025, arxiv.org). Daraus folgt die Regel: Beginnen Sie mit einem Agenten, messen Sie eine Basislinie mit Ihrem Eval-Satz, und fügen Sie Agenten nur hinzu, wenn der gemessene Gewinn die Mehrkosten rechtfertigt.\nFehler und Kosten schaukeln sich auf Jeder Schritt und jede Übergabe kann scheitern. Gelingt jeder Schritt unabhängig in 95 Prozent der Fälle, gelingt eine Kette aus zehn Schritten nur noch in etwa 60 Prozent der Fälle:\nFehlerfortpflanzung in einer Kette unabhängiger Schritte. Eine Rechnung, keine Messung. Echte Fehler sind nicht völlig unabhängig, die Richtung stimmt aber: Lange Ketten brauchen Prüfungen zwischen den Schritten. Validieren Sie jede Übergabe gegen ein Schema, lassen Sie einen Schritt erst selbst wiederholen, bevor die ganze Aufgabe neu startet, und speichern Sie Zwischenergebnisse, damit ein Lauf fortgesetzt werden kann.\nAuch die Kosten schaukeln sich auf. Jeder Agent liest seinen eigenen Kontext, und viele lesen erneut, was andere geschrieben haben. In Anthropics Daten verbrauchten Agenten etwa viermal so viele Tokens wie Chat-Interaktionen, Multi-Agenten-Systeme etwa 15-mal so viele (Quelle: Anthropic, 2025, siehe oben). Legen Sie ein Token-Budget je Aufgabe und je Agent fest, und erwägen Sie leichtere Modelle für Worker mit einfachen Aufgaben.\nHalten Sie die Aufgabe jedes Workers klein. Der METR-Zeithorizont misst die Länge der Aufgaben, die ein Modell in etwa der Hälfte der Versuche löst — Aufgaben dieser Länge scheitern also noch in jedem zweiten Fall. Das sind die aktuellen Spitzenreiter in unseren Daten:\nMETR Time Horizon: die 5 besten Modelle #ModellErschienenErgebnis 1Claude Mythos Preview (Early) Anthropic07.04.202617 Std. 25 min 2Claude Opus 4.6 (unknown thinking) Anthropic05.02.202611 Std. 59 min 3Gemini 3.1 Pro Preview Google DeepMind19.02.20266 Std. 24 min 4GPT-5.2 (high) OpenAI11.12.20255 Std. 52 min 5GPT-5.3 Codex OpenAI05.02.20265 Std. 50 min Die Länge der Aufgaben, die ein Modell in etwa der Hälfte der Fälle richtig löst — gemessen daran, wie lange ein menschlicher Experte dafür braucht. Die Zahl ist eine Dauer, kein Punktwert: Ein längerer Horizont heißt, das Modell kann länger selbstständig arbeiten. Daten: Epoch AI, abgerufen am 17.10.2026, Lizenz CC BY 4.0. Alle Modelle: LLM-Datenbank.\nGeben Sie Workern Aufgaben, die deutlich kürzer sind als dieser Horizont, und lassen Sie den Orchestrator viele kurze Erfolge zusammensetzen, statt auf einen langen zu hoffen.\nEinen Multi-Agenten-Lauf nachverfolgen Scheitert eine Multi-Agenten-Aufgabe, müssen Sie wissen, welcher Agent welchen Auftrag bekam, was er tat und was er zurückgab. Zeichnen Sie jede Aufgabe als einen Trace auf, mit einem Span für jeden Agenten und jeden Tool-Aufruf und einem Verweis auf den Eltern-Span:\nEine Aufgabe, ein Trace: Der neue Versuch von Worker C und die Wartezeit für die Freigabe sind auf einen Blick sichtbar. Beispiel mit erfundenen Werten. Das Projekt OpenTelemetry hat semantische Konventionen für generative KI. Sie vereinheitlichen Attribute wie den Modellnamen und die Token-Zahlen, sodass Traces aus verschiedenen Frameworks in ein Werkzeug passen. Level 3 zeigt, wie Sie Observability für LLM-Apps aufsetzen. Bei Multi-Agenten-Systemen beobachten Sie je Aufgabe vier Zahlen: Erfolgsquote, Kosten je erfolgreicher Aufgabe, Zahl der Übergaben und wiederholte Schleifen. Bewerten Sie das System dann als Ganzes und je Rolle; Level 2 zeigt, wie Sie KI-Funktionen mit Evals testen.\nPrüfpunkte für Menschen Mehr Agenten bedeuten mehr Aktionen, die niemand in Echtzeit verfolgt. Setzen Sie Menschen dort ein, wo ein Fehler teuer wird:\nVor dem Auffächern: Den Plan freigeben, bevor der Orchestrator Dutzende Worker startet. Vor Aktionen nach außen: Senden, Bezahlen, Löschen oder Ausrollen braucht immer eine Freigabe. Beim Ergebnis: Bei folgenreichen Ergebnissen zeichnet ein Mensch die Antwort ab. Bei Uneinigkeit: Finden Erzeuger und Prüfer nicht zusammen, eskalieren Sie, statt weiter zu kreisen. Agenten reichen sich auch Inhalte weiter. Ein Worker, der Webseiten liest, kann versteckte Anweisungen in den Kontext des Orchestrators tragen — eine Form von Prompt Injection. Behandeln Sie jedes Worker-Ergebnis als Daten, nie als Anweisung, und geben Sie Workern nur Leserechte. Unser Bereich AI Security erklärt den Angriff.\n✦Viele lesen, einer schreibt\nWenn Sie unsicher sind, welches Muster passt, beginnen Sie hier: Lassen Sie mehrere Agenten parallel recherchieren, analysieren oder prüfen, aber nur einen Agenten — oder einen Menschen — Dateien, Datensätze oder Texte für Kunden ändern.\nCheckliste für den Entwurf Beantworten Sie diese Fragen, bevor Sie bauen:\nMulti-Agenten-Systeme: Muster und Fallstricke (2) Frage Eine gute Antwort Würde ein Agent mit besseren Tools genügen? Sie haben eine Basislinie mit einem Agenten auf demselben Eval-Satz gemessen Sind die Teilaufgaben unabhängig? Ja — oder nur ein Agent schreibt Hat jede Übergabe einen Vertrag? Ziel, Eingaben, Ausgabeschema, Grenzen Wo liegen die Grenzen? Höchstzahl an Agenten, Runden und Tokens je Aufgabe Wo prüfen Menschen? Den Plan, Aktionen nach außen, das Endergebnis Sehen Sie alles? Ein Trace je Aufgabe, ein Span je Agent Die Orchestrierung müssen Sie nicht selbst programmieren. Nach Angaben der Anbieter baut MindStudio KI-Agenten ohne Code, Turbotic erstellt Automatisierungen aus einer Beschreibung in Alltagssprache, mit Devs.ai bauen und betreiben Teams Agenten auf eigenen Daten, und Dry Ground AI erledigt Routinearbeit über angebundene Tools:\nMindStudioAgenten \u0026amp; Automatisierung · KI ist der KernNo-Code-Plattform zum Bauen eigener KI-Agenten. TurboticAgenten \u0026amp; Automatisierung · KI ist der KernBaut Automatisierungen aus einer Beschreibung in natürlicher Sprache, ohne Code. Devs.aiApp-Bau \u0026amp; Tests · KI ist der KernPlattform, auf der Teams KI-Anwendungen und eigene Agenten mit ihren Daten bauen und betreiben. Dry Ground AIApp-Bau \u0026amp; Tests · KI ist der KernKI-Operator (CompanyClaw), der Abläufe eines Unternehmens lernt und Routinearbeit über angebundene Tools erledigt. Kurzbeschreibungen aus unserem Tool-Vergleich, nach Angaben der Anbieter — nicht von ABXK getestet.\nEgal mit welcher Plattform: Messen Sie weiter. Ein Multi-Agenten-System verdient seinen Platz nur, wenn es die Basislinie mit einem Agenten bei der Qualität je Kosteneinheit schlägt.\n","words":1709},"date":"2026-10-14","description":"Wann mehrere KI-Agenten mehr leisten als einer: Orchestrator, Pipeline, Prüfer, gemeinsamer Speicher, Fehlerfortpflanzung, Kosten, Traces und Freigaben.","image":"https://abxk.ai/images/cover/multi-agent-systems.webp","json":"https://abxk.ai/de/ai-development/learn/multi-agent-systems/index.json","kind":"page","language":"de","learning_path":{"category":"ai-development","level":4,"level_name":"Experte"},"modified":"2026-10-14","related_tools":["MindStudio","Turbotic","Devs.ai","Dry Ground AI"],"section":"ai-development","tags":["multi-agenten-systeme","ki-agenten","orchestrierung","observability","experte"],"title":"Multi-Agenten-Systeme: Muster und Fallstricke","translations":[{"json":"https://abxk.ai/en/ai-development/learn/multi-agent-systems/index.json","language":"en","url":"https://abxk.ai/en/ai-development/learn/multi-agent-systems/"}],"url":"https://abxk.ai/de/ai-development/learn/multi-agent-systems/"}