DeepSeek Super-agent einrichten: Router und Worker

Teste DeepSeek Super-agent zunächst mit einem Repository, einer einzigen freigegebenen Person und einem eigenen Betriebssystemkonto. Der Router macht aus autorisierten Anfragen Tickets; die Worker arbeiten in getrennten Sitzungen und Verzeichnissen. Lass anfangs observe aktiviert, beachte aber: Explizite Anfragen können weiterhin ausgeführt werden.

Stand 2026-11-09 ist dsh-superagent-prototype Forschungscode, kein offizielles DeepSeek-Produkt und kein produktionsreifer Dienst. Das Paketmanifest nennt die Version 0.1.0 und die MIT-Lizenz. Die öffentliche Implementierung unterscheidet sich außerdem vom internen System des Teams und von der im Designartikel beschriebenen Umsetzung.

Welche Aufgaben Router, Ticket und Worker übernehmen

Der wesentliche Unterschied ist die fortlaufende Annahme von Aufgaben, nicht ein weiteres Modell oder eine neue Programmieroberfläche. Das Erweiterungspaket läuft in DeepSeek Harness, beobachtet ein GitHub-Repository und kann optional Nachrichten aus Feishu empfangen.

Das Domänenmodell trennt eingehende Ereignisse von autorisierten Aufgaben. Die Bewertung, Eval genannt, entscheidet, ob aus einer möglichen Aufgabe ein neues Ticket werden soll. Jedes angenommene Ticket erhält ein Mandate, das Berechtigung und Umfang festhält.

Der Router ist die Hauptsitzung des Agenten und entscheidet, wohin Anfragen weitergeleitet werden. Der Worker führt die angenommene Aufgabe aus. In den Einstellungen heißt dieser Worker Executor.

Jeder Worker erhält eine eigene Sitzung und ein eigenes Arbeitsverzeichnis. Ergebnisse gehen an die ursprüngliche Unterhaltung zurück, etwa als GitHub-Kommentar mit einem Pull Request. Getrennte Verzeichnisse trennen Arbeitskopien; sie begrenzen nicht, welche Dateien der Prozess lesen kann.

So können zwei unabhängige Fehlermeldungen zu getrennten Tickets werden, statt dieselbe Programmierunterhaltung zu teilen. Das hilft, wenn die Koordination eingehender Aufgaben mehr Aufmerksamkeit kostet als der Start einer einzelnen Aufgabe.

Für eine einzelne interaktive Änderung bleib bei deinem bisherigen Coding-Agenten. Wenn du begrenzte Aufgaben delegieren möchtest, beginne mit Claude-Code-Subagenten mit reinem Lesezugriff und expliziter Modellwahl.

Warum observe keine Sicherheits-Sandbox ist

observe begrenzt Aufgaben, die aus dem Kontext abgeleitet werden, nicht jede Ausführung. Die Berechtigungsregeln erlauben explizite Anfragen in jedem Annahmemodus.

In observe wird eine positiv bewertete, abgeleitete Aufgabe als „would accept“ protokolliert, ohne daraus einen Auftrag anzulegen. In auto kann eine positive Bewertung zur Annahme führen. Eine freigegebene Person kann den Agenten in jedem Modus erwähnen und ihm Arbeit zuweisen.

Die Freigabeliste ist nicht die einzige Zugangskontrolle. Eine Zelle in der Zulassungstabelle kann auch nicht gelisteten Personen explizite Befugnisse geben. Richte daher die unten beschriebene Regelung für genau eine anfragende Person ein, statt allein auf observe zu vertrauen.

Was danger-full-access bedeutet

Nutze ein Betriebssystemkonto, das nur die Zugangsdaten des Agenten enthält. Die Isolationswarnung im Deployment-Leitfaden gilt für dsh-superagent-router und dsh-superagent-worker. Beide Voreinstellungen laufen als Betriebssystembenutzer des Betreibers mit danger-full-access.

Wrapper für Zugangsdaten wählen Konten aus; sie isolieren keine Prozesse. Worker können Programme über absolute Pfade starten und das Home-Verzeichnis des Betreibers lesen. Laut Implementierungsleitfaden besitzt auch der Router Shell- und Dateilesewerkzeuge.

