Clive kann sich jetzt selbst verändern

Wir bauen clive, ein CLI Live Environment, das einem LLM ein Terminal und eine Tastatur gibt. Die Grundidee ist einfach: Statt Tools in APIs und Schemas zu verpacken, lässt man den Agenten den Bildschirm lesen und tippen. Das Terminal wird zur Schnittstelle. Der Loop wird zum Protokoll. Jetzt haben wir etwas ergänzt, das diese Idee zu Ende denkt: clive kann seinen eigenen Code ändern.

Was clive ist

Zuerst kurz zur Erinnerung, wie clive funktioniert.

clive führt ein LLM in einer tmux-Session aus. Der Loop:

1. Agent reads the current terminal screen
2. Agent decides what to type
3. Agent sends a command via XML tag
4. Tool executes, produces output
5. Repeat

Jedes Tool (Browser, E-Mail-Client, Kalender, Datenverarbeitung) läuft in einem eigenen, benannten tmux-Pane. Der Agent sieht sie alle, entscheidet, mit welchem er arbeitet, und leitet die Befehle über einen Session Manager weiter. Große Inhalte umgehen das Terminal komplett über einen Dateikanal. So entstehen die Scrollback- und Token-Probleme gar nicht erst, an denen die meisten terminalbasierten Agenten-Setups scheitern. Die Überlegung hinter dem Design: LLMs können ausgezeichnet Text lesen und darüber nachdenken. CLI-Tools erzeugen Text. Das Terminal ist bereits eine persistente, zustandsbehaftete und beobachtbare Umgebung. Statt also Übersetzungsschichten zwischen Agenten und Tools zu bauen (MCP-Server, REST-Wrapper, Schema-Definitionen), gibt man dem Agenten einfach ein Terminal. Er liest, was dort steht, denkt darüber nach und antwortet. Ändert ein Tool sein Ausgabeformat, passt sich der Agent an. Ein fragiles Schema-Mapping muss niemand pflegen.

Das Problem mit der Selbstmodifikation

Irgendwann fangen Nutzer ganz von selbst an zu fragen: „Bau Unterstützung für dieses Tool ein.“ „Behebe diesen Fehler.“ „Ändere, wie du zusammenfasst.“

Einen Agenten seine eigenen Dateien bearbeiten zu lassen, ist wirklich gefährlich. Die offensichtlichen Risiken: Der Agent könnte seine eigenen Sicherheitsvorgaben aufweichen, Zugangsdaten nach außen schleusen, Netzwerkaufrufe einbauen, die über Sessions hinweg bestehen bleiben, oder sich schlicht so kaputt machen, dass er nicht mehr startet. Und für Nutzer ohne technischen Hintergrund ist eine kaputte Installation ohne erkennbaren Weg zurück schlimmer als gar kein Feature. Der naive Ansatz (den Agenten einfach Dateien bearbeiten lassen) scheitert an all dem. Richtig ist eine abgesicherte Pipeline, deren Regeln hart durchgesetzt werden, und zwar nicht von einem LLM.

Die Architektur der Selbstmodifikation

Die wichtigste Strukturentscheidung: clive wird in einen Runner und einen Workspace aufgeteilt.

Der Runner ist der stabile Einstiegspunkt. Er setzt die Richtlinien durch, ihm gehört der Rollback-Mechanismus, und der Agent kann ihn nicht verändern. Niemals. Er ist der Teil, der eine missglückte Änderung überlebt.

Im Workspace finden die Änderungen statt. Er ist ein von der aktiven Version isolierter git-Worktree, der für jede Änderungsanfrage neu angelegt wird:

.clive/worktrees/change-<timestamp>/

Jede Änderung ist ein Unified Diff, der auf den Workspace angewendet wird, nie auf den laufenden Code. Der Agent greift nie direkt in die laufende Version ein.

Die Pipeline

Wenn jemand clive selfmod "add support for tool X" ausführt, passiert Folgendes:

1. Plan: Der Agent erstellt eine Beschreibung der Änderung: welche Dateien, welche Absicht, welche Risiken.

