Super-agent-Design erkunden: hin zu einem autonomen Agent-System

1. Super-agent

Im vergangenen Jahr haben Einzeltask-Agenten — allen voran Coding-Agents — bewiesen, dass Modelle mit Werkzeugen komplexe Probleme lösen können, mit immer weniger permanenter Überwachung und schrittweiser Intervention. Zugleich wächst die Fähigkeit zur Koordination mehrerer Agenten; Organisation und Dispatch über Sitzungen hinweg werden machbar. Mit sinkender menschlicher Beteiligung an der Ausführung wandert die menschliche Rolle nach oben zu Entscheidungen und Abnahme.

Dieser Fähigkeitsschub erzeugte neue Anwendungsformen: Personal Agents schießen zuletzt aus dem Boden — direkt an Messaging, Kalender, E-Mail und Arbeitsplattformen angeschlossen, beobachten sie laufend den Informationsfluss und helfen. Dieser Dauer-Online-, event-getriebene Arbeitsmodus ist keine Privatangelegenheit — der persönliche Assistent ist nur eine Anwendungsklasse; in kommerziellen Szenarien wie der Softwareentwicklung ist er ebenso wertvoll.

Die gängigen Agent-Designs tragen diesen Modus aber nicht auf Multitask- und Teamskala. Agent-Arbeit ist noch um die Einzelsession organisiert; Sessions sind unabhängig. Wer Parallelarbeit schiebt, switcht von Hand und merkt sich die Kontexte — und beobachtet das Team: Eine Person verfolgt realistisch 3 bis 5 aktive Sessions. In diesem Design liegt die Einzeltask-Grenze beim Modell, die Multitask-Grenze beim menschlichen Blick.

Einen lokalen Einzelsession-Agenten per CLI, MCP oder Konnektoren zu erweitern lässt ihn Nachrichten empfangen, bleibt aber am synchronen Blockieren, am Kontext-Gemisch und am Tod mit dem Offline-Gerät — mit viel Handpflege.

Der Ausweg: die Bindung des Agenten an die einzelne manuelle Session lösen — zu einer kontinuierlichen Entität machen, die Kontext über Sessions hält und mehrere komplexe Tasks störungsfrei parallel treibt. Das Team nennt diese Form und Architektur Super-agent.

In der internen Instanz auf DeepSeek Harness wandert eine Entwicklungsaufgabe kontinuierlich zwischen IM und GitHub; die Instanz beobachtet öffentliche Gruppen, findet ohne Erwähnung die Ursache und reicht einen Fix-Pull-Request.

Konkret vier Grundeigenschaften:

• Kontinuierlich: Der Nutzer interagiert in gewohnten Oberflächen — IM, GitHub-Kommentare — und spürt stets denselben Agenten; kein „Stand Y in Session X?". Plan A im Chat, Plan B im PR-Kommentar — der Agent versteht und dreht mit.
• Effizient: Reaktionsschnelle Interaktion, während mehrere komplexe Tasks parallel und qualitativ laufen; der nächste Befehl wartet nicht auf den vorigen.
• Proaktiv: kein Warten auf Befehl um Befehl; der Agent beobachtet Umgebungsereignisse, treibt Vorwürdiges voran und schweigt, wenn kein Eingriff nötig ist.
• Persistent: immer online, in echten Arbeitsumgebungen eingehängt, mit Selbstheilung bei Anomalien im Dauerbetrieb.

Ein einzelner ReAct-Loop trägt die vier nicht zugleich; darunter braucht es Architektur. Ähnliche Zwänge führen zu ähnlichen Entwürfen — ob persönlicher Assistent oder kommerzieller Entwicklungsagent, ein dauerhaftes, nebenläufiges System wird unten ähnlich gebaut. Und viele Probleme hier ähneln klassischen Systemproblemen so sehr, dass klassisches Systemdenken direkt greift.

