DeepSeek Harness Praxis: Warum ein AI Agent nicht nur das Modell ist

Zuletzt geprüft am 11. September 2026 anhand des offiziellen DeepSeek-Harness-Repositoriums, der Skills-Referenz und der Process-Sandbox-Dokumentation.

Wer DeepSeek gegen Claude oder Gemini tauscht, bekommt oft netttere Antworten. Am selben Punkt kippt der Einsatz trotzdem: Das Modell ruft Werkzeuge, ändert Dateien, startet Skripte – und niemand kann sagen, warum dieser Schritt geschah, ob er wiederholbar ist, wohin geschrieben wurde und ob ein erneuter Versuch sicher ist. 2026 ist der Engpass eines Agents nicht mehr „wer formuliert flüssiger“, sondern wer eine Aufgabe zu Ende bringt, ohne Chaos zu hinterlassen.

Vorweg: Das Modell wählt die nächste Absicht. Das Harness besitzt Schleife, Sitzung und Plugin-Zusammensetzung. Ein Skill lädt eine wiederverwendbare Anleitung erst bei Bedarf, statt jedes Handbuch in den Systemprompt zu stopfen. Die Sandbox begrenzt, welche Dateien genau dieser Kindprozess anfassen darf, und bricht geschlossen ab, wenn Isolation nicht durchsetzbar ist. Fehlt eine Schicht, überlebt die Demo – die Prüfung nicht.

Wer Verfahrenswissen aus PDFs in Agent-Anleitungen gießen will, trennt dasselbe Problem anders: Inhalt vorbereiten, dann erst laden. Dafür eignet sich unser Leitfaden Book to Skill. DeepSeek Harness beantwortet die Anschlussfrage: Wann erscheint diese Anleitung, und wer darf danach auf die Platte schreiben?

Drei Brüche, die kein größeres Modell heilt

„Ein stärkeres Modell“ als Agent-Plan zerbricht meist an drei Stellen gleichzeitig. Ein anderer Anbieter repariert das nicht.

Erstens eine Schleife ohne vertrauenswürdigen Speicher. Eine echte Aufgabe listet, liest, patcht und testet mehrfach. Lebt die Geschichte nur in einem Array im Prozess, löscht ein Neustart oder ein UI-Refresh das Arbeitsgedächtnis. Wer debuggt, sieht dasselbe Ereignisprotokoll nicht und rät anhand von Chat-Screenshots.

Zweitens überladene Handbücher. Release-Regeln, Stil und Ticketwege wandern in den Systemprompt. Das Fenster läuft voll, Schritte fehlen, und ein weiterer Satz „unbedingt einhalten“ macht den Prompt nur lauter. Das Modell soll meist einen Katalog sehen und genau einen Textkörper laden, wenn die Arbeit wirklich beginnt.

Drittens unbeschränkte Nebenwirkungen. Eine Shell kann außerhalb des Repos schreiben, eine Geheimdatei berühren oder einen halbfertigen Patch auf der Platte lassen. Ein Prompt „tu das nicht“ ist keine Steuerungsebene.

Ein größeres Kontextfenster heilt das nicht. Es lässt ein schlechtes Handbuch nur länger sitzen. Schleife und Dateigrenze gehören zur Ausführungsschicht. Langzeitgedächtnis in Redis oder Postgres ist ein anderes Kaufproblem; das Session-Log des Harness fragt nur, ob sich dieser Lauf rekonstruieren lässt. Die Auswahl der Memory-Datenbank haben wir getrennt verglichen.

Was das Harness wirklich trägt

DeepSeek Harness (dsh) nennt sich Open-Source-Agent-Harness, nicht noch ein Chat-Skin. Die öffentliche Linie lautet Everything is a Plugin: Modelladapter, Systemprompts, Werkzeugregistrierung, Sitzungsprotokolle, Agent-Schnittstelle und Standardschleife kommen als tauschbare Pakete, zusammengesetzt mit Cordis. Das Repo ist weiterhin Developer Preview. Bruchstellen sind möglich. Trotzdem zeigt es, was eine Ausführungsschicht besitzen muss.

Im Labor trägt das Harness drei Aufgaben, die das Modell nicht kann.

