Tech Teardown 039 | dsh-superagent: von Agenten geschrieben

Hintergrund und Phänomene: 13.000 Sterne in 3 Tagen und eine Selbstreflektion bezüglich der Haftung

Am 31. Oktober 2026 startete die GitHub-Organisation deepseek-ai den Repository dsh-superagent-prototype. Drei Tage später, am Morgen des 3. November, lautete die Beschreibung: 13.000 Sterne, 1.348 Fork-Versionen, 79 Abonnenten, 0 offener Probleme. Im Autorenfeld stand „DeepSeek Harness Team“, unter MIT-Lizenz, Version 0.1.0.

Neben den Sterne gibt es in dem ersten Absatz des README eine weitere wichtige Aussage: Drei zentrale Sätze sollten direkt zitiert werden: „Research prototype for reference only, not an official DeepSeek product.“ Es handelt sich um ein Forschungsprototyp zur Referenz, nicht um ein offizielles Produkt von DeepSeek; „much of the engineering done by coding agents“ – vielen Teile der Ingenieurarbeit wurden von coding agents erledigt; „adapted for publication, so it is not identical to our internal version“ – es wurde für die Veröffentlichung angepasst und unterscheidet sich von der internen Version. Ein Repository, das in drei Tagen um 13.000 Sterne gewonnen hat, leugnet zunächst seine offizielle Identität – diese Kontrastierung ist der erste Untersuchungspunkt dieser Ausgabe: Es handelt sich um ein Forschungsprototyp, das von der DSH-Team öffentlich gezeigt wurde, mit der Beschränkung auf „Forschungsprototyp des Teams“, ohne weitergehende Angaben.

Es gibt eine deutliche Unterschiedlichkeit in der Verbreitung. Dieser Repository wurde mehrfach auf Hacker News eingereicht, wobei das beste Ergebnis nur 11 Punkte und 0 Kommentare waren, mit wenig Diskussionen; auf GitHub hingegen stieg die Anzahl der Sterne stark an, und die Popularität lag fast ausschließlich auf der trending-Seite. Der Hintergrund ist die DSH-Plattform selbst: Am 13. August erhielt die Developer Preview auf HN 747 Punkte und 314 Kommentare; am 2. Oktober erhielt Harness Desktop (macOS/Windows Client) 417 Punkte und 228 Kommentare. Die Plattform hat echte Community-Beachtung, und dsh-superagent ist das erste wichtige Bundle in ihrem Ökosystem – die Anzahl der Sterne zeigt die Aufmerksamkeit, die die Plattform erhält.

Was es ist, lässt sich mit einem Satz zusammenfassen: Ein ständig laufender coding agent, der für DSH zusammengestellt wurde und nur einen GitHub-Repository bedient. Er wartet auf GitHub, optional auch auf Lark; Personen, die autorisiert sind, senden ihm Aufträge, er erstellt eine Ticket-Anfrage, arbeitet in seiner eigenen Sitzung und im Verzeichnis, und antwortet anschließend auf die ursprüngliche Unterhaltung, zum Beispiel durch das Einreichen eines Pull Requests; Das Web-Panel zeigt nur „Dinge, die bearbeitet werden müssen“. Es gibt auch einen Artikel mit dem Titel „Exploring Super-agent Design: Towards a More Autonomous Agent System“, in dem im README besonders darauf hingewiesen wird, dass die diskutierten Designelemente zukünftige Richtungen sind und das Prototyp nicht implementiert wurde.

Architektur und Technologieprinzipien: Eine einzige Autorisierungsregel und fünf Disziplinen

Zuerst zum Format. Es handelt sich nicht um eine separate Anwendung, sondern um einen Bundle unter der Cordis-Architektur (cordis.patch.yml), der in DSH läuft. Das Repository enthält neun dokumentierte Artikel mit Nummern von 000 bis 008: Philosophie, Domänenmodell, Autorisierung, Ausführung, Prompten, Panel, Bereitstellung, Architektur und Cookbook. Der letzte Artikel beschäftigt sich mit der Erweiterung einer Source. Jeder Artikel verhtut sich nur auf die vorherigen Dokumente ein – das ist eine Designregel des README: Der Leser wird niemals auf ein noch nicht eingeführtes Konzept stoßen.

