SSD Nodes Learn Hosting plans →
Anleitungen Matt ConnorVon Matt Connor · Aktualisiert 2026-08-22

Die 5 besten DeepSeek-Harness-Plugins für Ihren VPS

Fünf DeepSeek-Harness-Plugins für einen gemieteten VPS: Ausgaben begrenzen, Tools absichern, Injections erkennen, Sitzungswissen speichern und LAN-Zugriff kontrollieren.

Welche DeepSeek-Harness-Plugins sind die Installation wert?

DeepSeek-Harness-Plugins sind Code von Drittanbietern, der innerhalb Ihres Agents mit den Berechtigungen Ihres Agents auf einer von Ihnen bezahlten Maschine ausgeführt wird. Die Community-Liste umfasst mehr als zwanzig Kategorien und über tausend Einträge. Auf einem gemieteten virtuellen privaten Server (VPS) benötigen Sie fünf: dsh-budget für Ausgabenlimits, dsh-permission-rules für die Steuerung von Tools, dsh-defend zum Erkennen von Injections und Secrets, dsh-memory für Fakten, die eine Sitzung überdauern, und dsh-web-lan-access erst, nachdem Sie festgelegt haben, wie Sie sich authentifizieren.

Der Harness ist dsh, der Open-Source-Agent-Harness von DeepSeek, der so konzipiert ist, dass alles ein Plugin ist. In der eigenen README wird er als Developer Preview bezeichnet und vor THERE WILL BE COMPATIBILITY-BREAKING CHANGES gewarnt. Diese eine Tatsache bestimmt jede der folgenden Entscheidungen. Fixieren Sie die Version der installierten Komponenten, rechnen Sie damit, dass ein Upgrade sie unbrauchbar macht, und halten Sie die Zusammenstellung klein genug, damit Sie den gesamten Code tatsächlich lesen können. Wenn der Harness noch nicht läuft, beginnen Sie mit der Installation von DeepSeek Harness auf einem VPS und kehren Sie anschließend hierher zurück.

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 und eine cordis.patch.yml.

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

Es gibt vier Quellformen: einen einfachen npm-Paketnamen, einen Bereichsnamen wie @towzai/dsh-memory, eine GitHub-Referenz wie github:PerryLink/dsh-budget#main sowie einen lokalen Pfad mit link: oder ./. Verwenden Sie möglichst die GitHub-Form. Sie können #main durch einen Commit ersetzen und erhalten 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 jedes --patch-Overlay. Die Reihenfolge ist wichtig, weil eine spätere Ebene die Konfiguration einer früheren Ebene ändern oder entfernen kann. Wenn ein Plugin scheinbar installiert ist, 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 steht das npm-Paket @deepseek-ai/dsh bei 0.1.0-rc.7. Jedes unten aufgeführte Plugin gibt dagegen Kompatibilität mit 0.1.0-rc.5 bis 0.1.0-rc.6 an. Diese Lücke ist in diesem Ökosystem normal. Sie ist der häufigste Grund dafür, dass ein Plugin nicht mehr geladen wird: Das Harness entwickelt sich schneller als die zugehörigen Plugins. Aktualisieren Sie das Harness bewusst und testen Sie anschließend jeweils nur ein Plugin.

Lesen Sie ein Plugin, bevor Sie ihm vertrauen

