Wie man KI-Agenten-Schwärme aufbaut (Vollständiger Leitfaden)

Das ist eine komplette A–Z-Aufschlüsselung von KI-Agenten-Schwärmen – was sie sind und wie man sie nutzt.

Warum sie alles daran ändern, wie du mit KI arbeitest.

Speichere dir das ab, bevor du es vergisst.

Kimi K2.6, Moonshot AIs Open-Weight-Flaggschiff vom April 2026, ist die ernsthafteste Open-Source-Implementierung dieser Idee, die ich gesehen habe.

Reale Aufgaben haben Breite. Fünfzig zu recherchierende Unternehmen.

Zweihundert zu analysierende Dateien. Ein Dutzend Teilaufgaben, die nicht voneinander abhängen und nicht hintereinander warten sollten. Ein Agentenschwarm ist die Architektur dafür.

Dieser Leitfaden erklärt, wie es funktioniert, von der Trainingsinfrastruktur bis zur API, und behandelt dann das Muster, das ich derzeit für am wichtigsten halte: Kimi für die Ausführung, Claude Opus 4.8 für die Planung und Verifizierung.

So sieht der endgültige Workflow aus.

Abschnitt 1: Was ist ein Agentenschwarm?

Ein Agentenschwarm ist eine Gruppe mehrerer Agenten, die gleichzeitig an zerlegten Teilaufgaben arbeiten, koordiniert von einem Orchestrator, der die Ergebnisse zusammenführt.

Der Unterschied zu einer sequenziellen Kette ist der entscheidende Punkt:

• Sequentielle Kette: Agent A läuft, übergibt an B, B übergibt an C. Gesamtzeit = A + B + C.
• Schwarm: Der Orchestrator zerlegt das Ziel, die Agenten A, B, C arbeiten gleichzeitig an unabhängigen Teilaufgaben, die Ergebnisse werden zusammengeführt. Gesamtzeit ≈ max(A, B, C).

Wenn eine Aufgabe eine echte parallele Struktur hat, ist das der Unterschied zwischen Minuten und Stunden.

Ein Schwarm löst auch das Problem des Kontextüberlaufs. Ein einzelner Agent bei einer langen Aufgabe sammelt so viele Tokens an, bis sein Fenster überschwemmt wird. Ein Schwarm gibt jeder Teilaufgabe ihren eigenen begrenzten Kontext, und nur strukturierte Ausgaben fließen zurück zum Orchestrator.

Die sechs Bausteine

Jeder Schwarm hat dieselben Kernkomponenten:

Komponente

Was sie tut

Orchestrator

Zerlegt die Aufgabe, weist Teilaufgaben zu, überwacht die Ausführung, fasst Ergebnisse zusammen

Unter-Agenten

Spezialisierte Arbeiter, die auf einen Bereich beschränkt sind (Recherche, Code, Analyse, Schreiben)

Werkzeuge

Funktionen, die Agenten aufrufen können: Websuche, Code-Interpreter, Datei-I/O, APIs

Gedächtnis

Gemeinsamer Zustand, den der Schwarm lesen/schreiben kann

Übergaben / Routing

Mechanismus zur Steuerungs- oder Datenübergabe zwischen Agenten

Absicherungen

Iterationsgrenzen, Timeouts, Human-in-the-Loop-Auslöser, Fehlerbehebung

Wenn du diese sechs richtig hinbekommst, hast du einen Schwarm. Wenn du auch nur eine davon falsch machst, hast du eine teure Debugging-Sitzung.

Abschnitt 2: Was Kimi K2.6 tatsächlich ist

Bevor wir uns mit dem Schwarmverhalten befassen, lohnt es sich zu verstehen, was darunter liegt. K2.6 ist ein 1-Billionen-Parameter-Mixture-of-Experts-Modell von Moonshot AI, das am 20. April 2026 unter einer modifizierten MIT-Lizenz als Open Weight veröffentlicht wurde. Die kommerzielle Nutzung ist kostenlos bei einem monatlichen Umsatz unter 20 Millionen US-Dollar oder unter 100 Millionen monatlich aktiven Nutzern – für die meisten Entwickler ist es also praktisch kostenlos.

