DeepSeek veröffentlicht Super-Agent-Prototyp für parallele Programmieraufgaben

Ein Coding-Agent, der mehrere Aufgaben gleichzeitig bearbeitet

Das Harness-Team von DeepSeek veröffentlichte am 31. Oktober 2026 seinen Entwurf für Super-Agent zusammen mit einem unter MIT-Lizenz stehenden Forschungsprototyp, der Anfragen zu einem GitHub-Repository in separate Coding-Sitzungen aufteilt. Ziel ist es, mehrere Aufgaben gleichzeitig voranzubringen und Entwicklern weniger Zeit für den Wechsel zwischen Gesprächen und die Fortschrittskontrolle abzuverlangen.

Im vorläufigen Experiment des Teams kamen etwa 300 simulierte Nachrichten mit rund 20 Arbeitsaufträgen zum Einsatz. Super-Agent erledigte die Hälfte der Aufgaben innerhalb von 12,4 Minuten und 95 Prozent innerhalb von 15,7 Minuten. Ein Vergleichssystem mit einer Hauptsitzung und Zugriff auf einen Hilfsagenten benötigte bei neutralen Anweisungen 29,5 Minuten, um die 95-Prozent-Marke zu erreichen.

Das öffentliche Prototyp-Repository von DeepSeek mit dem Namen dsh-superagent-prototype beschreibt eine enger gefasste, praxisorientierte Veröffentlichung: einen proaktiven Coding-Agenten für ein einzelnes GitHub-Repository, gebündelt für DeepSeek Harness. Er überwacht GitHub und optional Feishu, eröffnet einen Arbeitsauftrag, wenn eine berechtigte Person eine Aufgabe stellt, und antwortet im ursprünglichen Gespräch, gegebenenfalls mit einem Pull Request, der Codeänderungen vorschlägt.

Die README enthält außerdem eine deutliche Warnung. Der veröffentlichte Code unterscheidet sich vom internen System und in Teilen auch vom Design-Essay. Einige vorgeschlagene Funktionen sind noch Zukunftspläne, und DeepSeek bezeichnet die Veröffentlichung als Forschungscode, nicht als fertiges Produkt.

Das DeepSeek-Harness-Team, das den Prototyp betreut, beschreibt seinen Status in der README so:

Nur ein Forschungsprototyp zur Orientierung, kein offizielles DeepSeek-Produkt.

Für Entwickler bietet die Veröffentlichung Code, den sie untersuchen und anpassen können. Im Mittelpunkt des Experiments steht die Frage, wie ein Agent Arbeit organisiert, zusammenhängende Gespräche im Gedächtnis behält und entscheidet, wann ein Mensch eingreifen muss.

Warum DeepSeek das Sitzungsmanagement verbergen möchte

DeepSeeks Entwurf geht von einer Beobachtung aus der eigenen Arbeit aus: Eine Person kann üblicherweise nur drei bis fünf aktive Agentensitzungen gleichzeitig verfolgen. Jede Sitzung hat ihren eigenen Gesprächsverlauf. Entwickler müssen sich daher merken, welche Aufgabe zu welcher Sitzung gehört und welche Anweisungen die einzelnen Agenten erhalten haben.

Ein Harness ist die Software rund um ein KI-Modell, die Tools, Dateien, Gespräche und Ausführung verwaltet. Das Modell denkt über eine Aufgabe nach; das Harness bestimmt, wie sie das Modell erreicht und wie dessen Aktionen ausgeführt werden. Super-Agent verlagert mehr Verantwortung für die Koordination mehrerer Aufgaben in diese umgebende Software.

Das Team nennt vier Ziele: Kontinuität über mehrere Gespräche hinweg, effiziente parallele Ausführung, proaktive Reaktionen auf Ereignisse und dauerhaften Betrieb mit Wiederherstellung nach Fehlern. Ein Beispiel: Entwickler entscheiden sich in einem Chat für einen Plan und ändern ihn später in einem GitHub-Kommentar. Das System soll beide Gespräche miteinander verknüpfen und dieselbe Aufgabe entsprechend anpassen.