Das Domänenmodell ist ein einspuriger Fluss. Die Source (Ereignisquelle, GitHub oder Lark) erzeugt Trigger (unveränderliche Ereignisse), die Trigger gehören zu Threads (zeitliche Sitzungen). Eval führt zwei Schritte durch (Gate plus Bewertung) auf einer Gruppe von Triggers und liefert eine Entscheidung; wenn eine Entscheidung angenommen wird, wird ein Ticket erstellt und ein Mandat hinzugefügt. Die Assignment bindet das Ticket an einen Executor (Ausführungs-Sitzung), und das Ergebnis wird über den Channel in die ursprüngliche Sitzung geschrieben. Danach werden Nachrichten desselben Threads über Subscription verteilt, direkt an das bereits abonniertes Ticket gesendet, ohne dass eine weitere Bewertung durchgeführt wird.

Der Schwerpunkt des gesamten Systems liegt bei der Autorisierung. In der Anfangszeile von docs/002 steht: „Der Host führt die allowlist, Regeln und Mandate durch. Nachrichten, Kommentare und zitierte Dokumente sind Eingaben für eine Entscheidung; sie können die Berechtigungen nicht ändern.“ Das Hostprogramm verlangt die Allowlist, Regeln und Mandate strikt einzuführen; Nachrichten, Kommentare und zitierte Dokumente sind nur Eingaben für die Entscheidung und dürfen keine Berechtigungen ändern. Mit anderen Worten: Die Verteidigungslinie gegen Prompt-Injection ist nicht in den Prompten selbst geschrieben, sondern in der Architektur: Unabhängig davon, was die Nachrichteninhalt enthalten, wird die Berechtigkeitsbewertung nicht über den Inhalt der Nachrichten erfolgen.

Es gibt zwei Wege für Triggers. Der erste ist Eval, der entscheidet, ob mit der Ausführung begonnen wird: Die Source registriert, ob eine Nachricht direkt angesprochen wird (@-Referenz oder private Nachricht), und Gate überprüft die Absender und die Policy der Source. Personen in der Allowlist, die direkt angesprochen werden, bilden explizite Anfragen; Bots erzeugen höchstens „deduzierte Kandidaten“, die niemals eine explizite Anfrage bilden, und Bots, die nicht auf der Liste stehen, akzeptieren keine Anfragen. Die deduzierten Kandidaten müssen auch den accept Mode durchlaufen: off, observe, auto – standardmäßig observe, nur die Entscheidung „normalerweise akzeptiert“ wird registriert, ohne tatsächlich mit der Ausführung begonnen zu werden. Der zweite Weg ist Subscription, der die bestehende Arbeit fortsetzt: Jede Nachricht, die ein Thread abonniert (einschließlich Bots und CI), wird an das bereits abonniertes Ticket gesendet. Dabei wird Gate umgangen, aber keine neuen Berechtigungen vergeben; das Ticket ist stets durch sein eigenes Mandat begrenzt. Selbst wenn eine Person die Abonnement abbricht, bleibt die Eigentumsverhältniss des Executors bis zum Ende des Tickets bestehen.

„Mandate“ ist ein autorisierter Zertifikat, der in dem Moment der „accept“-Aktion festgelegt wird und nicht veränderbar ist. Es dokumentiert die Version, den Umfang, die Intensität und die Regeln des Policies. Im gesamten System gibt es nur drei Operationen, die es ändern können: „accept“ erstellt es, „stop“ von ihm entfernt es, und ein erfolgloser Wiederholter Test löscht es. Um ein beendetes Ticket wiederherzustellen, muss es zunächst gemäß dem aktuellen Policy getestet werden: Den Absender aus der Liste der Freigaben zu nehmen, führt dazu, dass das ursprünglich von ihm verliehene „Mandate“ gelöscht wird. Diese Regeln finden sich in Zeile 242 des Files „src/policy.ts“, wobei die Funktionen „gate“ und „revalidate“ im Dokument entsprechend angeordnet sind.