Der Baukasten hat Varianten, doch fünf Module tragen die vier Eigenschaften: die Zweiebenenarchitektur (Abs. 2) für Kontinuität und Effizienz, Event-Driven (Abs. 3) für Proaktivität, menschengerichtete Interaktion (Abs. 4) für beides an der Oberfläche, die Trennung von Compute, Staat und Umgebung (Abs. 5) plus Watchdog (Abs. 6) für geräteübergreifende Persistenz und Selbstheilung.

2. Die Zweiebenenarchitektur

Für kanalübergreifend kontinuierliche Interaktion und effiziente Nebenläufigkeit zugleich steht die Session-Organisation vor einem Grundkonflikt: Kontinuität gegen Durchsatz.

Alles in eine Session: maximaler Kontext, aber die serielle ReAct-Geschwindigkeit deckelt — lange Zeiten, niedriger Durchsatz, und die vermengten Zwischendetails mehrerer Tasks drücken die Qualität.

Für jedes Ereignis eine eigene Session: maximaler Durchsatz, aber ohne Globalkontext zerfasern die Ergebnisse, und mehrere Sessions, die je dem Nutzer antworten, stiften Chaos.

Also splittern wir „globale Kontinuität wahren" und „hochnebenläufig ausführen": eine residente Router-Ebene (2.1) für alle Menscheninteraktion und globale Koordination; eine kontextisolierte Worker-Ebene (2.2) für die parallele Ausführung.

So übernimmt das System unten Kontextverwaltung und Nebenläufigkeit und blendet die Session beim Nutzer aus — vor ihm steht immer ein Super-agent. So gesehen ist manuelle Session-Pflege zum großen Teil API-Erbe; Session ist Implementierungsdetail, kein Denklast.

„Zwei Ebenen" ist eine logische Rollenaufteilung; keine Ebene muss eine Einzelsession sein, beide dürfen interne Struktur haben. Nun die Ebenen.

2.1 Die Router-Ebene

Der Router ist die residente, global Routing-Ebene und fängt alle Menscheninteraktion an allen Eingängen ab. Alle taskübergreifenden Informationen und Entscheidungen konvergieren hier — Sequenzpunkt, Koordinationspunkt und Gedächtnis. Damit der Knoten nicht zum Flaschenhals wird, führt der Router keine Tasks aus — nur Interaktion und Dispatch; ein Bash-Werkzeug darf fehlen.

Zentraler Disponent über Ausführern ähnelt oberflächlich dem Agent Team — der Fokus differiert. Teams zerlegen Schritte innerhalb eines komplexen Task; die Teilschritte hängen eng, der Lead muss Details kennen, planen, dauernd koordinieren — schwere Denklast. Der Super-agent-Router fasst nur hochrangige Taskverbindungen und Dispatch. Umgekehrt: einer Agent-Team-Hauptsession per Prompt zu verbieten, selbst auszuführen — nur außen und verteilen —, macht sie zu dieser Architektur. In der Praxis sind Routeraufgaben oft leichter als gedacht; ein kleineres Modell genügt meist.

Auch intern muss der Router keine Einzelsession sein; Teile der Logik rufen womöglich gar kein LLM. Das Team wählte den direktesten Kern — eine residente LLM-Session — und fand sie weit weniger bottleneck-anfällig als gedacht: Ereignisse der letzten Inferenzrunde (die Trigger aus Abs. 3) stauen sich und werden in der nächsten Runde gemeinsam abgearbeitet — Batching —, dessen Zusatzaufwand klein ist:

• Bei ruhigem Strom trudeln Trigger einzeln ein; die Latenz bleibt niedrig.
• Drängen Ereignisse und staut sich die Session, verschmelzen die gestauten Trigger automatisch und fließen gemeinsam in den nächsten LLM-Aufruf. Router-Schritte: langer Input, kurzer Output; gebündelte Trigger parallelisieren das Prefill, die Latenz wächst weit langsamer als der Batch. In Bereichen gilt: je Stau, desto weniger Inferenzzeit pro Entscheidung — nach oben begrenzt durch Kontextlänge und die Triggerzahl, die das Modell pro Runde sauber schafft.