Die Veröffentlichung folgt auf DeepSeeks Experiment vom 3. Oktober zur Kompatibilität mit Claude-Code-Erweiterungen in Harness v0.2.1-alpha.1. Bei diesem Update wurde eine Schnittstelle für Erweiterungen erprobt; Super-Agent untersucht, wie das Harness selbst laufende Arbeit koordinieren kann. Yujia Qiao wird als Entwickler des Systems und Autor des Design-Essays genannt. Weitere 15 Personen waren an Prüfung und Diskussion beteiligt.

Ein Router koordiniert, mehrere Worker führen Aufgaben aus

Super-Agent teilt die Zuständigkeiten zwischen einem dauerhaft laufenden Router und separaten Workern auf. Der Router empfängt menschliche Nachrichten, verwaltet Informationen, die mehrere Aufgaben betreffen, und weist Arbeit zu. Er verzichtet darauf, selbst zu programmieren, damit er für die Koordination verfügbar bleibt, während andere Sitzungen ausgelastet sind.

Die einzelnen Aufgaben übernehmen Worker. Jeder hat seinen eigenen Gesprächskontext und eigene Ausführungswerkzeuge, sodass eine Fehlersuche, eine Antwort auf eine Codeüberprüfung und eine Funktionsänderung parallel bearbeitet werden können. Die Worker melden ihre Ergebnisse an den Router, der mit den Menschen kommuniziert, statt mehrere Sitzungen unabhängig voneinander antworten zu lassen.

DeepSeek zufolge kann oft ein kleineres Modell die Weiterleitung übernehmen, während leistungsfähigere Modelle die Arbeit erledigen, die über die Codequalität entscheidet. Für eine komplexe Aufgabe kann ein Worker außerdem Hilfsagenten erstellen. Der Router verwaltet die Beziehungen zwischen den Aufgaben, statt jeden einzelnen Arbeitsschritt darin zu planen.

Der Prototyp gibt jedem Arbeitsauftrag eine eigene Sitzung und ein eigenes Verzeichnis. Die Aufträge werden parallel gestartet, bis eine festgelegte Obergrenze erreicht ist. Betreiber können also steuern, wie viel Arbeit gleichzeitig beginnt. Getrennte Gesprächsverläufe verringern das Risiko, dass Details einer Aufgabe eine andere verdrängen, während der Router den gemeinsamen Überblick behält.

Wie Nachrichten ohne ständige Unterbrechungen zu Aufgaben werden

Chat-Nachrichten, Kommentare zu Codeüberprüfungen und automatisierte Testergebnisse werden zu Ereignissen, die Aktionen auslösen können. Der umfassendere Entwurf berücksichtigt auch E-Mails und Kalendererinnerungen. Continuous Integration (CI) bezeichnet automatisierte Prüfungen, die Code nach einer Änderung erstellen oder testen und Ergebnisse liefern, auf die ein Agent reagieren kann.

DeepSeek filtert diese Ereignisse in zwei Stufen. Zunächst prüfen gewöhnliche Programmregeln Faktoren wie Quelle, Gruppe und berechtigte Nutzer. Anschließend bewertet ein Modell die verbleibenden Kandidaten anhand des Kontexts und schriftlich festgelegter Richtlinien. So werden Modellaufrufe für routinemäßige Nachrichten vermieden, die keine Aktion erfordern.

Zusammengehörige Ereignisse bilden einen Thread, etwa die Kommentare zu einem Pull Request oder zu einem Chat-Thema. Sobald ein Worker den Auftrag übernimmt, abonniert er diesen Thread. Spätere Kommentare und Testergebnisse können dann direkt an ihn gehen, ohne dass der Router sie erneut zuweisen muss.

Abonnements können sich überschneiden. Mehrere Worker, die am selben Pull Request arbeiten, können dieselben Aktualisierungen erhalten und so Änderungen bemerken, die ihre Arbeit betreffen. Ein Worker kann auch mehrere zusammenhängende Threads verfolgen oder ein Ereignis an den Router zurückgeben, wenn es außerhalb seines Auftrags liegt.

Früh handeln, aber nur bei Bedarf sprechen

