Beginnen Sie bei der DeepSeek Harness Plugin-Entwicklung nicht mit einem großen Plugin-Paket. Ordnen Sie Ihre Erweiterung zuerst einem Ziel zu: Werkzeug, Modellanbieter, Oberfläche oder Workflow. Bauen Sie danach die kleinste prüfbare Version und testen Sie Konfiguration, Berechtigungen sowie Kompatibilität getrennt.

Für diese Woche ist die sinnvolle Reihenfolge klar: ein Szenario auswählen, ein isoliertes TypeScript-Projekt anlegen, es in einem eigenen Profil laden und anschließend unter einer sauberen Umgebung prüfen.

Dieser Beitrag richtet sich an Sie, wenn Sie interne Skripte als DeepSeek-Harness-Werkzeug bereitstellen, einen eigenen Modell-Endpunkt oder ein Team-Gateway anbinden oder für mehrere Entwickler eine einheitliche Remote-Umgebung und einen reproduzierbaren Abnahmeprozess benötigen. Wenn Sie dagegen nur die Weboberfläche reparieren möchten, ist eine Anleitung zur Fehlersuche bei der DeepSeek-Harness-Weboberfläche der passendere Einstieg.

Letzte Aktualisierung: 18.08.2026. Die technischen Angaben wurden an diesem Datum anhand des offiziellen Repository-Stands, der Architektur- und Entwicklungsdokumentation, der package.json sowie der Build-Hinweise geprüft. DeepSeek Harness befindet sich weiterhin in einer Developer Preview. APIs und Projektkonventionen können sich daher durch Änderungen im offiziellen master-Zweig verschieben. (Offizielles Repository)

01

Die Erweiterungsziele als erste Architekturentscheidung

DeepSeek Harness verwendet eine Plugin-Architektur. Der Agent setzt sich aus mehreren Komponenten zusammen, anstatt alle Funktionen in einer unveränderlichen Kernanwendung zu bündeln. Die offizielle Architektur beschreibt unter anderem Modelladapter, Werkzeugregistrierung, Sitzungsprotokoll und Agentenloop als erweiterbare Bausteine. Cordis stellt dafür einen gemeinsamen Kontext und die Verbindung zwischen den Komponenten bereit. (Architekturdokumentation von DeepSeek Harness)

Ordnen Sie Ihre Idee zunächst einer von vier Kategorien zu:

  1. Werkzeug-Plugin: Eine klar begrenzte Fähigkeit wie Dateisuche, Repository-Analyse, Datenbankabfrage oder Zugriff auf eine interne API.
  2. Modellanbieter-Plugin: Ein eigener Anbieter, ein Unternehmens-Gateway oder ein kompatibler Modell-Endpunkt mit eigener Modellliste.
  3. Oberflächen-Plugin: Eine Webansicht, ein Konfigurationsdialog, eine Statusanzeige oder eine andere Browserfunktion.
  4. Workflow-Plugin: Eine wiederkehrende Kombination aus Werkzeugen, Modellwahl, Freigaben und Konfigurationswerten.

Diese Einteilung entscheidet über mehr als den Ordnernamen. Sie legt fest, welche Berechtigungen erforderlich sind, wo Zugangsdaten geladen werden, ob Host- und Client-Code getrennt geprüft werden müssen und wie das Plugin wieder entfernt werden kann.

Entscheidungshilfe für die Plugin-Grenze

Verwenden Sie vor dem ersten Coding diese Bedingungen:

  • Wenn Ihre Erweiterung genau eine externe Fähigkeit bereitstellt, wählen Sie ein Werkzeug-Plugin. Beispiel: Ein Skript liest den Status eines Deployments und liefert ein strukturiertes Ergebnis.
  • Wenn Ihre Erweiterung Modelle, Anbieterparameter oder Endpunkte beschreibt, wählen Sie ein Modellanbieter-Plugin. Die Auswahl des Arbeitsablaufs gehört nicht in diesen Baustein.
  • Wenn eine Browseransicht, eine Remote-Schnittstelle oder clientseitige Ressourcen erforderlich sind, wählen Sie ein Oberflächen-Plugin und trennen Sie Host- und Client-Code.
  • Wenn mehrere bereits getestete Fähigkeiten in einer festen Reihenfolge zusammenarbeiten, wählen Sie ein Workflow-Plugin oder ein separates Profil.
  • Wenn zwei Funktionen unabhängig aktiviert, getestet und entfernt werden können, teilen Sie sie in mehrere Plugins auf.
  • Wenn zwei Funktionen dieselben Berechtigungen, dieselbe Konfiguration und denselben Lebenszyklus besitzen, kann ein gemeinsames Plugin vertretbar sein.
  • Wenn Sie die Grenze nicht eindeutig formulieren können, bauen Sie zuerst nur einen Registrierungsprototyp. Eine unklare Grenze ist ein Architekturproblem und kein Grund, mehr Code zu schreiben.

