Leçons tirées de la mise à niveau vers LangChain 1.0 en production

première version stable v1.0 fin octobre 2025. Après avoir passé les deux derniers mois à travailler avec leurs nouvelles API, je pense sincèrement qu’il s’agit de la version la plus cohérente et la plus réfléchie de LangChain à ce jour.

Je n’ai pas toujours été un fan de LangChain. Les premières versions étaient fragiles, mal documentées, les abstractions changeaient fréquemment et cela semblait trop prématuré pour être utilisé en production. Mais la version 1.0 semblait plus intentionnelle et disposait d’un modèle mental plus cohérent sur la manière dont les données devaient circuler via les agents et les outils.

Ce n’est-ce pas un post sponsorisé au fait — j’aimerais entendre vos commentaires, n’hésitez pas à m’envoyer un message privé ici!

Cet article n’est pas là pour régurgiter la documentation. Je suppose que vous avez déjà essayé LangChain (ou que vous êtes un gros utilisateur). Plutôt que de dresser une longue liste de points, je vais sélectionner seulement quatre points clés.

Un bref récapitulatif : LangChain, LangGraph & LangSmith

À un niveau élevé, LangChain est un cadre permettant de créer des applications et des agents LLM, permettant aux développeurs de proposer rapidement des fonctionnalités d’IA avec des abstractions communes.

LangGraph est le moteur d’exécution basé sur des graphiques pour des flux de travail d’agent durables et dynamiques de manière contrôlable. Enfin, LangSmith est une plateforme d’observabilité pour le traçage et la surveillance.

En termes simples : LangChain vous aide à créer des agents rapidement, LangGraph les exécute de manière fiable et LangSmith vous permet de les surveiller et de les améliorer en production.

Ma pile

Pour le contexte, la plupart de mes travaux récents se concentrent sur la création de fonctionnalités multi-agents pour une plate-forme d’IA orientée client au travail. Ma pile backend est FastAPI, avec Pydantic alimentant la validation de schéma et les contrats de données.

Leçon 1 : Abandon du support pour les modèles Pydantic

Un changement majeur dans la migration vers la v1.0 a été l’introduction du nouveau create_agent méthode. Il rationalise la façon dont les agents sont définis et appelés, mais il supprime également la prise en charge des modèles Pydantic et des classes de données dans l’état de l’agent. Tout doit maintenant être exprimé sous forme de TypedDicts étendant AgentState.

Si vous utilisez FastAPI, Pydantic est souvent le validateur de schéma recommandé et par défaut. J’ai apprécié la cohérence des schémas dans la base de code et j’ai estimé que mélanger les modèles TypedDicts et Pydantic créerait inévitablement de la confusion, en particulier pour les nouveaux ingénieurs qui ne sauraient peut-être pas quel format de schéma suivre.

Pour résoudre ce problème, j’ai introduit un petit assistant qui convertit un modèle Pydantic en un TypedDict qui étend AgentState juste avant qu’il ne soit transmis à create_agent . Il est essentiel de noter que LangChain attache des métadonnées personnalisées aux annotations de type que vous devez conserver. Des utilitaires Python comme get_type_hints() supprimez ces annotations, ce qui signifie qu’une conversion naïve ne fonctionnera pas.

Leçon 2 : Les agents profonds sont opiniâtres par conception

Aux côtés du nouveau create_agent L’API de LangChain 1.0 a attiré mon attention : le deepagents bibliothèque. Inspirés par des outils comme Claude Code et Manus, les agents profonds peuvent planifier, diviser les tâches en étapes et même générer des sous-agents.

Quand j’ai vu ça pour la première fois, j’ai voulu l’utiliser partout. Pourquoi ne voudriez-vous pas d’agents « plus intelligents », n’est-ce pas ? Mais après l’avoir essayé sur plusieurs workflows, j’ai réalisé que cette autonomie supplémentaire était parfois inutile – et dans certains cas, contre-productive – pour mes cas d’utilisation.

