--- title: "DeerFlow 2.0: Docker-Setup, Sandboxes und Memory" canonical: https://wavect.io/de/blog/deerflow-2-docker-setup-sandbox-memory/ language: de description: "DeerFlow 2.0 mit Docker einrichten: Subagenten und Sandbox-Isolation verstehen, Memory-Probleme eingrenzen und die Checkliste für den Produktivbetrieb nutzen." image: "https://wavect.io/img/blog/headers/header_deerflow-2-docker-setup-sandbox-memory.png" --- [**Zurück**](/de/blog/overview/) [![Kevin Riedl](/img/team/kevin.webp)](/de/team/kevin-riedl/) [Kevin Riedl](/de/team/kevin-riedl/) https://linkedin.com/in/wsdt 11 min Lesezeit · 28. Sep. 2026 Zuletzt geprüft 28. September 2026 [**Weiter**](/de/blog/agent-harness-engineering/) # DeerFlow 2.0: Docker-Setup, Sandboxes und Memory TL;DR DeerFlow 2.0 ist ByteDances quelloffenes Agent-Harness für Modelle, Tools, Subagenten, Skills und deren Ausführung. Für einen lokalen Docker-Test zuerst die Konfiguration erstellen und den Sandbox-Provider wählen, danach make docker-init und make docker-start ausführen. Getrennte Agentengespräche bedeuten nicht zwangsläufig getrennte Sandboxes. Persistenter Speicher beseitigt außerdem keine Token-Kosten. Ein erfolgreicher Start ist der Beginn der Prüfung, kein Nachweis der Produktionsreife. **DeerFlow 2.0 ist eine Ausführungsumgebung für Agenten, kein weiteres Modell.** Entscheidend ist, ob sich damit Tools, Dateien und spezialisierte Agenten mit weniger eigener Integrationsarbeit koordinieren lassen, ohne überprüfbare Grenzen aufzugeben. Das [offizielle ByteDance-Repository](https://github.com/bytedance/deer-flow) beschreibt Version 2 als vollständige Neuentwicklung und nicht als kleines Update des früheren Deep-Research-Systems. **Stand der Prüfung:** Dieser Beitrag untersucht die öffentliche Dokumentation und Implementierung des 2.x-Branches `main` am 28. September 2026. Er ist weder eine Meldung vom Veröffentlichungstag noch ein praktischer Installationstest oder ein reproduzierter Leistungsbenchmark. Spätere Revisionen und ältere 2.0-Stände können abweichen. Deshalb vor der Umsetzung den Commit festhalten. ## Was orchestriert DeerFlow tatsächlich? DeerFlow vereint Agentenlaufzeit, Tool-Ausführung, Arbeitsdateien und wiederverwendbare Skills in einem System auf Basis von LangGraph und LangChain. Die [Architekturdokumentation](https://github.com/bytedance/deer-flow/blob/main/backend/docs/ARCHITECTURE.md) beschreibt die Agenten-Middleware und dateibasierte `SKILL.md`-Erweiterungen. DeerFlow ersetzt LangGraph nicht, sondern stellt darauf aufbauend eine stärker integrierte Ausführungsumgebung bereit. Unsere Einschätzung: Eine Evaluierung lohnt sich, wenn eine Aufgabe recherchieren, Dateien prüfen, Code ausführen und über mehrere Schritte ein überprüfbares Ergebnis erstellen muss. Weniger überzeugend ist der zusätzliche Aufwand, wenn ein festes Skript oder ein gewöhnlicher Workflow mit Warteschlange das Problem bereits löst. Die grundsätzliche Auswahl behandelt unser [Leitfaden zu Agent-Harness-Engineering](/de/blog/agent-harness-engineering/). Hier geht es gezielt um den Betrieb von DeerFlow. Ein Harness kann Koordinationscode reduzieren. Das Team muss dennoch festlegen, was Erfolg bedeutet, welche Aktionen eine Freigabe benötigen, welche Daten an ein Modell gehen dürfen und wer Fehler bearbeitet. Sinnvoller Einstieg ist ein begrenzter Workflow, nicht ein universeller Assistent mit Zugriff auf sämtliche Unternehmenssysteme. ## DeerFlow 2.0 mit Docker einrichten: die fehlenden Schritte **Klonen und Starten ist noch keine vollständige Ersteinrichtung.** Für die folgenden Befehle werden Git, Make, Python 3, eine geeignete Shell, eine laufende Docker-Engine und Docker Compose benötigt. Die geprüfte Upstream-Anleitung verlangt Compose ab Version 2.24. Konfigurationsbeispiele sollten aus demselben Checkout stammen, nicht aus einem älteren Blogbeitrag. ### 1. Upstream-Repository klonen und Konfiguration erstellen ``` set -eu git clone https://github.com/bytedance/deer-flow.git cd deer-flow git rev-parse HEAD docker compose version make config ``` Den ausgegebenen Commit-Hash in den Evaluierungsnotizen aufbewahren. Das [Skript zur Konfigurationserstellung](https://github.com/bytedance/deer-flow/blob/main/scripts/configure.py) legt `config.yaml`, `.env` und `frontend/.env` aus den Beispieldateien an. Existiert bereits eine Konfiguration im Projektstamm, bricht es ab. Das ist kein Anlass, eine funktionierende Datei zu löschen. Stattdessen sichern und den Upgrade-Pfad des Repositorys prüfen. ### 2. Ein echtes Modell konfigurieren und die Task-Sandbox wählen Die erzeugten Dateien vor dem Start bearbeiten. Mindestens ein unterstütztes Modell mit tatsächlichen Provider-Zugangsdaten einrichten und die Anforderungen der Frontend-Umgebung prüfen. Geheimnisse gehören weder in Commits noch in gemeinsam genutzte Diagnoseausgaben. Platzhalter für Modellnamen oder Schlüssel machen aus einem plausiblen Beispiel noch keine lauffähige Konfiguration. Für einen Test mit AIO-Containern den bestehenden `sandbox:`-Block in `config.yaml` durch diese minimale Auswahl ersetzen. Keinen zweiten gleichnamigen YAML-Schlüssel anhängen: ``` sandbox: use: deerflow.community.aio_sandbox:AioSandboxProvider ``` Der [Leitfaden zur Sandbox-Konfiguration](https://github.com/bytedance/deer-flow/blob/main/backend/docs/CONFIGURATION.md) unterscheidet den lokalen Provider von der Ausführung in AIO-Containern. Dass die DeerFlow-Anwendung in Docker läuft, wählt noch keine isolierte Task-Sandbox aus. Dieses Beispiel ist für lokale AIO-Container gedacht, nicht für einen bereits eingerichteten entfernten Provisioner. Bestehende Provider-Einstellungen vor einer Änderung prüfen. ### 3. Image initialisieren und den Entwicklungsstack starten ``` make docker-init make docker-start ``` Anschließend `http://localhost:2026` öffnen. Das geprüfte [Makefile](https://github.com/bytedance/deer-flow/blob/main/Makefile) ordnet `make docker-start` dem Docker-Entwicklungsbetrieb zu. Diesen Stack mit `make docker-stop` beenden. Der separate Produktionspfad lautet `make up`, ergänzt durch `make prod-logs` und `make down`. Ein Produktionsbefehl ist keine Sicherheitszertifizierung. Für die Diagnose im Entwicklungsbetrieb: ``` make docker-logs ``` Vor einem echten Workflow einen synthetischen Funktionstest ausführen: eine kleine CSV mit den Werten 2 und 3 hochladen, die Summe mit dem Code-Tool berechnen lassen und eine gespeicherte Ergebnisdatei mit dem Wert 5 verlangen. Datei und Tool-Protokoll unabhängig prüfen. Eine Chatantwort wie „erledigt“ beweist weder die Code-Ausführung noch die Verfügbarkeit eines Artefakts. ## Startprobleme eingrenzen, bevor Berechtigungen erweitert werden Die [Upstream-Einrichtungsanleitung](https://github.com/bytedance/deer-flow/blob/main/backend/docs/SETUP.md) erwartet `config.yaml` im Projektstamm und dokumentiert Laufzeitdaten unter `.deer-flow` beziehungsweise einem über `DEER_FLOW_HOME` festgelegten Ort. Zuerst Pfade und eingebundene Konfiguration prüfen, statt jeden Fehler dem Modell zuzuschreiben. Die folgende Tabelle empfiehlt eine Diagnosereihenfolge; sie behauptet nicht, dass diese Fehler bei jeder Installation auftreten. | Symptom | Zuerst prüfen | Diese Abkürzung vermeiden | | --- | --- | --- | | Konfiguration fehlt oder wird abgelehnt | Projektstamm, tatsächlich eingebundene Datei, gültiges YAML und Kompatibilität mit dem ausgecheckten Beispiel. | Funktionierende Konfiguration löschen oder oberste Schlüssel doppelt einfügen. | | Oberfläche lädt, Modellaufruf scheitert | Modellkennung, Endpunkt, Zugangsdaten, Provider-Zugriff und Gateway-Logs. | Eine erreichbare Oberfläche als Nachweis einer funktionierenden Modellkonfiguration betrachten. | | Shell-Ausführung scheitert | Gewählten Sandbox-Provider, verfügbares Image und Container-Verbindung des Providers. | Uneingeschränkte lokale Shell-Ausführung aktivieren, nur damit die Fehlermeldung verschwindet. | | Erste Code-Aufgabe scheint zu hängen | Fortschritt des Image-Downloads, Container-Start und Hinweise auf Tool-Zeitüberschreitungen. | Dieselbe teure Aufgabe ohne Log-Prüfung wiederholt absenden. | | Ergebnisse fehlen nach einem Neustart | Konfigurierte Zustands-Backends, persistente Mounts, Identitäten und Artefaktpfade. | Annehmen, dass jede Komponente im Arbeitsspeicher dauerhaft gespeichert wird. | ## Sind DeerFlow-Subagenten voneinander isoliert? **Getrennter Gesprächskontext bedeutet keinen getrennten Container.** Der geprüfte [Subagenten-Executor](https://github.com/bytedance/deer-flow/blob/main/backend/packages/harness/deerflow/subagents/executor.py) kann die Sandbox des übergeordneten Agenten in die delegierte Ausführung übernehmen. Agenten in derselben Sandbox sind daher als Teilnehmer an einem gemeinsamen Dateisystem zu behandeln, auch bei getrennten Gesprächsverläufen. Ein frischer Modellkontext ist keine Sicherheitsgrenze zwischen Mandanten. Die aktuelle [Implementierung des AIO-Providers](https://github.com/bytedance/deer-flow/blob/main/backend/packages/harness/deerflow/community/aio_sandbox/aio_sandbox_provider.py) ordnet Sandboxes anhand von Benutzer- und Thread-Identität zu. Ist `provisioner_url` gesetzt, wird ein entferntes Backend gewählt; andernfalls das lokale Container-Backend. Daraus folgt in keinem Fall automatisch ein unabhängiger Container für jeden spezialisierten Subagenten. Für den ersten Workflow jedem parallelen Zweig einen eigenen Ausgabedateinamen geben, Quelldateien soweit unterstützt schreibgeschützt bereitstellen und die Verantwortung für den Abschlussbericht einem Syntheseschritt zuweisen. Prüfen, ob ein Zweig Dateien eines anderen überschreiben kann. Bei getrennten Kunden zählen serverseitig abgeleitete Identität, Autorisierung und Speichergrenzen, nicht Kundennamen im Prompt. Der lokale Provider ist eine andere Betriebsform: Er führt Aufgaben in der Anwendungsumgebung aus, statt einen zusätzlichen Task-Container zu erzeugen. Eine deaktivierte lokale Shell nicht beiläufig freigeben. Unser [OpenSandbox-Review](/de/blog/opensandbox-ai-agent-sandbox-review/) behandelt Sandbox-Infrastruktur separat. Sandbox-Provider und vollständiges Agent-Harness lösen unterschiedliche Ebenen des Problems. ## Wie DeerFlow Memory funktioniert und warum Tokens trotzdem zählen Drei Dinge auseinanderhalten: das aktuelle Gespräch, wiederverwendbare Erinnerungen über Gespräche hinweg und den Laufzeitzustand zum Fortsetzen von Arbeit. Die [gemeinsame Memory-Konfiguration](https://github.com/bytedance/deer-flow/blob/main/backend/packages/harness/deerflow/config/memory_config.py) trennt Aktivierung, Einblendung in Prompts und Backend-Auswahl. „Memory ist aktiviert“ beweist deshalb weder, dass neue Fakten extrahiert werden, noch dass jeder unvollständige Lauf einen Neustart übersteht. Im geprüften [Konfigurationsbeispiel](https://github.com/bytedance/deer-flow/blob/main/config.example.yaml) liegt DeerMems `max_injection_tokens` unter `memory.backend_config`; der Beispielwert beträgt 2000. Das Extraktionsmodell wird separat konfiguriert. Ohne dessen Einstellungen steht automatische Extraktion nicht zur Verfügung, während Memory-Vorgänge ohne LLM weiterhin funktionieren können. Maßgeblich ist die tatsächlich geladene Konfiguration der eingesetzten Revision. Gesprächskomprimierung ist ein weiterer Mechanismus. Die [Summarization-Middleware](https://github.com/bytedance/deer-flow/blob/main/backend/packages/harness/deerflow/agents/middlewares/summarization_middleware.py) stellt diese Ebene bereit; sie ist nicht gleichbedeutend mit dauerhaftem fachlichem Gedächtnis. Zusammenfassungen können Details verlieren, und zusätzlicher Modellkontext verbraucht weiterhin Kapazität. Aus „begrenzter Einblendung“ wird kein „unbegrenzter Speicher ohne Token-Kosten“. Unser empfohlener Memory-Test besteht aus drei Teilen. Eine harmlose Präferenz speichern, unter derselben Identität ein neues Gespräch beginnen und den Abruf prüfen. Danach die Präferenz korrigieren und kontrollieren, dass sich der alte Wert nicht weiterhin durchsetzt. Abschließend mit einer anderen Testidentität wiederholen und prüfen, dass die Präferenz dort nicht verfügbar ist. Neben der Antwort auch Logs und Speicher untersuchen. Den tatsächlichen Prompt und die gesamte Provider-Nutzung erfassen. Steigen die Kosten ohne bessere akzeptierte Ergebnisse, weniger Inhalt einblenden oder den Workflow enger fassen. Fehlt dem vorhandenen Agentenstack lediglich eine Memory-Schicht, diese engere Anforderung mit unserem [OpenViking-Memory-Review](/de/blog/openviking-agent-memory-review/) abgleichen, statt standardmäßig den gesamten Stack auszutauschen. ## Eigene DeerFlow-Skills: Verfahren statt Berechtigungen Ein sinnvoller erster Skill beschreibt einen wiederholbaren Ergebnisvertrag, nicht den Auftrag zu allgemeiner Autonomie. Das folgende Beispiel nutzt das oben beschriebene Dateiformat für einen `SKILL.md`-Inhalt zu einem quellenbasierten Anbieterbriefing. Den Skill nach den Erkennungs- und Freigaberegeln des eigenen Checkouts integrieren und testen. Dies ist kein praktisch geprüftes Plugin-Paket. ``` --- name: vendor-evidence-brief description: Prepare a source-linked vendor brief for human review. --- Use only the approved input documents and permitted sources. Record a source URL or input filename for each factual claim. Mark missing evidence as unknown; never invent a reference. Write research branches to separate output files. Produce a draft, not an approval or a published report. Do not send messages, change accounts, or execute payments. ``` Die Unterscheidung ist entscheidend: „Keine Nachrichten senden“ ist eine Anweisung, keine technisch erzwungene Sperre des Nachrichtenzugriffs. Einschränkungen müssen durch die verfügbaren Tools und Zugangsdaten durchgesetzt werden. Fremde Skill-Dateien, mitgelieferte Skripte und Abhängigkeiten als prüfpflichtigen Code beziehungsweise prüfpflichtige Anweisungen behandeln, nicht als automatisch vertrauenswürdige Erweiterungen. Wiederverwendbare Verfahren gehören in den Skill, aufgabenspezifische Fakten in die Eingaben. So lassen sich Skills leichter prüfen, zwischen Revisionen vergleichen und mit erfolgreichen wie bösartigen Beispielen testen. Echte Kundengeheimnisse gehören nicht in wiederverwendbare Anweisungen. ## Ein begrenzter Workflow: von Anbieterrecherche zum belegten Entwurf **Dies ist ein vorgeschlagener Pilotaufbau, kein Bericht über ein DeerFlow-Kundenprojekt.** Mit drei freigegebenen Anbieterdokumenten und einer festen Frage beginnen: Welche Optionen erfüllen eine definierte technische Anforderung? Das Ergebnis auf einen Vergleichsentwurf und eine Evidenzdatei beschränken. Keine Einkaufs-, Zahlungs- oder ausgehenden E-Mail-Aktionen anbinden. | Schritt | Erwartetes Artefakt | Abnahmeprüfung | | --- | --- | --- | | Eingaben vorbereiten | Freigegebene Dateien und ausdrückliche Vergleichskriterien. | Keine unnötigen Geheimnisse in den Eingaben; Umfang und erlaubte Quellen sind festgehalten. | | Parallel recherchieren | Eine eigene Evidenzdatei je Anbieter. | Jede Faktenzeile verweist auf eine Eingabedatei oder erlaubte Quell-URL. Unbekanntes bleibt unbekannt. | | Ergebnisse zusammenführen | Ein Vergleichsentwurf mit Einschränkungen. | Aussagen sind auf Evidenzdateien zurückführbar. Fehlende Belege gelten weder als Erfüllung noch als Nichterfüllung. | | Unabhängig validieren | Ein strukturiertes Prüfergebnis. | Erforderliche Dateien existieren, maschinenlesbare Ausgaben lassen sich parsen und Stichproben stimmen mit Quellen überein. | | Menschlich freigeben | Ein freigegebener oder abgelehnter Entwurf. | Eine benannte Person entscheidet, ob Inhalte geteilt oder Maßnahmen ausgelöst werden dürfen. | Eine absichtlich widersprüchliche Quelle, ein fehlendes Dokument und einen unterbrochenen Lauf in den Abnahmesatz aufnehmen. Das System muss Unsicherheit offenlegen, statt eine widerspruchsfreie Antwort zu erfinden. Liefert ein einfacher Einzelagent bessere Ergebnisse, bleibt er die richtige Wahl. Zusätzliche Subagenten sind eine Implementierungsoption, keine Erfolgskennzahl. ## DeerFlow-Produktionscheckliste: Was muss nachgewiesen werden? Ältere Beschreibungen ohne Authentifizierung sollten nicht als aktueller Stand übernommen werden. Das geprüfte [Authentifizierungsdesign](https://github.com/bytedance/deer-flow/blob/main/backend/docs/AUTH_DESIGN.md) enthält eine Ersteinrichtung und die Verarbeitung authentifizierter Benutzer. Das erste Administratorkonto über den lokalen `/setup`-Ablauf einrichten, bevor andere Personen den Dienst erreichen können. Anschließend Autorisierung mit getrennten Konten testen. Die geprüfte [Compose-Datei für den Produktivbetrieb](https://github.com/bytedance/deer-flow/blob/main/docker/docker-compose.yaml) bindet den veröffentlichten Einstiegspunkt standardmäßig an `127.0.0.1` und verlangt `BETTER_AUTH_SECRET`. Während der Evaluierung die Loopback-Bindung beibehalten. Öffentlicher Zugriff sollte einer bewussten Deployment-Prüfung folgen, nicht einer beiläufigen Änderung von `BIND_HOST`. Die folgenden Punkte sind vorgeschlagene Freigabekriterien. Sie bedeuten nicht, dass DeerFlow jede Kontrolle bereits mitliefert oder aktiviert. | Kontrolle | Zu erhebender Nachweis | | --- | --- | | Identität und Berechtigungen | Ein Benutzer kann keine Threads, Dateien oder Erinnerungen anderer abrufen. Privilegierte Aktionen verlangen eine ausdrücklich autorisierte Identität. | | Laufzeitabschottung | Mounts, ausgehenden Netzwerkzugriff, Geheimnisse und Ressourcenlimits prüfen. Nutzt AIO den Docker-Socket des Hosts, diesen privilegierten Steuerungspfad gesondert bewerten. | | Persistenz und Wiederherstellung | Während eines Laufs neu starten, erneut verbinden und den Zustand prüfen. Backup-Wiederherstellung testen; Wiederholungen dürfen externe Aktionen nicht doppelt auslösen. | | Kosten und Abbruch | Ausgabenlimits, Fristen, Abbruchverhalten und Grenzen paralleler Arbeit anhand repräsentativer Fehlerfälle nachweisen. | | Vertrauen in Skills und Tools | Ausführbare Erweiterungen, MCP-Launcher und Skill-Änderungen prüfen. Nicht vertrauenswürdige Inhalte dürfen keine administrative Tool-Autorität erlangen. | | Verantwortung für Updates | Anwendungs- und Image-Revisionen festschreiben, bereinigte Protokolle aufbewahren, Abnahmetests erneut ausführen und Rollback mit einem benannten Betreiber nachweisen. | Für die abschließende Freigabe unsere [Software-QA-Checkliste vor dem Launch](/de/software-development-guide/software-qa-checklist-before-launch/) als übergreifende Liefercheckliste verwenden und die agentenspezifischen Fälle ergänzen. Eine erfolgreiche Standarddemonstration reicht nicht als Nachweis für Kontenänderungen, Zahlungen oder andere irreversible Aktionen. ## Lohnt sich DeerFlow für den eigenen Anwendungsfall? Gemessen werden sollten **Kosten pro akzeptierter Aufgabe = (gesamte Modellkosten + gesamte Tool-Kosten + gesamte Laufzeitkosten + Kosten menschlicher Prüfung) / akzeptierte Aufgaben**. Einheitliche Rechnungseinheiten verwenden, Fehlversuche in diesen Gesamtkosten erfassen, Memory-Extraktion und delegierte Aufrufe einbeziehen und dieselben Aufgaben mit dem bisherigen Ansatz vergleichen. Zusätzlich Dauer, Korrekturen, Wiederherstellungsquote und blockierte unsichere Aktionen erfassen. Wird keine Aufgabe akzeptiert, diesen Fehlschlag offen ausweisen statt einen irreführenden Durchschnitt zu bilden. Ein DeerFlow-Pilot passt, wenn eine integrierte Ausführungsumgebung tatsächlich eigene Orchestrierungsarbeit reduzieren könnte. Ein kleineres Framework oder ein deterministischer Workflow bleibt sinnvoll, wenn der Abnahmevertrag damit bei geringerer Betriebskomplexität erfüllt wird. Unser [LangChain-Deep-Agents-Review](/de/blog/langchain-deep-agents-review/) hilft, die schlankere Framework-Option einzuordnen. Wavects [KI-Entwicklung](/de/services/artificial-intelligence/) unterstützt bei der Abgrenzung eines Workflows sowie seiner Berechtigungen und Abnahmetests. Die [TwinSoft-AI-Fallstudie](/de/case-studies/twinsoft-ai/) zeigt angrenzende Projekterfahrung, keinen DeerFlow-Einsatz. Zur Einordnung für das eigene System [den Workflow und seine Fehlerfälle mit Wavect besprechen](/de/contact/). ## Häufige Fragen zu DeerFlow 2.0 ### Was ist DeerFlow 2.0? DeerFlow 2.0 ist ByteDances quelloffenes Agent-Harness auf Basis von LangGraph und LangChain. Es verbindet Agentenausführung, Subagenten, Tools, Sandbox-Anbindung, Memory und Skills. Es ist weder ein neues Basismodell noch eine Garantie für erfolgreiche Workflows. ### Reichen git clone und anschließend make docker-start? Nicht als vollständige Ersteinrichtung. Zuerst Konfigurations- und Umgebungsdateien vorbereiten, ein funktionierendes Modell konfigurieren, den Sandbox-Provider wählen und das Sandbox-Image initialisieren. Erst danach den Entwicklungsstack starten. ### Bekommt jeder DeerFlow-Subagent einen eigenen Docker-Container? Davon sollte man nicht ausgehen. Gesprächskontext und Sandbox sind unterschiedliche Isolationsebenen. Subagenten können die Sandbox des übergeordneten Agenten und gemeinsame Dateien verwenden. Entscheidend sind die Grenzen des tatsächlich eingesetzten Providers und Deployments. ### Warum lernt DeerFlows Memory nichts Neues? Sowohl die gemeinsamen Memory-Einstellungen als auch das gewählte Backend prüfen. Im untersuchten DeerMem-Beispiel benötigt die automatische Extraktion ein konfiguriertes Extraktionsmodell. Zusätzlich Zugangsdaten, Identitätszuordnung, Speicher und Logs kontrollieren. Bestehende Erinnerungen einzublenden und neue Fakten zu extrahieren sind getrennte Vorgänge. ### Entfallen mit DeerFlow Memory die Token-Kosten? Nein. Eingeblendete Erinnerungen, abgerufene Inhalte, Zusammenfassungen und Extraktionsaufrufe können Tokens verbrauchen. Relevant sind die Gesamtkosten pro akzeptierter Aufgabe, einschließlich Fehlversuchen und menschlicher Prüfung, nicht nur die Größe eines einzelnen Prompts. ### Kann DeerFlow produktiv eingesetzt werden? Zuerst eine festgehaltene Revision mit dem eigenen Anwendungsfall prüfen. Das Repository enthält einen separaten Docker-Produktionsstart und Authentifizierung. Getestete Berechtigungen, Persistenz, Abschottung, Wiederherstellung, Kostenkontrollen und operative Verantwortung bleiben trotzdem erforderlich. Modelle und Infrastruktur ## In diesem Cluster weiterlesen Modellauswahl, Inferenzkosten, lokaler Betrieb, Kompression und Serving-Architektur. [Mit dem Grundlagenartikel starten**LLMs in der EU selbst hosten: Wann sich Open Weights wirklich rechnen**](/de/blog/self-hosting-llms-eu-cost/) - [LiteAgents SDK: Modell-Routing, Setup und Migration](/de/blog/liteagents-sdk-per-turn-model-routing/) - [mcp-memory-service: Gemeinsames Gedächtnis für Claude Code und Cursor](/de/blog/mcp-memory-service-claude-code-cursor/) - [Claude Opus 5.5: Einsatzfälle, Prompts und Effort](/de/blog/claude-opus-5-5-best-use-cases-workflows/) - [Laya und Jev im Unternehmen: 6 praktische Workflows](/de/blog/laya-jev-business-workflows-roi/) - [Laya vs Jev: Benchmarks und das Risiko für KI-Startups](/de/blog/laya-vs-jev-benchmark-ai-startup-moat/) [**Zurück**](/de/blog/overview/) [![Kevin Riedl](/img/team/kevin.webp)](/de/team/kevin-riedl/) [Kevin Riedl](/de/team/kevin-riedl/) https://linkedin.com/in/wsdt 11 min Lesezeit · 28. Sep. 2026 Zuletzt geprüft 28. September 2026 [**Weiter**](/de/blog/agent-harness-engineering/) ## Structured Data ```json { "@context": "https://schema.org", "@graph": [ { "@id": "https://wavect.io/#organization", "@type": [ "Organization", "ProfessionalService", "LocalBusiness" ], "employee": [ { "@id": "https://wavect.io/team/kevin-riedl/#person", "@type": "Person", "jobTitle": "Managing Director", "name": "Kevin Riedl", "url": "https://wavect.io/team/kevin-riedl/", "worksFor": { "@id": "https://wavect.io/#organization", "@type": [ "Organization", "ProfessionalService", "LocalBusiness" ] } }, { "@id": "https://wavect.io/team/christof-jori/#person", "@type": "Person", "jobTitle": "Managing Director", "name": "Christof Jori", "url": "https://wavect.io/team/christof-jori/", "worksFor": { "@id": "https://wavect.io/#organization", "@type": [ "Organization", "ProfessionalService", "LocalBusiness" ] } } ], "founder": [ { "@id": "https://wavect.io/team/kevin-riedl/#person", "@type": "Person", "jobTitle": "Managing Director", "name": "Kevin Riedl", "url": "https://wavect.io/team/kevin-riedl/", "worksFor": { "@id": "https://wavect.io/#organization", "@type": [ "Organization", "ProfessionalService", "LocalBusiness" ] } }, { "@id": "https://wavect.io/team/christof-jori/#person", "@type": "Person", "jobTitle": "Managing Director", "name": "Christof Jori", "url": "https://wavect.io/team/christof-jori/", "worksFor": { "@id": "https://wavect.io/#organization", "@type": [ "Organization", "ProfessionalService", "LocalBusiness" ] } } ], "legalRepresentative": [ { "@id": "https://wavect.io/team/kevin-riedl/#person", "@type": "Person", "jobTitle": "Managing Director", "name": "Kevin Riedl", "url": "https://wavect.io/team/kevin-riedl/", "worksFor": { "@id": "https://wavect.io/#organization", "@type": [ "Organization", "ProfessionalService", "LocalBusiness" ] } }, { "@id": "https://wavect.io/team/christof-jori/#person", "@type": "Person", "jobTitle": "Managing Director", "name": "Christof Jori", "url": "https://wavect.io/team/christof-jori/", "worksFor": { "@id": "https://wavect.io/#organization", "@type": [ "Organization", "ProfessionalService", "LocalBusiness" ] } } ], "name": "Wavect GmbH", "subjectOf": { "@id": "https://wavect.io/verified-claims.json#dataset", "@type": "Dataset", "creator": { "@id": "https://wavect.io/#organization", "@type": [ "Organization", "ProfessionalService", "LocalBusiness" ] }, "description": "A machine-readable registry of quantitative and qualitative claims published by Wavect, with review dates, localized page appearances and public third-party citations where available.", "inLanguage": "en", "isAccessibleForFree": true, "license": "https://creativecommons.org/licenses/by/4.0/", "name": "Wavect verified publication claims", "url": "https://wavect.io/verified-claims.json" }, "url": "https://wavect.io/" }, { "@id": "https://wavect.io/team/kevin-riedl/#person", "@type": "Person", "jobTitle": "Managing Director", "name": "Kevin Riedl", "sameAs": [ "https://www.wikidata.org/wiki/Q139796365", "https://www.linkedin.com/in/wsdt", "https://github.com/wsdt" ], "url": "https://wavect.io/team/kevin-riedl/", "worksFor": { "@id": "https://wavect.io/#organization", "@type": [ "Organization", "ProfessionalService", "LocalBusiness" ] } }, { "@id": "https://wavect.io/team/christof-jori/#person", "@type": "Person", "jobTitle": "Managing Director", "name": "Christof Jori", "sameAs": [ "https://www.wikidata.org/wiki/Q139796367", "https://www.linkedin.com/in/jocr77/", "https://github.com/jo-chris" ], "url": "https://wavect.io/team/christof-jori/", "worksFor": { "@id": "https://wavect.io/#organization", "@type": [ "Organization", "ProfessionalService", "LocalBusiness" ] } }, { "@id": "https://wavect.io/#website", "@type": "WebSite", "inLanguage": [ "en", "de", "es", "zh" ], "name": "Wavect", "potentialAction": { "@type": "SearchAction", "query-input": "required name=search_term_string", "target": { "@type": "EntryPoint", "urlTemplate": "https://wavect.io/search/?q={search_term_string}" } }, "publisher": { "@id": "https://wavect.io/#organization", "@type": [ "Organization", "ProfessionalService", "LocalBusiness" ] }, "url": "https://wavect.io/" }, { "@id": "https://wavect.io/de/blog/deerflow-2-docker-setup-sandbox-memory/#webpage", "@type": "WebPage", "dateModified": "2026-09-28", "inLanguage": "de", "isPartOf": { "@id": "https://wavect.io/#website", "@type": "WebSite" }, "lastReviewed": "2026-09-28", "url": "https://wavect.io/de/blog/deerflow-2-docker-setup-sandbox-memory/" } ] } ``` ```json { "@context": "https://schema.org", "@type": "BlogPosting", "abstract": "DeerFlow 2.0 ist ByteDances quelloffenes Agent-Harness für Modelle, Tools, Subagenten, Skills und deren Ausführung. Für einen lokalen Docker-Test zuerst die Konfiguration erstellen und den Sandbox-Provider wählen, danach make docker-init und make docker-start ausführen. Getrennte Agentengespräche bedeuten nicht zwangsläufig getrennte Sandboxes. Persistenter Speicher beseitigt außerdem keine Token-Kosten. Ein erfolgreicher Start ist der Beginn der Prüfung, kein Nachweis der Produktionsreife.", "articleBody": " Blog-Übersicht/AI und Agents/Modelle und Infrastruktur DeerFlow 2.0: Docker-Setup, Sandboxes und Memory TL;DR DeerFlow 2.0 ist ByteDances quelloffenes Agent-Harness für Modelle, Tools, Subagenten, Skills und deren Ausführung. Für einen lokalen Docker-Test zuerst die Konfiguration erstellen und den Sandbox-Provider wählen, danach make docker-init und make docker-start ausführen. Getrennte Agentengespräche bedeuten nicht zwangsläufig getrennte Sandboxes. Persistenter Speicher beseitigt außerdem keine Token-Kosten. Ein erfolgreicher Start ist der Beginn der Prüfung, kein Nachweis der Produktionsreife. DeerFlow 2.0 ist eine Ausführungsumgebung für Agenten, kein weiteres Modell. Entscheidend ist, ob sich damit Tools, Dateien und spezialisierte Agenten mit weniger eigener Integrationsarbeit koordinieren lassen, ohne überprüfbare Grenzen aufzugeben. Das offizielle ByteDance-Repository beschreibt Version 2 als vollständige Neuentwicklung und nicht als kleines Update des früheren Deep-Research-Systems. Stand der Prüfung: Dieser Beitrag untersucht die öffentliche Dokumentation und Implementierung des 2.x-Branches main am 28. September 2026. Er ist weder eine Meldung vom Veröffentlichungstag noch ein praktischer Installationstest oder ein reproduzierter Leistungsbenchmark. Spätere Revisionen und ältere 2.0-Stände können abweichen. Deshalb vor der Umsetzung den Commit festhalten. Was orchestriert DeerFlow tatsächlich? DeerFlow vereint Agentenlaufzeit, Tool-Ausführung, Arbeitsdateien und wiederverwendbare Skills in einem System auf Basis von LangGraph und LangChain. Die Architekturdokumentation beschreibt die Agenten-Middleware und dateibasierte SKILL.md-Erweiterungen. DeerFlow ersetzt LangGraph nicht, sondern stellt darauf aufbauend eine stärker integrierte Ausführungsumgebung bereit. Unsere Einschätzung: Eine Evaluierung lohnt sich, wenn eine Aufgabe recherchieren, Dateien prüfen, Code ausführen und über mehrere Schritte ein überprüfbares Ergebnis erstellen muss. Weniger überzeugend ist der zusätzliche Aufwand, wenn ein festes Skript oder ein gewöhnlicher Workflow mit Warteschlange das Problem bereits löst. Die grundsätzliche Auswahl behandelt unser Leitfaden zu Agent-Harness-Engineering. Hier geht es gezielt um den Betrieb von DeerFlow. Ein Harness kann Koordinationscode reduzieren. Das Team muss dennoch festlegen, was Erfolg bedeutet, welche Aktionen eine Freigabe benötigen, welche Daten an ein Modell gehen dürfen und wer Fehler bearbeitet. Sinnvoller Einstieg ist ein begrenzter Workflow, nicht ein universeller Assistent mit Zugriff auf sämtliche Unternehmenssysteme. DeerFlow 2.0 mit Docker einrichten: die fehlenden Schritte Klonen und Starten ist noch keine vollständige Ersteinrichtung. Für die folgenden Befehle werden Git, Make, Python 3, eine geeignete Shell, eine laufende Docker-Engine und Docker Compose benötigt. Die geprüfte Upstream-Anleitung verlangt Compose ab Version 2.24. Konfigurationsbeispiele sollten aus demselben Checkout stammen, nicht aus einem älteren Blogbeitrag. 1. Upstream-Repository klonen und Konfiguration erstellen set -eu git clone https://github.com/bytedance/deer-flow.git cd deer-flow git rev-parse HEAD docker compose version make config Den ausgegebenen Commit-Hash in den Evaluierungsnotizen aufbewahren. Das Skript zur Konfigurationserstellung legt config.yaml, .env und frontend/.env aus den Beispieldateien an. Existiert bereits eine Konfiguration im Projektstamm, bricht es ab. Das ist kein Anlass, eine funktionierende Datei zu löschen. Stattdessen sichern und den Upgrade-Pfad des Repositorys prüfen. 2. Ein echtes Modell konfigurieren und die Task-Sandbox wählen Die erzeugten Dateien vor dem Start bearbeiten. Mindestens ein unterstütztes Modell mit tatsächlichen Provider-Zugangsdaten einrichten und die Anforderungen der Frontend-Umgebung prüfen. Geheimnisse gehören weder in Commits noch in gemeinsam genutzte Diagnoseausgaben. Platzhalter für Modellnamen oder Schlüssel machen aus einem plausiblen Beispiel noch keine lauffähige Konfiguration. Für einen Test mit AIO-Containern den bestehenden sandbox:-Block in config.yaml durch diese minimale Auswahl ersetzen. Keinen zweiten gleichnamigen YAML-Schlüssel anhängen: sandbox: use: deerflow.community.aio_sandbox:AioSandboxProvider Der Leitfaden zur Sandbox-Konfiguration unterscheidet den lokalen Provider von der Ausführung in AIO-Containern. Dass die DeerFlow-Anwendung in Docker läuft, wählt noch keine isolierte Task-Sandbox aus. Dieses Beispiel ist für lokale AIO-Container gedacht, nicht für einen bereits eingerichteten entfernten Provisioner. Bestehende Provider-Einstellungen vor einer Änderung prüfen. 3. Image initialisieren und den Entwicklungsstack starten make docker-init make docker-start Anschließend http://localhost:2026 öffnen. Das geprüfte Makefile ordnet make docker-start dem Docker-Entwicklungsbetrieb zu. Diesen Stack mit make docker-stop beenden. Der separate Produktionspfad lautet make up, ergänzt durch make prod-logs und make", "articleSection": "KI-Engineering", "author": { "@id": "https://wavect.io/team/kevin-riedl/#person", "@type": "Person", "name": "Kevin Riedl", "sameAs": [ "https://www.wikidata.org/wiki/Q139796365", "https://www.linkedin.com/in/wsdt", "https://github.com/wsdt" ], "url": "https://wavect.io/team/kevin-riedl/" }, "citation": [ { "@type": "WebPage", "name": "offizielle ByteDance-Repository", "url": "https://github.com/bytedance/deer-flow" }, { "@type": "WebPage", "name": "Architekturdokumentation", "url": "https://github.com/bytedance/deer-flow/blob/main/backend/docs/ARCHITECTURE.md" }, { "@type": "WebPage", "name": "Skript zur Konfigurationserstellung", "url": "https://github.com/bytedance/deer-flow/blob/main/scripts/configure.py" }, { "@type": "WebPage", "name": "Leitfaden zur Sandbox-Konfiguration", "url": "https://github.com/bytedance/deer-flow/blob/main/backend/docs/CONFIGURATION.md" }, { "@type": "WebPage", "name": "Makefile", "url": "https://github.com/bytedance/deer-flow/blob/main/Makefile" }, { "@type": "WebPage", "name": "Upstream-Einrichtungsanleitung", "url": "https://github.com/bytedance/deer-flow/blob/main/backend/docs/SETUP.md" }, { "@type": "WebPage", "name": "Subagenten-Executor", "url": "https://github.com/bytedance/deer-flow/blob/main/backend/packages/harness/deerflow/subagents/executor.py" }, { "@type": "WebPage", "name": "Implementierung des AIO-Providers", "url": "https://github.com/bytedance/deer-flow/blob/main/backend/packages/harness/deerflow/community/aio_sandbox/aio_sandbox_provider.py" }, { "@type": "WebPage", "name": "gemeinsame Memory-Konfiguration", "url": "https://github.com/bytedance/deer-flow/blob/main/backend/packages/harness/deerflow/config/memory_config.py" }, { "@type": "WebPage", "name": "Konfigurationsbeispiel", "url": "https://github.com/bytedance/deer-flow/blob/main/config.example.yaml" }, { "@type": "WebPage", "name": "Summarization-Middleware", "url": "https://github.com/bytedance/deer-flow/blob/main/backend/packages/harness/deerflow/agents/middlewares/summarization_middleware.py" }, { "@type": "WebPage", "name": "Authentifizierungsdesign", "url": "https://github.com/bytedance/deer-flow/blob/main/backend/docs/AUTH_DESIGN.md" }, { "@type": "WebPage", "name": "Compose-Datei für den Produktivbetrieb", "url": "https://github.com/bytedance/deer-flow/blob/main/docker/docker-compose.yaml" } ], "dateModified": "2026-09-28", "datePublished": "2026-09-28", "description": "DeerFlow 2.0 ist ByteDances quelloffenes Agent-Harness für Modelle, Tools, Subagenten, Skills und deren Ausführung. Für einen lokalen Docker-Test zuerst die Konfiguration erstellen und den Sandbox-Provider wählen, danach make docker-init und make docker-start ausführen. Getrennte Agentengespräche bedeuten nicht zwangsläufig getrennte Sandboxes. Persistenter Speicher beseitigt außerdem keine Token-Kosten. Ein erfolgreicher Start ist der Beginn der Prüfung, kein Nachweis der Produktionsreife.", "headline": "DeerFlow 2.0: Docker-Setup, Sandboxes und Memory", "image": "https://wavect.io/img/blog/headers/header_deerflow-2-docker-setup-sandbox-memory.svg", "inLanguage": "de", "keywords": "DeerFlow 2.0, Docker-Einrichtung, Agent-Harness", "mainEntityOfPage": { "@id": "https://wavect.io/de/blog/deerflow-2-docker-setup-sandbox-memory/", "@type": "WebPage" }, "publisher": { "@id": "https://wavect.io/#organization", "@type": [ "Organization", "ProfessionalService", "LocalBusiness" ] }, "url": "https://wavect.io/de/blog/deerflow-2-docker-setup-sandbox-memory/", "wordCount": 2432 } ``` ```json { "@context": "https://schema.org", "@type": "BreadcrumbList", "itemListElement": [ { "@type": "ListItem", "item": "https://wavect.io/de/", "name": "Startseite", "position": 1 }, { "@type": "ListItem", "item": "https://wavect.io/de/blog/overview/", "name": "Blog-Übersicht", "position": 2 }, { "@type": "ListItem", "item": "https://wavect.io/de/blog/topics/ai-agents/", "name": "AI und Agents", "position": 3 }, { "@type": "ListItem", "item": "https://wavect.io/de/blog/clusters/models-infrastructure/", "name": "Modelle und Infrastruktur", "position": 4 }, { "@type": "ListItem", "item": "https://wavect.io/de/blog/deerflow-2-docker-setup-sandbox-memory/", "name": "DeerFlow 2.0: Docker-Setup, Sandboxes und Memory", "position": 5 } ] } ``` ```json { "@context": "https://schema.org", "@type": "FAQPage", "mainEntity": [ { "@type": "Question", "acceptedAnswer": { "@type": "Answer", "text": "DeerFlow 2.0 ist ByteDances quelloffenes Agent-Harness auf Basis von LangGraph und LangChain. Es verbindet Agentenausführung, Subagenten, Tools, Sandbox-Anbindung, Memory und Skills. Es ist weder ein neues Basismodell noch eine Garantie für erfolgreiche Workflows." }, "name": "Was ist DeerFlow 2.0?" }, { "@type": "Question", "acceptedAnswer": { "@type": "Answer", "text": "Nicht als vollständige Ersteinrichtung. Zuerst Konfigurations- und Umgebungsdateien vorbereiten, ein funktionierendes Modell konfigurieren, den Sandbox-Provider wählen und das Sandbox-Image initialisieren. Erst danach den Entwicklungsstack starten." }, "name": "Reichen git clone und anschließend make docker-start?" }, { "@type": "Question", "acceptedAnswer": { "@type": "Answer", "text": "Davon sollte man nicht ausgehen. Gesprächskontext und Sandbox sind unterschiedliche Isolationsebenen. Subagenten können die Sandbox des übergeordneten Agenten und gemeinsame Dateien verwenden. Entscheidend sind die Grenzen des tatsächlich eingesetzten Providers und Deployments." }, "name": "Bekommt jeder DeerFlow-Subagent einen eigenen Docker-Container?" }, { "@type": "Question", "acceptedAnswer": { "@type": "Answer", "text": "Sowohl die gemeinsamen Memory-Einstellungen als auch das gewählte Backend prüfen. Im untersuchten DeerMem-Beispiel benötigt die automatische Extraktion ein konfiguriertes Extraktionsmodell. Zusätzlich Zugangsdaten, Identitätszuordnung, Speicher und Logs kontrollieren. Bestehende Erinnerungen einzublenden und neue Fakten zu extrahieren sind getrennte Vorgänge." }, "name": "Warum lernt DeerFlows Memory nichts Neues?" }, { "@type": "Question", "acceptedAnswer": { "@type": "Answer", "text": "Nein. Eingeblendete Erinnerungen, abgerufene Inhalte, Zusammenfassungen und Extraktionsaufrufe können Tokens verbrauchen. Relevant sind die Gesamtkosten pro akzeptierter Aufgabe, einschließlich Fehlversuchen und menschlicher Prüfung, nicht nur die Größe eines einzelnen Prompts." }, "name": "Entfallen mit DeerFlow Memory die Token-Kosten?" }, { "@type": "Question", "acceptedAnswer": { "@type": "Answer", "text": "Zuerst eine festgehaltene Revision mit dem eigenen Anwendungsfall prüfen. Das Repository enthält einen separaten Docker-Produktionsstart und Authentifizierung. Getestete Berechtigungen, Persistenz, Abschottung, Wiederherstellung, Kostenkontrollen und operative Verantwortung bleiben trotzdem erforderlich." }, "name": "Kann DeerFlow produktiv eingesetzt werden?" } ] } ```