KunAgent/Kun: ein lokaler Agent-Runtime für GUI und TUI

Ein Runtime statt zwei getrennter Sitzungen

Die meisten Agent-Werkzeuge existieren entweder als Desktop-Anwendung oder als Kommandozeilenprogramm. Kun verfolgt den umgekehrten Ansatz: Beide Oberflächen greifen auf denselben lokalen Prozess zu, den das Projekt als `kun serve` bezeichnet. Das README formuliert den Anspruch so, dass GUI und TUI Threads, Ziele, Pläne, Freigaben und Hintergrundaufgaben teilen, statt zwei voneinander isolierte Sitzungen zu führen. Wer also eine Aufgabe im Terminal startet und später im Desktop-Fenster weiterverfolgen möchte, soll denselben Kontext vorfinden. Das ist die eigentliche Designentscheidung des Projekts, nicht die Modellauswahl.

Adressiert wird damit ein Arbeitsablauf, der zwischen Beobachtung und Konzentration schwankt. Die Desktop-Oberfläche dient laut README dem Beobachten, Prüfen und Steuern eines laufenden Vorgangs. Das Terminal ist für diejenigen gedacht, die mit der Tastatur arbeiten und den Zwischenstand nicht in einem Fenster mitverfolgen wollen. Beide Gruppen arbeiten an denselben Dateien und demselben Plan. Das Projekt richtet sich damit an Einzelpersonen und kleine Teams, die Coding, Dokumentenarbeit und wiederkehrende Automatisierung nicht über drei verschiedene Werkzeuge verteilen wollen.

Zwei Modi, ein Aufgabenkontext

Kun organisiert die Arbeit in zwei Hauptmodi. Code deckt Softwarelieferung ab: Projektkontext, Dateibearbeitung, Terminal, Git und Worktree, Diff, Tests und Review. Work deckt Schreiben und Dokumentenarbeit ab: Markdown bearbeiten, PDF- und Office-Dateien lesen und analysieren, Tabellen auswerten und aus einer Gliederung Präsentationen erzeugen. Wichtig ist die Einschränkung im README: Office-Dateien bleiben schreibgeschützt. Wer also eine vorhandene .docx direkt aus dem Agent heraus ändern will, sollte das nicht erwarten.

Bemerkenswerter ist die Verzahnung von Design und Code. Der Design-Bereich ist keine separate Anwendung, sondern eine Leinwand innerhalb derselben Code-Aufgabe. Dort entstehen Prototypen, ein Designsystem und der Kontext für den Übergang von Design zu Code. Der dokumentierte Ablauf lautet: Ziel klären, Plan bilden, ausführen und zusammenarbeiten, Belege prüfen, ausliefern oder fortsetzen. Pläne und Anforderungen sollen standardmäßig im Projekt gespeichert werden, sodass sie in Versionskontrolle und Review landen können. Diese Entscheidung ist praktisch relevant: Sie macht den Planungsstand zu einem Artefakt im Repository und nicht zu einem flüchtigen Chatverlauf.

Lokal zuerst, aber nicht offline

Das README ist an dieser Stelle ehrlicher als viele vergleichbare Projekte. Sitzungen, Einstellungen, Protokolle und Laufzeitdaten liegen standardmäßig auf dem Rechner. Sobald jedoch ein Cloud-Modell ausgewählt wird, gehen Prompts, Anhänge und Aufgabenkontext an den jeweiligen Anbieter. Das ist keine Nebenbemerkung, sondern der zentrale Vorbehalt gegenüber dem Schlagwort lokal-first. Die Datenhoheit gilt für die Speicherung, nicht für die Verarbeitung.

Das Projekt bindet sich nicht an einen Anbieter. Genannt werden unter anderem ChatGPT und Codex, Claude, Gemini, Cursor, Ollama, DeepSeek, Kimi, GLM, Qwen, MiniMax und Xiaomi MiMo. Entscheidend ist der Nachsatz im README: Anmeldeverfahren, verfügbare Modelle, Regionen und Kontingente hängen von der jeweiligen Version und den Regeln des Anbieters ab. Die Liste ist also keine Zusage, dass jeder dieser Wege in jeder Installation funktioniert. Die Konfiguration läuft über einen Provider-Begriff, dokumentiert in docs/model-provider-presets.md. Wer ein selbst gehostetes Modell über Ollama betreiben will, findet dort den vorgesehenen Weg.