0:29

Architekturspezifikationen

Spezifikation

Wert

Gesamtparameter

~1,04 Billionen

Aktiviert pro Token

~32 Milliarden (8 ausgewählte Experten + 1 gemeinsamer)

Gesamtzahl der Experten

384, verteilt über 61 Transformer-Ebenen

Kontextfenster

262.144 Tokens (262K)

Aufmerksamkeit

Multi-Head Latent Attention (MLA) – geringerer KV-Cache-Fußabdruck

Aktivierungsfunktion

SwiGLU

Vision-Encoder

MoonViT-3D (400M Parameter, Bild + Video bis zu 2K)

Quantisierung

INT4 via Quantization-Aware Training (~594 GB auf der Festplatte)

FP16 vollständige Gewichtsgröße

~2 TB

Lizenz

Modifizierte MIT

Die INT4-QAT-Variante läuft nativ auf 4x H100 80 GB. FP16 benötigt 8x H100 80 GB. Alle drei unterstützten Inferenz-Frameworks (vLLM, SGLang, KTransformers) bieten OpenAI-kompatible APIs.

Abschnitt 3: Der MuonClip-Optimierer, oder warum das Training stabil ist

Das Training eines dünn besetzten MoE mit einer Billion Parametern, ohne dass es explodiert, ist schwierig. Die spezifische Fehlerart: Wenn die Sequenzlänge wächst, kann das Query-Key (QK)-Skalarprodukt in den Aufmerksamkeitsschichten unbegrenzt wachsen. Es kommt zu Verlustspitzen, und in dieser Größenordnung kann eine Verlustspitze nicht wieder behoben werden.

Das technische Paper zu Kimi K2 (arXiv: 2507.20534) stellt MuonClip vor, um damit umzugehen.

Muon ist ein Gradientenoptimierer, der tokeneffizienter ist als AdamW. Gleiche Qualität, weniger Trainingsschritte. Der Haken: Muon allein führt bei einer Billion Parametern zu Aufmerksamkeitsinstabilität.

QK-Clip fügt eine tokenweise, kopfweise Begrenzung direkt auf den QK-Matrizen vor dem Softmax hinzu. Das begrenzt die Größe der Aufmerksamkeitswerte und stoppt die Explosionspathologie. Kein manuelles Tuning, keine Learning-Rate-Hacks.

Aus der Zusammenfassung des Papers:

"Wir stellen MuonClip vor, einen neuartigen Optimierer, der den tokeneffizienten Muon-Algorithmus mit einem stabilisierenden Mechanismus namens QK-Clip kombiniert ... Mit MuonClip erreicht Kimi K2 eine wettbewerbsfähige Leistung, während es deutlich weniger Trainings-Tokens als AdamW-Baselines benötigt."

Warum sollte sich ein Entwickler für ein Trainingsdetail interessieren? Weil der Grund, warum K2.6 4.000 Werkzeugaufrufe über 12+ Stunden ohne Leistungseinbußen durchhalten kann, darauf zurückzuführen ist. Ein Modell, das mit Aufmerksamkeitsinstabilität trainiert wurde, neigt unter Bedingungen mit langem Kontext und vielen Schritten zu Halluzinationen. Und das ist genau das Umfeld, in dem sich ein Agentenschwarm bewegt.

Abschnitt 4: PARL, die Forschung hinter dem Schwarm

Agent Swarm ist kein Framework, das nachträglich auf K2.6 aufgesetzt wurde. Das Verhalten wurde in das Modell einprogrammiert, und zwar durch ein Paradigma, das Moonshot PARL: Parallel-Agent Reinforcement Learning nennt, beschrieben im technischen Paper zu Kimi K2.5 (arXiv: 2602.02276).

Trainierbarer Orchestrator, eingefrorene Unter-Agenten

Der übliche Weg, Multi-Agenten-Systeme zu bauen, besteht darin, mehrere aktive Modellinstanzen auf der Anwendungsebene zu koordinieren. Dann wird die Kreditzuweisung zum Problem: Welcher deiner Agenten hat die endgültige Antwort gut oder schlecht gemacht? Das End-to-End-Training durch diesen Graphen ist rechenintensiv nicht machbar.

