Le framework DeepAgents de LangChain

 (blog.langchain.com)
21 points par GN⁺ 2025-08-07 | 1 commentaires | Partager sur WhatsApp
  • Les agents LLM traditionnels reposent généralement sur une architecture d’« agents superficiels » (shallow agents) qui se contentent d’appeler des outils de façon répétée, tandis que les Deep Agents sont des agents IA planifiés et structurés capables de résoudre en profondeur des tâches complexes et de long terme
  • Les agents récents comme Deep Research, Manus, Claude Code implémentent des « agents profonds » capables d’explorer les sujets plus en profondeur et de mieux gérer le contexte
    • Prompts système détaillés, outils de planification, sous-agents et utilisation du système de fichiers constituent le cœur des « agents profonds »
  • LangChain a publié le package open source deepagents afin que chacun puisse facilement créer son propre deep agent adapté à son vertical (domaine)
    • Il permet de configurer des prompts, outils et sous-agents personnalisés, et fournit un framework générique applicable à de nombreux domaines comme la recherche ou le développement

Les limites des agents LLM traditionnels et les caractéristiques des Deep Agents

  • Agent traditionnel : le LLM tourne en boucle et n’appelle que des outils → adapté seulement à un contexte court et à des tâches simples et de courte durée
  • Deep Agents : capables de décomposer, planifier, suivre et coordonner eux-mêmes des objectifs de long terme et des tâches complexes

Les 4 éléments qui composent les Deep Agents

  1. Prompt système détaillé

    • Comme dans des cas représentatifs tels que Claude Code, utilisation de prompts décrivant en détail les méthodes d’usage des outils et des exemples de comportement
    • Des instructions complexes et des exemples few-shot favorisent une réflexion et une exécution plus « profondes »

  2. Outil de planification

    • Même sans fonctionnalité réelle, intégrer à la routine un outil de planification comme une liste de tâches permet de maintenir la gestion du contexte et la capacité d’exécution
    • Même un no-op (qui n’effectue aucune action) peut fournir du contexte via le prompt

  3. Sous-agents (Sub Agents)

    • Création et découpage en sous-agents selon les sous-tâches, chaque agent travaillant séparément avant l’intégration des résultats
    • Les problèmes vastes ou complexes peuvent ainsi être traités via une structure parallèle et distribuée

  4. Système de fichiers

    • Utilisé non seulement pour les opérations sur fichiers, mais aussi comme espace de stockage des notes et du contexte
    • Plusieurs agents et sous-agents partagent le système de fichiers pour collaborer et conserver le contexte sur la durée

Le framework Deep Agents de LangChain : deepagents

  • Package Python open source (pip install deepagents), avec configuration possible de prompts, outils et sous-agents personnalisés
    • Prompt système inspiré de Claude Code, adapté pour être plus généraliste
    • Outil de planification sous forme de liste ToDo no-op (comme dans Claude Code)
    • Création de sous-agents et personnalisation possibles
    • Système de fichiers virtuel fondé sur les concepts de LangGraph (en utilisant l’état de l’agent)
  • Un exemple d’agent de deep research est fourni, ce qui permet de créer facilement des agents spécialisés par vertical

Exemples d’usage et valeur apportée

  • Optimisé pour les travaux IA longs et complexes comme la recherche, le développement, la génération de code, la recherche d’information ou l’automatisation complexe
  • Une conception détaillée du contexte et une structure de répartition du travail permettent de produire des résultats plus approfondis
  • Chacun peut construire un « deep agent » adapté à son domaine — une nouvelle étape dans l’usage de l’IA

À lire aussi