Ein dsh-Plugin ist nicht von der Ausführungsumgebung abgeschottet. 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 Modellzugangsdaten und dasselbe Arbeitsverzeichnis. Die Installation entspricht eher dem Ausführen des Skripts einer anderen Person mit sudo als dem Hinzufügen einer Browsererweiterung. Es geht um 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. tools/pre-execute bedeutet, dass das Plugin jeden Tool-Aufruf sieht und blockieren kann. agent/pre-step bedeutet, dass es Ihre Nachrichten sieht. webServer.tapIndex bedeutet, dass es die an Ihren Browser ausgelieferte Seite umschreibt. Ein Plugin, das keinen dieser Punkte 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 Kostenmonitor, der Daten nach außen übermittelt, sendet Ihr Nutzungsmuster irgendwohin.
  • Ob es Zugangsdaten liest. Alles, was auf credentials.* oder einen Provider-Schlüssel zugreift, benötigt im README einen genannten Grund.
  • 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 statt anhand eines Branches, und lesen Sie den Einfügeblock, den das Installationsprogramm in cordis.patch.yml geschrieben hat. Dieser Block nennt die Plugin-ID und die von ihm registrierte Konfiguration. Damit erhalten Sie die kürzeste ehrliche Beschreibung dessen, was Sie gerade hinzugefügt haben. Halten Sie Provider-Schlüssel außerhalb der Reichweite des 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 Ausgaben verursacht?

Ein Agent auf einem VPS läuft unbeaufsichtigt. Genau dafür wird er dort betrieben, und genau darin liegt auch das Risiko. dsh-budget erfasst Tokens und geschätzte Kosten nach Modell, Sitzung und Tag und setzt für diese Summen Obergrenzen 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 privaten Server sind sie hoch genug, dass eine Endlosschleife endet, bevor die Obergrenze greift. Senken Sie sie daher am ersten Tag.

Chartdsh-budget default caps and a lower starting point for one small VPS (USD)
The data behind this chart
[
  {
    "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
  }
]

Der vorgeschlagene Wert ist ein Ausgangspunkt für eine Person auf einem Server, keine veröffentlichte Referenzgröße. Erhöhen Sie ihn, wenn ein tatsächlicher Nutzungsmonat dies rechtfertigt. Eine monatliche Obergrenze von 40 USD zusammen mit einer Sitzungsobergrenze von 2 führt früh und eindeutig zum Abbruch. Das ist sinnvoll, solange Sie den Verbrauch des Tools noch ermitteln.

- 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. Dabei wird eine Warnung ausgegeben, aber die Ausgaben laufen weiter. Ohne weitere Konfiguration dient dieses Plugin daher nur als Übersicht. Setzen Sie den Wert auf block. Dann verweigert das Harness weitere Modellaufrufe, sobald eine Obergrenze erreicht ist. Ein Auftrag über Nacht wird dadurch beendet, statt bis zum Morgen weitere Kosten zu verursachen. degrade ist der dritte Modus. Er ersetzt das Modell durch ein günstigeres Modell aus der Zuordnung degradation. Das ist geeignet, wenn ein Auftrag abgeschlossen werden muss, dafür aber nicht Ihr leistungsfähigstes Modell benötigt. warnRatio hat standardmäßig den Wert 0.8. Sie werden daher bei 80 Prozent der Obergrenze informiert.

Es gibt zwei wichtige Einschränkungen. Die Kosten werden anhand der von Ihnen angegebenen Preise berechnet: prices ist standardmäßig leer, und defaultPrice verwendet ersatzweise 1.0 USD pro Million Eingabetokens sowie 3.0 USD pro Million Ausgabetokens. Tragen Sie die tatsächlichen Werte für Ihre Modelle ein. Andernfalls ist die Übersicht nur eine Schätzung, keine Messung. Zweitens aggregiert das Plugin die Werte im laufenden Prozess aus dem Sitzungsereignisstrom. Die Summen werden daher zurückgesetzt, wenn das Harness neu gestartet wird. Eine Absturzschleife oder ein Supervisor, der dsh neu startet, setzt eine Tagesobergrenze zurück. Betrachten Sie dsh-budget als Schutz gegen eigene Aufträge. Legen Sie zusätzlich ein Ausgabenlimit für das Provider-Konto fest. Dieses Limit ist die tatsächliche Obergrenze. Das ist auch das zentrale Thema im Abschnitt AI-Agentenkosten auf einem VPS begrenzen.

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, sobald Sie sich für die Fortsetzung entschieden haben.

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

