Notes pratiques : Donnez à votre agent IA une mémoire — puis observez tout ce qu’il fait
Guide pas à pas pratique : Donnez à votre agent IA une mémoire — puis surveillez tout ce qu’il fait : contrats, vérifications et emplacements pour du code intégrable destinés aux équipes qui utilisent ce modèle.
Cette démarche reconstitue le parcours allant des matières premières à un système fonctionnel pour : Donner une mémoire à votre agent IA — puis observer comment l’auteur s’y prend avec LangSmith. L’accent est mis sur des étapes opérationnelles, des vérifications explicites, ainsi que du code que vous pouvez intégrer directement dans un dépôt sans devoir deviner l’intention derrière lui. Pour l’étape d’aperçu, définissez les entrées, le responsable de l’étape et les critères de fin avant de modifier le code. Les opérateurs doivent pouvoir relancer l’étape à partir d’un point de contrôle connu, sans avoir à deviner l’état caché. Conservez la configuration en dehors du code de l’application. Les fichiers d’environnement, les bases de données secrètes et les indicateurs fonctionnels doivent être regroupés en un seul endroit que les opérateurs peuvent auditer sans devoir lire l’ensemble du système.
L’architecture
Lors de la phase d’architecture, notez d’abord le contrat : les entrées requises, le signal de succès et ce qui se passe en cas d’échec partiel. Cette liste de contrôle permet de rester honnête lors des modifications ultérieures du code. Documentez ensemble le parcours normal et le parcours de récupération. Les tentatives répétées, les contrôles humains et la gestion des messages non livrés font partie intégrante du produit, et non d’une mise en forme ultérieure. Faites un point après les étapes coûteuses. Le système de reprise ne doit pas facturer à nouveau la même appel d’LLM lorsque l’opérateur réessaie un nœud ultérieur.
┌─────────────────────┐
│ User │
└──────────┬──────────┘
│
▼
┌─────────────────────┐
│ AI Agent │
│ LangChain Agent │
└──────────┬──────────┘
│
┌─────────────┴─────────────┐
│ │
▼ ▼
┌─────────────────┐ ┌──────────────────┐
│ Conversation │ │ Tools │
│ Memory │ │ │
│ InMemorySaver │ │ Tavily Web Search│
└─────────────────┘ └──────────────────┘
│ │
└─────────────┬─────────────┘
│
▼
┌─────────────────────┐
│ Ollama │
│ Llama 3.2 │
└─────────────────────┘
│
▼
┌─────────────────────┐
│ LangSmith │
│ Traces & Debugging │
└─────────────────────┘
1. Exécuter un LLM localement avec Ollama
Lors de la réalisation de l’étape 1 « Exécution d’un LLM », notez d’abord le contrat : les entrées requises, le signal de succès et ce qui se passe en cas d’échec partiel. Cette liste de contrôle permet de rester honnête lors des modifications ultérieures du code. Préférez des unités petites et testables plutôt que des scripts volumineux. Lorsqu’une étape échoue, l’échec doit indiquer une seule responsabilité et non un processus complexe et embrouillé. Enregistrez l’ID de la demande, l’ID du modèle et le temps de latence à chaque appel. Sans cette trace, les erreurs intermittentes du fournisseur ressemblent à des bugs de l’application.
from langchain_ollama import ChatOllama
llm = ChatOllama(
model="llama3.2:latest",
base_url="http://localhost:11434",
temperature=0,
)
model
Lors du travail sur l’étape du modèle, écrivez d’abord le contrat : entrées requises, signal de succès et ce qui se passe en cas d’échec partiel. Cette liste de contrôle permet de garantir l’honnêteté des modifications ultérieures du code. Considérez cette étape comme un contrat entre les entrées et les sorties validées. Donnez des noms aux artefacts, définez des vérifications de succès et refusez les terminations partielles silencieuses. Cachez les instructions du système stables ainsi que les schémas des outils. L’envoi répété d’un préambule identique est une source fréquente de problèmes.
model="llama3.2:latest"
Lors du travail sur l’étape du modèle, écrivez d’abord le contrat : entrées requises, signal de succès et ce qui se passe en cas d’échec partiel. Cette liste de contrôle permet de garantir l’honnêteté des modifications ultérieures du code. Gardez la configuration en dehors du code de l’application. Les fichiers d’environnement, les bases de données secrètes et les indicateurs fonctionnels doivent être regroupés en un seul endroit que les opérateurs peuvent auditer sans devoir lire l’ensemble du système.
base_url
La phase baseurl fonctionne le mieux lorsqu’elle est considérée comme une surface mesurable. Capturez un transcript parfait, un cas d’échec et la note de rollback avant d’élargir le périmètre. Documentez ensemble le parcours réussi et le parcours de récupération. Les tentatives répétées, les contrôles humains et le traitement des messages non livrés font partie du produit, et non d’une mise en forme ultérieure. Maintenez l’état des graphes plat et typé. Les blobs imbriqués masquent le fait que tel nœud a écrit telle champ et perturbent la reprise après interruption.
base_url="http://localhost:11434"
temperature
La phase de température fonctionne le mieux lorsqu’elle est considérée comme une surface mesurable. Capturez un exemple réussi, un cas d’échec ainsi que la note de réversion avant d’élargir le périmètre. Préférez des unités petites et testables aux scripts complexes. Lorsqu’une étape échoue, l’erreur doit indiquer une seule responsabilité plutôt qu’un processus embrouillé. Maintenez l’état des graphes simple et typé. Les blocs imbriqués masquent le fait que tel nœud a écrit telle champ et perturbent la reprise après interruption.
temperature=0
2. Création de l’agent
La phase 2 « Création de l’agent » fonctionne le mieux lorsqu’elle est considérée comme une surface mesurable. Capturez un exemple idéal de fonctionnement, un cas d’échec et une note de réversion avant d’élargir le périmètre. Considérez cette phase comme un contrat entre les entrées et les sorties validées. Donnez des noms aux artefacts, définez des critères de succès et refusez toute mise en œuvre partielle silencieuse. Maintenez l’état du graphe simplifié et typé. Les blocs imbriqués masquent l’identité du nœud qui a écrit tel champ, ce qui perturbe la reprise après interruption. La phase 2 « Création de l’agent » fonctionne le mieux lorsqu’elle est considérée comme une surface mesurable. Capturez un exemple idéal de fonctionnement, un cas d’échec et une note de réversion avant d’élargir le périmètre. Gardez la configuration en dehors du code de l’application. Les fichiers d’environnement, les bases de données secrètes et les indicateurs fonctionnels doivent être regroupés en un seul endroit que les opérateurs peuvent auditer sans avoir à lire l’ensemble du graphe.
from langchain.agents import create_agent
agent = create_agent(
model=llm
)
agent = create_agent(
model=llm,
tools=[tool1],
system_prompt="You are an intelligent knowlegable agent"
)
3. Fournir à l’agent un outil de recherche sur le Web
Pour l’étape 3 « Giving the Agent », définissez les entrées, le responsable de l’étape et les critères de fin avant de modifier le code. Les opérateurs doivent pouvoir relancer l’étape à partir d’un point de contrôle connu sans deviner l’état caché. Documentez ensemble le parcours normal et le parcours de récupération. Les tentatives répétées, les contrôles humains et la gestion des messages non livrés font partie du produit, et non d’une mise en forme ultérieure. Authentifiez au niveau du gateway et réautorisez au niveau du plan de données. Un token porteur seul ne constitue pas une frontière entre les tenants.
from langchain.tools import tool
@tool("web_search", description="Search the web for information")
def tool1(query: str) -> Dict[str, Any]:
tavily = TavilyClient()
return tavily.search(query=query)
tavily = TavilyClient()
return tavily.search(query=query)
User Question
│
▼
LLM
│
│ "I need external information"
▼
Web Search Tool
│
▼
Tavily API
│
▼
Search Results
│
▼
LLM
│
▼
Final Answer
4. Le problème : les LLM ne se souviennent pas automatiquement de l’auteur
Pour la phase 4 des LLMs, définissez les entrées, le responsable de l’étape et les critères d’arrêt avant de modifier le code. Les opérateurs doivent pouvoir relancer l’étape à partir d’un point de contrôle connu sans deviner l’état caché. Préférez des unités petites et testables à des scripts complexes. Lorsqu’une étape échoue, l’échec doit indiquer une seule responsabilité plutôt qu’un processus embrouillé. Préférez des sorties structurées avec validation de schéma à du texte libre lorsque l’étape suivante consiste en du code ou une appel d’outil.
from langgraph.checkpoint.memory import InMemorySaver
agent = create_agent(
model=llm,
checkpointer=InMemorySaver()
)
Question → LLM → Answer
5. InMemorySaver — Fournir une mémoire à l’Agent
Pour l’étape 5 InMemorySaver Giving, définissez les entrées, le responsable de l’étape et les critères de sortie avant de modifier le code. Les opérateurs doivent pouvoir relancer l’étape à partir d’un point de contrôle connu sans deviner l’état caché. Considérez cette étape comme un contrat entre les entrées et les sorties validées. Nommez les artefacts, définissez des vérifications de succès et refusez toute exécution partielle silencieuse. Faites approuver par un humain les opérations qui entraînent des dépenses ou modifient des données de production. La connexion en temps de compilation ne garantit pas la complétude du processus métier. Pour l’étape 5 InMemorySaver Giving, définissez les entrées, le responsable de l’étape et les critères de sortie avant de modifier le code. Les opérateurs doivent pouvoir relancer l’étape à partir d’un point de contrôle connu sans deviner l’état caché. Gardez la configuration en dehors du code de l’application. Les fichiers d’environnement, les bases de données secrètes et les indicateurs fonctionnels doivent être regroupés en un seul endroit que les opérateurs peuvent auditer sans avoir à lire l’intégralité du code.
graph.checkpointer=InMemorySaver()
6. La ligne la plus importante : thread_id
Lorsque vous travaillez sur l’étape 6 la plus importante, notez d’abord le contrat : les entrées requises, le signal de succès et ce qui se passe en cas d’échec partiel. Cette liste de contrôle permet de rester honnête lors des modifications ultérieures du code. Documentez ensemble le parcours normal et le parcours de récupération. Les tentatives répétées, les contrôles humains et la gestion des messages non livrés font partie du produit, et non d’une mise en forme ultérieure. Créez un point de contrôle après les étapes coûteuses. Resume ne doit pas facturer à nouveau la même appel LLM lorsque un opérateur réessaie un nœud ultérieur.
config = {
"configurable": {
"thread_id": "1"
}
}
Thread 1
────────────
User → My favorite color is Green
AI → Great!
User → What's my favorite color?
AI → Green
Thread 2
────────────
User → My favorite color is Blue
AI → Blue
7. Première conversation
Lorsque vous travaillez sur l’étape 7 « Première conversation », notez d’abord le contrat : les entrées requises, le signal de succès et ce qui se passe en cas d’échec partiel. Cette liste de contrôle permet de rester honnête lors des modifications ultérieures du code. Préférez des unités petites et testables plutôt que des scripts volumineux. Lorsqu’une étape échoue, l’échec doit indiquer une seule responsabilité et non un processus embrouillé. Faites des points de contrôle après les étapes coûteuses. Le système de reprise ne doit pas facturer à nouveau la même appel d’LLM lorsque l’opérateur réessaie un nœud ultérieur.
question = HumanMessage(
content="I am X my favorite color is Green"
)
response = agent.invoke(
{"messages": [question]},
config,
)
"thread_id": "1"
8. Demander à l’agent plus tard
Lors de la réalisation des 8 étapes relatives à la demande adressée à l’agent, notez d’abord les conditions du contrat : entrées requises, signal de succès et conséquences en cas d’échec partiel. Cette liste de contrôle permet de garantir l’intégrité des modifications ultérieures du code. Considérez cette étape comme un contrat entre les entrées et les sorties validées. Donnez des noms aux éléments générés, définez des vérifications de succès et refusez toute exécution partielle silencieuse. Faites des points de contrôle après les étapes coûteuses. Le système de reprise ne doit pas facturer à nouveau la même appel du LLM lorsque l’opérateur réessaie un nœud ultérieur. Lors de la réalisation des 8 étapes relatives à la demande adressée à l’agent, notez d’abord les conditions du contrat : entrées requises, signal de succès et conséquences en cas d’échec partiel. Cette liste de contrôle permet de garantir l’intégrité des modifications ultérieures du code. Conservez la configuration en dehors du code de l’application. Les fichiers d’environnement, les bases de données secrètes et les indicateurs fonctionnels doivent être regroupés en un seul endroit que les opérateurs peuvent auditer sans avoir à lire l’ensemble du système.
question2 = HumanMessage(
content="What's my favorite color?"
)
response2 = agent.invoke(
{"messages": [question2]},
config,
)
config = {
"configurable": {
"thread_id": "1"
}
}
Your favorite color is Green!
9. Pourquoi thread_id est si important
La méthode des 9 « Pourquoi » concernant thread_id fonctionne le mieux lorsqu’elle est considérée comme une donnée mesurable. Recueillez un exemple exemplaire, un cas d’échec et les notes de réversion avant d’élargir le champ d’étude.
Documentez en même temps le parcours normal et celui de récupération. Les tentatives répétées, les contrôles humains et la gestion des messages non livrés font partie intégrante du produit, et non d’une mise en forme ultérieure.
Maintenez l’état des graphes simple et typé. Les blocs imbriqués masquent le fait que tel nœud a écrit telle champ, ce qui perturbe la reprise après interruption.
Customer A → thread_id = "customer-A"
Customer B → thread_id = "customer-B"
Customer C → thread_id = "customer-C"
AI Agent
│
┌────────┼────────┐
▼ ▼ ▼
Customer A Customer B Customer C
│ │ │
Thread A Thread B Thread C
10. Mais la mémoire ne suffit pas
La phase « 10 But Memory Isn » fonctionne le mieux lorsqu’elle est considérée comme une surface mesurable. Capturez un exemplaire idéal, un cas d’échec et la note de réversion avant d’élargir le périmètre. Préférez des unités petites et testables aux scripts complexes. Lorsqu’une étape échoue, l’échec doit pointer vers une seule responsabilité plutôt que vers un processus embrouillé. Maintenez l’état du graphe plat et typé. Les blocs imbriqués cachent le fait que tel nœud a écrit tel champ et perturbent la reprise après interruption.
User Question
↓
Agent
↓
LLM decides to call web_search
↓
Tavily
↓
Search results
↓
LLM
↓
Final answer
11. Entrer dans LangSmith
La phase 11 d’Enter LangSmith fonctionne le mieux lorsqu’elle est considérée comme une surface mesurable. Capturez un transcript idéal, un cas d’échec et la note de réversion avant d’élargir le périmètre. Considérez cette phase comme un contrat entre les entrées et les sorties validées. Nommez les artefacts, définites des vérifications de succès et refusez toute complétion partielle silencieuse. Maintenez l’état du graphe plat et typé. Les blocs imbriqués masquent le fait que tel nœud a écrit telle champ et perturbent la reprise après interruption. La phase 11 d’Enter LangSmith fonctionne le mieux lorsqu’elle est considérée comme une surface mesurable. Capturez un transcript idéal, un cas d’échec et la note de réversion avant d’élargir le périmètre. Gardez la configuration en dehors du code de l’application. Les fichiers d’environnement, les stocks de secrets et les flags fonctionnels doivent se trouver en un seul endroit que les opérateurs peuvent auditer sans devoir lire l’ensemble du graphe.
os.environ["LANGSMITH_TRACING"] = "true"
os.environ["LANGSMITH_API_KEY"] = "YYY"
os.environ["LANGSMITH_ENDPOINT"] = "https://langsmith-endpoint"
os.environ["LANGSMITH_PROJECT"] = "local-ollama-agent"
LANGSMITH_TRACING=true
12. Pourquoi le traçage est meilleur que print()
Pour l’étape de suivi des 12 « pourquoi », définissez les entrées, le responsable de l’étape et les critères d’arrêt avant de modifier le code. Les opérateurs doivent pouvoir relancer l’étape à partir d’un point de contrôle connu sans deviner l’état caché. Documentez ensemble le parcours normal et les scénarios de récupération. Les tentatives répétées, les contrôles humains et la gestion des messages non livrés font partie intégrante du produit, et non d’une mise en forme ultérieure. Faites approuver par un humain les actions qui entraînent des dépenses ou modifient des données de production. La connexion en temps de compilation ne garantit pas l’exhaustivité du processus métier.
print(response)
Question
│
├── LLM call
│
├── Tool decision
│
├── Web search
│
├── Tool response
│
├── Another LLM call
│
└── Final response
13. Que pouvons-nous apprendre d’un suivi ?
Pour le volet 13 « What Can We », il convient de définir les entrées, le responsable de l’étape et les critères d’arrêt avant de modifier du code. Les opérateurs doivent pouvoir relancer l’étape à partir d’un point de contrôle connu, sans avoir à deviner l’état caché. Préférer des unités petites et testables aux scripts complexes. Lorsqu’une étape échoue, l’échec doit indiquer une seule responsabilité et non un processus embrouillé. Imposer l’approbation humaine pour les actions qui entraînent des dépenses ou modifient des données de production. La connexion en temps de compilation ne garantit pas la complétude du processus métier.
Total execution: 8 seconds
LLM call 1.5 sec
Web search 5.2 sec
Final LLM call 1.3 sec
14. Associer la mémoire et l’observabilité
Pour l’étape 14 « Mémorisation et mise en œuvre », définissez les entrées, le responsable de l’étape ainsi que les critères de fin avant de modifier le code. Les opérateurs doivent pouvoir relancer l’étape à partir d’un point de contrôle connu sans deviner l’état caché. Considérez cette étape comme un contrat entre les entrées et les sorties validées. Nommez les artefacts, définissez des vérifications de succès et refusez toute exécution partielle silencieuse. Faites approuver manuellement les cas où de l’argent est dépensé ou où des données de production sont modifiées. La connexion en temps de compilation ne garantit pas la complétude du processus métier. Pour l’étape 14 « Mémorisation et mise en œuvre », définissez les entrées, le responsable de l’étape ainsi que les critères de fin avant de modifier le code. Les opérateurs doivent pouvoir relancer l’étape à partir d’un point de contrôle connu sans deviner l’état caché. Gardez la configuration en dehors du code de l’application. Les fichiers d’environnement, les bases de données secrètes et les indicateurs fonctionnels doivent être regroupés en un seul endroit que les opérateurs peuvent auditer sans avoir à lire l’ensemble du système.
┌───────────────┐
│ User │
└───────┬───────┘
│
▼
┌────────────────────┐
│ AI Agent │
└─────────┬──────────┘
│
┌──────────────┼──────────────┐
│ │ │
▼ ▼ ▼
Memory LLM Tools
InMemorySaver Ollama Tavily
│ │ │
└──────────────┼──────────────┘
│
▼
┌─────────────┐
│ LangSmith │
│ Tracing │
└─────────────┘
Mémoire
Lors du travail sur l’étape de mémoire, notez d’abord le contrat : les entrées requises, le signal de succès et ce qui se passe en cas d’échec partiel. Cette liste de contrôle permet de rester honnête lors des modifications ultérieures du code. Documentez ensemble le parcours normal et le parcours de récupération. Les tentatives répétées, les contrôles humains et la gestion des messages non livrés font partie du produit, et non d’améliorations apportées ultérieurement. Créez un point de contrôle après les étapes coûteuses. Le système de reprise ne doit pas facturer à nouveau la même appel LLM lorsque l’opérateur tente à nouveau un nœud ultérieur.
LLM
Lors du travail sur l’étape LLM, notez d’abord le contrat : les entrées requises, le signal de succès, ainsi que ce qui se passe en cas d’échec partiel. Cette liste de contrôle permet de rester honnête lors des modifications ultérieures du code. Préférez des unités petites et testables plutôt que des scripts volumineux. Lorsqu’une étape échoue, l’échec doit indiquer une seule responsabilité et non un processus embrouillé. Cachez les instructions du système stables ainsi que les schémas des outils. Envoyer à nouveau un préambule identique est une cause fréquente de gaspillage.
Outils
Lors du traitement de l’étape Outils, notez d’abord le contrat : les entrées requises, le signal de succès et ce qui se passe en cas d’échec partiel. Cette liste de contrôle permet de garantir l’intégrité des modifications ultérieures du code. Considérez cette étape comme un contrat entre les entrées et les sorties validées. Donnez des noms aux artefacts, définites des vérifications de succès et refusez les terminations partielles silencieuses. Enregistrez le nom de l’outil, le hash des arguments, la latence et le résultat de chaque appel. Sans cette trace, les boucles d’analyse des erreurs perdent des heures. Lors du traitement de l’étape Outils, notez d’abord le contrat : les entrées requises, le signal de succès et ce qui se passe en cas d’échec partiel. Cette liste de contrôle permet de garantir l’intégrité des modifications ultérieures du code. Conservez la configuration en dehors du code de l’application. Les fichiers d’environnement, les bases de données secrètes et les indicateurs fonctionnels doivent être regroupés en un seul endroit que les administrateurs peuvent auditer sans devoir lire l’ensemble du système.
LangSmith
Le stage LangSmith fonctionne le mieux lorsqu’il est considéré comme une surface mesurable. Capturez un transcript parfait, un cas d’échec et la note de réversion avant d’élargir le périmètre. Documentez ensemble le parcours réussi et le parcours de récupération. Les tentatives répétées, les contrôles humains et le traitement des messages non livrés font partie intégrante du produit, et non d’une mise en forme ultérieure. Gardez l’état des graphes simple et typé : les blocs imbriqués masquent le fait que tel nœud a écrit telle champ et perturbent la reprise après interruption.
15. Le flux conceptuel complet
La phase 15 « The Complete Conceptual » fonctionne le mieux lorsqu’elle est considérée comme une surface mesurable. Capturez un exemple réussi, un cas d’échec et la note de réversion avant d’élargir le périmètre. Préférez des unités petites et testables aux scripts complexes. Lorsqu’une étape échoue, l’erreur doit indiquer une seule responsabilité plutôt qu’un processus embrouillé. Maintenez l’état du graphe plat et typé. Les blocs imbriqués masquent le fait que tel nœud a écrit telle champ et perturbent la reprise après interruption.
Étape 1 — L’utilisateur fournit des informations
L’utilisateur de l’Étape 1 obtient de meilleurs résultats en traitant cette étape comme une surface mesurable. Capturez un transcript idéal, un cas d’échec et la note de réversion avant d’élargir le périmètre. Considérez cette étape comme un contrat entre les entrées et les sorties validées. Nommez les artefacts, définites des critères de succès et refusez toute mise en œuvre partielle silencieuse. Maintenez l’état du graphe simple et typé. Les blocs imbriqués masquent le fait que tel nœud a modifié tel champ et perturbent la reprise après interruption.
"My name is Amit and my favorite color is Green."
L’utilisateur de l’Étape 1 obtient de meilleurs résultats en traitant cette étape comme une surface mesurable. Capturez un transcript idéal, un cas d’échec et la note de réversion avant d’élargir le périmètre. Gardez la configuration en dehors du code de l’application. Les fichiers d’environnement, les bases de données secrètes et les indicateurs fonctionnels doivent être regroupés en un seul endroit que les opérateurs peuvent auditer sans devoir lire l’ensemble du graphe.
thread_id = 1
Étape 2 — L’utilisateur pose une autre question
Pour l’étape 2 où l’utilisateur pose une question, il faut définir les entrées, le responsable de l’étape ainsi que les critères d’arrêt avant de modifier le code. Les opérateurs doivent pouvoir relancer l’étape à partir d’un point de contrôle connu sans deviner l’état caché. Documentez conjointement le parcours normal et les scénarios de récupération. Les tentatives répétées, les contrôles humains et la gestion des messages non traités font partie intégrante du produit, et non d’améliorations ultérieures. Imposez une approbation humaine pour les actions qui entraînent des dépenses ou modifient des données de production. Une configuration en temps de compilation ne garantit pas la complétude du fonctionnement métier.
"What's my favorite color?"
"Your favorite color is Green."
Étape 3 — L’utilisateur pose une question de connaissance
Pour l’étape 3, avant de modifier le code, il convient de définir les entrées, le responsable de l’étape ainsi que les critères d’arrêt. Les opérateurs doivent pouvoir relancer l’étape à partir d’un point de contrôle connu, sans avoir à deviner l’état caché. Préférez des unités petites et testables aux scripts complexes. Lorsqu’une étape échoue, l’échec doit indiquer une seule responsabilité et non un processus embrouillé. Faites approuver par des humains les actions qui entraînent des dépenses ou modifient des données de production. Une connexion en temps de compilation ne garantit pas la complétude du processus métier.
"Who is the Chief Minister of Tamil Nadu?"
web_search
Étape 4 — Exécution par l’outil
Pour la phase d’exécution de l’outil de l’Étape 4, définissez les entrées, le responsable de l’étape et les critères de fin avant de modifier le code. Les opérateurs doivent pouvoir relancer l’étape à partir d’un point de contrôle connu sans deviner l’état caché. Considérez cette phase comme un contrat entre les entrées et les sorties validées. Donnez des noms aux artefacts, définites des vérifications de succès et refusez les terminations partielles silencieuses. Authentifiez-vous au niveau du gateway et réautorisez-vous au niveau du plan de données. Un simple token porteur ne constitue pas une frontière entre les tenants. Pour la phase d’exécution de l’outil de l’Étape 4, définissez les entrées, le responsable de l’étape et les critères de fin avant de modifier le code. Les opérateurs doivent pouvoir relancer l’étape à partir d’un point de contrôle connu sans deviner l’état caché. Conservez la configuration en dehors du code de l’application. Les fichiers d’environnement, les bases de données secrètes et les flags fonctionnels doivent être regroupés en un seul endroit que les opérateurs peuvent auditer sans avoir à lire l’ensemble du système.
Étape 5 — Le LLM génère la réponse
Lors de l’étape 5 où le LLM génère la réponse, notez d’abord les éléments requis : les entrées nécessaires, le signal de succès, ainsi que ce qui se passe en cas d’échec partiel. Cette liste de contrôle permet de rester honnête lors des modifications ultérieures du code.
Étape 6 — LangSmith enregistre l’exécution
16. Une note sur les secrets
os.environ["TAVILY_API_KEY"] = "XXX"
os.environ["LANGSMITH_API_KEY"] = "YYY"
export TAVILY_API_KEY="..."
export LANGSMITH_API_KEY="..."
export LANGSMITH_TRACING="true"
export LANGSMITH_PROJECT="local-ollama-agent"
17. Pourquoi cette architecture est importante
User → LLM → Response
┌── Memory
│
User → Agent → LLM ├── Tools
│
└── State
│
▼
Tracing
18. Mémoire vs. persistance
InMemorySaver()
Application starts
↓
Thread 1 created
↓
Conversation stored in memory
↓
Application restarts
↓
Memory is gone
19. Un modèle mental simple
1⃣ Agent
agent = create_agent(...)
2⃣ Modèle
llm = ChatOllama(...)
3⃣ Mémoire
checkpointer=InMemorySaver()
4⃣ Observabilité
LANGSMITH_TRACING=true
Agent
├── Model
├── Memory
├── Tools
└── Observability
Conclusion
Ollama
+
Llama 3.2
+
LangChain Agent
+
InMemorySaver
+
Tavily
+
LangSmith