Installation und die TUI-Änderung ab 0.3.8

Für die Nutzung ohne eigenen Build verweist das README auf die GitHub-Releases mit .dmg und .zip für macOS auf Apple Silicon und Intel, .exe für Windows x64 sowie .AppImage und .deb für Linux x64. Nach dem Start sind drei Schritte dokumentiert: Sprache wählen und einen Provider konfigurieren, ein lokales Projekt öffnen oder einen Arbeitsbereich anlegen, dann eine klar abgegrenzte und überprüfbare Aufgabe senden. Der letzte Punkt ist keine Höflichkeitsformel. Ein Agent, der Dateien ändert und Tests ausführt, arbeitet umso nachvollziehbarer, je enger die Aufgabe gefasst ist.

Für den Terminal-Client gibt es eine Änderung, die man leicht übersieht. Ab Version 0.3.8 wird kein separates TUI-Archiv mehr verteilt. Stattdessen nutzt man den im Desktop-Paket enthaltenen Befehl und startet ihn im Projektverzeichnis mit `kun`. Wer bisher ein eigenständiges TUI-Paket bezogen hat, muss seinen Bezugsweg also umstellen. Details stehen in docs/kun-tui.md.

Für einen Build aus dem Quellcode nennt das README Node.js 22.19 oder neuer, npm und mindestens eine funktionierende Modellverbindung. Der Ablauf ist `git clone`, `cd Kun`, `npm ci`, `npm run dev`. Für langsame Netze in China gibt es den Hinweis, `npm ci --registry=https://registry.npmmirror.com` zu verwenden. Die verfügbaren Skripte umfassen `npm run dev:tui`, `npm run typecheck`, `npm run lint`, `npm run test`, `npm run build` sowie `npm run dist:mac`, `dist:win` und `dist:linux`.

Automatisierung, Erweiterungen und der Preis der Offenheit

Wiederkehrende Abläufe lassen sich über Scheduled tasks, Loops, Hooks, MCP, Skills und installierbare Erweiterungen abbilden. Die zugehörigen Dokumente liegen unter docs/workflow-loop.md, docs/project-mcp-skills.md und docs/extensions/README.md. Das ist ein breites Angebot, und genau darin liegt eine Spannung: Ein Runtime, der Coding, Design, Schreiben, Tabellen, Präsentationen und Automatisierung abdeckt, muss in jedem dieser Bereiche gegen spezialisierte Werkzeuge bestehen. Für das Bearbeiten von Tabellen oder das Erzeugen von Präsentationen ist der Funktionsumfang eines dedizierten Büroprogramms naturgemäß nicht erreichbar, und das README verspricht das auch nicht.

Ein zweiter Punkt betrifft die Erweiterbarkeit. Installierbare Erweiterungen und MCP-Server erweitern nicht nur den Funktionsumfang, sondern auch die Angriffsfläche. Das README erklärt, dass Werkzeugberechtigungen, sensible Vorgänge und Erweiterungsrechte in der Oberfläche sichtbar gemacht werden und die Freigabe beim Nutzer liegt. Das ist der richtige Ansatz, verlagert die Verantwortung aber vollständig auf die Person vor dem Bildschirm. Wer Erweiterungen aus unbekannter Quelle einbindet, hat keine technische Garantie, dass deren Werkzeuge sich auf den vorgesehenen Bereich beschränken. Aus dem vorliegenden Material geht nicht hervor, ob es eine Signaturprüfung, eine Sandbox oder eine Rechtebeschränkung pro Erweiterung gibt.

Wenn Kun das falsche Werkzeug ist

Der deutlichste Ausschlussgrund steht in der Lizenz. Kun verwendet die PolyForm Noncommercial License 1.0.0, die laut README ausschließlich Lernen, Forschung und nichtkommerzielle Nutzung erlaubt. Kommerzielle Nutzung, kommerzielle Weitergabe, SaaS- oder Hosting-Angebote, Weiterverkauf und die Integration in kommerzielle Produkte benötigen eine separate schriftliche Genehmigung des Autors. Für ein Unternehmen, das einen Agenten in eine interne kostenpflichtige Plattform einbetten will, ist das ein Ausschlusskriterium, solange diese Genehmigung nicht vorliegt. Der Repository-Status meldet die Lizenz als NOASSERTION, das README benennt sie dagegen konkret. Diese Abweichung sollte man vor jeder Entscheidung selbst im LICENSE- und CLA-Verzeichnis prüfen.

