5 DeepSeek-Harness-Plugins für gemietete Server

Welche DeepSeek-Harness-Plugins sind eine Installation wert

DeepSeek-Harness-Plugins sind Code von Drittanbietern, der innerhalb Ihres Agents mit dessen Berechtigungen auf einer Maschine ausgeführt wird, für die Sie bezahlen. Die Community-Liste umfasst mehr als zwanzig Kategorien und über tausend Einträge. Auf einem gemieteten Virtual Private Server (VPS) benötigen Sie fünf: dsh-budget für Ausgabenlimits, dsh-permission-rules für die Steuerung von Tools, dsh-defend für Injection- und Secret-Scans, dsh-memory für Fakten, die eine Sitzung überdauern, und dsh-web-lan-access erst dann, wenn Sie festgelegt haben, wie die Authentifizierung erfolgen soll.

Das Harness ist dsh, das Open-Source-Agent-Harness von DeepSeek, das so entwickelt wurde, dass alles ein Plugin ist. In der eigenen README wird es als Developer Preview bezeichnet, außerdem wird vor THERE WILL BE COMPATIBILITY-BREAKING CHANGES gewarnt. Diese eine Tatsache bestimmt jede der folgenden Entscheidungen. Fixieren Sie die von Ihnen installierten Versionen, rechnen Sie damit, dass ein Upgrade die Installation unbrauchbar machen kann, und halten Sie die Auswahl klein genug, damit Sie den gesamten Code tatsächlich lesen können. Wenn das Harness noch nicht läuft, beginnen Sie mit der Installation von DeepSeek Harness auf einem VPS und kehren Sie anschließend hierher zurück. Wenn die Komponenten, in die diese Plugins eingreifen, also die Agent-Schleife, ihre Tools und ihr Speicher, noch unklar sind, arbeiten Sie zuerst die Grundlagen durch, denn jede der folgenden Entscheidungen lässt sich leichter beurteilen, wenn Sie wissen, welche Aufgabe die einzelnen Schichten erfüllen.

Wie dsh ein Plugin installiert und wo die Konfiguration abgelegt wird

dsh setzt sich aus Cordis-Plugins zusammen. Eine laufende Instanz ist daher ein Plugin-Baum und kein einzelnes Programm. Ein Profil ist eine benannte Zusammenstellung dieser Plugins. Die beiden Vorlagen sind web und headless. $DSH_HOME verwendet standardmäßig ~/.dsh. Ein Profil liegt unter $DSH_HOME/profiles/<name>/ und enthält ein eigenes package.json, ein dsh.profile-Manifest sowie ein cordis.patch.yml.

dsh plugin --profile web list
dsh plugin --profile web add dsh-budget
dsh plugin --profile web remove dsh-budget

Vier Quellformen werden unterstützt: ein einfacher npm-Paketname, ein Name mit Scope wie @towzai/dsh-memory, eine GitHub-Referenz wie github:PerryLink/dsh-budget#main sowie ein lokaler Pfad mit link: oder ./. Verwenden Sie möglichst die GitHub-Form. Dort können Sie #main durch einen Commit ersetzen und erhalten auch im nächsten Monat denselben Code.

dsh plugin --profile web add "github:PerryLink/dsh-budget#461d478"

Die Ebenen werden in einer festen Reihenfolge angewendet: zuerst jedes Bundle in der im Profil angegebenen Reihenfolge, danach das cordis.patch.yml des Profils, anschließend das cordis.patch.yml auf Home-Ebene und zuletzt ein etwaiges --patch-Overlay. Die Reihenfolge ist wichtig, weil eine spätere Ebene die Konfiguration einer früheren Ebene ändern oder entfernen kann. Wenn ein Plugin daher installiert aussieht, aber nichts tut, öffnen Sie das cordis.patch.yml des Profils und prüfen Sie zwei Dinge: Der Insert-Block muss vorhanden sein, und keine spätere Ebene darf das Plugin deaktivieren.