PARL umgeht das:

• Der Orchestrator ist trainierbar und wird durch RL auf Ergebnisbelohnungen aktualisiert.
• Die Unter-Agenten sind eingefrorene, feste Zwischen-Checkpoints der Strategie.

Die Trajektorien der Unter-Agenten werden als Umweltbeobachtungen behandelt, nicht als differenzierbare Entscheidungspunkte. Das entkoppelt gleich zwei schwierige Probleme. Die Anerkennung geht nur an die Aktionen des Orchestrators, niemals an 300 gleichzeitige Unter-Agenten. Und das Training bleibt stabil, weil nur ein Modell aktualisiert wird.

Der Orchestrator lernt, wann er parallelisieren, wie viele Unter-Agenten er erzeugen und wie er die Arbeit aufteilen muss. Niemand hat diese Verhaltensweisen manuell vorgegeben. Sie entstehen aus der Maximierung der Belohnung.

Die dreiteilige Belohnungsfunktion

Der Orchestrator trainiert anhand von drei Signalen.

Eine Parallelitätsbelohnung drängt ihn dazu, gleichzeitige Unter-Agenten zu erzeugen, anstatt Aufgaben sequenziell abzuarbeiten. Ohne diese Belohnung würde das Modell standardmäßig immer nur einen Agenten gleichzeitig verwenden: sicher, vorhersagbar, langsam.

Eine Abschlussbelohnung stellt sicher, dass die Unter-Agenten ihre Aufgaben tatsächlich erledigen. Das verhindert „scheinbare Parallelität", bei der der Orchestrator eine Menge von Nichtstuer-Agenten erzeugt, nur um die Parallelitätsbelohnung zu kassieren.

Eine Leistungsbelohnung bewertet die endgültige Ausgabequalität im Hinblick auf das Aufgabenziele. Das ist die grundlegende Wahrheit, der alles andere dient.

Das Detail, das ich am interessantesten finde: Die Optimierungsmetrik sind die kritischen Schritte (kritische Pfadlänge), nicht die Gesamtschritte. Das Modell wird dafür belohnt, die längste Abhängigkeitskette zu verkürzen, nicht dafür, die rohe Parallelität zu maximieren. Das ist es, was tatsächlich die Wandzeit reduziert.

PARL-Ergebnisse

• BrowseComp: Der Schwarmmodus erreichte 78,4 % bei K2.5, ein absoluter Gewinn von 17,8 Punkten gegenüber dem Einzelagenten K2.5 (60,6 %), der damals GPT-5.2 Pro (77,9 %) übertraf. K2.6 treibt dies auf 86,3 %.
• WideSearch: 6,3 Punkte absolute Verbesserung bei Item-F1 (72,7 % auf 79,0 %)
• Wandzeit: 3- bis 4,5-fache Reduzierung bei parallelisierbaren Aufgaben im Vergleich zur Einzelagenten-Baseline
• Parallele Werkzeugaufrufe: bis zu 4.000 koordinierte Schritte in K2.6

Abschnitt 5: Mooncake, die Infrastruktur hinter Kimi

Die Serving-Infrastruktur von Moonshot erklärt, warum K2.6 300 parallele Agenten durchhalten kann, ohne zu schmelzen. Die Modellgewichte sind nur die halbe Geschichte; das System, das sie bedient, ist die andere Hälfte.

Die Infrastruktur ist gut für Aufgaben mit langem Kontext strukturiert.

KVCache-zentrierte disaggregierte Architektur

Die Serving-Plattform von Moonshot heißt Mooncake, beschrieben in ihrem Infrastruktur-Paper von 2024 (arXiv: 2407.00079). Es ist die Engine, die Kimi im großen Maßstab betreibt, und ihre Designentscheidung ist ungewöhnlich.

Die traditionelle LLM-Inferenz führt Prefill (Verarbeitung des Eingabe-Prompts) und Decode (Generierung von Tokens) auf denselben GPU-Instanzen aus. Mooncake trennt sie in separate Cluster auf:

