2026 DEEPSEEK HARNESS
JSONL oder SQLite für Sitzungen?

Sitzungen lassen sich zwar öffnen, aber nach einem Absturz fehlen die letzten Ereignisse oder die Sicherung ist nicht eindeutig prüfbar. Die schnellste Entscheidung lautet: Für Einzelbetrieb, kurze Tests und einfache Einzeldatei-Backups zuerst JSONL validieren; für strukturierte Abfragen SQLite nur auf zuverlässigem lokalem Speicher einsetzen und WAL auf Netzlaufwerken erst nach einem eigenen Wiederherstellungstest freigeben.

Diese Anleitung richtet sich an Sie, wenn Sie DeepSeek Harness-Sitzungen über längere Zeit aufbewahren, auf einem lokalen oder Cloud-Mac von MACGPU betreiben oder einen standardisierten Übergabe- und Wiederherstellungsprozess für ein Team definieren. Wenn Sie lediglich einen kurzen Einmaltest ausführen und keine Sitzung wiederaufnehmen müssen, benötigen Sie keine komplexe Datenbankentscheidung.

Die Entscheidung nach Betriebsfall treffen

Die zentrale Frage ist nicht, ob JSONL „einfacher“ oder SQLite „professioneller“ klingt. Entscheidend sind Schreibmuster, Abfragebedarf, Datenträger und die Verantwortung nach einem Fehler. DeepSeek Harness befindet sich laut offizieller Repository-Dokumentation weiterhin in der Entwickler-Vorschau; ausdrücklich wird vor inkompatiblen Änderungen gewarnt. Deshalb sollten Sie weder ein Format als dauerhaft stabil annehmen noch eine Migration ohne dokumentierten Rückweg durchführen. (github.com)

<

Entscheidungskriterium	JSONL	SQLite
Einzelne Sitzung prüfen	Sehr gut: Textdatei zeilenweise lesbar	Eingeschränkt: Werkzeug oder Export erforderlich
Einzeldatei-Backup	Einfach, sofern Schreibvorgang beendet ist	Nur sicher mit konsistentem Datenbank-Backup
Viele Sitzungen durchsuchen	Zusätzliche Indizes oder Skripte notwendig	Sehr gut mit SQL und abgeleiteten Indizes
Kontinuierliches Anhängen	Gut, wenn unvollständige Schlusszeilen toleriert werden	Gut bei lokalem Datenträger und korrekter Transaktionsbehandlung
Wiederherstellung nach Prozessabbruch	Letzte vollständige Ereignisse müssen geprüft werden	Journal-, WAL- und Sperrstatus müssen geprüft werden
Netzwerkdateisystem	Einfacher zu transportieren, aber nicht automatisch sicher	Kritisch; WAL und Sperren müssen konkret validiert werden
Migrationsrisiko in der Vorschau	Zeilen können einzeln inspiziert und transformiert werden	Schema- und Versionsabhängigkeiten können stärker ausfallen
Typischer Einsatz	Einzelentwickler, Archiv, Export, kleine Sitzungszahl	Teamabfragen, Auditfilter, viele Ereignisse, lokale Datenbank

**Bewertung für die Praxis:**

• JSONL erhält 5 von 5 Punkten, wenn Ihre wichtigste Anforderung lautet: „Ich muss jede Sitzung einzeln kopieren, lesen und notfalls manuell prüfen können.“
• SQLite erhält 5 von 5 Punkten, wenn Sie nach Projekten, Ereignistypen, Zeitfenstern oder Sitzungsstatus filtern müssen und die Datenbank auf einem lokalen Dateisystem liegt.
• Netzwerkbetrieb erhält für SQLite zunächst 1 von 5 Punkten, solange Sperren, WAL, SHM-Datei und Wiederherstellung nicht auf genau diesem Speicher getestet wurden.
• Ein Wechsel des Backends erhält 0 von 5 Punkten, wenn Sie nur das Vorhandensein neuer Dateien kontrollieren, aber keine Sitzung öffnen, durchsuchen und fortsetzen.

Die Tabelle ist damit kein allgemeiner Qualitätsvergleich. Sie ist eine Rückfallregel: Erfüllt Ihr Einsatz die lokalen SQLite-Bedingungen nicht, bleibt JSONL oder ein lokaler SQLite-Datenträger die bessere Ausgangsbasis.

