Ein gestarteter Python-Prozess verliert nach einem Neustart seinen Arbeitsstand, obwohl die Sitzungsdateien noch vorhanden sind.
Die schnellste Lösung: Erst eine isolierte Einzelaufgabe ausführen, danach SDK und Laufzeit festschreiben, session_root getrennt sichern und erst anschließend einen dauerhaft überwachten Prozess einrichten.
Zielgruppe und Betriebsgrenze
Dieser Leitfaden ist für Sie gedacht, wenn Sie DeepSeek Harness mit Python-Aufrufen automatisieren und nicht nur einmalig im Terminal testen möchten. Er passt besonders zu drei Rollen:
- Automatisierungsentwickler, die wiederholbare Codeaufgaben aus Python anstoßen;
- Plattformingenieure, die einen Cloud-Mac als dauerhaft verfügbaren Agent-Arbeitsplatz betreiben;
- Projektverantwortliche, die eine übergebene Umgebung auf Wiederherstellbarkeit prüfen müssen.
JSON-RPC übernehmen. Es ersetzt jedoch weder Ihre Prozessaufsicht noch Ihre Berechtigungs- und Backup-Regeln.
Der Status ist außerdem wichtig: Die offizielle Dokumentation führt den Python-Zugang als programmatische Alternative zur Weboberfläche und beschreibt eine vorgefertigte Laufzeit, die keine systemweite Node.js-Installation voraussetzt. macOS auf Apple-Silicon wird dabei als Zielplattform genannt. Der Entwicklungsstatus kann sich jedoch ändern; rechnen Sie bei einer Developer Preview mit inkompatiblen Änderungen. Prüfen Sie deshalb vor jeder Übergabe das offizielle DeepSeek-Harness-Repository und die dort verlinkte Python-SDK-Anleitung.
Betriebsmodell vor der Installation
Bevor Sie einen Cloud-Mac einrichten, legen Sie fest, ob Ihr Skript eine einmalige Aufgabe, einen periodischen Lauf oder einen langfristigen Agent-Prozess ausführt. Diese drei Modelle sehen ähnlich aus, haben aber unterschiedliche Anforderungen an Zustände und Wiederanlauf.
| Betriebsmodell | Arbeitsbereich | Sitzungsstrategie | Prozessverantwortung | Bewertung |
|---|---|---|---|---|
| Einmaliges Skript | Temporäres Test-Repository | Neue Sitzung je Lauf | Manuelles Starten und Prüfen | 5/5 für Ersttests |
| Periodischer Job | Separates Arbeitsverzeichnis je Auftrag | Neue Sitzung oder bewusst versionierte Sitzung | Scheduler, Timeout und Exit-Code | 4/5 für planbare Automatisierung |
| Dauerhafter Agent | Festes Repository mit klarer Zuständigkeit | Sitzung gezielt fortsetzen | Supervisor, Protokollierung, Wiederanlauf | 3/5 ohne zusätzliche Betriebslogik |
| Mehrere Projekte auf einem Host | Strikte Trennung pro Projekt | Niemals gemeinsame Sitzungskennung | Getrennte Benutzer- oder Prozessrechte | 2/5 bei fehlender Isolation |
- Zustandsvermischung: Ein gemeinsamer Sitzungsordner kann Gesprächsverlauf und persistente Bash-Zustände zwischen Projekten vermengen.
- Unklare Prozessgrenzen: Ein SSH-Abbruch beendet nicht zwingend den Prozess, während ein Prozessabbruch nicht automatisch eine Aufgabe sicher fortsetzt.
- Fehlende Beweiskette: Ohne Eingabe, Arbeitsbereich, Ergebnis und tatsächliche Dateiveränderung können Sie nicht unterscheiden, ob eine Aufgabe erfolgreich war oder nur ein plausibel aussehendes Ergebnis geliefert wurde.
Voraussetzungen und Auswahl des Cloud-Macs
Die Auswahl des Rechners sollte sich am Agent-Betrieb orientieren, nicht am Gedanken, dass das Sprachmodell lokal auf dem Mac ausgeführt wird. In diesem Szenario übernimmt der Cloud-Mac vor allem Arbeitsbereich, Tool-Aufrufe, Dateien, Shell-Prozesse und Sitzungszustand; die Modellkommunikation erfolgt über den konfigurierten Endpunkt.
Prüfen Sie in dieser Reihenfolge:
- Systemarchitektur: Stimmen die von der offiziellen SDK-Dokumentation unterstützte macOS-Architektur und die Architektur des bereitgestellten Rechners überein?
- Python-Version: Verwenden Sie die von der Dokumentation geforderte Python-Haupt- und Nebenversion, statt die globale Standardversion blind zu übernehmen.
- Netzwerkzugang: Kann der Rechner den Modell-Endpunkt und den Paketindex erreichen, ohne dass Sie unnötige eingehende Ports öffnen?
- Speicherort: Gibt es getrennte Verzeichnisse für Quellcode, Sitzungen, Logs und Backups?
- Berechtigungen: Läuft der Agent mit einem Benutzerkonto, das nur die für die Aufgabe erforderlichen Dateien verändern darf?
Falls Sie verschiedene Standorte und Bereitstellungsmodelle vergleichen, können Sie die verfügbaren Mac-Konfigurationen von MACGPU als Ausgangspunkt verwenden. Übernehmen Sie daraus aber nur tatsächlich veröffentlichte Angaben; die SDK-Mindestanforderungen stammen weiterhin aus der jeweiligen Projektdokumentation.
Isolierte Python-Umgebung
Legen Sie zunächst ein neutrales Verzeichnis an, das nicht Ihr Produktiv-Repository ist. Ein mögliches Layout sieht so aus:
~/agent-runs/deepseek-harness/
├── app/
├── test-repo/
├── sessions/
├── logs/
├── backups/
└── .venv/Die konkrete Pfadangabe ist kein SDK-Standard. Entscheidend ist, dass sessions/ nicht innerhalb des Git-Arbeitsbereichs liegt und dass logs/ nicht versehentlich mit Zugangsdaten oder vollständigen Prompt-Inhalten öffentlich archiviert wird.
Führen Sie die Installation in fünf kontrollierten Schritten aus:
- Erstellen Sie das Verzeichnis und wechseln Sie hinein.
- Erzeugen Sie eine eigene virtuelle Umgebung mit der zuvor geprüften Python-Version.
- Aktivieren Sie die Umgebung nur für die Installation und den Test, nicht als unkontrollierte globale Shell-Konfiguration.
- Installieren Sie das in der offiziellen Dokumentation genannte Paket für
deepseek-harness-sdkund die dazugehörige vorgefertigte Laufzeit in den dort angegebenen Versionen. - Speichern Sie anschließend Installationsquelle, Paketversion, Python-Version, macOS-Version und Architektur in einer Übergabedatei.
mkdir -p "$HOME/agent-runs/deepseek-harness"/{app,test-repo,sessions,logs,backups}
cd "$HOME/agent-runs/deepseek-harness"
python3 -m venv .venv
source .venv/bin/activate
python -m pip install --upgrade pip
python -m pip install deepseek-harness-sdk
python -m pip freeze > app/requirements.lock.txt
sw_vers > app/macos-version.txt
python --version > app/python-version.txt
uname -m > app/architecture.txtDas ist bewusst kein Produktionsrezept mit fest erfundenen Versionsnummern. Am 18.08.2026 müssen Sie die tatsächlich freigegebene Paketbezeichnung und die Laufzeitbindung aus dem offiziellen Repository übernehmen. Die Python-Dokumentation zu virtuellen Umgebungen beschreibt den verwendeten Isolationsmechanismus.
Braucht das Python SDK auf dem Mac Node.js?
Für die vorgefertigte Laufzeit ist laut Aufgabenrahmen keine systemweite Node.js-Installation erforderlich. Das bedeutet aber nicht, dass Node.js in jedem Installationsweg entbehrlich ist. Wenn Sie aus dem Quellcode bauen, ein Entwicklerpaket verwenden oder eine Laufzeit selbst zusammensetzen, können zusätzliche Build-Werkzeuge verlangt werden.
Prüfen Sie daher drei Fälle getrennt:
- Vorgefertigte Laufzeit: Node.js nicht global nachinstallieren, wenn das Paket die Laufzeit tatsächlich mitliefert.
- Quellcode-Build: Anforderungen aus dem Repository vollständig übernehmen; hier können Node.js, Paketmanager und Compiler relevant sein.
- Gemischte Umgebung: Nicht durch ein lokal vorhandenes Node.js kaschieren, dass Ihr Python-Prozess eine andere Runtime startet als die getestete.
Erste Aufgabe mit überprüfbarem Ergebnis
Verwenden Sie für den ersten End-to-End-Test ein wegwerfbares Repository. Es sollte keine Kundendaten, keine privaten Schlüssel und keine Produktionsabhängigkeiten enthalten. Der Test muss drei Ebenen getrennt prüfen:
- Modellantwort: Erzeugt das SDK eine Antwort und beendet die Sitzung kontrolliert?
- Dateioperation: Wird eine genau definierte Datei am erwarteten Ort erstellt oder verändert?
- Bash-Ausführung: Liefert ein ungefährlicher Shell-Befehl das erwartete Ergebnis?
Auftrag: Eine Datei TEST_RESULT.md mit einem festgelegten Satz erstellen.
Arbeitsbereich: /vollständiger/pfad/zu/test-repo
Sitzung: test-2026-08-18-001
Erwartete Änderung: test-repo/TEST_RESULT.md
Erwarteter Exit-Status: 0Nach dem Lauf kontrollieren Sie nicht nur die Antwort des Modells. Prüfen Sie den tatsächlichen Dateistatus:
pwd
git status --short
find . -maxdepth 2 -type f -printErfolgreich ist der Test erst dann, wenn Arbeitsbereich, Ausgabe und Dateiveränderung zusammenpassen. Eine sprachlich korrekte Antwort bei falschem cwd ist ein Fehlschlag. Ebenso ist eine Datei am richtigen Ort kein ausreichender Nachweis, wenn der Prozess mit Fehlerstatus beendet wurde.
Wenn die Prüfung scheitert, reduzieren Sie den Auftrag auf eine reine Modellantwort. Danach testen Sie eine einzelne Dateioperation und erst anschließend Bash. Diese Rückfallfolge verhindert, dass Sie Netzwerk-, Berechtigungs- und Sitzungsprobleme gleichzeitig debuggen. Für die saubere Übergabe von Exit-Codes und Prozessfehlern ist außerdem die offizielle Python-Dokumentation zum Starten und Überwachen von Unterprozessen relevant.
Session_root, Arbeitsverzeichnis und Sitzungskennung
Die drei Pfadangaben werden häufig verwechselt, obwohl sie unterschiedliche Aufgaben haben:
cwdbestimmt, in welchem Arbeitsverzeichnis Datei- und Shell-Operationen ausgeführt werden.session_rootbestimmt, wo Sitzungsdaten und der zugehörige persistente Zustand abgelegt werden.- Die
session ididentifiziert die konkrete Unterhaltung beziehungsweise den wiederaufnehmbaren Lauf.
session_root auf einen kontrollierten, nicht öffentlichen Datenpfad außerhalb des Quellcodeverzeichnisses. Ein typischer Aufbau ist:
~/agent-runs/deepseek-harness/sessions/<projektname>/<umgebung>/Verwenden Sie für jedes Projekt und jede Umgebung einen eigenen Bereich. Sitzungsdateien gehören nicht in ein Git-Repository, nicht in einen frei lesbaren Webserver-Pfad und nicht in ein gemeinsam genutztes temporäres Verzeichnis. Wenn Sitzungsprotokolle vollständige Eingaben, Dateiinhalte oder Tool-Ergebnisse enthalten, müssen Sie deren Zugriff und Aufbewahrung wie bei anderen Betriebsdaten behandeln.
Kann dieselbe Session-ID über mehrere Prozesse fortgesetzt werden?
Ja, sofern die verwendete SDK-Version und Laufzeit die Sitzung über denselben session_root lesen können und nicht zwei Prozesse gleichzeitig dieselbe Sitzung verändern. Die Sitzungskennung allein reicht nicht aus: Der zweite Prozess muss auf denselben Sitzungsbestand zeigen und denselben Arbeitsbereich korrekt setzen.
Das Wiederverwenden einer Kennung setzt normalerweise nicht nur den Gesprächsverlauf, sondern auch den persistenten Bash-Zustand fort. Genau deshalb darf eine Kennung nicht für unabhängige Projekte oder parallele Aufträge geteilt werden.
Regel für die Übergabe:
- Neue Aufgabe: neue Sitzungskennung;
- Fortsetzung nach bewusstem Zwischenstand: bestehende Kennung;
- Parallel laufender Auftrag: eigene Kennung und eigener Sitzungsbereich;
- Unklarer Zustand nach Abbruch: zuerst lesen und prüfen, nicht blind fortsetzen.
| Zustand | Neue Sitzung | Bestehende Sitzung |
|---|---|---|
| Ersttest im Wegwerf-Repository | Ja | Nein |
| Fortsetzung nach kontrolliertem Timeout | Nein | Ja, nach Prüfung |
| Neues Projekt auf demselben Cloud-Mac | Ja | Nein |
| Prozessabbruch während einer Dateiänderung | Nicht sofort | Nur nach Zustandsprüfung |
| Wiederholung eines nachweislich nicht gestarteten Jobs | Meist ja | Nur mit eindeutigem Startprotokoll |
Zugangsdaten und Prozessverantwortung
Speichern Sie API-Schlüssel nicht im Repository, nicht im Python-Quelltext und nicht als Klartext in einer dauerhaft lesbaren Startdatei. Für einen einfachen Test genügt eine geschützte Umgebungsvariable. Für einen länger laufenden Dienst ist ein kontrollierter Geheimnisspeicher oder die macOS-Schlüsselbundintegration vorzuziehen. Die Apple-Dokumentation zu Keychain Services beschreibt den verschlüsselten Schlüsselbund und die Zugriffskontrolle für kleine geheime Daten; verwenden Sie ihn nur so, dass der Dienst beim unbeaufsichtigten Start nicht an einer unerwarteten interaktiven Authentifizierungsabfrage hängen bleibt.
Beispiel für einen interaktiven Test:
export DEEPSEEK_API_KEY='nur-für-diese-shell'
python app/run_probe.py
unset DEEPSEEK_API_KEYIn einem produktiven Ablauf müssen Sie zusätzlich festlegen:
- Wer den Prozess startet?
- Wer ihn stoppt?
- Nach welcher Zeit gilt ein Lauf als festgefahren?
- Wo landen Standardausgabe und Fehlerausgabe?
- Wie werden Logs rotiert und gelöscht?
- Wer entscheidet nach einem Host-Neustart über Fortsetzung oder Abbruch?
launchd](https://developer.apple.com/library/archive/documentation/MacOSX/Conceptual/BPSystemStartup/Chapters/CreatinglaunchdJobs.html) ist eine mögliche Grundlage für macOS-Prozessstarts. Sie sollten daraus jedoch nicht ableiten, dass das SDK selbst einen Daemon, automatische Wiederaufnahme oder eine sichere Parallelitätssteuerung bereitstellt. Diese Eigenschaften müssen Sie in Ihrer Betriebslogik und in Ihren Tests nachweisen.
Ein zusätzlicher Kontrollpunkt ist JSON-RPC: Wenn der Python-Adapter einen Runtime-Prozess über stdio steuert, müssen Sie Exit-Status, Transportfehler und unvollständige Antworten getrennt protokollieren. Eine erfolgreiche Verbindung bedeutet nicht automatisch, dass die Aufgabe im Arbeitsbereich erfolgreich abgeschlossen wurde.
Neustart- und Rückfallprüfung
Vor dem produktiven Einsatz simulieren Sie drei Fehlerbilder: kontrollierter Prozessabbruch, unterbrochene Remote-Verbindung und vollständiger Host-Neustart. Nach jedem Szenario prüfen Sie zuerst den Zustand und entscheiden erst danach über eine Fortsetzung.
Wiederherstellung nach einem Cloud-Mac-Neustart
Nach einem Neustart gehen Sie in dieser Reihenfolge vor:
- Prüfen Sie, ob der erwartete Benutzer und der erwartete Host aktiv sind.
- Wechseln Sie in den festgelegten Projektpfad und führen Sie
pwdaus. - Prüfen Sie die SDK- und Python-Version gegen die gespeicherte Lock-Datei.
- Lesen Sie das letzte Start- und Abschlussprotokoll.
- Prüfen Sie Sitzungsordner und Repository-Status, ohne Dateien zu verändern.
- Entscheiden Sie anhand des letzten bestätigten Zustands zwischen Fortsetzung, neuem Lauf und manuellem Eingriff.
- Führen Sie erst danach den Python-Prozess erneut aus.
Verwenden Sie für die Abnahme folgende Checkliste:
- [ ] Python-Version, SDK-Version und Runtime-Version sind dokumentiert.
- [ ] Die Architektur des Cloud-Macs stimmt mit der getesteten Zielarchitektur überein.
- [ ]
cwdzeigt auf das richtige Repository. - [ ]
session_rootliegt außerhalb des Git-Arbeitsbereichs. - [ ] Für neue Aufgaben wird eine neue Sitzungskennung erzeugt.
- [ ] API-Schlüssel erscheinen nicht in Repository, Log oder Startskript.
- [ ] Ein Prozessabbruch hinterlässt einen auswertbaren Exit-Status.
- [ ] Ein Remote-Abbruch führt nicht zu einer unkontrollierten Doppelverarbeitung.
- [ ] Nach einem Host-Neustart ist der letzte Sitzungsstand lesbar.
- [ ] Backup-Umfang und Wiederherstellungsziel sind schriftlich festgelegt.
- [ ] Eine getestete Rückfallversion ist verfügbar.
- [ ] Die nächste Aufgabe wird erst nach erfolgreicher Abnahme freigeschaltet.
Entscheidung für den Dauerbetrieb
Die folgende Bewertung hilft Ihnen, die richtige Ausbaustufe zu wählen:
- Einzeltest: Der Cloud-Mac ist geeignet, wenn Sie Architektur, Paketinstallation und Werkzeugzugriff prüfen möchten.
- Periodische Automation: Ergänzen Sie feste Exit-Codes, Zeitlimits und eine neue Sitzungskennung je Auftrag.
- Langfristiger Agent: Ergänzen Sie Prozessüberwachung, Logrotation, Backup, Locking und eine dokumentierte Wiederaufnahme.
- Produktionskritischer Lauf: Starten Sie erst nach einem simulierten Neustart und einer manuellen Prüfung des letzten Zustands.
Cloud-Mac statt lokaler oder Linux-Umgebung
Eine lokale Umgebung ist für Entwicklung und schnelle Iteration angenehm, aber sie hängt an Ihrem Arbeitsgerät, Ihrer Netzwerkverbindung und Ihrer persönlichen Shell-Konfiguration. Ein Linux-Server kann für headless Prozesse günstiger und leichter automatisierbar sein, ist jedoch nicht die passende Wahl, wenn Sie macOS- und Apple-Silicon-Verhalten validieren müssen. Eine kurzfristig zusammengestellte Container- oder Hackintosh-Lösung erschwert zusätzlich die Reproduzierbarkeit und die rechtssichere Betriebsdokumentation.
Für den hier beschriebenen Fall bietet ein Cloud-Mac vor allem drei konkrete Vorteile: ein dauerhaft erreichbarer macOS-Arbeitsbereich, eine sauber übergebbare Umgebung und die Möglichkeit, Wiederanlauf unter den tatsächlich benötigten Systembedingungen zu testen. Er ist trotzdem nicht für jede Aufgabe die beste Lösung. Wenn Sie über lange Zeit eine gleichmäßig hohe Rechenlast ohne macOS-Abhängigkeit betreiben oder physische Schnittstellen benötigen, sollten Sie den Kauf eigener Hardware beziehungsweise eine andere Serverklasse sachlich gegenrechnen.
Wenn Sie zunächst nur die Plattform- und Systemseite vergleichen möchten, finden Sie bei MACGPU weitere Informationen zur Auswahl eines passenden Mac-Systems. Entscheiden Sie erst nach dem Minimaltest über eine längere Mietdauer. Für die meisten Python-Agent-Projekte ist eine klar begrenzte Testphase mit dokumentiertem Rückfallweg belastbarer als eine sofortige Dauerbuchung.
Ein Cloud-Mac beseitigt weder fehlerhafte Sitzungslogik noch ungeschützte API-Schlüssel. Er beseitigt aber einige Schwächen des bisherigen Setups: den an einen Arbeitsplatz gebundenen Prozess, die nicht reproduzierbare lokale Python-Umgebung und die fehlende Prüfung nach einem Host-Neustart. Wenn Sie genau diese drei Probleme lösen müssen und nur vorübergehend eine stabile macOS-Umgebung benötigen, ist die Miete eines Cloud-Macs von MACGPU meist der vernünftigere nächste Schritt als ein vorschneller Hardwarekauf. Prüfen Sie vor der Buchung anhand dieser Anleitung Arbeitsbereich, session_root, Prozessverantwortung und Wiederanlauf; erst wenn diese Punkte abgenommen sind, lohnt sich die Entscheidung für Konfiguration und Mietzeitraum.
Zuletzt aktualisiert am 18.08.2026; geprüft gegen die zu diesem Datum verfügbare offizielle DeepSeek-Harness-Dokumentation, die Python-Umgebungs- und Unterprozessdokumentation sowie die Apple-Dokumentation zu launchd und Keychain Services.