dsh-permission-rules legt deklarative Regeln auf der tools/pre-execute-Verarbeitungskette fest, sodass eine Regel ausgewertet wird, bevor ein Tool ausgeführt wird. Es gibt drei Aktionen. allow lässt den Aufruf passieren, deny blockiert ihn und gibt einen Grund zurück, den das Modell lesen kann, 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. Es gibt außerdem ein globales fallbackPath und ein optionales searchUp, um im Dateisystembaum bis zum Root-Verzeichnis nach oben zu gehen. Die Übereinstimmung berücksichtigt Globs für Tool-Namen, Globs für Parameter-Schlüssel und -Werte, Globs für Pfade relativ zum Arbeitsbereich, Agentenauswahlen 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 am Anfang hebt daher stillschweigend jede darunterliegende, spezifischere Regel auf. Schreiben Sie die Ablehnungen zuerst und die erlaubenden Regeln zuletzt. Der Tool-Namen-Glob erfasst mcp__*. Damit können Sie Tools steuern, die von einem Model Context Protocol-(MCP-)Server und nicht 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. Bei einem headless-Profil schaut möglicherweise niemand zu. Eine ask-Regel kann einen Lauf daher anhalten, bis jemand verfügbar ist. Verwenden Sie deny für alles, was Sie niemals genehmigen würden. Verwenden Sie ask für das Profil, vor dem Sie sitzen. Wenn Genehmigungen unbeaufsichtigt funktionieren sollen, benötigen Sie einen tatsächlich erreichbaren Antwortpfad. Darum geht es in Genehmigungen für Aktionen von KI-Agenten steuern.

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

dsh-defend scannt an drei Stellen: eingehende Nachrichten auf agent/pre-step, Tool-Argumente auf tools/pre-execute einschließlich einer Schutzvorrichtung gegen destruktives Löschen sowie Tool-Ergebnisse auf tools/post-execute. Der letzte Punkt ist besonders relevant, weil dort Inhalte, die von einer Webseite abgerufen wurden, geprüft werden, bevor das Modell darauf reagiert.

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

Die Standardwerte sind vorsichtig, aber nicht strikt: detection.injectionAction, detection.jailbreakAction und detection.secretAction sind alle ask, 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 gewünschten Aktionen auf block setzen, weil ask ohne jemanden, der gefragt werden kann, keine Entscheidung darstellt.

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

Machen Sie sich klar, welchen Schutz das bietet. Die Erkennung basiert auf Regeln, und die README weist ausdrücklich darauf hin, dass neue Formulierungen und mehrstufige Angriffe diese umgehen können. Dadurch sinkt die Zahl offensichtlicher Angriffe. Ein Agent kann deshalb trotzdem nicht bedenkenlos auf nicht vertrauenswürdige Inhalte angesetzt werden. Lassen Sie die Berechtigungsregeln weiterhin als zusätzliche Schutzebene bestehen.

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 das Plugin über die explizite Quelle. So erhalten Sie genau die Variante, über die Sie gelesen haben.

Auf einem kleinen Server würde ich den SQLite-Build einsetzen. Er 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 verwendet Schlüsselwörter für den gespeicherten Text und 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. Das Plugin verwendet node:sqlite. Node 22 und 24 kennzeichnen diese Funktion weiterhin als experimentell. Ein Node-Upgrade sollten Sie daher testen und nicht voraussetzen.

Das ändert sich durch den Speicher tatsächlich auf dem Rechner: Eingefügte Erinnerungen werden bei jeder Anfrage in den System-Prompt übernommen. Ein Budget von 2000 Zeichen entspricht bei jeder einzelnen Anfrage dauerhaft einigen hundert zusätzlichen Input-Tokens. Das verursacht reale Kosten. Deshalb gehört dsh-budget auf den Server, bevor Sie dsh-memory installieren. Halten Sie promptMaxChars klein und bereinigen Sie den Speicher mit memory_forget, statt die Datei unkontrolliert wachsen zu lassen.

