Symptom: Die Web-Oberfläche von DeepSeek Harness ist erreichbar, aber niemand kann belegen, dass Arbeitsbereich, Modellzugriff, Befehlsrechte und Wiederanlauf korrekt funktionieren.
Schnellste Lösung: Führen Sie die DeepSeek Harness Cloud-Mac-Abnahme anhand von sieben prüfbaren Indikatorgruppen durch. Bestehen Sie auf Belegen aus echten Befehlen, Testdateien, Sitzungsprotokollen und einem kontrollierten Neustart, bevor Sie den Mac für dauerhafte Agent-Aufgaben freigeben.

Diese Anleitung ist für technische Einkäufer gedacht, die aus einer abstrakten Anforderung eine unterschriftsfähige Übergabe machen müssen. Entwickler prüfen damit, ob der Agent reale Aufgaben ausführen kann. Betriebsteams klären Zuständigkeiten für Rechte, Protokolle, Backups und Rückfall.

Letzte Aktualisierung: 18.08.2026. Die Angaben zu DeepSeek Harness wurden gegen das offizielle Repository und die dort verlinkten Dokumente geprüft. DeepSeek Harness befindet sich laut offizieller Dokumentation weiterhin in der Developer Preview; inkompatible Änderungen sind ausdrücklich möglich. (github.com)

Abnahmeregeln vor dem ersten Test

Eine geöffnete Seite ist kein Abnahmenachweis. Sie beweist höchstens, dass ein Dienst an einer Adresse antwortet. Für eine belastbare Übergabe müssen Sie sieben Fragen getrennt beantworten:

  1. Ist die Umgebung eindeutig identifiziert?
  2. Wer darf sich anmelden und wer darf den Agenten steuern?
  3. Welche Dateien und Pfade kann der Agent tatsächlich sehen?
  4. Erreicht der Modellaufruf die erwartete API oder den vorgesehenen Dienst?
  5. Funktionieren Werkzeuge, Befehlsfreigaben und das Zurückschreiben von Ergebnissen?
  6. Was bleibt nach einer Sitzung, einem Prozessabbruch und einem Neustart erhalten?
  7. Kann ein anderes Team die Umgebung ohne geheime Zugangsdaten übernehmen?

Legen Sie vor der Prüfung eine unveränderliche Test-ID fest. Verwenden Sie ein isoliertes Repository mit einer README-Datei, einer absichtlich nicht freigegebenen Datei außerhalb des Arbeitsbereichs und einer kleinen Aufgabe, die eine kontrollierte Änderung erzeugt. So vergleichen Sie nicht nur Aussagen des Lieferanten, sondern beobachtbares Verhalten.

Bei DeepSeek Harness ist dieser Unterschied besonders wichtig. Das offizielle Projekt beschreibt eine pluginbasierte Architektur, eine Web-UI und eine laufende Developer Preview. Die Standardausführung über npx @deepseek-ai/dsh web stellt die Oberfläche standardmäßig lokal unter http://127.0.0.1:3080 bereit. Daraus folgt nicht automatisch, wie ein Anbieter den Dienst auf einem entfernten Mac veröffentlicht oder absichert. (github.com)

Umgebungsidentität und Versionsnachweis

Beginnen Sie nicht mit dem Modell. Beginnen Sie mit der Identität der Umgebung. Ohne diesen Nachweis können Sie einen erfolgreichen Test später nicht reproduzieren.

Fordern Sie folgende Informationen direkt aus dem System oder aus der Lieferdokumentation an:

  • macOS-Version und Build-Nummer
  • Mac-Modell und Prozessorfamilie
  • DeepSeek-Harness-Quelle: Paket, Repository oder lokaler Build
  • installierte DeepSeek-Harness-Version oder Commit
  • Node.js-Version und Paketmanager
  • verwendete Konfigurationsdateien
  • Startbefehl und gestarteter Dienst
  • Zeitzone, Benutzerkonto und Arbeitsverzeichnis

Wichtig ist die Beweiskette. Eine Bezeichnung wie „Mac mini M-Serie“ oder „aktuelle Harness-Version“ reicht nicht. Sie benötigen die Ausgabe konkreter Befehle, einen Screenshot der Lieferseite oder einen exportierten Zustandsbericht. Versionen dürfen nicht aus dem Namen eines Mietpakets abgeleitet werden.

