2026 DeepSeek Harness Agent Preset: System- oder Benutzerebene?

Ein Preset wird auf einem gemeinsam genutzten Mac unerwartet überschrieben oder verschwindet nach einer Neuinstallation.

Die schnellste Lösung: Persönliche Experimente legen Sie auf der Benutzerebene ab, Team-Baselines versionieren Sie auf der Systemebene, und gemeinsam genutzte Macs betreiben Sie mit einer systemweiten schreibgeschützten Basis plus begrenzten Benutzer-Erweiterungen.

SECTION 01Wer sollte diese Entscheidung treffen?

Dieser Leitfaden richtet sich an Entwickler, die eigene Agent-Kombinationen testen möchten, ohne andere Konten zu beeinflussen. Er ist ebenso für Plattformverantwortliche gedacht, die ein einheitliches DeepSeek Harness Agent Preset an mehrere Macs ausliefern müssen.

Auch Sicherheitsverantwortliche für gemeinsam genutzte oder gemietete Macs finden hier ein Verfahren, mit dem sich Schreibrechte, Kundenprojektgrenzen und Rückfallverantwortung sauber trennen lassen.

DeepSeek Harness befindet sich weiterhin in einer schnell veränderlichen Entwicklungsphase. Prüfen Sie deshalb vor jedem Rollout die aktuelle offizielle Projektübersicht von DeepSeek Harness und nicht nur ältere Blogbeiträge oder Screenshots.

SECTION 02Quellenvertrauen statt Bequemlichkeit

Ein Agent Preset ist nicht automatisch vertrauenswürdig, nur weil die Oberfläche es erfolgreich lädt. Entscheidend ist, wer die Datei erstellt, wer sie ändern darf und auf welcher Ebene sie in die laufende Konfiguration gelangt.

Das ist bei DeepSeek Harness besonders relevant, weil die Architektur auf Cordis aufbaut und mehrere Bestandteile als Plugins, Profile, Bundles oder Konfigurationsschichten zusammengesetzt werden. In der offiziellen Architekturdokumentation von DeepSeek Harness wird beschrieben, dass ein laufendes dsh aus geordneten Ebenen aufgebaut wird und spätere Patches Konfigurationszeilen anhand ihrer ID ersetzen können.

Für Ihre Ablageentscheidung bedeutet das:

• Benutzerebene: Die Quelle gehört in erster Linie dem einzelnen Konto. Sie eignet sich für Experimente, persönliche Arbeitsweisen und kurzfristige Anpassungen.
• Systemebene: Die Quelle gehört dem Betreiber der Maschine oder Plattform. Sie eignet sich für freigegebene Teamstandards, geprüfte Tool-Kombinationen und reproduzierbare Bereitstellung.
• Doppelte Ablage: Beide Ebenen existieren bewusst nebeneinander. Eine systemweite Baseline stellt den Mindeststandard bereit, während das Benutzerkonto eine klar begrenzte Erweiterung erhält.

Ein Benutzer-Preset kann von Ihnen selbst, einem Teammitglied oder einem Agenten erzeugt worden sein. Diese Entstehungsgeschichte muss in der Bewertung sichtbar bleiben. Ein erfolgreich geladener Datensatz ist kein Nachweis für Sicherheitsprüfung, erwartete Herkunft oder korrekte Berechtigungen.

Agent Preset, Rechtevorlage und Skills nicht vermischen

Ein Agent Preset beschreibt eine Zusammensetzung für einen Agenten oder eine Sitzung. Eine Rechtevorlage regelt dagegen, welche Aktionen oder Werkzeuge erlaubt sind. Plan Mode betrifft den Ausführungsmodus, während Skills zusätzliche Fähigkeiten oder Anweisungen bereitstellen können.

Diese Begriffe können in derselben Oberfläche nebeneinander erscheinen, sind aber nicht austauschbar. Ein Agent Preset darf deshalb nicht als Ersatz für eine Sicherheitsprüfung behandelt werden. Wenn Sie eine Rechtebegrenzung benötigen, prüfen Sie die dafür vorgesehene Konfiguration separat. Wenn Sie zusätzliche Fähigkeiten verteilen möchten, behandeln Sie Skills als eigenes Lieferobjekt.

Die Cordis-Architektur beschreibt Agent Presets als eine Möglichkeit, die Fähigkeiten einer einzelnen Sitzung zusammenzustellen. Das ist eine andere Verantwortung als das allgemeine Berechtigungsmodell des Hosts.

