Dieser Beitrag richtet sich an Sie, wenn eine lokale Mac-Aufgabe nach dem Zuklappen oder längerer Inaktivität scheinbar verschwunden ist.

Er ist ebenso für Agent-Entwickler geeignet, die lange Builds und Tests über eine entfernte Verbindung starten. Auch Betriebsteams finden hier eine belastbare Prüfreihenfolge für dauerhaft online betriebene Mac-Systeme.

Zwei Beobachtungen führen besonders häufig zu Fehlentscheidungen:

• Die Weboberfläche ist nicht mehr erreichbar, während der Mac und der Harness-Prozess weiterarbeiten.
• Die Sitzung ist nach dem Aufwachen noch sichtbar, während der eigentliche Prozess oder ein Kindprozess bereits beendet wurde.

Eine sichtbare Sitzung ist daher kein Lebenszeichen des Prozesses. Umgekehrt beweist ein verlorenes Browserfenster nicht, dass die Arbeit beendet wurde. Ein Terminal- oder Web-Frontend kann getrennt werden, während ein lokaler Prozess weiterläuft. Das hängt von der verwendeten Betriebsart, dem Sitzungsmodell, dem Benutzerkontext und der Prozessverwaltung ab.

Bei einer protokollorientierten Implementierung sollten Sie deshalb nicht zuerst die Oberfläche aktualisieren. Suchen Sie zuerst nach drei unabhängigen Signalen:

1. Prozesssignal: Existiert der Harness-Prozess noch?
2. Ereignissignal: Wird das Sitzungs- oder Aufgabenprotokoll weitergeschrieben?
3. Arbeitsbereichsignal: Ändern sich Dateien, Testberichte oder definierte Ausgabeverzeichnisse kontrolliert?

Fehlt eines dieser Signale, ist die Aufgabe nicht automatisch „gestoppt“. Sie ist zunächst nicht ausreichend verifiziert.

Szenario: Die Weboberfläche ist weg, der Build läuft aber weiter

Angenommen, Sie starten einen langen Test über eine Remote-Weboberfläche. Nach einer Netzwerkunterbrechung lädt die Seite nicht mehr. Ein vorschnelles Neusenden erzeugt dann möglicherweise zwei parallele Builds, doppelte Artefakte oder wiederholte Veröffentlichungen.

Prüfen Sie stattdessen:

ssh BENUTZER@MAC-HOST
pgrep -af 'deepseek|harness|node|python'
pmset -g assertions

Die Prozesssuche ist nur ein Indikator. Ein Prozessname allein beweist keinen Fortschritt. Ergänzen Sie sie durch:

find /PFAD/ZUM/ARBEITSBEREICH -type f -mmin -10 -print
tail -n 100 /PFAD/ZUR_LOGDATEI
git status --short

Die Zeitspanne -10 ist dabei kein allgemeiner Erfolgswert, sondern ein Prüfbeispiel. Wählen Sie das Intervall passend zur erwarteten Schrittgröße Ihrer Aufgabe. Bei einem Test, der nur alle zwanzig Minuten ein Ergebnis schreibt, wäre ein kürzeres Intervall irreführend.

Weiterwarten dürfen Sie nur, wenn:

• der erwartete Hauptprozess vorhanden ist;
• ein bekanntes Protokoll neue Ereignisse erhält;
• die Änderungen im Arbeitsbereich zum aktuellen Schritt passen;
• keine Sperrdatei, Fehlermeldung oder Authentifizierungsstörung sichtbar ist;
• keine externe Nebenwirkung bereits doppelt ausgelöst wurde.

Stoppen Sie die automatische Fortsetzung, wenn:

• der Prozess nicht mehr vorhanden ist;
• nur die Oberfläche, aber kein Zustandsprotokoll existiert;
• Dateien teilweise geändert und nicht eindeutig einem Schritt zugeordnet sind;
• ein Deployment, Commit oder Upload möglicherweise bereits ausgeführt wurde;
• die letzte Aktion Zugangsdaten, Schlüsselbund oder grafische Berechtigungen benötigte.

Die passende interne Referenz für die eigene Abnahme ist der Leitfaden zu DeepSeek Harness Hintergrundaufgaben, sofern dort die eingesetzte Betriebsart beschrieben ist. Entscheidend bleibt jedoch die Prüfung auf Ihrem konkreten Mac.

