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 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 Quellformate: einen einfachen npm-Paketnamen, einen Bereichsnamen wie @towzai/dsh-memory, eine GitHub-Referenz wie github:PerryLink/dsh-budget#main und einen lokalen Pfad mit link: oder ./. Verwenden Sie möglichst das GitHub-Format, weil Sie #main durch einen Commit ersetzen können und im nächsten Monat denselben Code erhalten.

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 --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 zu sein scheint, aber nichts bewirkt, ö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 hat das npm-Paket @deepseek-ai/dsh die Version 0.1.0-rc.7. Jedes nachfolgend aufgeführte Plugin deklariert dagegen Kompatibilität mit 0.1.0-rc.5 bis 0.1.0-rc.6. Diese Lücke ist in diesem Ökosystem normal. Sie ist der häufigste Grund dafür, dass ein Plugin nicht mehr geladen wird: Der Harness entwickelt sich schneller als die umgebenden Plugins. Aktualisieren Sie den Harness gezielt 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 eingerichtet, aber darin liegt auch das Risiko. dsh-budget erfasst Tokens und geschätzte Kosten pro 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 persönlichen Server sind sie hoch genug, dass eine außer Kontrolle geratene Schleife endet, bevor die Obergrenze greift. Senken Sie sie 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 vorgeschlagene Spalte ist ein Ausgangspunkt für einen Administrator auf einem einzelnen Server, keine veröffentlichte Richtgröße. Erhöhen Sie den Wert, wenn die tatsächliche Nutzung eines Monats dies nahelegt. Eine monatliche Obergrenze von 40 USD zusammen mit einer Sitzungsobergrenze von 2 schlägt früh und eindeutig fehl. Das ist sinnvoll, solange Sie noch lernen, wie viel das Tool 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. Damit wird eine Warnung ausgegeben, aber die Ausgaben laufen weiter. Standardmäßig ist dieses Plugin daher ein Dashboard. Setzen Sie den Wert auf block. Dann verweigert das Harness weitere Modellaufrufe, sobald eine Obergrenze erreicht ist. Ein nächtlicher Job wird dadurch beendet, statt bis zum Morgen 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 Job abgeschlossen werden muss, aber nicht Ihr leistungsfähigstes Modell benötigt. warnRatio verwendet standardmäßig 0.8. Sie werden daher bei 80 Prozent der Obergrenze informiert.

Es gibt zwei wichtige Einschränkungen. Die Kosten werden anhand der von Ihnen eingetragenen Preise berechnet: prices ist standardmäßig leer, und defaultPrice verwendet ersatzweise 1.0 USD pro Million Eingabetokens und 3.0 USD pro Million Ausgabetokens. 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 bildet das Plugin die Summen im laufenden Prozess anhand des Sitzungsereignisstroms. Die Summen werden daher beim Neustart des Harness zurückgesetzt. Eine Absturzschleife oder ein Supervisor, der dsh neu startet, setzt eine Tagesobergrenze zurück. Betrachten Sie dsh-budget als Schutz gegen Ihre eigenen Jobs. Setzen Sie beim Anbieter zusätzlich ein Ausgabenlimit. Dieses Limit ist die tatsächliche Obergrenze. Das ist das weiter gefasste Thema in AI-Agent-Kosten 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 dem tools/pre-execute-Ablauf fest. Dadurch 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. Zusätzlich gibt es ein globales fallbackPath und ein optionales searchUp, um auf dem Pfad in Richtung Dateisystemwurzel nach oben zu gehen. Das Matching umfasst Globs für Tool-Namen, Globs für Parameter-Schlüssel und -Werte, Globs für pfadbezogene Angaben relativ zum Workspace, Agent-Auswahlen 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"

Bei der Auswertung gilt die erste passende Regel. Ein weit gefasstes allow am Anfang setzt daher unbemerkt alle engeren Regeln darunter außer Kraft. Schreiben Sie die Verweigerungen zuerst und die freigebenden 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 bereitgestellt werden. Das ist relevant, sobald Sie MCP-Server auf einem VPS betreiben.

Planen Sie ein Verhalten ein: ask benötigt eine antwortende Instanz. Bei einem headless-Profil beobachtet möglicherweise niemand den Ablauf. 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 echten Antwortpfad. Darum geht es in Genehmigungen für Aktionen von AI-Agenten erzwingen.

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 das Plugin mit einer expliziten Quelle, damit Sie genau 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 sowie memory_forget bereit. Die Suche verwendet Schlüsselwörter für den gespeicherten Text und die Tags. Es gibt keinen Embedding-Dienst, keinen API-Key und keinen zusätzlichen Prozess.

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

