DeerFlow 2.0: das Super-Agent-Harness aus ByteDance im Detail
Ein Open-Source-SuperAgent-System mit langem Horizont, das recherchiert, codiert und erstellt. Mit Hilfe von Sandboxes, Speichern, Tools, Skills, Subagenten und Message Gateway bewältigt es verschiedene Ebenen von Aufgaben, die Minuten bis Stunden dauern können.
Auf einen Blick
- Was ist das?
- Der Neuentwurf bytedance/deer-flow orchestriert Sub-Agenten, Sandboxes, Speicher und Skills für Aufgaben von Minuten bis Stunden. Einrichtung, Betriebsgrößen, Tracing und die Vertrauensgrenze der Sandbox.
- Für wen ist es gedacht?
- DeerFlow 2.0 passt für Teams, die langlaufende Agentenaufgaben selbst betreiben und dabei Sandbox-Isolation, Beobachtbarkeit und Nachrichtenkopplung an Telegram oder Slack brauchen; es passt nicht für minimale Einzelplatz-Setups ohne Docker, denn der empfohlene Weg verläuft über Container und eine Größentabelle ab 4 vCPU.
- Darf ich es kommerziell nutzen?
- Ja. MIT ist eine freizügige Lizenz: Sie dürfen darauf aufbauende Software nutzen, verändern und verkaufen, solange Sie die Urheberrechts- und Lizenzhinweise beibehalten.
- Wird es noch gepflegt?
- Ja. Das Repository hat innerhalb des letzten Tages neue Commits erhalten.
- In welcher Sprache ist es geschrieben?
- Hauptsächlich Python, laut der Sprachstatistik von GitHub.
Die Antworten beruhen auf den GitHub-Daten des Projekts (zuletzt abgeglichen am 15. September 2026) und auf unserer Analyse. Sie sind keine Rechtsberatung.
TIEFGEHENDE OPEN-SOURCE-ANALYSE
Vom Deep-Research-Framework zum Super-Agent-Harness: der Neuanfang in 2.0
Der Name DeerFlow steht für Deep Exploration and Efficient Research Flow, und das Projekt beschreibt sich als offenes Super-Agent-Harness, das Sub-Agenten, Speicher und Sandboxes orchestriert, angetrieben von erweiterbaren Skills. Damit adressiert es Aufgaben, die von Minuten bis Stunden laufen: Recherche, Programmierung, Erstellung von Inhalten, Datenpipelines, Folien oder Dashboards.
Die Version 2.0 ist laut README eine Neuentwicklung ohne gemeinsamen Code mit v1. Das ursprüngliche Deep-Research-Framework wird im main-1.x-Zweig weiter gepflegt, die aktive Entwicklung ist auf 2.0 übergegangen. Das Projekt meldet selbst, am 28. Februar 2026 den ersten Platz auf GitHub Trending erreicht zu haben, und weist 81.054 Sterne sowie 11.164 Forks aus. Die Schwesternwerkzeuge sind bemerkenswert: LLM Space dient als Desktop-Werkzeug, um Agentenideen zu prototypisieren, jeden Harness-Schritt zu inspizieren, Fehler wiederzugeben und die Leistung zu vergleichen. Für das Modellbackend empfiehlt das README ausdrücklich Doubao-Seed-2.0-Code, DeepSeek v3.2 und Kimi 2.5, und mit InfoQuest ist die Suche- und Crawl-Werkzeugsammlung von BytePlus integriert.
make setup und make doctor: die Einrichtung von deer-flow
Der Einstieg beginnt mit git clone https://github.com/bytedance/deer-flow.git und cd deer-flow. Dann startet make setup einen interaktiven Assistenten, der die Wahl des LLM-Anbieters, optionaler Websuche und der Ausführungseinstellungen abfragt, also Sandbox-Modus, Bash-Zugriff und Dateischreibwerkzeuge. Laut README erzeugt der Assistent in etwa zwei Minuten eine minimale config.yaml und schreibt die Schlüssel in die .env-Datei.
Für Kontrolle und Berichterstattung gibt es zwei weitere make-Ziele. make doctor prüft die Einrichtung jederzeit und liefert umsetzbare Korrekturhinweise. make support-bundle schreibt eine *-issue-summary.md, einen *-issue-draft.md für KI-gestützte Fehlermeldungen und ein optionales Beweisarchiv unter .deer-flow/support-bundles/. Das Bündel enthält laut README nur geschwärzte Diagnosen und Dateimanifeste, niemals die .env, Rohkonversationen oder Nutzerdateien; Maintainern dient triage.json als Einstieg. Wer von Hand konfiguriert, nutzt make config, um die vollständige Vorlage zu kopieren; config.example.yaml dokumentiert CLI-basierte Anbieter wie Codex CLI und Claude Code OAuth, OpenRouter, die Responses API sowie Laufzeitgrenzen für Sub-Agenten wie subagents.max_total_per_run.
make up gegen make dev: Betriebsgrößen und der Port 2026
Der empfohlene Betriebsweg führt über Docker. make docker-init zieht das Sandbox-Image, make docker-start startet die Dienste, make up baut die Images und startet die Produktionsdienste, make down stoppt alles. Für die lokale Entwicklung prüft make check die Voraussetzungen Node.js 22+, pnpm, uv und nginx, danach starten make install und make dev die Dienste; der Zugriff läuft in beiden Fällen über http://localhost:2026.
Das README liefert eine Größentabelle für drei Szenarien. Die lokale Auswertung beginnt bei 4 vCPU, 8 GB RAM und 20 GB freier SSD, die Docker-Entwicklung bei 4 vCPU, 8 GB und 25 GB, langlaufende Server werden mit 8 vCPU, 16 GB und 40 GB veranschlagt. Diese Zahlen sind Richtwerte der Maintainer, keine Messergebnisse. Eine Feinheit des Betriebs: Backend-Prozesse übernehmen config.yaml-Änderungen beim nächsten Konfigurationszugriff, außer bei den Checkpoint-Speichereinstellungen, die einen Neustart verlangen. Unter Windows verläuft die lokale Entwicklung laut README über Git Bash; cmd.exe und PowerShell werden für die bash-basierten Skripte nicht unterstützt.
Skills als Markdown und allowed-tools: das Fähigkeitsmodell von DeerFlow
Eine Standard-Agent-Fähigkeit ist laut README eine Markdown-Datei, die einen Workflow, bewährte Vorgehensweisen und Referenzen definiert. Mitgeliefert werden Fähigkeiten für Forschung, Berichte, Folien, Webseiten sowie Bild- und Videogenerierung. Die Fähigkeiten werden progressiv geladen, damit das Kontextfenster schlank bleibt; die genaue Zahl der eingebauten Fähigkeiten nennt das README nicht.
Wichtig für die Sicherheitsbewertung ist die Greifweise der allowed-tools-Richtlinie. Sie greift erst, nachdem eine Fähigkeit per Slash-Befehl aktiviert oder über read_file geladen wurde; das bloße Auflisten einer Fähigkeit verkleinert das normale Werkzeugset des Agenten nicht. Das README nennt dieses Verhalten ausdrücklich eine Best-Effort-Abgrenzung und keine harte Sicherheitsgrenze. Ergänzt wird das Modell durch Sub-Agenten, Sitzungsziele, manuelle Kontextverdichtung, Langzeitspeicher und ein Dateisystem; die Einbindung von Claude Code ist als eigene Integration dokumentiert, und ein Terminal-Workbench in Form einer TUI sowie ein eingebetteter Python-Client und geplante Aufgaben runden die Bedienoberflächen ab.
LangSmith, Langfuse und Monocle: Tracing in DeerFlow konfigurieren
Drei Tracer sind integriert und können laut README gleichzeitig laufen. LangSmith und Langfuse aktivieren sich über Umgebungsvariablen wie LANGSMITH_TRACING, LANGSMITH_API_KEY, LANGFUSE_TRACING und LANGFUSE_PUBLIC_KEY. Jeder Agentenlauf wird in Langfuse mit reservierten Attributen annotiert: session_id aus der thread_id, user_id aus get_effective_user_id(), trace_name mit der Assistant-ID, Tags für Umgebung und Modell sowie metadata.deerflow_trace_id.
Monocle verfolgt einen OpenTelemetry-Ansatz und zeichnet LLM-Aufrufe, Agentenschritte sowie Tool- und MCP-Aufrufe mit Eingaben, Ausgaben, Zeitmessungen und Tokenzahlen auf. Der zugehörige Warnhinweis verdient Beachtung: Monocle-Spuren erfassen Eingaben und Ausgaben wörtlich, deshalb sollten entfernte Exporteure nur für vertrauenswürdige Ziele eingeschaltet werden. Damit stellt das Projekt selbst klar, dass die Beobachtbarkeit in den Unternehmenskontext gehört, nicht in beliebige Umgebungen.
Telegram bis DingTalk: IM-Kanäle und die Lark-Vertrauensgrenze
DeerFlow koppelt an Nachrichtendienste an, laut README für Telegram, Slack, Feishu/Lark, WeChat, WeCom und DingTalk, wahlweise mit Long-Polling oder WebSocket und ohne öffentliche IP. Im Kanal stehen Befehle wie /new, /status, /models, /memory und /help bereit, und Nutzer können ihre eigenen Konten anbinden.
Eine Sonderrolle nimmt Lark ein, und das README behandelt sie ungewöhnlich offen. Der Browser erhält das Lark-App-Geheimnis nie, aber Agentenkonversationen führen lark-cli in der Sandbox aus; dafür gemountete Berechtigungsverzeichnisse sind von jedem Prozess lesbar, den der Agent startet. Die Sandbox rückt damit in die Vertrauensgrenze der Lark-Berechtigungen, ein Umstand, den Betreiber in ihre Risikobewertung aufnehmen müssen. Zusammen mit dem Sicherheitshinweis des README gegen unsachgemäße Bereitstellung, der keine vollständige Bedrohungsanalyse ersetzt, ergibt sich der realistische Rahmen: Wer IM-Kanäle und Sandbox-Werkzeuge kombiniert, sollte den erlaubten Werkzeugkreis zunächst klein halten und schrittweise erweitern.
Redaktionelles Fazit
DeerFlow 2.0 passt für Teams, die langlaufende Agentenaufgaben selbst betreiben und dabei Sandbox-Isolation, Beobachtbarkeit und Nachrichtenkopplung an Telegram oder Slack brauchen; es passt nicht für minimale Einzelplatz-Setups ohne Docker, denn der empfohlene Weg verläuft über Container und eine Größentabelle ab 4 vCPU. Vor dem Ernstbetrieb lohnt der Lauf von make doctor, das Studium von config.example.yaml einschließlich subagents.max_total_per_run und ein Sandbox-Testlauf, bevor bash access freigeschaltet wird.
Community-Notizen