• Prefill-Cluster: übernimmt die anfängliche Prompt-Verarbeitung, skaliert unabhängig für Eingaben mit langem Kontext
• Decode-Cluster: übernimmt die Tokengenerierung, optimiert für Durchsatz und Latenz

Der KV-Cache, der mittlere Aufmerksamkeitszustand, der die autoregressive Generierung effizient macht, wird als erstklassige Systemressource verwaltet. Mooncake baut einen verteilten KV-Cache auf, der GPU-VRAM, CPU-DRAM und SSDs umfasst, mit einer benutzerdefinierten Transfer-Engine, die den Cache zwischen den Knoten verschiebt.

Warum das für Agent Swarm wichtig ist

Wenn 300 Unter-Agenten gleichzeitig laufen, erzeugt jeder seinen eigenen KV-Cache. In einer traditionellen Architektur führt das zu massivem GPU-Speicherdruck und Terminkonflikten. Mit dem disaggregierten Cache von Mooncake:

• KV-Caches von abgeschlossenen Unter-Agenten können auf DRAM oder SSD ausgelagert und bei Bedarf wieder abgerufen werden
• Der Prefill-Cluster verarbeitet die (oft großen) System-Prompts für jeden Unter-Agenten unabhängig
• Der Scheduler maximiert den Gesamtdurchsatz, während er die Latenz-SLOs für jeden Agenten einhält

Aus dem Mooncake-Paper: „Im Vergleich zur Basismethode kann Mooncake in bestimmten simulierten Szenarien eine bis zu 525 % höhere Durchsatzsteigerung erzielen, während die SLOs eingehalten werden. Unter realen Arbeitslasten ermöglicht die innovative Architektur von Mooncake Kimi, 75 % mehr Anfragen zu bearbeiten."

Das aktualisierte Paper berichtet, dass Mooncake „über Tausende von Knoten hinweg operativ ist, täglich über 100 Milliarden Tokens verarbeitet" und im Vergleich zu früheren Systemen 115 % mehr Anfragen auf A800-Clustern und 107 % mehr auf H800-Clustern bewältigt.

PD-Disaggregation im großen Maßstab: Die 128-GPU-K2-Bereitstellung

LMSYS veröffentlichte eine Fallstudie zur Bereitstellung von Kimi K2 unter Verwendung der Prefill-Decode (PD)-Disaggregation auf 128 H200 GPUs über den SGLang Router. Die Architektur:

• SGLang Router: Leichter Dienst für die dynamische Dienstentdeckung von Prefill- und Decode-Knoten über Label-Selektoren
• Expertenparallelität: K2s 384 Experten, verteilt auf Knoten, mit Routing auf Netzwerkebene
• OME (Open Model Engine): Kubernetes-native Orchestrierung für die Serving-Ebene

Das ist der Stack, der die K2-Familie in Produktionsgröße betreibt. Wenn du K2.6 selbst hostest, ist das deine Vorlage.

Abschnitt 6: Wie Agent Swarm Schritt für Schritt funktioniert

Der mechanische Ablauf, wenn K2.6 eine Aufgabe im Schwarmmodus ausführt:

Schritt 1: Aufgabenzerlegung

Der Orchestrator analysiert die Aufgabe und erstellt den Abhängigkeitsgraphen: welche Teilaufgaben unabhängig sind und parallel laufen können, welche von vorherigen Ausgaben abhängen.

Für „Recherchiere 100 YC-Unternehmen und erstelle eine Branchenanalyse" identifiziert der Orchestrator 100 unabhängige Rechercheaufgaben, dann eine Aggregationsaufgabe, dann eine Syntheseaufgabe. Die erste Ebene ist vollständig parallelisierbar.

Schritt 2: Erzeugung spezialisierter Agenten

Der Orchestrator erzeugt domänenspezialisierte Unter-Agenten basierend auf dem Teilaufgabentyp. K2.6 instanziiert Agenten dynamisch mit rollenspezifischen Anweisungen und gezieltem Werkzeugzugriff:

• Web-Recherche-Agenten: Such- + Browser-Werkzeuge
• Datenanalyse-Agenten: Python-Ausführung + Tabellenkalkulationswerkzeuge
• Schreib-Agenten: Synthese und Dokumentenerstellung
• Faktenprüfungs-Agenten: Querverweise und Validierung

Jeder Unter-Agent arbeitet innerhalb seines eigenen begrenzten lokalen Kontexts. Er bearbeitet eine abgegrenzte Aufgabe, erzeugt eine strukturierte Ausgabe und beendet sich. Der lokale Kontext trägt nicht alles, was der Orchestrator weiß, sondern nur das, was dieser Unter-Agent benötigt. Auf diese Weise vermeidet K2.6 Überläufe bei Aufgaben, die das Fenster eines einzelnen Agenten in Minuten füllen würden.

Schritt 3: Parallele Ausführung in Wellen

Agenten führen in Wellen aus. Die erste Welle bearbeitet vollständig unabhängige Aufgaben.

1. Sobald Ergebnisse eintreffen, startet der Orchestrator eine zweite Welle mit Aufgaben, die von den Ergebnissen der ersten Welle abhingen, und so weiter, bis der Abhängigkeitsgraph aufgelöst ist.
2. K2.6 unterstützt bis zu 300 Unter-Agenten und 4.000 koordinierte Schritte pro Sitzung. Der Orchestrator überwacht die Ausführung in Echtzeit, erkennt fehlgeschlagene oder blockierte Agenten und weist ihre Aufgaben automatisch neu zu.
3. Diese Fehlertoleranz ermöglicht autonome Läufe von über 12 Stunden ohne menschliche Überwachung.

Schritt 4: Aggregation und Ausgabe

Sobald alle Unter-Agenten abgeschlossen haben, fasst der Orchestrator die Ergebnisse zu einem endgültigen Ergebnis zusammen: Dokument, Tabelle, Website, Präsentation.

• Er synthetisiert die Ergebnisse der Agenten, anstatt sie nur aneinanderzureihen, sodass das Ergebnis strukturell zusammenhält.
• Ein weiterer erwähnenswerter Punkt: Die Schwarmstruktur ist auch Kimis Antwort auf das Problem des Kontextfensters.
• Die explizite Richtlinie von K2.6: „Sobald das Kontextfenster den Schwellenwert überschreitet, wird nur die aktuellste Runde von werkzeugbezogenen Nachrichten beibehalten." Der Schwarm macht diese Richtlinie über sehr lange Aufgabenhorizonte hinweg nachhaltig.

Abschnitt 7: Die Kimi x Claude Opus 4.8-Architektur

Kein einzelnes Modell ist die richtige Antwort für jede Ebene eines Schwarms. Kimi K2.6 ist für horizontale Skalierung gebaut – parallele Ausführung über Hunderte von Agenten, lange autonome Läufe, kosteneffiziente Massenverarbeitung.

Claude Opus 4.8 ist für Urteilsvermögen gebaut – Planung, nuanciertes Denken und das Erkennen eigener Fehler. Sie ergänzen sich strukturell, und die Lücke, die jedes hinterlässt, kommt der Form der Stärke des anderen nahe.

Das Muster:

1[Benutzerziel]
2      |
3[Claude Opus 4.8 - Planer]
4  Zerlegt das Ziel in eine strukturierte Aufgabenspezifikation
5  Identifiziert parallele vs. sequenzielle Teilaufgaben
6  Definiert Erfolgskriterien für jede Teilaufgabe
7      |
8[Kimi K2.6 Agentenschwarm - Ausführer]
9  Empfängt die strukturierte Aufgabenspezifikation
10  Erzeugt bis zu 300 spezialisierte Unter-Agenten
11  Läuft parallel über Werkzeugaufrufe hinweg
12  Gibt strukturierte Ergebnisse zurück
13      |
14[Claude Opus 4.8 - Verifizierer]
15  Überprüft Kimis Ausgaben anhand der Erfolgskriterien
16  Markiert Fehler, Lücken, Inkonsistenzen
17  Synthetisiert das endgültige Ergebnis

