Planen, patchen, prüfen mit Kimi
Kimi K3 – das Modell hinter dem Agenten, Teil 3
Kimi K3 allein kennt weder das lokale Git-Repository noch Kommandos wie dotnet test. Erst Kimi Code verbindet das Modell mit Dateien, Suche, Shell und Sitzungszustand. Dieser Agent-Harness entscheidet damit wesentlich über Qualität und Risiko von Aktionen und Operationen auf beispielsweise Dateien. Der dritte Teil der Serie zu Kimi K3 richtet einen kontrollierten Workflow für eine kleine .NET-Modernisierung ein und zeigt, wie Plan-, Berechtigungs- und Zielmodus zusammenspielen.
Installation und Vertrauensgrenze
Moonshot verteilt Kimi Code als ausführbares Programm und NPM-Paket. Unter Windows setzt die Shell-Integration Git for Windows voraus. Die NPM-Variante verlangt Node.js ab Version 22.19. Kimi startet im Projektverzeichnis die Terminaloberfläche, /login verbindet Konto oder API-Schlüssel. Weitere kompatible Provider lassen sich per config.toml anbinden [Kimi Code – Getting started]. Die folgenden Zeilen bewirken die Installation und erste Ausführung über die PowerShell:
irm https://code.kimi.com/kimi-code/install.ps1 | iex cd C:\src\CatalogApi kimi
Für einen produktiven Einsatz gehört das Installationsskript als fixierte Version samt Prüfsumme in die interne Toolchain. Erst auf diese Weise ist es in der Praxis deterministisch und reproduzierbar [Kimi Code Repository]. Repository und CLI tragen eine MIT-Lizenz. Für die K3-Gewichte gilt die eigene Kimi-K3-Lizenz [Kimi K3 License].
Die Standardkonfiguration startet im manuellen Berechtigungsmodus. Lesezugriffe laufen gewöhnlich ohne Nachfrage, während Dateiänderungen und Shell-Befehle eine Freigabe anfordern. Der Yolo-Modus genehmigt reguläre Tool-Aufrufe automatisch, kann aber weiterhin Fragen stellen und schützt sensible Aktionen. Auto entscheidet vollständig ohne Rückfrage, einschließlich Zugriffen auf sensible Dateien und Planfreigaben. Für einen ersten Lauf in einem Unternehmensrepository passt in der Regel nur der manuelle Modus. Autonome Modi gehören in einen isolierten Klon mit minimalen Zugangsdaten, damit so wenig wie möglich schieflaufen kann [Kimi Code – Interaction and input].
Das Projektwissen explizit machen
Ein Coding-Agent errät Architekturregeln aus Codefragmenten, wenn sonst keine Informationen beziehungsweise Quellen vorhanden sind. Eine kurze AGENTS.md im Repository macht die wichtigsten Leitplanken maschinenlesbar. So eine Datei könnte wie folgt aufgebaut sein:
# Arbeitsregeln - Zielplattform: .NET 10, C# mit Nullable Reference Types. - Öffentliche API-Verträge nur nach ausdrücklicher Freigabe ändern. - Keine neuen Pakete ohne Begründung und Lizenzprüfung. - Vor Abschluss: dotnet format --verify-no-changes und dotnet test -c Release. - Niemals Secrets, .env-Dateien oder Produktionsdaten öffnen.
Die Datei enthält nur projektweite Regeln, denn Fachanforderungen bleiben im Issue. Projektbezogene Profile aus .kimi-code/agents/ oder .agents/agents/ können Systemprompt und Toolauswahl verändern. In fremden Repositories verdienen sie deshalb dieselbe Prüfung wie Skripte [Kimi Code – Agents and Sub-Agents].
Erst planen, dann ändern
Der Planmodus ([Shift]+[Tab] oder /plan) lässt den Agenten zunächst einen Ablauf formulieren und pausiert vor Dateiänderungen. Für die Demo liegt ein älterer Minimal-API-Endpunkt vor, dessen Handler Validierung, Datenzugriff und Mapping vermischt. Der Auftrag lautet:
Analysiere @src/Catalog.Api und @tests/Catalog.Api.Tests. Plane die Extraktion der Geschäftslogik in einen Service. Behalte HTTP-Vertrag und Datenbankschema bei. Ergänze Tests für 404, ungültige IDs und Parallelzugriffe. Nenne vor jeder Änderung betroffene Dateien.
Ein brauchbarer Plan nennt Abhängigkeiten, Prüfkommandos und Kompatibilitätsrisiken. Einzelne Shell-Freigaben zeigen früh, ob der Agent ungeplant Migrationen, Paketinstallationen oder Netzwerkzugriffe anfordert. Eine Sitzungsfreigabe passt für dotnet test, nicht für beliebige Shell-Kommandos.
Nach der Planphase übernimmt ein Ziel die mehrstufige Ausführung:
/goal Setze den freigegebenen Refactoring-Plan um. Alle Tests sowie dotnet format --verify-no-changes müssen erfolgreich sein. Ändere weder API-Vertrag noch Datenbankschema. Stoppe bei einem nötigen Paketupdate, einer Migration oder einem nicht reproduzierbaren Testfehler.
Der Agent darf Quelltext ändern, Builds starten und Testergebnisse aufnehmen. Stopbedingungen verhindern kreative Umgehungen. Ein Git-Worktree oder Container isoliert Nebenwirkungen. Danach zeigen git diff und Testbericht den tatsächlichen Umfang.
Sitzungen statt endloser Chats
Kimi Code persistiert Sitzungen pro Arbeitsverzeichnis. kimi --continue setzt die letzte Sitzung fort, /fork erzeugt eine Abzweigung. /compact Behalte API-Vertrag, Abnahmekriterien und offene Testfehler komprimiert den Kontext mit Prioritäten [Kimi Code – Sessions and context]. Das sind auch aus anderen Agenten beziehungsweise Assistenten bekannte Befehle.
Wichtige Entscheidungen gehören trotzdem in Code, Issue oder Architecture Decision Record (ADR). Sitzungsdateien können Prompts, Tool-Ausgaben und Spuren von Zugangsdaten enthalten. Diese dürfen nicht ungeprüft in öffentlichen Fehlermeldungen erscheinen [Kimi Code – Agents and Sub-Agents] [Kimi Code – Sessions and context].
Sub-Agenten mit getrennten Kontexten
Kimi Code bringt drei Profile mit: explore durchsucht das Repository nur lesend, plan entwirft eine Vorgehensweise ohne Shell und coder darf implementieren. Der Hauptagent delegiert automatisch oder auf ausdrückliche Anweisung. Jeder Sub-Agent erhält ein eigenes Kontextfenster und liefert nur sein Endergebnis zurück. Dadurch blähen Suchprotokolle den Hauptkontext nicht auf. Wichtig zu beachten ist, dass jeder Agent gleichzeitig eigene Token verbraucht [Kimi Code – Agents and Sub-Agents].
In der Demo kartiert explore Aufrufer und Tests, während plan eine Schnittstellengrenze vorschlägt. Beide Aufgaben sind unabhängig. Dieselbe Datei sollten zwei Agenten dagegen nicht parallel refaktorieren.
Eigene Profile begrenzen Tools. Ein Reviewer braucht Read, Grep und Glob, aber keinen Schreibzugriff. MCP-Anbindungen öffnen externe Systeme wie GitHub oder Datenbanken; jede Verbindung erweitert die Vertrauensgrenze und benötigt eng gefasste Rechte [Kimi Code – Agents and Sub-Agents] [Kimi Code – Model Context Protocol].
Der Agent liefert einen Patch, kein Urteil
Nach dem Zielmodus folgen dieselben Kontrollen wie bei menschlichen Änderungen: Diff-Review, sauberer CI-Lauf, statische Analyse, Dependency- und Secret-Scan sowie fachliche Abnahme. Kimi Code kann sie ausführen, aber nicht unabhängig alle unausgesprochenen Anforderungen bestätigen.
Der praktische Fortschritt liegt deshalb nicht in „vollständig autonomer Entwicklung“, sondern in einer engeren Feedbackschleife: erkunden, planen, patchen, testen, korrigieren. Mit klaren Berechtigungen, überprüfbaren Zielen und persistierten Sitzungen kann K3 diese Schleife lange aufrechterhalten.
Anhand von Bildern und Browser-Screenshots bleibt nun noch zu zeigen, wie aus Coding ein visueller Designprozess entsteht.