Verwende für den ersten Versuch einen temporären Rechner oder eine virtuelle Maschine mit einem Agentenkonto ohne Administratorrechte. Halte persönliche Zugangsdaten, Produktionsgeheimnisse und fremde Repositories aus dieser Umgebung heraus. Das sind Vorsichtsmaßnahmen beim Betrieb, keine eingebauten Schutzfunktionen des Prototyps.

Halte auch das Harness-Profil getrennt. Das Plugin ändert PATH und die git-Konfiguration für den gesamten Prozess. Lass das Panel an 127.0.0.1 gebunden und veröffentliche diesen Test nicht als öffentlichen Webdienst.

Einen Test nur mit GitHub einrichten

Führe die folgenden manuellen Schritte mit einem neuen Konto und Profil aus. Das Repository enthält auch eine SETUP.md für die agentengestützte Einrichtung.

Voraussetzungen prüfen

Installiere Node.js 22.19+ oder 24+, pnpm, git 2.32+, Python 3.8+, tmux und GitHub CLI 2.48+. Das sind die dokumentierten Voraussetzungen.

Du brauchst außerdem ein Repository auf github.com und einen Modellanbieter für DeepSeek Harness. GitHub Enterprise Server wird nicht unterstützt. Installiere git-lfs, wenn das Ziel-Repository Git LFS verwendet.

Verwende ein nicht leeres Test-Repository mit einer README.md. Für den ersten Test eignet sich am besten ein privates Repository, auf das nur du und der Agent zugreifen.

Feishu ist optional und nicht Teil dieses Tests. Der dokumentierte Anschluss benötigt zusätzlich eine Feishu- oder Lark-App mit Bot sowie lark-cli. Das Projekt nennt 1.0.90 als getestete Version.

Nur mit dem Agentenkonto anmelden

Erstelle ein eigenes GitHub-Benutzerkonto und gib ihm Schreibzugriff auf dein Test-Repository. Führe diese Befehle in Bash unter dem eigenen Betriebssystemkonto des Agenten aus.

unset GH_TOKEN GITHUB_TOKEN
gh auth login --hostname github.com --git-protocol https
gh api user --jq .login
gh auth setup-git --hostname github.com

Schließe die interaktive Anmeldung der GitHub CLI als Agent ab. Der Befehl gh api muss dessen Benutzernamen anzeigen. Das Entfernen der beiden Variablen verhindert, dass Zugangsdaten aus der Umgebung die gespeicherte Anmeldung übersteuern.

Der separate Schritt gh auth setup-git richtet GitHub CLI als Git-Credential-Helper ein. Das ist nötig, weil Vorbereitung und Branch-Pushes Git direkt verwenden.

Erstelle den lokalen Klon mit der dokumentierten Syntax der GitHub CLI:

read -r -p "Repository (owner/name): " TARGET_REPOSITORY
mkdir -p "$HOME/src"
gh repo clone "$TARGET_REPOSITORY" "$HOME/src/superagent-target"

Prüfe anschließend den HTTPS-Zugriff unabhängig von gh api:

GIT_TERMINAL_PROMPT=0 git ls-remote \
  "https://github.com/$TARGET_REPOSITORY.git" HEAD

GIT_TERMINAL_PROMPT=0 git -C "$HOME/src/superagent-target" push --dry-run \
  "https://github.com/$TARGET_REPOSITORY.git" \
  HEAD:refs/heads/agent-auth-check

git ls-remote muss den entfernten HEAD zurückgeben. Bei einem öffentlichen Repository kann dieser Lesezugriff auch anonym gelingen. Der Test mit push --dry-run prüft die Push-Verbindung, ohne entfernte Referenzen zu ändern.

Beide Befehle müssen erfolgreich sein. Die abschließende Prüfung der Auslieferung bleibt aber der echte Branch-Push für den späteren PR.

Dieses Beispiel verwendet gh direkt, weil das gesamte Betriebssystemkonto dem Agenten gehört. Übernimm keine Konfiguration mit mehreren GitHub-Anmeldungen aus einem persönlichen Konto.

Ein eigenes Harness-Profil installieren

Verwende die im Deployment-Leitfaden festgelegte Harness-Version 0.2.1-rc.3. Das Paketmanifest verlangt für engines.dsh den Bereich ^0.2.1-alpha.2.

Setze DSH_HOME vor dem ersten dsh-Befehl. Laut der CLI-Referenz dieser Version liegen benannte Profile unter $DSH_HOME/profiles/<name>. Für diesen Test wird $HOME/.dsh ausdrücklich als Speicherort gewählt.