Le deepagents la bibliothèque est assez opiniâtre, et en grande partie intentionnelle. Chaque agent profond est livré avec un middleware intégré, comme ToDoListMiddleware, FilesystemMiddleware, SummarizationMiddlewareetc. Ceux-ci façonnent la façon dont l’agent pense, planifie et gère le contexte. Le problème, c’est que vous je ne peux pas contrôler exactement lorsque ces middlewares par défaut sont exécutés, vous ne pouvez pas non plus désactiver ceux dont vous n’avez pas besoin.

Après avoir fouillé dans deepagents code source icivous pouvez voir que le paramètre middleware est supplémentaire middleware à appliquer après le middleware standard. Tout middleware transmis middleware=[...] est ajouté après les valeurs par défaut.

Toute cette orchestration supplémentaire a également introduit une latence notable et peut ne pas apporter d’avantages significatifs. Donc, si vous souhaitez un contrôle plus granulaire, restez avec le plus simple create_agent méthode.

Je ne dis pas que les agents profonds sont mauvais, ils sont puissants dans les bons scénarios. Cependant, c’est un bon rappel d’un principe d’ingénierie classique : ne courez pas après le « brillant ». Utilisez la technologie qui résout votre problème réel, même s’il s’agit de l’option « la moins glamour ».

Ma fonctionnalité préférée : sortie structurée

Après avoir déployé des agents en production, en particulier ceux qui s’intègrent aux systèmes d’entreprise déterministes, il était crucial d’amener les agents à produire systématiquement le résultat d’un schéma spécifique.

LangChain 1.0 rend cela assez simple. Vous pouvez définir un schéma (par exemple, un modèle Pydantic) et le transmettre à create_agent via le response_format paramètre. L’agent produit ensuite une sortie conforme à ce schéma dans une boucle à agent unique sans étapes supplémentaires.

Cela a été incroyablement utile chaque fois que j’ai besoin que l’agent adhère strictement à une structure JSON avec certains champs garantis. Jusqu’à présent, la sortie structurée s’est également révélée très fiable.

Ce que je souhaite explorer davantage : Middleware

L’une des parties les plus délicates de la création d’agents fiables est ingénierie du contexte— s’assurer que l’agent dispose toujours de la bonne information au bon moment. Le middleware a été introduit pour donner aux développeurs un contrôle précis sur chaque étape de la boucle des agents, et je pense que cela vaut la peine d’y approfondir.

Le middleware peut signifier différentes choses selon le contexte (jeu de mots). Dans LangGraph, cela peut signifier contrôler la séquence exacte d’exécution des nœuds. Dans les conversations de longue durée, cela peut impliquer de résumer le contexte accumulé avant le prochain appel LLM. Dans les scénarios impliquant une intervention humaine, le middleware peut suspendre l’exécution et attendre qu’un utilisateur approuve ou rejette un appel d’outil.

Plus récemment, dans la dernière version mineure v1.1, LangChain a également ajouté un middleware de nouvelle tentative de modèle avec une interruption exponentielle configurable, permettant une récupération gracieuse des erreurs transitoires des points de terminaison.

Personnellement, je pense que le middleware change la donne, car les flux de travail agents deviennent plus complexes, plus longs et plus dynamiques, en particulier lorsque vous avez besoin d’un contrôle plus fin ou d’une gestion robuste des erreurs.

Cette liste de middleware est croissance et il est vraiment utile qu’il reste indépendant du fournisseur. Si vous avez expérimenté le middleware dans votre propre travail, j’aimerais savoir ce que vous avez trouvé le plus utile !

Pour finir

C’est tout pour l’instant – quatre réflexions clés sur ce que j’ai appris jusqu’à présent sur LangChain. Et si quelqu’un de l’équipe LangChain lit ceci, je suis toujours heureux de partager les commentaires des utilisateurs à tout moment ou simplement de discuter 🙂

Amusez-vous à construire !