DeepSeek Super-agent: Was Cloud-Coding-Agenten sind und wo es sich einordnet

In Entwickler-Tools hat sich eine neue Gewohnheit verbreitet: Man hinterlässt irgendwo eine Aufgabe – ein Issue, eine Chat-Erwähnung oder einen Prompt – klappt den Laptop zu und kehrt zu einem Branch oder Pull Request zurück, den ein Agent währenddessen erstellt hat. GitHub, Cursor, OpenAI, Anthropic, Cognition und xAI bieten inzwischen alle eine Variante davon an, unter Bezeichnungen wie Cloud-Agent, Hintergrund-Agent, Cloud-Sitzung oder autonomer Softwareentwickler. Dieser Artikel erklärt die Kategorie: Was diese Produkte tatsächlich tun, wie der Ablauf funktioniert, worauf man verzichtet und wo sich DeepSeeks Open-Source-Prototyp Super-agent einordnet.

Was als Cloud-Coding-Agent gilt

Die Bezeichnung ist weit gefasst. Deshalb lohnt es sich, die drei Bestandteile zu benennen, die alle Produkte dieser Kategorie gemeinsam haben:

• Ein Auslöser, für den kein geöffneter Editor erforderlich ist. Die Arbeit kommt als Issue-Zuweisung, @Erwähnung in Slack oder Feishu, Prompt in einer Web-App, API-Aufruf oder Übergabe über eine CLI.
• Eine Umgebung außerhalb des eigenen Rechners. Der Agent klont das Repository, installiert, was er braucht, und arbeitet in einer Sandbox oder einem Arbeitsbereich, der vom Anbieter oder der eigenen Organisation verwaltet wird.
• Ein überprüfbares Ergebnis. Am Ende steht ein Branch, ein Diff, ein Entwurf für einen PR oder ein Kommentar – etwas, das eine Person prüfen und weiterverarbeiten kann.

Damit unterscheidet sich diese Kategorie von zwei benachbarten Formen. Ein lokaler IDE-Agent läuft auf dem Laptop, während man ihn beobachtet; ein Chat-Assistent beantwortet Fragen, ohne das Repository anzufassen. Ein Cloud-Coding-Agent liegt dazwischen: Er hat echte Tools und einen echten Checkout, aber der Mensch soll sich zurückziehen.

Das Wort Bot beschreibt die chatbasierte Form derselben Idee. Statt ein Issue zuzuweisen, erwähnt man den Agenten in Slack, Teams oder Feishu. Der Auslöser ändert sich, die Remote-Umgebung nicht. Das Ergebnis kann ein PR, ein Diff oder eine Reihe fertiger Dateien sein.

Die Produktübersicht

Sechs Produkte, beschrieben nach den Angaben ihrer Anbieter:

Grok Bot ist der breiteste Eintrag: xAI beschreibt es als persistenten KI-Teamkollegen, der über den Desktop- oder Mobil-Chat gestartet wird oder durch eine Erwähnung von @bot auf X, wenn die Konten verknüpft sind. Er läuft auf einem Cloud-Rechner auf Kontoebene, der von Cursor gehostet wird, und hat Zugriff auf Browser, Speicher und Befehlszeile. Die Dokumentation beschreibt fertige Dateien und Entwürfe, aber keinen Repository-Workflow; das Erstellen von Branches und PRs ist nicht dokumentiert. Damit liegt das Produkt am Bot-Ende des Spektrums.

Vier Unterschiede sind wichtiger als die Tabelle:

Wo der Auslöser angesiedelt ist. GitHub Copilot cloud agent und OpenAI Codex Cloud sind auf Arbeit ausgelegt, die bereits in GitHub oder der ChatGPT-App angesiedelt ist. Cursor Cloud Agents und Devin setzen stärker auf Chats: Ein Thread in Slack oder Teams ist der Einstiegspunkt. Claude Code cloud sessions können über einen Browser, ein Smartphone, die Desktop-App oder claude --cloud im Terminal gestartet werden und lassen sich auch nach Zeitplan ausführen.

Wie viel der Anbieter offenlegt. Claude Code dokumentiert die Isolation ausführlich: In von Anthropic gehosteten Umgebungen läuft jede Sitzung in einer isolierten VM, der Netzwerkzugriff ist standardmäßig eingeschränkt und Git-Anmeldedaten bleiben außerhalb der Sandbox; ein Proxy authentifiziert sich stellvertretend für die Sitzung. Organisationen können Sitzungen stattdessen an eine selbst gehostete Umgebung weiterleiten, für deren Isolation sie dann selbst verantwortlich sind. Cloud-Sitzungen teilen sich die Rate-Limits des jeweiligen Tarifs; zusätzliche VM-Kosten fallen nicht an. Erforderlich ist eine Anmeldung bei claude.ai. Nicht verfügbar sind die Sitzungen, wenn Claude Code für Amazon Bedrock, die Agent Platform von Google Cloud oder einen anderen Drittanbieter konfiguriert ist. Die übrigen Anbieter veröffentlichen weniger über die internen Abläufe; „Sandbox“ oder „VM“ bildet oft schon das Ende der öffentlichen Beschreibung.