Den einfachen Einzelbetrieb mit JSONL beginnen

Für eine einzelne Person, eine überschaubare Sitzungszahl und kurzfristige Erprobung ist JSONL häufig der schnellere erste Prüfpunkt. Der Vorteil liegt nicht in einer behaupteten höheren Zuverlässigkeit, sondern in der Sichtbarkeit: Sie können den Sitzungsordner kopieren, die Datei mit Standardwerkzeugen untersuchen und beschädigte Schlussbereiche leichter erkennen als in einer Datenbankdatei.

Prüfen Sie dabei vier Dinge:

1. Effektives Sitzungsstammverzeichnis: Lesen Sie aus der tatsächlich geladenen Konfiguration, wohin DeepSeek Harness schreibt. Raten Sie nicht anhand von Beispielen aus einer älteren Version.
2. Physische Kodierung: Kontrollieren Sie, ob die Datei als erwarteter Text geöffnet werden kann und ob Sonderzeichen, Zeilenumbrüche und lange Tool-Ausgaben unverändert erscheinen.
3. Lesbarkeit nach Prozessende: Beenden Sie den Prozess regulär und öffnen Sie die Datei anschließend unabhängig vom laufenden Harness.
4. Minimale Wiederherstellung: Kopieren Sie genau eine Sitzung in ein leeres Testverzeichnis, starten Sie DeepSeek Harness mit dieser Kopie und prüfen Sie, ob die Sitzung nicht nur gelistet, sondern auch fortgesetzt werden kann.

Das ist der entscheidende Unterschied zwischen „Datei wurde erzeugt“ und „Sitzung ist wiederherstellbar“. Bei einem append-only-artigen JSONL-Verfahren kann ein Abbruch während des letzten Schreibvorgangs eine unvollständige Schlusszeile hinterlassen. Ein robuster Wiederherstellungsprozess muss diese Zeile entweder sicher ignorieren, markieren oder reparieren, ohne frühere Ereignisse zu verändern.

**Achtung:** Eine Sicherung während eines laufenden Agent-Laufs ist keine automatisch konsistente Sicherung. Kopieren Sie JSONL erst nach einem kontrollierten Prozessende oder dokumentieren Sie ausdrücklich, dass die letzte Zeile unvollständig sein kann.

Wenn Sie Sitzungen auf einem Cloud-Mac verwalten, trennen Sie außerdem drei Ebenen: die eigentliche Sitzung, Konfigurationsdateien und Geheimnisse. Ein JSONL-Backup kann den Gesprächsverlauf enthalten, aber nicht automatisch die Konfiguration, den verwendeten Harness-Stand oder die Zugangsdaten. Für DSGVO-konforme Übergaben sollten API-Schlüssel und persönliche Inhalte getrennt behandelt, verschlüsselt übertragen und nicht gemeinsam mit dem Sitzungsarchiv in einem ungeschützten Ordner abgelegt werden.

Dauerhafte Agent-Läufe anhand von Unterbrechungen bewerten

Bei einem langfristigen Agent-Lauf ist die Schreibstrategie wichtiger als der Dateiname. Ein System kann JSONL verwenden und trotzdem bei einem Prozessabbruch unbrauchbar sein; umgekehrt kann SQLite stabil laufen, aber bei einer fehlerhaften Sicherung eine nicht konsistente Kopie hinterlassen.

Führen Sie deshalb eine feste Unterbrechungssequenz aus:

1. Starten Sie eine repräsentative Sitzung mit mindestens einem Tool-Aufruf und einer sichtbaren Antwort.
2. Beenden Sie den Prozess kontrolliert und notieren Sie den letzten erwarteten Ereignistyp.
3. Starten Sie DeepSeek Harness erneut und prüfen Sie die Sitzungsliste.
4. Öffnen Sie dieselbe Sitzung und vergleichen Sie die letzte Antwort, den letzten Tool-Status und die Fortsetzungsposition.
5. Wiederholen Sie den Test mit einem harten Prozessabbruch, nicht nur mit dem normalen Beenden.
6. Starten Sie den Mac oder die Remote-Umgebung neu und führen Sie die Wiederaufnahme nochmals aus.