• Wer den nächsten Schritt treibt. Die Standard-agent-loop ist eine Umsetzung des Agent-Vertrags. Plugins hängen an dieser Schnittstelle, nicht am Standardtreiber. Offene Schleifen passen zu unscharfen Zielen. Freigaben gehören in einen äußeren, deterministischen Ablauf.
• Eine Sitzung, die sich neu aufbauen lässt. Die nächste Modellanfrage muss aus dem Session-Log ableitbar sein, nicht aus einem temporären Array. Rohe Chunks bleiben für Replay, Oberfläche und Diagnose.
• Zusammensetzung, die sich patchen lässt. Profile, Bundles und Patches stapeln sich zum Laufzeitbaum. Modellgeber, Sandbox-Backend oder UI wechselt man per Patch, bevor man Kernpakete forkt. dsh --profile web --dump-config zeigt den Baum, den die Maschine wirklich startet.

Das Harness macht das Modell also nicht klüger. Es beantwortet, wer den nächsten Schritt ausführt, wo Geschichte liegt und welche Naht ersetzt werden darf. Ohne diese Schicht hat ein Skill keinen stabilen Einspritzpunkt und die Sandbox keinen stabilen Aufrufer.

Wofür ein Skill da ist

Offiziell ist ein Skill eine optionale Anweisung, kein Sitzungsereignis. Das Modell sieht normal einen Katalog: sortierte name-Werte und maskierte, gekürzte description (Standardgrenze 500 Zeichen). Körper, Pfade, Quellen und Routing-Hinweise bleiben draußen. Beginnt die Arbeit, ruft das Modell skill({ name }). Das Framework löst den siegenden Skill gegen das Sitzungs-cwd auf und liefert eine kanonische Antwort.

Lokale Skills nutzen kebab-case. Erlaubt ist ein Verzeichnisbündel mit SKILL.md oder eine flache Markdown-Datei. Verschachtelte rekursive **/SKILL.md-Suche gibt es nicht. Der lokale Anbieter scannt Wurzeln nach Rang: zuerst Projekt-.dsh/skills, dann .agents/skills, danach eigene, Benutzer- und gebündelte Verzeichnisse. Die Projektwurzel ist die nächste Git-Wurzel; fehlt sie, gilt das cwd.

Diese Schicht beantwortet: Wann erscheint das Handbuch? Eine Release-Checkliste oder ein Test-Patch-Verfahren als Skill lädt der Lauf nur für genau diesen Job. Eine Änderung am Körper betrifft spätere Aufrufe, nicht alte Werkzeugresultate. Kataloge dürfen heiß neu geladen werden; eine unvollständige Entdeckung darf den letzten guten Katalog nicht überschreiben.

Ein Skill ist kein Rechtesystem. Er sagt, wie gearbeitet wird – nicht, ob ein Schreibzugriff das Workspace verlassen darf. Ohne Sandbox ist ein sehr klarer „Deploy“-Skill gefährlicher, weil gefährliche Schritte leichter ausführbar werden.

Was die Sandbox begrenzt

Die Process Sandbox betrifft Dateiwirkungen eines Kindprozesses auf demselben Host. Netz und Prozesssichtbarkeit liegen außerhalb dieses Wortschatzes. Container, MicroVMs und Remote-Läufer sind Geschwister-Nähte, keine Anbieter von ctx.sandbox. Lokal laufen bwrap/Landlock unter Linux, Seatbelt unter macOS, Restricted Token plus ACL unter Windows.

Es gibt drei Modi. Nur die ersten beiden gehen an den isolierenden Anbieter:

• read-only verweigert Schreibzugriffe; POSIX-Läufer lassen zusätzlich die /dev/null-Senke zu, die Shells brauchen.
• workspace-write erlaubt Schreiben unter dem unveränderlichen cwd der Sitzung und in einem vom Backend zugesagten Temp-Bereich.
• danger-full-access überspringt die Isolation. Der Aufrufer startet das originale argv und ruft ctx.sandbox nicht.

Im Labor zählt fail-closed: Wurde Isolation verlangt und kein Backend kann sie halten, fliegt SANDBOX_UNAVAILABLE. Stillschweigendes Durchreichen ist verboten. Die Politik wird pro Aufruf aufgelöst, daher kann Bash nur lesen, während ein Kind-Agent sein Statusverzeichnis schreibt. Zwei Fehlerarten bleiben getrennt: Der Läufer startete nie – versus Isolation wirkte und blockierte den Schreibzugriff. Ersteres ist Infrastruktur, letzteres heißt: Die Sandbox hat gearbeitet.

Die Durchsetzung kann full oder partial sein. Ältere Landlock-ABIs und einige Windows-ACL-Kanten sind heute partial. Wer ein absolutes Versprechen braucht, behandelt partial nicht als verriegelt.