Ein einzelnes Paket ist nicht automatisch einfacher. Ein großes Plugin kann zwar zunächst weniger Paketverwaltung erzeugen, aber ein fehlender API-Schlüssel, ein Webfehler oder eine inkompatible Modellkonfiguration kann dann das gesamte Profil blockieren.

02

Das Werkzeug-Plugin als kleinster Prüfpfad

Für viele Teams ist ein Werkzeug-Plugin die beste erste Ausbaustufe. Sie können damit den Ladevorgang, die Registrierung, die Eingabevalidierung und den Fehlerpfad testen, ohne gleichzeitig die Modellschicht oder eine Webanwendung zu verändern.

Nehmen Sie ein internes Release-Skript als Beispiel. Die erste Version sollte nicht „den gesamten Release-Prozess automatisieren“. Sie sollte nur eine Operation anbieten, etwa den aktuellen Status eines Releases lesen. Schreiben, Freigeben und Zurückrollen können später als getrennte Fähigkeiten folgen.

Minimale Struktur für ein dsh-plugin

Die konkrete API kann sich während der Developer Preview verändern. Daher ist die folgende Struktur ein belastbares Projektgerüst, aber keine unveränderliche offizielle Vorlage:

mein-dsh-plugin/
├── package.json
├── src/
│   └── index.ts
├── patches/
│   └── plugin.patch.yml
├── test/
│   └── plugin.test.ts
├── README.md
└── .env.example

Die package.json beschreibt das Paket und gegebenenfalls seine dsh-spezifischen Rollen. Die offizielle Architektur nennt dsh.profile für Profil-Bundles und dsh.bundle für die zugehörige Bundle-Konfiguration. Der TypeScript-Einstiegspunkt montiert die Fähigkeit in den Cordis-Kontext. Der Patch enthält nur die Konfiguration, die Ihr Plugin tatsächlich ergänzen oder ändern muss. (Entwicklungsleitfaden)

Vermeiden Sie in der ersten Version mehrere imaginäre Erweiterungspunkte. Ein kleineres Paket macht drei Erfolgssignale sichtbar:

  • Laden: Das Plugin startet im vorgesehenen Profil ohne Modul- oder Abhängigkeitsfehler.
  • Erkennen: Die bereitgestellte Fähigkeit erscheint im erwarteten Registry- oder Kontextbereich.
  • Diagnose: Eine ungültige Eingabe, ein nicht erreichbarer Dienst oder eine verweigerte Berechtigung erzeugt eine konkrete Fehlermeldung.

Eine allgemeine Meldung wie „Plugin failed“ genügt nicht. Die Fehlermeldung sollte zeigen, welche Operation betroffen war, ob die Eingabe validiert wurde und ob der externe Dienst erreichbar war.

Eingabe- und Ausgabevertrag

Definieren Sie vor der Implementierung drei Punkte:

  1. Welche Eingaben sind zwingend erforderlich?
  2. Welche Werte werden normalisiert oder begrenzt?
  3. Welche Ausgabe darf ein aufrufender Agent zuverlässig erwarten?

Ein Statuswerkzeug könnte eine Repository-ID und eine Umgebung akzeptieren. Die Ausgabe sollte nicht aus einem unstrukturierten Logblock bestehen. Ein stabiler Vertrag mit Status, Quelle, Zeitstempel und optionaler Diagnose lässt sich später in einem Workflow verwenden, ohne freie Textantworten analysieren zu müssen.

Legen Sie diese Verträge in TypeScript-Typen fest. Das verhindert nicht jeden Laufzeitfehler, zeigt aber früh, wenn Eingaben oder Ausgaben an einer falschen Stelle verwendet werden. Bei der DeepSeek Harness Plugin-Entwicklung ist das besonders relevant, weil Host- und Client-Bereiche unterschiedliche Kontexte besitzen können.

03

Modellanbieter mit isolierter Geheimnisverwaltung

Ein Modellanbieter ist kein besonders umfangreiches Werkzeug-Plugin. Seine Aufgabe ist eine andere: Er stellt eine Verbindung her, beschreibt verfügbare Modelle und behandelt Anbieterparameter. Ein gewöhnliches Werkzeug nutzt dagegen einen bereits verfügbaren Modell- und Agentenkontext.