Bei JSONL genügt es nicht, nur die Anzahl der Zeilen zu vergleichen. Prüfen Sie, ob jede relevante Zeile gültig geparst wird, ob Rollen und Ereignistypen erhalten bleiben und ob eine Wiederaufnahme nicht stillschweigend eine neue Sitzung erzeugt. Bei SQLite müssen Sie zusätzlich feststellen, ob die Datenbank nach dem Neustart geöffnet werden kann und ob der letzte Commit sichtbar ist.

Die offizielle Dokumentation des Projekts weist auf den Vorschaucharakter und mögliche Kompatibilitätsbrüche hin. Das bedeutet für Ihr Runbook: Eine bestandene Wiederherstellung am 19.08.2026 ist ein Umgebungsnachweis für die geprüfte Version, aber keine Zusage für jede spätere Version. (github.com)

Strukturierte Abfragen mit SQLite getrennt von der Speicherung planen

SQLite wird interessant, sobald Sie nicht mehr nur „Sitzung Nummer drei öffnen“, sondern Fragen wie diese beantworten müssen:

• Welche Sitzungen haben in einem bestimmten Zeitraum einen bestimmten Tool-Aufruf enthalten?
• Welche Projekte wurden nach einem Fehler fortgesetzt?
• Welche Agent-Läufe warten noch auf eine Antwort?
• Welche Ereignisse müssen für einen Auditbericht exportiert werden?

Für solche Aufgaben reduziert SQLite den Bedarf an wiederholten Vollscans. Sie können Sitzungsmetadaten, Zeitstempel und Ereignistypen strukturiert filtern. Das ist ein echter organisatorischer Vorteil für Plattformteams, aber noch kein Grund, jede JSONL-Datei sofort in eine Datenbank zu überführen.

Unterscheiden Sie sauber zwischen:

• Sitzungspersistenz: Das primäre Format, in dem DeepSeek Harness Ereignisse und Wiederaufnahmeinformationen ablegt.
• Abgeleitetem Suchindex: Eine zusätzliche Datenbank oder Indexdatei, die aus den Sitzungen aufgebaut wird und bei Bedarf neu erzeugt werden kann.
• Dateisicherung: Eine Kopie oder ein Export zur Wiederherstellung, nicht automatisch ein Suchsystem.

Ein sinnvoller Mittelweg ist daher, die primäre Speicherung zunächst unverändert zu lassen und einen abgeleiteten SQLite-Index für Such- und Auditfunktionen aufzubauen. Fällt der Index aus, rekonstruieren Sie ihn aus den Primärdaten. Wird dagegen die Primärdatenbank selbst als alleinige Quelle verwendet, müssen Schema, Journaldateien, Version und Sicherungsmethode gemeinsam dokumentiert werden.

Der offizielle Projektstand nennt SQLite- und JSONL-Konfigurationen als verfügbare Persistenzwege. Da DeepSeek Harness jedoch noch als Entwickler-Vorschau geführt wird, sollten Sie Konfigurationsschlüssel, Default-Verhalten und Speicherformat vor jedem Versionswechsel erneut im offiziellen Konfigurationsstand prüfen. (github.com)

WAL und Netzlaufwerke nicht aus dem Bauch heraus freigeben

SQLite WAL ist für lokale Anwendungsfälle nützlich, weil Schreibvorgänge zunächst in eine Write-Ahead-Log-Datei gelangen und Leser unter bestimmten Bedingungen parallel arbeiten können. Die SQLite-Dokumentation erklärt jedoch ausdrücklich, dass WAL gemeinsame Speicherprimitive voraussetzt. Wenn das Dateisystem diese nicht unterstützt, kann der Wechsel in den WAL-Modus scheitern oder in einen anderen Journalmodus zurückfallen. (sqlite.org)

Zusätzlich existieren neben der Datenbank typischerweise eine WAL-Datei und eine gemeinsame Speicherdatei. Diese Dateien dürfen bei einer einfachen Datei-für-Datei-Kopie nicht als nebensächlich behandelt werden. Eine Kopie der Hauptdatei ohne einen konsistenten Zustand der Journalinformationen kann ältere Daten enthalten oder den zuletzt geschriebenen Zustand nicht abbilden.