Abs. 7.2 quantifiziert das. Mit Abo-Pass-through und Chain of Recall (3.2, 3.3) genügt die einzelne residente Router-Session bei heutiger Teamgröße.

Bei weiterem Wachstum kann der Router intern mehrstufig filtern oder sich horizontal sharden. Dann ist Router-Design selbst Kontinuität gegen Durchsatz: feinere Shards, mehr Nebenläufigkeit, weniger zusammenhängendes Gedächtnis. Bis Globalgedächtnis gelöst ist, bleibt der Konflikt.

2.2 Die Worker-Ebene

Worker sind die Ausführungssessions: gegenseitig kontextisoliert, voll bestückt, je auf einen Task konzentriert. Da sie Ergebnis und Codequalität direkt bestimmen, gehört das stärkste Modell hierher.

Worker reden nicht mit Menschen; Reasoning und Tool-Aufrufe laufen nicht auf äußere Kanäle. Sie melden dem Router; der antwortet dem Nutzer — Nebenläufigkeit und Qualität ohne Antwort-Chaos.

Im Multitask laufen Worker unabhängig und brauchen meist keine direkte Kommunikation. Konflikte entstehen meist in geteilten Umgebungen wie demselben PR; abonnierten beide den Thread (3.2), bekommen sie dieselben Ereignisse und können Konflikte selbst lösen; das seltene Taskübergreifende vermittelt der Router.

Wie der Router darf ein Worker intern vielfältig sein: Subagenten zeugen oder selbst Team sein — transparent nach oben. Passt für Code-Kollaboration — Reproduktionen, Reviews, Features parallel ohne Blockade — wie für den persönlichen Assistenten: ein Chatfenster vorne, darunter ein Worker pro Thema, parallel arbeitend und entwerfend.

3. Event-getrieben

Proaktivität beginnt mit dem Antrieb: Nicht menschliche Sitzungsprompts, sondern halbstrukturierte Umwelt-Ereignisse treiben den Agenten. Gruppenchat, Mail- und Kalender-Hinweise, Review-Kommentare, CI-Läufe — all das heißt Trigger. Auf Trigger hörend, wartet der Agent nicht mehr auf Einzelaufträge.

Entlang des Trigger-Lebenslaufs vier Fragen: Rauschen mit zweistufiger Programm-Modell-Politik filtern (3.1); per Abonnement und Pass-through an Worker routen (3.2); Kontext dicht injizieren und nach Bedarf zurückholen mit Inline & Spill und Chain of Recall (3.3); spekulativ vorab handeln (3.4).

3.1 Ereignisfilterung

An echten Chats und Codeplattformen ist der Strom ausgesprochen „hohes Rauschen, niedrige Triggerrate": Die meisten Nachrichten brauchen keinen Agenten. Alles mit Modellfrischaufruf zu entscheiden, ruinier Latenz und Rechenkosten. Nach dem Fast-Path-/Slow-Path-Gedanken ist LLM-Inferenz der teure, flexible Slow Path; klare, stabile Hochfrequenzurteile in deterministischen Code gegossen bilden den billigen Fast Path.

Schritt eins nach Eintritt: filtern — vor jedem Modellaufruf mit deterministischer Politik das Rauschen sieben, nur Semantik-Kandidaten dem Modell überlassen. Zweistufig:

• Programmebene (Fast Path): deterministische Einlassprüfung in Code — Quelle, Gruppenumfang, User-/Bot-Whitelists; je Quelle „nur explizite Anfragen", „Kandidat" oder „ignorieren" — das Meiste fällt vor dem Modell.
• Semantikebene (Slow Path): die Kandidaten geht ans LLM, das anhand prompt-geschriebener Politik und Kontext über Handeln entscheidet. Die Semantikebene ist zugleich der natürlichsprachige Erweiterungspunkt: Politik an/aus/neu ist eine Prompt-Änderung.