SECTION 03Ablageebenen und Namensauflösung

Die Frage „DeepSeek Harness eigenes Preset in welchem Verzeichnis?“ lässt sich nicht zuverlässig mit einem dauerhaft gültigen, hart codierten Pfad beantworten. Die offiziellen Konfigurationsangaben und der aktuelle Release bestimmen, welche Preset-Wurzeln vorhanden sind, ob Benutzerwurzeln aktiviert werden und in welcher Reihenfolge sie gescannt werden.

Am 19.08.2026 ist als belastbare Arbeitsregel daher nicht ein einzelner Pfad entscheidend, sondern die Kombination aus:

1. aktuell installierter DeepSeek-Harness-Version,
2. aktivierten Preset-Wurzeln,
3. dokumentierter Scan-Reihenfolge,
4. Vertrauenskennzeichnung für System- und Benutzerquellen,
5. tatsächlich geladener Konfigurationszeile.

Die aktuelle Release-Übersicht weist weiterhin auf eine Vorabentwicklung hin. Unter anderem wurden integrierte Presets und Benennungen im Verlauf der Entwicklung verändert. Daraus folgt: Laden Sie keine Verzeichnisstruktur aus einem älteren Beitrag ungeprüft in eine neue Umgebung.

Welches Preset wird bei gleichem Namen geladen?
Das dürfen Sie nicht aus dem sichtbaren Namen in der Oberfläche ableiten. Wenn mehrere Preset-Wurzeln denselben Bezeichner enthalten, müssen Sie die dokumentierte Scan-Reihenfolge und die tatsächlich angewendete Konfigurationszeile zusammen prüfen. Ein Name ist nur eine Kennung; er beweist weder den Speicherort noch die Herkunft.

Minimaltest für ein gleichnamiges Preset

Führen Sie den Test in einer isolierten Umgebung und ohne Geheimnisse durch. Verwenden Sie zwei Presets mit identischer ID, aber mit eindeutig unterscheidbaren, harmlosen Merkmalen, etwa einer unterschiedlichen Beschreibung oder einem unkritischen Kennzeichen. Starten Sie danach genau dieselbe Sitzung und erfassen Sie:

• welche Preset-ID erkannt wird,
• welche Beschreibung oder Einstellung sichtbar ist,
• welche Wurzel laut Diagnose oder Konfigurationsdump aktiv war,
• ob eine spätere Ebene die frühere Konfiguration vollständig ersetzt,
• ob ein Neustart dasselbe Ergebnis liefert.

Die offizielle Architektur beschreibt mit dsh --profile web --dump-config einen Weg, den tatsächlich gestarteten Konfigurationsbaum sichtbar zu machen. Verwenden Sie diesen oder die in Ihrer Version dokumentierte gleichwertige Diagnose, statt den Pfad aus der Benutzeroberfläche zu erraten.

Wenn die Ausgabe keine eindeutige Herkunft zeigt, ist das Ergebnis für einen Team-Rollout noch nicht ausreichend. Dann ergänzen Sie die Prüfung um Dateiinformationen, Besitz, Änderungszeitpunkt und Hash des getesteten Presets.

SECTION 04Team-Rollout und Rückfallverantwortung

Der wichtigste Vorteil eines systemweiten Presets ist nicht, dass Sie eine Datei an einem bequemeren Ort speichern. Der Vorteil besteht darin, dass Sie aus einer Konfiguration ein kontrolliertes Lieferobjekt machen können.

Ein Team-Preset sollte mindestens folgende Eigenschaften besitzen:

• eine eindeutige Versionsquelle,
• eine dokumentierte Freigabe,
• eine nachvollziehbare Änderungshistorie,
• eine definierte Eigentümerschaft,
• eine Prüfsumme oder vergleichbare Integritätskontrolle,
• eine bekannte Rückfallversion,
• eine dokumentierte Prüfung nach Installation.

Die offizielle Entwicklungsdokumentation nennt konkrete Node.js- und Paketmanager-Anforderungen für die Entwicklung. Diese Angaben sind für die Preset-Ablage selbst nicht die Entscheidungskriterien, zeigen aber, warum Ihr Rollout immer an eine konkrete Harness-Version und nicht nur an einen Dateinamen gebunden werden sollte.