Halten Sie diese Zuständigkeiten getrennt. Sonst enthält das Werkzeug plötzlich eigene Modelllogik und wird schwer testbar. Umgekehrt sollte ein Anbieter nicht entscheiden, welcher Workflow gestartet oder welche interne API aufgerufen wird.

API-Schlüssel, Basis-URL und Modellkennung gehören nicht in TypeScript-Dateien und nicht in die Commit-Historie. Der offizielle Entwicklungsleitfaden beschreibt DEEPSEEK_API_KEY sowie die optionale Variable DEEPSEEK_BASE_URL; Tests mit echten API-Aufrufen können ohne gesetzten Schlüssel übersprungen werden. Zugangsdaten sollen aus der Umgebung oder aus einer gitignorierten .env-Datei geladen werden. (Umgebungsvariablen im Entwicklungsleitfaden)

Hinweis: Eine .env.example darf Variablennamen und Platzhalter enthalten. Eine echte .env gehört weder in das Paket noch in ein öffentliches Repository. Prüfen Sie vor jedem Commit die Diff-Datei und die CI-Protokolle auf versehentlich ausgegebene Geheimnisse.

Prüfen Sie bei einem eigenen Endpunkt drei Ebenen:

  • Verbindung: Ist der Endpunkt erreichbar und antwortet er mit dem erwarteten Protokoll?
  • Modellkatalog: Welche Modellnamen dürfen Nutzer auswählen?
  • Laufzeitverhalten: Wie werden Timeouts, Streaming, Fehlercodes und Wiederholungen behandelt?

Wenn ein Team-Gateway mehrere Modelle anbietet, sollte die Auswahl über Konfiguration oder Profile erfolgen. Schreiben Sie nicht für jede Umgebung einen separaten Quellcodezweig. Das erschwert die Prüfung und erhöht den Aufwand beim Rückrollen.

04

Host- und Client-Grenze bei Webfunktionen

Sobald Ihr Plugin eine Weboberfläche benötigt, steigt der Prüfaufwand. Sie testen dann nicht nur, ob ein Dienst registriert wird. Sie müssen auch sicherstellen, dass der Browser die richtige Ressource erhält und keine vertraulichen Daten im Client landen.

Die offizielle Projektstruktur trennt Host- und Client-Aggregate. Der Build verarbeitet diese Bereiche in einer bestimmten Reihenfolge: zunächst TypeScript und Host-Artefakte, danach den Client-Bereich und anschließend den Web-Build. Für neue Pakete ist diese Trennung wichtig, weil ein Client-Plugin während der Client-Phase zusätzliche Laufzeitartefakte erzeugen kann. (Entwicklungsdokumentation)

Prüfen Sie bei einem UI-Plugin mindestens:

  • Wird der Host-Dienst vor der Client-Ressource erzeugt?
  • Ist die Remote-Schnittstelle typisiert?
  • Sind nur die vorgesehenen Methoden erreichbar?
  • Bleiben API-Schlüssel ausschließlich auf der Host-Seite?
  • Funktioniert die Ansicht auch ohne vorhandene Daten?
  • Gibt es sichtbare Zustände für Ladefehler, Berechtigungsfehler und leere Ergebnisse?
  • Lässt sich die Oberfläche entfernen, ohne den Agentenloop zu beschädigen?

Bauen Sie nicht auf vermutete interne Implementierungen. Die Dokumentation bestätigt die Host- und Client-Aggregate sowie Remote-Projektionen. Sie garantiert aber nicht automatisch jede mögliche eigene UI-Komponente. Testen Sie daher nur gegen dokumentierte Schnittstellen und tatsächlich erzeugte Build-Artefakte.

Für ein kleines Team ist ein UI-Plugin meist erst dann sinnvoll, wenn der zugrunde liegende Dienst bereits als Werkzeug funktioniert. Andernfalls debuggen Sie gleichzeitig Kontextregistrierung, Remote-Aufruf, Browserzustand und Bundling.

05

Profile statt kopierter Workflow-Projekte

Ein Workflow-Plugin sollte nicht dazu führen, dass mehrere Entwickler dieselbe globale Harness-Konfiguration bearbeiten. Die Architektur beschreibt Profile als benannte Zusammensetzungen im Harness-Home. Sie enthalten Bundles, installierte externe Plugins und eine eigene cordis.patch.yml. web und headless werden als Vorlagen beschrieben. (Profile und Bundles)