Testen Sie ein Netzlaufwerk daher in dieser Reihenfolge:

1. Legen Sie eine leere Testdatenbank auf dem konkreten Mount an.
2. Prüfen Sie, welchen Journalmodus SQLite tatsächlich meldet.
3. Starten Sie zwei parallele Schreib- und Leseprozesse.
4. Unterbrechen Sie einen Schreibprozess während einer Transaktion.
5. Trennen Sie den Mount oder simulieren Sie einen Verbindungsverlust.
6. Öffnen Sie die Datenbank nach der Wiederverbindung und prüfen Sie Integrität und erwartete Datensätze.
7. Erstellen Sie danach einen kontrollierten Backup-Export und stellen Sie diesen in einem leeren Verzeichnis wieder her.

Die SQLite-Dokumentation nennt außerdem einen automatischen Checkpoint, wenn die WAL-Datei 1.000 Seiten erreicht oder die letzte Verbindung geschlossen wird. Dieser Wert ist eine dokumentierte Standardbedingung, aber kein Versprechen über die Größe Ihrer Sitzungsdateien oder über die Latenz Ihres Speichers. ([sqlite.org](https://www.sqlite.org/wal.html?utm_source=openai))

**Erfahrung aus dem Betrieb:** Wenn ein Netzlaufwerk nur deshalb gewählt wird, weil der Cloud-Mac keinen lokalen Speicherbereich für Sitzungen erhalten soll, ist das häufig die falsche Abstraktion. Geben Sie der Datenbank lokalen Speicher und liefern Sie anschließend signierte oder verschlüsselte Backups aus, statt eine aktive WAL-Datenbank direkt auf einen ungetesteten Share zu legen.

Auf einem Cloud-Mac sollten Sie die Datenträgerklasse, Mount-Optionen und den Backup-Weg in der Betriebsdokumentation festhalten. Eine [M4-Konfiguration für einen Cloud-Mac](https://macgpu.com/de/m4-bestellen.html) kann für interaktive Agent-Läufe passend sein, sagt aber allein nichts über die Eignung eines Netzwerkdateisystems aus. Die Speicherentscheidung muss auf dem konkret bereitgestellten lokalen Datenträger und dem getesteten Übergabeprozess beruhen.

Migration mit lesbarem Rückweg durchführen

Ein Backend-Wechsel sollte nicht als einmaliger Kopiervorgang behandelt werden. Planen Sie ihn wie eine kleine Datenmigration mit Prüfpunkten und Rückfalloption:

1. Erfassen Sie Harness-Version, Commit oder Release, Betriebssystem, Sitzungsstammverzeichnis und aktiven Backend-Schlüssel.
2. Beenden Sie alle laufenden Agent-Prozesse kontrolliert.
3. Erstellen Sie ein unverändertes, schreibgeschütztes Archiv des alten Backends.
4. Wählen Sie eine kleine Stichprobe: eine kurze Sitzung, eine Tool-Sitzung, eine lange Sitzung und eine abgebrochene Sitzung.
5. Importieren oder konvertieren Sie nur diese Stichprobe in das neue Backend.
6. Vergleichen Sie Sitzungsidentität, Ereignisanzahl, Rollen, Zeitstempel, Tool-Ergebnisse und letzten Fortsetzungspunkt.
7. Öffnen Sie jede Stichprobensitzung und führen Sie mindestens eine Fortsetzung aus.
8. Lassen Sie den neuen Backend-Modus erst danach mit einer begrenzten Zahl neuer Sitzungen schreiben.
9. Bewahren Sie das alte Backend so lange auf, bis ein unabhängiger Restore-Test erfolgreich abgeschlossen ist.

Die Validierung muss mehr leisten als ein Dateivergleich. Bei JSONL-zu-SQLite-Migrationen kann die Reihenfolge zwar erhalten sein, während Suchfelder, Nullwerte oder Ereignistypen falsch abgebildet werden. Bei SQLite-zu-JSONL-Migrationen kann dagegen der Export lesbar sein, aber Informationen verlieren, die für die Wiederaufnahme erforderlich sind.

Vermerken Sie deshalb im Prüfprotokoll nicht nur „Import erfolgreich“, sondern auch:

• Sitzung lässt sich öffnen.
• Letzte Antwort stimmt mit dem Ausgangsbestand überein.
• Tool-Ereignis ist vorhanden.
• Suche findet die erwarteten Ereignisse.
• Fortsetzung schreibt in das neue Backend.
• Altes Archiv bleibt unverändert lesbar.
• Rückfall auf die alte Konfiguration ist möglich.

Für Teams mit Remote-Umgebungen gehört außerdem die Lieferverantwortung in das Protokoll: Wer erstellt den Export, wer verschlüsselt ihn, wer prüft die Prüfsumme, wer darf ihn wieder einspielen und wie werden persönliche oder geheime Inhalte nach der Übergabe entfernt? Das ist besonders wichtig, wenn Sitzungen Quellcode, Pfade, interne Namen oder API-Antworten enthalten.

Eine regionale Cloud-Mac-Bereitstellung in Virginia kann die Latenz oder organisatorische Zuständigkeit beeinflussen, ersetzt aber keine Backend-Prüfung. Region, Hardware und Persistenzformat sind getrennte Entscheidungen.

Das belastbare Auswahlurteil für Ihren Fall

Wählen Sie JSONL, wenn Sie allein arbeiten, Sitzungen einzeln archivieren, den Inhalt mit Standardwerkzeugen kontrollieren und nur gelegentlich nach alten Ereignissen suchen. Besonders auf einem Cloud-Mac ist die einfache Dateiauslieferung ein Vorteil, solange Sie den Schreibvorgang vor dem Backup beenden und den Restore testen.

Wählen Sie SQLite auf lokalem Speicher, wenn mehrere Personen oder Prozesse Sitzungen nach Metadaten und Ereignissen durchsuchen, wenn Sie wiederkehrende Auditabfragen benötigen und wenn Sie eine konsistente Backup- und Restore-Methode für Datenbank, WAL und SHM dokumentieren können.

Wählen Sie nicht automatisch SQLite auf einem Netzlaufwerk, nur weil mehrere Macs auf dieselbe Datei zugreifen sollen. Ohne geprüfte Sperr- und Wiederherstellungssemantik wird aus der vermeintlichen Teamlösung ein zusätzlicher Fehlerbereich.

Für die meisten frühen DeepSeek-Harness-Installationen lautet die vernünftige Reihenfolge daher: JSONL oder lokales SQLite in einer isolierten Testumgebung, danach Unterbrechungs- und Restore-Nachweis, erst anschließend Teamabfragen oder Remote-Mounts. Da das Projekt laut offizieller Dokumentation weiterhin mit möglichen inkompatiblen Änderungen rechnet, sollten Sie die Entscheidung bei jedem Release erneut gegen Konfiguration und Wiederherstellung testen. (github.com)

Häufige Fragen zur Sitzungsspeicherung

Die folgenden Antworten sind als kurze Betriebsregeln gedacht und ersetzen nicht den Test auf Ihrer konkreten Version und Ihrem konkreten Datenträger.

Wenn Sie Ihre Auswahl getroffen haben, vergleichen Sie zuerst Aufgabenlaufzeit, Suchbedarf und Speicherort in der Entscheidungstabelle. Für eine Migration in eine entfernte Umgebung ist anschließend ein dokumentierter Cloud-Mac-Wiederherstellungs- und Übergabetest der passendere nächste Schritt als ein ungetesteter gemeinsamer Datenbankpfad.

Ein eigener Mac ist für dauerhaft hohe, planbare Last und den Bedarf an physischen Schnittstellen oft sinnvoller als eine Miete. Eine lokale Maschine bringt jedoch Beschaffung, Wartung, Ausfallvorsorge, Backup-Verantwortung und sichere Fernzugriffe mit sich. Ein Cloud-Mac ist dagegen besonders dann zweckmäßig, wenn Sie für eine begrenzte Agent-Phase, einen reproduzierbaren Migrationstest oder eine getrennte Abnahmeumgebung schnell eine Mac-Instanz benötigen. Für diesen Fall ist MACGPU die pragmatischere Option, sofern Sie Speicherort, Restore-Test und Datenübergabe vor Beginn schriftlich festlegen.