Warum Claude für Planung und Verifizierung?

Die am meisten unterschätzte Änderung in Opus 4.8 ist die Verbesserung der Ehrlichkeit: „Opus 4.8 ist etwa viermal weniger wahrscheinlich als sein Vorgänger, Fehler in selbst geschriebenem Code unkommentiert durchzulassen." In agentischen Systemen ist falsches Selbstvertrauen die katastrophale Fehlerart.

• Ein Orchestrator, der „abgeschlossen" meldet, obwohl er es nicht ist, wird Fehler auf 300 nachgelagerte Agenten kaskadieren. Claudes Tendenz, Unsicherheit zu markieren und eigene Fehler während der Aufgabe zu erkennen, macht ihn zum richtigen Anker für die Ebenen, auf denen Fehler teuer sind.
• Opus 4.8 unterstützt auch ein 1-Millionen-Token-Kontextfenster, was für den Verifizierungsdurchlauf wichtig ist, wenn du Ausgaben von über 50 parallelen Recherche-Agenten in einen einzigen Überprüfungskontext ziehst.

Warum Kimi für die Ausführung?

K2.6s Agent Swarm unterstützt bis zu 300 parallele Unter-Agenten und 4.000 koordinierte Werkzeugschritte pro Sitzung – das ist ein antrainiertes Verhalten, kein Anwendungs-Wrapper.

• Claude hat zwar eine Dynamic Workflows-Funktion in Claude Code, aber diese befindet sich derzeit in der Forschung und ist auf Enterprise/Max-Pläne beschränkt.
• Kimis Schwarmfähigkeit ist jetzt für alle über die API verfügbar. Die Token-Ökonomie ist auch im großen Maßstab relevant: K2.6 kostet 0,95 $/4,00 $ pro Million Eingabe-/Ausgabe-Tokens. Für die parallele Massenausführung ist das nicht nichts.

Abschnitt 8: Wann du einen Schwarm brauchst (und wann nicht)

Der mit Abstand häufigste Fehler beim Multi-Agenten-Design: Die Komplexität eines Schwarms hinzuzufügen, bevor du die Grenzen eines einzelnen Agenten erreicht hast.

Bleibe bei einem einzelnen Agenten, wenn:

• Die Aufgabe in ein einzelnes Kontextfenster passt (unter ~50.000 Token tatsächlicher Arbeit)
• Die Aufgabe von Natur aus sequenziell ist und jeder Schritt vom vorherigen abhängt
• Du dich noch in der Prototypenphase befindest – Fehlerarten einzelner Agenten sind viel einfacher zu beheben
• Die Aufgabe ohnehin in unter 10 Minuten erledigt wäre

Greife zu Agent Swarm, wenn:

• Die Aufgabe n parallele, unabhängige Teilaufgaben hat, wobei n > 5
• Kontextüberlauf ein echtes Problem ist (tiefgehende Recherche, große Codebasen, Batch-Operationen)
• Du domänenspezialisierte Agenten benötigst, die gleichzeitig arbeiten
• Die Aufgabe zu lang ist, um die Qualität über eine einzige sequenzielle Sitzung aufrechtzuerhalten
• Du einen Kritiker- oder Verifizierer-Agenten haben möchtest, der die Arbeit eines anderen Agenten überprüft

Verwende den Kimi + Claude Opus 4.8-Hybrid, wenn:

• Die Qualität der Planung wichtig ist und du ein Modell möchtest, das widerspricht, wenn der Plan falsch ist
• Die Ausgabe ohne weitere menschliche Überprüfung ausgeliefert wird – die Verifizierung muss also integriert sein
• Du eine umfangreiche Ausführung mit sich schnell summierenden Tokenkosten betreibst
• Du Claudes Urteilsvermögen auf den Entscheidungsebenen und Kimis Skalierbarkeit auf den Arbeitsebenen möchtest

Abschnitt 10: Die vier Architekturmuster für Schwärme

Muster 1: Orchestrator-Arbeiter (am häufigsten)

