73 Patches, Geld-zurück-Garantie bei durch Modifikation verursachten Funktionsstörungen: Das Open-Source-Plugin DSH Unbound gibt dir die Kontrolle über die KI-Tools zurück
Lokale KI-Programmierwerkzeuge wie DeepSeek Harness werden zunehmend in den täglichen Workflow von Entwicklern integriert. Die Verhaltensgrenzen dieser Tools – welche Prompts verwendet werden, welche Aktionen zugelassen werden und wie man zu einem fehlerhaften Zustand zurückkehrt – werden größtenteils einseitig vom Hersteller festgelegt. Ein Bachelorstudent des Jahrgangs 2027 hat ein Open-Source-Plugin entwickelt, um diese Kontrolle an die Nutzer zurückzugeben.
1. Die fest kodierte Konfigurationsebene
Die Fähigkeitsgrenzen von KI-Programmierwerkzeugen sind größtenteils im Code festgeschrieben.
Am Beispiel von DeepSeek Harness: Es ändert zur Laufzeit Prompts, legt Genehmigungsschwellen fest und definiert den Gültigkeitsbereich der Sandbox. Nutzer können nur Schalter in der Oberfläche anpassen, die Parameter, die das tatsächliche Verhalten bestimmen, sind für normale Nutzer nicht zugänglich.
Die Probleme konzentrieren sich auf drei Bereiche: System-Prompts sind vom Host fest kodiert, sodass Teamrichtlinien nicht umgesetzt werden können; Genehmigungsgranularität, Sandbox-Bereich und Tool-Pfade werden von der oberen Ebene festgelegt, es gibt keine mittleren Einstellungen; Verhaltensänderungen durch Versionsupgrades können nicht teilweise rückgängig gemacht werden.
„Viele Nutzer verwechseln die Host-Interzeption fälschlicherweise mit einer Ablehnung durch das Modell“, sagt der Projektentwickler. Wenn diese beiden Ebenen vermischt werden, ist selbst die Fehlersuche sehr schwierig.
Diese Fehlausrichtung ist besonders offensichtlich in Szenarien der Sicherheitsbewertung – wenn man nicht unterscheiden kann, ob das Modell selbst eine Aktion abgelehnt hat oder der Host sie dazwischen blockiert hat, ist das Bewertungsergebnis bedeutungslos.
2. Die Konfigurationsebene herauslösen, um ein rückgängigmachbares Patch-System zu erstellen
Der Ansatz von DSH Unbound besteht darin, eine unabhängige Konfigurationsverwaltung über dem Host hinzuzufügen, um das ursprünglich vermischte Verhalten zu trennen.
Der erste Teil ist die Prompt-Injektion, die für das Speichern und Wiederherstellen von System-Prompts zuständig ist und Kontextverknüpfungssegmente in Gespräche injiziert. Die Konfiguration wird lokal gespeichert und überschreibt bei der Installation keine vorhandenen Inhalte des Nutzers.
Der zweite Teil ist die Patch-Verwaltung, der umfangreichste Teil des gesamten Projekts – 73 klassifizierte Patches, bei denen für jeden der aktuelle Status angezeigt werden kann und die einzeln angewendet oder wiederhergestellt werden können. Alle Patches sind idempotent, wiederholte Ausführungen führen zu keiner Überlagerung; vor der Anwendung wird automatisch das Original gesichert, sodass bei Fehlern zurückgekehrt werden kann; nach einem Upgrade wird übersprungen, wenn der Originaltext nicht übereinstimmt, sodass keine Dateien willkürlich geändert werden.
Der dritte Teil ist die Ausführungssteuerung, die Genehmigungsrichtlinien, Sandbox-Bereiche, Tool-Pfade und Hooks-Verarbeitung in die Konfigurationsebene schreibt, die von der Oberfläche überschrieben werden kann, ohne Umgebungsvariablen zu sperren.
Der vierte Teil ist der Übungsarbeitsbereich, der 10 Module wie Asset-Mapping, Umgebungskonfiguration, Agenten und Sitzungstunnel enthält. Die Daten werden in der lokalen SQLite gespeichert und sitzungsübergreifend gemeinsam genutzt. Dieser Teil ist auf Codeebene von den ersten drei Teilen entkoppelt und kann separat angepasst werden.
Technisch wurde ein Kompromiss eingegangen: Keine Laufzeitabhängigkeiten. Abgesehen von dem vom Host bereitgestellten Framework-Paket werden alle anderen Komponenten mit integrierten Node-Modulen implementiert.
„Für die Installation ist keine Internetverbindung zum Abrufen von Abhängigkeiten erforderlich, es besteht kein Risiko für die Lieferkette, und das Tool kann direkt in Intranetumgebungen verwendet werden“, sagt der Projektentwickler. Der Nachteil ist, dass einige Funktionen selbst geschrieben werden müssen, z. B. der SQLite-Zugriff sowie Komprimierung und Entpackung; der Vorteil liegt in der Bereitstellungssicherheit – es läuft sofort nach der Installation und stürzt nicht aufgrund von Konflikten bei Abhängigkeitsversionen ab.
Um den Übergang von „funktionsfähig“ zu „überprüfbar“ zu schaffen, hat das Projekt 22 Regressionsprüfungen eingerichtet, die kritische Pfade wie Prompt-Kompatibilität, Sicherungsintegrität, Statusbestimmung, Diagnoseexport und Plugin-Registrierung abdecken und automatisch auf vier Matrizen aus Windows, Linux sowie Node 20 und 22 ausgeführt werden. Alle Prüfpunkte sind prüfbar und reproduzierbar und erfordern keine manuelle Beurteilung.
Darüber hinaus verwendet der Diagnoseexport einen Feld-Whitelist-Mechanismus, die Ausgabedaten enthalten keine privaten Prompts, Anmeldeinformationen, Zieladressen oder ursprünglichen Pfade, und standardmäßig erfolgt kein automatischer Upload.
3. Open Source, kostenlos und keine Absicht, Gebühren zu erheben
Das Projekt ist unter der MIT-Lizenz Open Source, Code und Installationspaket sind vollständig öffentlich: 66 Moduldateien, 53.158 Codezeilen, 31 Dokumente, das Installationspaket hat eine Größe von 909 KB.
Es gibt keine kostenpflichtige Version, keine Enterprise-Version und keine kommerziellen Lizenzen.
Diese Entscheidung hat zwei Gründe. Erstens die Lizenz der oberen Ebene – das Projekt basiert auf einem anderen Open-Source-Plugin namens dsh-purge, das ausdrücklich verlangt, dass bei Weiterentwicklungen die Namensnennung erfolgt und der kommerzielle Verkauf verboten ist. Dieses Projekt hält sich an die strengeren Anforderungen und behält die vollständigen Urheberrechtshinweise und Quellenangaben der oberen Ebene bei. Zweitens die Produkteigenschaft – der Wert eines Konfigurationsverwaltungstools liegt in seiner Nutzbarkeit, nicht in seiner Knappheit.
„Um kontinuierlich verbessert zu werden, müssen mehr Menschen es verwenden“, sagt er. Kostenpflichtige Angebote würden die Reichweite direkt stark einschränken.
Die Zielnutzer gliedern sich in drei Gruppen: Einzelentwickler, die eine stabile Arbeitsumgebung benötigen, kleine technische Teams, die konsistente Konfigurationen verlangen, sowie Sicherheitsforschungs- und Lehrszenarien, die reproduzierbare Übungsumgebungen benötigen.
Derzeit befindet sich das Projekt in der Version v1.0.0, das Team besteht aus nur einer Person. Der Entwickler ist ein eingeschriebener Bachelorstudent des Jahrgangs 2027, der Praxiserfahrung im Betrieb von KI-Produkten hat und täglich mit KI-Agenten und AIGC-Werkzeugketten arbeitet. Anforderungsdefinition, Codeentwicklung, Testvalidierung, Dokumentationserstellung, Veröffentlichung und Wartung des Projekts werden vollständig von ihm alleine durchgeführt.
Die nächsten Pläne bestehen darin, die Anpassung an weitere Host-Versionen zu erweitern, Dokumente zu häufig gestellten Fragen zu ergänzen und externe Mitwirkende einzubeziehen, um das Risiko der Wartung durch eine einzelne Person zu senken. Das Projekt sucht keine Finanzierung.
„Was am meisten fehlt, ist nicht Geld, sondern dass Menschen es tatsächlich verwenden und mir mitteilen, was nicht funktioniert.“
Projektinformationen
Projektname: DSH Unbound
Projektausrichtung: Laufzeiterweiterung für DeepSeek Harness, bietet Prompt-Injektion, lokale Patches, Ausführungssteuerung und Übungsarbeitsbereich
Veröffentlichungsdatum: Oktober 2026
Aktuelle Version: v1.0.0
Open-Source-Lizenz: MIT (nicht kommerziell, keine kostenpflichtigen Versionen)
Technologie-Stack: Node.js / JavaScript, keine Laufzeitabhängigkeiten
Team: 1 Person (Projektinitiator / unabhängiger Entwickler)