DeepSeek Super-Agent: Was es ist, wie es funktioniert und was noch fehlt21 min read

Öffnen Sie drei Codierungsagenten gleichzeitig und Sie können das Problem spüren. Einer wartet auf eine Entscheidung, einer ist vor zwanzig Minuten fertig und Sie haben bereits vergessen, welcher den Auth-Fix hat. Das Harness-Team von DeepSeek hat es auf den Punkt gebracht: Seiner Erfahrung nach kann eine Person nur drei bis fünf aktive Agentensitzungen gleichzeitig verfolgen. Ab diesem Zeitpunkt stellt das Modell nicht mehr den Flaschenhals dar. Du bist.

Am 31. Oktober 2026 veröffentlichte das Team einen Designartikel für einen sogenannten Superagenten und stellte einen Prototyp namens dsh-superagent als Open-Source-Lösung zur Verfügung. Es handelt sich um einen proaktiven Codierungsagenten für ein GitHub-Repository. Eine langlebige Router-Sitzung kommuniziert mit Leuten und verteilt Arbeit, und jede akzeptierte Anfrage erhält eine eigene Worker-Sitzung, die in einer Pull-Anfrage oder einer Frage endet. Das Endlager passierte in etwa zwei Tagen 12.000 Sterne. In der README-Datei wird deutlich, dass es sich hierbei um Forschungscode und nicht um ein offizielles DeepSeek-Produkt handelt.

Dieser Leitfaden richtet sich an Ingenieure und Teamleiter, die wissen möchten, was der Prototyp macht, wie das Router- und Worker-Design funktioniert, was die Benchmark-Zahlen beweisen und was nicht, und was sie überprüfen müssen, bevor sie ihn auf ein echtes Repository verweisen.

Eine Anmerkung vor den Details. Die Antwort eines Arbeiters auf „Diesen Fehler beheben“ ist eine Pull-Anfrage, und GitHub ist dafür ein gutes Zuhause. Der Rest dessen, was Agenten rund um den Code produzieren, ist schwieriger zuzuordnen: die Beschreibung der Grundursache, die Testzusammenfassung, die Vergleichstabelle, nach der ein Prüfer gefragt hat.AgentGrid.ioist ein gemeinsamer Arbeitsbereich, in dem Menschen und KI-Agenten Dokumente, Apps und Dateien erstellen, bearbeiten und teilen, mit einer Live-Version, Zuordnung und Verlauf. Gegen Ende kommen wir wieder dorthin zurück, wo es hingehört.

Was ist DeepSeek Super-Agent?

Zwei Dinge erschienen gleichzeitig. Der erste ist ein langer Designartikel mit dem Titel „Exploring Super-Agent Design: Towards a More Autonomous Agent System“. Das Harness-Team hat es auf Chinesisch geschrieben und am 1. November eine maschinell übersetzte englische Version auf X veröffentlicht. Es wurde mehr als 2,2 Millionen Mal angesehen. Der zweite ist der Code:deepseek-ai/dsh-superagent-prototyp, veröffentlicht unter der MIT-Lizenz.

Erforschung des Superagentendesigns: Auf dem Weg zu einem autonomeren Agentensystem

https://t.co/gwwIHtyCRQ

– DeepSeek-Geschirr (@DeepSeekHarness)1. November 2026

Es handelt sich nicht um ein neues Modell. dsh-superagent ist ein Bundle fürDeepSeek Kabelbaum, DeepSeeks Open-Source-Agentennutzung, die sich nach Angaben des Unternehmens weltweit in der öffentlichen Vorschau befindet. Das Bundle überwacht ein GitHub-Repository und, wenn Sie es einschalten, chattet Feishu. Wenn jemand auf einer Zulassungsliste den Agenten um Arbeit bittet, öffnet dieser ein Arbeitselement, führt es in seiner eigenen Sitzung und seinem eigenen Verzeichnis aus und antwortet in der ursprünglichen Konversation. Ein Webpanel zeigt nur das, was eine Person braucht.