3.2 Ereignisrouting

Der Router hält kanalübergreifende Kontinuität — aber müsste jedes Folgeereignis zugewiesener Tasks noch durch ihn, trüge der Knoten schwer und die Latenz stiege. Also gilt Fast/Slow auch hier: Der Router macht nur Kaltstarts neuer Tasks und taskübergreifende Koordination; Folgeereignisse mit bekannter Zuständigkeit schickt der Code direkt an die Workersession.

Im echten Workflow bilden die Ereignisse unter einem PR, einem IM-Thema, einem Mailthread einen Strom — einen Thread. Hat der Router für das Anfangsereignis eine Workersession geschaffen, abonniert der Worker den Thread direkt; zwei Pfade entstehen:

• Abonniert (Fast Path): Folgereignisse desselben Thread laufen direkt zum abonnierten Worker — ohne Router-Weiterleitung. Spielt ein Ereignis aus dem Taskrahmen, darf der Worker abbestellen oder zurückgeben.
• Nicht abonniert (Slow Path): der Router sieht weiter alles fürs Gesamtbild, richtet aber nur noch Unabonniertes.

Abo ist viele-zu-viele: ein Worker abonniert mehrere verwandte Thread; ein Thread hat mehrere Worker-Abonnenten. Kreuzen sich Worker in einer Umgebung, bekommen alle Abonnenten dasselbe Ereignis und können einander ohne Punktnachrichten sehen und Konflikte lösen. Nach außen melden die Worker die Schlüsse dem Router, der einheitlich antwortet und das Globalgedächtnis pflegt.

3.3 Kontextorganisation

Gefiltert und geroutet, bleibt: wie viel ins Kontextfenster? Der Input kam von begrenzten Menschenprompts zu endlosen halbstrukturierten Ereignissen — Injection- und Tool-Design wiegt schwerer. Zu viel stopft und verdünnt; zu wenig erzwingt Lese-Roundtrips. Verschenktes Fenster ist verschenkte Modellintelligenz.

Das endliche Fenster als Cache verwalten — mit Compiler- und Systembegriffen genügen zwei Operationen: Inline trägt Baldiges direkt ins Fenster und spart Tool-Roundtrips; Spill hält Budget-Überschreitendes und Seltenes vor dem Fenster, drin bleiben Verweis oder Digest zum Bedarfslesen.

Mit klassischer Lokalität:

1. Minimal beginnen: nur ID und Digest.
2. Lokal inlinen: erst IDs eng verwandter Objekte, dann raumzeitlich Benachbartes — die ersten 50 Zeichen, Nachbar- und Beantwortet-Nachrichten, Nachbar-Kommentare im Review.
3. Über Limit spillen: kleine Längenoberkante für nicht Inlinbares; Überhang raus, mit Lese-Anker fürs Nachholen per Tool.

Mit vielen direkt durchgereichten Ereignissen und lang wachsender Historie kann der Router unmöglich alles im Fenster tragen — muss aber Kontext wiederfinden, wenn der Nutzer kanalübergreifend eine alte Aufgabe anspricht. Inline & Spill durchgängig auf Systemobjekte angewandt ergibt das nach Bedarf expandierende Mehrhop-Rückholverfahren — die Chain of Recall —, die das Fern-Schwundproblem des Routers mildert.

Konkret: Trigger, Thread und Workersessions bekommen eindeutige IDs; Injection inline-t die eng verwandten IDs — unten entsteht ein Referenzgraph. Da auch jedes per Tool zurückgeholte Objekt Inline & Spill folgt, trägt sein Ergebnis Digest und ID des nächsten Hops: Von der aktuellen Nachricht zum Thread, von dort zur verknüpften Workersession, weiter zum anderen Review-Thread.

3.4 Vorab handeln