DeepSeek zufolge läuft intern bereits ein Super-Agent dauerhaft. Er reproduziert und behebt Probleme, reagiert auf Codeüberprüfungen und hilft bei der Entwicklung von Harness selbst. Eine schriftliche Regel erlaubt ihm, Fehler zu untersuchen, die in einem Gruppenchat erwähnt werden, auch wenn niemand den Agenten direkt markiert.

Die Regel sieht zunächst eine Untersuchung im Hintergrund vor. Der Agent versucht, das gemeldete Problem zu reproduzieren und eine einfache Lösung zu finden, bevor er ein brauchbares Ergebnis vorlegt. In einem Beispiel diskutierten Entwickler ein Problem, bei dem Tilden als durchgestrichene Formatierung angezeigt wurden, während der Agent bereits einen Pull Request mit einem Lösungsvorschlag eröffnet hatte.

Das Harness-Team beschreibt das Arbeitsprinzip in seiner README so:

So wenig menschliche Aufmerksamkeit wie möglich beanspruchen und so viel Mehrwert wie möglich bieten.

Der Prototyp wird aktiv, wenn eine berechtigte Person darum bittet oder eine vom Team verfasste Regel dies erlaubt. Sein Webpanel listet Arbeitsaufträge auf, bei denen menschliche Aufmerksamkeit erforderlich ist. Die Oberfläche konzentriert sich damit auf Entscheidungen und verwertbare Ergebnisse statt auf jeden Tool-Aufruf und jeden Zwischenschritt.

Alten Kontext und neue Anweisungen verfügbar halten

In DeepSeeks Entwurf wird das Kontextfenster eines Modells, also die begrenzte Informationsmenge, die es gleichzeitig berücksichtigen kann, wie ein Cache behandelt. Häufig benötigte Inhalte bleiben griffbereit; längere oder weniger relevante Verläufe bleiben außerhalb des Fensters, bis sie angefordert werden.

Der Essay bezeichnet diese Vorgänge als Inline und Spill. Bei Inline werden nützliche Details direkt in den aktuellen Kontext aufgenommen, etwa Nachrichten aus dem unmittelbaren Gesprächsumfeld, Kennungen oder eine kurze Vorschau. Bei Spill bleiben längere Inhalte an anderer Stelle und werden mit einem Verweis versehen, über den das Modell weitere Informationen abrufen kann.

Chain of Recall verknüpft diese Verweise. Ereignisse, Threads und Worker-Sitzungen erhalten eindeutige Kennungen. So kann der Agent von einer aktuellen Nachricht zum zugehörigen Gespräch, dann zu einem verwandten Worker und weiter zu einer anderen Codeüberprüfung gelangen. Ziel ist es, eine ältere Aufgabe kanalübergreifend wiederzufinden, ohne jedes Mal ihren gesamten Verlauf laden zu müssen.

DeepSeek befasst sich auch mit einem unmittelbareren Problem durch Unterbrechungen: Ein langer Befehl kann einen herkömmlichen Agenten daran hindern, zu antworten. Der asynchrone Mechanismus startet die Arbeit im Hintergrund und sendet das Ergebnis als neues Ereignis zurück. Nutzer können währenddessen weitere Anweisungen geben, etwa den Agenten um eine Kursänderung bitten oder ihn stoppen.

Das Team gibt an, dass dieser Mechanismus in DeepSeek Harness implementiert, aber standardmäßig nicht aktiviert ist. Auch die Kommunikationsregeln unterscheiden sich je nach Kanal: Laut Entwurf ist eine einzelne Sofortnachricht auf 100 Wörter begrenzt, während Pull Requests und Dokumente ausführlichere, strukturierte Erläuterungen zu Änderungen und Prüfungen erhalten.

Koordination in der Cloud, Arbeit auf dem lokalen Rechner

DeepSeek trennt die Berechnung, auf der der Agent läuft, den gespeicherten Sitzungsverlauf und den Rechner, auf dem Befehle ausgeführt werden. Der vorgeschlagene Agenten-Loop läuft in Cloud-Containern, der Sitzungsstatus liegt in einer Datenbank, und ein schlanker lokaler Dienst führt Befehle aus und gibt Ergebnisse zurück.