Worauf der Agent zugreifen darf. Manche Produkte sind auf ein einzelnes Repository beschränkt; andere werben mit organisationsweiter Arbeit oder der Unterstützung mehrerer Repositories. Das sollte man als Erstes mit der eigenen Einrichtung abgleichen: Ein leistungsfähiger Agent mit dem falschen Repository-Umfang ist entweder nutzlos oder gefährlich.

Für welche Art von Arbeit es gedacht ist. Die meisten Produkte auf dieser Liste sind für Coding-Arbeit in einem Repository gedacht. Grok Bot ist ein allgemeiner Cloud-Teamkollege: In der Dokumentation geht es um Dateien und Entwürfe, nicht um einen Repository-Workflow. „Cloud-Agent“ bezeichnet ein Spektrum, keine einheitliche Produktform.

Wie der Ablauf tatsächlich funktioniert

Ohne das Branding ist der Ablauf überall ähnlich:

1. Aufnahme. Ein Auslöser trifft ein. Das Produkt entscheidet, ob es sich um eine echte Aufgabe handelt, stellt manchmal eine Rückfrage und reiht eine Sitzung in die Warteschlange ein.
2. Umgebung. Der Agent klont das Repository mit dem richtigen Branch, führt ein Einrichtungsskript oder ein Image aus und installiert die Toolchain. Netzwerkzugriff und Secrets werden hier konfiguriert, nicht später.
3. Arbeit. Der Agent liest Code, bearbeitet Dateien, führt Tests und Befehle aus und öffnet gelegentlich einen Browser. Auch wenn der Laptop in den Ruhemodus wechselt, laufen längere Aufgaben weiter.
4. Ergebnis. Der Agent pusht einen Branch und erstellt einen PR oder hinterlässt ein Diff mit einer schriftlichen Zusammenfassung. Manche Produkte liefern PR-Entwürfe, weil der Agent vor dem Merge aufhören soll.
5. Prüfung. Eine Person liest das Diff, kommentiert und führt den Merge durch, bittet um Änderungen oder übernimmt die Arbeit wieder in einer lokalen Sitzung. Manche Produkte können den PR auch beobachten und bei fehlgeschlagener CI Korrekturen pushen.

Die entscheidenden Unterschiede liegen in Schritt 2 und 5. Ein zu lange dauerndes Einrichtungsskript, ein Repository, das der Agent nicht klonen kann, eine Netzwerkrichtlinie, die eine Paketregistrierung blockiert, oder Anmeldedaten, auf die die Sandbox nicht zugreifen kann – all das kann eine scheinbar einfache Aufgabe zum Stillstand bringen. Und „überprüfbares Ergebnis“ bedeutet weiterhin, dass ein Mensch es überprüft: Keines dieser Produkte macht den Prüfschritt überflüssig; sie verlagern lediglich das Tippen.

Warum diese Welle gerade jetzt kommt

Drei Bedingungen mussten zusammenkommen. Modelle wurden zuverlässig genug, um lange Tool-Schleifen ohne ständige Aufsicht auszuführen. Sandboxes und Einrichtungsskripte wurden günstig genug, um jeder Aufgabe eine eigene Umgebung zu geben. Und der Pull Request wurde zur Standardschnittstelle zwischen Agent und Prüfer, sodass Teams keinen neuen Prüfprozess erfinden mussten.

Auch die Aufmerksamkeit spielt eine Rolle. DeepSeeks begleitender Design-Essay formuliert es ausdrücklich: Eine einzelne Aufgabe wird durch das Modell begrenzt, aber der Durchsatz einer Person bei vielen Aufgaben durch ihre Aufmerksamkeit. Ein Cloud-Agent nimmt der Person Sitzungsverwaltung, Kontextwechsel und Wartezeiten ab. Diese Aussage stammt aus DeepSeeks Essay und nicht aus einer unabhängigen Studie, beschreibt aber, warum diese Kategorie nützlich erscheint.

Worauf man verzichtet

Jedes gehostete Produkt tauscht Kontrolle gegen Komfort:

• Vertrauensgrenze. Dein Code und manchmal auch deine Anmeldedaten verlassen deinen Rechner. Anbieter veröffentlichen unterschiedlich viele Details zu Isolation, Aufbewahrung und Netzwerkzugriff. Lies die Angaben für jedes Produkt einzeln, statt anzunehmen, dass die ganze Kategorie einheitlich ist.
• Isolation. Eine verwaltete VM soll den Agenten abschirmen, bleibt aber trotzdem die Umgebung des Anbieters. „Sandbox“ kann alles bedeuten – von einer gehärteten VM bis zu einem Container mit weitreichendem Netzwerkzugriff.
• Anpassbarkeit. Gehostete Agenten bieten Einstellungen, keinen Quellcode. Wenn dein Workflow einen anderen Auslöser, eine andere Prüfregel oder ein anderes Modell erfordert, bist du auf das beschränkt, was das Produkt anbietet.
• Kostenmodell. Die meisten dieser Produkte werden über ein Abonnement oder einen Tarif mit Nutzungslimits abgerechnet; die Laufzeit des Agenten ist keine Position, die du direkt steuern kannst. Plane nach Tarif, nicht nach Token.
• Umfang und Bindung an einen Anbieter. Unterstützung mehrerer Repositories, Chat-Integrationen und Enterprise-Steuerelemente unterscheiden sich je nach Anbieter. Einen Workflow von einem Produkt zu einem anderen zu verlagern, ist nicht kostenlos.

Der selbst gehostete Weg: DeepSeeks Super-agent

DeepSeeks Veröffentlichung ist interessant, weil sie der Frage nachgeht, wie derselbe Ablauf aussieht, wenn die Kontrollebene bei dir bleibt. Das Repository enthält ein TypeScript-Plugin für DeepSeek Harness (DSH) unter MIT-Lizenz, Version 0.1.0, veröffentlicht als Forschungsprototyp. Die README stellt klar: Das Plugin wurde für die Veröffentlichung angepasst, ist nicht mit der internen Version von DeepSeek identisch und setzt nicht alle Ideen aus dem Design-Essay um.

Der Aufbau besteht aus einer langlebigen Router-Sitzung und einer Worker-Sitzung pro Ticket. Ereignisse durchlaufen die Kette Source → Trigger → Thread → Eval → Mandate → Ticket → Assignment → Executor. Ein Team autorisiert die Arbeit über eine Richtlinie; explizite @Erwähnungen durch zugelassene Personen werden akzeptiert, während proaktive Arbeit im Modus observe beginnt. Dieser zeichnet auf, was der Agent getan hätte, ohne Tickets zu eröffnen. Jedes Ticket erhält eine eigene Sitzung und ein eigenes Verzeichnis; ein Vorbereitungsbefehl kann für jedes Ticket einen Git-Worktree erstellen.

Das Betriebsmodell ist das Gegenteil einer Anbieter-Sandbox. Das System überwacht ein einzelnes github.com-Repository (kein GitHub Enterprise Server) und optional Feishu. Sowohl die Router- als auch die Worker-Voreinstellungen laufen mit danger-full-access als Betriebssystembenutzer des Betreibers; Konten-Wrapper wählen die Anmeldedaten des Agenten aus, isolieren aber den Prozess nicht. Der Deployment-Leitfaden empfiehlt ein eigenes Betriebssystemkonto, das ausschließlich die Anmeldedaten des Agenten enthält. Der Zustand wird in SQLite unter einem konfigurierten stateDir gespeichert. Die Philosophie lässt sich als Zielvorgabe zusammenfassen: so wenig menschliche Aufmerksamkeit wie möglich beanspruchen und so viel Mehrwert wie möglich liefern.

Der Essay nennt Kennzahlen zur Zeitplanung für eine synthetische Arbeitslast – etwa 300 Nachrichten und 20 Arbeitsaufträge, simulierte Tools, fünf Durchläufe – mit einem p50/p95 von etwa 12.4 / 15.7 Minuten gegenüber rund 29.5 Minuten p95 für eine Baseline mit einer einzelnen Sitzung, die keine Subagent-Aufrufe machte. Das sind eigene Messwerte des Essays unter Verwendung simulierter Tools, kein unabhängiger Benchmark zur Codequalität.

Der Prototyp demonstriert etwas Engeres und Nützlicheres als einen Produktstart: Der ereignisgesteuerte Coding-Agent, dessen Ergebnisse erst am Ende geprüft werden, ist nicht an die Cloud eines Anbieters gebunden. Sie können den Orchestrator, den Zustand und die Modellwahl selbst bestimmen. Zugleich zeigt der Prototyp auch, was diese Kontrolle kostet: Sie betreiben den Prozess, sichern das Konto ab und akzeptieren, dass standardmäßig keine Sandbox vorhanden ist.

Wer sollte was wählen?

Bleiben Sie bei einem gehosteten Cloud-Agenten, wenn Sie keinen Betriebsaufwand, eine vom Anbieter verwaltete Sandbox, Funktionen für mehrere Repositories oder Organisationen und einen Auslöser in GitHub, Slack, Teams oder einer Web-App möchten. Der Anbieter kümmert sich um Isolation und Verfügbarkeit.