Nach der spekulativen Ausführung der Systeme darf der Agent probieren, bevor feststeht, ob das Resultat gebraucht wird — Hintergrundrechenkraft gegen menschliches Warten und Eingreifen. Wertvolles wird geliefert, Wertloses verworfen.

Assistenten-Szenario: Bei Einladung oder To-do prüft der Agent im Hintergrund Terminkonflikte, sammelt Material und entwirft die Antwort — der Nutzer blickt drauf und schickt. Engineering: In der internen DeepSeek-Harness-Usergruppe läuft die Politik „still reproduzieren und fixen" — meldet jemand ein Problem oder diskutiert eine Änderung, reproduziert und sucht der Agent im Hintergrund; erst bei bestätigtem Problem und einfachem Fix liefert er, sonst schweigt er durch.

4. Interaktion mit Menschen

Die Zweiebenen sichert Kontinuität auf Kontextebene; im Erlebten bleiben zwei Aufgaben: lange Hintergrundoperationen mit einem asynchronen ReAct-Loop entblocken (4.1) und die Ausgabe an Bandbreite und Gewohnheiten jedes Kanals anpassen (4.2).

4.1 Vollduplex

Im klassischen Loop blockiert der synchrone run() bis zur Rückkehr — die Session ist taub für Neues. Abhilfe: vom Halbduplex-Frage-Antwort in den Vollduplex.

Das Team stellte langlaufende Befehle und Subtasks auf asynchrone start()/stop() um — der asynchrone ReAct-Loop. start() kehrt sofort mit „Started" zurück; nach Abschluss wirft das System das Resultat als neues Ereignis in die Session; und der Modell kann Überlanges per stop() killen.

Vordergrunddialog und Hintergrundausführung entkoppeln: Der Agent antwortet, während lange Tasks laufen. Neueingaben werden direkt nach dem aktuellen Inferenzschritt behandelt — nie hinter wartendem Werkzeug. Implementiert in DeepSeek Harness, noch nicht default an.

4.2 Mehrkanal-Interaktion

Kanäle unterscheiden sich in Dichte und Brauch; die Ausgabe muss passen. Terminal-Einzelinteraktion unverändert in die Gruppe gekippt — endloses Reasoning, Tool-Spam — überlädt.

Die Zweiebenen isoliert das schon: Reasoning und Tool-Aufrufe bleiben in Workern; der Router allein redet nach außen. Darüber: Anbindung an echte Umgebungen plus kanalspezifische Norm per Prompt:

• IM-Kanäle: leicht, störfrei — wie ein Kollege, der nur bei Entscheidung und Abnahme pingt, direkt fragt, knapp antwortet. Bewährte Hartregel: max. 100 Wörter pro Antwort.
• GitHub, Mail, Dokumente (asynchron): strukturierte, dichte Lieferung — PRs nach Projektnorm mit Hintergrund, Änderungsbeschreibung, Verifikation; für den Assistenten entworfene Mails und Zusammenfassungen.

5. Trennung von Compute, Staat und Umgebung

Lokale Agenten binden Compute (der Loop), den persistenten Session-Staat und die Umgebung (Repos, Toolchains) an ein Gerät. Gerät schläft — Agent stoppt; andere Umgebungen bleiben fern. Für Dauerpräsenz und flexible Anbindung trennen wir in zwei Schritten: erst Compute vom Staat (5.1), dann den Cloud-Loop von der schweren Umgebung (5.2).

5.1 Compute und Staat

Loop-Compute darf staatenlos sein; persistieren muss der Session-Staat. Erste Trennung: Compute in staatenlose elastische Cloud-Container, Staat in die Datenbank. Container skalieren, starten neu, werden getauscht; Beständigkeit garantiert der Speicher — der Agent entkommt dem Geräteleben.

5.2 Compute und Umgebung

Loop und Staat in der Wolke — nun der Zugriff auf Umgebungen. Viel Modellkontext kommt per Tool aus Repos, lokalen Dateien, Abhängigkeitsdiensten; im weiten Sinn ist die Umgebung selbst Kontext.