Die folgenden Bash-Befehle sind nur für eine neue Installation gedacht:

export DSH_HOME="$HOME/.dsh"

npm install -g @deepseek-ai/dsh@0.2.1-rc.3
git clone https://github.com/deepseek-ai/dsh-superagent-prototype.git
cd dsh-superagent-prototype
pnpm install
pnpm build
dsh superagent --from-default-profile web --dump-config > /dev/null
dsh plugin --profile superagent add "link:$PWD"

Führe den Befehl zum Erstellen des Profils bei einer vorhandenen Installation nicht erneut aus. Er ersetzt das Profil und löscht dessen cordis.patch.yml. Für Updates nutze den Upgrade-Ablauf im Deployment-Leitfaden.

Prüfe vor dem Schreiben der Maschinenkonfiguration, ob das Profilmanifest existiert. Bleib dabei in derselben Bash-Shell:

test -f "$DSH_HOME/profiles/superagent/package.json" || exit 1

cat > "$DSH_HOME/profiles/superagent/cordis.patch.yml" <<EOF
- id: webserver
  config:
    host: 127.0.0.1
    port: 3082
- id: dsh-superagent
  config:
    stateDir: "$DSH_HOME/state/superagent"
EOF

if tmux list-sessions >/dev/null 2>&1; then
  tmux set-environment -g DSH_HOME "$DSH_HOME"
  if tmux has-session -t '=dsh-superagent' 2>/dev/null; then
    tmux set-environment -t '=dsh-superagent' DSH_HOME "$DSH_HOME"
  fi
fi

scripts/dsh-superagent start
scripts/dsh-superagent status

Das Dienstskript startet dsh --profile superagent über tmux. Ein neuer tmux-Server übernimmt die exportierte Umgebung. Der Block aktualisiert außerdem die tmux-Umgebung eines bereits vorhandenen Servers oder einer bestehenden Sitzung.

Öffne http://127.0.0.1:3082 in einem Browser auf dem Serverrechner. In den Harness-Einstellungen muss Open configuration file die oben genannte superagent/cordis.patch.yml öffnen. Halte an, falls ein anderer Pfad erscheint. Überschreibe diese Patch-Datei nicht mehr, nachdem du Anbietereinstellungen ergänzt hast.

Wähle Superagent in der Seitenleiste. Eine Warnung zur unvollständigen Einrichtung ist zu erwarten, solange Repository und Konto noch nicht konfiguriert sind. Schließe vor der Einrichtung des Anfrageempfangs die weiter unten beschriebene Modellauswahl und den Funktionstest ab.

Anfrageannahme und Arbeitsverzeichnisse je Ticket konfigurieren

Nutze Superagent → Settings und die dokumentierten Einstellungsgruppen.

Trage unter Sources → GitHub dein Repository als owner/name ein und setze die Agenten-CLI auf gh. Lass die Schalter für den Empfang aller Issues, Pull Requests, Kommentare und CI-Ereignisse des Standardbranches ausgeschaltet. Feishu bleibt deaktiviert.

Unter Eval → On each Source → GitHub darf GitHub accounts that may originate work nur deinen persönlichen GitHub-Benutzernamen enthalten. Entferne alle anderen Einträge und lass die Bot-Liste leer. Setze jede sichtbare Zulassungszelle für nicht gelistete Personen auf ignore, auch bei direkter Ansprache des Agenten. Speichere mit dem Annahmemodus observe.

Diese Standardwerte sind in der Zulassungsmatrix definiert. Sie begrenzen neue Arbeitsanfragen. Sie verhindern nicht, dass Nachrichten aus abonnierten Diskussionen als Kontext bei bestehenden Tickets ankommen. Beschränke die Testunterhaltung deshalb auf dich und den Agenten.

Starte unter Execution für den Test mit einer Parallelität von 1. Lass das Stammverzeichnis auf seinem Standardwert. Füge den folgenden Code in das Feld für den Vorbereitungsbefehl ein. Er läuft unter sh; die Syntax ist auch in Bash gültig.

git -C "$HOME/src/superagent-target" fetch --no-tags \
  "https://github.com/$DSH_SUPERAGENT_GITHUB_REPOSITORY.git" \
  "${DSH_SUPERAGENT_GITHUB_PR_HEAD:-HEAD}:refs/dsh-superagent/$DSH_SUPERAGENT_TICKET" &&