Ein zentraler Orchestrator weist den Arbeitern Teilaufgaben zu, die Arbeiter führen parallel aus, die Ergebnisse werden zusammengeführt.

1[Benutzerziel]
2    |
3[Orchestrator - Claude Opus 4.8]
4    +-- [Arbeiter: Kimi Recherche-Agent x N]
5    +-- [Arbeiter: Kimi Daten-Agent x N]
6    +-- [Arbeiter: Kimi Code-Agent x N]
7    |
8[Synthetisierer - Claude Opus 4.8]
9    |
10[Endgültige Ausgabe]

Am besten geeignet für: Aufgaben mit klar trennbaren Teilaufgaben und einer variablen Anzahl von Arbeitern.

Muster 2: Kritiker-Verbesserer-Schleife

Ein Agent erstellt, ein anderer kritisiert, wiederholen, bis die Qualitätsschwelle erreicht ist.

1[Kimi K2.6 Ersteller] -> Entwurf -> [Claude Opus 4.8 Kritiker] -> Feedback -> [Kimi K2.6 Ersteller]
2                                        |
3                                   (genehmigt)
4                                [Endgültige Ausgabe]

Am besten geeignet für: Codegenerierung, technisches Schreiben, compliance-sensitive Ausgaben. Lege immer ein Limit für die maximale Anzahl von Iterationen fest.

Muster 3: Hierarchisch

Ein strategischer Orchestrator verwaltet Domänen-Orchestratoren, die wiederum Arbeiter verwalten.

1[Claude Opus 4.8 - Strategischer Orchestrator]
2    +-- [Kimi K2.6 Schwarm - Forschungsteam (50 Agenten)]
3    +-- [Kimi K2.6 Schwarm - Bauteam (50 Agenten)]

Am besten geeignet für: Große Unternehmensworkflows mit unterschiedlichen Bereichen.

Muster 4: Claw Groups (Kimi-nativer heterogener Schwarm)

K2.6 koordiniert Agenten, die jedes Modell ausführen, einschließlich lokaler Modelle, Claude und GPT, zusammen mit menschlichen Arbeitern in einem gemeinsamen Operationsraum. Derzeit in der Forschung.

1[Kimi K2.6 Koordinator]
2    +-- [Claude Opus 4.8 - Denkspezialist]
3    +-- [Llama 3.3 lokal - kostenintensive Massenaufgaben]
4    +-- [Kimi K2.6 Agenten x N - Ausführungsebene]
5    +-- [Menschlicher Prüfer - Genehmigungs-Checkpoints]

Am besten geeignet für: Workflows, die Modellvielfalt, lokale + Cloud-Hybride oder Human-in-the-Loop-Anforderungen benötigen.

Abschnitt 12: Prompt-Design für Schwarmaufgaben

Der Zerlegungs-Prompt (Orchestratoren)

1Du bist ein Aufgabenarchitekt. Zerlege dieses Ziel in unabhängige, parallelisierbare Teilaufgaben.
2
3Regeln:
4- Jede Teilaufgabe muss von einem einzelnen spezialisierten Agenten isoliert abschließbar sein
5- Teilaufgaben mit Abhängigkeiten müssen mit ihrer Abhängigkeitskette markiert werden
6- Ausgabe als JSON: {task_id, description, agent_type, depends_on, success_criteria}
7
8Ziel: {user_goal}
9Verfügbare Agententypen: Forscher, Analyst, Programmierer, Schreiber, Verifizierer

Der Spezialisten-System-Prompt (Unter-Agenten)

1Du bist ein {ROLE}-Agent, der auf {DOMAIN} spezialisiert ist.
2
3Aufgabe: {subtask_description}
4
5EINSCHRÄNKUNGEN:
6- Gib NUR gültiges JSON zurück, das folgendem Schema entspricht: {output_schema}
7- Gehe NICHT über deinen Aufgabenbereich hinaus
8- Wenn du die Aufgabe nicht abschließen kannst: {"error": "Grund", "partial_results": [...]}
9- Maximale Werkzeugaufrufe: {max_tool_calls}
10
11Kontext: {context_from_orchestrator}