Diese Anordnung unterstützt Bring Your Own Machine (BYOM). Entwickler können einen vorhandenen Rechner mit Repository, Tools und unfertigen Änderungen verbinden, statt alles in eine neue entfernte Umgebung zu verlagern. Die Koordination über die Cloud bleibt verfügbar, wenn die Verbindung zu diesem Rechner abbricht; Aufgaben, die ihn benötigen, warten dann, bis das Gerät wieder erreichbar ist.

Eine unabhängige Watchdog-Sitzung prüft auf Fehler und ins Stocken geratene Arbeit. Sie soll mehr leisten, als lediglich Fehlermeldungen zu erkennen: Mithilfe eines Modells beurteilt sie, ob die Worker tatsächlich Fortschritte machen oder vom Ziel abweichen, und versucht bei Bedarf, den Fehler zu beheben.

DeepSeek stellt diese Elemente als Teile seiner umfassenderen Architekturentwicklung vor. Die README warnt, dass sich das öffentliche Paket und die interne Implementierung unterscheiden. Entwickler sollten deshalb den veröffentlichten Code prüfen, bevor sie sich auf bestimmte Funktionen des Entwurfs verlassen.

Was das Experiment gemessen hat

DeepSeek wiederholte jeden Versuchsaufbau fünfmal und verglich Super-Agent mit einer Version ohne direkte Ereigniszustellung sowie mit zwei Konfigurationen einer einzelnen Sitzung, die mit einem Hilfsagenten ausgestattet war. Zum Einsatz kamen synthetische Nachrichten und ein Tool, das langwierige Programmierarbeit simulierte. Nachrichtenintervalle und Arbeitsdauer wurden auf ein Viertel skaliert.

Der Median von 12,4 Minuten bedeutet, dass die Hälfte der Aufgaben bis zu diesem Zeitpunkt erledigt war. Das 95. Perzentil von 15,7 Minuten bedeutet, dass 95 Prozent innerhalb dieser Zeit abgeschlossen waren. Gegenüber dem 95. Perzentil von 29,5 Minuten bei der einzelnen Sitzung mit neutralen Anweisungen verkürzte Super-Agent diesen Wert um 13,8 Minuten beziehungsweise rund 47 Prozent.

Das Delegationsverhalten hilft, das Ergebnis zu erklären. Bei neutralen Anweisungen rief die einzelne Sitzung in keinem der fünf Durchläufe ihren Hilfsagenten auf. Bei ausdrücklicher Aufforderung, Aufgaben bevorzugt zu delegieren, tat sie dies in vier Durchläufen und erledigte die Arbeit im fünften selbst. Bei Super-Agent ist die Trennung zwischen Koordination und Ausführung eine strukturelle Vorgabe.

Die Tests untersuchten Planung und Koordination bei simulierter Ausführung. Die tatsächliche Codequalität, unabhängige Leistungsmessungen und die Zahl aktiver Nutzer wurden nicht veröffentlicht; das Team bezeichnet seine Messwerte als vorläufig. DeepSeek hat keinen Termin für eine Produktivversion genannt.

Schnellere Koordination benötigt mehr zwischengespeicherte Tokens

Die Parallelität von Super-Agent ging mit einer stärkeren Nutzung zwischengespeicherter Eingaben einher. Das System verarbeitete 23,23 Millionen zwischengespeicherte Tokens, verglichen mit 6,05 Millionen und 10,82 Millionen bei den beiden Konfigurationen mit nur einer Sitzung. Tokens sind die kleinen Texteinheiten, die ein Modell verarbeitet; bei zwischengespeicherten Eingaben werden zuvor übermittelte Inhalte wiederverwendet.

Ohne direkte Ereigniszustellung stieg die Zahl der zwischengespeicherten Tokens von 23,23 Millionen auf 31,77 Millionen, also um rund 37 Prozent. Die Zahl der Router-Entscheidungen nahm um etwa 30 Prozent zu. Folgeereignisse direkt an den zuständigen Worker zu senden, verringerte somit den Koordinationsaufwand innerhalb des parallelen Designs.

Batch-Verarbeitung half dem Router, ein höheres Nachrichtenaufkommen zu bewältigen. Als die Ereignisrate von etwa einem auf 40 Auslöser pro Minute stieg, wuchs die durchschnittliche Batch-Größe von 1,0 auf 2,8 und die Dauer der Anfragen von 2,5 auf 3,9 Sekunden. Die angegebene Inferenzzeit pro Router-Entscheidung sank von 6,4 auf 1,6 Sekunden.

