Vom Sub-Agenten zum Schwarm
Kimi K3 – das Modell hinter dem Agenten, Teil 5
Mehr Agenten versprechen kürzere Laufzeiten, doch die Parallelität allein erzeugt noch keine gute Lösung. Aufgaben müssen sich zerlegen lassen, Ergebnisse brauchen klare Schnittstellen, und am Ende muss jemand Widersprüche auflösen. Moonshots Agent Swarm zeigt, wie sich Test-Time Compute horizontal skalieren lässt. Kimi K3 verbessert die Orchestrierung, während Kimi Code und Kimi Work die Ausführungsumgebung bereitstellen.
100, 300 und K3: Die Zahlen richtig zuordnen
Kimi K2.5 führte einen selbstorganisierten Schwarm mit bis zu 100 Sub-Agenten und 1.500 koordinierten Schritten als Research Preview ein. Parallel-Agent Reinforcement Learning trainierte den Orchestrator, Aufgaben und Rollen ohne vorgefertigten Workflow zu erzeugen. Moonshot berichtete bis zu 4,5-fach beschleunigte Bearbeitung und 80 Prozent weniger End-to-End-Laufzeit in internen Auswertungen. Moonshot nennt im Bericht die „Wall-Clock time“. Sie bezeichnet die tatsächlich verstrichene Zeit, die sich auf einer Uhr messen lassen würde, vom Start der Aufgabe bis zum fertigen Ergebnis. Gemeint ist also nicht die aufsummierte Rechenzeit aller Agenten. Wenn ein einzelner Agent beispielsweise 45 Minuten benötigt und mehrere Agenten parallel einen Faktor von 4,5 erreichen, liegt die reale Wartezeit theoretisch nur noch bei etwa 10 Minuten. Dabei können die Agenten zusammen mehr Rechenzeit und Ressourcen verbrauchen als der einzelne Agent.
Kimi K2.6 erhöhte die Produktgrenze auf 300 Sub-Agenten und 4.000 Schritte, und Kimi Work nennt ebenfalls bis zu 300 parallele Agenten. K3 führt Moonshots internen Swarm Bench mit 76,3 Punkten an. Präzise lautet die Aussage: Die 300er-Grenze gehört zum Harness. K3 stellt das aktuelle Modell und zeigt intern stärkere Orchestrierung [Kimi Team].
Der kritische Pfad entscheidet
Ein Schwarm hilft nur, wenn Teilaufgaben unabhängig genug laufen. Das Kartieren von sechs Subsystemen, die Prüfung verschiedener Programmiersprachen oder parallele Recherche zu Bibliotheken eignen sich gut. Eine Datenbankmigration, deren zweiter Schritt das Schema aus Schritt eins benötigt, bleibt weitgehend seriell. Zusätzliche Agenten verkürzen dann den kritischen Pfad nicht.
Praktisch lässt sich der Plan als Abhängigkeitsgraph formulieren. Knoten ohne offene Vorgänger dürfen parallel starten. Build, Integrationstest und Review bilden Synchronisationspunkte. Eine Concurrency-Grenze verhindert, dass ein breiter Graph API-Limits, CI-Runner oder Datenbanken überlastet. Der Orchestrator braucht damit auch Backpressure und Prioritäten, nicht nur Delegation.
Eine robuste Zerlegung definiert Eingaben, Werkzeuge, Ausgabeformat und Abnahme. Der Orchestrator muss Duplikate erkennen, Fehler neu vergeben und Befunde zusammenführen. Kimi Code isoliert Sub-Agenten-Kontexte. Gemeinsame Annahmen müssen ausdrücklich im Auftrag stehen [Kimi Code – Agents and Sub-Agents].
Schreibende Agenten brauchen zudem Grenzen bezogen auf die Berechtigungen von Dateien und Verzeichnissen. Separate Branches oder Worktrees trennen Änderungen, und ein Integrationsagent übernimmt Merge, Build und Tests. Andernfalls würden viele plausible Patches entstehen, aber kein konsistenter Systemzustand.
Kleine Python-Demo als Map-Reduce
Die überschaubare Demo in Listing 1 verteilt eine lesende Analyse auf vier Repository-Bereiche und lässt K3 die Berichte zusammenführen. Sie verwendet bewusst nur wenige Worker. In der Praxis bestimmen die API- und Budgetgrenzen des Kontos die reale Parallelität.
Listing 1: Eine verteilte (lesende) Analyse, verteilt auf vier Repository-Bereiche
import os
from concurrent.futures import ThreadPoolExecutor
from openai import OpenAI
client = OpenAI(api_key=os.environ["MOONSHOT_API_KEY"],
base_url="https://api.moonshot.ai/v1")
def ask(text):
r = client.chat.completions.create(
model="kimi-k3", reasoning_effort="low",
messages=[{"role": "user", "content": text}])
return r.choices[0].message.content
areas = ["src/api", "src/domain", "src/data", "tests"]
with ThreadPoolExecutor(max_workers=4) as pool:
reports = list(pool.map(
lambda p: ask(f"Prüfe den bereitgestellten Inhalt aus {p}. "
"Liefere Risiken als JSON, ändere nichts."), areas))
result = ask("Führe diese Berichte zusammen, entferne Duplikate und "
"priorisiere nach Belegstärke:\n" + "\n".join(reports))
print(result) Im realen Einsatz erhält das Modell Inhalte oder Repository-Werkzeuge statt bloßer Pfadnamen. JSON-Schemata, Time-outs, Retry mit Jitter, Tokenbudget und Protokollierung gehören ebenfalls dazu. Schreiboperationen bleiben wegen paralleler Seiteneffekte außen vor.
Kimi Code bringt dafür Hauptagent, explore, plan, coder und eigene Profile mit. Die Delegation läuft automatisch, doch jeder Kontext erzeugt eigene Modellkosten. Für kleine Aufgaben bleibt ein einzelner Agent oft konsistenter und einfacher zu handhaben [Kimi Code – Agents and Sub-Agents].
Proaktive Agenten leben länger als ein Turn
Moonshot beschreibt für K2.6 einen internen Agenten, der fünf Tage Monitoring, Incident Response und Systembetrieb bearbeitete. Das ist ein Herstellerversuch, keine Garantie. K3 trainierte zudem in persistenten, über simulierten Tagen fortschreitenden Umgebungen. Im 24/7 ClawBench 2.0 erreicht K3 48,3 Punkte und liegt damit nicht an der Spitze [Kimi Team].
Kimi Codes /goal setzt eine kleinere Form proaktiver Arbeit um. Klare Endkriterien sind zwingend, denn einen separaten Stop-Limit-Schalter gibt es nicht. Budgets und Stop-Bedingungen gehören in Konfiguration und Zieltext [Kimi Work] [Kimi Code – Goals].
Sicherheit skaliert ebenfalls horizontal
Mit jedem Sub-Agenten steigen Angriffsfläche und Kosten. Prompt Injection, breite MCP-Rechte und parallele Seiteneffekte verlangen technische Begrenzungen. Zu berücksichtigen sind mindestens die nachfolgenden Punkte. Je nach Projekt und Unternehmen kommen weitere Richtlinien hinzu:
- lesende Profile für Exploration und Review,
- getrennte Worktrees oder Container für schreibende Agenten,
- kurzlebige Zugangsdaten mit minimalen Scopes,
- zentrale Budget-, Concurrency- und Zeitlimits,
- unveränderliche Logs sowie eindeutige Agenten- und Tool-IDs,
- einen seriellen Integrationsschritt mit Tests und menschlicher Freigabe.
Auch die Qualität skaliert nicht linear: Gleiche Modelle, Prompts und Daten erzeugen korrelierte Fehler. Eine brauchbare Diversität braucht unterschiedliche Rollen, Prüfer und Testdaten.
Parallelität mit Begründung
Agent Swarms eignen sich für breite Suche, große Codebasen, unabhängige Reviews und die Erzeugung vieler klar abgegrenzter Artefakte. Sie eignen sich schlecht für kleine Patches, eng gekoppelte Architekturentscheidungen und irreversible Aktionen. Der praktische Maßstab lautet nicht „Wie viele Agenten kann das Produkt starten?“, sondern: „Welche Arbeit verlässt den kritischen Pfad, und wie lässt sich das Gesamtergebnis prüfen?“
K3 liefert starke Signale für Zerlegung und Orchestrierung, doch Moonshots interne Benchmarks und spektakuläre Demos brauchen Replikation im eigenen Kontext. Zu betrachtet gilt es deshalb noch die weniger sichtbare Seite: Modellbereitstellung, Tokenkosten, Kontext-Caching, Lizenzbedingungen und die sichere Integration in eine .NET-Anwendung.