Der alternative Build speichert Erinnerungen in einer YAML-Datei und führt eine Embedding-Suche mit automatischer Prompt-Injektion durch. Installiert wird er mit dsh plugin --profile web add github:towzai/dsh-memory. Dafür benötigen Sie eine lokale ollama-Instanz und ein Embedding-Modell, standardmäßig qwen3-embedding:0.6b, das Sie mit DSH_MEMORY_EMBED_MODEL überschreiben können. Die semantische Suche liefert bessere Ergebnisse als eine Schlüsselwortsuche. Dafür benötigen Sie einen zweiten Dienst sowie einen Satz residenter Modellgewichte auf demselben Server. Bei einem kleinen Tarif belegt das Arbeitsspeicher, den Sie eigentlich für die Aufgabe gemietet haben. Wählen Sie diese Variante, wenn ausreichend RAM verfügbar ist. Der allgemeine Zielkonflikt zwischen Recall-Qualität und dem Ressourcenbedarf residenter Komponenten wird unter lokaler Speicher für Agenten erläutert.

dsh-web-lan-access: 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. Daher schlägt das Laden derselben Seite über unverschlüsseltes HTTP von einem anderen Rechner fehl. dsh-web-lan-access behebt das Problem, indem es webServer.tapIndex verwendet, um ein kleines Polyfill einzuschleusen, und die Server-Bindung auf 0.0.0.0 umstellt.

Lesen Sie vor der Installation die zugehörige Warnung. Durch die Bindung an 0.0.0.0 ist der Agent für alle Personen im selben lokalen Netzwerk (LAN) ohne Authentifizierung erreichbar. Auf einem Server mit öffentlicher IP-Adresse bedeutet das, dass das gesamte Internet darauf zugreifen kann. Eine kurze Liste sensibler Methoden (settings.*, credentials.*, llm.discoverModels) bleibt an Loopback gebunden und liefert bei Anfragen von entfernten Ursprüngen den Status 403 zurück. Das begrenzt den Schaden, verhindert ihn aber nicht, weil die Oberfläche zum Aufrufen von Tools weiterhin für jeden offen ist, der den Port findet.

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 im lokalen Browser. Das Harness lauscht weiterhin nur an Loopback. Dadurch wird nichts nach außen freigegeben. Da Browser 127.0.0.1 als sicheren Ursprung behandeln, ist crypto.randomUUID() verfügbar und kein Polyfill erforderlich. Ein Befehl, kein Plugin, keine zusätzliche Angriffsfläche.

Installieren Sie das Plugin nur, wenn eine Weiterleitung nicht ausreicht, beispielsweise wenn ein Telefon im selben Netzwerk auf die Oberfläche zugreifen muss. Binden Sie es in diesem Fall hinter einer privaten Netzwerkschnittstelle, lassen Sie eine Firewall-Regel bestehen, die nur diese Schnittstelle zulässt, und tragen Sie die verwendeten Namen unter trustedHosts im Eintrag web-runtime ein. Für echten Zugriff durch mehrere Benutzer gibt es dsh-passwords. Es bietet Berechtigungen für Unterbenutzer, stündliche Token- und tägliche Zeitkontingente pro Unterbenutzer, automatische TLS-Zertifikate (Transport Layer Security) über Let's Encrypt sowie ein verschlüsseltes Audit-Log. Bewerten Sie es als Plattform und nicht 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. Bevorzugen Sie npm install -g dsh-passwords gefolgt von dsh-passwords install. Dadurch liegt der Code auf der Festplatte und kann vor der Ausführung gelesen werden.

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 das Plugin nicht mehr anzeigen. Öffnen Sie anschließend $DSH_HOME/profiles/web/cordis.patch.yml und löschen Sie alle verbliebenen 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 den Harness neu starten. Denken Sie außerdem daran, dass Daten länger als der Code bestehen bleiben. $DSH_HOME/memory/memory.db und .dsh/rules.yaml bleiben bei einer Deinstallation erhalten. Löschen Sie sie selbst, 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 zum Zeitpunkt Ihrer Lektüre bereits anderen Code enthalten wird. Ich habe den gesamten Inhalt am 17. August 2026 gelesen. Das Harness selbst stand an diesem Tag auf npm bei 0.1.0-rc.7.