Wie ein Auftrag alle drei nutzt

Ein „failenden Test flicken und einen Patch öffnen“ macht die Teilung konkret.

1. Das Harness baut den Kontext aus dem Session-Log und injiziert den sichtbaren Skill-Katalog (nur Namen und Beschreibungen).
2. Das Modell lädt etwa repo-test-patch, statt Schritte aus dem Gedächtnis zu erfinden.
3. Das Werkzeug skill liest den Körper für dieses cwd und liefert Anweisungen plus relative Ressourcenhinweise.
4. Das Modell will Dateien lesen oder Tests laufen lassen. Das Harness fährt die Werkzeugpipeline. Die Sandbox umhüllt dieses argv unter der Politik dieses Aufrufs.
5. Ergebnisse landen wieder im Session-Log. Der nächste Schritt kommt aus dem Log, nicht aus einer globalen Variable „haben wir wahrscheinlich schon“.

Ohne Harness fehlen stabile Katalogeinspritzung und Ergebnispersistenz. Ohne Skills ersäuft der Systemprompt in Handbüchern. Ohne Sandbox ist ein klarerer Skill nur eine klarere Anleitung zur Rechteausweitung. Die drei Schichten ergänzen sich; sie sind nicht drei Namen für dasselbe Feature.

Starten und den ersten Skill schreiben

Der schnellste offizielle Weg ist npx @deepseek-ai/dsh web, standardmäßig mit Web-UI unter http://127.0.0.1:3080. Aus dem Quellbaum: klonen, dann pnpm install && pnpm run build && pnpm dsh web. Beim SSH-Start erscheint meist nur die Host-URL; die weitergeleitete lokale Adresse bleibt beim Client.

Den ersten Projekt-Skill legen Sie dort ab, wo der lokale Anbieter zuerst sucht – an der Repo-Wurzel:

---
name: repo-test-patch
description: Nur nutzen, wenn ein fehlschlagender Test mit einem Minimalpatch gefixt wird.
---

# repo-test-patch
1. Branch an der Workspace-Wurzel prüfen.
2. Fehlschlagenden Test laufen lassen, bevor Produktionscode geändert wird.
3. Patch auf Dateien begrenzen, die der Fehler wirklich berührt.
4. Nicht außerhalb des Workspace schreiben.

Namen müssen kebab-case sein. Nutzen Sie ein SKILL.md-Bündel; tiefe Verschachtelung wird nicht gefunden. Die Frontmatter-Schlüssel disable-model-invocation und user-invocable steuern, ob Modell oder Mensch den Eintrag sehen. Beide aus: Nur ein vertrauenswürdiger ctx.skills.get()-Aufrufer lädt noch.

Nach dem Boot drei Fakten prüfen: Eine Katalognachricht steht in der Sitzung; ein skill-Aufruf liefert den Körper, statt das ganze Handbuch in den Systemprompt zu kleben; ein Schreibzugriff außerhalb des Workspace unter read-only wird vom Backend verweigert, nicht nur vom Prompt missbilligt. Fehlt ein isolierendes Backend, muss der Prozess mit Fehler enden statt nackt weiterzulaufen.

Behandeln Sie DeepSeek Harness als Architekturmuster zum Prüfen, nicht als bereits produktionszertifizierte Plattform. Abgenommen werden Schleife, Katalog und Confine-Pfad – kein Marketingclip.

Wann sich der volle Stapel lohnt

Gegen eine selbst gebaute while-Schleife plus ein paar Tools kauft DeepSeek Harness getrennte Nähte für Zusammensetzung, Sitzungsrebuild und Isolation pro Aufruf. Bezahlt wird das Cordis-Modell, Preview-Brüche und das Lernen, dass Skill und Sandbox nicht dasselbe sind. Die Teilung lohnt, wenn Sie Modell-Backends, Sandbox-Implementierungen oder einen Skill-Katalog über Repositorien dieses Jahr wirklich tauschen.

Kurz: Ein stabiler Agent 2026 ist kein weiteres Chatmodell. Trennen Sie Urteil, Schleife, Handbuch und Dateigrenze. Das Harness beendet den Lauf. Der Skill erklärt den Job, wenn er gebraucht wird. Die Sandbox sagt, wohin dieser Aufruf schreiben darf. Zusammen wird aus einer Demo ein prüfbarer Auftrag.

Häufige Fragen