Die offizielle Installationsbeschreibung nennt für den Start aus dem Quellcode unter anderem pnpm install, pnpm run build und pnpm dsh web. Für die Abnahme sollten Sie dokumentieren, welcher dieser Wege tatsächlich verwendet wurde. Ein vorkompiliertes Paket, ein lokaler Quellcode-Build und ein global installierter Befehl sind nicht dasselbe Wartungsobjekt. (github.com)

Prüfaktion: Öffnen Sie die Terminal-Sitzung des Lieferkontos und lassen Sie sich die Versionen, den Startbefehl und den Prozessstatus anzeigen. Speichern Sie die Ausgabe als Textdatei.

Beleg: environment-report.txt, Lieferseite als PDF oder Screenshot, Startprotokoll und Testzeitpunkt.

Bestanden: Ein unabhängiger Techniker kann anhand der Unterlagen dieselbe Softwarequelle und denselben Startweg erkennen.

Nicht bestanden: Der Anbieter nennt nur eine Konfigurationsklasse, verweigert den Versionsnachweis oder kann nicht erklären, welche Dateien bei einem Update ersetzt werden.

Zugriffsmodell und Übergabekonten

Die Fernanmeldung am Mac und die internen Freigaben von DeepSeek Harness sind zwei verschiedene Kontrollflächen. Eine funktionierende Remote-Mac-Anmeldung sagt nichts darüber aus, ob der Agent destruktive Aktionen ohne Zustimmung ausführen darf. Umgekehrt kann eine restriktive Agent-Konfiguration nutzlos sein, wenn mehrere Personen dasselbe Administratorkonto verwenden.

Prüfen Sie deshalb getrennt:

  • persönliches Benutzerkonto statt gemeinsamer Zugangsdaten
  • Standardbenutzer oder Administrator mit dokumentierter Begründung
  • Remote-Login und gegebenenfalls grafischer Fernzugriff
  • erreichbare Web-UI und deren Bind-Adresse
  • Firewall- oder Netzwerkfreigabe
  • Zugriff auf Terminal, Dateisystem und Schlüsselbund
  • Verfahren zum Wechseln oder Sperren der Zugangsdaten nach der Übergabe
  • Verantwortlicher für Notfallzugang und Kontosperrung

Prüfaktion: Lassen Sie einen zweiten Testbenutzer ohne Administrationsrechte anmelden. Prüfen Sie, ob dieser Benutzer die Web-UI, das Arbeitsverzeichnis, die Konfigurationsdateien und die Agentensteuerung erreichen kann. Testen Sie anschließend eine nicht freigegebene Aktion.

Beleg: Liste der Benutzerrollen, anonymisiertes Zugriffsprotokoll, Ergebnis der verweigerten Aktion und dokumentierter Prozess zum Credential-Wechsel.

Bestanden: Jede Rolle besitzt einen klaren Zweck. Ein nicht autorisierter Benutzer erreicht weder die Steuerungsebene noch geheime Konfigurationen.

Nicht bestanden: Ein gemeinsames Administratorkonto bleibt aktiv, der Webzugang ist ohne nachvollziehbare Zugriffskontrolle erreichbar oder niemand weiß, wer nach der Abnahme die Kennwörter austauscht.

Datenschutz ist dabei kein Zusatzkapitel. Wenn Quellcode, Kundendaten oder API-Schlüssel über einen Agenten verarbeitet werden, müssen Sie Datenfluss, Aufbewahrung und Zugriff nach Ihren DSGVO-Vorgaben bewerten. Ein Cloud-Mac ist nicht automatisch datenschutzkonform, nur weil das Betriebssystem macOS heißt.

Arbeitsbereich und Dateigrenzen

Der Arbeitsbereich ist die wichtigste praktische Grenze. Ein Lieferant kann „Arbeitsverzeichnis eingerichtet“ melden, ohne zu zeigen, welche Pfade der Agent tatsächlich lesen oder verändern kann.

Legen Sie im Test-Repository vier Fälle an:

  1. eine lesbare Quelldatei innerhalb des Arbeitsbereichs,
  2. eine Datei, die der Agent kontrolliert ändern darf,
  3. eine schreibgeschützte Datei,
  4. eine Referenzdatei außerhalb des Arbeitsbereichs, die nicht sichtbar sein soll.