Wie verteilen Teams ein schreibgeschütztes Preset?
Sie verteilen eine geprüfte Version über den Systempfad oder über den von der aktuellen Version vorgesehenen systemweiten Preset-Root. Der ausführende Benutzer erhält Leserechte, aber kein Änderungsrecht auf die Baseline. Änderungen erfolgen in der Quelle, werden geprüft und anschließend als neue Version auf die Zielgeräte ausgerollt.

Vermeiden Sie dagegen diese scheinbar einfache Vorgehensweise:

1. Ein Administrator kopiert ein unbekanntes Preset-Verzeichnis manuell auf mehrere Macs.
2. Niemand notiert Version, Quelle oder Hash.
3. Benutzer ändern einzelne Dateien direkt.
4. Bei einem Fehler wird eine ältere Datei aus einem beliebigen Backup zurückkopiert.

Dieses Verfahren erzeugt keine Standardisierung, sondern eine nicht reproduzierbare Zustandskopie. Nach einem Mac-Tausch, einer Neuinstallation oder einer Kontenbereinigung weiß dann niemand sicher, welche Preset-Version tatsächlich aktiv war.

Stärken und Grenzen der Systemebene

Vorteile

• Einheitliche Ausgangsbasis für mehrere Konten.
• Zentral prüfbare Herkunft und Versionsfreigabe.
• Geeignet für neue Remote-Macs und standardisierte Neuaufsetzung.
• Klarere Rückfallverantwortung bei fehlerhaften Änderungen.

Nachteile

• Einzelne Entwickler können nicht ohne Freigabe die gemeinsame Basis ändern.
• Ein fehlerhaftes systemweites Preset kann mehrere Benutzer gleichzeitig beeinflussen.
• Die Plattformverwaltung muss Release-Änderungen und Kompatibilität aktiv überwachen.

Stärken und Grenzen der Benutzerebene

Vorteile

• Schnelle Iteration ohne Eingriff in andere Konten.
• Gute Isolation persönlicher Arbeitsabläufe.
• Geeignet für temporäre Werkzeuge, Testprofile und individuelle Präferenzen.
• Geringerer administrativer Aufwand für Einzelversuche.

Nachteile

• Die Konfiguration kann nach Kontenlöschung oder Migration fehlen.
• Teammitglieder erhalten möglicherweise unterschiedliche Ergebnisse.
• Die Herkunft ist schwerer zu prüfen, wenn ein Agent Dateien erzeugt oder verändert.
• Rückfall und Beweissicherung müssen je Benutzerkonto erfolgen.

SECTION 05Entscheidungsbedingungen für die richtige Ebene

Nutzen Sie die folgende Abzweigung, bevor Sie ein neues Preset ablegen:

• Wenn nur Sie selbst einen Agent-Ablauf testen und die Änderung keine anderen Konten beeinflussen soll, wählen Sie die Benutzerebene.
• Wenn ein Preset als verbindliche Teamarbeitsweise gelten soll, wählen Sie die Systemebene und machen Sie sie schreibgeschützt.
• Wenn ein Preset Werkzeuge, Netzwerkzugriffe, externe Dienste oder sensible Projektgrenzen berührt, wählen Sie nicht automatisch die Benutzerebene, sondern lassen Sie Herkunft und Rechte vorab prüfen.
• Wenn mehrere Benutzer auf demselben Mac arbeiten, wählen Sie zunächst eine systemweite Baseline plus begrenzte Benutzer-Erweiterungen.
• Wenn Kundenprojekte, Konten oder Abrechnungseinheiten voneinander getrennt bleiben müssen, teilen Sie die Umgebung, sobald ein gemeinsamer Preset-Root die Verantwortungsgrenzen nicht mehr eindeutig abbildet.
• Wenn Sie keine verlässliche Scan-Reihenfolge und keinen belastbaren Gleichnamigkeitstest dokumentieren können, stoppen Sie den Rollout und behandeln Sie das Preset bis zur Klärung als nicht freigegeben.
• Wenn die Umgebung nach jeder Sitzung vollständig zurückgesetzt wird und keine dauerhafte Benutzeranpassung erforderlich ist, bevorzugen Sie eine systemweite, unveränderliche Ausgangsbasis.
• Wenn ein Entwickler kurzfristig eine persönliche Variante benötigt, legen Sie eine neue Benutzer-ID oder eine eindeutig benannte Erweiterung an, statt die Team-ID zu überschreiben.