Zwei übliche Wege: Cloud-Sandbox, Code ziehen, Umgebung nachbauen — teuer und verlustreich, denn echte Umgebungen tragen uncommittete Änderungen, private Credentials, Intranet-Abhängigkeiten, Hardware und Toolchains; oder den Nutzer in die Cloud zwingen — für viele unerschwinglich.

Was sich nicht kopieren lässt, ist die Umgebung — also nicht hochziehen. Zweite Trennung: der Loop läuft in der Wolke, die schwere Umgebung bleibt, wo sie ist; vorn nur ein leichter, staatenloser Daemon, der Befehle ausführt und Ergebnisse zurückgibt.

Das deckt sich mit Anthropics „Gehirn von den Händen trennen": staatenloser Harness, Session-Logs außen, Umgebungen über eine Schnittstelle. Der Unterschied: Dort Managed Services, On-Demand-Sandboxen, Kunden-VPC; hier zunächst die täglichen, vielleicht intermittierend online privaten Maschinen mit uncommitteten Änderungen. Daher BYOM (Bring Your Own Machine) nebst verwalteten Maschinen und On-Demand-Compute.

Der Agent ist nicht mehr ans eine Gerät gebunden: Er wechselt pro Task, führt aus, wo nötig, und holt Kontext dort. Sogar intermittierende Geräte: Kommt die private Maschine zurück, zündet der Cloud-Agent und erledigt, was dort anstand.

6. Watchdog

Persistenz braucht mehr als Trennung: Dauerläufer müssen aus Anomalien selbst heilen. Ein verteiltes Dauerlife-System hält allein aus interner Logik schwerlich langfristig — daher muss eine unabhängige äußere Kontrollschleife, der Control Loop.

Und bei Agenten reichen Prozesssonden und Skripte nicht: Viele Anomalien sind keine Crashes, sondern nutzlose Loops oder Zielabweichung des Modells. Dauerläufer überwachen Infrastruktur-Leben und Task-Fortschritt.

Extern läuft eine unabhängige Watchdog-Session, getaktet von Zeitnachrichten. Sie behandelt Infra-Fehler — API-Fehler, misslungene State-Recovery — und lässt das Modell urteilen, ob Worker real fortschreiten und kurs halten; greift ein, repariert, prüft Flüchtigkeiten bis zur Genesung. Da der Watchdog selbst voll bestückte Agent-Session ist, kann man ihn fragen, warum etwas brachlag, oder ihn das Hauptsystem live umkonfigurieren lassen — Prompts rein, raus, Trigger-Regeln justieren.

7. Vorversuche

Zur Bewertung der Kern-Scheduling- und Routingideen zwei Schichten: End-to-End-Vergleich von Zweiebenen/Abo-Pass-through gegen Einzelsession (7.1); separater Stresstest des Router-Batchings (7.2). Synthetische Last, vereinfachte Umgebung — Vorab-Referenz.

7.1 Ablation

Gruppenchat- und GitHub-CI-Ströme treiben vier Schemata: ~300 Nachrichten pro Lauf, ~20 Arbeitsanfragen, Rest Geplauder, Follow-ups, Abbrüche, CI. Codierarbeit ersetzt ein Tool, das nur Zeit frisst — gemessen wird Scheduling und Koordination, nicht Einzeltaskausführung. Fünf Läufe je Schema.

Die vier: Super-agent; ohne Pass-through; Einzelsession + Subagent-Tool unter zwei Prompts. Neutral: "Use a subagent for a piece of work when appropriate..." Delegate-first: "Every message of the chat reaches you, so work you run yourself keeps stopping for new messages. Prefer handing each piece of work to a subagent of its own, and do only small things yourself..."

