DeerFlow 2.0: ByteDances quelloffenes „Super Agent Harness“, das Unteragenten, Gedächtnis und Sandboxes in einer Laufzeit bündelt

DeerFlow steht für Deep Exploration and Efficient Research Flow und begann als quelloffenes Deep-Research-Framework von ByteDance. Die README erklärt den Wandel: Die Community trieb es in Datenpipelines, Foliensätze, Dashboards und Content-Automatisierung, Einsatzfälle, die das Team nicht vorhergesehen hatte. Daraus folgerte das Team, dass DeerFlow kein bloßes Forschungswerkzeug ist, sondern ein Harness, eine Laufzeit, die Agenten die Infrastruktur gibt, um Arbeit zu erledigen, und baute es von Grund auf neu. 2.0 teilt keinen Code mit 1.x; das ursprüngliche Deep-Research-Framework liegt im Branch 1.x, die aktive Entwicklung ist zu 2.0 gewandert. Die README sagt auch, nach dem Start von 2.0 habe DeerFlow am 28. Februar 2026 Platz eins bei GitHub Trending erreicht. Stand 13. Oktober 2026 hat das Repository etwa 83.766 Sterne und 11.654 Forks, eine MIT-Lizenz, Python-Code, wurde am 7. Mai 2025 angelegt und am 13. Oktober zuletzt gepusht.

Nach der Definition der README ist DeerFlow 2.0 kein Framework mehr, das man selbst zusammensteckt, sondern ein Super Agent Harness, Batterien inklusive und voll erweiterbar. Es baut auf LangGraph und LangChain auf und bringt Dateisystem, Gedächtnis, Skills, sandbox-bewusste Ausführung und die Fähigkeit mit, komplexe mehrstufige Aufgaben zu planen und Unteragenten zu erzeugen. Es ist modellunabhängig und läuft mit jedem LLM, das eine OpenAI-kompatible API bietet, arbeitet aber am besten mit langen Kontextfenstern (über 100.000 Token), Schlussfolgern, multimodaler Eingabe und starker Werkzeugnutzung; die README empfiehlt nachdrücklich Doubao-Seed-2.0-Code, DeepSeek v3.2 und Kimi 2.5. Für Suche und Crawling integriert es InfoQuest, ein von ByteDances BytePlus selbst entwickeltes Werkzeugset mit kostenloser Online-Erprobung.

Die Kernfunktionen lassen sich gruppieren. Skills und Werkzeuge: Ein Capability Center in der Seitenleiste verwaltet Plugins (MCP-Server und Lark/Feishu-Anbindung) und Skills, eingebaute und selbst erstellte oder importierte Skills werden getrennt aufgeführt, und ein Community-Tab importiert .skill-Archive. Unteragenten: Jeder läuft standardmäßig in einem isolierten Kontext, der den Hauptagenten und andere Unteragenten nicht sieht, damit er sich auf seine Aufgabe konzentriert; task-Aufrufe akzeptieren die Modi isolated (Standard) und snapshot, wobei snapshot dem Unteragenten das behaltene Gespräch des Elternagenten samt Kompaktierungszusammenfassung als Verlauf übergibt, auf Kosten zusätzlicher Eingabe-Token. Kontext-Engineering: Innerhalb einer Sitzung fasst es erledigte Teilaufgaben zusammen, lagert Zwischenergebnisse ins Dateisystem aus und komprimiert Nicht-mehr-Relevantes, damit lange mehrstufige Aufgaben das Fenster nicht sprengen; Werkzeugausgaben haben Vorschaubudgets und strukturierte Zusammenfassungen. Das Langzeitgedächtnis liefert eine Komponente namens DeerMem mit Entprellung je Gespräch, Nutzer und Agent, einer Standard-Ruhezeit von 30 Sekunden und höchstens 300 Sekunden Wartezeit. Hinzu kommen Sitzungsziele, manuelle Kontextkompaktierung, Chat-Archiv, Projekte mit Dokumentenregal, geplante Aufgaben (mit vorab sichtbaren Cron-Zeiten, Lebenszyklus und Sicherheitsobergrenzen), ein eingebetteter Python-Client und eine Terminal-Arbeitsumgebung.

