Agents LangChain en 2026 : ReAct, LangGraph et modèles de production

AgentExecutor vs LangGraph : ce qui a changé et pourquoi c'est important

Comprendre le chemin de migration nécessite de comprendre pourquoi AgentExecutor a été retiré. Ce n'était pas arbitraire : cela touchait aux limites architecturales fondamentales lorsque les développeurs essayaient de créer des systèmes de production.

La limitation AgentExecutor la plus douloureuse était l'incapacité de faire une pause à mi-parcours et de reprendre plus tard. Tout flux de travail réel – pensez « rédigez un rapport, attendez l'approbation humaine, puis publiez » - nécessite un état persistant au-delà des limites temporelles. Le point de contrôle de LangGraph résout ce problème de manière native.

Le modèle ReAct : raisonner + agir en boucle

ReAct (Reason + Act) est le modèle d'incitation fondamental derrière la plupart des agents LangChain. Il demande au LLM d'alterner entre deux modes : Pensée (raisonnement interne sur ce qu'il faut faire ensuite) et Action (appel d'un outil spécifique avec des arguments spécifiques).

En pratique, la boucle ressemble à ceci :

1. Pensée: Le LLM raisonne sur la demande de l'utilisateur et les outils disponibles.
2. Action: Le LLM génère un appel d'outil structuré (nom + arguments).
3. Observation: L'outil exécute et renvoie un résultat, ajouté au contexte.
4. J'ai encore pensé : Le LLM raisonne sur l’observation.
5. Réponse finale : Lorsque le LLM détermine qu’il dispose de suffisamment d’informations, il génère la réponse finale.

Dans LangGraph, chacune de ces étapes est un nœud dans un graphique. L'arête conditionnelle après la vérification du nœud LLM : "le modèle a-t-il appelé un outil ou a-t-il généré une réponse finale ?" - et les itinéraires en conséquence. Cela rend la boucle ReAct explicite et inspectable plutôt qu'implicite dans un exécuteur boîte noire.

Les LLM modernes (GPT-4o, Claude 3.7, Gemini 2.5) gèrent ReAct de manière native via leurs API d'appel de fonctions/d'utilisation d'outils. Vous n'avez plus besoin de formater manuellement les chaînes « Pensée/Action/Observation » : la capacité d'utilisation des outils du modèle gère cela au niveau de l'API. LangGraph enveloppe cela proprement afin que vos nœuds restent concentrés sur la logique métier.

Construire un agent LangGraph étape par étape

Voici le modèle d'agent LangGraph minimal en Python. Chaque agent de production est une variation de ce squelette.

1. Définir l'état

L’État est la source unique de vérité qui traverse chaque nœud. Utilisez TypedDict ou un modèle Pydantic :

from typing import Annotated, Sequence
from langchain_core.messages import BaseMessage
from langgraph.graph.message import add_messages
from typing_extensions import TypedDict

class AgentState(TypedDict):
    messages: Annotated[Sequence[BaseMessage], add_messages]
    # add any custom fields your agent needs
    context: str
    iteration_count: int

2. Définir les outils

Les outils sont de simples fonctions Python décorées avec @tool. La docstring devient la description de l'outil que le LLM voit :

from langchain_core.tools import tool

@tool
def search_web(query: str) -> str:
    """Search the web for current information about a topic."""
    # your search implementation here
    return results

@tool
def write_file(filename: str, content: str) -> str:
    """Write content to a file on disk."""
    with open(filename, 'w') as f:
        f.write(content)
    return f"Written {len(content)} chars to {filename}"

tools = [search_web, write_file]

3. Construisez le graphique

from langgraph.graph import StateGraph, END
from langgraph.prebuilt import ToolNode
from langchain_openai import ChatOpenAI

llm = ChatOpenAI(model="gpt-4o").bind_tools(tools)

def agent_node(state: AgentState):
    response = llm.invoke(state["messages"])
    return {"messages": [response]}