Diese Regeln vermeiden eine häufige Fehlannahme: „Benutzerebene“ bedeutet nicht automatisch „sicher“, und „Systemebene“ bedeutet nicht automatisch „korrekt“. Die Ebene legt vor allem fest, wer die Quelle kontrolliert und wie weit eine Änderung wirkt.

SECTION 06Gemeinsamer Mac und Schreibrechte

Ein gemeinsamer Mac benötigt eine strengere Trennung als ein persönliches Gerät, weil mehrere Konten dieselbe lokale Laufzeit, denselben Netzwerkzugang und möglicherweise dieselben Projektwerkzeuge verwenden. Zusätzlich entstehen unter macOS typische Verwaltungsfragen zu Konten, Dateibesitz, Datenschutz und Entfernung alter Sitzungsdaten.

Für gemeinsam genutzte Macs sind drei Betriebsmodelle sinnvoll:

Die mittlere Variante ist für die meisten gemeinsam verwalteten Remote-Macs der beste Ausgangspunkt. Der systemweite Teil enthält nur das, was für alle Konten identisch und geprüft sein muss. Persönliche Erweiterungen bleiben auf Benutzerebene und dürfen weder Teamstandards ersetzen noch Sicherheitsgrenzen umgehen.

Kann ein Benutzer auf einem gemeinsamen Mac das Standard-Preset ändern?
Technisch kann eine Anwendung eine Datei eventuell lesen oder verändern, wenn die Dateirechte dies erlauben. Governance-seitig sollte ein Benutzer die systemweite Standardversion jedoch nicht ändern dürfen. Erlauben Sie stattdessen eine benutzerbezogene Erweiterung mit eigener ID, eigener Änderungsverantwortung und klarer Rückfallmöglichkeit.

Kontrollieren Sie mindestens:

1. Eigentümer und Gruppe der Preset-Dateien.
2. Schreibrechte auf dem systemweiten Root.
3. Lesbarkeit für die vorgesehenen Konten.
4. Protokollierung von Änderungen.
5. Entfernung temporärer Benutzer-Presets nach Projektende.
6. Trennung von Kundendaten, Zugangsdaten und Preset-Definitionen.
7. Verhalten nach Abmeldung, Kontenwechsel und Neuaufsetzung.

Speichern Sie keine API-Schlüssel, privaten Zertifikate oder langlebigen Zugangsdaten im Agent Preset. Ein Preset kann eine Ausführung strukturieren, ist aber kein Geheimnisspeicher. Für DSGVO-relevante Umgebungen sollten Sie außerdem dokumentieren, welche Sitzungsdaten, Protokolle und Tool-Aufrufe auf dem Gerät verbleiben.

Wenn die Kontentrennung für ein Projekt nicht nachweisbar ist, sollten Sie keinen gemeinsam verwalteten Root weiterverwenden. In diesem Fall ist eine vollständig getrennte Umgebung sicherer als eine zusätzliche Regel in derselben Preset-Datei.

SECTION 07Fünf Schritte für einen kontrollierten Rollout

1. Version feststellen: Erfassen Sie die installierte DeepSeek-Harness-Version, den Release-Stand und die für Ihre Umgebung gültigen Konfigurationsangaben. Die Release-Übersicht bleibt der primäre Prüfpunkt; ältere Anleitungen dürfen nicht automatisch übernommen werden.

2. Quelleninventar erstellen: Listen Sie alle aktivierten systemweiten und benutzerbezogenen Preset-Wurzeln auf. Notieren Sie Besitz, Gruppe, Rechte, Quelle, Versionskennung und Änderungszeitpunkt. Verwenden Sie keine echten Kundennamen oder persönlichen Pfade in der Dokumentation.

3. Gleichnamigkeit isoliert prüfen: Erstellen Sie zwei harmlose Test-Presets mit derselben ID und unterschiedlichen sichtbaren Merkmalen. Starten Sie eine definierte Sitzung und sichern Sie Konfigurationsdump, Logauszug und Ergebnis. Entfernen Sie die Testdateien danach vollständig.

4. Lieferobjekt definieren: Legen Sie für das Team-Preset eine Quellversion, Freigabe, Prüfsumme und Rückfallversion fest. Der Ziel-Mac sollte nicht als dauerhafte Entwicklungsumgebung für die Baseline dienen. Änderungen werden außerhalb des systemweiten Roots vorbereitet und erst nach Prüfung verteilt.