Abschlusszeiten: p50/p95 des Super-agent bei 12,4/15,7 Minuten, klar vor der Subagent-Einzelsession. Die Einzelsession ist prompt-anfällig: Die Hauptsession führt oft selbst — lang, instabil. Neutral: kein einziger Subagent-Aufruf in 5 Läufen; alles in der Hauptsession, ständig unterbrochen, p95 bei 29,5 Minuten. Delegate-first: 4 von 5 delegiert — schneller, doch unter dem Super-agent; im fünften hielt sie die Arbeit für „klein", machte selbst — der lila Rattenschwanz. Statt Arbeitsteilung dem Promptengineering zu überlassen, regelt die Zweiebenen strukturell: Router führt nie, Worker sehen nur ihre Thread-Nachrichten.

Kosten: Mehrere Sessions machen die Cache-Read-Tokens pro Lauf höher als Einzelsession — mehr Token für kürzere, stabilere Zeiten. Ohne Pass-through blieben die Zeiten quasi gleich, aber Routerentscheidungen stiegen ~30 % und Cache-Read-Tokens von 23,23 Mio. auf 31,77 Mio. (+37 %). Pass-through hebt Qualität noch Tempo — er spart Router-Sessions echte Token und Inferenz.

7.2 Router-Batching

Für Decke und Batching der residenten Router-Session ein separater Stresstest: echtes Modell im Router, Mock-Worker; die Ankunftsrate entscheidungsbedürftiger Trigger von ~1 auf ~40 pro Minute, beobachtet Batchgröße, Latenz pro Aufruf, Inferenz pro Entscheidung.

Von ~1 auf ~40/min wuchs der Batch im Schnitt 1,0→2,8, während die Latenz nur 2,5s→3,9s stieg — langsamer als der Batch —, und die Inferenz pro Entscheidung sank von 6,4s auf 1,6s. Bei Event-Fluten hebt der Router die effektive Durchsatzrate durch automatisches Verschmelzen. Das erklärt auch 7.1: Ohne Pass-through und mit höherer Router-Spitze wurde die Einzelsession-Decke nie berührt — also kein voreiliges Sharding, das die Globalkontinuität opfert.

8. Offene Fragen

Abs. 2–6 bilden die Basisarchitektur; Abs. 7 validierte Kern-Scheduling unter Last. Das System bleibt so schlicht wegen gezielter Vereinfachungen. Darüber hinaus offen: Skalierung der Ebenen (8.1), Zusammenarbeit nach der Session (8.2), Kontextgrenzen und A2A (8.3), Sicherheit und Privacy (8.4).

8.1 Die Ebenen skalieren

„Ein residenter Router + Pass-through + keine Worker-Direktkommunikation" deckt mit kleinem Aufwand den Alltag. Über die Schwelle gibt es kein festes Innenleben: wann sharden, wie fein; wann Worker direkt reden lassen, in welcher Topologie. Co-Design von System und Modell ist eine Richtung — Training für Ereigniserkennung, Batch-Dispatch und Kontextabruf könnte Router-Throughput und Urteilsqualität heben.

Und: Residenter Router plus referenzgraphische Chain of Recall löst das Abrufen des Nahen. Über Monate hinaus wird Langzeitgedächtnis zum Skalierungs-Engpass.

8.2 Zusammenarbeit jenseits der Session

Mit verstecktem Session-Management verlor die Session ihren Primat als Produktfrage; doch wenn Ausführungssessions nicht mehr Gesprächen entsprechen, wird Präsentation und natürliches Management die neue Frage. Chat-Zentriertheit ist teils Pfadabhängigkeit. Interaktion kann in domänenspezifische Oberflächen wandern — wie im Text: der Super-agent, direkt in Issues und PRs arbeitend. Sessions dürfen aus Gewohnheit bleiben, doch ein sichtbares Gespräch ist unten nicht mehr zwingend eine Session.

Der Text behandelte den Menschen an Anfang und Abnahme; im Übergang brauchen viele Tasks Zwischenteilnahme — jederzeit einsteigen, übernehmen, live mit dem Hintergrund kooperieren: explorierenswert. Endform von Management und Interaktion wird vermutlich tief individualisiert; der offene Harness macht solche Anpassung leicht.