Der praktische Zielkonflikt besteht zwischen kürzeren Wartezeiten für Menschen und mehr Modellverarbeitung über separate Sitzungen hinweg. Die Token-Zahlen beziffern keine Kosten; Teams, die einen Einsatz erwägen, müssen die Preise ihrer Modelle, die Parallelitätseinstellungen und ihr tatsächliches Arbeitsaufkommen berücksichtigen.

Lokale Berechtigungen machen Sicherheit zu einem zentralen Thema

Der Dokumentation zur Ausführung des Prototyps zufolge werden Worker-Befehle ohne Genehmigung unter dem Betriebssystemkonto des Betreibers ausgeführt. Shell-Befehle im Vordergrund wechseln nach fünf Sekunden in die Hintergrundausführung; für Hintergrundaufgaben stehen pro Durchlauf bis zu 30 Minuten zur Verfügung. Diese Einstellungen machen die Berechtigungen des Betreiberkontos zu einem konkreten Faktor beim Einsatz.

Auf einem verbundenen Rechner können Zugangsdaten, privater Code und sensible Dateien liegen. Prompt Injection, bei der schädliche Inhalte versuchen, einen Agenten anhand gelesener Materialien umzulenken, ist besonders heikel, wenn eingehende Nachrichten oder Repository-Inhalte Befehle auf diesem Rechner beeinflussen können.

DeepSeek nennt Sicherheit und Datenschutz, die Skalierung des Routers, langfristiges Gedächtnis und die Kommunikation zwischen Agenteninstanzen als noch ungelöste Bereiche. Die README fordert Nutzer auf, den Code zu prüfen und anzupassen, und warnt, dass Fehler und uneinheitliche Vorgehensweisen in der Softwareentwicklung fortbestehen können. Ein großer Teil der Entwicklungsarbeit wurde selbst von Coding-Agenten erledigt.

Die Veröffentlichung stieß rasch auf große Aufmerksamkeit, darunter auch mit einem Beitrag von Leandro von Werra, Forschungsleiter bei Hugging Face. Die zeitliche Abfolge zeigt, wie schnell sich der Prototyp verbreitete:

• 31. Oktober 2026, 09:32 UTC: Das GitHub-Repository wurde erstellt.
• 31. Oktober: Das Harness-Team veröffentlichte seinen Design-Essay; bis 22:10 UTC hatte das Repository 2.046 Sterne und 172 Forks.
• 1. November, 04:20 UTC: Das Repository erreichte 3.433 Sterne.

Für Entwicklungsteams stellt sich zunächst die Frage, ob sie ein experimentelles Koordinationssystem prüfen und anpassen wollen. Attraktiv ist die Aussicht, mit weniger Unterbrechungen mehr Aufgaben zu bewältigen. Zum Betrieb gehören jedoch auch Codeprüfungen, die Vergabe von Berechtigungen und die Entscheidung, bei welchen Aktionen ein Mensch eingreifen muss.

Wichtige Punkte

• DeepSeek hat einen unter MIT-Lizenz stehenden Forschungsprototyp für Programmieraufgaben in einem GitHub-Repository veröffentlicht, mit optionaler Feishu-Integration.
• Ein Router übernimmt die Koordination, während separate Worker Aufgaben parallel ausführen.
• Das interne System kann gemeldete Fehler gemäß schriftlich festgelegten Regeln untersuchen, ohne direkt markiert zu werden.
• In synthetischen Tests lag die mediane Bearbeitungszeit bei 12,4 Minuten und das 95. Perzentil bei 15,7 Minuten. Dabei wurden mehr zwischengespeicherte Tokens verwendet als bei Alternativen mit nur einer Sitzung.
• Worker führen Befehle ohne Genehmigung unter dem Konto des Betreibers aus. Berechtigungen und Zugangsdaten sind daher zentrale Sicherheitsaspekte.
• Der öffentliche Code unterscheidet sich vom internen System und bleibt ein Forschungsprototyp statt eines offiziellen DeepSeek-Produkts.