DeepSeek SuperAgent: So funktioniert die Architektur des Open-Source-Coding-Agenten

Aktualisiert am 2. November 2026 · Analyse von Forschung und Dokumentation

Der SuperAgent-Prototyp von DeepSeek macht aus Aktivitäten in einem Repository fortlaufende Programmierarbeit. Seine interessantesten Designentscheidungen betreffen nicht nur das Schreiben von Code: Das System muss entscheiden, welche Ereignisse eine Handlung verdienen, den Kontext einer Aufgabe bewahren und erkennen, wann ein Mensch übernehmen muss.

Ein Coding-Assistent kann einen Fehler in einer einzelnen Sitzung beheben. Ein Team braucht mehr: Ein Issue wird eröffnet, eine Korrektur geprüft, ein Check schlägt fehl und am nächsten Tag erscheint ein Kommentar. Jemand muss diese Ereignisse verbinden und über den nächsten Schritt entscheiden. SuperAgent ist ein Versuch, diese Koordination im Agentensystem selbst abzubilden.

Dieser Artikel untersucht den öffentlichen Prototyp und seine Dokumentation und stellt einen praktischen Ansatz für die Bewertung vor. Die Beispiele sind illustrativ; für diesen Artikel haben wir weder eine Installation betrieben noch die Leistung gemessen.

Was hat DeepSeek genau als Open Source veröffentlicht?

Das öffentliche Projekt dsh-superagent-prototype ist ein proaktiver Coding-Agent für ein einzelnes GitHub-Repository. GitHub liefert Anfragen und Aktivitäten; Feishu kann als weitere Quelle hinzukommen. Das System kann für eine autorisierte Anfrage eine Arbeitseinheit anlegen, sie in einer eigenen Agentensitzung und einem eigenen Verzeichnis bearbeiten und in der ursprünglichen Unterhaltung antworten, beispielsweise mit einem Pull Request.

Das Projekt bezeichnet sich als Forschungscode, nicht als offizielles Produkt. Laut README wurde die veröffentlichte Version aus interner Arbeit angepasst und unterscheidet sich sowohl von dieser Implementierung als auch von der in der begleitenden Forschung beschriebenen. Einige Forschungsideen sind zukünftige Entwicklungsrichtungen. Diese Unterscheidung ist wichtig: Eine Architekturidee in einer Veröffentlichung ist nicht automatisch eine Funktion dieser Version.

Wie wird aus einer Anfrage eine Programmieraufgabe?

Das Domänenmodell des Projekts trennt den Ursprung eines Ereignisses von der Arbeit, die daraus entstehen kann. Eine Source (Quelle) bringt Aktivitäten ins System. Ein Trigger (Auslöser) steht für ein Ereignis. Ein Ticket beschreibt eine Aufgabe; sein Mandate (Mandat) hält fest, auf welcher Grundlage sie angenommen wurde. Ein Executor bearbeitet das Ticket in einer eigenen Sitzung.

Der Router entscheidet, ob ein Kandidat neue Arbeit auslösen, einer bestehenden Aufgabe zugeordnet, ignoriert oder gegebenenfalls Arbeit stoppen soll. Der Executor führt die angenommene Aufgabe aus und meldet ihren Zustand. Die Trennung ermöglicht es dem System, neue Aktivitäten zu empfangen, während eine Implementierung läuft.

Beispiel: ein Issue und ein anschließender Review-Kommentar

Angenommen, ein autorisiertes Teammitglied erwähnt den Agenten in einem GitHub-Issue und bittet ihn, einen fehlgeschlagenen Test zu untersuchen. Der Agent nimmt die Anfrage an, bereitet ein Ticket-Verzeichnis vor und beginnt die Untersuchung. Öffnet er einen Pull Request, können spätere Diskussionen das zuständige Ticket erreichen. Eine menschliche Rückfrage innerhalb des Aufgabenbereichs kann der bestehende Executor bearbeiten; eine Anfrage außerhalb dieses Bereichs kann er zur erneuten Weiterleitung zurückgeben. Das Beispiel veranschaulicht das dokumentierte Modell und garantiert keine erfolgreiche Fehlerbehebung.

Wer darf den Agenten zum Handeln autorisieren?

Das Autorisierungssystem unterscheidet eine ausdrückliche Anfrage von einem abgeleiteten Kandidaten. Eine zugelassene Person, die sich an den Agenten wendet, kann eine ausdrückliche Anfrage stellen. Andere Aktivitäten, etwa bestimmte Nachrichten ohne direkte Ansprache oder Nachrichten zugelassener Bots, können je nach Richtlinie der Quelle zu abgeleiteten Kandidaten werden. Bevor diese angenommen werden, müssen sie anhand der aktiven Teamregeln bewertet werden.

Ausdrückliche Anfragen funktionieren in allen drei Modi. Das Projekt empfiehlt, mit observe zu beginnen, damit Betreiber Entscheidungen prüfen können, bevor sie die proaktive Annahme aktivieren. So lassen sich Regeln erkennen, die unnötig viele Vorgänge auslösen: Ein Ereignis kann technisch gültig sein und trotzdem die Aufmerksamkeit des Teams verschwenden.

