DeepSeek Harness funktioniert in einem Kreislauf. Der Agent liest Ihren Arbeitsbereich, bearbeitet Dateien, führt Befehle über sein Bash-Tool aus und entscheidet basierend auf der Ausgabe, was als Nächstes zu tun ist. Warum sind Ihre API-Tests also nicht Teil dieses Kreislaufs? Sie befinden sich in Apidog hinter einer GUI und werden ausgeführt, wenn jemand daran denkt, darauf zu klicken. Der Agent greift nie auf sie zu.
Die Lösung ist ein einziger Konfigurationsblock. Die Apidog CLI ist ein npm-Paket, apidog-cli, das die in Apidog erstellten Testszenarien direkt von einem Terminal aus ausführt. Sobald die CLI installiert ist und DeepSeek Harness von ihrer Existenz weiß, führt der Agent ein Apidog-Szenario auf die gleiche Weise aus wie Ihre Unit-Tests: den Befehl ausführen, den Exit-Code lesen, den Code korrigieren, falls er rot ist (einen Fehler anzeigt).
Es gibt auch ein Token-Argument dafür. Ein Agent, der die Funktionsfähigkeit Ihrer API durch erneutes Lesen des Handler-Codes und die Analyse von Antwortstrukturen bestätigt, verbraucht bei jedem Durchlauf viel Kontext. Ein Agent, der einen Befehl ausführt, erhält die 'Ground Truth' in wenigen Zeilen zurück. Die CLI komprimiert die Frage „Ist die API korrekt?“ zu einem Exit-Code, und der Agent verwendet seinen Kontext stattdessen für die Fehlerbehebung.
Dieser Leitfaden behandelt den Harness-spezifischen Teil, den die generische Installationsanleitung überspringt: welche Anweisungsdatei DeepSeek Harness tatsächlich liest, wie sein Bash-Tool apidog run ausführt und wie der Kreislauf 'ehrlich' gehalten wird (d.h. korrekte Ergebnisse liefert). Wenn Sie die CLI noch nicht installiert haben, tun Sie dies zuerst. So installieren Sie die Apidog CLI mit einem KI-Codierungsagenten führt Sie durch die npm-Installation, Authentifizierung und den ersten Lauf. Dieser Artikel geht davon aus, dass apidog --version eine Nummer ausgibt und Ihr Rechner authentifiziert ist.
Worum es bei diesem DeepSeek Harness geht
DeepSeek Harness, in der Befehlszeile dsh, ist das Open-Source-Agenten-Harness, das DeepSeek am 13. August 2026 veröffentlichte, neben V4-Pro für die API. Es ist unter MIT-Lizenz veröffentlicht, befindet sich unter github.com/deepseek-ai/deepseek-harness und hatte bis zum 20. August über 169.000 Sterne erreicht. Sie starten es mit npx @deepseek-ai/dsh web, wodurch eine lokale Web-Benutzeroberfläche unter http://127.0.0.1:3080 bereitgestellt wird. Dort wählen Sie einen Arbeitsbereich aus – das Projektverzeichnis, in dem Sie es gestartet haben – und der Agent arbeitet darin: liest und bearbeitet Dateien, führt Befehle aus und fragt vor Operationen, die eine Genehmigung gemäß der aktiven Berechtigungsrichtlinie erfordern.
Zwei Dinge prägen alles Folgende. Erstens ist das Harness eine Entwicklervorschau. Die README warnt, in Großbuchstaben, dass es zu abwärtsinkompatiblen Änderungen kommen wird. Behandeln Sie Dateinamen und Konfigurationsschlüssel hier also als für Ende August 2026 zutreffend und überprüfen Sie sie gegebenenfalls anhand der Repo-Dokumentation, falls etwas nicht geladen wird. Zweitens ist alles in dsh ein Plugin, das auf der Cordis-Architektur aufbaut, was die folgende praktische Frage beantwortbar macht: Welches Plugin liest Ihre Projektregeln und wonach sucht es? Für einen umfassenderen Überblick siehe Was ist DeepSeek Harness; zum Vergleich mit dem etablierten Konkurrenten siehe DeepSeek Harness vs. Claude Code.
Schritt 1: die CLI in AGENTS.md einfügen
DeepSeek Harness liest Arbeitsbereichsanweisungen über sein @deepseek-ai/dsh-agent-instructions Plugin, und die Standardeinstellungen sind vertraut, wenn Sie andere Agenten verwendet haben. Gemäß der Plugin-Quelle und dem Konfigurationskatalog sucht der Loader vom Arbeitsverzeichnis der Session aufwärts bis zu Ihrem Projektstamm (gekennzeichnet durch .git) und lädt dabei in jedem Verzeichnis AGENTS.md, mit CLAUDE.md als Fallback. Lokale Overlays namens AGENTS.local.md oder CLAUDE.local.md werden nach den Basisdateien geladen, und eine feste benutzerglobale AGENTS.md in $DSH_HOME (standardmäßig ~/.dsh) gilt projektübergreifend. Dateien über 1 MiB werden ignoriert, eine Größe, die Ihre Regelsdatei niemals erreichen wird.
Das praktische Ergebnis: Wenn Ihr Repo bereits eine AGENTS.md für Codex oder eine CLAUDE.md für Claude Code enthält, übernimmt DeepSeek Harness diese ohne zusätzliche Einrichtung. Fügen Sie einen kurzen Apidog-Block hinzu:
## API testing with the Apidog CLI
- To test the API, run the Apidog scenario. Do not click through the GUI.
- Command: apidog run -t <scenario_id> -e <env_id> -r cli
- Exit code 0 means every assertion passed. Non-zero means a failure; read the report and fix the code.
- The machine is already authenticated. Never add an --access-token flag and never put a token in this file.
Deshalb ist die Regelsdatei dem Chat überlegen. Eine in den Session-Composer eingegebene Szenario-ID verschwindet, wenn die Session endet. Eine in AGENTS.md geschriebene ID wird in jede neue Session geladen, für jedes Teammitglied, auf jedem Rechner, der das Repo klont. Wenn Sie an mehreren Projekten arbeiten, vermittelt die benutzerglobale ~/.dsh/AGENTS.md die Gewohnheit („API-Änderungen immer mit dem apidog run-Befehl des Projekts überprüfen“), während die eigene Datei jedes Repos die echten IDs enthält.
Schritt 2: Den Befehl von Apidog abrufen
Sie müssen die Szenario- und Umgebungs-IDs nicht erraten. Öffnen Sie das Testszenario in Apidog, wechseln Sie zum CI/CD-Tab und kopieren Sie den generierten Befehl. Er sieht so aus:
apidog run -t 123456 -e 789012 -r cli
Der -t-Flag ist die Test-Szenario-ID, -e ist die Umgebungs-ID, und -r cli wählt den Reporter aus, der die Ergebnisse inline ausgibt, was genau das ist, was ein Agent lesen muss. Fügen Sie die echten IDs in Ihren AGENTS.md-Block ein, damit der Agent den von Apidog generierten Befehl ausführt und nicht eine Vermutung.
Schritt 3: Den Agenten den Test ausführen lassen
Starten Sie eine Session in der dsh Web-UI mit ausgewähltem Arbeitsbereich. Der Anweisungs-Loader hat Ihre AGENTS.md bereits in den Kontext des Agenten eingespeist, sodass dieser die Existenz der CLI kennt. Nehmen Sie eine Änderung vor, die Ihre API betrifft, oder fragen Sie einfach:
Run the Apidog test scenario and tell me the exit code.
Der Agent führt es über sein Bash-Tool aus, und zu wissen, wie sich dieses Tool verhält, erspart Ihnen später eine Debugging-Session. Gemäß dem Tool-Katalog führt das Standard-Bash-Tool jeden Befehl in einer neuen Shell aus: kein Arbeitsverzeichnis, keine Variablen oder Funktionen bleiben zwischen Aufrufen bestehen, und Befehle werden aus dem Session-Arbeitsbereich ausgeführt, es sei denn, ein workdir wird übergeben. Das ist in Ordnung für apidog run, einen einzelnen, in sich geschlossenen Befehl, aber der Agent kann nicht zuerst cd in ein Verzeichnis wechseln und den Test als zweiten Schritt ausführen. Wenn Ihr Szenario aus einem Unterverzeichnis ausgeführt werden muss, platzieren Sie den vollständigen Aufruf in einer Zeile in Ihrer Regelsdatei.
Zwei weitere Verhaltensweisen, die wissenswert sind. Nicht-Null-Exit-Codes werden als expliziter [exit code: N]-Marker zurückgegeben, sodass das Pass/Fail-Signal auch dann erhalten bleibt, wenn lange Ausgaben auf ihren Endteil gekürzt werden. Und Befehle können in einer Dateisandbox ausgeführt werden: Eine blockierte Operation wird als Richtlinienverweigerung gemeldet, nicht als Befehlsfehler. Ein reiner Lese-Testlauf löst dies selten aus, aber der HTML-Reporter, der nach ./apidog-reports schreibt, könnte dies tun, abhängig von der aktiven Richtlinie.
Ob der Lauf zuerst Ihre Bestätigung benötigt, hängt von derselben Berechtigungsrichtlinie ab. Die Web-UI fragt vor Operationen, die eine Genehmigung gemäß dieser Richtlinie erfordern, gemäß dem Benutzerhandbuch. Wenn es nach apidog run fragt, genehmigen Sie es: Ein Testszenario gegen Staging ist genau die Art von sicherem, meist lesendem Befehl, für den der Genehmigungsfluss existiert, um ihn durchzuwinken.
Schritt 4: Den Bericht lesen
Wenn ein Lauf fehlschlägt (rot wird), enthält der Bericht die Antwort. Mit -r cli erhält der Agent eine lesbare Aufschlüsselung inline: jede Anfrage, jede Assertion und welche mit erwartetem versus tatsächlichem Wert fehlschlug. Die fehlerhafte Assertion benennt das genaue Feld oder den Statuscode, was normalerweise ausreicht, damit der Agent die Korrektur findet, ohne dass Sie übersetzen müssen.
Für einen Bericht, den Sie in einem Browser öffnen oder einem Teamkollegen übergeben können, fügen Sie den HTML-Reporter hinzu:
apidog run -t 123456 -e 789012 -r cli,html
Der html-Reporter schreibt eine eigenständige Datei nach ./apidog-reports. Behalten Sie cli in der Liste, damit der Agent weiterhin die Inline-Ausgabe erhält, die er liest, um seinen nächsten Schritt zu entscheiden.
Der Kreislauf, End-to-End
Dies bringt Ihnen die Einrichtung ein. Angenommen, der Agent bearbeitet einen Checkout-Handler. Ohne die CLI endet sein Kreislauf bei „der Code sieht richtig aus“. Mit dem Block in AGENTS.md erweitert sich der Kreislauf: Er bearbeitet den Handler, führt apidog run -t 123456 -e 789012 -r cli aus und liest das Ergebnis. Grün (erfolgreich), fährt er fort. Rot (fehlerhaft), sieht er [exit code: 1], liest, welche Assertion fehlschlug (ein 500er, wo ein 200er erwartet wurde, ein fehlendes total-Feld, ein falscher Währungscode), patcht den Handler und führt es erneut aus. Die Überprüfung des API-Vertrags wird Teil desselben Bearbeiten-Testen-Beheben-Zyklus, den der Agent bereits für Ihre Unit-Tests durchläuft.
Beachten Sie, was der Agent *nicht* getan hat: Jede Routen-Datei neu gelesen, um sich selbst davon zu überzeugen, dass die API funktioniert. Das Szenario kodiert bereits das erwartete Verhalten, das visuell in Apidog von demjenigen erstellt wurde, der die API besitzt. Der Agent delegiert die Verifizierung an ein deterministisches Tool und verwendet seine Tokens dort, wo Urteilsvermögen gefragt ist. Diese Arbeitsteilung ist das ganze Muster: dsh schreibt Code, die CLI verifiziert die API-Schicht, und Sie erstellen Szenarien in Apidog, ohne überhaupt Testcode schreiben zu müssen.
Überprüfen Sie, ob dsh es tatsächlich ausgeführt hat
Agenten melden Erfolge, die sie nicht verdient haben, und ein Developer-Preview-Harness ist nicht der Ort, um Texten blind zu vertrauen. Drei Prüfungen, in der Reihenfolge, in der sie Probleme erkennen.
Zuerst bestätigen Sie, dass der Befehl ausgeführt wurde. Die dsh Web-UI zeigt die Tool-Aufrufe des Agenten und deren Ausgabe in der Session. Suchen Sie nach dem wörtlichen apidog run ... Bash-Aufruf und seinem Ergebnis. Wenn der Agent sagt, er hätte die Tests ausgeführt, aber kein solcher Aufruf erscheint, hat er etwas zusammengefasst, was er nie getan hat. Bitten Sie ihn, es erneut auszuführen und die Rohausgabe anzuzeigen.
Zweitens bestätigen Sie den Exit-Code. Fragen Sie direkt: „Was war der Exit-Code dieses apidog run-Befehls?“ Das Harness übergibt dem Agenten bei einem Fehler einen expliziten [exit code: N]-Marker, sodass es keine Mehrdeutigkeit gibt, hinter der man sich verstecken könnte. Wenn die Zusammenfassung des Agenten „Tests bestanden“ sagt, der Marker aber einen Wert ungleich Null anzeigte, hat der Marker Recht.
Drittens bestätigen Sie, dass das tatsächliche Szenario verwendet wurde. Ein „Szenario nicht gefunden“-Fehler bedeutet normalerweise, dass der Agent eine ID erfunden oder sich falsch erinnert hat. Überprüfen Sie die Werte für -t und -e anhand Ihres AGENTS.md-Blocks und des Befehls im CI/CD-Tab von Apidog. Die IDs in der Regelsdatei sind die Wahrheit; alles andere, was der Agent eingegeben hat, ist eine Vermutung.
Optional: Den Apidog MCP-Server für Spezifikationszugriff hinzufügen
Das Ausführen von Szenarien deckt die Verifizierung ab. Wenn Sie möchten, dass der Agent Ihre API-Spezifikation auch beim Schreiben von Code liest, ist das eine Aufgabe für MCP, und hier zählt das ehrliche Bild: Stand Ende August 2026 ist die MCP-Unterstützung nicht in der DeepSeek Harness Core README oder im Benutzerhandbuch dokumentiert. Was existiert, ist ein Community-Plugin, hyqhyq3/dsh-mcp-manager, das über das dsh-plugin GitHub-Thema wie der Rest des Ökosystems entdeckt wurde. Es fügt eine MCP-Seite unter Einstellungen hinzu, unterstützt entfernte HTTP- und lokale stdio-Server, registriert Tools als mcp__<name>__* und liest projektspezifische Serverdefinitionen aus <workspace>/.dsh/dshmm/mcp.json.
Darüber können Sie den Apidog MCP-Server verbinden, der Ihre API-Spezifikationen über MCP bereitstellt, damit der Agent das tatsächliche Schema eines Endpunkts überprüfen kann, *bevor* er den Handler schreibt, anstatt *nachdem* das Szenario fehlschlägt. Community-Plugin plus Entwicklervorschau-Host bedeutet, dass diese Kopplung bei Updates beider Seiten brechen kann, behandeln Sie es also als zusätzliche Ebene (Bonus). Der oben beschriebene CLI-Pfad ist der tragende: Er benötigt nichts außer einer Shell.
Vorschau-Vorbehalte und wohin die Reise geht
DeepSeek Harness entwickelt sich schnell und warnt Sie, dass es zu Brüchen kommen kann. Die Besonderheiten, die sich am ehesten ändern werden, sind die hier genannten: die Dateikandidaten des Anweisungs-Plugins, die Sandbox-Berichterstattung des Bash-Tools und alles, was das Community-MCP-Plugin berührt. Das Muster ist jedoch portabel. Eine Regelsdatei, die besagt „Überprüfen Sie die API mit diesem einen Befehl“, plus eine CLI, die einen sauberen Exit-Code zurückgibt, funktioniert heute in dsh aus demselben Grund, aus dem sie in Claude Code und jedem anderen Harness dieser Serie funktioniert: Agenten sind gut darin, Befehlsausgaben zu lesen, und schlecht darin, ohne diese vertraut zu werden.
Also: Laden Sie Apidog herunter, erstellen Sie visuell ein Testszenario, kopieren Sie den apidog run-Befehl aus dem CI/CD-Tab und fügen Sie den Block in die AGENTS.md-Datei ein, die Ihr Repo wahrscheinlich bereits enthält. Das nächste Mal, wenn DeepSeek Harness Ihren API-Code anfasst, wird es seine eigene Arbeit überprüfen, bevor es Ihnen mitteilt, dass es fertig ist.
FAQ
Liest DeepSeek Harness AGENTS.md nativ? Ja. Das @deepseek-ai/dsh-agent-instructions Plugin lädt AGENTS.md (oder CLAUDE.md als Fallback) aus Ihrem Projektstamm und den Verzeichnissen oberhalb des Arbeitsverzeichnisses Ihrer Session, sowie AGENTS.local.md/CLAUDE.local.md Overlays und eine benutzerglobale AGENTS.md in ~/.dsh. Wenn Sie bereits eine AGENTS.md für andere Agenten verwenden, übernimmt dsh diese unverändert.
Benötige ich einen kostenpflichtigen DeepSeek-Plan, um die Apidog CLI in dsh zu nutzen? Nein. Das Harness ist MIT-lizenziertes Open Source, und Sie bringen Ihr eigenes Modell mit: Kataloganbieter decken Anthropic, OpenAI, Bedrock, Vertex und Azure ab, und benutzerdefinierte Gateways funktionieren über settings.yaml, wie in wie man jedes Modell in DeepSeek Harness ausführt beschrieben. Die Apidog CLI selbst ist ein kostenloses npm-Paket; sie benötigt ein Apidog-Testszenario und Authentifizierung, kein spezifisches Modell.
Warum "vergisst" der Agent bei seinem zweiten Befehl das Verzeichnis, in das der erste gewechselt hat? Das ist beabsichtigt. Das Standard-dsh-Bash-Tool führt jeden Aufruf in einer neuen Shell aus, sodass cd nicht zwischen Befehlen persistent ist. Übergeben Sie den workdir-Parameter des Tools oder, einfacher, halten Sie den vollständigen apidog run-Aufruf in einer einzigen Zeile in Ihrer Regelsdatei, damit nichts vergessen wird.
Kann dsh das Szenario ausführen, ohne mich jedes Mal zu fragen? Das hängt von der aktiven Berechtigungsrichtlinie ab. Die Web-UI fragt vor Operationen, die eine Genehmigung gemäß dieser Richtlinie erfordern; das Benutzerhandbuch listet die Richtlinienebenen nicht auf, überprüfen Sie daher die Einstellungen in Ihrem Build, um zu sehen, was Ihre Bereitstellung zulässt. Wenn es eine Eingabeaufforderung gibt, ist die Genehmigung eines apidog run gegen Staging eine sichere Zustimmung.