
DeerFlow 2.0: ByteDances 68k-Sterne Super-Agent-Harness, der fertige Artefakte liefert
TL;DR: „DeerFlow 2.0 ist ByteDances 68k-Sterne Open-Source-Super-Agent-Harness: progressiv geladene Skills, sandboxed Sub-Agents, persistentes Gedächtnis, sechs IM-Kanäle. Prompt rein, fertiges Deck, Report oder Video raus."
— Till FreitagDer Harness ist jetzt das Produkt, nicht das Modell
Zwei Jahre lang ging es um Modelle. Wer hat das größte Kontextfenster, wer führt im MMLU, wessen Reasoning-Loop ist am engsten. Diese Diskussion ist weitgehend vorbei. Die interessante Arbeit ist eine Schicht nach oben gewandert: der Harness.
Ein Harness macht aus einem Modell etwas Brauchbares. Skill-Loading, Sub-Agent-Orchestrierung, Sandbox-Isolation, Memory, Channel-Routing, Artefakt-Übergabe. Die langweilige Infrastruktur, die darüber entscheidet, ob du einen Chatbot oder einen Mitarbeiter bekommst.
DeerFlow 2.0 ist gerade die vollständigste Open-Source-Antwort auf dieses Problem. ByteDance hat es geshipt, 68k GitHub-Sterne, und die Architektur lohnt sich zu verstehen – auch wenn du es nie selbst betreibst.
Was im Karton drin ist
Built-in Skills, progressiv geladen
DeerFlow bringt Skills für Research, Report-Generation, Slide-Decks, Web-Seiten, Bild- und Video-Generierung mit. Keiner davon lädt eager. Der Harness zieht Skill-Bundles on demand – das hält das aktive Kontextfenster schlank, selbst wenn die Skill-Registry riesig wird.
Das ist dieselbe architektonische Wette, die Anthropic letztes Quartal mit Agent Skills gemacht hat: Skills als Dateisystem, nicht als System-Prompt. Das Modell sieht nur das, was es gerade braucht.
Sub-Agents in isolierten Sandboxes
Jeder Sub-Agent läuft in seiner eigenen Sandbox mit Dateisystem-Zugriff und Bash. Nicht "Function Calls, die JSON zurückgeben" – echte Prozesse mit echten File-Handles. Das macht aus "bau mir ein Slide-Deck" einen echten Workflow statt einer Demo.
Die Isolation ist das Sicherheitsmodell. Ein Research-Sub-Agent, der aus dem Ruder läuft, kann das Arbeitsverzeichnis des Slide-Gen-Sub-Agents nicht anfassen. Genau diesen Teil bekommen die meisten Eigenbau-Agent-Stacks falsch hin – sie teilen State, dann teilen sie Blast Radius.
Memory, der über Sessions hinweg bleibt
Sessions resetten nicht. State trägt sich fort. Du kannst DeerFlow am Montag eine Aufgabe geben, am Mittwoch reinschauen, und es weiß noch, worum es geht. Klingt offensichtlich, bis du es selbst auf einer stateless API gebaut hast.
Sechs Kanäle rein, Artefakte raus
Tasks kommen aus einer Web-UI, sechs IM-Kanälen inklusive Slack und Telegram, oder Claude Code via dem claude-to-deerflow-Skill. Der letzte Punkt ist verräterisch: DeerFlow geht davon aus, dass du ohnehin schon einen Agent betreibst (Claude Code) und die langlaufenden, artefakt-produzierenden Tasks an einen anderen Harness delegieren willst, der die bessere Infrastruktur dafür hat.
Zurück kommt ein fertiges Artefakt. Kein Transkript, kein Tool-Call-Log – ein Deck, ein Report, ein Video.
Warum die Architektur zählt
Die meisten Agent-Frameworks 2026 verwechseln immer noch Modell und Produkt. Sie shippen einen Wrapper um einen API-Call und nennen das einen Agent. DeerFlow zieht die Linien richtig:
| Schicht | Aufgabe | Wo die meisten Stacks scheitern |
|---|---|---|
| Channels | Tasks von Menschen oder anderen Agents empfangen | Hardcoden eine UI |
| Router | Skill + Sub-Agent auswählen | Routen zu einem Mega-Prompt |
| Skills | Prozedurales Wissen + Skripte | Stopfen alles in den System-Prompt |
| Sandboxes | Isolierte Ausführung pro Sub-Agent | Teilen Dateisystem, teilen Fehlerbilder |
| Memory | State über Sessions hinweg | Behandeln jeden Turn als neu |
| Artefakte | Etwas Brauchbares zurückgeben | Liefern ein Chat-Transkript |
Jede einzelne dieser Schichten baust du an einem Wochenende. Alle sechs so zu bauen, dass sie zusammenspielen, ist die Arbeit – und genau das bezahlen die 68k Sterne.
Was das für Teams bedeutet
Wenn du Production-Agents betreibst, lohnt sich DeerFlow zu lesen, auch wenn du es nicht deployst:
- Skill-als-Dateisystem ist das richtige Pattern. Wenn dein Agent-System-Prompt länger als eine Seite ist, machst du es falsch.
- Sandbox pro Sub-Agent ist nicht verhandelbar für alles, was Dateien oder Shell anfasst. Das "Always Allow"-Permission-Model mancher kommerzieller Produkte ist kein Sicherheitsmodell.
- Channels sind eine Integrations-Oberfläche, keine UI-Entscheidung. Wenn dein Agent nur aus einem Frontend funktioniert, ist er nicht deployed – er ist demonstriert.
- Memory ist ein Produkt-Feature. Stateless Agents sind Spielzeug.
Für unsere Kunden, die interne Agent-Plattformen bauen, ist das die Referenzarchitektur-Diskussion. Du musst DeerFlow nicht nutzen – aber wenn dein Design von diesen sechs Schichten abweicht, solltest du wissen, warum.
Das größere Muster
Da draußen gibt es irgendwo ein Social-Graph-basiertes Agent-Harness-Startup, das in den nächsten fünf Jahren auf 1 Billion Dollar geht. Die Kategorie formt sich gerade so, wie sich Mobile-OS 2008 und Cloud-Plattformen 2012 geformt haben: ein paar opinionierte Stacks, schnelle Divergenz, dann Konsolidierung auf zwei oder drei.
DeerFlow ist der Open-Source-Pol. Anthropics Agent Skills + Dispatch ist der vertikal integrierte kommerzielle Pol. Die Mitte – LangGraph, CrewAI, jedes "Agent Framework", das eine Series A raised – wird in den nächsten zwölf Monaten viel Druck spüren.
Wähl den Pol, mit dem du leben kannst. Die Mitte ist der gefährliche Ort.
→ Unser Vergleich: Claude Managed Agents, LangGraph und CrewAI → Desktop-Agenten-Showdown: Dispatch, Manus, Perplexity Computer, DIY → Agent-Sandboxing-Ansätze im Vergleich