Der Name ist einfacher als er klingt. Cui Tianyi aus der Produktabteilung von DeepSeek und einer der letzten Rezensenten des Artikels erklärte in einem Zhihu-Beitrag, dass „super“ als hochgestellt versus tiefgestellt gemeint sei. Ein Superagent fügt eine Ebene über dem Agenten hinzu, der die Arbeit erledigt, im Gegensatz zu einem Unteragenten, der eine Ebene darunter hinzufügt. Es ist kein Anspruch auf überlegene Intelligenz.

Die README-Datei beginnt mit einer Warnung, die es wert ist, vollständig gelesen zu werden: „Forschungsprototyp nur als Referenz, kein offizielles DeepSeek-Produkt.“ Es wird hinzugefügt, dass ein Großteil der Entwicklung von Coding-Agenten durchgeführt wurde, dass der Code möglicherweise Fehler enthält und dass einige Entwürfe im Artikel Anweisungen für zukünftige Arbeiten darstellen und nicht implementiert sind.

Ein weiterer DeepSeek-Drop: dsh-superagent

Ein Agenten-Framework, das die GitHub-Probleme und PRs eines Repos mit vielen Agenten parallel bearbeitet und so wenig menschliche Aufmerksamkeit wie möglich beansprucht und gleichzeitig so viel Wert wie möglich liefert.

pic.twitter.com/XR73mIvA0V

– Leandro von Werra (@lvwerra)31. Oktober 2026

Warum sagt DeepSeek, dass der Engpass in der menschlichen Aufmerksamkeit liegt?

Der Artikel beginnt mit einer einfachen Beobachtung. Im vergangenen Jahr sind die Codierungsagenten so gut geworden, dass eine einzelne Aufgabe durch das Modell eingeschränkt wird. Sobald Sie jedoch mehrere Aufgaben gleichzeitig ausführen, liegt das Limit bei Ihnen. Jede Sitzung ist isoliert, sodass Sie manuell zwischen ihnen wechseln und den Überblick behalten, was jeder weiß. Wenn Sie eine CLI, einen MCP oder einen Chat-Connector in eine lokale Sitzung einbinden, können Sie über neue Ereignisse Bescheid wissen, blockieren aber weiterhin lange Befehle, vermischen Kontexte aus verschiedenen Aufgaben und stoppen, wenn Ihr Laptop in den Ruhezustand wechselt.

Die Antwort von DeepSeek besteht darin, die Sitzung nicht mehr als die von Ihnen verwaltete Einheit zu behandeln. Es listet vier Eigenschaften auf, die ein Superagent haben sollte:

• Kontinuierlich.Sie sprechen mit ihm dort, wo Sie bereits arbeiten, z. B. im Chat oder in GitHub-Kommentaren, und er verhält sich wie ein einziger Agent. Wenn Sie im Chat nach Plan A fragen und in einem Pull-Request-Kommentar zu Plan B wechseln, folgt Folgendes.
• Produktiv.Es führt mehrere komplexe Aufgaben parallel aus und nimmt die nächste Anweisung entgegen, bevor die letzte abgeschlossen ist.
• Proaktiv.Es beobachtet das Geschehen, handelt bei dem, was es wert ist, behandelt zu werden, und schweigt ansonsten.
• Anhaltend.Es bleibt online und wird nach Ausfällen wiederhergestellt, ohne dass Sie es neu starten müssen.

Die Autoren argumentieren, dass keine einzelne ReAct-Schleife alle vier liefern kann, sodass die Qualitäten aus der Architektur rund um das Modell stammen müssen. Das ist das eigentliche Thema des Artikels, und die visuelle Erklärung unten, die von Hesam geteilt wird, ist eine schnelle Möglichkeit, das gesamte Design auf einer Seite zu sehen.

Hier ist eine visuelle Erklärung des Artikels von DeepSeek über Super-Agent:https://t.co/bByKYDoq6h pic.twitter.com/BhzbBh3NrP

– ℏεsam (@Hesamation)1. November 2026

Wie funktioniert das Router- und Worker-Design?