Am 17. August 2026 stand das npm-Paket @deepseek-ai/dsh auf 0.1.0-rc.7, während die folgenden Plugins für die 0.1.0-rc-Linie erstellt wurden. dsh-permission-rules und dsh-defend deklarieren Kompatibilität mit 0.1.0-rc.5 bis 0.1.0-rc.6, dsh-budget deklariert nur 0.1.0-rc.6, dsh-memory legt nur Peer-Bereiche ab ^0.1.0-rc.6 fest, und dsh-web-lan-access deklariert überhaupt keine dsh-Version. Am 10. Oktober 2026 ist der latest-Tag auf npm 0.2.0-rc.2. Die Lücke ist jetzt also größer als zu dem Zeitpunkt, an dem diese Versionen festgelegt wurden. Diese Lücke ist in diesem Ökosystem normal. Sie ist der übliche Grund dafür, dass ein Plugin nicht mehr geladen wird: Das Harness entwickelt sich schneller als die Plugins, die es umgeben. Aktualisieren Sie das Harness bewusst und testen Sie anschließend jeweils ein Plugin einzeln.

Lesen Sie ein Plugin, bevor Sie ihm vertrauen

Ein dsh-Plugin ist von der Ausführungsumgebung nicht sandboxed. Es wird im selben Cordis-Baum und im selben Prozess wie die Ausführungsumgebung geladen, läuft unter demselben Betriebssystembenutzer und hat Zugriff auf dieselben Modellanmeldedaten und dasselbe Arbeitsverzeichnis. Die Installation entspricht eher dem Ausführen des Skripts einer anderen Person mit sudo als dem Hinzufügen einer Browsererweiterung. Das ist dieselbe Vertrauensfrage, die Claude-Code-Plugins aufwerfen, und die Antwort ist ebenfalls dieselbe: Lesen Sie den Code, oder installieren Sie das Plugin nicht.

Prüfen Sie diese vier Punkte in dieser Reihenfolge:

• Welche Erweiterungspunkte es verwendet. Mit tools/pre-execute sieht es jeden Tool-Aufruf und kann ihn blockieren. Mit agent/pre-step sieht es Ihre Nachrichten. Mit webServer.tapIndex schreibt es die an Ihren Browser ausgelieferte Seite um. Ein Plugin, das keinen dieser Erweiterungspunkte verwendet, kann nur sehr wenig tun. Ein Plugin, das alle verwendet, ist Ihre Sicherheitsgrenze.
• Ob es mit dem Netzwerk kommuniziert. Durchsuchen Sie den Quellcode nach fetch, http und jedem fest codierten Hostnamen. Ein Kostenmesser, der Daten nach außen übermittelt, sendet Ihr Nutzungsmuster an einen anderen Ort.
• Ob es Anmeldedaten liest. Alles, was auf credentials.* oder einen Provider-Schlüssel zugreift, benötigt im README eine dokumentierte Begründung.
• Die Lizenz und das Datum des letzten Commits. Ein Plugin ohne Lizenz, das seit Monaten nicht aktualisiert wurde, ist in einem Ökosystem, das sich wöchentlich ändert, ein Haftungsrisiko.

Installieren Sie das Plugin anschließend anhand eines Commits und nicht anhand eines Branches. Lesen Sie den Einfügeblock, den der Installer in cordis.patch.yml geschrieben hat. Dieser Block nennt die Plugin-ID und die registrierte Konfiguration. Er ist die kürzeste zuverlässige Beschreibung dessen, was Sie gerade hinzugefügt haben. Halten Sie Provider-Schlüssel außerhalb der Reichweite eines Plugins, soweit die Ausführungsumgebung dies zulässt, ähnlich wie beim Halten von Geheimnissen außerhalb von KI-Agenten.

dsh-budget: Wie verhindere ich, dass ein Agent die ganze Nacht Geld ausgibt?

Ein Agent läuft unbeaufsichtigt auf einem VPS. Genau dafür wird er dort betrieben. Das ist zugleich das Risiko. dsh-budget erfasst Tokens und geschätzte Kosten pro Modell, Sitzung und Tag und setzt für diese Summen Limits durch.

