DeerFlow 2.0: Docker-Setup, Sandboxes und Memory

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 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 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.

Sind DeerFlow-Subagenten voneinander isoliert?

Getrennter Gesprächskontext bedeutet keinen getrennten Container. Der geprüfte Subagenten-Executor 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 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 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 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 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 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 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.

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 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 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.

Für die abschließende Freigabe unsere Software-QA-Checkliste vor dem 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 hilft, die schlankere Framework-Option einzuordnen.

Wavects KI-Entwicklung unterstützt bei der Abgrenzung eines Workflows sowie seiner Berechtigungen und Abnahmetests. Die TwinSoft-AI-Fallstudie zeigt angrenzende Projekterfahrung, keinen DeerFlow-Einsatz. Zur Einordnung für das eigene System den Workflow und seine Fehlerfälle mit Wavect besprechen.