Geben Sie dem Agenten anschließend eine feste Aufgabe: Er soll die Quelldatei analysieren, eine neue Testdatei erzeugen, die schreibgeschützte Datei verändern und die Datei außerhalb des Arbeitsbereichs öffnen. Sie benötigen für jeden Fall ein eigenes Ergebnis. „Der Agent hat den richtigen Ordner geöffnet“ ist kein Dateigrenzentest.

Das offizielle Repository beschreibt für seine lokale Agentenarchitektur unter anderem Dateioperationen, Arbeitsbereichsgrenzen und Schutz gegen Pfadüberquerung. Bei einer konkreten Cloud-Mac-Lieferung dürfen Sie diese dokumentierte Funktion jedoch nicht als Beweis für die Anbieterumgebung verwenden. Sie müssen testen, welche Konfiguration und welche Plugins tatsächlich aktiviert sind. (github.com)

Prüfaktion: Führen Sie die vier Dateioperationen mit unveränderten Eingaben aus. Protokollieren Sie Pfad, Aktion, Freigabeaufforderung, Ergebnis und Nebenwirkung.

Beleg: Test-Repository vor und nach dem Lauf, Agentenprotokoll, Terminalausgabe und Liste der sichtbaren Mounts oder Arbeitsbereiche.

Bestanden: Zulässige Änderungen werden geschrieben, schreibgeschützte oder externe Ziele werden nachvollziehbar blockiert oder zur Freigabe vorgelegt.

Nicht bestanden: Der Agent kann unerwartete Benutzerverzeichnisse durchsuchen, der Arbeitsbereich wechselt stillschweigend oder die Freigabe wird nur im Frontend angezeigt, aber nicht technisch durchgesetzt.

Achtung: Prüfen Sie immer den tatsächlich sichtbaren Dateibaum. Ein eingestelltes Arbeitsverzeichnis ist eine Konfigurationsangabe, kein Nachweis über die effektive Dateigrenze.

Modell-, Tool- und Ergebnisweg

Ein Modellname in einer Auswahlliste beweist keinen erfolgreichen Modellaufruf. Der entscheidende Test geht vom festen Prompt bis zum gespeicherten Ergebnis.

Verwenden Sie einen kleinen, wiederholbaren Benchmark:

  • Prompt mit eindeutiger erwarteter Antwort
  • einfache Dateiinspektion
  • kontrollierte Dateierstellung
  • ein nicht destruktiver Shell-Befehl
  • eine Aktion, die eine Freigabe benötigt
  • Rückschreiben des Ergebnisses in eine Ausgabedatei

Speichern Sie Prompt, Modellbezeichnung, Konfigurationsquelle, Antwort, Tool-Aufruf, Freigabeentscheidung und Fehlerausgabe. Ein Timeout, ein leerer Stream oder ein lokal erzeugtes Fallback-Ergebnis muss als Fehlsignal im Protokoll bleiben.

DeepSeek Harness dokumentiert eine Web-UI und verweist auf eigene Anleitungen für Modelle, Plugins und Architektur. Die offizielle Startseite bestätigt jedoch nicht die konkrete API-Konfiguration Ihres Cloud-Macs. Prüfen Sie deshalb, ob der Schlüssel aus einer Umgebungsvariablen, einer Konfigurationsdatei oder einer verwalteten Übergabe stammt. Einen echten geheimen Schlüssel müssen Sie nicht in das Abnahmedokument kopieren. (github.com)

Für die technische Bewertung hilft diese Vergleichsmatrix:

Prüfbereich Nachweis aus der Umgebung Bestehensbedingung Rückfallentscheidung
Modellaufruf Antwortprotokoll mit Modell und Zeitstempel Feste Eingabe erzeugt nachvollziehbare Antwort Ohne reproduzierbare Antwort keine Freigabe
Tool-Aufruf Ereignisprotokoll mit Tool, Argumenten und Ergebnis Werkzeug wird korrekt gestartet und beendet Tool nur nach Nachkonfiguration verwenden
Befehlsfreigabe Ablehnung und genehmigte Testaktion Nicht erlaubte Aktion bleibt blockiert Agent nur im Lesemodus einsetzen
Dateischreiben Diff oder Prüfsumme der Testdatei Ergebnis landet im vorgesehenen Arbeitsbereich Rückgabe über manuelle Artefakte
Fehlerweg Timeout-, Authentifizierungs- oder Exit-Signal Fehler wird sichtbar und zugeordnet Betrieb nur mit manueller Überwachung