2. Patch: Der Agent erzeugt einen Unified Diff. Das Policy Gate prüft ihn: Berührt er nur erlaubte Dateien? Bleibt er innerhalb des Workspace? Versucht er, den Runner, das Policy Gate selbst oder Zugangsdaten zu verändern?

3. Test: Die Prüf-Pipeline läuft automatisch. Unit-Tests, falls vorhanden. Lint und Typecheck. Ein Smoke Test: clive startet in einer frischen tmux-Session mit einer minimalen Aufgabe, und die Pipeline bestätigt, dass clive sie abschließt.

4. Explain: Der Nutzer sieht, was sich geändert hat, warum, welche Risiken erkannt wurden und wie er die Änderung rückgängig macht. Das Ganze erscheint als Diffstat plus Zusammenfassung in einfacher Sprache.

5. Apply? Dafür braucht es eine ausdrückliche Bestätigung. Nichts wird stillschweigend angewendet.

6. Promote: Nach der Freigabe entsteht ein Snapshot des letzten funktionierenden Stands, die Änderungen aus dem Workspace werden aktiv geschaltet, und clive startet sauber neu.

7. Rollback: clive undo führt jederzeit zurück zum letzten funktionierenden Stand und startet neu, auch nach einer missglückten Anwendung. Das klappt selbst dann, wenn die aktuelle Version abstürzt.

Das Policy Gate

Das Policy Gate ist die wichtigste Komponente und die, an die das LLM nicht herankommt. Es ist ein Modul ohne LLM, also deterministischer Code, und setzt harte Regeln durch, egal was der Agent produziert:

• Path Jail: keine Lese- oder Schreibzugriffe außerhalb des Workspace-Stammverzeichnisses
• Geschützte Dateien: das Policy Gate selbst, das Rollback-System und die Dateien mit Zugangsdaten sind unveränderlich
• Befehls-Allowlist: git-Operationen, Test-Runner und Linter sind erlaubt. curl, wget, ssh, Paketinstaller und destruktive Dateisystem-Operationen sind standardmäßig blockiert
• Capability-Modell: EDIT_PLUGIN und RUN_TESTS sind standardmäßig eingeschaltet. EDIT_CORE, NETWORK und INSTALL_DEPS sind ausgeschaltet

Das LLM kann vorschlagen, was es will. Was durchgeht, entscheidet das Gate.

Safe Mode

Noch ein Sicherheitsventil: clive safe-mode startet clive mit deaktiviertem selfmod, deaktivierten Plugins und einem minimalen Satz an Tools. Das ist der Weg zurück, wenn etwas schiefgeht, das clive undo nicht beheben kann. Auch Nutzer ohne technischen Hintergrund erreichen ihn mit einem einzigen Befehl, ohne verstehen zu müssen, was schiefgegangen ist.

Warum das wichtig ist

Selbstmodifikation ist mehr als ein Feature. Sie macht clive zu einem lebenden System statt zu einem statischen Tool. Die meiste Agenten-Infrastruktur ist ab dem Deployment eingefroren. Die Tools sind, was sie sind. Das Schema ist, was es ist. Passt etwas nicht, muss es ein Entwickler aktualisieren. Das Design von clive (Terminal als Schnittstelle, Text als Protokoll) bedeutet, dass der Agent über jedes Tool nachdenken kann, auf das er stößt. Selbstmodifikation richtet dieses Prinzip nach innen: Der Agent kann über sich selbst nachdenken und Verbesserungen vorschlagen, und die Entscheidung, was davon angewendet wird, bleibt beim Menschen. Der Pipeline-Ansatz (Plan → Patch → Test → Explain → Apply → Rollback) macht das sicher genug, um es Nutzern ohne technischen Hintergrund in die Hand zu geben. Sie müssen weder git noch Diffs verstehen, um clive um eine Verbesserung zu bitten und sie rückgängig zu machen, wenn etwas kaputtgeht.

Der Code liegt auf github.com/ikangai/clive.

Aus dem Englischen übersetzt: zum Originalbeitrag