Ziehen Sie den selbst gehosteten Prototyp in Betracht, wenn Ihr Code Ihre Infrastruktur nicht verlassen darf, Sie die Orchestrierung anpassen müssen oder für jede Rolle ein eigenes Modell wählen möchten. Planen Sie einen dedizierten Rechner oder ein dediziertes Betriebssystemkonto ein und betrachten Sie den Code als Forschungssoftware.

Ein praktischer Kompromiss: Gehostete Agenten für routinemäßige Repository-Aufgaben und ein selbst gehosteter Agent nur für Repositories, bei denen die Datengrenze entscheidend ist. Der Prüfschritt ist in beiden Fällen derselbe.

Hinweis zu Modellen

Der Prototyp ist nicht auf ein bestimmtes Modell festgelegt. Er verwendet standardmäßig das Harness-Profil, sofern Eval oder Execution keine abweichende Vorgabe machen. So kann ein Team ein leichteres Modell für den Router und ein leistungsfähigeres für die Worker einsetzen. AIHubMix verbindet DeepSeek Harness über einen OpenAI-kompatiblen Endpunkt unter https://aihubmix.com/v1; das Beispiel im Leitfaden zu DeepSeek Harness verwendet den Anbieter aihubmix und das Modell auto. Der Leitfaden behandelt die grundlegende Verbindung zu DSH, nicht das Super-agent-Plugin; die oben genannten gehosteten Produkte verwalten ihre Modellauswahl selbst.

FAQ

Was ist ein Cloud-Coding-Agent?
Eine Software, die eine Coding-Aufgabe aus einem Issue, einer Erwähnung im Chat oder einem API-Aufruf entgegennimmt, sie in einer Umgebung außerhalb Ihres Rechners ausführt und einen Branch, Diff oder Pull Request zur Prüfung zurückgibt.

Ist das dasselbe wie ein lokaler Coding-Agent?
Nein. Ein lokaler Agent läuft in Ihrem Terminal oder Ihrer IDE, während Sie zusehen. Ein Cloud-Agent arbeitet weiter, nachdem Sie den Laptop geschlossen haben, und ist dafür gedacht, später geprüft zu werden.

Muss man den Code trotzdem prüfen?
Ja. Jedes hier vorgestellte Produkt liefert am Ende einen Diff oder PR, den ein Mensch prüfen muss. Der Agent übernimmt das Tippen, nicht die Freigabe.

Wo wird Ihr Code ausgeführt?
In der Umgebung des Anbieters. Die Details unterscheiden sich: Copilot nennt eine Cloud-Sandbox oder eine Actions-Umgebung, Cursor isolierte VMs, Codex einen Cloud-Arbeitsbereich, Claude Code eine isolierte, von Anthropic verwaltete VM oder eine selbst gehostete Umgebung einer Organisation und Devin einen Arbeitsbereich mit Terminal, Editor und Browser. Lesen Sie die Sicherheitsdokumentation der jeweiligen Anbieter, bevor Sie ihnen privaten Code anvertrauen.

Was ist ein Coding-Bot?
Die chatbasierte Variante derselben Idee: Statt ein Issue zuzuweisen, erwähnen Sie den Agenten in Slack, Teams oder Feishu. Er arbeitet weiterhin in einer Remote-Umgebung. Das Ergebnis kann ein PR oder Diff sein oder – bei einem allgemeinen Teammitglied wie Grok Bot – fertige Dateien und Entwürfe.

Was bietet DeepSeeks Super-agent zusätzlich?
Eine selbst gehostete, MIT-lizenzierte Implementierung desselben Ablaufs mit einem Router-Worker-Design, einem Richtlinien- und Ticketmodell sowie optionaler Feishu-Integration. Es handelt sich um einen Forschungsprototyp, nicht um ein gehostetes Produkt.

Ist es produktionsreif?
Nein. Die README bezeichnet den Code als Forschungssoftware, die Voreinstellungen laufen mit danger-full-access und standardmäßig gibt es keine Sandbox. Verwenden Sie bei einem Test ein dediziertes Betriebssystemkonto und ein dediziertes GitHub-Konto für den Agenten.

Quellen

1. deepseek-ai/dsh-superagent-prototype — README, der darin zitierte Design-Essay und docs/000–008
2. DeepSeek Harness mit AIHubMix verbinden — AIHubMix
3. GitHub Copilot Cloud-Agent — GitHub Docs
4. Cursor Cloud Agents — Cursor Docs
5. Codex Cloud — ChatGPT Learn / OpenAI
6. Claude Code in der Cloud — Anthropic
7. Devin-Dokumentation — Cognition
8. Grok-Bot-Dokumentation — xAI