Cloud-Mac öffnet DeepSeek Harness – reicht das? Nein. Die Oberfläche ist ein Einstiegspunkt. Für eine Abnahme brauchen Sie zusätzlich einen erfolgreichen Modellaufruf, einen Tool-Test, eine kontrollierte Änderung und dokumentierte Fehlersignale.

Sitzungen, Konfiguration und Neustart

Dauerhafte Agent-Aufgaben scheitern häufig nicht am ersten Start, sondern am zweiten Arbeitstag. Prüfen Sie deshalb, welche Zustände gespeichert werden und welche nur im laufenden Prozess existieren.

Erstellen Sie eine Test-Sitzung mit einer ungefährlichen Konfiguration:

  1. wählen Sie den vorgesehenen Arbeitsbereich,
  2. setzen Sie das zu prüfende Modell,
  3. aktivieren Sie nur die benötigten Werkzeuge,
  4. schreiben Sie eine eindeutige Markierung in die Sitzung,
  5. beenden Sie den Prozess kontrolliert,
  6. starten Sie DeepSeek Harness erneut,
  7. öffnen Sie die Sitzung und vergleichen Sie alle Zustände.

Prüfen Sie dabei separat:

  • Sitzungsverlauf
  • ausgewählter Arbeitsbereich
  • Modellkonfiguration
  • Plugin- oder Tool-Auswahl
  • Freigabestatus
  • erzeugte Dateien
  • Sitzungsprotokoll und Ereignisfolge

Ein gespeicherter Browser-Tab ist keine Sitzungswiederherstellung. Ebenso ist eine vorhandene Konfigurationsdatei kein Beweis, dass die Web-UI sie nach dem Neustart lädt. Das offizielle Projekt beschreibt die Web-UI als lokalen Dienst und stellt Architektur- sowie Entwicklungsdokumente bereit; für die konkrete Cloud-Umgebung müssen Sie den Wiederanlauf trotzdem selbst ausführen. (github.com)

Prüfaktion: Führen Sie einen kontrollierten Neustart des DeepSeek-Harness-Prozesses und danach – nach Freigabe durch den Betreiber – einen Neustart des Mac aus. Verwenden Sie keine produktiven Geheimnisse.

Beleg: Vorher-Nachher-Zustandsbericht, Sitzungs-ID, Prozessprotokoll, wiederhergestellte Dateien und Liste der manuell erneut zu setzenden Parameter.

Bestanden: Sie können exakt benennen, was automatisch zurückkommt und was nach einem Neustart neu injiziert werden muss.

Nicht bestanden: Sitzungen verschwinden, der Arbeitsbereich springt auf einen Standardpfad, Plugins fehlen oder der Anbieter behauptet eine Wiederherstellung, ohne sie vorgeführt zu haben.

Betriebsfähigkeit und Fehlerbegrenzung

Eine Übergabe ist erst belastbar, wenn ein Fehler nicht zum Suchspiel zwischen Einkauf, Anbieter und Entwickler wird. Fordern Sie deshalb keine pauschale Verfügbarkeitszusage, sondern konkrete Betriebswege.

Prüfen Sie:

  • Wo liegen Anwendungs- und Systemprotokolle?
  • Wer darf sie lesen und exportieren?
  • Wie lautet der minimale Health-Check?
  • Wer aktualisiert Node.js, DeepSeek Harness und Plugins?
  • Gibt es eine definierte Version, auf die zurückgegangen werden kann?
  • Welche Konfiguration wird gesichert?
  • Sind Sitzungen, Arbeitsbereiche oder nur Systemdateien im Backup enthalten?
  • Wie wird ein kompromittierter API-Schlüssel gesperrt?
  • Was kann der Anbieter neu aufbauen und was müssen Sie selbst sichern?

Die Developer Preview ist für die Abnahme ein reales Risikosignal: Das offizielle Repository weist ausdrücklich auf mögliche Kompatibilitätsbrüche hin. Daraus folgt eine klare Vertragsfrage: Wer prüft Updates, wer genehmigt sie und wer trägt die Folgen eines inkompatiblen Plugins? (github.com)

Schreiben Sie keine unbelegten Wiederherstellungszeiten in das Protokoll. Wenn eine Wiederherstellung nicht praktisch getestet wurde, formulieren Sie: „Verfahren beschrieben, Wiederherstellungsdauer nicht gemessen.“ Das ist belastbarer als eine scheinpräzise Garantie.

Übergabepaket und Signaturentscheidung