Stellen Sie sich einen guten technischen Manager vor, der während des Stand-up-Vorgangs nie Code schreibt. DieRouterist eine langlebige Sitzung, die jede Nachricht von jedem Kanal empfängt. Es werden keine Aufgaben ausgeführt. Es entscheidet, worum es in einer Nachricht geht, übergibt neue Arbeiten an einen Mitarbeiter und schreibt jede Antwort an die beteiligten Personen. Im Artikel heißt es, dass es überhaupt ohne Shell-Tool laufen kann und dass dafür in der Regel ein leichteres, schnelleres Modell ausreicht.

AArbeiterist eine separate Sitzung mit einem isolierten Kontext und einem vollständigen Satz an Tools, die einer Aufgabe gewidmet ist. Arbeiter sprechen nie direkt mit Menschen. Sie melden den Status an den Router, der die Antworten mit einer Stimme beantwortet. Im Prototyp erhält jedes Ticket eine eigene Sitzung und ein eigenes Verzeichnis, typischerweise ein Git-Worktree, und die Anzahl der Worker ist begrenzt. Die Standardeinstellung ist drei gleichzeitig, einstellbar von 1 bis 16, wobei ein zusätzlicher Steckplatz frei bleibt, damit die Nachricht einer Person immer durchkommen kann.

Zwei Details machen dies zu mehr als einer Aufgabenwarteschlange.

Follow-ups überspringen den Router.Sobald ein Worker eine Pull-Anfrage oder einen Chat-Thread besitzt, abonniert er diesen Thread. Spätere Kommentare gehen direkt darauf ein, ohne zusätzlichen Modellaufruf am Router. Wenn sich herausstellt, dass sich ein Kommentar auf etwas anderes bezieht, gibt der Mitarbeiter ihn zurück.

Bursts werden gebündelt.Trigger, die während eines Modells eintreffen, werden in die Warteschlange gestellt und gemeinsam in den nächsten Aufruf eingefügt. Die Autoren haben den Effekt gemessen und wir sehen uns die Zahlen unten an.

Noch ein Kontrastpunkt. Der Artikel unterscheidet dies von einem Agententeam. In einem Agententeam unterteilt ein Lead eine komplexe Aufgabe in Schritte und koordiniert die Rollen, die daran arbeiten, was eine hohe Denklast darstellt. Der Superagent-Router verteilt nur unabhängige Aufgaben und verfolgt deren Zusammenhang auf hoher Ebene. Das Werk selbst wird dadurch nicht zerlegt.

Was macht es, wenn niemand fragt?

Hier wird die Philosophie des Projekts in die Praxis umgesetzt. Das erste Dokument im Repository bringt das Prinzip in einer Zeile zum Ausdruck: Nehmen Sie so wenig menschliche Aufmerksamkeit wie möglich in Anspruch und geben Sie so viel Wert wie möglich. Jede Nachricht, die der Agent sendet, kostet die Aufmerksamkeit eines Kollegen, daher spricht er nur, wenn eine Person handeln muss oder ein Ergebnis verwenden kann, und er handelt nur, wenn er dazu aufgefordert wird oder wenn eine vom Team verfasste Regel dies zulässt.

Das Tor, das dies erzwingt, ist einfacher Code, kein Modell. Es prüft anhand der Zulassungsliste des Teams, wer eine Anfrage stellt, und zeichnet auf, wie stark die Anfrage ist:

Dieser Beobachtungsmodus gefällt mir am besten. Der Agent zeichnet zunächst auf, was er getan hätte, sodass das Team diese Datensätze auf der Registerkarte „Auswerten“ lesen und seine Berechtigungen nur dann erweitern kann, wenn sie richtig aussehen. Nachrichten, Kommentare und zitierte Dokumente werden als Input für eine Entscheidung behandelt. Sie können nicht ändern, was der Agent tun darf.