Der Aggregations-Prompt (Synthetisierer)

1Synthetisiere die Forschung von {n} spezialisierten Agenten zu einer kohärenten Ausgabe.
2
31. Lies alle bereitgestellten Agentenausgaben
42. Identifiziere, wo sie übereinstimmen, widersprechen oder Lücken haben
53. Erstelle ein {output_type}, das alle Ergebnisse integriert
64. Weise Inkonsistenzen explizit aus – löse Widersprüche nicht stillschweigend auf
7
8Agentenausgaben: {agent_outputs_as_json}
9Ausgabeformat: {final_output_spec}

Abschnitt 13: Die sieben nicht verhandelbaren Absicherungen

1. Maximale Iterationen pro Agent. Harte Grenze für Schleifen, bevor der Orchestrator benachrichtigt wird.

2. Sitzungs-Timeout. Wenn der Schwarm nicht innerhalb von N Minuten abgeschlossen ist, beende und gib Teilergebnisse zurück.

3. Erzwingen strukturierter Ausgaben. Zwinge die Agenten, JSON zurückzugeben. Prosa von Zwischenagenten führt zu nachgelagerten Parsing-Fehlern.

4. Fehlerisolation. Ein fehlschlagender Unter-Agent darf den Orchestrator nicht zum Absturz bringen.

1async def run_subagent_safely(kimi_client, task, agent_id):
2    try:
3        result = kimi_client.chat.completions.create(
4            model="kimi-k2.6",
5            messages=[{"role": "user", "content": task}],
6            max_tokens=4096
7        )
8        return {"agent_id": agent_id, "status": "success",
9                "output": result.choices[0].message.content}
10    except Exception as e:
11        return {"agent_id": agent_id, "status": "failed", "error": str(e)}

5. Wiederholung mit exponentiellem Backoff. Behandle 429er und vorübergehende Fehler, ohne sie als dauerhafte Fehler anzuzeigen.

6. Human-in-the-Loop-Checkpoints. Für Schwärme mit Schreibzugriff (Bereitstellen von Code, Senden von E-Mails, Durchführen von API-Mutationen) füge obligatorische Genehmigungspausen ein.

7. Kostenüberwachung. Lege Token-Budgets pro Lauf fest. Außer Kontrolle geratene Schleifen zeigen sich jedes Mal als Kostenanomalien, bevor sie sich als Qualitätsfehler manifestieren.

Was du zuerst bauen solltest

Beginne mit der Drei-Agenten-Pipeline aus Abschnitt 9. Sie ist klein genug, um an einem Nachmittag getestet zu werden, sie trainiert Planung, parallele Ausführung und Verifizierung, und du kannst sie mit weniger als einer Stunde Einrichtungszeit an einer echten Aufgabe ausführen.

Wenn sie kaputt geht – und das wird sie – wird dir die Fehlerart mehr über das Design von Schwärmen beibringen als eine weitere Stunde Lesen.

Baue es. Zerstöre es absichtlich. Dann kehre mit einem konkreten Referenzpunkt zu den Mustern in Abschnitt 11 zurück.

Die Architektur ist nicht der schwierige Teil. Der schwierige Teil ist die Lücke zwischen „funktioniert im Test" und „funktioniert um 3 Uhr morgens, ohne dass jemand zusieht", und diese Lücke liegt vollständig in den Absicherungen, der Beobachtbarkeit und dem Gedächtnisdesign.

Fazit

Kimi 2.6 ist eine Revolution für Agenten, wie Reinforcement Learning Agentenschwärme etablieren kann.

Es zeigt auch, wie lange Kontexthorizonte solche auf Orchestratoren basierenden Infrastrukturen nutzbar machen können, die es ermöglichen, mehrere Unter-Agenten zu erzeugen, um komplexe Systeme zu bauen – alles mit einem einzigen

Haftungsausschluss

Der Artikel wurde unter Verwendung der technischen Dokumentation von Kimi 2.6 und Forschungsarbeiten in den Notizen des Autors verfasst und von einer KI, Opus 4.7, bearbeitet.