DeepSeek hat dsh-superagent veröffentlicht, einen unter MIT-Lizenz stehenden Forschungsprototyp, der als proaktiver Programmieragent für ein einzelnes GitHub-Repository vorgestellt wird. Für DeepSeek Harness gepackt, lauscht er auf GitHub und optional auf Feishu und wandelt dann autorisierte Anfragen in parallele Aufgaben um, jede in ihrer eigenen Agentensitzung.
- DeepSeek veröffentlicht dsh-superagent, einen Forschungsprototyp unter MIT-Lizenz, der ein GitHub-Repository proaktiv betreut.
- Jede autorisierte Anfrage öffnet ein Ticket in einer eigenen Sitzung, und die Ergebnisse landen oft als Pull Request.
- Ein langlebiger Router verteilt Aufgaben an isolierte Worker, damit die menschliche Aufmerksamkeit geschont wird.
- In einer Simulation war der Super-Agent schneller als eine einzelne Sitzung, doch die Daten sind selbstdeklariert und nur mit synthetischen Nachrichten getestet.
Ein Agent, der auf Aufforderung wartet
Die Funktionsweise basiert auf dem Konzept eines Tickets, einer Arbeitseinheit, die geöffnet wird, wenn eine autorisierte Person den Agenten anspricht. Jedes Ticket wird in seiner eigenen Sitzung und seinem eigenen Verzeichnis ausgeführt, und die Ergebnisse fließen zurück in die ursprüngliche Konversation, oft in Form eines Pull Requests, also eines zur Überprüfung eingereichten Codeänderungsvorschlags. Eine lokale Weboberfläche listet nur die Elemente auf, die menschliches Eingreifen erfordern.
Die README des Projekts legt eine einfache Regel fest: menschliche Aufmerksamkeit minimieren, während maximaler Wert geliefert wird. Laut dem Projektphilosophie-Dokument fordert der Agent nur einmal eine Bestätigung an, bleibt während seiner Arbeit still und meldet sich erst wieder mit einem Ergebnis, einer Frage oder einem Fehler.
Eine Router-Worker-Architektur
Laut dem Team betrachten gängige Agenten die Sitzung als Grundeinheit. Dem von ifeng zitierten Bericht zufolge kann eine Person aktiv nur 3 bis 5 Sitzungen gleichzeitig verfolgen, sodass die menschliche Aufmerksamkeit und nicht die Modellkapazität zum limitierenden Faktor für paralleles Arbeiten wird. Die vorgeschlagene Architektur umfasst zwei Schichten: Ein langlebiger Router verwaltet den Austausch und die Verteilung von Aufgaben, während isolierte Worker-Sitzungen die eigentliche Arbeit erledigen.
Das Domänenmodell beschreibt eine präzise Abfolge: GitHub oder Feishu produzieren Ereignisse, sogenannte Triggers; eine Evaluierungsstufe entscheidet, ob ein Batch von Triggers neue Arbeit auslöst; jedes Ticket trägt ein unveränderliches Mandat, das festlegt, warum es ausgeführt werden darf; schließlich werden spätere Kommentare zu einem Pull Request ohne erneute Erwähnung an den richtigen Worker weitergeleitet. Shell-Befehle gehen nach 5 Sekunden in den Hintergrund, damit Worker weiterhin Nachrichten empfangen können. Proaktive Arbeit wird durch drei Modi gerahmt: off, observe (Standard) und auto. Im Modus observe protokolliert der Agent lediglich, was er angenommen hätte.
Ergebnisse aus einer Simulation
DeepSeek testete das System mit simulierten Strömen von Gruppendiskussionen und GitHub-CI, mit etwa 300 Nachrichten pro Durchlauf, davon etwa 20 echte Arbeitsanfragen, wobei jede Konfiguration 5-mal ausgeführt wurde. Der Super-Agent zeigt einen p50 von 12,4 Minuten und einen p95 von 15,7 Minuten, verglichen mit einem p95 von 29,5 Minuten für eine einzelne Sitzung mit Sub-Agenten und neutralem Prompt, für die kein p50 angegeben wurde. In dieser Referenzkonfiguration wurde der Sub-Agent in 5 Durchläufen kein einziges Mal aufgerufen.
Laut denselben Daten stieg die Batch-Größe von etwa 1,0 auf 2,8 und die Latenz pro Anfrage von 2,5 auf 3,9 Sekunden, als die Ankunftsrate von etwa 1 auf 40 pro Minute anstieg. Diese Zahlen sind selbstdeklariert von DeepSeek und stammen aus sekundären Berichtsauszügen. Das Projekt stellt außerdem klar, dass es nur mit synthetischen Nachrichten und simulierten Tools getestet wurde und die tatsächliche Qualität des produzierten Codes nicht gemessen wurde.
Für die Installation benötigt der Prototyp Node.js 22.19+ oder 24+, git 2.32+, Python 3.8+, tmux und GitHub CLI 2.48+. Das Repository weist abschließend darauf hin, dass der Agent mit allen Rechten des Betriebssystembenutzers läuft, was eine Isolierung vor jeglicher Nutzung erforderlich macht.