1 commentaires

 
GN⁺ 2025-08-07
Avis Hacker News

  • J’en suis l’auteur. Ces derniers temps, je trouve frappant de voir à quel point une série d’agents comme Claude Code, Manus ou Deep Research exécutent particulièrement bien des tâches qui s’étendent sur une longue durée. En pratique, en interne, le LLM boucle et appelle des outils. Mais si on fait ça sans réfléchir, on se retrouve avec le problème que le LLM n’arrive pas correctement à mener à bien des tâches complexes ou longues. Je me suis donc demandé comment les autres agents s’y prenaient. Les points communs que j’ai observés sont les suivants : 1) ils utilisent un outil de planification 2) ils utilisent des sous-agents 3) ils utilisent une structure qui déporte le contexte, comme un système de fichiers 4) ils conçoivent des prompts système détaillés (le prompt engineering reste important). Chacun de ces éléments existait déjà, mais ce ne sont pas forcément des méthodes largement employées en pratique quand on développe des agents. À mon avis, c’est justement cette combinaison qui constitue l’insight important. Tous les retours sont bienvenus

  • En réfléchissant aux différents avis, je suis d’accord sur le fait que le concept de deep agents ne diffère au fond pas tant que ça d’une combinaison agent + outils. Pour moi, les points clés sont les suivants : 1) pour les connaissances de base, il faut utiliser un bon LLM 2) le prompt pour guider correctement le LLM est important (le transformer en agent) 3) les fonctions qui ne demandent pas de jugement particulier doivent être implémentées comme des outils 4) quand le flux agent+outil devient complexe, il faut le découper en sous-agents, chacun avec un prompt ciblé et peu d’outils, afin de séparer les domaines

    • Au final, j’ai l’impression que ça va évoluer vers un modèle de « coordinateur » où l’agent de plus haut niveau choisit ce qu’il faut faire et délègue à l’agent le plus adapté à cette tâche. Cette structure peut se prolonger récursivement (par exemple : un agent par produit, puis cet agent se subdivise en agents chargés du frontend et du backend). Dans ce type d’architecture, les agents qui exécutent réellement le travail peuvent se concentrer sur un contexte et des outils limités, tandis que l’agent supérieur n’a besoin de connaître que ce que ses sous-agents savent faire

  • Je pense que deep agents = un agent avec de la planification ajoutée + une combinaison d’outils d’agent, donc au final c’est proche des agents existants. Je trouve dommage que LangChain emballe toujours des concepts simples de manière compliquée et crée sans raison de nouveaux termes ou concepts pour faire sa promo. Bon, j’imagine que c’est inévitable s’ils veulent mieux vendre LangSmith

    • Avant, je faisais ce genre de consulting. Ce n’est peut-être pas strictement identique, mais sur le fond c’est une ficelle très classique. On met en scène quelque chose de banal, on invente sa propre terminologie et sa propre taxonomie, puis on vend le tout. L’étape suivante, c’est d’inonder le SEO avec son concept. Il suffit de surfer sur des mots-clés populaires comme deep * et agent… Quand on pense à ce genre de choses, on a au fond l’impression que l’environnement d’entreprise vide un peu de son âme

  • C’est à peu près le résultat auquel je m’attendais. Maintenant qu’il est clair qu’écrire soi-même un serveur MCP n’apporte plus grand-chose, il faut une nouvelle méthode qui permette de surfer rapidement sur la tendance. Construire directement un agent, comme Gemini ou Claude Code, est la tendance du moment. La barrière à l’entrée est faible, c’est utile jusqu’à un certain point, ça ne demande pas une expertise IA très poussée, et c’est facile à promouvoir. C’est un peu le modèle du « cursor for X », sauf qu’on peut le mettre en produit encore plus vite. Je pense qu’on va voir énormément d’agents de codage construits de cette façon, mais pour l’instant, ça ne donne pas encore vraiment une impression de nouveauté. Cela dit, le fait de pouvoir démarrer aussi vite me rend plutôt optimiste sur un point : la valeur d’un clone intuitif de Claude Code va bientôt tendre vers zéro

  • Je suis en train d’analyser ce dépôt en le suivant de près https://github.com/ghuntley/claude-code-source-code-deobfuscation L’auteur a fait de la rétro-ingénierie de Claude Code et en explique bien l’architecture. J’ai remplacé le lien par un meilleur dépôt

    • Quelqu’un peut expliquer ce que ça montre exactement ? J’ai l’impression de ne voir qu’un énorme readme et des commandes système

  • Je construis un agent cli+library générique en rust : https://github.com/fdietze/alors C’est encore très tôt dans le développement, mais je m’en sers déjà pour le développer lui-même. Les retours sont bienvenus

  • À mes yeux, c’est Junie de JetBrains qui a été le premier à proposer une fonction de to do list vraiment de très haute qualité, et c’est ce que j’ai le plus apprécié. Je ne l’ai plus utilisé depuis que c’est devenu payant, mais à l’époque Junie était lent et prudent. Cursor réécrivait sans arrêt même des fichiers sans problème, et Claude donnait une impression intermédiaire

    • Cursor propose aussi une UI dédiée pour la todo list et pousse l’agent à l’utiliser (l’UX est bonne, mais on ne peut pas consulter directement le fichier). Kiro d’Amazon utilise une approche où tasks.md sert à gérer à la fois les tâches à faire et les spécifications. Comme il y a de plus en plus d’outils, chacun peut choisir celui qui lui convient

  • La partie la plus intéressante est complètement cachée. Le vrai sujet, c’est la manière dont ils gèrent les tool calls, du parsing jusqu’à l’exécution

  • Le vrai point innovant, c’est l’isolation du contexte via les sous-agents. Le reste, c’est juste un agent ReAct LangGraph

    • C’est utile, mais ce n’est pas non plus une idée totalement nouvelle

  • Je me demande s’il y a plus d’informations sur le fait que l’outil de todo list soit un no-op. J’aimerais comprendre précisément comment ça fonctionne

    • Si tu veux le voir directement dans le code, notre agent Sketch utilise l’outil de TODO list de cette manière : https://github.com/boldsoftware/sketch/blob/main/claudetool/todo.go l’agent le faire utiliser est relativement simple. L’essentiel du travail consiste à le rendre visible dans l’UI
    • Même question. Je ne comprends pas bien ce que ça veut dire. Pourtant, ça semble clairement faire partie des raisons pour lesquelles Claude Code est excellent
    • À mon avis, c’est juste une simple fonction de concaténation. En pratique, les techniques de prompt utiles sont le plus souvent simples à implémenter. Ce qui est d’autant plus surprenant, c’est jusqu’où peut aller une idée aussi simple qu’une TODO ! (Dans un environnement sérieux, les frameworks d’agents restent difficiles : trouver la bonne combinaison et les bons réglages est vraiment compliqué, et côté infra il faut aussi gérer le multi-tenant, le multithreading, le streaming, l’annulation, etc.). Je suis tout à fait d’accord sur l’importance de la TODO list. Des choses comme le concours d’analyse de logs de sécurité de louie.ai vont aussi beaucoup plus vite grâce à cette méthode. Ça évite que le CoT s’effondre au bout de quelques tours. Le moment « aha » amusant, c’est que les TODO imbriquées (A.2.i...) fonctionnent bien, et du point de vue du LLM elles sont de toute façon linéarisées, donc ce n’est pas difficile à traiter. En interne, au lieu de Claude Code, nous gérons cela avec un prompt de plan de ce type : https://github.com/graphistry/louie-py/blob/main/ai/prompts/PLAN.md
    • Seul le fait qu’un tool call a eu lieu est enregistré dans le contexte. Les données réelles de la todo list, elles, ne sont pas réinjectées
    • D’après ce que j’ai compris, on peut grosso modo voir ça comme un prompt qui dit simplement d’écrire une TODO list