Nachrichten aus einer abonnierten Unterhaltung liefern einem Ticket Kontext; sie erteilen nicht automatisch neue Befugnisse. Richtlinie, Zulassungslisten und Mandat bestimmen die Autorisierung. Issue-Texte, Kommentare und zitierte Dokumente bleiben Eingaben für eine Entscheidung. Eine Richtlinienänderung widerruft auch nicht sofort alle aktiven Mandate; die Dokumentation beschreibt Hinweise und eine erneute Prüfung vor bestimmten Fortsetzungen. Diese Einzelheiten sollte man kennen, bevor man annimmt, dass eine Einstellungsänderung alle laufenden Arbeiten unmittelbar stoppt.

Was geschieht in einer Arbeitssitzung?

Jedes Ticket erhält eine Executor-Sitzung und ein Verzeichnis unter dem konfigurierten Ausführungspfad. Ein Vorbereitungskommando kann eine Git-Worktree erstellen; ohne Vorbereitungskommando beginnt der Executor in einem leeren Verzeichnis. Eine fehlgeschlagene Vorbereitung wird als Fehler des Tickets aufgezeichnet. Die Ausführungsdokumentation beschreibt den vollständigen Ablauf.

Executors belegen beim Start und während aktiver Arbeit konfigurierte Ausführungsplätze. Das Design erlaubt einen zusätzlichen Platz für eine Nachricht einer Person oder eine Statusanfrage, wenn die reguläre Kapazität erschöpft ist. Andere Eingaben, darunter CI-Ergebnisse, warten auf einen regulären Platz. So soll eine volle Warteschlange nicht verhindern, dass eine Person ein bestehendes Ticket fortsetzen kann.

Das Panel unterscheidet unter anderem zwischen Arbeit in der Warteschlange, laufender Arbeit, Warten, ausstehender Prüfung, Blockierung und Fehlern. Das ist hilfreich: Ein Agent, der eine Entscheidung benötigt, sollte nicht genauso aussehen wie einer, der noch einen Test ausführt.

Wie geht SuperAgent mit Unterbrechungen und Wiederherstellung um?

Lang laufende Agentenarbeit braucht einen Plan für Fehler. Der Prototyp speichert Arbeitsschritte, bevor er beispielsweise eine Ausführung startet oder eine Eingabe zustellt. Fehlgeschlagene Zustellungen werden mit wachsenden Abständen erneut versucht; vorübergehende Fehler des Modellanbieters oder Netzwerks werden begrenzt wiederholt. Ein blockiertes oder fehlgeschlagenes Ticket nimmt keine automatischen Eingaben an, bis ein Mensch eingreift, ein entsprechender Bericht eingeht oder ein Betreiber einen neuen Versuch startet.

Nach einem Neustart des Hosts beginnen unterbrochene Ausführungen mit einem Wiederherstellungshinweis. Dieser fordert den Executor auf, sein Verzeichnis, die Git-Historie und GitHub zu prüfen, bevor er externe Aktionen wiederholt. Laut Dokumentation bleiben unter anderem Sitzungen, Verzeichnisse, Abonnements und ausstehende Nachrichten nach einem Neustart erhalten. Ein erneuter Versuch startet eine neue Ausführung in derselben Executor-Sitzung, im selben Verzeichnis, Branch und Pull Request.

Diese Mechanismen verringern das Risiko, den Arbeitsstand zu verlieren. Sie machen externe Aktionen nicht automatisch sicher und garantieren nicht, dass jede Aktion in allen Fehlerszenarien genau einmal erfolgt. Bevor eine Aktion wiederholt wird, die eine Nachricht senden, Daten verändern oder eine Bereitstellung auslösen könnte, sollten Betreiber prüfen, was tatsächlich geschehen ist.

Was braucht man, um den Prototyp auszuprobieren?

Das Repository bietet eine agentengestützte Einrichtungsanleitung und eine Anleitung zur manuellen Bereitstellung. Genannt werden Node.js 22.19+ oder 24+, pnpm, Git 2.32+, tmux, Python 3.8+, GitHub CLI 2.48+, eine kompatible Version von DeepSeek Harness und ein konfigurierter Modellanbieter. Die aktuellen Dateien enthalten mögliche Versionsänderungen und Plattformanforderungen.

Die Anleitung empfiehlt ein eigenes GitHub-Konto für den Agenten, eine zunächst kurze Zulassungsliste, den Modus observe und menschliches Mergen. Sie beschreibt außerdem ein separates Harness-Profil und ein Vorbereitungskommando für Arbeitskopien pro Ticket. Feishu ist optional. Prüfen Sie jeden Einrichtungsschritt und die Berechtigungen der Zugangsdaten selbst; die folgende Liste ersetzt nicht die Bereitstellungsanleitung des Projekts.

Ein erster Versuch, den wir durchführen würden