dsh plugin --profile web add "github:PerryLink/dsh-budget#461d478"

Die Standardwerte sind großzügig: 10 USD pro Sitzung, 50 pro Tag und 500 pro Monat. Diese Werte passen zu einem finanzierten Team. Auf einem persönlichen Server sind sie hoch genug, dass eine Endlosschleife beendet wird, bevor das Limit greift. Senken Sie die Werte daher am ersten Tag.

[
  {
    "label": "Per session",
    "plugin_default_usd": 10,
    "suggested_start_usd": 2
  },
  {
    "label": "Per day",
    "plugin_default_usd": 50,
    "suggested_start_usd": 5
  },
  {
    "label": "Per month",
    "plugin_default_usd": 500,
    "suggested_start_usd": 40
  }
]

Die vorgeschlagenen Werte sind ein Ausgangspunkt für eine Person auf einem Server. Es handelt sich nicht um veröffentlichte Richtwerte. Erhöhen Sie sie, wenn die tatsächliche Nutzung über einen vollständigen Monat dies nahelegt. Ein Monatslimit von 40 USD mit einem Sitzungslimit von 2 schlägt früh und deutlich fehl. Das ist sinnvoll, solange Sie noch lernen, wie viel der Dienst verbraucht.

- id: budget
  config:
    budgets:
      session: 2
      daily: 5
      monthly: 40
    warnRatio: 0.8
    overLimit: block

Die Einstellung, die das Verhalten des Systems ändert, ist overLimit. Der Standardwert ist alert. Dieser gibt eine Warnung aus und lässt weitere Ausgaben zu. Standardmäßig ist dieses Plugin daher ein Dashboard. Setzen Sie den Wert auf block. Dann verweigert das Harness weitere Modellaufrufe, sobald ein Limit erreicht ist. Ein nächtlicher Job wird dadurch beendet, statt bis zum Morgen weitere Kosten zu verursachen. degrade ist der dritte Modus. Er blockiert den Aufruf und nennt als Anleitung ein günstigeres Modell aus der Zuordnung degradation. Das ist geeignet, wenn ein Job abgeschlossen werden muss, aber nicht Ihr bestes Modell benötigt. warnRatio hat standardmäßig den Wert 0.8. Sie werden daher bei 80 Prozent des Limits benachrichtigt.

Zwei wichtige Einschränkungen. Die Kosten werden anhand einer integrierten Preistabelle berechnet, die mit den von Ihnen angegebenen Preisen zusammengeführt wird. Der Maintainer weist darauf hin, dass sich die integrierten Preise ändern können. prices ist standardmäßig leer. Beim festgelegten Commit 461d478 gilt defaultPrice, der Fallback für ein Modell, das in keiner der beiden Tabellen enthalten ist: 1.0 USD pro Million Eingabetokens und 3.0 USD pro Million Ausgabetokens. In der aktuellen Version von main, geprüft am 10. Oktober 2026, ist der Standardwert 0. Das Modell wird dann als ohne Preisangabe angezeigt. Tragen Sie die tatsächlichen Werte für Ihre Modelle ein. Andernfalls ist das Dashboard nur eine Schätzung, die wie eine Messung aussieht. Zweitens aggregiert das Plugin bei 461d478 die Werte im laufenden Prozess aus dem Sitzungsereignisstrom. Die Summen werden daher beim Neustart des Harness zurückgesetzt. Eine Absturzschleife oder ein Supervisor, der dsh neu startet, setzt dadurch auch ein Tageslimit zurück. Die aktuelle Version von main speichert Tages- und Monatszeiträume standardmäßig dauerhaft (persistence.enabled: true, alle 10 Sekunden als Snapshot) und stellt sie beim Start wieder her. Ein Neustart löscht dort ein Tages- oder Monatslimit daher nicht mehr, sofern das Harness die Speicherungsdomäne bereitstellt. Ohne diese Domäne bleibt die Aggregation auf den Prozess beschränkt. main richtet sich außerdem nach der Harness-Linie 0.2. Wenn Sie den festgelegten Commit ändern, müssen Sie daher auch das Harness ändern. Betrachten Sie dsh-budget in jedem Fall als Schutz gegen Ihre eigenen Jobs. Setzen Sie beim Provider-Konto zusätzlich ein Ausgabenlimit als tatsächliche Obergrenze. Das ist das übergeordnete Argument in AI-Agent-Kosten auf einem VPS kontrollieren.

