Das Team von DeepSeek Harness hat am Abend des 31. Oktober den langen Beitrag „Super-agent-Designstudie: Auf dem Weg zu autonomeren Agentensystemen“ veröffentlicht. Darin schlägt es eine zweischichtige Agenten-Architektur vor und hat den Prototyp dsh-superagent-prototype auf GitHub offengelegt. Das Team schreibt ausdrücklich, der Prototyp diene dazu, den technischen Ansatz zu prüfen, und sei kein offizielles Produkt von DeepSeek.
Ausgangspunkt des Beitrags ist eine schlichte Beobachtung: Damit ein Modell eine Aufgabe allein erledigt, braucht es immer weniger menschliche Eingriffe, und der Engpass für die Produktivität ist die Aufmerksamkeit des Menschen geworden. Nach Angaben des Teams kann ein Mensch üblicherweise nur 3 bis 5 aktive Sessions gleichzeitig verfolgen; werden es mehr Aufgaben, muss er von Hand hin- und herwechseln und den Kontext selbst im Kopf behalten.
Die Session sollte ein Implementierungsdetail des Systems sein, keine kognitive Last für den Nutzer.
Der Router führt das Gespräch, der Worker die Arbeit
Die Architektur hat zwei Schichten. Die dauerhaft laufende Router-Schicht nimmt Nachrichten von Menschen entgegen, pflegt den globalen Kontext und verteilt Aufgaben. Sie hat keine Ausführungswerkzeuge wie Bash und kann deshalb von einem schlanken Modell angetrieben werden. Die Worker-Schicht besteht aus mehreren Sitzungen mit voneinander isolierten Kontexten, die mit dem vollen Werkzeugsatz und dem stärksten Modell ausgestattet sind; jede konzentriert sich auf eine Sache, alle laufen parallel. Worker antworten nicht direkt an den Nutzer, sondern melden Status und Ergebnisse zunächst an den Router, der dann einheitlich nach außen spricht.
Mehrere weitere Bausteine drehen sich darum, den Agenten „immer online“ zu halten:
- Ereignisgetrieben: Gruppenchat-Nachrichten, E-Mails, Terminerinnerungen, Kommentare in Code-Reviews und CI-Ergebnisse gelten alle als Trigger. Den Großteil des Rauschens filtern zunächst Programmregeln heraus; erst der Rest geht ans Modell, das entscheidet, ob gehandelt wird. Folgeereignisse zu bereits zugewiesenen Threads liefert das Programm direkt an den zuständigen Worker aus, ohne Umweg über den Router.
- Asynchroner ReAct Loop: Zeitaufwendige Werkzeugaufrufe werden in start() und stop() aufgeteilt. Eine Hintergrundaufgabe gibt nach dem Start sofort Started zurück, im Vordergrund geht das Gespräch mit dem Nutzer weiter, und das Ergebnis kehrt als neues Ereignis in die Sitzung zurück.
- Trennung von Rechenleistung, Zustand und Umgebung: Agent Loop und Zustand liegen in der Cloud, die Ausführungsumgebung kann auf dem Rechner des Nutzers bleiben, wo nur ein leichter Daemon läuft; eigene Maschinen werden unterstützt (BYOM).
- Watchdog: Eine eigenständige Sitzung wacht regelmäßig auf. Sie prüft nicht nur, ob Prozesse noch leben, sondern lässt das Modell beurteilen, ob jeder Worker substanzielle Fortschritte macht und ob die Richtung noch stimmt.
Der Beitrag nennt auch ein Beispiel für „spekulative Ausführung“: Meldet jemand in der Gruppe einen Bug, versucht der Agent zunächst im Hintergrund, ihn zu reproduzieren und zu beheben, und meldet sich erst, wenn die Korrektur gelungen ist; scheitert sie, wird niemand gestört.
Die Zahlen stammen nur aus synthetischer Last
Das Team führte einen Vergleichsversuch durch: Pro Durchlauf gab es rund 300 Nachrichten, davon etwa 20 Arbeitsanfragen, der Rest waren Smalltalk und Rauschen; jede Variante wurde fünfmal wiederholt. Die Bearbeitungszeit des Super-agent lag bei p50 12,4 Minuten und bei p95 15,7 Minuten; die Vergleichsgruppe „einzelne Session plus Subagent“ kam bei neutralem Prompt auf ein p95 von 29,5 Minuten. Ohne den Mechanismus der direkten Ereigniszustellung stieg die Zahl der Router-Entscheidungen um etwa 30 %, die gelesenen Cache-Token um etwa 37 %.
Im Stresstest des Routers wurden die Trigger von etwa 1 auf etwa 40 pro Minute erhöht. Die durchschnittliche Batch-Größe stieg dabei von 1,0 auf 2,8, die Dauer pro Anfrage von 2,5 auf 3,9 Sekunden, während die auf jede einzelne Entscheidung entfallende Inferenzzeit von 6,4 auf 1,6 Sekunden sank.
Die Einschränkungen benennt das Team offen: Der Versuch nutzte synthetische Last und eine vereinfachte Umgebung und misst nur Koordination und Zusammenarbeit, nicht die Qualität der einzelnen Aufgabenlösung. Der Token-Verbrauch des Super-agent liegt über dem der Einzelsession-Variante, die Gesamtmenge wird jedoch nicht offengelegt. Der Open-Source-Prototyp zielt derzeit nur auf ein einzelnes GitHub-Repository; geräteübergreifender Betrieb, dauerhaft laufende Cloud-Instanzen und der Watchdog sind nicht vollständig umgesetzt.
Von dsh zum Super-agent
Zieht man die Zeitlinie zusammen, veröffentlicht DeepSeek bei Agenten zuerst das Framework und erst danach die Gedanken zur Orchestrierung. Rund um den August dieses Jahres machte das Unternehmen das Agenten-Framework DeepSeek Harness (Kommandozeilenname dsh) unter MIT-Lizenz zu Open Source; Dateisystem, Shell, Modelladapter, Web-UI und Subagenten sind darin als austauschbare Plugins ausgelegt. In den Monaten danach gingen Modelle wie V4.1 Flash online, und auch Programmierwerkzeuge von Drittanbietern begannen, es als Hauptmodell zu verwenden.
Der neue Beitrag geht eine Ebene höher und fragt, wie eine einzelne Agenteninstanz Dutzende Dinge gleichzeitig im Blick behalten kann. Das Team gibt an, der im Text beschriebene asynchrone Aufgabenmechanismus sei bereits in DeepSeek Harness eingebaut, nur standardmäßig deaktiviert. Interne Instanzen auf Basis derselben Idee liefen seit längerem; sie reproduzieren und beheben Probleme, reagieren auf Code-Reviews und werden auch genutzt, um Harness selbst weiterzuentwickeln.
Zu den offenen Fragen, die das Team aufführt, zählen die Skalierung der Router-Schicht mit der Aufgabenzahl, ein Langzeitgedächtnis über Monate hinweg und die Kommunikation zwischen mehreren Agenteninstanzen. Am konkretesten fällt der Punkt Sicherheit aus: Wird der Cloud-Agent-Loop per Prompt Injection manipuliert, könnten angebundene lokale Geräte kontrolliert werden, und im Modellkontext abgelegte Zugangsdaten könnten im normalen Betrieb abfließen. Wie sich diese Risiken abwehren lassen, beantwortet der Beitrag nicht vollständig.
Quellen: Technischer Langbeitrag des DeepSeek-Harness-Teams und Beschreibung des Repositorys dsh-superagent-prototype, ITHome, CocoLoop, Ifeng Tech; maßgeblich für Laufzeiten und Stresstestdaten sind die vom Team veröffentlichten Ergebnisse unter synthetischer Last.