8.3 Kontextgrenzen und A2A

Bisher: eine Instanz, alles im einen Global-Kontext. Vom Einzelnen zum Unternehmen wird die Frage, wie viele Instanzen — und das ist das Zeichnen von Grenzen des Teilens und Isolierens: Wer teilt, teilt die Instanz; wer isoliert, kriegt die eigene.

Und mit mehreren isolierten Instanzen — persönliche Assistenten neben dem Team-Super-agent — wird die Grenzüberschreitung Agent-zu-Agent (A2A, ohne Protokollfixierung). Sicheres, verlässliches A2A zwischen Kontextfremden mit verschiedenen Rechten bleibt offen.

8.4 Sicherheit und Privacy

Event-Driven weitet den Treiberraum — und die Berührung mit Eingaben ohne Vertrauen. Ohne gute Antworten arbeitet der Super-agent nur in kleinem, vertrautem Rahmen.

Abs. 5 — Loop in der Wolke, leichte Daemons auf Geräten — setzt beiderseitiges Vertrauen voraus. Ein Cloud-Loop, der ständig äußere Events schluckt und an Geräten mit privatem Code, sensiblen Daten und lokalen Credentials hängt, trägt reale Risiken: Server-Kompromittierung oder Prompt-Injection im Loop bedrohen die Kontrolle über alle angeschlossenen Geräte.

Und selbst ohne Kompromittierung: Gelangen Credentials in den Modellkontext, droht Leakage im Normalbetrieb — Mechanismen müssen Credentials nutzbar machen, ohne dass der Agent sie je berührt. Für breite Anwendung gilt: Kontext aus vielfältigen Umgebungen zurückholen und diese Probleme zusammen lösen.

9. Schluss

Zurückschauend: keine neue Theorie — klassisches System-Engineering auf Agenten angewandt. Implementationen werden wandern; das Designdenken behält Referenzwert. Die interne Instanz auf diesen Ideen und DeepSeek Harness läuft und läuft — täglich bei Reproduktion und Fix, Review-Antworten und Harness-Iteration.

Wie eingangs: Sinkt der Je-Task-Eingriff, wandert der Produktivitätsengpass zur menschlichen Aufmerksamkeit. Zweiebenen, Event-Driven, asynchrone Mehrkanal-Interaktion, Compute-Trennung und der äußere Watchdog nehmen unten Session-Pflege und Kontextsynchronisierung ab — der Mensch steigt zu Entscheidungen und Abnahme.

So ist der Agent kein wartendes Fenster mehr, sondern ein durchgehend online autonomer Mitarbeiter in der digitalen Umwelt: dem Einzelnen ein geräteübergreifender Assistent, dem Team ein eingebetteter Träger konkreter Aufgaben. Mit gemeinsam reifender Fähigkeit und Architektur dürfte dieser autonomere Arbeitsmodus zur Norm der Mensch-Maschine-Kooperation werden.

Wie im Original: Teile des Designs leben in dsh-superagent-prototype; das Plugin ist ein Routenevaluierungs-Prototyp, kein offizielles DeepSeek-Produkt. Autor und Dank: Der Text wuchs aus der gemeinsamen Praxis des DeepSeek-Harness-Teams; Yujia Qiao realisierte System und Text, mit Review durch Huanqi Cao, Zui Chen, Xieting Chu, Tianyi Cui, Shiyuan Feng, Yudong Han, Kexin Liu, Shichun Liu, Gesi Luo, Yifan Shi, Tongrui Xiong, Hanxiang Xu, C.C. Yu, Ziya Zhang und F. Zhou.

Quellen

• DeepSeek 产品部 (offizielles WeChat) — das chinesische Original, 1. Nov. 2026
• deepseek-ai/dsh-superagent-prototype — der MIT-Prototyp (README, docs 000–008)
• Stationsintern: vollständige englische Übersetzung · chinesisches Original · dsh-superagent-Bericht