Das philosophische Dokument legt fünf Disziplinen für den Agent fest: Handeln nur, wenn es verlangt wird oder durch teambedingte Regeln erlaubt ist; Arbeiten, die niemand verlangt, müssen zuerst in einer nur dokumentierten Form ausgeführt werden; sprechen, wenn jemand handeln muss oder die Ergebnisse genutzt werden können; während der Arbeit ruhig bleiben; jeweils nur eine spezifische Frage stellen, strukturiert fragen, damit die Fragen jemanden finden und nicht in langen Berichten versteckt bleiben; stoppen nach dem Einfluss, nicht nach der Arbeitsleistung; lokale Änderungen erst bis zu einem bewertbaren Punkt durchführen; bei Designentscheidungen anhalten und fragen; ehrlich berichten, Entwürfe als unvollendet markieren, Fehler melden, „Begrenzungen dürfen nicht vermieden werden, indem man Fragen vermeidet“.

Die Katalogstruktur und das Dokumentationssystem ergänzen sich gegenseitig. „src/core“ enthält das Domänenmodell und den Ticket-Engine (15 Dateien wie „engine“, „tickets“, „intake“, „stage“, „replies“, „memory“); in „src/sources“ treten die GitHub-- und Feishu--Dateien paarweise auf, zwei Quellen-Implementierungen sind vollständig symmetrisch; „src/executor“ führt die Ausführung auf DSH-Sitzungen um; „policy.ts“, „limits.ts“ und „admission.ts“ sind als separate Dateien erstellt, ihre Autorisierung und Throttling werden nicht mit dem Geschäftscode vermischt. 13 Anleitungen befinden sich im Verzeichnis „prompts/“ und wurden in das Repository aufgenommen; „admission“, „dispatch“, „orchestrator“, „worker“ und „handoff“ haben jeweils ihre eigene Aufgabe, und die Anleitungen werden als Bürger der ersten Klasse verwaltet.

Schlüsseldaten: 12.390 Codezeilen, ein Commit

Einige feste Zahlen zur Statistik des Repositories: Unter „src/“ gibt es insgesamt 12.390 Zeilen TypeScript und 147 .ts-Dateien; unter „tests/“ sind 65 Dateien; insgesamt 216 Dateien im gesamten Repository (ohne „node_modules“ und „.git“), mit einer Gesamtgröße von 3,8 MB. Die Sprache ist TypeScript, in „package.json“ steht „private: true“, es wird kein npm-Paket veröffentlicht, sondern nur „bundle“ verwendet.

Geschichte: Es gibt nur einen einzelnen „squash Commit“ (6337fc8, 2026-10-31, „feat: add the dsh-superagent research prototype“), nach der Veröffentlichung gab es keine weiteren Commits, und die „contributors API“ liefert eine leere Array. Neben den neun nummerierten Dokumenten gibt es in „prompts/“ 13 Anleitungen und in „skills/“ 2 (einmal jeweils auf GitHub und Feishu).

Die Standardwerte in policy.ts sollten separat aufgeführt werden: Die maximale Anzahl an Konkurrenzberechnern beträgt standardmäßig 3; die Eval-Zeitüberschreitung beträgt standardmäßig 120 Sekunden; der accept-Modus ist standardmäßig „observe“. Es gibt nur zwei Standardregeln: „copy“ (Textkorrektur) und „visual“ (Visuell korrigieren). Die Anweisung in der „visual“-Regel lautet „Do not invent visual style“. Da die Richtung oder der Umfang nicht festgelegt sind, wird nur beobachtet, ohne zu bestätigen oder etwas zu ändern. Die Standardwerte sind sehr eng gefasst und entsprechen dem Vorschlag „zuerst eng, dann weit“.

Details zur Ausführung: Jedes Ticket wird in eine Sitzung mit dem Namen „worker-<ticket id>“ und ein spezielles Verzeichnis eingeteilt. Hintergrundbefehle, die länger als 5 Sekunden dauern, werden automatisch zu Hintergrundaufgaben umgewandelt, damit der Worker neue Nachrichten sofort erhalten kann, anstatt zu warten, bis die Befehle abgeschlossen sind.