Im täglichen Betrieb verwenden Sie /budget für die Übersicht, /budget models für die Aufschlüsselung nach Modell und /budget unblock <scope>, um eine Sperre aufzuheben, nachdem Sie entschieden haben, fortzufahren.

dsh-Berechtigungsregeln: Welche Tool-Aufrufe dürfen niemals ausgeführt werden?

dsh-permission-rules legt deklarative Regeln in der tools/pre-execute-Kaskade ab. Daher wird eine Regel ausgewertet, bevor ein Tool ausgeführt wird. Es gibt drei Aktionen. allow lässt den Aufruf durch, deny blockiert ihn und gibt einen für das Modell lesbaren Grund zurück, und ask leitet ihn an die offizielle Genehmigungsschnittstelle weiter.

dsh plugin --profile web add "github:PerryLink/dsh-permission-rules#b30b4fb"

Die Regeln befinden sich in .dsh/rules.yaml relativ zum Arbeitsverzeichnis der Sitzung. Mit fallbackPath und optional searchUp kann die Suche nach oben in Richtung des Dateisystemstamms fortgesetzt werden. Die Übereinstimmung umfasst Globs für Tool-Namen, Globs für Parameter-Schlüssel und -Werte, Globs für Pfade relativ zum Arbeitsbereich, Agenten-Selektoren wie main oder subagent sowie Netzwerkziele.

rules:
  - match: { tools: [bash], params: { command: "rm -rf*" } }
    action: deny
    reason: "No recursive deletes"
  - match: { tools: [edit, write], paths: ["**/.env*", "**/secrets/**"] }
    action: ask
    reason: "Secret files need confirmation"
  - match: { tools: ["mcp__*"] }
    action: ask
    reason: "MCP tools need confirmation"

Die Auswertung verwendet die erste passende Regel. Ein weit gefasstes allow weiter oben hebt daher unbemerkt alle darunterliegenden, spezifischeren Regeln auf. Schreiben Sie die Verweigerungen zuerst und die permissiven Regeln zuletzt. Der Tool-Namen-Glob umfasst mcp__*. Damit können Sie Tools steuern, die von einem Model Context Protocol (MCP)-Server statt vom Harness selbst stammen. Das ist wichtig, sobald Sie MCP-Server auf einem VPS betreiben.

Planen Sie ein Verhalten ein: ask benötigt eine antwortende Instanz. In einem headless-Profil beobachtet möglicherweise niemand die Sitzung. Ein unbeantwortetes ask wartet nicht, bis jemand verfügbar ist: Wenn keine antwortende Instanz zusammengestellt wurde, schlägt die Genehmigungskette des Harness mit geschlossenem Fehlerverhalten fehl, und der Aufruf wird verweigert. Auf einem unbeaufsichtigten System verhält sich eine ask-Regel daher wie ein deny, den Sie nicht absichtlich geschrieben haben. Verwenden Sie deny für alles, was Sie niemals genehmigen würden. Behalten Sie ask für das Profil bei, vor dem Sie sitzen. Wenn Genehmigungen unbeaufsichtigt funktionieren sollen, benötigen Sie einen tatsächlichen Antwortpfad. Darum geht es in Genehmigungen zum Steuern von Aktionen von KI-Agenten.

dsh-defend: Wie steht es um Prompt-Injection und durchgesickerte Geheimnisse?