Am Ende brauchen Sie kein langes Präsentationsdeck, sondern ein Paket, das ein anderes Team prüfen kann. Es sollte mindestens enthalten:

  • Umgebungs- und Versionsbericht
  • Startbefehl und Konfigurationsquellen
  • Benutzer- und Verantwortungsmatrix
  • Remote-Zugangsweg ohne Klartextpasswörter
  • Arbeitsbereichs- und Dateigrenzentest
  • Modell-, Tool- und Freigabeprotokoll
  • Sitzungs- und Neustartvergleich
  • Log- und Health-Check-Anleitung
  • Backup-Umfang
  • Rückfall- oder Wiederaufbauweg
  • offene Abweichungen mit Termin und Verantwortlichem

Verwenden Sie drei Signaturklassen:

Abnahme bestanden: Alle kritischen Tests sind reproduzierbar. Zugang, Dateigrenzen, Modellkette und Neustartverhalten sind dokumentiert. Offene Punkte beeinträchtigen den geplanten Betrieb nicht.

Abnahme mit Frist: Der Kernbetrieb funktioniert, aber ein nichtkritischer Nachweis fehlt. Der offene Punkt erhält eine Frist, einen Verantwortlichen und ein konkretes Beweisdokument.

Abnahme verweigert: Ein kritischer Test ist nicht reproduzierbar. Dazu zählen ein unklarer Modellweg, unkontrollierte Dateirechte, nicht wechselbare Zugangsdaten, verlorene Sitzungen oder fehlende Rückfallunterlagen.

Wenn alle sieben Indikatorgruppen belegt sind, wählen Sie die produktive Übergabe. Wenn nur die Oberfläche und ein Demo-Prompt funktionieren, wählen Sie eine Nachbesserungsphase. Wenn Dateigrenzen, Zugriffsmodell oder Schlüsselwechsel unklar bleiben, lehnen Sie die Signatur ab.

Die passende Cloud-Mac-Entscheidung

Ein selbst verwalteter Rechner kann für langfristige, gleichbleibende Lasten sinnvoll sein. Er verlangt aber eigene Beschaffung, Betriebssystempflege, Fernzugriff, Ersatzteil- und Ausfallplanung. Eine öffentliche Cloud-Instanz ist für bestimmte Linux-Workloads flexibler, ersetzt aber keinen Mac, wenn macOS, Apple-Toolchains oder ein realer Remote-Mac-Arbeitsplatz Teil des Projekts sind.

Ein Cloud-Mac ist für Ihren Fall besonders dann sinnvoll, wenn Sie kurzfristig eine reproduzierbare Umgebung für DeepSeek Harness benötigen, mehrere Beteiligte testen oder vor dem Kauf eines eigenen Geräts die tatsächliche Übergabequalität bewerten möchten. Er ist weniger geeignet, wenn Sie dauerhaft hohe Last ohne Änderungsfenster benötigen, physische Schnittstellen voraussetzen oder eine vollständig selbst kontrollierte Hardwarekette verlangen.

Bei MACCOME sollten Sie deshalb nicht nur nach einem Modellnamen fragen. Übermitteln Sie geplante Parallelität, gewünschte Isolation, benötigte Zugriffsart und voraussichtliche Mietdauer. Nutzen Sie für die Vorauswahl beispielsweise die Übersicht zum Mac-Mieten für DeepSeek Harness und lassen Sie die spätere Übergabe an derselben Abnahmeliste messen. So vermeiden Sie typische Nachteile einer ungeprüften Lösung: unklare Versionen, gemeinsam verwaltete Konten, fehlende Neustartnachweise und nicht definierte Verantwortlichkeiten.

Wenn Sie eine regionale Option benötigen, können Sie außerdem die verfügbaren Cloud-Mac-Standorte und Mac-mini-Optionen prüfen. Entscheidend bleibt nicht der Eintrag in einer Liste, sondern ob die konkrete Umgebung Ihre Test-ID, Ihr Arbeitsbereichsmodell und Ihren Wiederanlaufprozess nachweisbar erfüllt.

Für eine konkrete Prüfung senden Sie an MACCOME am besten drei Angaben: die geplante Agent-Aufgabe, die gewünschte Dateiisolation und den voraussichtlichen Mietzeitraum. Dann kann die technische Übergabe anhand derselben Checkliste vorbereitet werden, statt eine Konfiguration zu versprechen, deren Modell-, Rechte- oder Neustartverhalten noch nicht getestet ist.