SETUP.md ist an sich eine Aufschlüsselungstechnik. Es ist nicht für Menschen geschrieben, sondern für Agenten: Die offizellen Installationsempfehlungen lauten „Lassen Sie Ihren Coding-Agenten SETUP.md lesen, um bei der Installation zu helfen“. Im Dokument werden den Agenten Regeln gegeben: Stellen Sie nur eine kurze Frage pro Mal, jede Nachricht soll 300 Wörter nicht überschreiten. Der vollständige Plan wird nur einmal angezeigt, nachdem alle Fragen gestellt wurden. Es ist strengstens verboten, im Chat Geheimnisse zu verlangen. Schritte, die manuell ausgeführt werden müssen (Account erstellen, CLI abmelden, App-Secret eintragen), werden separat in einer Nachricht zusammengefasst. Die Voraussetzungen sind ebenfalls nicht kurz: Node.js 22.19+, pnpm, git 2.32+, tmux, Python 3.8+, GitHub CLI 2.48+, dazu die DSH-Daten und ein Model-Provider.

Einfluss und Bedeutung: Aufmerksamkeit ist Geld, Berechtigungen sind eine Eisenregel

Erstens wird die Aufmerksamkexeconomy als Designaxiom betrachtet. Die fett gedruckte Aussage in dem README lautet: „Nimm so wenig menschliche Aufmerksamkeit wie möglich und gib so viel Wert wie möglich.“ Philosophische Dokumente entwickeln dies zu Qualitätskriterien: Jede Nachricht, jede Benachrichtigung, jede Frage, jede Einstellung, jedes Panel-Element, jeder Textabschnitt beansprucht die Aufmerksamkeit eines Menschen. Wenn der Wert nicht den Kosten entspricht, wird er gelöscht. Die Motivation ist ebenfalls direkt: „Ein Agent, der für das gesamte Team handeln kann, kann auch die Aufmerksamkeit des gesamten Teams verschwenden.“ Die meisten Agentenprodukte betonen ihre Fähigkeiten als Verkaufsargument. In diesem Projekt wird hingegen „wie viel Aufmerksamkeit man beansprucht“ als erste Einschränkung betrachtet: Das Panel zeigt nur Dinge an, die man bearbeiten muss; der Gesundheitszustand nimmt keinen Platz ein. Es soll weniger Konzepte und weniger Einstellungen geben. Wenn ein Standardwert ausreicht, wird dieser nicht als Konfigurationspunkt angelegt. Das Verhalten des Teams, das in Worten beschrieben wird, wird als Hinweisstext statt als Schalter dargestellt.

Zweitens gibt es eine architektonische Antwort auf Prompt Injection. Die gängige Praxis in der Branche besteht darin, dem Modell in den Anweisungen zu sagen: „Führe die Befehle nicht aus“, was im Wesentlichen die Autonomie des Modells fördern soll. DSH-Superagent überlässt das Problem dem Hostprogramm: Berechtigungen existieren nur in der Whitelist, den Regeln und den Mandaten. Nachrichten, Kommentare und zitierte Dokumente dienen lediglich als Entscheidungsinput. Egal wie ähnlich die eingegebenen Texte Befehlen erscheinen, es ist nicht möglich, Berechtigungen außerhalb des Gates zu erhalten. Diese Verteidigungslinie ist nicht von den Fähigkeiten des Modells abhängig – sie bleibt bestehen, auch wenn das Modell gewechselt wird. In der Tabelle „Abgelehnte Konzepte“ von docs/001 gibt es eine Entscheidung bezüglich der Quelle: DerExecutor darf nicht behaupten, dass „jemand ihn zum Stoppen aufgefordert hat“ – das Recht zur Anweisung des Stoppens liegt bei Eval. Jedes Agentensystem, das externe Nachrichten entgegennimmt, kann direkt übernommen werden.