dsh-defend prüft an drei Stellen: eingehende Nachrichten auf agent/pre-step, Tool-Argumente auf tools/pre-execute einschließlich einer Sperre für destruktive Löschvorgänge sowie Tool-Ergebnisse auf tools/post-execute. Der letzte Punkt ist besonders wichtig, weil dort der Inhalt einer abgerufenen Webseite geprüft wird, bevor das Modell darauf reagiert.

dsh plugin --profile web add "github:PerryLink/dsh-defend#7ba3427"

Die Standardwerte sind vorsichtig statt strikt: detection.injectionAction, detection.jailbreakAction und detection.secretAction sind alle auf ask gesetzt, während detection.secretBlockCritical auf true steht. Dadurch wird ein kritisches Geheimnis unabhängig von den übrigen Einstellungen blockiert. Auf einem unbeaufsichtigten System sollten Sie die für Sie relevanten Aktionen auf block setzen, weil ask ohne jemanden, der gefragt werden kann, keine Entscheidung ist.

Das Audit-Design ist positiv hervorzuheben. defend/detection-Ereignisse protokollieren Regel-ID, Familie, Kategorie, Schweregrad, Entscheidung und Prüfdaten, niemals jedoch den gefundenen Text. Geheimnisse werden nur nach Typ erfasst. Durch die Aktivierung des Audit-Logs entsteht daher keine zweite Kopie der Zugangsdaten, die Sie schützen wollten.

Machen Sie sich klar, welchen Nutzen dies bietet. Die Erkennung basiert auf Regeln, und die README weist ausdrücklich darauf hin, dass neuartige Formulierungen und mehrstufige Angriffe die Prüfung umgehen können. Die Rate offensichtlicher Angriffe sinkt. Ein Agent kann dadurch jedoch nicht bedenkenlos auf nicht vertrauenswürdige Inhalte angesetzt werden. Behalten Sie deshalb die Berechtigungsregeln darunter bei.

dsh-memory: Was merkt sich der Agent morgen?

Zwei verschiedene Plugins heißen dsh-memory. Das sollten Sie wissen, bevor Sie einen Installationsbefehl eingeben. Installieren Sie die Quelle explizit, damit Sie die Variante erhalten, über die Sie gelesen haben.

Für einen kleinen Server würde ich die SQLite-Variante verwenden. Sie registriert sich als memory, speichert eine gemeinsame Datei für alle Profile unter $DSH_HOME/memory/memory.db und stellt memory_write, memory_search und memory_forget bereit. Die Suche basiert auf Schlüsselwörtern und durchsucht den gespeicherten Text sowie die Tags. Es gibt keinen Embedding-Dienst, keinen API-Schlüssel und keinen zusätzlichen Prozess.

dsh plugin --profile web add "github:ben7am1n/dsh-memory#def7c6a"

Die Konfiguration, die Sie anpassen müssen, ist überschaubar: path für die Datenbankdatei, promptRecentCount (Standardwert 10) für die Anzahl der nicht angehefteten Erinnerungen, die eingefügt werden, und promptMaxChars (Standardwert 2000) für das Rendering-Budget. Sie verwendet node:sqlite, das Node 22 und 24 weiterhin als experimentell kennzeichnen. Ein Node-Upgrade sollten Sie daher testen und nicht einfach voraussetzen.

Das ändert sich durch den Speicher tatsächlich auf dem Computer: Eingefügte Erinnerungen werden bei jedem Durchlauf in den System-Prompt aufgenommen. promptMaxChars ist eine Obergrenze für den gerenderten Abschnitt, kein fester Umfang. Sobald Ihre gespeicherten Erinnerungen diesen Umfang ausfüllen, bedeuten 2000 Zeichen bei jeder einzelnen Anfrage dauerhaft einige hundert zusätzliche Eingabe-Tokens. Das ist ein realer Kostenfaktor. Deshalb sollte dsh-budget vor dsh-memory auf dem Server eingerichtet werden. Halten Sie promptMaxChars klein und bereinigen Sie den Speicher mit memory_forget, statt die Datei unkontrolliert wachsen zu lassen.