Ein zweiter Grenzfall ist die Plattformbindung. Die Desktop-Anwendung basiert auf Electron, was den Ressourcenverbrauch im Vergleich zu einem reinen Terminal-Client erhöht. Wer ausschließlich im Terminal arbeiten will, trägt diesen Ballast mit, seit ab 0.3.8 kein separates TUI-Paket mehr verteilt wird. Und wer eine vollständig offline arbeitende Installation mit lokalen Modellen über Ollama betreibt, verliert den Vorteil der großen Cloud-Modelle, die das Projekt in seiner Provider-Liste anführt.

Als Alternative bietet sich ein Terminal-zentrierter Agent wie Aider an. Der Unterschied liegt im Ansatz, nicht im Funktionsumfang: Aider arbeitet direkt im Repository und committet Änderungen in Git, ohne Desktop-Oberfläche und ohne Design-Leinwand. Kun setzt dagegen auf einen gemeinsamen Runtime mit zwei Oberflächen und auf einen Planungs- und Freigabeprozess, der sichtbar neben der Aufgabe liegt. Wer einen schlanken, in Git eingebetteten Ablauf will, ist bei Aider besser aufgehoben. Wer den Zustand einer lang laufenden Aufgabe über Oberflächen hinweg behalten will, findet bei Kun das passendere Modell.

Pflegeaufwand und Versionsrhythmus

Die Release-Historie zeigt einen kurzen Abstand: v0.3.7 am 28. August 2026, v0.3.8 und v0.3.9 am 6. September 2026. Zwei Releases am selben Tag deuten auf schnelle Korrekturen hin. Für Betreiber bedeutet das, dass die Versionsnummer klein ist und sich Verhalten zwischen Minor-Versionen ändern kann. Das TUI-Paket ist dafür ein konkretes Beispiel: eine Bezugsquelle fiel zwischen 0.3.7 und 0.3.8 weg. Wer Kun produktiv einsetzt, sollte die Release-Notes vor jedem Upgrade lesen, statt automatisch zu aktualisieren.

Für Beiträge nennt das README den Branch `develop` als täglichen Integrationszweig, Pull Requests sollen dorthin zielen. Externe Beiträge erfordern die Annahme einer CLA. Das ist ein üblicher, aber nicht trivialer Schritt für Unternehmen, die eigene Änderungen einreichen wollen. Die Dokumentation liegt unter anderem in docs/DEVELOPMENT.zh-CN.md und docs/CONTRIBUTING.zh-CN.md.

Ein Hinweis zur Herkunft: Das README erklärt, die Speicherarchitektur orientiere sich an öffentlich dokumentierten Ideen aus Nowledge Mem, namentlich der Trennung von Thread und Memory, der Quellenverfolgung und hybrider Suche. Die Implementierung sei eigenständig. Wer die Speicherfunktion bewerten will, sollte daher die genannten Konzepte mit der tatsächlichen Umsetzung im Repository vergleichen und nicht allein der Beschreibung folgen.

Redaktionelles Fazit

Für Einzelpersonen, Forschung und nichtkommerzielle Projekte ist Kun dann sinnvoll, wenn ein gemeinsamer Runtime für Desktop und Terminal gebraucht wird und die Datenhoheit im Vordergrund steht. Wer das Ergebnis in ein Produkt einbetten oder als Dienst betreiben will, sollte vorher die Lizenzfrage klären, denn PolyForm Noncommercial 1.0.0 verlangt dafür eine separate schriftliche Genehmigung. Vor dem Einsatz lohnt ein Blick in docs/model-provider-presets.md, um zu prüfen, ob der gewünschte Provider in der installierten Version enthalten ist.

Offizielle Quellen

1. Issues
2. KunAgent/Kun on GitHub
3. Project website
4. README
5. Releases