Sich bei komplexen, domänenübergreifenden Workflows auf eine einzelne AI-Sitzung zu verlassen, ist grundsätzlich langsam. Claude agent teams lösen das, indem sie spezialisierte agents parallel ausführen und so deutlich schneller tiefere Ergebnisse liefern. Dieser Leitfaden erklärt, wie Claude Code agent teams funktionieren, wie man sie einrichtet und mit welchen Best Practices man ihren Nutzen maximiert.
Was sind Claude agent teams?
Claude Code agent teams sind ein Koordinationssystem mit mehreren Instanzen, in dem mehrere Claude-Sitzungen parallel an derselben Codebasis arbeiten. Eine Sitzung wird als lead agent festgelegt, erhält die Gesamtaufgabe, zerlegt sie in Teilaufgaben und synthetisiert das Endergebnis. Die anderen sub-agents sind teammates; sie laufen jeweils in ihrem eigenen isolierten Kontextfenster, übernehmen ein klar abgegrenztes Arbeitspaket und kommunizieren direkt mit anderen teammates.
Vorteile von agent teams
Agent teams unterscheiden sich von typischen AI-Assistenten, die Aufgaben sequenziell und einzeln abarbeiten. Agent teams durchbrechen diese Beschränkung: Wenn Arbeit tatsächlich parallelisiert werden kann, sinkt die Durchlaufzeit entsprechend.
Gleichzeitig sind agent teams mehr als mehrere Sitzungen: Die Koordinationsschicht bietet drei Fähigkeiten, die manueller Multi-Session-Arbeit fehlen:
Peer-to-Peer-Messaging: Teammates können einander direkt Nachrichten senden, ohne den Weg über dich oder den lead zu nehmen. Zum Beispiel kann in einem agent team ein Security Reviewer mitten im Lauf einen Befund an den Performance Reviewer melden, ohne das gesamte Team aufzuhalten.
Dateisperren: Wenn ein teammate in eine Datei schreibt, setzt er eine Sperre, die parallele Schreibvorgänge anderer agents verhindert. So wird die Klasse von Merge-Konflikten durch stille Überschreibungen blockiert.
Abhängigkeitsverfolgung: Der lead kodiert Aufgabenabhängigkeiten während der Zerlegung. Die Koordinationsschicht setzt sie durch, sodass kein agent startet, bevor seine Voraussetzungen erfüllt sind – ganz ohne manuelles Polling.
Wie agent teams tatsächlich funktionieren
Ein agent team besteht aus den folgenden Komponenten, jeweils mit einer bestimmten Rolle:
Der team lead ist die Hauptsitzung von Claude Code. Er erstellt das Team, spawnt teammates, koordiniert ihre Arbeit und synthetisiert das Endergebnis. Mit dieser Sitzung interagierst du direkt.
Teammates sind separate Claude Code-Instanzen, die jeweils unabhängig in ihrem eigenen Kontextfenster an den ihnen zugewiesenen Aufgaben arbeiten. Sie teilen keinen Kontext mit dem lead oder miteinander; ihre Kommunikation erfolgt explizit über die Aufgabenliste und die Mailbox.
Die gemeinsame Aufgabenliste und die Mailbox ermöglichen Koordination**.** Die gemeinsame Aufgabenliste ist eine Live-Warteschlange, aus der die agent-Gruppe liest und in die sie schreibt. Der lead befüllt sie bei der Zerlegung, und teammates übernehmen Aufgaben, arbeiten sie ab und markieren sie als erledigt. Abhängigkeiten werden automatisch durchgesetzt; wenn ein teammate eine Aufgabe abschließt, werden alle dadurch blockierten Aufgaben ohne manuelles Eingreifen freigegeben. Die Mailbox ist das Nachrichtensystem für direkte agent-zu-agent-Kommunikation. Nachrichten fließen automatisch zwischen teammates und lead.
Sowohl die Teamkonfiguration als auch die Aufgabenliste werden lokal gespeichert (~/.claude/teams/ und ~/.claude/tasks/). Claude Code erzeugt und pflegt diese Dateien automatisch. Bearbeite sie nicht von Hand, da Änderungen beim nächsten Statusupdate überschrieben werden.
Claude Code agent teams einrichten
Claude agent teams sind in Claude Code standardmäßig deaktiviert. Sie sind als experimentell gekennzeichnet und müssen ausdrücklich aktiviert werden. Hier ist der vollständige Einrichtungsweg. Bevor du agent teams aktivierst, solltest du prüfen, ob deine Claude Code-Version v2.1.32 oder neuer ist**.** Das kannst du im Terminal mit claude --version überprüfen.
Schritt 1: Feature-Flag aktivieren
Setze die Umgebungsvariable CLAUDE_CODE_EXPERIMENTAL_AGENT_TEAMS auf 1. Dafür gibt es drei Möglichkeiten:
Option A: ~/.claude/settings.json (empfohlen)
Option B: Shell-Profil (~/.bashrc oder ~/.zshrc)
Option C: Inline, für eine einzelne Sitzung
Wenn du settings.json oder dein Shell-Profil bearbeitet hast, starte Claude Code neu, damit das Flag wirksam wird.
Schritt 2: tmux installieren (empfohlen, nicht erforderlich)
Agent teams werden in zwei Modi angezeigt: In-process (alle teammates laufen im Hauptterminal) und geteilte Panes (jeder teammate hat ein eigenes Pane; dafür ist tmux oder iTerm2 erforderlich). Wenn jeder teammate in einem eigenen Terminal-Pane läuft, lässt sich das Team in Echtzeit deutlich leichter überwachen.
Um sicher im Modus mit geteilten Panes zu bleiben, setze teammateMode in ~/.claude/settings.json:
Um die Standardeinstellung "auto" zu überschreiben, setze teammateMode in ~/.claude/settings.json auf in-process. Um den In-process-Modus für eine einzelne Sitzung zu erzwingen, übergib ihn als Flag: claude --teammate-mode in-process.
Schritt 3: Prompt zum Start deines agent teams
Nachdem du das agent team aktiviert hast, sag Claude einfach in natürlicher Sprache, welche Aufgaben, welches Ergebnis und welche Teamstruktur das agent team haben soll. Du kannst jede Rolle im Prompt festlegen; Claude erstellt dann das Team, spawnt teammates und plant die Aufgaben entsprechend.
Beispiel-Prompt:
Du kannst festlegen, welches Modell deine agent teams verwenden, etwa "Use Sonnet for every teammate". Teammates übernehmen das Modell des lead agent nicht automatisch. Nutzer müssen das Modell im Frontmatter der Rollendatei angeben oder über /config ein Standardmodell für teammates setzen.
Schritt 4: Bei komplexen Aufgaben Planfreigabe anfordern (optional)
Bei Aufgaben mit hohem Risiko und hoher Komplexität kannst du verlangen, dass das Team vor der Ausführung einen Plan erstellt. Die teammates in der agent-Gruppe arbeiten im Read-only-Modus; der lead prüft, überarbeitet und genehmigt den Plan schließlich. Erst wenn der Plan vom lead freigegeben ist, beginnen die teammates mit der Umsetzung.
Beachte, dass der lead agent Entscheidungen trifft; du kannst daher auch Kriterien für die Entscheidungsfindung vorgeben.
Beispiel-Prompt:
Schritt 5: git worktrees für Dateiisolation einrichten (optional, empfohlen)
Wenn ein teammate Dateien schreibt, werden Claude Code worktrees dringend empfohlen. Ein git worktree ist ein separates Arbeitsverzeichnis auf einem eigenen Branch, das dieselbe .git-Historie wie dein Haupt-Checkout teilt. Jeder agent erhält isolierten Dateizugriff, und Änderungen aus einem worktree berühren nie die laufende Arbeit eines anderen agents.
Um dies pro agent zu aktivieren, füge einfach isolation: worktree zum YAML-Frontmatter des agents hinzu. Claude Code stellt für jeden parallelen agent-Aufruf einen frischen worktree bereit und räumt ihn automatisch auf, wenn der agent fertig ist.
Für die CLI-Nutzung: claude --worktree oder claude -w startet eine Sitzung in einem eigenen worktree. Die Desktop-App erstellt automatisch pro Sitzung einen Claude Code worktree.
Schritt 6: Regelmäßig überwachen
Agent teams sind kein Selbstläufer, und lang laufende Teams können vom Kurs abkommen. Agents können bei Berechtigungs-Prompts hängen bleiben, Aufgaben zu früh als erledigt markieren oder den Umfang aus den Augen verlieren. Du kannst alle 10–15 Minuten nachsehen und die gemeinsame Aufgabenliste auf blockierte oder nicht übernommene Aufgaben prüfen. Wenn sich eine Aufgabe 20–30 Minuten lang nicht bewegt hat, kann das an einer Berechtigungsblockade oder an einer falsch spezifizierten Rolle liegen, die manuelles Eingreifen erfordert.
Direktvergleich: subagents vs. agent teams
Subagents sind ein Delegationsmuster. Agent teams sind ein Kollaborationsmuster. Dieser Unterschied prägt alles – vom Umgang mit Kontext bis zu den Kosten eines Laufs.
| Subagents | Agent teams | |
|---|---|---|
| Kommunikation | Einweg: lead delegiert, subagents melden zurück | Peer-to-Peer + Koordination durch lead |
| Gemeinsamer Zustand | Keiner | Gemeinsame Aufgabenliste mit Abhängigkeitsverfolgung |
| Kontextfenster | Eigenes Kontextfenster; Ergebnisse gehen an den lead zurück | Jeder teammate hat ein eigenes (bis zu 1 Mio. tokens) |
| Vermeidung von Dateikonflikten | Nicht integriert | File locking enthalten |
| token-Kosten | Niedriger | Höher (jeder teammate ist eine einzelne Instanz) |
| Sitzungsfortsetzung | Unterstützt | /resume and /rewind don't restore in-process teammates |
| Verschachtelte agents | Unterstützt | Nicht unterstützt; nur der lead kann teammates spawnen |
| Am besten geeignet für | Gezielte Delegation, wiederholbare Workflows | Parallelisierbare, voneinander abhängige, domänenübergreifende Arbeit |
Subagents sind ein Einweg-Delegationsmuster: Der lead sendet eine Aufgabe, der subagent führt sie in seinem eigenen Kontextfenster aus, und das Ergebnis wird zurückgegeben. Es gibt keinen gemeinsamen Zustand, keine direkte Kommunikation zwischen sibling agents und keine Koordinationsschicht – nur eine klare Dispatch-and-Return-Schleife.
Agent teams arbeiten mit einer gemeinsamen Aufgabenliste samt automatischer Durchsetzung von Abhängigkeiten und kommunizieren über die Mailbox Peer-to-Peer zwischen teammates.
Kurz gesagt: agent teams lohnen sich, wenn die Arbeit in wirklich unabhängige parallele Stränge aufgeteilt ist, die Erkenntnisse austauschen und sich miteinander abstimmen müssen. Für schnelle Ergebnisse, sequenzielle Aufgaben, Änderungen an einzelnen Dateien oder alles, bei dem Kostenplanbarkeit wichtiger ist als Geschwindigkeit, sind subagents die bessere Wahl.
Wann du agent teams wählst – und wann subagents
Verwende agent teams, wenn:
Teammates direkt miteinander kommunizieren müssen
Die Arbeit eine gemeinsame Aufgabenliste mit Abhängigkeitsverfolgung über parallele Arbeitsstränge hinweg erfordert
Die Aufgabe für eine einzelne Sitzung zu groß ist und jeder worker einen vollständig unabhängigen eigenen Kontext braucht
Verwende subagents, wenn:
Du nur die abschließende Zusammenfassung brauchst, nicht die vollständigen Zwischenergebnisse
Die Arbeit in sich abgeschlossen genug ist, um ein sauberes Ergebnis zu liefern
Du Tools einschränken oder auf ein günstigeres Modell routen möchtest
Du parallele Recherchepfade brauchst, die nicht voneinander abhängen
Wenn du nicht mindestens drei wirklich unabhängige parallele Arbeitsstränge benennen kannst, wird eine einzelne Sitzung oder subagents ein agent team wahrscheinlich bei geringeren Kosten übertreffen.
Praxisnahe Anwendungsfälle für agent teams
Wenn sich die Arbeit auf natürliche Weise in klar umrissene, begrenzte Arbeitsstränge aufteilen lässt, diese Stränge nicht aufeinander warten müssen (oder ihre Abhängigkeiten explizit kodiert werden können) und der Koordinationsaufwand im Verhältnis zur Zeitersparnis durch Parallelisierung gering ist. Hier sind fünf Anwendungsfälle, in denen agent teams eine einzelne Sitzung übertreffen.
Paralleles Code-Review
Weise einem Pull Request gleichzeitig drei Reviewer zu, darunter einen security agent, einen performance agent und einen test coverage agent. Der lead verdichtet drei parallele Berichte zu einer priorisierten Maßnahmenliste. Dieses Muster funktioniert auch für Architektur-Reviews (scalability agent, security agent, maintainability agent) oder Compliance-Prüfungen über verschiedene regulatorische Rahmenwerke hinweg.
Debugging konkurrierender Hypothesen
Spawne fünf agents, jeweils mit einer einzelnen Hypothese, um bestimmte Dateien oder Logs zu testen und einen Produktionsfehler zu untersuchen. Der erste agent, der seine Hypothese bestätigt, bringt den Fix hervor; die anderen können gestoppt werden. Das ist effizienter, als jede Theorie nacheinander zu prüfen, stundenlang einen Debugging-Pfad zu verfolgen, zurückzugehen und mit dem nächsten zu beginnen.
Schichtenübergreifende Refactorings
Eine schichtenübergreifende Refactoring-Aufgabe enthält sowohl sequenzielle als auch parallele Schritte. Eine breaking API-Änderung erfordert beispielsweise Updates an Backend-Endpunkten, an Frontend-Komponenten, die diese Endpunkte nutzen, und an der Testsuite, die beides abdeckt. Die Backend-Arbeit muss abgeschlossen sein, bevor das Frontend beginnen kann. Sobald die Backend-Aufgabe läuft, kann der Testsuite-agent parallel die neue Teststruktur vorbereiten. In einem agent team nutzt der lead die Abhängigkeitsverfolgung der gemeinsamen Aufgabenliste, um diese Reihenfolge festzulegen.
Recherche-Durchlauf ohne Kontextkontamination
Eine technische Entscheidung kann die Prüfung mehrerer unabhängiger Evidenzbereiche erfordern, etwa die Auswahl einer Datenbank-Engine, die Bewertung von drei Drittanbieter-APIs und die Einschätzung von Build-Tooling. Weise jedem agent einen überschneidungsfreien Bereich zu; jeder veröffentlicht eine strukturierte Zusammenfassung. Der lead bündelt alles in einem Vergleichsdokument. Die Isolation bewahrt unabhängige Perspektiven und verbessert so die Qualität der Ergebnisse.
Migration großer Codebases
Das Upgrade einer wichtigen Abhängigkeit in einer großen Codebase betrifft typischerweise mehrere Module. Wenn diese Module klare Grenzen haben und gleichzeitig migriert werden können, helfen agent teams. Weise jedem unabhängigen Modul einen agent zu; jeder agent migriert sein Modul, führt seine eigene Testsuite aus und meldet sich mit einer Migrationszusammenfassung zurück, einschließlich aller geänderten Schnittstellen. Der lead prüft Schnittstellenänderungen, bevor er die Migration als abgeschlossen erklärt, und koordiniert die Merge-Reihenfolge.
Dos and Don’ts für das Design deines agent teams
Ein paralleles agent-System mit Claude Code lässt sich schnell einrichten, aber ebenso leicht falsch gestalten. Diese Gestaltungsprinzipien entscheiden darüber, ob dein agent team Leistung bringt oder Zeit verschwendet.
Profi-Tipps für den Aufbau deines parallelen agent-Systems
Berechtigungen vorab freigeben: Teammates starten mit den Berechtigungseinstellungen des lead. Läuft der lead mit --dangerously-skip-permissions, übernehmen das alle teammates ebenfalls. Einzelne teammate-Modi kannst du nach dem Spawnen anpassen; beim Spawnen selbst lassen sich Modi pro teammate jedoch nicht konfigurieren. Lege deine Berechtigungsstrategie über den lead fest, bevor du das Team startest.
Präzise Rollen-Prompts schreiben: Jeder Rollen-Prompt sollte vier Dinge festlegen: was zu tun ist, in welchen Dateien oder Domänen gearbeitet wird, worauf der Fokus liegt und was ausgeschlossen ist, und wie das Deliverable aussehen soll. Beim Spawnen von teammates kannst du auf subagent-Typen aus jedem subagent-Scope verweisen: Projekt, Benutzer, Plugin oder CLI-definiert. So definierst du eine Rolle – etwa security reviewer oder test runner – nur einmal und verwendest sie sowohl als delegierten subagent als auch als teammate in einem agent team.
Datei-Isolation erzwingen: Für jeden agent, der auf die Festplatte schreibt, solltest du Isolation verwenden. Zwei agents, die gleichzeitig dieselbe Datei ändern, sind einer der zuverlässigsten Wege zu beschädigter Ausgabe.
Regelmäßig nachsehen: Bei aktiven agent teams alle 10–15 Minuten. Prüfe in der gemeinsamen Aufgabenliste, welche Aufgaben nicht vorankommen. Hängt eine Aufgabe länger als 20–30 Minuten, kann ein Berechtigungsproblem, eine ungenau definierte Rolle oder eine zyklische Abhängigkeit dahinterstecken; das erfordert möglicherweise manuelles Eingreifen.
Abhängigkeiten explizit kodieren: Wenn Task B logisch auf Task A folgt, schreibe diese Abhängigkeit schon bei der Zerlegung in die Aufgabenliste – nicht als Anweisung in einen Rollen-Prompt. Die Koordinationsschicht setzt Abhängigkeiten automatisch durch; Anweisungen in Prompts können missverstanden oder ignoriert werden.
Ownership-Grenzen in deiner md-Datei definieren: Lege für Multi-Session-Projekte eine Regel fest, dass jedes Modul oder Verzeichnis genau einen verantwortlichen agent hat. So vermeidest du Überschneidungen, noch bevor das Team startet.
Immer über den lead aufräumen, nicht über einen teammate: Der lead prüft vor dem Freigeben von Ressourcen, ob noch aktive teammates vorhanden sind. Teammates haben nicht den vollständigen Teamkontext, um sicher aufzuräumen; dadurch kann die Sitzung in einen inkonsistenten Zustand geraten.
Häufige Fehler, die du bei deinem agent team vermeiden kannst
Starte kein Team für eine Aufgabe, die eine einzelne Sitzung sauber erledigt: Zeichne den Aufgabengraphen, bevor du auch nur eine Rollen-Datei schreibst oder einen swarm-Prompt sendest. Welche Teilaufgaben sind wirklich unabhängig? Welche haben Abhängigkeiten? Handelt es sich um sequenziell abhängige Arbeit? Wenn du keine drei parallelen Stränge mit klaren Grenzen benennen kannst, ist eine einzelne Sitzung dem Team überlegen.
Weise nicht zwei agents derselben Datei zu. Das ist die häufigste Ursache für Merge-Konflikte und stille Überschreibungen. Wenn deine Aufgabenzerlegung zwei agents hervorbringt, die dieselbe Komponente anfassen müssen, sollte die Arbeit an dieser Komponente sequenziell laufen – weise sie einem agent zu, nachdem der andere fertig ist.
Überspringe in Claude Code nicht die Vorabfreigabe von Berechtigungen. Berechtigungsabfragen mitten im Lauf blockieren die parallele Ausführung und erfordern manuelles Eingreifen. Der Zusatzaufwand frisst einen großen Teil des Nutzens auf. Gib Dateischreibzugriffe und Shell-Befehle für das Arbeitsverzeichnis vor dem Start frei.
Erwarte nicht, dein Claude Code-Team wiederherstellen zu können. Wenn eine Sitzung bereinigt wurde, stellen /resume und /rewind laufende in-process teammates nicht wieder her. Speichere wichtige Zwischenergebnisse vor langen Läufen.
Betreibe kein Team mit mehr als fünf Mitgliedern ohne klaren Grund. token-Kosten skalieren linear, der Koordinationsaufwand wächst jedoch schneller. Drei fokussierte agents mit klaren Rollen übertreffen fünf agents mit vagen Rollen zuverlässig. Füge teammates nur hinzu, wenn ein expliziter paralleler Arbeitsstrang wartet – nicht, weil mehr nach mehr klingt.
Ein weiteres Paradigma: Baue dein Multi-agent-Team in Kimi Agent Swarm auf
Claude Code agent teams glänzen in entwicklungsnahen Szenarien und fügen sich tief in Terminal-Workflows und das Git-Ökosystem ein. Das Paradigma der Multi-agent-Zusammenarbeit reicht jedoch weit über die Kommandozeile hinaus. Kimi Agent Swarm macht dieses Paradigma für alle zugänglich.
Kimi Agent Swarm ist Kimi's Multi-agent-Kollaborationssystem für komplexe Aufgaben im großen Maßstab. Es zerlegt ein übergeordnetes Ziel in einzelne Teilaufgaben und plant verschiedene agents und Fähigkeiten so ein, dass Suche, Lesen, Analyse, Schreiben, Coding, Tabellenerstellung, Folienerstellung und Webseitenerstellung gleichzeitig laufen. Keine env-Flags. Keine git-Konfiguration erforderlich.
Wichtigste Funktionen von Kimi Agent Swarm
Parallele Zusammenarbeit mit bis zu 300 sub-agents: Kimi Agent Swarm zerlegt eine komplexe Aufgabe und plant mehrere sub-agents ein, die Teilaufgaben gleichzeitig bearbeiten. Das System kann bis zu 300 sub-agents koordinieren, um in einem einzigen Lauf mehr als 4.000 Tool-Aufrufe auszuführen.
Zusammengesetzte Multi-Skill-Ausführung: Der Swarm kann mehrere spezialisierte Fähigkeiten in einem einzigen Lauf kombinieren, darunter Tiefgehende Recherche, pptx, Berichtserstellung, Vibe-Coding, Website-Erstellung und Paper Writing, und übertrifft einen einzelnen agent bei Ausgabetiefe und Formatabdeckung.
Dokumentverarbeitung im großen Maßstab: Agent Swarm kann Dateien in über 20 Formaten (PDF, Word, Excel, PPT, Bilder usw.) im Batch verarbeiten, Inhalte über den gesamten Dokumentensatz hinweg parallel lesen, Informationen extrahieren und zusammenfassen sowie Bibliotheken, Competitive-Intelligence-Dateien oder Multi-Source-Dateningestion referenzieren.
Proaktive breite Recherche: Für Aufgaben, die Informationen über große Themenflächen hinweg erfordern, entsendet Agent Swarm sub-agents, die parallel im Web suchen, Quellen finden, Inhalte herunterladen, Erkenntnisse kategorisieren und strukturierte Zusammenfassungen erzeugen.
Reasoning aus mehreren Perspektiven: Agent Swarm kann mehrere Expertenperspektiven gleichzeitig auf dasselbe Problem anwenden. Das führt zu einer vollständigeren Analyse als ein Durchlauf aus nur einer Perspektive und macht blinde Flecken sichtbar, die bei sequenzieller Prüfung leicht übersehen werden.
Tiefgehende Content-Lieferung: Die parallele Architektur von Agent Swarm ist auf Ergebnisse mit dauerhaft hoher Tiefe ausgelegt, etwa mehrhundertseitige Forschungsberichte, ausführliche Branchenanalysen, wissenschaftliche Literaturübersichten, strukturierte Lernleitfäden und umfangreiche narrative Inhalte.
Multi-Format-Ausgabe in einem einzigen Lauf: Agent Swarm kann für dieselbe Aufgabe mehrere Deliverable-Typen gleichzeitig erzeugen, etwa einen PDF-Bericht, ein PPT-Deck, eine Webseite, einen Excel-Datensatz und ein Codeprojekt.
So führst du ein agent team in Kimi Agent Swarm aus
Schritt 1: Öffne Kimi Agent Swarm und gib deinen Prompt ein
Öffne die Agent Swarm-Seite und beschreibe deine Aufgabe im Eingabefeld. Die besten Ergebnisse erzielst du, wenn du Umfang, erwartete Deliverables und Einschränkungen wie Zeitraum, Quellen oder Formatvorgaben konkret angibst.
Beispiel-Prompt:
Schritt 2: Lass Kimi Agent Swarm arbeiten
Nachdem du deinen Prompt gesendet hast, zerlegt Agent Swarm die Aufgabe in Teilaufgaben und entsendet subagents, die parallel arbeiten. Du kannst den Fortschritt in Echtzeit verfolgen, einschließlich Aufgabenplanung, Spawnen von sub-agents und paralleler Ausführung.
Schritt 3: Ergebnisse erhalten, ansehen und herunterladen oder teilen
Nach Abschluss des Laufs kannst du deine Deliverables direkt in der Oberfläche als Vorschau ansehen. Je nach Aufgabe können die Ergebnisse Forschungsberichte, Datenanalysen, PPT-Decks, Webseiten, Codeprojekte oder eine Kombination daraus umfassen. Du kannst die Dateien herunterladen und direkt teilen.
Anwendungsfälle, in denen Kimi Agent Swarm glänzt
Ausschreibungs- und Angebotserstellung: Weise parallele agents gleichzeitig technischen Spezifikationen, Compliance-Anforderungen, Preismodellen und Fallstudien zu; der Orchestrator integriert sie zu einem stimmigen Angebot.
Finanzanalyse: Weise parallele agents Marktdaten, Wettbewerber-Filings, Makroindikatoren und interne Modelle zu; der Orchestrator verdichtet sie zu einer einheitlichen Analyse.
Business-Recherche: Weise parallele agents Wettbewerbslandschaften, Kundeninterviews, Branchenberichten und regulatorischem Kontext aus unterschiedlichen Quellen zu; der Orchestrator erzeugt eine strukturierte Ausgabe.
Security Testing: Starte parallele agents für Reconnaissance, Vulnerability Scanning, Dependency Auditing und Prüfungen zur Rechteausweitung; der Orchestrator bündelt die Erkenntnisse in einem Abschlussbericht.
Full-Stack-Entwicklung: Erstelle parallele agents für Frontend-Komponenten, Backend-Endpunkte, Datenbankschema und Testsuites; der Orchestrator koordiniert die Integration über den gesamten Stack hinweg.
Fazit
Claude Code agent teams sind speziell für Engineering-Workflows entwickelt und bringen parallele Ausführung direkt aus dem Terminal in komplexe Codebases. Wenn deine Arbeit über Code hinausgeht, überträgt Kimi Agent Swarm dasselbe Multi-agent-Paradigma auf Recherche, Analyse, Inhalte und mehr. Beschreibe einfach deine Aufgabe und lass den swarm den Rest erledigen.