1. Verwenden Sie ein Wegwerf-Repository oder ein Repository mit geringem Risiko ohne sensible Daten. Geben Sie dem eigenen Agentenkonto nur die für den Test nötigen Rechte.
2. Lassen Sie die proaktive Annahme auf observe, wählen Sie einen autorisierten Betreiber und verlangen Sie menschliches Mergen.
3. Stellen Sie eine klar begrenzte Aufgabe, etwa die Diagnose eines reproduzierbar fehlschlagenden Tests, mit klaren Abnahmekriterien und ohne Bereitstellung.
4. Prüfen Sie die Routingentscheidung, den vorgeschlagenen Diff, die tatsächlichen Testergebnisse, Nachrichten und Modellnutzung. Halten Sie Fehlschläge ebenso wie Erfolge fest.
5. Prüfen Sie die beobachteten proaktiven Entscheidungen, bevor Sie eine Regel hinzufügen oder Berechtigungen erweitern.

Dies sind redaktionelle Empfehlungen, keine Ergebnisse eines praktischen Tests. Wählen Sie eine Ausführungsisolierung und Netzwerkregeln, die zu Ihrer Umgebung passen; die Verzeichnisse des Prototyps allein bieten sie nicht.

Kann der Agent seine eigenen Pull Requests mergen?

Die Einrichtungsanleitung empfiehlt, dass Menschen mergen, bis die Pull Requests des Agenten über längere Zeit zuverlässig korrekt waren. Die Ausführungsdokumentation beschreibt optionale Anweisungen für Auto-Merge unter Bedingungen, darunter erforderliche Genehmigungen. Dabei unterscheidet sie: Die Anweisungen steuern den Agenten, während GitHub-Branch-Protection die Regeln des Repositorys durchsetzt. Der Host besitzt keine separate Entscheidungslösung speziell für Merges. Wenn Genehmigungen erforderlich sind, sollten sie in GitHub erzwungen und veraltete Genehmigungen bei neuen Änderungen gegebenenfalls verworfen werden. Für einen rein manuellen Test empfiehlt die Einrichtung, den Auto-Merge-Abschnitt zu entfernen.

Wie sollte ein Team beurteilen, ob der Agent hilft?

Messen Sie den gesamten Aufwand rund um eine Änderung, nicht nur die Zeit bis zum Pull Request. Vergleichen Sie eine kleine Gruppe ähnlicher Aufgaben mit Ihrem üblichen Vorgehen und berücksichtigen Sie auch fehlgeschlagene oder abgebrochene Durchläufe.

Ein schneller Pull Request, dessen Korrektur Stunden dauert, ist nicht automatisch ein Produktivitätsgewinn. Ebenso kann ein Agent, der im richtigen Moment schweigt, nützlicher sein als einer, der für jedes Ereignis ein Ticket eröffnet. Halten Sie Aufgabenschwierigkeit und Stichprobengröße fest, bevor Sie Schlussfolgerungen ziehen.

Wo liegen die Grenzen der öffentlichen Version?

Sie ist auf ein Repository ausgerichtet, hängt vom umgebenden Harness und seinen Integrationen ab und wird ausdrücklich als Forschungssoftware beschrieben. Die Verantwortlichen warnen vor möglichen Fehlern und uneinheitlichen Entwicklungspraktiken. Einige Forschungskonzepte sind im öffentlichen Code nicht implementiert. In der Projektdokumentation haben wir keine Grundlage für einen allgemeinen prozentualen Produktivitätsgewinn oder die Zusicherung gefunden, dass der Agent ein Produktions-Repository selbstständig verwalten kann.

Der Architekturbeitrag ist konkreter: Das Projekt behandelt Aufgabenzuständigkeit, Autorisierung, Kontinuität und menschliche Aufmerksamkeit als technische Probleme. Teams können diese Entscheidungen untersuchen, auch wenn sie sich gegen den Einsatz dieses Prototyps entscheiden.

Häufig gestellte Fragen

Ist DeepSeek SuperAgent ein neues Modell?

Nein. Das veröffentlichte Projekt ist ein Agentensystem-Prototyp als Paket für DeepSeek Harness. Es benötigt einen konfigurierten Modellanbieter; Modell und Orchestrierungssystem sind getrennte Ebenen.

Ist SuperAgent Open Source?

Ja. Das öffentliche Repository steht unter der MIT-Lizenz. Der veröffentlichte Code wurde aus der internen Implementierung des Teams angepasst und ist nicht mit ihr identisch.

Verhindert der Modus observe jede Arbeit?

Nein. Er verhindert die Annahme abgeleiteter Kandidaten als proaktive Arbeit und speichert positive Bewertungen; ausdrückliche Anfragen können weiterhin angenommen werden.

Kann SuperAgent mit mehreren Repositorys arbeiten?

Das öffentliche README beschreibt den Prototyp als Coding-Agent für ein einzelnes GitHub-Repository. Eine umfassendere Orchestrierung mehrerer Repositorys sollte nicht vorausgesetzt werden.

Reicht eine separate Worktree als Schutz?

Nein. Die Ausführungsdokumentation bezeichnet Verzeichnisse und Befehls-Wrapper nicht als Sicherheitsgrenze. Executors führen Befehle unter dem Betriebssystemkonto des Betreibers aus; Isolierung und Berechtigungen müssen daher gesondert betrachtet werden.