git -C "$HOME/src/superagent-target" worktree add \
  -b "agent/$DSH_SUPERAGENT_NAME" \
  "$DSH_SUPERAGENT_DIR" \
  "refs/dsh-superagent/$DSH_SUPERAGENT_TICKET"

Das Beispiel passt die Worktree-Anleitung des Deployment-Leitfadens an den zuvor angelegten Klon an. Es lädt den passenden Commit und erstellt Branch und Arbeitskopie des Tickets. Ohne Vorbereitungsbefehl startet der Worker in einem leeren Verzeichnis.

Lege unter Prompts die Identität des Commit-Autors und den Hinweis auf die Beteiligung des Agenten fest. Verlange manuelles Mergen und hinterlege kein separates Merge-Konto. Prompt-Anweisungen leiten den Agenten an; sie erzwingen keinen Schutz im Repository.

Kannst du ein anderes Modell verwenden?

Ja, über die in DeepSeek Harness eingerichteten Anbieter. Der Anbieterleitfaden zum Tag dsh-v0.2.1-rc.3 beschreibt die folgenden Schritte für die installierte Version.

Öffne in Harness Settings → Models. Trage auf der DeepSeek-Karte den API-Schlüssel ein und speichere ihn. Für einen anderen unterstützten Anbieter wählst du Add model provider. Gib Zugangsdaten lokal in dieser Oberfläche ein, nicht in einer GitHub-Diskussion.

Für Custom model API brauchst du eine kleingeschriebene Provider ID, die Basis-URL, das passende API-Protokoll, Zugangsdaten und mindestens ein Modell. Nutze die vom Anbieter dokumentierten Werte. Eine gespeicherte Anbieterkonfiguration beweist noch nicht, dass das Modell die erforderlichen Werkzeugaufrufe beherrscht.

Füge anschließend über Choose workspace den Pfad $HOME/src/superagent-target hinzu und wähle ihn aus. Folge dabei dem Web-UI-Leitfaden dieser Version. Starte eine normale Sitzung und wähle dort ein konfiguriertes Modell. Diese Auswahl wird zum Standard für neue Sitzungen.

Öffne eine zweite neue Sitzung und prüfe vor der ersten Anfrage, ob derselbe Anbieter und dasselbe Modell angezeigt werden. Lass sie README.md lesen und die erste Überschrift ohne Änderungen zurückgeben. Vergleiche die Antwort mit der Datei. Verwende für diesen Test keines der beiden verwalteten dsh-superagent-*-Presets.

Wähle den geprüften Anbieter und das Modell anschließend ausdrücklich unter Superagent → Settings → Eval und Execution aus. Eval legt das Router- und Bewertungsmodell fest, Execution das Worker-Modell. Der Test verlässt sich damit nicht auf einen ungeprüften Standard. Lass eine der beiden Auswahlen nur dann offen, wenn du das Standardmodell des Profils bestätigt hast.

Die Executor-Auswahl gilt beim Erstellen einer Sitzung. Bestehende Worker-Sitzungen behalten ihr Modell, und Retry verwendet dieselbe Sitzung erneut. Prüfe einen späteren Modellwechsel mit einem neuen Ticket.

Eine Anfrage prüfen und die Fehlerstelle finden

Prüfe eine vollständige GitHub-Anfrage samt Antwort, bevor du eine Codeänderung beauftragst. Ein laufendes Panel allein bestätigt weder Berechtigungen noch Vorbereitung oder Modellaufrufe.

Führe zuerst scripts/dsh-superagent status erneut aus. Verlange Exit-Code 0 und keine Einrichtungsfehler. Verfasse mit dem freigegebenen persönlichen Konto einen neuen Issue-Kommentar. Ersetze @AGENT_LOGIN durch den Benutzernamen des Agenten:

@AGENT_LOGIN Read README.md and reply here with its first heading.
Do not edit files, push a branch, or open a pull request.

Laut dem Testablauf im Deployment-Leitfaden erscheint das erzeugte Ticket unter Overview. Prüfe, ob die Antwort in der ursprünglichen GitHub-Unterhaltung die richtige Überschrift enthält.