Der Designartikel zeigt, wie proaktives Arbeiten in der Praxis aussieht. In der internen Benutzergruppe DeepSeek Harness hat das Team eine Richtlinie zum „stillen Reproduzieren und Korrigieren“ konfiguriert. Wenn jemand ein Problem meldet oder eine vorgeschlagene Änderung bespricht, versucht der Agent, es zu reproduzieren und im Hintergrund eine Lösung zu finden, und liefert erst ein Ergebnis, nachdem er das Problem bestätigt und eine einfache Lösung gefunden hat. Sonst bleibt es ruhig. Der Artikel enthält auch eine klare Regel für Chat-Kanäle, die die Autoren angeblich überprüft haben: Jede Antwort darf maximal 100 Wörter lang sein. Auf GitHub hingegen sollten Pull-Requests dicht sein, mit dem Problemhintergrund, der Änderungsbeschreibung und den Verifizierungsergebnissen.

Standardmäßig beginnt jede vom Agenten gepostete GitHub-Nachricht mit der Zeile „Dies stammt von einem automatisierten Agenten, nicht von einem Menschen“. Teams können dies zusammen mit den übrigen Eingabeaufforderungen bearbeiten.

Halten die Benchmark-Zahlen stand?

Der Artikel enthält ein kleines Experiment, und die Autoren achten darauf, es nur als Hinweis zu bezeichnen. Vier Designs liefen nebeneinander in einem Stream aus Gruppenchats und CI-Nachrichten: etwa 300 Nachrichten pro Durchlauf, etwa 20 davon echte Arbeitsanfragen, jeweils fünf Durchläufe. Die Codierungsarbeit wurde mit einem Tool simuliert, das einfach nur Zeit kostet. Der Test misst also Planung und Koordination und nicht die Qualität des Codes von irgendjemandem.

Lesen Sie die Tabelle zweimal, denn die Überschrift ist nicht die ganze Geschichte. Das Router-Design verkürzte die p95-Abschlusszeit auf etwa die Hälfte einer einzelnen Sitzung, verbrauchte jedoch etwa das Zwei- bis Vierfache der Cache-Lese-Tokens. Und die interessanteste Zeile ist die zweite: Das Entfernen der Pass-Through-Verknüpfung führte nicht dazu, dass Aufgaben schneller oder langsamer abgeschlossen wurden, sondern dass der Router lediglich etwa 30 Prozent mehr Entscheidungen traf und 37 Prozent mehr Token verbrennte.

Meiner Meinung nach liegt der eigentliche Befund in den Einzelsitzungszeilen. Bei einer neutralen Eingabeaufforderung rief das Modell in keinem der fünf Durchläufe einen Subagenten an. Die Arbeit erledigte es selbst, neue Nachrichten unterbrachen es ständig und die langsamsten Aufgaben dauerten 29,5 Minuten. Mit einer Aufforderung zum Delegieren delegierte es in vier von fünf Durchläufen, und im verbleibenden Durchlauf beurteilte das Modell die Arbeit als „gering“ und erledigte sie selbst. Eine einzelne Sitzung hängt von der Stimmung des Models ab. Ein Router, der keinen Code ausführen darf, kann diesen Fehler nicht machen.

Allein durch einen separaten Stresstest des Routers stieg die Ankunftsrate entscheidungsrelevanter Ereignisse von etwa 1 auf etwa 40 pro Minute. Der durchschnittliche Batch wuchs von 1,0 auf 2,8 Ereignisse, die Zeit pro Anfrage stieg nur von 2,5 auf 3,9 Sekunden und die amortisierte Zeit pro Entscheidung sank von 6,4 auf 1,6 Sekunden. Je mehr Ereignisse sich häufen, desto günstiger wird jedes einzelne, bis zu einem gewissen Grad, den die Autoren sagen, abhängig von der Kontextlänge und davon, wie viele Ereignisse ein Modell in einer Runde genau verarbeiten kann.

DeepSeek hat gerade seinen Super-Agent-Prototyp als Open Source veröffentlicht. Eine Router-Sitzung kommuniziert mit Personen und verteilt Arbeit, und isolierte Mitarbeiter führen parallel Aufgaben von GitHub-Ereignissen aus. In ihrem eigenen Test sank die p95-Abschlusszeit im Vergleich zu einer einzelnen Sitzung mit Subagenten von 29,5 auf 15,7 Minuten.