Legen Sie für unterschiedliche Aufgaben getrennte Profile an:

  • Experiment: neue Plugins und häufige Änderungen ohne Stabilitätszusage.
  • Test: reproduzierbare Versionen, begrenzte Berechtigungen und feste Testendpunkte.
  • Daueraufgabe: möglichst wenige bewegliche Teile und konservative Konfigurationsänderungen.

Die Reihenfolge der Konfigurationsebenen muss dokumentiert werden. Bundles werden nach der Profildefinition, dem Profil-Patch, dem Home-Patch und einem möglichen --patch-Overlay verarbeitet. Ein Patch kann die vollständige Konfiguration einer Zielzeile ersetzen oder eine neue Zeile hinzufügen. Eine scheinbar kleine Änderung kann deshalb einen bestehenden Zielzustand verdrängen, wenn Sie ihn nicht vollständig beschreiben. (Architektur-Dokumentation)

Prüfen Sie das Ergebnis nicht nur anhand Ihrer Patch-Datei. Verwenden Sie den dokumentierten Dump-Befehl:

dsh --profile web --dump-config

Vergleichen Sie die Ausgabe zwischen Experiment-, Test- und Dauerprofil. Wenn ein Plugin im falschen Profil auftaucht, liegt der Fehler häufig nicht in der TypeScript-Registrierung, sondern in der Bundle- oder Patch-Reihenfolge.

Die offiziellen Entwicklungsbeispiele zeigen außerdem, dass ein Headless-Auftrag mit einem Profil gestartet werden kann:

pnpm dsh --profile headless "summarize this workspace"

Verwenden Sie solche Aufrufe erst nach einem erfolgreichen Build und mit einem dafür vorgesehenen API-Schlüssel. (Entwicklungsleitfaden)

06

FAQ zur Plugin-Entwicklung

Welche Erweiterungen sind für DeepSeek Harness geeignet?

Geeignet sind klar abgegrenzte Werkzeuge, Modellanbieter, Oberflächenfunktionen und Workflow-Zusammensetzungen. Beginnen Sie mit einer einzigen Verantwortung. Ein internes API-Skript gehört in ein Werkzeug-Plugin, ein eigener Modellkatalog in einen Anbieter und eine wiederkehrende Agentenkette in ein Profil oder Workflow-Plugin. Unabhängig aktivierbare Fähigkeiten sollten getrennt bleiben.

Wie laden Sie ein dsh-plugin reproduzierbar?

Verwenden Sie ein eigenes Profil, eine festgehaltene Paketversion und einen dokumentierten Patch. Prüfen Sie anschließend mit --dump-config, welche Bundles und Plugins tatsächlich geladen werden. Ein Repository-Topic wie dsh-plugin verbessert die Auffindbarkeit, ist aber keine Kompatibilitätsgarantie. Entscheidend bleiben der geprüfte Commit und die dokumentierte Laufzeitumgebung.

Warum sollten Host und Client in TypeScript getrennt bleiben?

Die offizielle Codebasis trennt Host- und Client-Projekte, weil beide Seiten unterschiedliche Kontexte und Verantwortlichkeiten haben. TypeScript zeigt früh, wenn ein Dienst im falschen Bereich verwendet oder ein Remote-Vertrag falsch aufgerufen wird. Zusätzlich benötigen Sie weiterhin Build-, Browser- und Berechtigungstests, da statische Typen keine Laufzeitfehler abdecken.

07

Fünf Schritte bis zur ersten prüfbaren Version

1. Erweiterungsgrenze festlegen

Schreiben Sie einen Satz: „Dieses Plugin stellt genau Fähigkeit X bereit.“ Ergänzen Sie Eingaben, Ausgaben, benötigte Berechtigungen und einen Rückbauweg. Wenn der Satz mehrere unabhängige Verben enthält, teilen Sie das Vorhaben auf.

2. Offiziellen Entwicklungsstand einfrieren

Notieren Sie den geprüften Commit, den Paketstand, die Node.js-Version und die pnpm-Version. Der Entwicklungsleitfaden nennt Node.js 22.19 oder neuer sowie Node.js 24 als unterstützte Entwicklungsbasis und pinnt pnpm@11.7.0 in der package.json. (Offizieller Entwicklungsleitfaden)

3. Minimales Paket erstellen

Erstellen Sie nur Einstiegspunkt, Konfiguration, Test und Dokumentation. Nutzen Sie TypeScript für Ein- und Ausgabeverträge. Verzichten Sie zunächst auf UI, mehrere externe Dienste und automatische Wiederholungen.

