DeerFlow 2.0 : le « super agent harness » open source de ByteDance, qui réunit sous-agents, mémoire et bacs à sable dans un seul runtime

DeerFlow signifie Deep Exploration and Efficient Research Flow, et il a commencé comme un framework de recherche approfondie open source de ByteDance. Le README explique l'évolution : la communauté l'a poussé vers les pipelines de données, les présentations, les tableaux de bord et l'automatisation de contenu, des usages que l'équipe n'avait pas prévus. Elle en a conclu que DeerFlow n'était pas qu'un outil de recherche mais un harness, un runtime qui donne aux agents l'infrastructure pour accomplir un travail, et l'a réécrit de zéro. La 2.0 ne partage aucun code avec la 1.x ; le framework de recherche d'origine reste sur la branche 1.x, et le développement actif est passé à la 2.0. Le README ajoute que, après la sortie de la 2.0, DeerFlow a pris la première place de GitHub Trending le 28 février 2026. Au 13 octobre 2026, le dépôt compte environ 83 766 étoiles et 11 654 forks, une licence MIT, du code Python, une création le 7 mai 2025 et une dernière poussée le 13 octobre. Selon la définition du README, DeerFlow 2.0 n'est plus un framework à assembler mais un super agent harness, piles incluses et entièrement extensible. Bâti sur LangGraph et LangChain, il fournit un système de fichiers, une mémoire, des compétences, une exécution consciente des bacs à sable et la capacité de planifier et d'engendrer des sous-agents pour des tâches complexes en plusieurs étapes. Il est agnostique au modèle et fonctionne avec tout LLM implémentant une API compatible OpenAI, mais donne le meilleur avec de longues fenêtres de contexte (plus de 100 k jetons), du raisonnement, des entrées multimodales et un solide usage d'outils ; le README recommande vivement Doubao-Seed-2.0-Code, DeepSeek v3.2 et Kimi 2.5. Pour la recherche et l'exploration du web, il intègre InfoQuest, un jeu d'outils que BytePlus de ByteDance a développé lui-même, avec un essai en ligne gratuit. Les fonctions centrales se regroupent en plusieurs blocs. Compétences et outils : un Capability Center dans la barre latérale gère les plugins (serveurs MCP et intégration Lark/Feishu) et les compétences, avec les compétences intégrées séparées de celles créées ou importées, et un onglet Community qui importe des archives .skill. Sous-agents : chacun s'exécute par défaut dans un contexte isolé qui ne voit ni l'agent principal ni les autres sous-agents, pour rester concentré sur sa tâche ; les appels task acceptent les modes isolated (défaut) et snapshot, ce dernier remettant au sous-agent la conversation retenue du parent et son résumé de compactage comme historique, au prix de jetons d'entrée supplémentaires. Ingénierie du contexte : dans une session, il résume les sous-tâches terminées, décharge les résultats intermédiaires vers le système de fichiers et comprime ce qui n'est plus utile, afin que les longues tâches en plusieurs étapes ne saturent pas la fenêtre ; les sorties d'outils ont des budgets d'aperçu et des synthèses structurées. La mémoire à long terme relève d'un composant nommé DeerMem, avec antirebond par conversation, utilisateur et agent, une période de calme par défaut de 30 secondes et une attente maximale de 300 secondes. S'y ajoutent des objectifs de session, un compactage manuel du contexte, une archive de discussions, des projets avec étagère de documents, des tâches planifiées (heures cron prévisualisables, cycle de vie et plafonds de sécurité), un client Python embarqué et un atelier de terminal.

Le README est détaillé sur l'exécution. Le démarrage rapide configure d'abord un modèle, puis propose Docker (recommandé) ou le développement local, avec LangGraph Studio en option pour le débogage ; des sections dédiées couvrent la mise à jour d'une copie existante, plusieurs fournisseurs, les actions de flux sur des exécutions existantes et les jetons d'accès personnels. La section sur le bac à sable mérite l'attention. Les bacs à sable AIO sont recyclés après un résultat de shell implicite incertain ou après la création d'une session, et avant le recyclage la passerelle consigne l'identifiant du conteneur ou l'UID du Pod dans un répertoire de quarantaine, des enregistrements qui survivent aux arrêts échoués et aux redémarrages de la passerelle. Les anciens enregistrements ne sont retirés qu'après confirmation par le backend qu'aucun conteneur ni Pod ne subsiste ; un accusé de suppression ou un échec de contrôle de santé ne suffit pas. Un traitement aussi prudent des chemins d'échec suggère un outil écrit pour un usage long et sans surveillance.

Le chapitre de sécurité est à lire en premier. Le README dit que DeerFlow dispose de capacités à privilèges élevés (exécution de commandes système, opérations sur les ressources, appel de logique métier) et est conçu par défaut pour un environnement local de confiance, accessible seulement par la boucle locale 127.0.0.1. Déployé sur un réseau local, un serveur cloud public ou un environnement multi-terminaux sans mesures strictes, il expose à des appels non autorisés, au déclenchement en masse d'opérations à risque dès qu'un scanner d'internet le trouve, et à des risques de conformité et juridiques. La pile Docker ne publie son port d'entrée que sur 127.0.0.1, et make dev et make start locaux se lient à la boucle locale. Pour l'atteindre depuis une autre machine, on définit BIND_HOST dans .env, mais seulement après avoir mis en place des mesures : liste d'adresses autorisées avec iptables ou des pare-feu matériels, authentification forte préalable via un proxy inverse comme nginx, et VLAN dédié. Une instance neuve n'a aucun compte : tout déploiement qui n'est pas limité à la boucle locale doit créer le compte administrateur via /setup dès le démarrage. Le README précise qu'un administrateur de passerelle peut enregistrer des serveurs MCP stdio, qui exécutent des commandes dans le conteneur de la passerelle ; l'API les restreint à une liste d'autorisation (npx et uvx par défaut) et rejette les arguments évaluant du code arbitraire, mais c'est une défense en profondeur, pas une frontière : l'administration de la passerelle équivaut à l'exécution de code sur l'hôte.

Notre lecture : ce qui vaut l'étude dans DeerFlow 2.0, ce sont ses arbitrages d'ingénierie, pas son nombre d'étoiles. Il documente des détails d'ordinaire cachés, comme l'isolement des sous-agents, la synthèse du contexte, le délestage vers le système de fichiers et le recyclage des bacs à sable, ce qui en fait une référence rare pour qui bâtit une infrastructure d'agents. Trois réserves. Le README est très long et évolue vite, et de nombreuses sections décrivent le comportement du code actuel : vérifiez votre version avant de déployer. Sa puissance et son risque viennent de la même chose, exécuter des commandes et lire et écrire des fichiers : ne modifiez pas à la légère la liaison par défaut à la boucle locale. Et ses recommandations de modèles ont une inclinaison visible vers certains fournisseurs ; le résultat réel dépend du modèle et de la tâche. Lancez-le d'abord dans un conteneur isolé sur un répertoire ne contenant que des données de test, puis décidez de connecter ou non des données réelles et des canaux externes.