Drittens sind die Verantwortlichkeiten der Operator in den technischen Dokumenten festgelegt. In den philosophischen Dokumenten gibt es eine spezielle Abschnitt mit „Verantwortung“: Agenten verfassen Kommentare, öffnen PRs und senden Nachrichten mit den Accounts, die das Team täglich sieht. Jede Nachricht beansprucht die Aufmerksamkeit der Kollegen – der Operator muss dafür verantwortlich sein. Vier Handlungsregeln: Beginnen Sie mit einer engen Liste der Whitelist, registrieren Sie nur aktive Arbeit, erweitern Sie die Liste nachdem Sie sie überprüft haben; ändern Sie die Anweisungen, wenn es störend ist, verlängern Sie oder pausieren Sie direkt: „Verwenden Sie keine mehr Nachrichten, um Störgeräusche zu erklären“; nutzen Sie es nicht zur Menge-Produktion – massenhafte PRs, öffentliche Nachrichten und unnötige Arbeit führen zu einem höheren Verbrauch für das Team als zu einem höheren Wert. Seien Sie verantwortlich für das, was Sie sagen – lesen Sie die Inhalte, die im Namen Ihrer Person veröffentlicht wurden, und ändern Sie die Anweisungen, wenn sie falsch sind. Die Verwaltungsregeln und das technische Design werden in demselben Dokument dargestellt – diese Praxis ist seltener als der Code selbst.

Viertens bietet es ein Beispiel für eine Projektorganisation, bei der „Agenten schreiben und lesen“. Der README erkennt an, dass viele Arbeiten vom coding agent erledigt wurden – die Organisation dieser 12.390 Zeilen Code liefert eine wiederholbare Antwort: Die Dokumente sind nacheinander abhängig, damit der Leser (einschließlich Agent-Leser) keine Voraussetzungen für das nächste Dokument verpasst; Anweisungen werden in die Datenbank aufgenommen und nach Rollen eingeteilt; zwei Source-Implementierungen sind streng symmetrisch – die Erweiterung eines Sources beinhaltet Lehrbücher; 65 Testdokumente bilden die Grundlage; sogar die Dokumente über das Domänenmodell enthalten eine Tabelle mit „Abgelehnten Konzepten“, in der zehn klare Entwürfe und Gründe dafür aufgeführt sind, nicht verwendet zu werden. Hier gibt es eine vollständige Antwort auf, wie ein Repository für Agenten gestaltet sein sollte.

Kontroversen und Risiken: Das Forschungsprototyp ist ein Forschungsprototyp

Erstens, Identität und Reifegrad. Der README erkennt an: Der Code könnte noch Fehler enthalten, der Codestil und die Projektarbeit könnten unterschiedlich sein – „Betrachten Sie es als Forschungscode, es ist kein produktiv einsatzbarer Software“. Die Veröffentlichungsversion unterscheidet sich von der internen Version – einige Designs in den Begleitartikeln sind zukünftige Richtungen oder noch nicht implementierte Prototypen. Teams, die direkt verwenden möchten, sollten diese Abschnitte dreimal lesen.

Zweitens, keine Entwicklungsgeschichte. Im gesamten Repository gibt es nur einen squash Commit – eine einmalige Veröffentlichung, die Entscheidungen im Laufe des Wachstums des Codes sind unbekannt; die contributors API liefert eine leere Array zurück – die Verteilung der Beiträger ist unbekannt. Für ein Repository, das darauf abzielt, „Agenten in das Projekt einzubeziehen“, ist die fehlende Geschichte besonders bedauerlich: Es ist nicht möglich, aus den Commit-Protokollen zu erkennen, wie Agenten echte Codeproduktion durchführen – man sieht nur das endgültige Ergebnis. Außerdem bedeutet 0 open issues nicht, dass keine Probleme existieren – es ist eher möglich, dass die Community noch nicht Zeit hatte, ernsthaft zu nutzen (das ist meine Einschätzung).

Drittens ist die Verbreitung von Unterschieden an sich ein Signal. HN hat mit 11 Punkten und 0 Kommentaren die beste Bewertung erhalten, während GitHub innerhalb von drei Tagen 13.000 Sterne erhalten hat. Die Abwesenheit von HN zeigt, dass seine Beteiligung an den Diskussionen in der englischsprachigen Technikgemeinschaft begrenzt ist; der Anstieg der Sterne bei GitHub kommt hauptsächlich durch den Markendruck von DeepSeek und die Erzählung von „Super-Agenten“ zustande. Sterne sind ein Indikator für Aufmerksamkeit, nicht für Qualität – diese beiden Dinge dürfen nicht zusammen gelesen werden (das ist auch meine Einschätzung).