Die README ist beim Betrieb ausführlich. Der Schnellstart konfiguriert zuerst ein Modell und bietet dann Docker (empfohlen) oder lokale Entwicklung, optional mit LangGraph Studio zur Fehlersuche; eigene Abschnitte behandeln das Aktualisieren eines bestehenden Checkouts, mehrere Anbieter, Stream-Aktionen auf bestehenden Läufen und persönliche Zugriffstoken. Der Sandbox-Abschnitt lohnt die Lektüre. AIO-Sandboxes werden nach einem unsicheren impliziten Shell-Ergebnis oder nach der Sitzungserstellung recycelt, und vor dem Recycling hält das Gateway die Container-ID oder Pod-UID in einem Quarantäneverzeichnis fest, Einträge, die fehlgeschlagene Stopps und Gateway-Neustarts überdauern. Alte Einträge werden erst gelöscht, wenn das Backend bestätigt, dass kein Container oder Pod mehr existiert; eine Lösch-Bestätigung oder ein gescheiterter Health-Check genügt nicht. Dieser vorsichtige Umgang mit Fehlerpfaden deutet auf einen Einsatz über lange Zeit ohne Aufsicht hin.

Das Sicherheitskapitel sollte man zuerst lesen. Die README sagt, DeerFlow habe hochprivilegierte Fähigkeiten, Ausführung von Systembefehlen, Ressourcenoperationen und Aufruf von Geschäftslogik, und sei standardmäßig für eine lokale vertrauenswürdige Umgebung gedacht, die nur über die Loopback-Adresse 127.0.0.1 erreichbar ist. In einem LAN, auf einem öffentlichen Cloud-Server oder in einer anderen Umgebung mit vielen Zugriffspunkten ohne strenge Maßnahmen drohen unbefugte Aufrufe, Massenauslösung riskanter Operationen, sobald Internet-Scanner es finden, sowie Compliance- und Rechtsrisiken. Der Docker-Stack veröffentlicht den Eingangsport nur auf 127.0.0.1, auch lokales make dev und make start binden an Loopback. Für den Zugriff von anderen Rechnern setzt man BIND_HOST in .env, aber erst nach Schutzmaßnahmen: eine IP-Allowlist mit iptables oder Hardware-Firewalls, starke Vorab-Authentifizierung über einen Reverse-Proxy wie nginx und ein eigenes VLAN. Eine frische Instanz hat keine Konten, daher legt jede nicht auf Loopback beschränkte Installation sofort nach dem Start über /setup das Admin-Konto an. Die README ergänzt, ein Gateway-Admin könne stdio-MCP-Server registrieren, die Befehle im Gateway-Container ausführen; die API beschränkt sie auf eine Allowlist (standardmäßig npx und uvx) und lehnt Argumente ab, die beliebigen Code auswerten, doch das ist Verteidigung in der Tiefe, keine Grenze: Gateway-Admin ist wie Codeausführung auf dem Host zu behandeln.

Unsere Einordnung: Studieren sollte man an DeerFlow 2.0 die technischen Abwägungen, nicht die Sternezahl. Es dokumentiert Details, die sonst im Inneren verborgen bleiben, etwa Unteragenten-Isolation, Kontextzusammenfassung, Auslagerung ins Dateisystem und Sandbox-Recycling, und ist damit eine seltene Referenz für alle, die Agenteninfrastruktur bauen. Drei Vorbehalte. Die README ist sehr lang und ändert sich schnell, viele Abschnitte beschreiben das Verhalten des aktuellen Quelltexts; vor dem Einsatz mit der eigenen Version abgleichen. Macht und Risiko stammen aus demselben, dem Ausführen von Befehlen und Lesen und Schreiben von Dateien; die Loopback-Bindung sollte man nicht leichtfertig ändern. Und die Modellempfehlungen haben eine erkennbare Anbieterneigung; echte Ergebnisse hängen von Modell und Aufgabe ab. Erst in einem isolierten Container mit einem Verzeichnis nur mit Testdaten betreiben, dann entscheiden, ob echte Daten und externe Kanäle angebunden werden.