def should_continue(state: AgentState):
    last_message = state["messages"][-1]
    if last_message.tool_calls:
        return "tools"
    return END

graph = StateGraph(AgentState)
graph.add_node("agent", agent_node)
graph.add_node("tools", ToolNode(tools))
graph.set_entry_point("agent")
graph.add_conditional_edges("agent", should_continue)
graph.add_edge("tools", "agent")

app = graph.compile()

4. Ajouter un point de contrôle pour la persistance

from langgraph.checkpoint.sqlite import SqliteSaver

checkpointer = SqliteSaver.from_conn_string("./agent_memory.db")
app = graph.compile(checkpointer=checkpointer)

# Now every run is persisted and resumable
config = {"configurable": {"thread_id": "user-session-123"}}
result = app.invoke({"messages": [("human", "Research LangGraph and write a summary")]}, config)

LangGraph en JavaScript / TypeScript : parité complète des fonctionnalités

Depuis 2026, @langchain/langgraph a une parité complète de fonctionnalités avec le SDK Python. Si vous créez des backends Node.js, des actions de serveur Next.js ou des routes API Nuxt, vous êtes entièrement pris en charge.

import { StateGraph, END } from "@langchain/langgraph";
import { ChatOpenAI } from "@langchain/openai";
import { tool } from "@langchain/core/tools";
import { z } from "zod";

// Define a tool with Zod schema
const searchWeb = tool(
  async ({ query }) => {
    const results = await yourSearchFunction(query);
    return results;
  },
  {
    name: "search_web",
    description: "Search the web for current information",
    schema: z.object({ query: z.string() }),
  }
);

// State type
interface AgentState {
  messages: BaseMessage[];
}

const llm = new ChatOpenAI({ model: "gpt-4o" }).bindTools([searchWeb]);

// Build graph — identical pattern to Python
const graph = new StateGraph<AgentState>({ channels: messagesStateReducer })
  .addNode("agent", async (state) => ({
    messages: [await llm.invoke(state.messages)],
  }))
  .addNode("tools", new ToolNode([searchWeb]))
  .addEdge("__start__", "agent")
  .addConditionalEdges("agent", shouldContinue)
  .addEdge("tools", "agent");

const app = graph.compile();

Le SDK JS/TS prend en charge les mêmes points de contrôle (en mémoire pour le développement, PostgreSQL pour la production), la même API de streaming (streamEvents) et la même intégration de traçage LangSmith. Le modèle mental se transfère directement entre les langues.

Architectures multi-agents : orchestrateurs et sous-graphes

Les systèmes mono-agent atteignent rapidement leurs limites : les fenêtres contextuelles débordent, la spécialisation en souffre et les tâches complexes nécessitent une coordination. En 2026, les déploiements de production LangGraph utilisent presque toujours des modèles multi-agents.

Les trois modèles fondamentaux

LangGraph implémente des systèmes multi-agents via composition du sous-graphe. Chaque agent spécialisé est un graphe compilé qui est intégré en tant que nœud dans le graphe de l'orchestrateur parent. L'état peut circuler entre les niveaux et chaque sous-graphe peut avoir son propre point de contrôle et sa propre mémoire.

Modèles de production : ce que les démos de jouets ne vous montrent pas

Faire fonctionner un agent LangGraph dans un notebook Jupyter est une chose. L’exécuter de manière fiable à grande échelle en est une autre. Voici les modèles qui séparent le prototype de la production.

Gestion des erreurs et logique de nouvelle tentative

Les pannes des outils sont inévitables : limites de débit, délais d'attente du réseau, sorties mal formées. LangGraph vous offre deux leviers : un try/catch au niveau du nœud qui renvoie un message d'erreur au LLM (le laissant récupérer facilement) et des politiques de nouvelle tentative au niveau du graphique sur les bords.

Limites d'itération

Always set recursion_limit when compiling. Sans cela, un LLM confus peut boucler indéfiniment et brûler votre budget API. Une valeur par défaut raisonnable est de 25 itérations pour la plupart des tâches.