Die Konfiguration, die Sie anpassen, ist klein: 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 Rechner: Eingefügte Erinnerungen werden bei jeder Interaktion in den System-Prompt aufgenommen. Ein Budget von 2000 Zeichen entspricht bei jeder einzelnen Anfrage dauerhaft einigen hundert zusätzlichen Input-Tokens. Das erscheint real auf Ihrer Abrechnung. Deshalb sollte dsh-budget auf dem Server vorhanden sein, bevor Sie dsh-memory installieren. Halten Sie promptMaxChars klein und bereinigen Sie 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 Prompt-Injektion durch. Installiert wird sie mit dsh plugin --profile web add github:towzai/dsh-memory. Sie benötigt 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 Treffer als eine Schlüsselwortsuche. Dafür benötigen Sie einen zweiten Dienst und einen Satz von Modellgewichten, die auf demselben Server im Arbeitsspeicher liegen. Bei einem kleinen Tarif fehlt dieser Speicher dann für die eigentliche Arbeit, für die Sie den Server gemietet haben. Wählen Sie diese Variante, wenn ausreichend RAM verfügbar ist. Der allgemeine Zielkonflikt zwischen Trefferqualität und dauerhaftem Ressourcenverbrauch wird unter lokaler Speicher für Agents 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. Deshalb 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 nutzt, um ein kleines Polyfill einzuschleusen. Außerdem ändert es die Server-Bindung auf 0.0.0.0.

Lesen Sie vor der Installation die eigene Warnung. Durch die Bindung an 0.0.0.0 ist der Agent für jeden im selben lokalen Netzwerk (LAN) ohne Authentifizierung erreichbar. Auf einem Server mit öffentlicher IP-Adresse bedeutet 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 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. 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 und es wird kein Polyfill benötigt. Ein Befehl, kein Plugin, keine neue Angriffsfläche.

Installieren Sie das Plugin nur, wenn eine Weiterleitung nicht ausreicht, beispielsweise wenn ein Telefon im selben Netzwerk die Oberfläche erreichen 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 gewünschten Namen unter trustedHosts im Eintrag web-runtime ein. Für echten Mehrbenutzerzugriff gibt es dsh-passwords. Es ergänzt 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, wo Sie ihn vor der Ausführung prüfen 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 zum Zeitpunkt Ihrer Lektüre bereits anderen Code enthalten wird. Ich habe alle Inhalte am 17. August 2026 gelesen. Das Harness selbst stand an diesem Tag auf npm bei 0.1.0-rc.7.

Prüfen Sie diese Pins erneut, bevor Sie einen Befehl kopieren. In einem Ökosystem mit Developer Preview ist eine Versionsnummer zusammen mit einem Datum die einzige Angabe, die wirklich aussagekräftig 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 des Computers 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 nur?

Das hängt von overLimit ab. Standardmäßig ist alert aktiviert. Es warnt bei warnRatio und setzt die Ausgaben fort. block lehnt weitere Modellaufrufe ab, sobald ein Limit erreicht ist, und /budget unblock <scope> hebt dieses Limit auf, wenn Sie den Vorgang fortsetzen möchten. degrade wechselt anhand der Zuordnung degradation 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 somit umgehen. Legen Sie beim Anbieter ein Ausgabenlimit als tatsächliche Obergrenze fest.

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 auf die Festplatte geschriebene Daten bleiben erhalten: $DSH_HOME/memory/memory.db und .dsh/rules.yaml überstehen die Deinstallation, bis Sie sie selbst löschen.

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

Nicht ohne zusätzliche Absicherung. dsh web lauscht auf 127.0.0.1:3080, und dsh-web-lan-access ändert diese Bindung in 0.0.0.0. In der eigenen README wird darauf hingewiesen, dass der Agent dadurch für alle Benutzer im selben Netzwerk ohne Authentifizierung erreichbar ist. Bei einer öffentlichen IP-Adresse bedeutet das, dass er aus dem Internet erreichbar ist. Einige Methoden (settings.*, credentials.*, llm.discoverModels) bleiben an Loopback gebunden und geben bei entfernten Ursprüngen 403 zurück. Das begrenzt den möglichen Schaden, verhindert den Zugriff 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 ergänzen Sie eine Firewall-Regel. Richten Sie eine echte Authentifizierung ein, bevor der Dienst von außerhalb erreichbar ist.