Nein, darauf sollten Sie nicht pauschal vertrauen. Der Begriff macOS-Ruhezustand beschreibt einen Systemzustand, in dem laufende Arbeit nicht wie im normalen Betrieb fortschreitet. Netzwerkzugriffe, Timer, Terminalverbindungen und Hintergrundprozesse können sich anders verhalten. Apple stellt mit pmset Werkzeuge bereit, um Energiezustände, Zeitpläne und sogenannte Assertions zu untersuchen. (support.apple.com)

Prüfen Sie nach dem Aufwachen zuerst den zeitlichen Zusammenhang:

date
pmset -g batt
pmset -g assertions
pmset -g sched
pmset -g log | egrep -i 'sleep|wake|shutdown|restart'

Vergleichen Sie danach:

• Zeitpunkt des letzten Harness-Ereignisses;
• Beginn des Ruhezustands;
• Zeitpunkt des Aufwachens;
• letzte Änderung im Arbeitsbereich;
• letzte erfolgreiche Tool- oder API-Antwort.

Eine einzelne Uhrzeit genügt nicht. Wenn das letzte Log-Ereignis um 02:14 Uhr und das Aufwachen um 07:50 Uhr erfolgte, wissen Sie nur, dass dazwischen kein sichtbares Ereignis protokolliert wurde. Sie wissen noch nicht, ob ein Auftrag sauber pausierte, ein Netzwerkfehler auftrat oder ein Prozess beendet wurde.

Die Arbeitsannahme sollte daher lauten: Der Ruhezustand kann den Fortschritt unterbrechen; automatisches Fortsetzen ist erst nach einem Test belegt. Für eine konkrete Harness-Version und deren Unterprozesse muss die Wiederaufnahme reproduzierbar geprüft werden. Die vorhandenen Projektunterlagen nennen Sitzungs- und Zustandsmechanismen, aber keine allgemeine Zusicherung für alle Ruhezustands- und Neustartszenarien. (github.com)

Vorgehen nach dem Aufwachen

1. Arbeitsbereich zunächst nur lesend betrachten. Öffnen Sie keine automatische Reparatur und lassen Sie keinen Agenten sofort weiterarbeiten.
2. Prozessstatus erfassen. Prüfen Sie Hauptprozess, Kindprozesse und laufende Shell-Kommandos.
3. Sitzungsstatus vergleichen. Ist die Sitzung nur sichtbar oder enthält sie ein neues Ereignis nach dem Aufwachen?
4. Dateiunterschiede sichern. Erstellen Sie ein Patch, ein Archiv oder einen separaten Branch.
5. Artefakte validieren. Prüfen Sie Prüfsummen, Testberichte, Build-Verzeichnisse und Exit-Codes.
6. Kleinsten sicheren Test ausführen. Starten Sie nicht sofort den gesamten Agentenlauf.
7. Erst danach fortsetzen oder neu erstellen.

Bei einem Arbeitsbereich mit teilweise geänderten Dateien ist ein neuer, sauberer Lauf oft sicherer als eine spekulative Fortsetzung. Bei einer strikt idempotenten Aufgabe kann ein Wiederholungslauf vertretbar sein. Bei Veröffentlichung, Datenbankänderung oder externen API-Aktionen brauchen Sie dagegen eine manuelle Freigabe.

„Browser schließen“, „Remote-Verbindung trennen“, „macOS abmelden“ und „Mac neu starten“ sind vier unterschiedliche Ereignisse.

Das Schließen des Browsers beendet normalerweise nur die Oberfläche. Eine SSH- oder Remote-Desktop-Trennung kann dagegen je nach Startmethode auch das Terminalprogramm beeinflussen. Das Abmelden beendet oder verändert den Benutzerkontext. Ein Neustart beendet alle laufenden Prozesse und erzeugt danach eine neue System- und Benutzersitzung.

Apple unterscheidet zwischen Systemkontexten und Benutzer-Login-Sitzungen. Prozesse sind dabei nicht beliebig über Sitzungsgrenzen hinweg verfügbar. (developer.apple.com) Für benutzerbezogene Hintergrundprozesse ist launchd die vorgesehene macOS-Komponente; ein LaunchAgent gehört jedoch zum Benutzerkontext und ist nicht mit einem systemweiten Dienst gleichzusetzen. (developer.apple.com)

Prüfen Sie deshalb vor einer Wiederaufnahme:

who
w
launchctl print gui/$(id -u)
security list-keychains

Die Befehle zeigen nicht automatisch, ob Ihre Harness-Aufgabe korrekt fortgesetzt werden kann. Sie helfen nur bei der Einordnung:

