rappidAI Replay. Jeden Lauf verstehen.
Replay ist ein lokal ausgerichteter Recorder und eine Zustands-Engine für Läufe von KI-Agenten. Der deterministische Kern funktioniert ohne KI. Er ist darauf ausgelegt, technische Ausführungen prüfbar, wiederherstellbar, verzweigbar und vergleichbar zu machen.
- 01CLI-/API-Schicht
- 02Session- und Ereignisdienste
- 03Generic Recorder + Adapter
- 04Event-Bus + Zustands-Engine
- 05SQLite-Metadaten und Indizes
- 06Inhaltsadressierter Zustandsspeicher
- 07Optionale Intelligence-Schicht (nur lesend)
Aktuell
Was derzeit implementiert ist.
- Generische Aufzeichnung von Ausführungen; erfasst werden Befehl, Prozesse und Workspace.
- Überprüfung aufgezeichneter Zustände.
- Verifizierte Wiederherstellung in einen Staging-Verzeichnisbaum.
- Verzweigen aus früheren Zuständen, mit ausdrücklicher Zustimmung zur erneuten Live-Ausführung.
- Erneute Live-Ausführung nach ausdrücklicher Zustimmung. Die Modi Recorded, Controlled und Hybrid sind nicht implementiert.
- Deterministischer Replay-Vergleich über mehrere Dimensionen.
Designprinzipien
Die Architektur trennt Belege von ihrer Deutung.
- 01
Der deterministische Kern ist auch ohne KI vollständig.
- 02
Der Generic Recorder bleibt Pflicht. Adapter dürfen die Aufzeichnung anreichern, sie aber nie von sich abhängig machen.
- 03
Watcher-Ereignisse stoßen einen Abgleich an, sind aber nicht die maßgebliche Wahrheit.
- 04
Finale Checkpoints, abgeglichene Dateiereignisse und der Merkle-Zustand bilden zusammen die technische Quelle der Wahrheit.
- 05
Wiedergabe und erneute Ausführung sind getrennte Konzepte: Die Wiedergabe liest gespeicherte Nachweise, die erneute Ausführung führt Code aus.
Stufen der Reproduzierbarkeit
Reproduzierbarkeit ist eine Stufenleiter, keine Ja-oder-Nein-Frage.
R0–R4 legt in der Architektur verbindlich fest, wie die erreichte Reproduzierbarkeit beschrieben wird. Diese Seite behauptet nicht, dass heute jede Stufe für jede Session vollständig implementiert ist.
R0
Prüfbar
R1
Wiederherstellbar
R2
Erneut ausführbar
R3
Kontrollierte externe I/O
R4
Containerisiert / vollständig erfasst
Architektur
Architektur für Zustände und Speicherung.
Erkenntnisse aus der Entwicklung.
- Eine zuverlässige Wiederherstellung braucht ein eigenes Zustandsmodell; Terminal-Logs allein reichen nicht.
- Inhaltsadressierte Speicherung und rekursive Zustandsbäume machen die Identität von Zuständen explizit und erlauben Deduplizierung.
- Ein Dateisystem-Watcher allein kann nicht die Quelle der Wahrheit sein; Abgleich und Checkpoints sind nötig.
- Die Wiedergabe einer Aufzeichnung sollte nie unbemerkt Code ausführen oder auf das Netzwerk zugreifen.
- Adapter sind eine reine Ergänzung, damit die Reproduzierbarkeit nicht von einer bestimmten IDE oder einem einzelnen Agentenanbieter abhängt.
Geplant / Architekturziel
Architekturziele – nicht zu verwechseln mit dem, was heute implementiert ist.
- Portables .rplay-Paket für Export und Import
- Vollständiges Kassetten-Ökosystem für externe I/O
- Vollständige lokale Benutzeroberfläche
- Optionaler lokaler Intelligence-Sidecar
- Breitere Abdeckung durch Adapter und weitere Härtung
Aktuelle CLI-Befehle.
rappid replay record -- <command>
rappid replay verify <state-id>
rappid replay restore <state-id>
rappid replay branch <state-id>
rappid replay rerun --mode live --confirm-execution <state-id> -- <command>
rappid replay diff <left-session-id> <right-session-id>Für wen Replay gedacht ist.
Für Entwickler und Forschende, die autonome Agenten debuggen, Ausführungspfade vergleichen, Fehler reproduzieren und Änderungen an Agenten testen – und lokal prüfbare Nachweise darüber sichern wollen, was ein Lauf verändert hat.
Geprüfte Architektur und Quellen