Die alternative Variante speichert Erinnerungen in einer YAML-Datei und führt eine Embedding-Suche mit automatischer Aufnahme in den Prompt durch. Sie wird mit dsh plugin --profile web add github:towzai/dsh-memory installiert. Für die Embedding-Suche benötigt sie eine lokale ollama-Instanz und ein Embedding-Modell, standardmäßig qwen3-embedding:0.6b. Sie können es mit DSH_MEMORY_EMBED_MODEL überschreiben. Ohne ollama fällt sie auf eine reine Schlüsselwortsuche zurück. Die semantische Trefferqualität ist besser als bei einer Schlüsselwortsuche. Dafür benötigen Sie einen zusätzlichen Dienst und einen Satz von Modellgewichten, die auf demselben Server im Speicher bleiben. Bei einem kleinen Tarif steht dieser Speicher dann nicht mehr für die Arbeit zur Verfügung, für die Sie den Server gemietet haben. Wählen Sie diese Variante, wenn ausreichend RAM vorhanden ist. Der allgemeine Zielkonflikt zwischen Trefferqualität und dauerhaft belegten Ressourcen wird unter lokaler Speicher für Agenten erläutert.

dsh-web-LAN-Zugriff: Sollte die Weboberfläche über Loopback hinaus lauschen?

npx @deepseek-ai/dsh web stellt die Oberfläche unter 127.0.0.1:3080 bereit. Browser stellen crypto.randomUUID() nur in einem sicheren Kontext bereit. Deshalb schlägt das Laden derselben Seite über einfaches HTTP von einem anderen Rechner fehl. dsh-web-lan-access behebt das, indem es webServer.tapIndex abfängt und einen kleinen Polyfill einfügt. Außerdem ändert es die Serverbindung auf 0.0.0.0.

Lesen Sie die Warnung des Plugins, bevor Sie es installieren. Zum hier genannten Commit e27e909 erklärte die README, dass die Bindung an 0.0.0.0 den Agenten ohne Authentifizierung für alle Personen im selben lokalen Netzwerk (LAN) erreichbar macht. Auf einem Server mit öffentlicher IP-Adresse gilt das für das gesamte Internet. Eine kurze Liste sensibler Methoden (settings.*, credentials.*, llm.discoverModels) bleibt an Loopback gebunden und liefert bei Anfragen von entfernten Ursprüngen 403 zurück. Das hat sich geändert. Aktuelle Harness-Builds, geprüft am 10 October 2026, authentifizieren den Browser: Das Starttoken in der ausgegebenen URL wird gegen ein signiertes Sitzungscookie ausgetauscht. Dieses Cookie ist für jede Host-API-Route und jeden Stream erforderlich. Die aktuelle README des Plugins bezeichnet trustedHosts als Origin-/Host-Schranke, nicht als Identitätsprüfung. Sie weist darauf hin, dass die Bindung an 0.0.0.0 die Authentifizierungsoberfläche auf jeder erreichbaren Schnittstelle veröffentlicht. Außerdem aktiviert sie nun Host-basierte Einstellungen für eine authentifizierte entfernte Seite. Daher kann ein angemeldeter entfernter Browser in aktuellen Builds auch auf Host-Einstellungen zugreifen. Das Risiko ist also nicht verschwunden, sondern hat sich verlagert: Jeder, der den Port erreichen kann, kann die Anmeldung prüfen. Die ausgegebene URL ist selbst ein Zugangstoken. Über einfaches HTTP wird dieses Token unverschlüsselt über das Netzwerk übertragen.

In den meisten Fällen benötigen Sie dieses Plugin überhaupt nicht. Leiten Sie den Port stattdessen über SSH weiter.

ssh -N -L 3080:127.0.0.1:3080 you@your-server

