Kimi Code Modellpool: Subagenten nach Aufgabe statt Bauchgefühl routen

Kimi Code v0.36 macht aus der experimentellen Subagenten-Konfiguration einen Modellpool. Unternehmen können Kandidatenmodelle mit Beschreibungen hinterlegen; der Hauptagent wählt bei jedem Spawn anhand der Aufgabe ein Sekundärmodell aus. Das klingt nach automatischer Optimierung, verschiebt aber eine wichtige Entscheidung in den Agentenlauf: Welche Beschreibung führt zu welchem Modell – und wie wird eine falsche Auswahl erkannt?

Was sich mit dem Modellpool verändert

Bisherige Agentenarchitekturen binden Subtasks häufig an ein festes Modell oder lassen die Anwendung anhand statischer Regeln auswählen. Der Kimi-Code-Ansatz gibt dem Hauptagenten eine Liste beschriebener Kandidaten. Damit wird die Modellbeschreibung selbst zu einem Steuerungsinstrument. Unklare oder werbliche Formulierungen können das Routing ebenso verzerren wie fehlende Informationen zu Grenzen.

• Pool statt Einzelmodell: mehrere Kandidaten stehen für Subagenten bereit.
• Beschreibung als Routingkontext: der Hauptagent nutzt Angaben zu Eignung und Aufgabe.
• Auswahl pro Spawn: verschiedene Subtasks desselben Auftrags können unterschiedliche Modelle erhalten.
• Experimenteller Status: Konfiguration und Verhalten sollten begrenzt und eng beobachtet werden.
• Neue Betriebsdimension: Modellwahl wird Teil des protokollierbaren Agentenprozesses.

Ein Modellpool ist deshalb keine reine Kostenfunktion. Er kann einfache Aufgaben einem kleineren Modell und komplexe Analysen einem leistungsfähigeren Kandidaten zuordnen. Er kann aber auch uneinheitliche Ergebnisse, schwerere Fehlersuche und zusätzliche Anbieterabhängigkeiten erzeugen. Der Nutzen muss pro Aufgabentyp belegt werden.

Wie gute Kandidatenbeschreibungen aussehen

Eine Beschreibung sollte nicht behaupten, ein Modell sei „das beste“. Sie sollte die Entscheidung anhand beobachtbarer Eigenschaften ermöglichen: geeignete Aufgabentypen, unerwünschte Einsatzfälle, benötigte Werkzeuge, Kontextanforderungen, erwartete Ausgabeformate und betriebliche Grenzen. Preise oder Leistungsangaben gehören nur hinein, wenn sie aktuell und belastbar gepflegt werden.

1. Eignung nennen: etwa kurze Klassifikation, Repository-Recherche, Codeänderung oder unabhängige Prüfung.
2. Ausschlüsse nennen: sensible Daten, schreibende Tools, große Kontexte oder irreversible Aktionen begrenzen.
3. Ausgabe definieren: gewünschte Struktur, Belege, Tests und Unsicherheiten angeben.
4. Betriebsgrenzen nennen: Zeit-, Schritt- und Budgetrahmen sowie benötigte Werkzeuge festhalten.
5. Versionieren: jede Änderung an Beschreibung, Modell oder Routingregeln nachvollziehbar dokumentieren.

Evaluationsmatrix für Qualität, Kosten und Fehlrouting

Die Evaluation braucht einen festen Satz typischer Subtasks. Dazu gehören einfache, mittlere und komplexe Fälle sowie Aufgaben, die ausdrücklich keinem Kandidaten zugewiesen werden sollten. Für jeden Fall wird nicht nur das Ergebnis, sondern auch die Modellwahl bewertet. So lässt sich unterscheiden, ob ein Fehler aus dem Routing oder aus der Bearbeitung stammt.

• Routingtreffer: Wurde ein nach Kriterien geeignetes Modell ausgewählt?
• Ergebnisqualität: Bestehen Code, Tests, Struktur und fachliche Abnahme?
• Gesamtkosten: Modellnutzung, Tool-Aufrufe, Wiederholungen und Reviewaufwand zusammenzählen.
• Latenz: Zeit bis zum akzeptierten Ergebnis statt nur einzelne Antwortzeiten messen.
• Stabilität: ähnliche Aufgaben sollten nachvollziehbar ähnliche Entscheidungen erzeugen.
• Fallback: bei Unsicherheit, Ausfall oder Grenzwertverletzung einen sicheren Standardpfad nutzen.

Eine preiswerte Auswahl ist unwirtschaftlich, wenn sie zusätzliche Wiederholungen oder Reviews auslöst. Umgekehrt muss nicht jeder schwierige Task an das teuerste Modell gehen. Entscheidend ist die Kombination aus akzeptierter Qualität, Gesamtaufwand und Risiko.

Risiken eines dynamischen Subagenten-Routings

Mit jedem zusätzlichen Modell wachsen Konfigurations- und Betriebsflächen. Datenbedingungen können sich unterscheiden, Werkzeuge werden nicht überall gleich unterstützt und Ausgaben können verschiedene Formate oder Fehlerbilder haben. Unternehmen sollten den Pool daher klein halten und nur Kandidaten aufnehmen, deren Einsatzbedingungen geprüft sind.

• Fehlrouting: unklare Aufgaben oder überlappende Beschreibungen führen zur falschen Auswahl.
• Datenrisiko: Modelle oder Anbieter können unterschiedliche Verarbeitungsbedingungen besitzen.
• Formatrisiko: strukturierte Ausgaben und Tool-Aufrufe verhalten sich nicht zwingend identisch.
• Kostenrisiko: wiederholte Spawns oder Eskalationen können Einsparungen aufheben.
• Lock-in: Logik und Testkorpus sollten unabhängig von einzelnen Kandidaten bleiben.
• Auditrisiko: Auswahlgrund, Modellversion und Ergebnis müssen einem Subtask zugeordnet werden.

Vierstufiger Rollout für den Kimi Code Modellpool

Stufe eins enthält nur zwei klar abgegrenzte Kandidaten und ein Offline-Testkorpus. Stufe zwei protokolliert Routingentscheidungen im Shadow Mode, verwendet für echte Arbeit aber weiter das bisherige Standardmodell. Stufe drei erlaubt den Pool für wenige rücksetzbare Subtasks mit verpflichtendem Review. Erst Stufe vier erweitert Aufgaben oder Kandidaten, wenn Routingtreffer, Ergebnisqualität, Kosten und Fallback stabil sind.

Im Betrieb sollten Verantwortliche regelmäßig prüfen, ob Beschreibungen noch zum aktuellen Modellverhalten, zu Preisen und Richtlinien passen. Ein Modellpool ist kein einmaliges Setup. Er ist ein lebendes Routing-System, das mit jeder Modell- oder Prozessänderung neu validiert werden muss.

Wann der Modellpool einen echten Vorteil bietet

Der Kimi Code Modellpool ist sinnvoll, wenn Subtasks deutlich unterschiedliche Anforderungen haben und ein Team diese Unterschiede mit Testfällen belegen kann. Er ist unnötig, wenn fast alle Aufgaben dasselbe Modell benötigen oder das Team weder Auswahl noch Ergebnis überwachen kann. Der geschäftliche Wert entsteht nicht durch mehr Modelle, sondern durch eine bessere Zuordnung von Aufgabe, Qualität, Kosten und Risiko.