Der Wal ist wieder Open Source.pic.twitter.com/mS4sRbHmyx

– Mollig (@kimmonismus)1. November 2026

Dies sind selbstberichtete Ergebnisse zur synthetischen Arbeit. Sie zeigen, dass die Planungsidee sinnvoll ist. Sie zeigen nicht, dass der Prototyp Ihre Fehler schneller behebt.

Was sagen Personen, die dem Projekt nahe stehen, zu seinen Grenzen?

Kurz nach der Veröffentlichung schrieb Cui Tianyi aus der Produktabteilung von DeepSeek und einer der letzten Rezensenten des Designartikels, wie er das Design sieht. Sein Rahmen ist nützlich, weil er bescheiden ist. Den zentralen Kompromiss nennt er Kontinuität über Aufgaben hinweg vs. Aufgabendurchsatz.

In Bezug auf Grenzen ist die Überprüfung direkt. Der Prototyp implementiert nur einen Teil des vorgeschlagenen Designs. Zum Zeitpunkt seiner Überprüfung verfügte DeepSeek Harness über kein integriertes Langzeitgedächtnis über mehrere Sitzungen hinweg. Und das System wurde nur in einer kleinen, vertrauenswürdigen Umgebung innerhalb des Unternehmens validiert. Im Abschnitt „Offene Probleme“ des Artikels werden die Skalierung des Routers, Speicher über Monate, Arbeiten ohne Sitzungen, Kontextgrenzen zwischen Agenten und wie isolierte Agenten miteinander kommunizieren sollten sowie Sicherheit aufgeführt.

Was sollten Sie vor der Ausführung überprüfen?

Die Dokumentation ist offener als die meisten Startbeiträge und es lohnt sich, ihre Warnungen als Anforderungen zu betrachten.

• Arbeitnehmer haben breiten Zugang.Beide Berechtigungsvoreinstellungen, für den Router und für die Worker, laufen mitdanger-full-accessals Betriebssystembenutzer des Betreibers. Die Konto-Wrapper wählen aus, welche GitHub-Anmeldeinformationen der Agent verwendet. In den Dokumenten heißt es jedoch, dass es sich dabei um Standardeinstellungen und nicht um eine Sicherheitsgrenze handelt, da ein Worker weiterhin ein Programm über den absoluten Pfad ausführen oder Ihr Home-Verzeichnis lesen kann. Die Empfehlung ist ein dediziertes Betriebssystemkonto, das nur die Anmeldeinformationen des Agenten enthält.
• Nicht vertrauenswürdige Eingaben sind die offene Sicherheitsfrage.Der Artikel warnt davor, dass jedes angeschlossene Gerät erreicht werden könnte, wenn eine sofortige Injektion oder ein Servereingriff die Cloud-Agent-Schleife gefährdet, und dass Anmeldeinformationen, die in den Kontext des Modells gelangen, verloren gehen können.
• Menschen verschmelzen standardmäßig.Der Agent aktiviert niemals die automatische Zusammenführung unter seinem eigenen Konto. Für die automatische Zusammenführung ist die CLI eines zweiten Kontos erforderlich, die in der Eingabeaufforderung für die Bereitstellungsanforderungen genannt wird, und die Standardanweisungen lassen dies nur für kleine, genehmigte Pull-Anfragen unter 200 geänderten Zeilen zu.
• Es basiert auf einem Repository.Jedes Setup überwacht ein einzelnes GitHub-Repository, und Feishu, ein in China verbreitetes Arbeitsplatz-Chat-Tool, ist die andere erstklassige Quelle.
• Sie benötigen den DeepSeek-Kabelbaum und einen Modellanbieter.Setup listet Node.js 22.19 oder neuer, pnpm, Git 2.32 oder neuer, tmux, Python 3.8 oder neuer und GitHub CLI 2.48 oder neuer auf. Das Konfigurieren eines Modellanbieters ist ein Bedienerschritt.
• Lärm ist ein Kostenfaktor.Im Philosophiedokument heißt es, das Mittel nicht zur Volumenproduktion zu verwenden. Massen-Pull-Requests und Broadcast-Nachrichten kosten Ihr Team mehr, als es gibt.