5. Berechtigungen und Rückfall testen: Prüfen Sie mit einem normalen Benutzerkonto, dass die Baseline gelesen, aber nicht verändert werden kann. Installieren Sie anschließend eine bekannte ältere Version oder entfernen Sie die Erweiterung kontrolliert. Dokumentieren Sie, ob der vorherige Zustand tatsächlich wieder geladen wird.

Für eine umfassendere Mac-Umgebung gehört dieser Ablauf in eine Checkliste zur standardisierten Remote-Mac-Bereitstellung. Wenn Sie Konten projektbezogen trennen müssen, kombinieren Sie die Preset-Regeln mit einer Mac-Strategie für getrennte Arbeitsumgebungen, statt nur Dateirechte zu verändern.

SECTION 08Abgrenzung zu Cordis, Plan Mode und Skills

Cordis ist das zugrunde liegende Meta-Framework, über das DeepSeek Harness Plugins, Dienste, Ereignisse und Konfigurationsschichten zusammensetzt. Die offizielle Cordis-Dokumentation beschreibt das Framework als Grundlage für zeitlich und räumlich zusammensetzbare Erweiterungen.

Das bedeutet jedoch nicht, dass jede Cordis-Konfiguration ein Agent Preset ist. Ein Bundle, ein Profil, ein Patch und ein Agent Preset können unterschiedliche Rollen im Startprozess übernehmen. Die Harness-Architektur nennt geordnete Bundle-Schichten, Profil-Patches, Home-Patches und zusätzliche Overlays als getrennte Kompositionsstufen.

Behalten Sie daher diese Trennung bei:

• Agent Preset: Zusammensetzung eines Agenten oder einer Sitzung.
• Cordis-Bundle oder Profil: Laufzeit- und Plugin-Komposition.
• Plan Mode: Arbeits- oder Ausführungsmodus.
• Skills: zusätzliche Fähigkeiten, Anweisungen oder unterstützende Komponenten.
• Rechtevorlage: Sicherheits- und Zugriffsumfang.

Wenn Ihre Frage eigentlich lautet, ob ein Agent Dateien schreiben, Prozesse starten oder externe Werkzeuge verwenden darf, benötigen Sie eine Rechteprüfung und keine reine Preset-Ablageentscheidung. Ein Agent Preset kann die Auswahl eines Ablaufs beeinflussen, ersetzt aber weder Sandbox-Regeln noch Kontentrennung noch eine Freigabe für externe Dienste.

SECTION 09Entscheidung für Ihre Mac-Strategie

Für einen einzelnen Entwickler ist die Benutzerebene meist die schnellere und sauberere Lösung. Sie können experimentieren, eine temporäre Tool-Kombination verwerfen und müssen keine gemeinsame Team-Baseline anfassen. Sobald das Preset jedoch verbindliche Abläufe, sensible Grenzen oder reproduzierbare Lieferung steuert, gehört es auf Systemebene oder in eine kontrollierte systemweite Quelle.

Ein gemeinsamer Mac ohne klare Ebenentrennung hat drei reale Nachteile: Benutzer können sich gegenseitig Konfigurationen überschreiben, die tatsächliche Quelle eines gleichnamigen Presets bleibt unklar, und nach Kontenwechsel oder Neuinstallation fehlt häufig ein belastbarer Rückfallnachweis. Eine reine Benutzerlösung ist deshalb für standardisierte Teamarbeit zu fragil; eine vollständig systemweite Lösung ist wiederum zu unflexibel für persönliche Iteration.

Die belastbare Empfehlung lautet: systemweite, schreibgeschützte Team-Baseline; benutzerbezogene Erweiterungen mit eigener Kennung; vollständige Umgebungstrennung, sobald Kunden-, Konto- oder Unfallgrenzen nicht mehr durch Dateirechte allein beweisbar bleiben.

Wenn Sie dafür kurzfristig eine reproduzierbare Remote-Mac-Umgebung benötigen, kann MACNOX Mac-Miete für standardisierte Entwicklungsumgebungen sinnvoller sein als ein gemeinsam gepflegter Mac mit unbekanntem Preset-Zustand. Für langfristig konstante Hochlast oder Anforderungen an lokale Hardware-Schnittstellen ist der Kauf und die eigene Verwaltung weiterhin die bessere Option.