Ein kleines Plugin mit DeepSeek Harness Creator bauen
DeepSeek-V4 Team · 8. Oktober 2026 · 6 min read
Ein nützliches erstes Harness-Plugin hat eine klar umrissene Aufgabe und ein sichtbares Ergebnis. Ein Panel, das eine feste Projektcheckliste anzeigt, ist eine bessere Lernübung als eine Erweiterung, die gleichzeitig Dateien bearbeitet, externe Dienste aufruft und Anmeldeinformationen verwaltet. Wenn die kleine Version funktioniert, haben Sie eine Grundlage für weitere Änderungen.
Harness dsh-v0.2.1-alpha.1, veröffentlicht am 3. Oktober 2026, fügt einen Plugin-Manager-Eintrag hinzu, der den Creator-Modus mit einem vorbereiteten Entwurf öffnet. Dieses Tutorial verwendet diesen Workflow, um ein lokales Plugin zu entwerfen und zu prüfen. Die Schritte folgen der versionsgebundenen Dokumentation; das Beispiel ist ein Akzeptanztest, keine Behauptung, dass ein generiertes Paket bereits einen Live-Harness-Test bestanden hat.
Bereiten Sie einen Arbeitsbereich vor, den Sie prüfen können
Verwenden Sie eine Installation, deren Version Sie überprüft haben, einen konfigurierten Modellanbieter und ein leeres Verzeichnis für diese Übung. Wenn Harness neu für Sie ist, absolvieren Sie zunächst den lokalen Schnellstart. Halten Sie die Übung getrennt von der einzigen Kopie eines wichtigen Projekts.
Die Ausgabe sollte ein Plugin-Quellverzeichnis plus eine kurze Erklärung sein, wie diese Version von Harness es lädt. Bitten Sie den Agenten, den Paketeinstiegspunkt, die Abhängigkeiten und die Bundle-Konfiguration zu identifizieren, anstatt anzunehmen, dass eine einzelne TypeScript-Datei über den Plugin-Manager installierbar ist.
Wählen Sie ein konkretes Akzeptanzziel: ein Panel mit dem Titel Project checklist mit drei festen Zeilen. Die erste Version sollte keine Dateien automatisch entdecken oder Zustände speichern. Das sind vernünftige spätere Funktionen, aber jede fügt Verhalten hinzu, das überprüft und getestet werden muss.
Öffnen Sie den Creator und prüfen Sie den Entwurf
Öffnen Sie in der Seitenleiste Plugins. Verwenden Sie den Pfeil neben Add plugin, dann wählen Sie Let the agent create a plugin. Die Plugin-Manager-Referenz dokumentiert diese Aktion, wenn die relevante Preset-UI sie beisteuert.
Die Aktion öffnet den Creator-Modus. Sie startet die Generierung nicht, bis Sie die Anfrage senden. Überprüfen Sie den ausgewählten Arbeitsbereich und alle übernommenen Datei-, Ordner- oder Sitzungsreferenzen. Eine alte Referenz kann unbemerkt ändern, welches Projekt der Agent seiner Meinung nach modifizieren sollte.
Verwenden Sie eine Anfrage mit einem Ergebnis, das Sie zählen und prüfen können:
Erstellen Sie ein lokales Harness-Plugin für diesen leeren Arbeitsbereich. Zielen Sie auf die hier installierte Harness-Version und prüfen Sie die verfügbare Dokumentation, bevor Sie APIs wählen. Fügen Sie ein Project checklist-Panel mit genau drei statischen Zeilen hinzu: Review inputs, Inspect output, Record result. Verwenden Sie keine Netzwerkanfragen, Anmeldeinformationen, automatischen Dateischreibvorgänge oder Hintergrundtimer. Identifizieren Sie vor der Bearbeitung die Dateien, die Sie erstellen werden. Erklären Sie anschließend, wie Sie das lokale Bundle lädt und wie man es deaktiviert. Melden Sie jede Validierung, die Sie nicht ausführen konnten.
Die Einschränkungen halten die Übung klein. Sie machen auch unerwartete Abhängigkeiten leichter erkennbar. Ein Paket für ein statisches Panel hat wenig Grund, einen HTTP-Client oder einen Planungsdienst einzuführen.
Lesen Sie die generierte Struktur, bevor Sie sie installieren
Das offizielle First-Plugin-Tutorial erklärt das grundlegende Cordis-Modell: Ein Plugin exportiert eine apply-Funktion, und der Kontext, der daran übergeben wird, ist dort, wo Beiträge registriert werden. Der Kontext ist daher ein nützlicher Ausgangspunkt, um nachzuvollziehen, was der generierte Code tun wird.
Dieses einführende Beispiel ist kein vollständiges Rezept für ein verteilbares UI-Bundle. Fragen Sie für das generierte Panel den Agenten, den realen Einstiegspunkt bis zu seinem Registrierungs- und Rendering-Code zurückzuverfolgen. Es sollte möglich sein, zu erklären, warum jede Quelldatei existiert, ohne ein nicht verwandtes Tutorial zum Anwendungsframework lesen zu müssen.
Prüfen Sie auch das Paketmanifest und die Installationsskripte. Bestätigen Sie, dass Abhängigkeiten zur beabsichtigten Implementierung gehören, dass referenzierte Dateien existieren und dass Befehle das tatsächliche Projektverzeichnis verwenden. Wenn der Agent meldet, dass ein Build erfolgreich war, behalten Sie den Befehl und sein Exit-Ergebnis. Eine plausible Erklärung eines Builds ist nicht die Build-Ausgabe.
| Zu prüfendes Element | Zu suchende Hinweise |
|---|---|
| Einstiegspunkt | Das Manifest oder die Bundle-Konfiguration löst sich in eine reale Datei auf |
| Panel-Registrierung | Ein spezifischer Aufruf verbindet das Plugin mit seiner sichtbaren UI |
| Abhängigkeiten | Jedes hinzugefügte Paket hat einen erklärten Zweck |
| Lebenszyklus | Das Deaktivieren des Plugins entfernt seinen Beitrag sauber |
| Validierung | Befehle, Ergebnisse und verbleibendes ungetestetes Verhalten werden angegeben |
Installieren Sie das lokale Bundle und prüfen Sie die geladene Version
Kehren Sie zu Plugins → Add plugin zurück. Der Manager akzeptiert sowohl ein absolutes lokales Verzeichnis als auch Registry-Pakete und Git-Quellen. Verwenden Sie das Verzeichnis, das die generierten Installationsanweisungen als Bundle-Root identifizieren, nicht den verschachtelten Ordner, der zufällig eine Quelldatei enthält.
Lesen Sie die Installationsvorschau und den Vertrauenshinweis, installieren und aktivieren Sie dann die relevanten Bundle- oder Plugin-Zeilen. Der Manager unterscheidet installierte Bundles vom integrierten Inventar, das in Settings angezeigt wird. Wenn das Panel fehlt, prüfen Sie, ob die beabsichtigte Zeile aktiviert ist, bevor Sie den Quellcode ändern.
Behalten Sie die Paketidentität und die angezeigte Version bei Ihren Testnotizen. Das Oktober-Release verbessert die Versionsberichterstattung und die Sichtbarkeit der Codequelle. Ein älteres installiertes Paket kann ansonsten eine korrekte Bearbeitung wirkungslos erscheinen lassen. Die Überwachung des Entwicklungsverzeichnisses und das Ersetzen einer installierten Paketversion sind unterschiedliche Wege; letzteres erfordert weiterhin einen Neustart.
Testen Sie einen vollständigen Aktivierungs- und Deaktivierungszyklus
Aktivieren Sie zuerst das Plugin und prüfen Sie das Panel. Zählen Sie die Zeilen, prüfen Sie ihre Reihenfolge und prüfen Sie, ob der Text der Anfrage entspricht. Deaktivieren Sie dann das Plugin und bestätigen Sie, dass das Panel verschwindet. Aktivieren Sie es erneut und prüfen Sie, ob es einmal erscheint, ohne doppelten Eintrag oder verbliebenes Element.
Ändern Sie als Nächstes eine Zeile Text in der Quelle, unter Verwendung des dokumentierten Entwicklungsworkflow für das generierte Bundle. Prüfen Sie, ob das sichtbare Panel die Bearbeitung widerspiegelt. Wenn nicht, stellen Sie den geladenen Quellpfad und die Neustartanforderungen fest, bevor Sie den Agenten bitten, die Komponente neu zu schreiben.
Öffnen Sie schließlich die Anwendung erneut und wiederholen Sie die sichtbaren Prüfungen. Notieren Sie, welche Schritte bestanden wurden und welche einen Neustart benötigten. Diese Beobachtungen sagen Ihnen mehr über den tatsächlichen Lebenszyklus des Plugins als ein einzelner erfolgreicher Screenshot.
Diagnostizieren Sie Fehler auf der richtigen Ebene
Ein fehlendes Panel kann mehrere Dinge bedeuten: Das Paket wurde nicht aufgelöst, das Bundle wurde nicht aktiviert, die Registrierung ist fehlgeschlagen oder das Rendering ist fehlgeschlagen. Prüfen Sie diese Stufen in dieser Reihenfolge. Die einführende Cordis-Dokumentation merkt speziell an, dass ein Auflösungsfehler während des frühen Boots weniger offensichtlich sein kann, prüfen Sie also die Pfadschreibweise, wenn ein neuer Eintrag nichts zu tun scheint.
Achten Sie bei älteren Beispielen auf entfernte invariant-Exporte und die Änderung von der stats-Zeile des Nachrichteneingabefelds zu activity und usage. Dies sind versionspezifische Migrationsprobleme, die in den 0.2.1 Versionshinweisen beschrieben werden. Sie sind keine Gründe, Kompatibilitätsprüfungen pauschal zu deaktivieren.
Sobald das statische Panel besteht, fügen Sie eine Fähigkeit nach der anderen hinzu. Das Lesen einer ausgewählten lokalen Datei ist ein handhabbarer nächster Schritt, wenn der Pfad und das Fehlerverhalten explizit sind. Überlassen Sie Persistenz und externe Anfragen separaten Iterationen. Behalten Sie die funktionierende Minimalversion, sodass ein späterer Fehler mit etwas verglichen werden kann, das Sie tatsächlich funktionierend beobachtet haben.
Für den breiteren Upgrade-Kontext siehe die Harness 0.2.1 Übersicht. Wenn Ihr geplantes Plugin nur dazu dient, eine Erinnerung auszulösen, prüfen Sie zunächst den integrierten Automatisierungsworkflow; die Host-Anwendung bietet möglicherweise bereits das Planungsverhalten, das Sie benötigen.