app = graph.compile(checkpointer=checkpointer)
# Invoke with recursion limit
result = app.invoke(
    {"messages": [("human", query)]},
    config={"recursion_limit": 25, "configurable": {"thread_id": thread_id}}
)

Interruptions humaines dans la boucle

Les options de compilation interrupt_before et interrupt_after de LangGraph vous permettent de suspendre l'exécution sur des nœuds spécifiques, de présenter l'état actuel à un humain, de collecter des entrées et de reprendre. Ceci est indispensable pour les flux de travail d’approbation, les étapes de révision du contenu et les appels d’outils à enjeux élevés.

Streaming pour une UX en temps réel

Pour les applications destinées aux utilisateurs, le streaming n’est pas négociable. Le astream_events de LangGraph vous donne des événements granulaires : quel nœud est en cours d'exécution, quel outil a été appelé et la sortie LLM jeton par jeton. Connectez-le aux événements envoyés par le serveur (SSE) ou aux WebSockets pour une progression en direct dans votre interface utilisateur.

Observabilité avec LangSmith

Définissez LANGCHAIN_TRACING_V2=true et chaque exécution d'agent obtient une trace complète : quels nœuds ont été déclenchés, ce que le LLM a vu, ce que chaque outil a renvoyé, la latence totale et les coûts des jetons. C'est ainsi que vous déboguez le message « Pourquoi a-t-il appelé le mauvais outil ? » classe de bogues de production - pas d'instructions d'impression.

Cas d'utilisation réels des agents LangChain en 2026

Les modèles ci-dessus débloquent un large éventail d’applications de production. Voici les catégories dans lesquelles les agents LangGraph offrent aujourd’hui une réelle valeur ajoutée.

Comment choisir la bonne architecture d'agent pour votre cas d'utilisation

Tous les problèmes ne nécessitent pas un graphe multi-agent complexe. Voici un cadre de décision basé sur ce que vous essayez réellement de construire.

Une heuristique pratique : commencez par le modèle le plus simple qui pourrait éventuellement fonctionner, instrumentez avec LangSmith, puis identifiez le goulot d'étranglement. Les ingénieurs qui conçoivent dès le départ en fonction de la complexité sur-conçoivent presque toujours leur premier système d’agent. Les modèles de LangGraph facilitent la transition vers des architectures plus complexes à mesure que les exigences deviennent claires.

Foire aux questions

Réflexions finales : LangGraph est la norme pour les agents en 2026

Les « agents LangChain » que vous devriez construire en 2026 sont des machines à états LangGraph. L’ère obsolète AgentExecutor est révolue. L'état explicite de LangGraph, le routage conditionnel, les points de contrôle persistants et la composition multi-agents native ne sont pas des atouts : ce sont des conditions préalables à tout ce à quoi vous pourriez faire confiance en production.

Le modèle ReAct reste le bon point de départ pour la plupart des tâches. Ajoutez de la complexité multi-agents uniquement lorsqu’un seul agent atteint manifestement ses limites. Instrumentez tout avec LangSmith dès le premier jour : le débogage sans traces est le moyen le plus rapide de perdre une semaine sur un problème qui prend 10 minutes à diagnostiquer avec visibilité.

Le changement le plus important est conceptuel : les agents LangGraph ne sont pas des chatbots dotés d'outils intégrés. Ce sont des systèmes persistants et dynamiques dans lesquels un LLM gère le flux de contrôle. Concevez-les comme des systèmes distribués – avec des modes de défaillance, une logique de nouvelle tentative, des limites d'état et une observabilité – et ils vous récompenseront avec une fiabilité qui surprendra même les ingénieurs expérimentés.

Si vous créez une automatisation de contenu, des pipelines de référencement ou des flux de travail de recherche en plusieurs étapes, EasyClaw est le moyen le plus rapide de voir ces modèles en action, sans passer des semaines à câbler vous-même l'infrastructure.