• Browser geschlossen: Oberfläche getrennt, Prozess möglicherweise intakt.
• Remote-Verbindung getrennt: Prozess hängt eventuell an einer interaktiven Sitzung.
• Benutzer abgemeldet: Benutzerrechte, Schlüsselbund und grafische Berechtigungen können fehlen.
• System neu gestartet: Alte Prozesse sind beendet; eine sichtbare Sitzung kann nur gespeicherter Zustand sein.

Verwenden Sie nach einem Identitätswechsel keine alten Zugangsdaten ungeprüft. Prüfen Sie, ob der neue Prozess dieselbe Arbeitskopie, dieselben Umgebungsvariablen und dieselben Berechtigungen verwendet. Besonders bei API-Schlüsseln, Schlüsselbund-Einträgen und grafischen Freigaben kann ein Auftrag an der alten Sitzung hängen.

Ein Sitzungsprotokoll kann den bisherigen Verlauf anzeigen, obwohl der Agent nicht mehr läuft. Das ist bei DeepSeek Harness besonders wichtig, wenn Chatverlauf, Tool-Aufrufe, Unterprozesse und Arbeitsdateien getrennt gespeichert werden.

Gehen Sie in dieser Reihenfolge vor:

1. Letztes bestätigtes Ereignis bestimmen. Nicht die letzte Textzeile, sondern das letzte Ereignis mit eindeutiger Abschlussmarkierung zählt.
2. Arbeitsbereich mit dem letzten bestätigten Schritt vergleichen.
3. Sperrdateien und temporäre Verzeichnisse prüfen.
4. Externe Nebenwirkungen kontrollieren. Dazu gehören Commits, Uploads, Veröffentlichungen und Ticketänderungen.
5. Aufgabenklasse bestimmen: wiederholbar, fortsetzbar oder genehmigungspflichtig.
6. Neuen Lauf nur mit neuer Laufkennung starten.

Wenn das Harness eine Wiederaufnahmeoption anbietet, müssen Sie deren Verhalten auf Ihrer Version prüfen. „Resume“ kann den Gesprächsverlauf wiederherstellen, ohne einen abgebrochenen Shell-Prozess, einen Testlauf oder einen Netzwerktransfer zurückzubringen. Bei einer interaktiven Implementierung mit SQLite-gestützter Sitzungsablage kann der Verlauf zwar lokal erhalten bleiben; daraus folgt aber nicht, dass externe Arbeitsschritte bereits abgeschlossen sind. (github.com)

Vorteile einer kontrollierten Wiederaufnahme:

• geringerer Verlust bereits erledigter Analyse;
• nachvollziehbare Verbindung zwischen Log und Arbeitsbereich;
• weniger unnötige API- und Build-Aufrufe;
• bessere Auditierbarkeit bei Teamaufgaben.

Nachteile einer unkritischen Wiederaufnahme:

• doppelte Tool-Aufrufe;
• widersprüchliche Dateien;
• erneute Veröffentlichung;
• Agent entscheidet auf Basis unvollständiger Historie;
• schwer reproduzierbare Fehler nach dem Aufwachen.

Erfahrungsregel: Wenn Sie nicht beweisen können, ob der letzte Seiteneffekt erfolgreich war, behandeln Sie ihn als offen und verlangen Sie eine manuelle Prüfung. Lassen Sie keinen Agenten raten.

Nach einem Neustart ist der frühere Prozess beendet. Ob eine Sitzung automatisch wieder erscheint, hängt von der verwendeten Anwendung, ihrer Persistenz und einer korrekt eingerichteten Startlogik ab. Apple beschreibt launchd als zentrale Komponente für Start- und Hintergrundprozesse, garantiert damit aber nicht die Wiederherstellung eines beliebigen Agentenlaufs. (developer.apple.com)

Prüfen Sie die Wiederherstellung mit einer minimalen, nicht destruktiven Aufgabe:

git status --short
git diff --stat
find ./artifacts -type f -maxdepth 2 -print
shasum -a 256 ./artifacts/* 2>/dev/null

Danach führen Sie nur den kleinsten Test aus, der die Arbeitskopie bewertet. Erst wenn dieser Test erfolgreich ist, darf ein größerer Build oder Agentenlauf folgen.

Die Wiederherstellung ist ausreichend belastbar, wenn:

• die erwartete Version des Codes feststeht;
• Arbeitsbereich und Artefakte gesichert sind;
• der letzte bestätigte Prozessschritt identifiziert wurde;
• Zugangsdaten und Benutzerrechte im aktuellen Kontext funktionieren;
• ein kleiner Test reproduzierbar erfolgreich ist;
• ein erneuter externer Seiteneffekt ausgeschlossen oder freigegeben wurde.

Wenn Testergebnisse fehlen, Dateien halb geschrieben sind oder ein Befehl zwischen „gestartet“ und „abgeschlossen“ liegt, stoppen Sie die Automatisierung. Ein unbekannter Zustand ist keine Einladung an den Agenten, den letzten Schritt zu erraten.

Nutzen Sie diese Liste vor jeder Wiederaufnahme:

• [ ] Erreichbarkeit des Mac über eine zweite Verbindung geprüft.
• [ ] Hauptprozess und relevante Kindprozesse erfasst.
• [ ] Letztes Sitzungsereignis mit Zeitstempel gesichert.
• [ ] Ruhezustand, Aufwachen, Abmeldung und Neustart zeitlich abgeglichen.
• [ ] Arbeitsbereich als Patch, Archiv oder separater Branch gesichert.
• [ ] Sperrdateien und temporäre Ausgaben geprüft.
• [ ] Testberichte, Prüfsummen und Exit-Codes kontrolliert.
• [ ] Externe Seiteneffekte wie Commit, Upload oder Veröffentlichung geprüft.
• [ ] Aufgabenklasse auf Wiederholbarkeit bewertet.
• [ ] Neue Laufkennung für einen möglichen Neustart vergeben.
• [ ] Kleinsttest vor dem vollständigen Agentenlauf ausgeführt.
• [ ] Manuelle Freigabe eingeholt, falls der Zustand nicht eindeutig ist.

Für langfristige Prozesse sollten Sie die vier Fehlerklassen getrennt testen: Netzwerkunterbrechung, macOS-Ruhezustand, Prozessende und Systemneustart. Ein Test mit nur getrennter Browserseite sagt wenig über die anderen drei Fälle aus.

Die folgenden Tabellen trennen nicht nach Marketingmerkmalen, sondern nach Zustandsrisiko und Verantwortlichkeit. Die Angaben zu macOS-Verhalten und Benutzerkontexten stammen aus den Apple-Dokumentationen; DeepSeek Harness bleibt versionsabhängig. (support.apple.com)

Für Aufgaben mit hoher Belegungsdauer ist ein lokaler Mac nicht automatisch die beste langfristige Wahl. Entscheidend ist, ob Sie den Energiezustand kontrollieren, Prozesse nach einem Fehler wieder starten, den Benutzerkontext reproduzieren und nach einem Neustart einen Abnahmetest durchführen können.

Wenn ein Auftrag nur während Ihrer Arbeitszeit läuft, ist ein lokaler Mac mit klarer Prüfroutine oft ausreichend. Das gilt besonders für Aufgaben, die vollständig wiederholbar sind und keine externen Nebenwirkungen auslösen.

Eine unabhängige Online-Mac-Umgebung ist sinnvoller, wenn:

• der Prozess über mehrere Arbeitsphasen hinweg laufen muss;
• ein Mac regelmäßig in den Ruhezustand fällt;
• mehrere Personen auf denselben Zustand zugreifen;
• ein Neustart mit anschließender Abnahme vorgesehen ist;
• Builds, Tests oder Agentenläufe ein festes Zeitfenster blockieren;
• Sie einen nachvollziehbaren Übergabe- und Löschprozess benötigen.

KVMNODE kann dabei eine Option sein, wenn Sie eine separate Mac-Umgebung für längere DeepSeek-Harness-Aufgaben benötigen. Prüfen Sie vor einer Buchung nicht nur Rechenleistung, sondern vor allem Erreichbarkeit, Sitzungsübergabe, Neustartverhalten, Protokollzugriff und die Möglichkeit, die vier Unterbrechungsszenarien selbst abzunehmen. Einen Einstieg in die verfügbaren Mac-Optionen finden Sie auf der KVMNODE-Übersichtsseite; konkrete Beschaffungspfade sind beispielsweise für Mac-Umgebungen in den USA beschrieben.

Der entscheidende Unterschied zur aktuellen lokalen Lösung liegt meist nicht in einem einzelnen Chip. Ein lokaler Mac kann durch Ruhezustand, Benutzerabmeldung, Stromereignisse und unklare Remote-Sitzungen aus dem vorgesehenen Betriebszustand fallen. Eine dauerhaft online geplante Umgebung beseitigt diese Risiken nicht automatisch, macht sie aber prüfbar und organisatorisch trennbar. Wenn Ihre Aufgabe über Arbeitszeiten hinweg laufen muss, wählen Sie daher nicht einfach „mehr Leistung“, sondern eine Umgebung mit definierter Prozessverantwortung, Wiederanlaufprüfung und manueller Freigabe bei unbekanntem Zustand.