Öffnen Sie anschließend http://127.0.0.1:3080 in Ihrem lokalen Browser. Der Harness lauscht weiterhin nur auf Loopback. Dadurch wird nichts veröffentlicht. Da Browser 127.0.0.1 als sicheren Ursprung behandeln, ist crypto.randomUUID() verfügbar. Ein Polyfill ist nicht erforderlich. Ein Befehl, kein Plugin, keine zusätzliche Angriffsfläche.

Installieren Sie das Plugin nur, wenn eine Weiterleitung nicht ausreicht, zum Beispiel wenn ein Telefon im selben Netzwerk auf die Oberfläche zugreifen muss. Binden Sie es in diesem Fall hinter eine private Netzwerkschnittstelle. Behalten Sie eine Firewall-Regel bei, die nur diese Schnittstelle zulässt. Tragen Sie die verwendeten Namen unter trustedHosts im Eintrag web-runtime ein. Für den echten Zugriff durch mehrere Benutzer gibt es dsh-passwords. Dieses Plugin ergänzt Berechtigungen für Subuser, stündliche Token- und tägliche Zeitkontingente pro Subuser, automatische TLS-Zertifikate (Transport Layer Security) über Let's Encrypt und ein verschlüsseltes Audit-Log. Bewerten Sie es als Plattform und nicht nur als Plugin: Es benötigt die Ports 80 und 443, bringt ein eigenes Installationsprogramm mit, und der dokumentierte Schnellweg leitet ein Shell-Skript aus dem Netzwerk direkt an bash weiter. Verwenden Sie vorzugsweise npm install -g dsh-passwords und danach dsh-passwords install. Dann liegt der Code auf der Festplatte, sodass Sie ihn vor der Ausführung lesen können.

So entfernen Sie ein Plugin vollständig

Die Deinstallation besteht aus zwei Schritten. Der zweite wird häufig übersprungen.

dsh plugin --profile web remove dsh-budget
dsh plugin --profile web list

list sollte es nicht mehr anzeigen. Öffnen Sie anschließend $DSH_HOME/profiles/web/cordis.patch.yml und löschen Sie alle verbleibenden Insert-Blöcke, in denen dieses Plugin genannt wird. Dieser Eintrag lädt das Plugin in den Baum. Starten Sie den Harness neu, damit der Baum neu aufgebaut wird. Ein bereits geladenes Plugin bleibt geladen, bis Sie dies tun. Denken Sie außerdem daran, dass Daten länger bestehen als Code. $DSH_HOME/memory/memory.db und .dsh/rules.yaml bleiben nach der Deinstallation erhalten. Löschen Sie sie manuell, wenn auch die Daten entfernt werden sollen.

Was ich gelesen habe und wann

Jede Referenz hier verweist auf einen Commit, nicht auf einen Branch, weil main zu dem Zeitpunkt, an dem Sie dies lesen, bereits anderer Code sein wird. Ich habe den gesamten Inhalt am 17. August 2026 gelesen. Der Harness selbst stand an diesem Tag auf npm bei 0.1.0-rc.7. Am 10. Oktober 2026 habe ich die oben beschriebenen Standardwerte und das Verhalten erneut anhand der Primärquellen geprüft. Zu diesem Zeitpunkt war der Tag latest auf npm bei 0.2.0-rc.2.

Prüfen Sie diese Fixierungen erneut, bevor Sie einen Befehl kopieren. In einem Ökosystem mit Entwickler-Vorschau ist eine Versionsnummer mit Datum die einzige Angabe, die verlässlich ist.

FAQ

Welche DeepSeek-Harness-Plugins sollte ich zuerst auf einem VPS installieren?

Installieren Sie zuerst dsh-budget und dsh-permission-rules. Ein Budget mit overLimit: block verhindert, dass ein unbeaufsichtigter Lauf die ganze Nacht Ausgaben verursacht, und eine .dsh/rules.yaml-Datei verhindert einen Tool-Aufruf, den Sie niemals genehmigt hätten. Fügen Sie dsh-defend hinzu, sobald der Agent Inhalte aus dem öffentlichen Web liest, und dsh-memory, wenn Sie feststellen, dass Sie in jede Sitzung denselben Kontext einfügen. Verzichten Sie auf Themes und Status-Chips. Sie fügen Code hinzu, der mit den Berechtigungen Ihres Agents ausgeführt wird, ohne das Verhalten der Maschine zu ändern.

