DeerFlow : orchestrer une recherche agentique en plusieurs étapes
Un harnais SuperAgent open source à long terme qui recherche, code et crée. À l'aide de bacs à sable, de mémoires, d'outils, de compétences, de sous-agents et d'une passerelle de messages, il gère différents niveaux de tâches qui peuvent prendre de quelques minutes à plusieurs heures.
En bref
- De quoi s’agit-il ?
- DeerFlow assemble des agents, des outils et une interface de suivi pour des tâches de recherche ; son intérêt dépend de la visibilité donnée à chaque étape.
- À qui s’adresse-t-il ?
- deer-flow convient à une équipe qui accepte ses dépendances et ses limites documentées ; il ne convient pas à un déploiement qui exige des garanties absentes du README. Avant adoption, exécutez le chemin propre à ce dépôt, vérifiez les fichiers et commandes cités dans l’article, puis contrôlez le résultat observable et les permissions associées.
- Puis-je l’utiliser commercialement ?
- Oui. MIT est une licence permissive : vous pouvez utiliser, modifier et vendre un logiciel qui en dépend, à condition de conserver les mentions de droit d’auteur et de licence.
- Est-il encore maintenu ?
- Oui. Le dépôt a reçu de nouveaux commits au cours des dernières 24 heures.
- En quel langage est-il écrit ?
- Principalement Python, d’après les statistiques de langage de GitHub.
Ces réponses reposent sur les données GitHub du projet (dernière synchronisation le 15 septembre 2026) et sur notre analyse. Elles ne constituent pas un avis juridique.
ANALYSE OPEN SOURCE APPROFONDIE
Le graphe de recherche et ses états
DeerFlow a commencé comme un framework de recherche approfondie, mais le README indique que la communauté l'a poussé au-delà de la recherche, créant des pipelines de données, des présentations, des tableaux de bord et des flux de contenu. Les mainteneurs ont conclu que ce n'était pas seulement un outil de recherche mais un harnais, et l'ont réécrit de zéro. DeerFlow 2.0 ne partage aucun code avec v1 ; l'original est maintenu sur la branche 1.x, et le développement actif est passé à 2.0. Le nom signifie Deep Exploration and Efficient Research Flow. Le README ne fournit pas de comparaison des fonctionnalités v1 et v2 au-delà de la note de réécriture.
Le dépôt doit être lu comme une documentation opératoire, pas comme une preuve de compatibilité universelle. Les détails retenus ici viennent du README et des fichiers de configuration indiqués par le projet. Lorsqu’une valeur n’est pas documentée, elle reste à vérifier dans un environnement isolé. Cette distinction est importante pour éviter de transformer une commande d’exemple en engagement de production. Les dépendances, les permissions et la version annoncée peuvent modifier le résultat obtenu. Pour deer-flow, le contrôle utile consiste à relier le graphe de recherche et ses états à une sortie observable : journal, fichier produit, route appelée, certificat présenté ou état d’un service. Le dépôt ne fournit pas nécessairement toutes les garanties nécessaires à un usage sensible ; il faut documenter l’écart au lieu de le combler par une supposition.
Outils, sous-agents et contexte partagé
Le démarrage rapide du README utilise make setup à la racine du projet, qui lance un assistant interactif pour choisir le fournisseur LLM, la recherche web optionnelle et les préférences d'exécution telles que le mode sandbox, l'accès bash et les outils d'écriture de fichiers. Il génère un config.yaml minimal et écrit les clés dans .env, en environ deux minutes. make doctor vérifie la configuration et donne des conseils de correction. Pour les rapports de problème, make support-bundle écrit un résumé, un brouillon et une archive zip facultative sous .deer-flow/support-bundles, avec des diagnostics expurgés et des manifestes de fichiers, mais pas .env ni les messages de conversation. Sous Windows, le développement local doit se faire via Git Bash ; cmd.exe et PowerShell ne sont pas pris en charge pour les scripts bash.
Le dépôt doit être lu comme une documentation opératoire, pas comme une preuve de compatibilité universelle. Les détails retenus ici viennent du README et des fichiers de configuration indiqués par le projet. Lorsqu’une valeur n’est pas documentée, elle reste à vérifier dans un environnement isolé. Cette distinction est importante pour éviter de transformer une commande d’exemple en engagement de production. Les dépendances, les permissions et la version annoncée peuvent modifier le résultat obtenu. Pour deer-flow, le contrôle utile consiste à relier outils, sous-agents et contexte partagé à une sortie observable : journal, fichier produit, route appelée, certificat présenté ou état d’un service. Le dépôt ne fournit pas nécessairement toutes les garanties nécessaires à un usage sensible ; il faut documenter l’écart au lieu de le combler par une supposition.
Planification, exécution et reprise
Docker est le chemin recommandé. make docker-init tire l'image sandbox, make docker-start démarre les services, make up construit les images et démarre les services de production, make down pour arrêter. Le README inclut un tableau de dimensionnement : évaluation locale à partir de 4 vCPU, 8 Go de RAM, 20 Go de SSD libre ; développement Docker à 4 vCPU, 8 Go, 25 Go ; serveurs longue durée à 8 vCPU, 16 Go, 40 Go. Pour le développement local, make check vérifie Node.js 22+, pnpm, uv et nginx, puis make install et make dev démarrent les services. L'accès se fait via http://localhost:2026 dans les deux cas. Le README note que les processus backend prennent en compte les modifications de config.yaml lors du prochain accès à la configuration, sauf pour les paramètres de stockage de points de contrôle qui nécessitent un redémarrage.
Le dépôt doit être lu comme une documentation opératoire, pas comme une preuve de compatibilité universelle. Les détails retenus ici viennent du README et des fichiers de configuration indiqués par le projet. Lorsqu’une valeur n’est pas documentée, elle reste à vérifier dans un environnement isolé. Cette distinction est importante pour éviter de transformer une commande d’exemple en engagement de production. Les dépendances, les permissions et la version annoncée peuvent modifier le résultat obtenu. Pour deer-flow, le contrôle utile consiste à relier planification, exécution et reprise à une sortie observable : journal, fichier produit, route appelée, certificat présenté ou état d’un service. Le dépôt ne fournit pas nécessairement toutes les garanties nécessaires à un usage sensible ; il faut documenter l’écart au lieu de le combler par une supposition.
Interface, sorties et traçabilité
Les modes sandbox incluent l'exécution locale directement sur l'hôte, l'exécution Docker dans des conteneurs isolés, et Docker avec Kubernetes via un service de provisionnement. Les serveurs MCP sont configurables, avec des flux de jetons OAuth pour les serveurs HTTP/SSE et des délais par outil pour les serveurs stdio. Les noms d'outils sont préfixés par le nom du serveur pour éviter les collisions. Les canaux IM prennent en charge Telegram, Slack, Feishu/Lark, WeChat, WeCom et DingTalk, avec des transports par long-polling ou WebSocket, sans IP publique requise. Les commandes de canal incluent /new, /status, /models, /memory et /help. Le README documente également les connexions de canal IM par utilisateur permettant aux utilisateurs connectés de lier leurs propres comptes.
Le dépôt doit être lu comme une documentation opératoire, pas comme une preuve de compatibilité universelle. Les détails retenus ici viennent du README et des fichiers de configuration indiqués par le projet. Lorsqu’une valeur n’est pas documentée, elle reste à vérifier dans un environnement isolé. Cette distinction est importante pour éviter de transformer une commande d’exemple en engagement de production. Les dépendances, les permissions et la version annoncée peuvent modifier le résultat obtenu. Pour deer-flow, le contrôle utile consiste à relier interface, sorties et traçabilité à une sortie observable : journal, fichier produit, route appelée, certificat présenté ou état d’un service. Le dépôt ne fournit pas nécessairement toutes les garanties nécessaires à un usage sensible ; il faut documenter l’écart au lieu de le combler par une supposition.
Déployer en contrôlant les accès
DeerFlow dispose d'intégrations intégrées pour LangSmith et Langfuse. Pour les activer, il faut définir des variables d'environnement telles que LANGSMITH_TRACING, LANGSMITH_API_KEY, LANGFUSE_TRACING et LANGFUSE_PUBLIC_KEY. Chaque exécution d'agent est annotée avec les attributs réservés de Langfuse : session_id issu de thread_id, user_id issu de get_effective_user_id(), trace_name comme identifiant d'assistant, tags pour l'environnement et le modèle, et metadata.deerflow_trace_id. Monocle est un traceur basé sur OpenTelemetry qui enregistre les appels LLM, les étapes d'agent, les invocations d'outils et de MCP, avec entrées, sorties, minutages et nombres de jetons. Le README avertit que les traces Monocle capturent textuellement les entrées et sorties des spans, donc les exportateurs distants ne doivent être activés que vers des destinations de confiance. Les trois traceurs peuvent fonctionner ensemble.
Le dépôt doit être lu comme une documentation opératoire, pas comme une preuve de compatibilité universelle. Les détails retenus ici viennent du README et des fichiers de configuration indiqués par le projet. Lorsqu’une valeur n’est pas documentée, elle reste à vérifier dans un environnement isolé. Cette distinction est importante pour éviter de transformer une commande d’exemple en engagement de production. Les dépendances, les permissions et la version annoncée peuvent modifier le résultat obtenu. Pour deer-flow, le contrôle utile consiste à relier déployer en contrôlant les accès à une sortie observable : journal, fichier produit, route appelée, certificat présenté ou état d’un service. Le dépôt ne fournit pas nécessairement toutes les garanties nécessaires à un usage sensible ; il faut documenter l’écart au lieu de le combler par une supposition.
Mesurer la qualité plutôt que la promesse
Une compétence d'agent standard est un fichier Markdown définissant un flux de travail, des bonnes pratiques et des références. DeerFlow est fourni avec des compétences pour la recherche, la génération de rapports, la création de diapositives, les pages web, et la génération d'images et de vidéos. Les compétences se chargent progressivement pour garder la fenêtre de contexte légère. La politique allowed-tools ne s'applique qu'après qu'une compétence est activée par slash ou chargée via read_file ; activer ou lister une compétence ne réduit pas l'ensemble d'outils normal de l'agent. Le README précise qu'il s'agit d'un cadrage comportemental au mieux, pas d'une frontière de sécurité stricte. DeerFlow prend également en charge les sous-agents, les objectifs de session, la compaction manuelle du contexte, la mémoire à long terme et un système de fichiers. Le README ne spécifie pas le nombre exact de compétences intégrées.
Le dépôt doit être lu comme une documentation opératoire, pas comme une preuve de compatibilité universelle. Les détails retenus ici viennent du README et des fichiers de configuration indiqués par le projet. Lorsqu’une valeur n’est pas documentée, elle reste à vérifier dans un environnement isolé. Cette distinction est importante pour éviter de transformer une commande d’exemple en engagement de production. Les dépendances, les permissions et la version annoncée peuvent modifier le résultat obtenu. Pour deer-flow, le contrôle utile consiste à relier mesurer la qualité plutôt que la promesse à une sortie observable : journal, fichier produit, route appelée, certificat présenté ou état d’un service. Le dépôt ne fournit pas nécessairement toutes les garanties nécessaires à un usage sensible ; il faut documenter l’écart au lieu de le combler par une supposition.
Conclusion éditoriale
deer-flow convient à une équipe qui accepte ses dépendances et ses limites documentées ; il ne convient pas à un déploiement qui exige des garanties absentes du README. Avant adoption, exécutez le chemin propre à ce dépôt, vérifiez les fichiers et commandes cités dans l’article, puis contrôlez le résultat observable et les permissions associées.
Notes de la communauté