Wie würden Sie es versuchen, ohne Ihr Haupt-Repository zu gefährden?

Das Setup besteht aus vielen Schritten. Das Projekt fordert Sie daher auf, dies von einem Coding-Agenten durchführen zu lassen. Laut README stellt der Agent jeweils eine kurze Frage, zeigt einmal den vollständigen Plan und installiert und konfiguriert dann alles. Ein vorsichtiger erster Lauf sieht so aus:

1. Wählen Sie ein Wegwerf-Repositoryund ein dedizierter Maschinenbenutzer oder ein Betriebssystemkonto. Verwenden Sie nicht Ihr eigenes Login.
2. Erstellen Sie ein separates GitHub-Konto für den Agenten.Alles, was es schreibt, erscheint unter diesem Namen.
3. Öffnen Sie das Repository in Ihrem Codierungsagenten und fügen Sie die Eingabeaufforderung unten ein.Beantworten Sie die Fragen einzeln.
4. Behalten Sie die erlaubte Liste für sichund lassen Sie den Akzeptanzmodus auf Beobachtung.
5. Fordern Sie etwas Kleines an.Kommentieren Sie von einem zugelassenen Konto aus@<agent login> <request>zu einem Thema. Innerhalb von etwa einer Minute sollte in der Übersicht des Panels ein Ticket erscheinen.
6. Lesen Sie die Registerkarte „Bewertung“ eine Woche lang.Erweitern Sie die Liste oder wechseln Sie nur dann auf „Automatisch“, wenn die „würde akzeptieren“-Datensätze richtig aussehen.

Read SETUP.md in this repository and set up dsh-superagent with me.

Das Philosophiedokument des Projekts gibt den Betreibern vier Regeln vor, die es wert sind, wiederholt zu werden: Beginnen Sie eng, stimmen Sie auf weniger Lärm ab, verwenden Sie den Agenten nicht, um Lautstärke zu erzeugen, und machen Sie sich zu eigen, was er verspricht.

Wohin soll die restliche Arbeit des Agenten gehen?

Angenommen, ein Mitarbeiter verbringt eine Stunde mit einem unregelmäßigen Integrationstest. Der Pull-Request ist die Lösung. Aber die Untersuchung dahinter, welche Tests fehlschlugen, welche Hypothesen es ausschloss, was die Zeittabelle ergab, gehört nicht in eine PR-Beschreibung und ist genau das, was der Rezensent anfechten möchte. Bleibt das nur in einer Chat-Antwort, beginnt der nächste Agent oder Teamkollege von vorne.

AgentGrid.ioist für diese Übergabe konzipiert. Menschen und KI-Agenten arbeiten an denselben Live-Dokumenten, Apps und Dateien, mit einer stabilen Adresse, kontrolliertem Zugriff und einem Versionsverlauf. In den Dokumenten von AgentGrid.io wird die Verbindung eines befehlsfähigen Agenten durch Ausführen beschriebennpx @animaapp/cli@latest login. Ein Mensch genehmigt den Namen des Agenten, sein Team und seine Aktionen: Lesen, Schreiben, Teilen oder Veröffentlichen. Danach erscheinen die Änderungen des Agenten im Verlauf unter seinem eigenen Namen. Der Prototyp verfügt über keine integrierte AgentGrid.io-Integration. Betrachten Sie dies also als ein Muster, das Sie mit seinen Workern ausprobieren können, und nicht als dokumentierte Funktion.

In der Praxis schreibt der Mitarbeiter seine Untersuchung als Markdown-Datei, der Prüfer kommentiert eine Tabellenzeile, ein anderer Assistent präzisiert die Zusammenfassung und der Pull-Request verweist auf eine aktuelle Version statt auf drei eingefügte Kopien.

Eine andere Sichtweise auf mehrere Personen, die sich einen Agenten teilen, finden Sie in unserem LeitfadenGrok Bot Team Bots. Und wenn Sie sich fragen, was unter einem gehosteten Agenten läuft, finden Sie hier unseren LeitfadenClaude Managed Agentsbefasst sich mit Anthropics Version derselben Gehirn-Hände-Splittung, die im Artikel von DeepSeek zitiert wird.

