# đŠ DeerFlow - 2.0
[English](./README.md) | [äžæ](./README_zh.md) | [æ„æŹèȘ](./README_ja.md) | Français | [Đ ŃŃŃĐșĐžĐč](./README_ru.md) | [PortuguĂȘs](./README_pt.md)
[](./backend/pyproject.toml)
[](./Makefile)
[](./LICENSE)
> Le 28 fĂ©vrier 2026, DeerFlow a dĂ©crochĂ© la đ 1re place sur GitHub Trending suite au lancement de la version 2. Un immense merci Ă notre incroyable communautĂ© â c'est grĂące Ă vous ! đȘđ„
DeerFlow (**D**eep **E**xploration and **E**fficient **R**esearch **Flow**) est un **super agent harness** open source qui orchestre des **sub-agents**, de la **mĂ©moire** et des **sandboxes** pour accomplir pratiquement n'importe quelle tĂąche â le tout propulsĂ© par des **skills extensibles**.
https://github.com/user-attachments/assets/a8bcadc4-e040-4cf2-8fda-dd768b999c18
> [!NOTE]
> **DeerFlow 2.0 est une rĂ©Ă©criture complĂšte.** Il ne partage aucun code avec la v1. Si vous cherchez le framework Deep Research original, il est maintenu sur la [branche `1.x`](https://github.com/bytedance/deer-flow/tree/main-1.x) â les contributions y sont toujours les bienvenues. Le dĂ©veloppement actif a migrĂ© vers la 2.0.
## Site officiel
Découvrez-en plus et regardez des **démos réelles** sur notre [**site officiel**](https://deerflow.tech).
## Projets associés
- [**LLM Space**](https://github.com/deer-flow/llm-space) - DĂ©couvrez notre arme secrĂšte derriĂšre DeerFlow â un outil de bureau pour prototyper des idĂ©es d'agents, inspecter chaque Ă©tape du harness, rejouer les Ă©checs et tester les performances.
## Coding Plan de ByteDance Volcengine
- Nous recommandons fortement d'utiliser Doubao-Seed-2.0-Code, DeepSeek v3.2 et Kimi 2.5 pour exécuter DeerFlow
- [En savoir plus](https://www.byteplus.com/en/activity/codingplan?utm_campaign=deer_flow&utm_content=deer_flow&utm_medium=devrel&utm_source=OWO&utm_term=deer_flow)
- [DĂ©veloppeurs en Chine continentale, cliquez ici](https://www.volcengine.com/activity/codingplan?utm_campaign=deer_flow&utm_content=deer_flow&utm_medium=devrel&utm_source=OWO&utm_term=deer_flow)
## InfoQuest
DeerFlow intĂšgre dĂ©sormais le toolkit de recherche et de crawling intelligent dĂ©veloppĂ© par BytePlus â [InfoQuest (essai gratuit en ligne)](https://docs.byteplus.com/en/docs/InfoQuest/What_is_Info_Quest)
---
## Table des matiĂšres
- [đŠ DeerFlow - 2.0](#-deerflow---20)
- [Site officiel](#site-officiel)
- [Coding Plan de ByteDance Volcengine](#coding-plan-de-bytedance-volcengine)
- [InfoQuest](#infoquest)
- [Table des matiĂšres](#table-des-matiĂšres)
- [Installation en une phrase pour un coding agent](#installation-en-une-phrase-pour-un-coding-agent)
- [Démarrage rapide](#démarrage-rapide)
- [Configuration](#configuration)
- [Lancer l'application](#lancer-lapplication)
- [Option 1 : Docker (recommandé)](#option-1--docker-recommandé)
- [Option 2 : Développement local](#option-2--développement-local)
- [Avancé](#avancé)
- [Mode Sandbox](#mode-sandbox)
- [Serveur MCP](#serveur-mcp)
- [Canaux de messagerie](#canaux-de-messagerie)
- [Traçage LangSmith](#traçage-langsmith)
- [Traçage Langfuse](#traçage-langfuse)
- [Utiliser les deux fournisseurs](#utiliser-les-deux-fournisseurs)
- [Du Deep Research au Super Agent Harness](#du-deep-research-au-super-agent-harness)
- [Fonctionnalités principales](#fonctionnalités-principales)
- [Skills et outils](#skills-et-outils)
- [Intégration Claude Code](#intégration-claude-code)
- [Objectifs de session (Session Goals)](#objectifs-de-session-session-goals)
- [Sub-Agents](#sub-agents)
- [Sandbox et systĂšme de fichiers](#sandbox-et-systĂšme-de-fichiers)
- [Context Engineering](#context-engineering)
- [Mémoire à long terme](#mémoire-à -long-terme)
- [ModÚles recommandés](#modÚles-recommandés)
- [Client Python intégré](#client-python-intégré)
- [Projets](#projets)
- [Tùches planifiées (Scheduled Tasks)](#tùches-planifiées-scheduled-tasks)
- [Atelier terminal (TUI)](#atelier-terminal-tui)
- [Documentation](#documentation)
- [â ïž Avertissement de sĂ©curitĂ©](#ïž-avertissement-de-sĂ©curitĂ©)
- [Contribuer](#contribuer)
- [Licence](#licence)
- [Remerciements](#remerciements)
- [Contributeurs principaux](#contributeurs-principaux)
- [Star History](#star-history)
## Installation en une phrase pour un coding agent
Si vous utilisez Claude Code, Codex, Cursor, Windsurf ou un autre coding agent, vous pouvez simplement lui envoyer cette phrase :
```text
Aide-moi à cloner DeerFlow si nécessaire, puis à initialiser son environnement de développement local en suivant https://raw.githubusercontent.com/bytedance/deer-flow/main/Install.md
```
Ce prompt est destinĂ© aux coding agents. Il leur demande de cloner le dĂ©pĂŽt si nĂ©cessaire, de privilĂ©gier Docker quand il est disponible, puis de s'arrĂȘter avec la commande exacte pour lancer DeerFlow et la liste des configurations encore manquantes.
## DĂ©marrage rapide
### Configuration
1. **Cloner le dépÎt DeerFlow**
```bash
git clone https://github.com/bytedance/deer-flow.git
cd deer-flow
```
2. **Lancer l'assistant de configuration (recommandé)**
Depuis le répertoire racine du projet (`deer-flow/`), exécutez :
```bash
make setup
```
Cette commande lance un assistant interactif qui vous guide dans le choix d'un fournisseur LLM, d'une recherche web optionnelle et des préférences d'exécution/sécurité (mode sandbox, accÚs bash, outils d'écriture de fichiers). Il génÚre un `config.yaml` minimal et écrit vos clés dans `.env`. Comptez environ 2 minutes.
Exécutez `make doctor` à tout moment pour vérifier votre configuration et obtenir des pistes de correction concrÚtes.
Si vous ouvrez une issue GitHub à propos d'un problÚme de configuration ou d'exécution en local, exécutez
`make support-bundle`. La commande affiche les prochaines Ă©tapes pour le rapporteur, Ă©crit un fichier
`*-issue-summary.md` à coller dans l'issue, un fichier `*-issue-draft.md` destiné au dépÎt d'issue
assisté par IA, ainsi qu'un zip de preuves optionnel sous
`.deer-flow/support-bundles/`. Si un assistant IA dépose l'issue, partez du brouillon et remplacez
chaque placeholder REQUIRED au lieu d'inventer les informations manquantes. N'attachez le zip que si
un mainteneur le demande, ou si le résumé seul ne suffit pas. Les mainteneurs et les outils de triage
IA peuvent commencer par `triage.json` ; le bundle ne contient que des diagnostics expurgés et des
manifestes de fichiers, et n'inclut ni `.env`, ni les messages bruts des conversations, ni le contenu
des fichiers de l'utilisateur.
> **Configuration avancée / manuelle** : si vous préférez éditer `config.yaml` directement, exécutez plutÎt `make config` pour copier le template complet. Voir `config.example.yaml` pour la référence complÚte, y compris les providers basés sur un CLI (Codex CLI, Claude Code OAuth), OpenRouter, l'API Responses, et plus encore.
Exemples de configuration manuelle des modĂšles
```yaml
models:
- name: gpt-4o
display_name: GPT-4o
use: langchain_openai:ChatOpenAI
model: gpt-4o
api_key: $OPENAI_API_KEY
- name: openrouter-gemini-2.5-flash
display_name: Gemini 2.5 Flash (OpenRouter)
use: langchain_openai:ChatOpenAI
model: google/gemini-2.5-flash-preview
api_key: $OPENROUTER_API_KEY
base_url: https://openrouter.ai/api/v1
- name: gpt-5-responses
display_name: GPT-5 (Responses API)
use: langchain_openai:ChatOpenAI
model: gpt-5
api_key: $OPENAI_API_KEY
use_responses_api: true
output_version: responses/v1
- name: qwen3-32b-vllm
display_name: Qwen3 32B (vLLM)
use: deerflow.models.vllm_provider:VllmChatModel
model: Qwen/Qwen3-32B
api_key: $VLLM_API_KEY
base_url: http://localhost:8000/v1
supports_thinking: true
when_thinking_enabled:
extra_body:
chat_template_kwargs:
enable_thinking: true
```
OpenRouter et les passerelles compatibles OpenAI similaires doivent ĂȘtre configurĂ©s avec `langchain_openai:ChatOpenAI` et `base_url`. Si vous prĂ©fĂ©rez utiliser un nom de variable d'environnement propre au fournisseur, pointez `api_key` vers cette variable explicitement (par exemple `api_key: $OPENROUTER_API_KEY`).
Pour router les modÚles OpenAI via `/v1/responses`, continuez d'utiliser `langchain_openai:ChatOpenAI` et définissez `use_responses_api: true` avec `output_version: responses/v1`.
Pour vLLM 0.19.0, utilisez `deerflow.models.vllm_provider:VllmChatModel`. Pour les modĂšles de raisonnement de type Qwen, DeerFlow active le raisonnement via `extra_body.chat_template_kwargs.enable_thinking` et prĂ©serve le champ non standard `reasoning` de vLLM au fil des conversations multi-tours avec appels d'outils. Les anciennes configurations `thinking` sont normalisĂ©es automatiquement pour assurer la rĂ©trocompatibilitĂ©. Les modĂšles de raisonnement peuvent aussi exiger que le serveur soit dĂ©marrĂ© avec `--reasoning-parser ...`. Si votre dĂ©ploiement vLLM local accepte n'importe quelle clĂ© API non vide, vous pouvez tout de mĂȘme dĂ©finir `VLLM_API_KEY` avec une valeur factice.
Exemples de providers basés sur un CLI :
```yaml
models:
- name: gpt-5.4
display_name: GPT-5.4 (Codex CLI)
use: deerflow.models.openai_codex_provider:CodexChatModel
model: gpt-5.4
supports_thinking: true
supports_reasoning_effort: true
- name: claude-sonnet-4.6
display_name: Claude Sonnet 4.6 (Claude Code OAuth)
use: deerflow.models.claude_provider:ClaudeChatModel
model: claude-sonnet-4-6
max_tokens: 4096
supports_thinking: true
```
- Codex CLI lit `~/.codex/auth.json`
- Claude Code accepte `CLAUDE_CODE_OAUTH_TOKEN`, `ANTHROPIC_AUTH_TOKEN`, `CLAUDE_CODE_CREDENTIALS_PATH`, ou `~/.claude/.credentials.json`
- Les entrĂ©es d'agents ACP sont distinctes des providers de modĂšles â si vous configurez `acp_agents.codex`, pointez-le vers un adaptateur Codex ACP tel que `npx -y @zed-industries/codex-acp`
- Sur macOS, exportez l'auth Claude Code explicitement si nécessaire :
```bash
eval "$(python3 scripts/export_claude_code_oauth.py --print-export)"
```
Les clĂ©s API peuvent aussi ĂȘtre dĂ©finies manuellement dans `.env` (recommandĂ©) ou exportĂ©es dans votre shell :
```bash
OPENAI_API_KEY=your-openai-api-key
TAVILY_API_KEY=your-tavily-api-key
```
### Lancer l'application
#### Option 1 : Docker (recommandé)
**DĂ©veloppement** (hot-reload, montage des sources) :
```bash
make docker-init # Pull sandbox image (only once or when image updates)
make docker-start # Start services (auto-detects sandbox mode from config.yaml)
```
`make docker-start` ne lance `provisioner` que si `config.yaml` utilise le mode provisioner (`sandbox.use: deerflow.community.aio_sandbox:AioSandboxProvider` avec `provisioner_url`).
Les processus backend récupÚrent automatiquement les changements dans `config.yaml` au prochain accÚs à la configuration, donc les mises à jour de métadonnées des modÚles ne nécessitent pas de redémarrage manuel en développement.
> [!TIP]
> Sous Linux, si les commandes Docker échouent avec `permission denied while trying to connect to the Docker daemon socket at unix:///var/run/docker.sock`, ajoutez votre utilisateur au groupe `docker` et reconnectez-vous avant de réessayer. Voir [CONTRIBUTING.md](CONTRIBUTING.md#linux-docker-daemon-permission-denied) pour la solution complÚte.
**Production** (build des images en local, montage de la config et des données) :
```bash
make up # Build images and start all production services
make down # Stop and remove containers
```
> [!NOTE]
> Le runtime d'agent s'exécute actuellement dans la Gateway. nginx réécrit `/api/langgraph/*` vers l'API compatible LangGraph servie par la Gateway.
AccĂšs : http://localhost:2026
Voir [CONTRIBUTING.md](CONTRIBUTING.md) pour le guide complet de développement avec Docker.
#### Option 2 : DĂ©veloppement local
Si vous préférez lancer les services en local :
PrĂ©requis : complĂ©tez d'abord les Ă©tapes de « Configuration » ci-dessus (`make setup`). `make dev` nĂ©cessite un fichier `config.yaml` valide Ă la racine du projet. DĂ©finissez `DEER_FLOW_PROJECT_ROOT` pour indiquer explicitement cette racine, ou `DEER_FLOW_CONFIG_PATH` pour pointer vers un fichier de configuration prĂ©cis. L'Ă©tat d'exĂ©cution est Ă©crit par dĂ©faut dans `.deer-flow` sous la racine du projet et peut ĂȘtre dĂ©placĂ© avec `DEER_FLOW_HOME` ; les skills sont lus par dĂ©faut depuis `skills/` sous la racine du projet et peuvent ĂȘtre dĂ©placĂ©s avec `DEER_FLOW_SKILLS_PATH`. ExĂ©cutez `make doctor` pour vĂ©rifier votre configuration avant de dĂ©marrer.
Sous Windows, exécutez le flux de développement local depuis Git Bash. Les shells natifs `cmd.exe` et PowerShell ne sont pas pris en charge pour les scripts de service basés sur bash, et WSL n'est pas garanti car certains scripts dépendent d'utilitaires de Git for Windows comme `cygpath`.
1. **Vérifier les prérequis** :
```bash
make check # Verifies Node.js 22+, pnpm, uv, nginx
```
2. **Installer les dépendances** :
```bash
make install # Install backend + frontend dependencies
```
3. **(Optionnel) Pré-télécharger l'image sandbox** :
```bash
# Recommended if using Docker/Container-based sandbox
make setup-sandbox
```
4. **DĂ©marrer les services** :
```bash
make dev
```
5. **AccĂšs** : http://localhost:2026
### Avancé
#### Mode Sandbox
DeerFlow supporte plusieurs modes d'exécution sandbox :
- **Exécution locale** (exécute le code sandbox directement sur la machine hÎte)
- **Exécution Docker** (exécute le code sandbox dans des conteneurs Docker isolés)
- **Exécution Docker avec Kubernetes** (exécute le code sandbox dans des pods Kubernetes via le service provisioner)
En développement Docker, le démarrage des services suit le mode sandbox défini dans `config.yaml`. En mode Local/Docker, `provisioner` n'est pas démarré.
Voir le [Guide de configuration Sandbox](backend/docs/CONFIGURATION.md#sandbox) pour configurer le mode de votre choix.
#### Serveur MCP
DeerFlow supporte des serveurs MCP et des skills configurables pour étendre ses capacités.
Pour les serveurs MCP HTTP/SSE, les flux de tokens OAuth sont supportés (`client_credentials`, `refresh_token`).
Voir le [Guide MCP Server](backend/docs/MCP_SERVER.md) pour les instructions détaillées.
#### Canaux de messagerie
DeerFlow peut recevoir des tĂąches depuis des applications de messagerie. Les canaux dĂ©marrent automatiquement une fois configurĂ©s â aucune IP publique n'est requise.
DeerFlow peut aussi exposer des connexions de canaux IM appartenant à l'utilisateur dans l'UI du workspace. Quand `channel_connections` est activé, les utilisateurs connectés peuvent lier Telegram, Slack, Discord, Feishu/Lark, DingTalk, WeChat, WeCom, QQ ou Buzz depuis la barre latérale / Settings > Channels. Cela réutilise les transports sortants `channels.*` existants, donc aucune IP publique ni URL de callback provider n'est requise. Les messages IM entrants s'exécutent ensuite sous le compte utilisateur DeerFlow connecté. Voir [IM Channel Connections](backend/docs/IM_CHANNEL_CONNECTIONS.md) pour la configuration et les notes de sécurité.
| Canal | Transport | Difficulté |
|---------|-----------|------------|
| Telegram | Bot API (long-polling) | Facile |
| Slack | Socket Mode | Modérée |
| Feishu / Lark | WebSocket | Modérée |
| WeChat | Tencent iLink (long-polling) | Modérée |
| WeCom | WebSocket | Modérée |
| DingTalk | Stream Push (WebSocket) | Modérée |
| QQ | WebSocket (texte : messages privés et mentions de groupe) | Modérée |
| Buzz | Relais Nostr (WebSocket, NIP-42) | Modérée |
**Configuration dans `config.yaml` :**
```yaml
channels:
# LangGraph-compatible Gateway API base URL (default: http://localhost:8001/api)
langgraph_url: http://localhost:8001/api
# Gateway API URL (default: http://localhost:8001)
gateway_url: http://localhost:8001
# Optional: global session defaults for all mobile channels
session:
assistant_id: lead_agent
config:
recursion_limit: 100
context:
thinking_enabled: true
is_plan_mode: false
subagent_enabled: false
feishu:
enabled: true
app_id: $FEISHU_APP_ID
app_secret: $FEISHU_APP_SECRET
# domain: https://open.feishu.cn # China (default)
# domain: https://open.larksuite.com # International
wecom:
enabled: true
bot_id: $WECOM_BOT_ID
bot_secret: $WECOM_BOT_SECRET
slack:
enabled: true
bot_token: $SLACK_BOT_TOKEN # xoxb-...
app_token: $SLACK_APP_TOKEN # xapp-... (Socket Mode)
allowed_users: [] # empty = allow all
telegram:
enabled: true
bot_token: $TELEGRAM_BOT_TOKEN
allowed_users: [] # identifiants numériques, pas de @pseudo ; vide = tout le monde autorisé
# Optional: per-channel / per-user session settings
session:
assistant_id: mobile_agent
context:
thinking_enabled: false
users:
"123456789":
assistant_id: vip_agent
config:
recursion_limit: 150
context:
thinking_enabled: true
subagent_enabled: true
wechat:
enabled: false
bot_token: $WECHAT_BOT_TOKEN
ilink_bot_id: $WECHAT_ILINK_BOT_ID
qrcode_login_enabled: true # optionnel : autorise le bootstrap QR Ă la premiĂšre utilisation quand bot_token est absent
allowed_users: [] # vide = tout le monde autorisé
polling_timeout: 35
state_dir: ./.deer-flow/wechat/state
max_inbound_image_bytes: 20971520
max_outbound_image_bytes: 20971520
max_inbound_file_bytes: 52428800
max_outbound_file_bytes: 52428800
dingtalk:
enabled: true
client_id: $DINGTALK_CLIENT_ID # ClientId depuis DingTalk Open Platform
client_secret: $DINGTALK_CLIENT_SECRET # ClientSecret depuis DingTalk Open Platform
allowed_users: [] # vide = tout le monde autorisé
card_template_id: "" # Optionnel : ID de modĂšle AI Card pour l'effet machine Ă Ă©crire en streaming
```
Définissez les clés API correspondantes dans votre fichier `.env` :
```bash
# Telegram
TELEGRAM_BOT_TOKEN=123456789:ABCdefGHIjklMNOpqrSTUvwxYZ
# Slack
SLACK_BOT_TOKEN=xoxb-...
SLACK_APP_TOKEN=xapp-...
# Feishu / Lark
FEISHU_APP_ID=cli_xxxx
FEISHU_APP_SECRET=your_app_secret
# WeChat iLink
WECHAT_BOT_TOKEN=your_ilink_bot_token
WECHAT_ILINK_BOT_ID=your_ilink_bot_id
# WeCom
WECOM_BOT_ID=your_bot_id
WECOM_BOT_SECRET=your_bot_secret
# DingTalk
DINGTALK_CLIENT_ID=your_client_id
DINGTALK_CLIENT_SECRET=your_client_secret
```
**Configuration Telegram**
1. Ouvrez une conversation avec [@BotFather](https://t.me/BotFather), envoyez `/newbot`, et copiez le token HTTP API.
2. DĂ©finissez `TELEGRAM_BOT_TOKEN` dans `.env` et activez le canal dans `config.yaml`.
**Configuration Slack**
1. CrĂ©ez une Slack App sur [api.slack.com/apps](https://api.slack.com/apps) â Create New App â From scratch.
2. Dans **OAuth & Permissions**, ajoutez les Bot Token Scopes : `app_mentions:read`, `chat:write`, `im:history`, `im:read`, `im:write`, `files:write`.
3. Activez le **Socket Mode** â gĂ©nĂ©rez un App-Level Token (`xapp-âŠ`) avec le scope `connections:write`.
4. Dans **Event Subscriptions**, abonnez-vous aux bot events : `app_mention`, `message.im`.
5. DĂ©finissez `SLACK_BOT_TOKEN` et `SLACK_APP_TOKEN` dans `.env` et activez le canal dans `config.yaml`.
**Configuration Feishu / Lark**
1. CrĂ©ez une application sur [Feishu Open Platform](https://open.feishu.cn/) â activez la capacitĂ© **Bot**.
2. Ajoutez les permissions : `im:message`, `im:message.p2p_msg:readonly`, `im:resource`.
3. Dans **Events**, abonnez-vous à `im.message.receive_v1` et sélectionnez le mode **Long Connection**.
4. Copiez l'App ID et l'App Secret. DĂ©finissez `FEISHU_APP_ID` et `FEISHU_APP_SECRET` dans `.env` et activez le canal dans `config.yaml`.
**Configuration WeChat**
1. Activez le canal `wechat` dans `config.yaml`.
2. Soit définissez `WECHAT_BOT_TOKEN` dans `.env`, soit mettez `qrcode_login_enabled: true` pour le bootstrap QR à la premiÚre utilisation.
3. Quand `bot_token` est absent et que le bootstrap QR est activé, surveillez les logs du backend pour le contenu du QR renvoyé par iLink et complétez le flux de binding.
4. Une fois le flux QR réussi, DeerFlow persiste le token acquis sous `state_dir` pour les redémarrages ultérieurs.
5. Pour les déploiements Docker Compose, gardez `state_dir` sur un volume persistant afin que le curseur `get_updates_buf` et l'état d'auth sauvegardé survivent aux redémarrages.
**Configuration WeCom**
1. Créez un bot sur la plateforme WeCom AI Bot et obtenez le `bot_id` et le `bot_secret`.
2. Activez `channels.wecom` dans `config.yaml` et renseignez `bot_id` / `bot_secret`.
3. DĂ©finissez `WECOM_BOT_ID` et `WECOM_BOT_SECRET` dans `.env`.
4. Assurez-vous que les dépendances du backend incluent `wecom-aibot-python-sdk`. Le canal utilise une connexion longue WebSocket et ne nécessite pas d'URL de callback publique.
5. L'intégration actuelle prend en charge les messages entrants texte, image et fichier. Les images/fichiers finaux générés par l'agent sont aussi renvoyés dans la conversation WeCom.
**Configuration DingTalk**
1. Créez une application sur [DingTalk Open Platform](https://open.dingtalk.com/) et activez la capacité **Robot**.
2. Dans la page de configuration du robot, définissez le mode de réception des messages sur **Stream**.
3. Copiez le `Client ID` et le `Client Secret`. DĂ©finissez `DINGTALK_CLIENT_ID` et `DINGTALK_CLIENT_SECRET` dans `.env` et activez le canal dans `config.yaml`.
4. *(Optionnel)* Pour activer les réponses en streaming AI Card (effet machine à écrire), créez un modÚle **AI Card** sur la [plateforme de cartes DingTalk](https://open.dingtalk.com/document/dingstart/typewriter-effect-streaming-ai-card), puis définissez `card_template_id` dans `config.yaml` avec l'ID du modÚle. Vous devez également demander les permissions `Card.Streaming.Write` et `Card.Instance.Write`.
**Commandes**
Une fois un canal connecté, vous pouvez interagir avec DeerFlow directement depuis le chat :
| Commande | Description |
|---------|-------------|
| `/new` | DĂ©marrer une nouvelle conversation |
| `/status` | Afficher les infos du thread en cours |
| `/models` | Lister les modĂšles disponibles |
| `/memory` | Consulter la mémoire |
| `/help` | Afficher l'aide |
> Les messages sans prĂ©fixe de commande sont traitĂ©s comme du chat classique â DeerFlow crĂ©e un thread et rĂ©pond de maniĂšre conversationnelle.
#### Traçage LangSmith
DeerFlow intÚgre nativement [LangSmith](https://smith.langchain.com) pour l'observabilité. Une fois activé, tous les appels LLM, les exécutions d'agents et les exécutions d'outils sont tracés et visibles dans le tableau de bord LangSmith.
Ajoutez les lignes suivantes Ă votre fichier `.env` :
```bash
LANGSMITH_TRACING=true
LANGSMITH_ENDPOINT=https://api.smith.langchain.com
LANGSMITH_API_KEY=lsv2_pt_xxxxxxxxxxxxxxxx
LANGSMITH_PROJECT=xxx
```
#### Traçage Langfuse
DeerFlow prend également en charge l'observabilité via [Langfuse](https://langfuse.com) pour les exécutions compatibles LangChain.
Ajoutez les lignes suivantes Ă votre fichier `.env` :
```bash
LANGFUSE_TRACING=true
LANGFUSE_PUBLIC_KEY=pk-lf-xxxxxxxxxxxxxxxx
LANGFUSE_SECRET_KEY=sk-lf-xxxxxxxxxxxxxxxx
LANGFUSE_BASE_URL=https://cloud.langfuse.com
```
Si vous utilisez une instance Langfuse auto-hébergée, définissez `LANGFUSE_BASE_URL` sur l'URL de votre déploiement.
**Champs de corrélation des traces.** Chaque exécution d'agent est annotée avec les attributs de trace réservés de Langfuse afin que les pages Sessions et Users se remplissent automatiquement :
- `session_id` = `thread_id` de LangGraph â regroupe toutes les traces d'une mĂȘme conversation
- `user_id` = utilisateur effectif issu de `get_effective_user_id()` (revient Ă `default` en mode sans authentification)
- `trace_name` = assistant id (par défaut `lead-agent`)
- `tags` = `[env:, model:]` (omis lorsqu'ils ne sont pas définis)
- `metadata.deerflow_trace_id` = id de corrĂ©lation de requĂȘte DeerFlow, toujours identique Ă l'en-tĂȘte de rĂ©ponse `X-Trace-Id` renvoyĂ© par la mĂȘme requĂȘte (`logging.enhance.enabled` contrĂŽle uniquement si cet id est Ă©crit dans les logs)
Ces champs sont injectés dans `RunnableConfig.metadata` à la racine de l'invocation du graphe, à la fois pour le chemin gateway (`runtime/runs/worker.py::run_agent`) et le chemin embarqué (`client.py::DeerFlowClient.stream`), de sorte que tout callback compatible LangChain puisse les lire. Définissez `DEER_FLOW_ENV` (ou `ENVIRONMENT`) pour étiqueter les traces par environnement de déploiement.
#### Utiliser les deux fournisseurs
Si LangSmith et Langfuse sont tous deux activĂ©s, DeerFlow attache les deux callbacks de traçage et rapporte la mĂȘme activitĂ© de modĂšle aux deux systĂšmes.
Si un fournisseur est explicitement activé mais qu'il manque les identifiants requis, ou si son callback échoue à s'initialiser, DeerFlow échoue immédiatement (fail fast) lors de l'initialisation du traçage à la création du modÚle, et le message d'erreur indique le fournisseur à l'origine de l'échec.
Pour les déploiements Docker, le traçage est désactivé par défaut. Définissez `LANGSMITH_TRACING=true` et `LANGSMITH_API_KEY` dans votre `.env` pour l'activer.
## Du Deep Research au Super Agent Harness
DeerFlow a dĂ©marrĂ© comme un framework de Deep Research â et la communautĂ© s'en est emparĂ©e. Depuis le lancement, les dĂ©veloppeurs l'ont poussĂ© bien au-delĂ de la recherche : construction de pipelines de donnĂ©es, gĂ©nĂ©ration de prĂ©sentations, mise en place de dashboards, automatisation de workflows de contenu. Des usages qu'on n'avait jamais anticipĂ©s.
Ăa nous a rĂ©vĂ©lĂ© quelque chose d'important : DeerFlow n'Ă©tait pas qu'un simple outil de recherche. C'Ă©tait un **harness** â un runtime qui donne aux agents l'infrastructure nĂ©cessaire pour vraiment accomplir du travail.
On l'a donc reconstruit de zéro.
DeerFlow 2.0 n'est plus un framework Ă assembler soi-mĂȘme. C'est un super agent harness â clĂ© en main et entiĂšrement extensible. Construit sur LangGraph et LangChain, il embarque tout ce dont un agent a besoin out of the box : un systĂšme de fichiers, de la mĂ©moire, des skills, une exĂ©cution sandboxĂ©e, et la capacitĂ© de planifier et de lancer des sub-agents pour les tĂąches complexes et multi-Ă©tapes.
Utilisez-le tel quel. Ou démontez-le et faites-en le vÎtre.
## Fonctionnalités principales
### Skills et outils
Les skills sont ce qui permet Ă DeerFlow de faire *pratiquement n'importe quoi*.
Un Agent Skill standard est un module de capacitĂ© structurĂ© â un fichier Markdown qui dĂ©finit un workflow, des bonnes pratiques et des rĂ©fĂ©rences vers des ressources associĂ©es. DeerFlow est livrĂ© avec des skills intĂ©grĂ©s pour la recherche, la gĂ©nĂ©ration de rapports, la crĂ©ation de prĂ©sentations, les pages web, la gĂ©nĂ©ration d'images et de vidĂ©os, et bien plus. Mais la vraie force rĂ©side dans l'extensibilitĂ© : ajoutez vos propres skills, remplacez ceux fournis, ou combinez-les en workflows composites.
Les skills sont chargĂ©s progressivement â uniquement quand la tĂąche le nĂ©cessite, pas tous en mĂȘme temps. Ăa permet de garder la fenĂȘtre de contexte lĂ©gĂšre et de bien fonctionner mĂȘme avec des modĂšles sensibles au nombre de tokens.
Quand vous installez des archives `.skill` via le Gateway, DeerFlow accepte les métadonnées frontmatter optionnelles standard comme `version`, `author` et `compatibility`, plutÎt que de rejeter des skills externes par ailleurs valides.
Les outils suivent la mĂȘme philosophie. DeerFlow est livrĂ© avec un ensemble d'outils de base â recherche web, fetch de pages web, opĂ©rations sur les fichiers, exĂ©cution bash â et supporte les outils custom via des serveurs MCP et des fonctions Python. Remplacez n'importe quoi. Ajoutez n'importe quoi.
Les suggestions de suivi générées par le Gateway normalisent désormais aussi bien la sortie texte brut du modÚle que le contenu riche au format bloc/liste avant de parser la réponse en tableau JSON, de sorte que les wrappers de contenu propres à chaque provider ne suppriment plus silencieusement les suggestions.
```
# Paths inside the sandbox container
/mnt/skills/public
âââ research/SKILL.md
âââ report-generation/SKILL.md
âââ slide-creation/SKILL.md
âââ web-page/SKILL.md
âââ image-generation/SKILL.md
/mnt/skills/custom
âââ your-custom-skill/SKILL.md â yours
```
#### Intégration Claude Code
Le skill `claude-to-deerflow` vous permet d'interagir avec une instance DeerFlow en cours d'exĂ©cution directement depuis [Claude Code](https://docs.anthropic.com/en/docs/claude-code). Envoyez des tĂąches de recherche, vĂ©rifiez le statut, gĂ©rez les threads â le tout sans quitter le terminal.
**Installer le skill** :
```bash
npx skills add https://github.com/bytedance/deer-flow --skill claude-to-deerflow
```
Assurez-vous ensuite que DeerFlow tourne (par défaut sur `http://localhost:2026`) et utilisez la commande `/claude-to-deerflow` dans Claude Code.
**Ce que vous pouvez faire** :
- Envoyer des messages à DeerFlow et recevoir des réponses en streaming
- Choisir le mode d'exécution : flash (rapide), standard, pro (planification), ultra (sub-agents)
- Vérifier la santé de DeerFlow, lister les modÚles/skills/agents
- GĂ©rer les threads et l'historique des conversations
- Upload des fichiers pour analyse
**Variables d'environnement** (optionnel, pour des endpoints custom) :
```bash
DEERFLOW_URL=http://localhost:2026 # Unified proxy base URL
DEERFLOW_GATEWAY_URL=http://localhost:2026 # Gateway API
DEERFLOW_LANGGRAPH_URL=http://localhost:2026/api/langgraph # LangGraph API
```
Voir [`skills/public/claude-to-deerflow/SKILL.md`](skills/public/claude-to-deerflow/SKILL.md) pour la référence API complÚte.
### Objectifs de session (Session Goals)
Utilisez `/goal ` pour attacher une condition de complĂ©tion active au thread courant. Le goal est un Ă©tat de portĂ©e thread, pas une activation de skill â il reste actif entre les tours jusqu'Ă ce que DeerFlow dĂ©termine qu'il a Ă©tĂ© satisfait, ou jusqu'Ă ce que vous le supprimiez.
Commandes prises en charge :
```text
/goal finish the implementation and make all tests pass
/goal # afficher le goal actif
/goal clear # le supprimer
```
AprĂšs chaque exĂ©cution menĂ©e par la Gateway, DeerFlow Ă©value la conversation visible, y compris les appels d'outils de l'assistant et leurs rĂ©sultats abrĂ©gĂ©s, par rapport au goal actif Ă l'aide d'un modĂšle Ă©valuateur non-thinking. Un rĂ©sultat d'outil rĂ©ussi ne suffit pas Ă satisfaire un goal, et lorsque l'assistant a dĂ» deviner une information manquante ou ambiguĂ«, l'Ă©valuateur renvoie `needs_user_input`. L'Ă©valuateur doit renvoyer un blocker typĂ© (`missing_evidence`, `needs_user_input`, `run_failed`, `external_wait` ou `goal_not_met_yet`) accompagnĂ© de preuves visibles. DeerFlow n'injecte une hidden continuation que si le dernier tour assistant est durablement checkpointĂ©, que le blocker est `goal_not_met_yet`, que le thread n'a pas changĂ© durant l'Ă©valuation et que le disjoncteur de non-progression n'a pas dĂ©clenchĂ©. Le plafond de sĂ©curitĂ© est de 8 hidden continuations par dĂ©faut, et les Ă©valuations identiques de non-progression s'arrĂȘtent aprĂšs 2 tentatives rĂ©pĂ©tĂ©es. `/goal clear` ainsi que toute nouvelle saisie utilisateur ont prioritĂ© sur les continuations en file d'attente. Lorsque le goal est satisfait, DeerFlow le supprime automatiquement et publie l'Ă©tat mis Ă jour du thread.
Le Web UI affiche le goal actif au-dessus de la zone de saisie. La mĂȘme commande est disponible depuis le TUI et les canaux IM pris en charge. Dans le Web UI et les canaux IM pris en charge, dĂ©finir `/goal ` lance aussi une exĂ©cution avec la condition comme tĂąche ; les commandes de statut et de suppression ne gĂšrent que l'Ă©tat du goal lui-mĂȘme.
### Sub-Agents
Les tùches complexes tiennent rarement en une seule passe. DeerFlow les décompose.
L'agent principal peut lancer des sub-agents Ă la volĂ©e â chacun avec son propre contexte dĂ©limitĂ©, ses outils et ses conditions d'arrĂȘt. Les sub-agents s'exĂ©cutent en parallĂšle quand c'est possible, remontent des rĂ©sultats structurĂ©s, et l'agent principal synthĂ©tise le tout en une sortie cohĂ©rente.
C'est comme ça que DeerFlow gĂšre les tĂąches qui prennent de quelques minutes Ă plusieurs heures : une tĂąche de recherche peut se dĂ©ployer en une dizaine de sub-agents, chacun explorant un angle diffĂ©rent, puis converger vers un seul rapport â ou un site web â ou un jeu de slides avec des visuels gĂ©nĂ©rĂ©s. Un seul harness, de nombreuses mains.
### Sandbox et systĂšme de fichiers
DeerFlow ne se contente pas de *parler* de faire les choses. Il dispose de son propre ordinateur.
Chaque tĂąche s'exĂ©cute dans un conteneur Docker isolĂ© avec un systĂšme de fichiers complet â skills, workspace, uploads, outputs. L'agent lit, Ă©crit et Ă©dite des fichiers. Il exĂ©cute des commandes bash et du code. Il visualise des images. Le tout sandboxĂ©, le tout auditable, zĂ©ro contamination entre les sessions.
C'est la différence entre un chatbot avec accÚs à des outils et un agent doté d'un véritable environnement d'exécution.
```
# Paths inside the sandbox container
/mnt/user-data/
âââ uploads/ â your files
âââ workspace/ â agents' working directory
âââ outputs/ â final deliverables
```
### Context Engineering
**Contexte isolĂ© des Sub-Agents** : chaque sub-agent s'exĂ©cute dans son propre contexte isolĂ©. Il ne peut voir ni le contexte de l'agent principal, ni celui des autres sub-agents. L'objectif est de garantir que chaque sub-agent reste concentrĂ© sur sa tĂąche sans ĂȘtre parasitĂ© par des informations non pertinentes.
**RĂ©sumĂ©** : au sein d'une session, DeerFlow gĂšre le contexte de maniĂšre agressive â en rĂ©sumant les sous-tĂąches terminĂ©es, en dĂ©chargeant les rĂ©sultats intermĂ©diaires vers le systĂšme de fichiers, en compressant ce qui n'est plus immĂ©diatement pertinent. Ăa lui permet de rester efficace sur des tĂąches longues et multi-Ă©tapes sans faire exploser la fenĂȘtre de contexte.
### MĂ©moire Ă long terme
La plupart des agents oublient tout dĂšs qu'une conversation se termine. DeerFlow, lui, se souvient.
D'une session Ă l'autre, DeerFlow construit une mĂ©moire persistante de votre profil, de vos prĂ©fĂ©rences et de vos connaissances accumulĂ©es. Plus vous l'utilisez, mieux il vous connaĂźt â votre style d'Ă©criture, votre stack technique, vos workflows rĂ©currents. La mĂ©moire est stockĂ©e localement et reste sous votre contrĂŽle.
Les mises à jour de la mémoire ignorent désormais les entrées de faits en double au moment de l'application, de sorte que les préférences et le contexte répétés ne s'accumulent plus indéfiniment entre les sessions.
## ModÚles recommandés
DeerFlow est agnostique en termes de modĂšle â il fonctionne avec n'importe quel LLM implĂ©mentant l'API compatible OpenAI. Cela dit, il offre de meilleures performances avec des modĂšles qui supportent :
- **De longues fenĂȘtres de contexte** (100k+ tokens) pour la recherche approfondie et les tĂąches multi-Ă©tapes
- **Des capacités de raisonnement** pour la planification adaptative et la décomposition de tùches complexes
- **Des entrées multimodales** pour la compréhension d'images et de vidéos
- **Un usage fiable des outils (tool use)** pour des appels de fonctions et des sorties structurées fiables
## Client Python intégré
DeerFlow peut ĂȘtre utilisĂ© comme bibliothĂšque Python intĂ©grĂ©e sans lancer l'ensemble des services HTTP. Le `DeerFlowClient` fournit un accĂšs direct in-process Ă toutes les capacitĂ©s d'agent et de Gateway, en retournant les mĂȘmes schĂ©mas de rĂ©ponse que l'API HTTP Gateway. Le HTTP Gateway expose Ă©galement `DELETE /api/threads/{thread_id}` pour supprimer les donnĂ©es de thread locales gĂ©rĂ©es par DeerFlow aprĂšs la suppression du thread LangGraph :
```python
from deerflow.client import DeerFlowClient
client = DeerFlowClient()
# Chat
response = client.chat("Analyze this paper for me", thread_id="my-thread")
# Streaming (LangGraph SSE protocol: values, messages-tuple, end)
for event in client.stream("hello"):
if event.type == "messages-tuple" and event.data.get("type") == "ai":
print(event.data["content"])
# Configuration & management â returns Gateway-aligned dicts
models = client.list_models() # {"models": [...]}
skills = client.list_skills() # {"skills": [...]}
client.update_skill("web-search", enabled=True)
client.upload_files("thread-1", ["./report.pdf"]) # {"success": True, "files": [...]}
client.set_goal("thread-1", "finish the implementation and make all tests pass")
client.get_goal("thread-1") # {"goal": {...}} or {"goal": None}
client.clear_goal("thread-1")
```
Toutes les méthodes retournant des dicts sont validées en CI contre les modÚles de réponse Pydantic du Gateway (`TestGatewayConformance`), garantissant que le client intégré reste synchronisé avec les schémas de l'API HTTP. Voir `backend/packages/harness/deerflow/client.py` pour la documentation API complÚte.
## Projets
Les projets regroupent des conversations liées sous un nom partagé, des instructions et une étagÚre de documents.
Une conversation rejoint un projet au moment de sa création (lorsqu'un projet est sélectionné) ou plus tard via le menu de déplacement. Les exécutions ne modifient jamais l'appartenance : l'envoi d'un message ne peut pas affecter ou réaffecter une conversation. Déplacer une conversation hors d'un projet la laisse non affectée jusqu'à ce qu'elle soit à nouveau explicitement déplacée.
Le dĂ©placement d'une conversation actualise son rattachement dans l'en-tĂȘte ainsi que les listes de projets, y compris lorsqu'une requĂȘte de mĂ©tadonnĂ©es plus ancienne est encore en cours.
Les projets exigent les tables et colonnes de base de données actuelles. Une base de données estampillée `0019_thread_incarnations` issue de l'ancien déploiement basé sur 0018 est rejetée au démarrage si le schéma des projets est absent. Suivez la [procédure de récupération hors ligne de la base de données](docs/database-forward-revision-recovery.md) avant de démarrer ce build sur cette base.
### Instructions de projet
Chaque projet stocke des instructions en forme libre â contexte, conventions et contraintes s'appliquant Ă toutes les conversations du projet â modifiables dans l'onglet Instructions de la page du projet, avec un compteur d'octets en direct. Lorsqu'une exĂ©cution dĂ©marre sur un thread membre, le Gateway fige une seule fois l'Ă©tat actuel du projet et rend les instructions sous forme d'un bloc `` bornĂ©, propre Ă cette requĂȘte et rĂ©servĂ© Ă cette exĂ©cution : le bloc n'entre jamais dans le prompt systĂšme ni dans l'historique persistĂ©, et chaque nouvelle exĂ©cution voit les derniĂšres instructions enregistrĂ©es. Les instructions sont plafonnĂ©es Ă `projects.instructions_max_bytes` octets UTF-8 (par dĂ©faut 8192, plage 256â262144) ; les caractĂšres multioctets comptent pour leur longueur en octets UTF-8. Les instructions trop longues sont rejetĂ©es avec un `422` Ă l'Ă©criture et ne sont jamais tronquĂ©es silencieusement.
### ĂtagĂšre de documents
Chaque projet dispose d'une étagÚre de documents pour les fichiers partagés par l'ensemble du projet, gérée depuis la section Documents de la page du projet :
- **TĂ©lĂ©verser** un fichier (bouton ou glisser-dĂ©poser, un fichier par requĂȘte). Les limites de taille de l'Ă©tagĂšre rĂ©utilisent `uploads.max_file_size` (par dĂ©faut 50 Mio) ; re-tĂ©lĂ©verser un contenu identique renvoie l'entrĂ©e existante au lieu de crĂ©er un doublon.
- **Lister** les entrées avec leur nom, taille, date de modification et provenance (téléversées vs. enregistrées depuis une conversation), et prévisualiser ou télécharger n'importe quelle entrée.
- **Enregistrer dans le projet** depuis un fichier de thread : le navigateur en lecture seule des fichiers de conversation sous l'étagÚre liste les téléversements et sorties des threads membres, chacun avec une action « Enregistrer dans le projet ».
- **Joindre à un thread** : copier un fichier de l'étagÚre vers les téléversements d'un thread via le pipeline d'ingestion normal, pour que la conversation puisse l'utiliser directement.
Les exécutions sur les threads membres reçoivent également un index `` borné, rendu à chaque exécution à partir de l'instantané figé (limité par `projects.shelf_index_max_entries` et `projects.shelf_index_max_bytes`), et l'agent peut parcourir l'étagÚre et lire les documents avec les outils `list_project_documents` et `read_project_document`.
### Sémantique de lecture des projets archivés
Archiver un projet gĂšle les Ă©critures mais conserve les lectures. Les threads d'un projet archivĂ© s'exĂ©cutent toujours et reçoivent toujours les instructions du projet et l'index de l'Ă©tagĂšre, et l'Ă©tagĂšre reste entiĂšrement lisible : listage, prĂ©visualisation/tĂ©lĂ©chargement, navigateur de fichiers de conversation et jonction Ă un thread continuent de fonctionner. Les tĂ©lĂ©versements, l'enregistrement dans le projet et le dĂ©placement de fichiers individuels de l'Ă©tagĂšre vers la corbeille exigent un projet actif, et un document mis Ă la corbeille ne peut pas ĂȘtre restaurĂ© dans un projet archivĂ©. La suppression d'un projet archivĂ© reste possible et dĂ©place toute son Ă©tagĂšre vers la corbeille.
### Corbeille
Supprimer un document de l'Ă©tagĂšre le dĂ©place vers la corbeille au lieu de l'effacer : l'entrĂ©e conserve ses octets et un instantanĂ© de son projet d'origine pendant `projects.trash_retention_days` (par dĂ©faut 30) avant que le balayage de rĂ©tention puisse la purger dĂ©finitivement. La page `/workspace/trash` â accessible depuis la section Documents de la page du projet et l'en-tĂȘte Projets de la barre latĂ©rale â liste les documents mis Ă la corbeille avec leur projet d'origine et la rĂ©tention restante, avec des actions Restaurer et Supprimer dĂ©finitivement par entrĂ©e, plus une action Vider la corbeille qui supprime dĂ©finitivement tous les documents de la corbeille â immĂ©diatement, et non aprĂšs la fenĂȘtre de rĂ©tention ; la fenĂȘtre ne fait que borner la durĂ©e pendant laquelle une entrĂ©e peut y rester avant que le balayage de rĂ©tention ne la rĂ©cupĂšre. La restauration renvoie le document Ă son projet d'origine, ou Ă un projet de votre choix lorsque l'origine a disparu ou est archivĂ©e ; si la cible contient dĂ©jĂ un fichier actif identique, les entrĂ©es fusionnent. La suppression d'un projet dĂ©place toute son Ă©tagĂšre vers la corbeille en une seule Ă©tape.
## Tùches planifiées (Scheduled Tasks)
DeerFlow inclut désormais un MVP de tùches planifiées (scheduled-task) de premier niveau dans le workspace.
Capacités actuelles du MVP :
- GĂ©rer les tĂąches depuis `/workspace/scheduled-tasks`
- Choisir si chaque tùche planifiée réutilise un thread ou crée un nouveau thread à chaque exécution
- Prendre en charge les planifications `once`, `cron` et `interval`
- Exécuter les tùches planifiées en arriÚre-plan comme des exécutions DeerFlow non interactives (`ask_clarification` n'y est pas exposé)
- Utiliser le comportement de chevauchement `skip` pour les exĂ©cutions cron dues qui entrent en collision avec une exĂ©cution active sur le mĂȘme thread rĂ©utilisĂ©
- Mettre en pause, reprendre, déclencher, inspecter l'historique et supprimer les tùches
- Exécuter le travail planifié via le cycle de vie d'exécution normal de DeerFlow
Limites actuelles du MVP :
- Pas encore d'outil `schedule_task` créable depuis la conversation
- Pas de tĂąches de notification en texte seul
- Pas de cibles de dispatch canal ou GitHub
Activez le polling en arriĂšre-plan avec `config.yaml -> scheduler.enabled`. Le dĂ©clenchement manuel utilise la mĂȘme ressource scheduled-task et le mĂȘme chemin d'exĂ©cution.
## Atelier terminal (TUI)
`deerflow` est un atelier natif terminal pour ceux qui vivent dans le shell. Il s'exĂ©cute de maniĂšre **intĂ©grĂ©e** sur `DeerFlowClient` â pas besoin de Gateway, de frontend, de nginx ou de Docker â tout en honorant les mĂȘmes `config.yaml`, checkpointer, skills, mĂ©moire, MCP et sandbox que le reste de DeerFlow.
```bash
uv pip install 'deerflow-harness[tui]' # dépendance optionnelle 'textual'
deerflow # lancer l'UI terminal (TTY requis)
deerflow --continue # reprendre le thread le plus récent
deerflow --resume THREAD # reprendre un thread par id
deerflow --print "summarize this repo" # réponse one-shot headless vers stdout
deerflow --json "hello" # StreamEvents séparés par saut de ligne en mode headless
```
Une surface de chat pilotĂ©e au clavier avec un transcript en streaming (rĂ©ponses rendues en Markdown), des cartes d'activitĂ© d'outils compactes, une palette de commandes slash `/`, la gestion des goal via `/goal`, des sĂ©lecteurs `/model` et `/threads`, l'historique de saisie, et l'interruption via `Esc` / `Ctrl+C`. Les sessions ouvertes dans le TUI apparaissent aussi dans la barre latĂ©rale du Web UI â elles Ă©crivent dans le magasin de threads partagĂ© sous l'utilisateur local par dĂ©faut, donc le terminal et le web restent synchronisĂ©s **sans lancer la Gateway**.
Voir [backend/docs/TUI.md](backend/docs/TUI.md) pour le guide complet.
## Documentation
- [Guide de contribution](CONTRIBUTING.md) - Mise en place de l'environnement de développement et workflow
- [Guide de configuration](backend/docs/CONFIGURATION.md) - Instructions d'installation et de configuration
- [Vue d'ensemble de l'architecture](backend/CLAUDE.md) - DĂ©tails de l'architecture technique
- [Architecture backend](backend/README.md) - Architecture backend et référence API
## â ïž Avertissement de sĂ©curitĂ©
### Un déploiement inapproprié peut introduire des risques de sécurité
DeerFlow dispose de capacitĂ©s clĂ©s Ă hauts privilĂšges, notamment **l'exĂ©cution de commandes systĂšme, les opĂ©rations sur les ressources et l'invocation de logique mĂ©tier**. Il est conçu par dĂ©faut pour ĂȘtre **dĂ©ployĂ© dans un environnement local de confiance (accessible uniquement via l'interface de loopback 127.0.0.1)**. Si vous dĂ©ployez l'agent dans des environnements non fiables â tels que des rĂ©seaux LAN, des serveurs cloud publics ou d'autres environnements accessibles depuis plusieurs terminaux â sans mesures de sĂ©curitĂ© strictes, cela peut introduire des risques, notamment :
- **Invocation non autorisĂ©e** : les fonctionnalitĂ©s de l'agent pourraient ĂȘtre dĂ©couvertes par des tiers non autorisĂ©s ou des scanners malveillants, dĂ©clenchant des requĂȘtes non autorisĂ©es en masse qui exĂ©cutent des opĂ©rations Ă haut risque (commandes systĂšme, lecture/Ă©criture de fichiers), pouvant causer de graves consĂ©quences.
- **Risques juridiques et de conformité** : si l'agent est utilisé illégalement pour mener des cyberattaques, du vol de données ou d'autres activités illicites, cela peut entraßner des responsabilités juridiques et des risques de conformité.
### Recommandations de sécurité
**Note : nous recommandons fortement de déployer DeerFlow dans un environnement réseau local de confiance.** Si vous avez besoin d'un déploiement multi-appareils ou multi-réseaux, vous devez mettre en place des mesures de sécurité strictes, par exemple :
- **Liste blanche d'IP** : utilisez `iptables`, ou déployez des pare-feux matériels / commutateurs avec ACL, pour **configurer des rÚgles de liste blanche d'IP** et refuser l'accÚs à toutes les autres adresses IP.
- **Passerelle d'authentification** : configurez un proxy inverse (ex. nginx) et **activez une authentification forte en amont**, bloquant tout accÚs non authentifié.
- **Isolation rĂ©seau** : si possible, placez l'agent et les appareils de confiance dans le **mĂȘme VLAN dĂ©diĂ©**, isolĂ© des autres Ă©quipements rĂ©seau.
- **Restez informé** : continuez à suivre les mises à jour de sécurité du projet DeerFlow.
## Contribuer
Les contributions sont les bienvenues ! Consultez [CONTRIBUTING.md](CONTRIBUTING.md) pour la mise en place de l'environnement de développement, le workflow et les conventions.
La couverture de tests de régression inclut la détection du mode sandbox Docker et les tests de gestion du kubeconfig-path du provisioner dans `backend/tests/`.
## Licence
Ce projet est open source et disponible sous la [Licence MIT](./LICENSE).
## Remerciements
DeerFlow est construit sur le travail remarquable de la communauté open source. Nous sommes profondément reconnaissants envers tous les projets et contributeurs dont les efforts ont rendu DeerFlow possible. Nous nous tenons véritablement sur les épaules de géants.
Nous tenons Ă exprimer notre sincĂšre gratitude aux projets suivants pour leurs contributions inestimables :
- **[LangChain](https://github.com/langchain-ai/langchain)** : leur excellent framework propulse nos interactions LLM et nos chaßnes, permettant une intégration et des fonctionnalités fluides.
- **[LangGraph](https://github.com/langchain-ai/langgraph)** : leur approche innovante de l'orchestration multi-agents a été déterminante pour les workflows sophistiqués de DeerFlow.
Ces projets illustrent le pouvoir transformateur de la collaboration open source, et nous sommes fiers de bĂątir sur leurs fondations.
### Contributeurs principaux
Un grand merci aux auteurs principaux de `DeerFlow`, dont la vision, la passion et le dévouement ont donné vie à ce projet :
- **[Daniel Walnut](https://github.com/hetaoBackend/)**
- **[Henry Li](https://github.com/magiccube/)**
Votre engagement sans faille et votre expertise sont le moteur du succÚs de DeerFlow. Nous sommes honorés de vous avoir à la barre de cette aventure.
## Star History
[](https://star-history.dera.page/#bytedance/deer-flow&Date)