Exakte Commits hinter dieser Auswahl
  • Die Liste der Community-Plugins auf f2918fb, 17. August 2026. Mit Absicht nur einmal verlinkt. Sie ist ein Verzeichnis, keine Empfehlung.
  • dsh-budget auf 461d478, 17. August 2026. Apache 2.0. Gibt dsh 0.1.0-rc.6 sowie Node 22.19 oder höher vor.
  • dsh-permission-rules auf b30b4fb, 17. August 2026. Apache 2.0. Gibt dsh 0.1.0-rc.5 bis 0.1.0-rc.6 vor.
  • dsh-defend auf 7ba3427, 17. August 2026. Apache 2.0. Gibt dsh 0.1.0-rc.6 vor.
  • dsh-memory auf def7c6a, 13. August 2026. MIT. SQLite-Build.
  • dsh-web-lan-access auf e27e909, 16. August 2026. MIT.

Prüfen Sie diese Pins erneut, bevor Sie einen Befehl kopieren. In einem Entwickler-Preview-Ökosystem ist eine Versionsnummer mit Datum die einzige Angabe, die aussagekräftig ist.

FAQ

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

Installieren Sie zuerst dsh-budget und dsh-permission-rules. Ein Budget mit overLimit: block verhindert, dass ein unbeaufsichtigter Lauf die ganze Nacht weiterläuft und Kosten verursacht. 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ühren zusätzlichen Code mit den Berechtigungen Ihres Agents aus, ohne das Verhalten des Systems 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 Modell-Credentials und im selben Arbeitsbaum. Ein Plugin, das sich in tools/pre-execute einklinkt, kann jeden Tool-Aufruf sehen und blockieren. Ein Plugin, das sich in agent/pre-step einklinkt, 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 nur?

Das hängt von overLimit ab. Die Standardeinstellung ist alert. Sie warnt bei warnRatio und lässt weitere Ausgaben zu. block lehnt weitere Modellaufrufe ab, sobald ein Limit erreicht ist. /budget unblock <scope> hebt dieses Limit auf, wenn Sie den Lauf fortsetzen. degrade wechselt anhand der degradation-Zuordnung zu einem günstigeren Modell. Es gibt eine wichtige Einschränkung: Die Summen werden im laufenden Prozess aus dem Sitzungsereignisstrom aggregiert. Ein Neustart des Harness setzt sie daher zurück. Eine Neustartschleife kann ein Tageslimit dadurch umgehen. Setzen Sie beim Provider ein Ausgabenlimit als 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. Dieser Eintrag lädt das Plugin. 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 bis zu ihrer manuellen Löschung erhalten.

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. dsh-web-lan-access ändert diese Bindung in 0.0.0.0. Die README des Plugins weist darauf hin, dass der Agent dadurch für alle Geräte im selben Netzwerk ohne Authentifizierung erreichbar ist. Bei einer öffentlichen IP-Adresse gilt das für das Internet. Einige Methoden (settings.*, credentials.*, llm.discoverModels) bleiben an Loopback gebunden und liefern bei entfernten Ursprüngen 403 zurück. Das begrenzt den möglichen Schaden, verhindert die Erreichbarkeit aber nicht vollständig. 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 eine Firewall-Regel. Richten Sie eine echte Authentifizierung ein, bevor der Dienst von außerhalb erreichbar ist.