4. Eigenes Profil einrichten

Installieren Sie das Plugin nicht direkt in eine gemeinsam bearbeitete globale Konfiguration. Legen Sie ein Testprofil an, setzen Sie Geheimnisse über die Umgebung und prüfen Sie die resultierende Struktur mit dsh --profile <profil> --dump-config.

5. Fehlerpfade absichern

Testen Sie nicht nur den Erfolgsfall. Entfernen Sie den API-Schlüssel, verwenden Sie eine ungültige Eingabe, blockieren Sie den Zielendpunkt und entziehen Sie eine Berechtigung. Jede Variante muss mit einer Meldung enden, die ein Entwickler ohne Debugger einordnen kann.

08

Abnahme vor der Veröffentlichung

Vor der Veröffentlichung sollten Sie diese Punkte abhaken:

  • [ ] Typecheck auf einem sauberen Checkout.
  • [ ] Build der tatsächlich ausgelieferten Artefakte.
  • [ ] Start im vorgesehenen Profil.
  • [ ] Nachweis, dass die Fähigkeit gefunden und aufgerufen wird.
  • [ ] Test mit gültigen und ungültigen Eingaben.
  • [ ] Prüfung von Netzwerk-, Datei- und Modellberechtigungen.
  • [ ] Kontrolle, dass kein API-Schlüssel in Repository, Paket oder Log landet.
  • [ ] Installation in einer Umgebung ohne lokale Build-Artefakte.
  • [ ] Deinstallation und Rückkehr zum vorherigen Profilzustand.
  • [ ] Dokumentation von Commit, Paketstand und Prüfdatum.

Der offizielle Entwicklungsleitfaden nennt pnpm install, pnpm run typecheck und pnpm run build als zentrale Schritte für einen geprüften Checkout und den vollständigen Build. Zusätzlich werden CI-Prüfungen über mehrere Node.js-Versionen beschrieben. Die konkrete Abnahme Ihres Plugins hängt davon ab, ob es nur einen Dienst registriert oder auch Host-, Client- und Remote-Komponenten umfasst. (Entwicklungsleitfaden)

Veröffentlichen Sie während der Preview keine pauschale Aussage wie „kompatibel mit DeepSeek Harness“, wenn Sie nur einen einzelnen lokalen Commit getestet haben. Dokumentieren Sie stattdessen den geprüften Commit, die Paketversion, das Zielprofil, die Node.js-Version, die Berechtigungen und das Datum der letzten Prüfung. Die offizielle README weist ausdrücklich auf inkompatible Änderungen während der Developer Preview hin.

09

Wann sich eine verwaltete Mac-Umgebung lohnt

Für einen einzelnen Prototyp genügt Ihr vorhandener Rechner häufig. Der Bedarf verändert sich, sobald Sie Builds regelmäßig wiederholen, mehrere Profile parallel prüfen, Host- und Client-Artefakte vergleichen oder mehreren Entwicklern dieselbe Umgebung bereitstellen müssen.

Eine rein lokale Lösung hat dann drei typische Schwächen: Sie hängt an einem einzelnen Gerät, Abweichungen bei Node.js-, pnpm- oder Umgebungsvariablen bleiben lange unentdeckt und ein unterbrochener Rechner blockiert die gemeinsame Abnahme. Ein eigener physischer Mac beseitigt diese Abhängigkeiten, verursacht aber Anschaffung, Wartung und eine feste Auslastung.

Für kurzfristige Plugin-Sprints, externe Mitarbeitende und wechselnde Testprofile kann eine gemietete Mac-Umgebung von VpsMesh die passendere Zwischenlösung sein. Sie erhalten einen remote erreichbaren Entwicklungsplatz, ohne für jede Preview-Phase zusätzliche Hardware dauerhaft zu kaufen. Prüfen Sie die Mac-Mietpreise von VpsMesh gegen Ihre tatsächliche Build-Frequenz, Teamgröße und Aufbewahrungsdauer.

Wenn Sie DeepSeek Harness dauerhaft mit hoher Auslastung betreiben, physische Schnittstellen benötigen oder eine langfristig identische Maschine abschreiben möchten, bleibt ein eigener Mac die ehrlichere Wahl. Für wiederkehrende Tests, Remote-Zugriff und zeitlich begrenzte Plugin-Entwicklung liegt der Vorteil dagegen in einer Umgebung, die Sie nach dem Sprint behalten, teilen oder wieder freigeben können.