Viertens sollte der Einstieg in die Implementierung auf die Lage der Daten beschränkt werden. Voraussetzungen sind eine lange Liste von Anforderungen: Es muss eine DSH-Plattform, ein spezielles GitHub-Konto und optional ein WeChat-Robot vorhanden sein; die offiziellen Dokumente empfehlen direkt, dass ein Coding-Agent den Installationsprozess unterstützt. Für Teams, die nicht im DSH-Ökosystem sind, ist der praktische Wert begrenzt; was wirklich übertragbar ist, sind die Dokumentationen und die Designs. Auch sollte man auf den impliziten Preis des Zulassungsmodells achten: Je strenger die Mechanismen wie Gate, Mandate und Wiederholte Überprüfung sind, desto größer ist die Konfigurationsvielfalt. Wenn die Policy-Version ändert, werden alle laufenden Evaluationsungenstellt und neu angeordnet – es gibt viele Regeln, die bei der Betriebsführung beachtet werden müssen.

Schlussfolgerung und Perspektiven: Dokumente sind wichtiger als Code

Der Titel des Begleitartikels ist eine Aussage: „Exploring Super-agent Design: Towards a More Autonomous Agent System“, auf dem Weg zu einem autonomeren Agentensystem. Der Artikel und das Prototyp sind eng miteinander verbunden: Der Artikel befasst sich mit der Design, ein Teil davon ist die zukünftige Ausrichtung; das Prototyp zeigt nur die bereits implementierten Teile und erklärt, dass sie nicht identisch sind. Es lohnt sich, zwei Dinge im Auge zu behalten: Ob im DSH-Ökosystem ein zweites oder drittes großes Bundle entsteht; und ob das DeepSeek-Team die zukünftigen Richtungen aus dem Artikel in späteren Versionen umsetzt.

Für den Leser ist die Wertschichtung dieses Repos klar definiert. Am untersten Punkt befindet sich das Zulassungsmodell, das direkt übertragen werden kann: Der Host hat die Berechtigungen, Nachrichten sind nur Eingaben, Mandate sind unveränderlich und es gibt eine Wiederholte Überprüfung vor der Wiederherstellung. Im mittleren Bereich befinden sich die Designaxiome der Aufmerksamkeitswirtschaft und die Verantwortlichkeiten des Benutzers. Das oberste Level beinhaltet die 12.390 Zeilen TypeScript-Implementierung, die laut README nur als möglicherweise fehlerfreier Referenzmodell gilt. Meine Schlussfolgerung in einem Satz: dsh-superagent ist lesenswert, Dokumente sind wichtiger als Code und lohnen eine gründliche Analyse; es zeigt, dass die Schwierigkeiten eines Agentensystems nicht in der Fähigkeit liegen, sondern in der Zulassung und Aufmerksamkeit – beide Probleme haben eine ingenieurtechnische Lösung.

Referenzquellen

• Repository und README: https://github.com/deepseek-ai/dsh-superagent-prototype (13,000★ / 1,348 Fork / 0 offene Probleme / 79 Abonnenten, 2026-11-03)
• Lokale Clone für sichtbare Überprüfung (2026-11-03): README.md, SETUP.md, docs/000-philosophy.md, docs/001-domain.md, docs/002-authorization.md, docs/003-execution.md, src/policy.ts, package.json, prompts/, skills/
• Begleitende Artikel: „Exploring Super-agent Design: Towards a More Autonomous Agent System“ (Quelle des README, Prototypenbeschreibung und Artikel nicht vollständig übereinstimmen)
• Diskussionen auf der DSH-Plattform: Developer Preview 747▲/314c (2026-08-13); Harness Desktop 417▲/228c (2026-10-02)
• HN-Einträge in diesem Repository: Höchstwert 11▲/0 Bewertungen (2026-10-31)

Unterschrift: Yongliang