Wenn das funktioniert, beauftrage eine kleine Dokumentationsänderung und einen Pull Request zur menschlichen Prüfung. Kontrolliere den echten Branch-Push, das Agentenkonto als PR-Ersteller und den vereinbarten Umfang des Diffs. Das sind Abnahmekriterien, keine garantierten Modellergebnisse.

Fehlt ein Ticket, prüfe den freigegebenen Benutzernamen, die Zulassungszellen, das Repository und den Zustand der GitHub-Quelle. Schreibe danach einen neuen Kommentar, der den Agenten erwähnt.

Bei Dienstfehlern liefert das Skript 1 für Prozess- oder Laufzeitprobleme, 2 für Komponentenfehler und 3 für eine unvollständige Einrichtung. Bei 1 kann ein Neustart helfen. Bei 2 oder 3 behebst du die gemeldete Ursache.

Bei vorübergehenden Modell- oder Netzwerkfehlern sieht der Ausführungsleitfaden drei Wiederholungen mit zunehmender Wartezeit vor. Dazu gehören HTTP 408, 429 und 5xx. Fehlgeschlagene Vorbereitungsbefehle sind von diesen automatischen Wiederholungen ausgenommen.

Nach einem fehlgeschlagenen Vorbereitungsbefehl fortfahren

Prüfe den protokollierten Vorbereitungsfehler und das Ticketverzeichnis, bevor du Retry wählst. Die Startimplementierung führt die Vorbereitung nur aus, wenn dieses Verzeichnis fehlt. Ein vorhandenes Verzeichnis gilt als vorbereitet, selbst wenn die Arbeit darin unvollständig ist.

Fehlt das Verzeichnis, behebe zuerst das Problem mit den Zugangsdaten oder dem Vorbereitungsbefehl und wähle dann Retry. Beim neuen Start wird die Vorbereitung erneut versucht.

Existiert das Verzeichnis bereits, kopiere seinen Pfad aus den Ticketdetails und untersuche es in Bash:

read -r -p "Ticket directory (absolute path): " TICKET_DIR
git -C "$TICKET_DIR" rev-parse --show-toplevel
git -C "$TICKET_DIR" status --short --branch

Das angezeigte Wurzelverzeichnis muss das Ticketverzeichnis sein, nicht eine übergeordnete Arbeitskopie. Prüfe den Branch und den Zustand des Arbeitsverzeichnisses, die erwarteten Dateien und jeden zuvor fehlgeschlagenen Vorbereitungsschritt.

Starte bei einem vorhandenen Verzeichnis erst erneut, wenn du die Vorbereitung abgeschlossen und geprüft hast. Retry baut das Verzeichnis nicht neu auf. Kannst du eine unvollständige Arbeitskopie nicht sicher wiederherstellen, bewahre sie auf, stoppe das Ticket und korrigiere den Befehl. Stelle danach eine Anfrage in einem neuen Issue. Prüfe vor dem Fortfahren, ob das neue Ticket ein neues Verzeichnis verwendet.

Sobald ein Ticket fehlgeschlagen ist, aktivieren CI- und Bot-Nachrichten seinen Worker nicht mehr. Ein Mensch muss eingreifen. Stoppe den Testdienst, wenn du fertig bist:

scripts/dsh-superagent stop

Wann sich der dauerhafte Betrieb lohnt

Lass den Prototyp nur weiterlaufen, wenn seine Aufgabenverteilung und gelieferten Änderungen den Betriebsaufwand rechtfertigen. Beginne mit engem Umfang. Erhöhe die Parallelität erst, nachdem du nützliche Ergebnisse und den Verbrauch beim Anbieter gemessen hast.

Vergleiche Kosten pro akzeptierter Änderung statt nur Modellpreise. Rechne Aufgabenverteilung, Bewertung, Worker-Aufrufe und Fehlerbehebung in dein Testbudget ein. Der Leitfaden zu Kosten pro Coding-Agent-Aufgabe zeigt, wie sich ein Modell zusammen mit seiner Ausführungsumgebung vergleichen lässt.

Setze eine interne Demonstration nicht mit diesem öffentlichen Code gleich. Das Repository warnt davor, dass einige Entwürfe aus dem umfassenderen Designartikel noch nicht implementiert sind. Halte die Umgebung isoliert und prüfe Änderungen manuell, bis deine eigenen Abnahmetests einen breiteren Einsatz rechtfertigen.