Sind dsh-Plugins vom Harness isoliert?

Nein. Ein Plugin wird in denselben Cordis-Baum wie das Harness geladen, im selben Prozess, unter demselben Betriebssystembenutzer, mit denselben Modellzugangsdaten und im selben Arbeitsbaum. Ein Plugin, das tools/pre-execute abfängt, kann jeden Tool-Aufruf sehen und blockieren. Ein Plugin, das agent/pre-step abfängt, kann Ihre Nachrichten sehen. Lesen Sie daher den Quellcode, prüfen Sie die Lizenz und das Datum des letzten Commits. Installieren Sie das Plugin anhand eines Commits und nicht anhand eines Branches, damit sich der Code nicht unbemerkt ändert.

Stoppt dsh-budget den Agent tatsächlich oder warnt es mich nur?

Das hängt von overLimit ab. Der Standardwert ist alert. Dieser warnt bei warnRatio und setzt die Ausgaben fort. block verweigert weitere Modellaufrufe, sobald ein Limit erreicht ist, und /budget unblock <scope> hebt dieses Limit auf, wenn Sie fortfahren möchten. degrade blockiert den Vorgang und nennt als Hinweis ein günstigeres Modell aus der Zuordnung degradation. Es gibt eine wichtige Einschränkung: Beim hier festgelegten Commit 461d478 werden die Summen im laufenden Prozess aggregiert. Ein Neustart des Harness setzt sie daher zurück, und eine Neustartschleife kann ein Tageslimit umgehen. Die aktuelle Version main speichert Tages- und Monatswerte standardmäßig über Neustarts hinweg. Legen Sie in jedem Fall ein Ausgabenlimit beim Provider fest. Es bildet die tatsächliche Obergrenze.

Wie entferne ich ein dsh-Plugin vollständig?

Führen Sie dsh plugin --profile web remove <package-name> aus und bestätigen Sie mit dsh plugin --profile web list. Öffnen Sie anschließend $DSH_HOME/profiles/web/cordis.patch.yml und löschen Sie alle verbliebenen Insert-Blöcke für dieses Plugin, da dieser Eintrag das Plugin lädt. Starten Sie das Harness neu, damit der Plugin-Baum neu aufgebaut wird. Vom Plugin geschriebene Daten bleiben auf dem Datenträger: $DSH_HOME/memory/memory.db und .dsh/rules.yaml bleiben nach der Deinstallation erhalten, bis Sie sie selbst löschen.

Ist es sicher, die dsh-Weboberfläche über das Netzwerk bereitzustellen?

Nicht ohne weitere Maßnahmen. dsh web lauscht auf 127.0.0.1:3080, und dsh-web-lan-access ändert diese Bindung in 0.0.0.0. Beim hier genannten Commit wurde in der README angegeben, dass der Agent dadurch ohne Authentifizierung für alle Personen im selben Netzwerk erreichbar ist. Nur settings.*, credentials.* und llm.discoverModels waren an die Loopback-Schnittstelle gebunden. Aktuelle Harness-Builds, geprüft am 10. Oktober 2026, authentifizieren die Browsersitzung mit dem Launch-Token aus der ausgegebenen URL und einem signierten Session-Cookie. Dadurch ist die Anmeldeschnittstelle jedoch auf jeder Schnittstelle erreichbar. Außerdem wird dieses Token bei einer URL mit plain HTTP im Klartext übertragen. Verwenden Sie eine SSH-Portweiterleitung, ssh -N -L 3080:127.0.0.1:3080 you@your-server, oder binden Sie den Port an eine private Netzwerkschnittstelle und schützen Sie ihn mit einer Firewall-Regel. Setzen Sie außerdem TLS vor jeden Dienst, der von außerhalb erreichbar ist.