Wann sollten Sie dsh-superagent verwenden und wann etwas anderes?

• Verwenden Sie dsh-superagentum aus einem seriösen, dokumentierten Entwurf zu lernen, um ein geschlossenes Experiment auf einem Repository mit geringem Risiko durchzuführen oder um dessen Ideen auszuleihen: ein Router, der niemals Code ausführt, Tickets mit einem angegebenen Umfang, Beobachtungsmodus vor Automodus.
• Verwenden Sie einen einzigen interaktiven Codierungsagentenwenn Sie eine Aufgabe nach der anderen bearbeiten und diese Schritt für Schritt steuern möchten. Der Superagent ist für die gegenteilige Situation konzipiert.
• Verwenden Sie AgentGrid.iowenn es sich bei der Ausgabe um ein Dokument, einen Bericht oder eine App handelt, die von mehreren Personen und Agenten überprüft, bearbeitet und veröffentlicht werden muss, unabhängig davon, welcher Agent sie erstellt hat.

Häufig gestellte Fragen

Was ist DeepSeek Super-Agent?

Es handelt sich um einen Forschungsprototyp mit dem Namen dsh-superagent, der am 31. Oktober 2026 vom Harness-Team von DeepSeek unter der MIT-Lizenz veröffentlicht wurde. Es handelt sich um einen proaktiven Codierungsagenten für ein GitHub-Repository. Eine langlebige Router-Sitzung nimmt Anfragen entgegen und weist jede akzeptierte Anfrage einer eigenen Worker-Sitzung zu, die in der ursprünglichen Konversation antwortet, normalerweise mit einer Pull-Anfrage.

Ist der DeepSeek Super-Agent ein offizielles DeepSeek-Produkt?

Nein. In der README-Datei wird es als Forschungsprototyp bezeichnet, der nur als Referenz dient, und nicht als offizielles DeepSeek-Produkt, und es wird empfohlen, es zu überprüfen und anzupassen, bevor Sie es in Ihrer eigenen Umgebung verwenden. Es ist auch nicht identisch mit der internen Version oder der im Designartikel beschriebenen Implementierung.

Wie unterscheidet sich ein Superagent von einem Subagenten?

Ein Subagent fügt eine Ebene unter dem Arbeitsagenten hinzu. Ein Superagent fügt darüber eine Ebene hinzu. Bei diesem Design sitzt der Router über vielen Arbeitern, kommuniziert mit Leuten und verteilt Aufgaben, während jeder Arbeiter eine Aufgabe isoliert erledigt. Bei dem Namen geht es um die Position, nicht um den Anspruch größerer Intelligenz.

Benötigt es Feishu oder nur GitHub?

GitHub allein reicht aus. Feishu ist eine optionale zweite Quelle, und in der Dokumentation heißt es, dass ein Feishu-Setup-Fehler nur die Feishu-Quelle deaktiviert.

Ist die Ausführung in einem Unternehmens-Repository sicher?

Nicht so wie es ist. In den Dokumenten heißt es, dass Arbeiter mit vollem Zugriff als Betriebssystembenutzer des Betreibers ausgeführt werden und dass die Wrapper-Konten keine Isolationsgrenze darstellen. Sie empfehlen ein dediziertes Betriebssystemkonto, ein dediziertes Agentenkonto auf GitHub, eine kurze Zulassungsliste und einen Beobachtungsmodus, während Sie lernen, wie sich der Agent verhält.

Ist es schneller als eine einzelne Coding-Agent-Sitzung?

Im eigenen simulierten Test der Autoren beendete das Router-Design die langsamsten Aufgaben in 15,7 Minuten gegenüber 29,5 Minuten für eine einzelne Sitzung mit einem Subagenten-Tool und mehr Tokens. Der Test verwendete simulierte Codierungsarbeit und fünf Durchläufe pro Entwurf, sodass er Vorteile bei der Planung und nicht bei der Codequalität zeigt.