LangChain 1.0 et Milvus : comment créer des agents prêts pour la production avec une véritable mémoire à long terme

LangChain est un cadre populaire à code source ouvert pour le développement d'applications alimentées par de grands modèles de langage (LLM). Il fournit une boîte à outils modulaire pour construire des agents de raisonnement et d'utilisation d'outils, connecter des modèles à des données externes et gérer des flux d'interaction.

Avec la sortie de LangChain 1.0, le cadre fait un pas en avant vers une architecture plus conviviale pour la production. La nouvelle version remplace la conception antérieure basée sur la chaîne par une boucle ReAct normalisée (Raisonner → Appel d'outil → Observer → Décider) et introduit un intergiciel pour gérer l'exécution, le contrôle et la sécurité.

Cependant, le raisonnement seul n'est pas suffisant. Les agents doivent également pouvoir stocker, rappeler et réutiliser des informations. C'est là que Milvus, une base de données vectorielle open-source, peut jouer un rôle essentiel. Milvus fournit une couche de mémoire évolutive et performante qui permet aux agents de stocker, de rechercher et d'extraire des informations de manière efficace par le biais de la similarité sémantique.

Dans ce billet, nous verrons comment LangChain 1.0 met à jour l'architecture des agents et comment l'intégration de Milvus permet aux agents d'aller au-delà du raisonnement - en créant une mémoire persistante et intelligente pour des cas d'utilisation réels.

Pourquoi la conception basée sur la chaîne n'est pas à la hauteur

À ses débuts (version 0.x), l'architecture de LangChain était centrée sur les chaînes. Chaque chaîne définissait une séquence fixe et était livrée avec des modèles préconstruits qui rendaient l'orchestration LLM simple et rapide. Cette conception était idéale pour construire rapidement des prototypes. Mais au fur et à mesure que l'écosystème LLM évoluait et que les cas d'utilisation du monde réel devenaient plus complexes, des fissures dans cette architecture ont commencé à apparaître.

1. Manque de flexibilité

Les premières versions de LangChain fournissaient des pipelines modulaires tels que SimpleSequentialChain ou LLMChain, chacun suivant un flux fixe et linéaire - création d'un message → appel de modèle → traitement de sortie. Cette conception a bien fonctionné pour les tâches simples et prévisibles et a permis de créer rapidement des prototypes.

Toutefois, à mesure que les applications devenaient plus dynamiques, ces modèles rigides commençaient à sembler restrictifs. Lorsque la logique métier ne s'inscrit plus dans une séquence prédéfinie, deux options peu satisfaisantes s'offrent à vous : forcer votre logique à se conformer au cadre ou le contourner entièrement en appelant directement l'API LLM.

2. Absence de contrôle au niveau de la production

Ce qui fonctionnait bien dans les démonstrations se cassait souvent en production. Les chaînes n'incluaient pas les garanties nécessaires pour les applications à grande échelle, persistantes ou sensibles. Les problèmes les plus fréquents sont les suivants

• Débordement de contexte : Les longues conversations pouvaient dépasser les limites de jetons, provoquant des pannes ou une troncature silencieuse.

• Fuites de données sensibles : Des informations personnelles identifiables (comme des courriels ou des identifiants) peuvent être envoyées par inadvertance à des modèles tiers.

• Opérations non supervisées : Les agents peuvent supprimer des données ou envoyer des courriels sans l'approbation d'un humain.

3. Manque de compatibilité entre les modèles

Chaque fournisseur de LLM - OpenAI, Anthropic et de nombreux modèles chinois - met en œuvre ses propres protocoles de raisonnement et d'appel d'outils. Chaque fois que vous changiez de fournisseur, vous deviez réécrire la couche d'intégration : modèles d'invite, adaptateurs et analyseurs de réponse. Ce travail répétitif ralentissait le développement et rendait l'expérimentation pénible.

LangChain 1.0 : Un agent ReAct tout-en-un

Lorsque l'équipe LangChain a analysé des centaines d'implémentations d'agents de niveau production, une constatation s'est imposée : presque tous les agents performants convergeaient naturellement vers le modèle ReAct ("Reasoning + Acting").

Qu'il s'agisse d'un système multi-agents ou d'un agent unique effectuant un raisonnement approfondi, la même boucle de contrôle apparaît : alternance entre de brèves étapes de raisonnement et des appels d'outils ciblés, puis intégration des observations résultantes dans les décisions ultérieures jusqu'à ce que l'agent soit en mesure de fournir une réponse finale.

Pour s'appuyer sur cette structure éprouvée, LangChain 1.0 place la boucle ReAct au cœur de son architecture, ce qui en fait la structure par défaut pour construire des agents fiables, interprétables et prêts pour la production.

Pour prendre en charge tous les types d'agents, des plus simples aux plus complexes, LangChain 1.0 adopte une conception en couches qui allie facilité d'utilisation et contrôle précis :

• Scénarios standard : Commencez par la fonction create_agent() - une boucle ReAct propre et standardisée qui gère le raisonnement et les appels d'outils dès le départ.

• Scénarios étendus : Ajoutez un intergiciel pour obtenir un contrôle plus fin. Les intergiciels vous permettent d'inspecter ou de modifier ce qui se passe à l'intérieur de l'agent - par exemple, en ajoutant la détection des IPI, des points de contrôle d'approbation humaine, des tentatives automatiques ou des crochets de surveillance.

• Scénarios complexes : Pour les flux de travail avec état ou l'orchestration multi-agents, utilisez LangGraph, un moteur d'exécution basé sur un graphe qui permet un contrôle précis du flux logique, des dépendances et des états d'exécution.

Décortiquons maintenant les trois composants clés qui rendent le développement d'agents plus simple, plus sûr et plus cohérent d'un modèle à l'autre.

1. La fonction create_agent() : Une manière plus simple de construire des agents

L'une des principales avancées de LangChain 1.0 est la réduction de la complexité de la construction d'agents à une seule fonction - create_agent(). Vous n'avez plus besoin de gérer manuellement la gestion de l'état, la gestion des erreurs ou les sorties en continu. Ces fonctionnalités de niveau production sont désormais gérées automatiquement par le runtime LangGraph sous-jacent.

Avec seulement trois paramètres, vous pouvez lancer un agent entièrement fonctionnel :

• modèle - soit un identifiant de modèle (chaîne de caractères), soit un objet de modèle instancié.

• tools - une liste de fonctions qui donnent à l'agent ses capacités.

• system_prompt - l'instruction qui définit le rôle, le ton et le comportement de l'agent.

Sous le capot, create_agent() s'exécute sur la boucle standard d'un agent - appelant un modèle, le laissant choisir les outils à exécuter, et terminant une fois que plus aucun outil n'est nécessaire :

Il hérite également des capacités intégrées de LangGraph pour la persistance de l'état, la récupération des interruptions et le streaming. Les tâches qui nécessitaient auparavant des centaines de lignes de code d'orchestration sont désormais gérées par une API unique et déclarative.

from langchain.agents import create_agent
agent = create_agent(
    model="openai:gpt-4o",
    tools=[get_weather, query_database],
    system_prompt="You are a customer service assistant who helps users check the weather and order information."
)
result = agent.invoke({
    "messages": [{"role": "user", "content": "What’s the weather like in Shanghai today?"}]
})

2. L'intergiciel : Une couche composable pour un contrôle prêt à la production

L'intergiciel est la passerelle essentielle qui permet à LangChain de passer du prototype à la production. Il expose des crochets à des points stratégiques de la boucle d'exécution de l'agent, ce qui vous permet d'ajouter une logique personnalisée sans réécrire le processus central de ReAct.

La boucle principale d'un agent suit un processus de décision en trois étapes - Modèle → Outil → Terminaison :

LangChain 1.0 fournit quelques middlewares préconstruits pour des modèles courants. En voici quatre exemples.

• Détection des informations confidentielles : Toute application traitant des données sensibles de l'utilisateur

from langchain.agents import create_agent
from langchain.agents.middleware import PIIMiddleware
agent = create_agent(
model=“gpt-4o”,
tools=[],  # Add tools as needed
middleware=[
# Redact emails in user input
PIIMiddleware(“email”, strategy=“redact”, apply_to_input=True),
# Mask credit cards (show last 4 digits)
PIIMiddleware(“credit_card”, strategy=“mask”, apply_to_input=True),
# Custom PII type with regex
PIIMiddleware(
“api_key”,
detector=r"sk-[a-zA-Z0-9]{32}",
strategy=“block”,  # Raise error if detected
),
],
)

• Résumé : Résumer automatiquement l'historique des conversations lorsque la limite des jetons est atteinte.

from langchain.agents import create_agent
from langchain.agents.middleware import SummarizationMiddleware
agent = create_agent(
model=“gpt-4o”,
tools=[weather_tool, calculator_tool],
middleware=[
SummarizationMiddleware(
model=“gpt-4o-mini”,  #Summarize using a cheaper model  
max_tokens_before_summary=4000,  # Trigger summarization at 4000 tokens
messages_to_keep=20,  # Keep last 20 messages after summary
),
],
)

• Réessai d'outil : Réessayer automatiquement les appels d'outils qui n'ont pas abouti avec un délai exponentiel configurable.

from langchain.agents import create_agent
from langchain.agents.middleware import ToolRetryMiddleware
agent = create_agent(
    model="gpt-4o",
    tools=[search_tool, database_tool],
    middleware=[
        ToolRetryMiddleware(
            max_retries=3,  # Retry up to 3 times
            backoff_factor=2.0,  # Exponential backoff multiplier
            initial_delay=1.0,  # Start with 1 second delay
            max_delay=60.0,  # Cap delays at 60 seconds
            jitter=True,  # Add random jitter to avoid thundering herd (±25%)
    ),
],

)

• Middleware personnalisé

En plus des options officielles d'intergiciels préconstruits, vous pouvez également créer des intergiciels personnalisés en utilisant des décorateurs ou des classes.

Par exemple, l'extrait ci-dessous montre comment enregistrer les appels de modèle avant l'exécution :

from langchain.agents.middleware import before_model
from langchain.agents.middleware import AgentState
from langgraph.runtime import Runtime
@before_model
def log_before_model(state: AgentState, runtime: Runtime) -> dict | None:
    print(f"About to call model with {len(state['messages'])} messages")
    return None  # Returning None means the normal flow continues
agent = create_agent(
    model="openai:gpt-4o",
    tools=[...],
    middleware=[log_before_model],
)

3. Sortie structurée : Une manière standardisée de traiter les données

Dans le développement traditionnel d'agents, la sortie structurée a toujours été difficile à gérer. Chaque fournisseur de modèle le gère différemment - par exemple, OpenAI offre une API de sortie structurée native, tandis que d'autres ne prennent en charge les réponses structurées qu'indirectement par le biais d'appels d'outils. Cela signifiait souvent qu'il fallait écrire des adaptateurs personnalisés pour chaque fournisseur, ce qui ajoutait du travail supplémentaire et rendait la maintenance plus pénible qu'elle ne devrait l'être.

Dans LangChain 1.0, la sortie structurée est gérée directement par le paramètre response_format de la fonction create_agent(). Vous n'avez besoin de définir votre schéma de données qu'une seule fois. LangChain choisit automatiquement la meilleure stratégie d'application en fonction du modèle que vous utilisez - aucune configuration supplémentaire ou code spécifique au fournisseur n'est nécessaire.

from langchain.agents import create_agent
from pydantic import BaseModel, Field
class WeatherReport(BaseModel):
    location: str = Field(description="City name")
    temperature: float = Field(description="Temperature (°C)")
    condition: str = Field(description="Weather condition")
agent = create_agent(
    model="openai:gpt-4o",
    tools=[get_weather],
    response_format=WeatherReport  # Use the Pydantic model as the response schema
)
result = agent.invoke({"role": "user", "content": "What’s the weather like in Shanghai today??"})
weather_data = result['structured_response']  # Retrieve the structured response
print(f"{weather_data.location}: {weather_data.temperature}°C, {weather_data.condition}")

LangChain prend en charge deux stratégies pour les sorties structurées :

1. Stratégie du fournisseur : Certains fournisseurs de modèles prennent nativement en charge la sortie structurée via leurs API (par exemple OpenAI et Grok). Lorsqu'un tel support est disponible, LangChain utilise directement l'application du schéma intégré du fournisseur. Cette approche offre le plus haut niveau de fiabilité et de cohérence, puisque le modèle lui-même garantit le format de sortie.

2. Stratégie d'appel d'outils : Pour les modèles qui ne supportent pas les sorties structurées natives, LangChain utilise le Tool Calling pour obtenir le même résultat.

Vous n'avez pas à vous soucier de la stratégie utilisée : le cadre détecte les capacités du modèle et s'adapte automatiquement. Cette abstraction vous permet de passer librement d'un fournisseur de modèle à l'autre sans modifier votre logique métier.

Comment Milvus améliore la mémoire des agents

Pour les agents de niveau production, le véritable goulot d'étranglement des performances n'est souvent pas le moteur de raisonnement, mais le système de mémoire. Dans LangChain 1.0, les bases de données vectorielles jouent le rôle de mémoire externe de l'agent et permettent une mémorisation à long terme grâce à la récupération sémantique.

Milvus est l'une des bases de données vectorielles open-source les plus matures disponibles aujourd'hui, conçue pour la recherche vectorielle à grande échelle dans les applications d'intelligence artificielle. Elle s'intègre nativement à LangChain, de sorte que vous n'avez pas à gérer manuellement la vectorisation, la gestion de l'index ou la recherche de similarité. Le package langchain_milvus intègre Milvus comme une interface VectorStore standard, vous permettant de le connecter à vos agents avec seulement quelques lignes de code.

Ce faisant, Milvus relève trois défis majeurs dans la construction de systèmes de mémoire d'agents évolutifs et fiables :

1. Extraction rapide de bases de connaissances massives

Lorsqu'un agent doit traiter des milliers de documents, de conversations passées ou de manuels de produits, une simple recherche par mot-clé ne suffit pas. Milvus utilise la recherche par similarité vectorielle pour trouver des informations sémantiquement pertinentes en quelques millisecondes, même si la requête est formulée différemment. Cela permet à votre agent de rappeler des connaissances basées sur le sens, et pas seulement sur des correspondances de texte exactes.

from langchain.agents import create_agent
from langchain_milvus import Milvus
from langchain_openai import OpenAIEmbeddings
# Initialize the vector database as a knowledge base
vectorstore = Milvus(
    embedding=OpenAIEmbeddings(),  
    collection_name="company_knowledge",
    connection_args={"uri": "http://localhost:19530"}  #
)
# Convert the retriever into a Tool for the Agent
agent = create_agent(
    model="openai:gpt-4o",
    tools=[vectorstore.as_retriever().as_tool(
        name="knowledge_search",
        description="Search the company knowledge base to answer professional questions"
    )],
    system_prompt="You can retrieve information from the knowledge base to answer questions."
)

2. Mémoire à long terme persistante

Le SummarizationMiddleware de LangChain peut condenser l'historique des conversations lorsqu'il devient trop long, mais qu'advient-il de tous les détails qui sont résumés ? Milvus les conserve. Chaque conversation, appel d'outil et étape de raisonnement peut être vectorisé et stocké pour une référence à long terme. En cas de besoin, l'agent peut rapidement retrouver les souvenirs pertinents par le biais d'une recherche sémantique, ce qui permet une véritable continuité d'une session à l'autre.

from langchain_milvus import Milvus
from langchain.agents import create_agent
from langchain.agents.middleware import SummarizationMiddleware
from langgraph.checkpoint.memory import InMemorySaver
# Long-term memory storage(Milvus)
long_term_memory = Milvus.from_documents(
    documents=[],  # Initially empty; dynamically updated at runtime
    embedding=OpenAIEmbeddings(),
    connection_args={"uri": "./agent_memory.db"}
)
# Short-term memory management(LangGraph Checkpointer + Summarization)
agent = create_agent(
    model="openai:gpt-4o",
    tools=[long_term_memory.as_retriever().as_tool(
        name="recall_memory",
        description="Retrieve the agent’s historical memories and past experiences"
    )],
    checkpointer=InMemorySaver(),  # Short-term memory
    middleware=[
        SummarizationMiddleware(
            model="openai:gpt-4o-mini",
            max_tokens_before_summary=4000  # When the threshold is exceeded, summarize and store it in Milvus
        )
    ]
)

3. Gestion unifiée du contenu multimodal

Les agents modernes traitent plus que du texte - ils interagissent avec des images, du son et de la vidéo. Milvus prend en charge le stockage multi-vecteur et le schéma dynamique, ce qui vous permet de gérer les incorporations de plusieurs modalités dans un système unique. Il s'agit d'une base de mémoire unifiée pour les agents multimodaux, qui permet une récupération cohérente de différents types de données.

# Filter retrievals by source (e.g., search only medical reports)
vectorstore.similarity_search(
    query="What is the patient's blood pressure reading?",
    k=3,
    expr="source == 'medical_reports' AND modality == 'text'"  # Milvus scalar filtering
)

LangChain vs. LangGraph : Comment choisir celui qui convient à vos agents

La mise à jour vers LangChain 1.0 est une étape essentielle vers la création d'agents de niveau production - mais cela ne signifie pas que c'est toujours le seul ou le meilleur choix pour tous les cas d'utilisation. Le choix du bon framework détermine la rapidité avec laquelle vous pouvez combiner ces capacités dans un système fonctionnel et maintenable.

En fait, LangChain 1.0 et LangGraph 1.0 peuvent être considérés comme des éléments d'une même pile, conçus pour fonctionner ensemble plutôt que pour se remplacer l'un l'autre : LangChain vous aide à construire rapidement des agents standard, tandis que LangGraph vous permet de contrôler finement des flux de travail complexes. En d'autres termes, LangChain vous aide à aller vite, tandis que LangGraph vous aide à aller en profondeur.

Voici une comparaison rapide de leurs différences de positionnement technique :

Dimension	LangChain 1.0	LangChain 1.0
Niveau d'abstraction	Abstraction de haut niveau, conçue pour les scénarios d'agents standards	Cadre d'orchestration de bas niveau, conçu pour les flux de travail complexes
Capacité de base	Boucle ReAct standard (Raison → Appel d'outil → Observation → Réponse)	Machines à états personnalisées et logique de branchement complexe (StateGraph + routage conditionnel)
Mécanisme d'extension	Logiciel intermédiaire pour les capacités de production	Gestion manuelle des nœuds, des arêtes et des transitions d'état
Mise en œuvre sous-jacente	Gestion manuelle des nœuds, des arêtes et des transitions d'état	Exécution native avec persistance et récupération intégrées
Cas d'utilisation typiques	80 % des scénarios d'agents standard	Collaboration multi-agents et orchestration de flux de travail à long terme
Courbe d'apprentissage	Construire un agent en ~10 lignes de code	Nécessite une compréhension des graphes d'état et de l'orchestration des nœuds

Si vous êtes novice en matière de construction d'agents ou si vous souhaitez lancer un projet rapidement, commencez par LangChain. Si vous savez déjà que votre cas d'utilisation nécessite une orchestration complexe, une collaboration multi-agent ou des workflows de longue durée, passez directement à LangGraph.

Les deux frameworks peuvent coexister dans le même projet - vous pouvez commencer simplement avec LangChain et intégrer LangGraph lorsque votre système a besoin de plus de contrôle et de flexibilité. L'essentiel est de choisir le bon outil pour chaque partie de votre flux de travail.

Conclusion

Il y a trois ans, LangChain a commencé comme une enveloppe légère pour appeler les LLM. Aujourd'hui, il s'est transformé en un framework complet de niveau production.

Au cœur du système, des couches intermédiaires assurent la sécurité, la conformité et l'observabilité. LangGraph ajoute l'exécution persistante, le flux de contrôle et la gestion d'état. Enfin, au niveau de la mémoire, Milvus comble une lacune essentielle en fournissant une mémoire à long terme évolutive et fiable qui permet aux agents de retrouver le contexte, de raisonner sur l'historique et de s'améliorer au fil du temps.

Ensemble, LangChain, LangGraph et Milvus forment une chaîne d'outils pratique pour l'ère des agents modernes, permettant un prototypage rapide et un déploiement à l'échelle de l'entreprise, sans sacrifier la fiabilité ou les performances.

🚀 Prêt à doter votre agent d'une mémoire fiable et à long terme ? Découvrez Milvus et voyez comment il alimente une mémoire à long terme intelligente pour les agents LangChain en production.

Vous avez des questions ou souhaitez approfondir une fonctionnalité ? Rejoignez notre canal Discord ou déposez des questions sur GitHub. Vous pouvez également réserver une session individuelle de 20 minutes pour obtenir des informations, des conseils et des réponses à vos questions dans le cadre des Milvus Office Hours.