La plupart des tutoriels sur les agents Claude s'arrêtent au « hello world ».
Ils vous montrent comment faire appel à un outil avec Claude. Comment configurer une boucle basique. Comment obtenir une réponse autonome sur une tâche jouet simple.
Ensuite, vous essayez de construire quelque chose de réel et tout s'effondre.
La tâche est trop ambiguë. L'agent reste bloqué. Les résultats sont incohérents. La session se termine et rien n'est sauvegardé. Vous repartez de zéro la fois suivante.
L'écart entre un agent Claude qui fonctionne dans un tutoriel et un agent Claude qui fonctionne en production n'est pas un écart dans les capacités de Claude.
C'est un écart dans la manière dont l'agent a été conçu.
Ce guide comble complètement cet écart.
À la fin, vous aurez un agent Claude qui exécute un workflow réel de manière fiable. Pas une démo. Pas une tâche jouet. Un workflow qui produit des résultats cohérents, gère les cas limites avec élégance, s'améliore avec le temps et fonctionne sans que vous ayez à initier chaque étape.
Ce qui rend un agent du monde réel différent
Avant de construire quoi que ce soit, comprenez ce qui distingue un agent du monde réel d'un agent de tutoriel.
Un agent de tutoriel exécute une tâche propre avec des entrées propres et produit une sortie propre. La tâche est bien définie. Les entrées sont fournies dans le format exact attendu. Rien d'inattendu ne se produit. Le succès est binaire et évident.
Un agent du monde réel exécute des tâches désordonnées avec des entrées désordonnées et doit quand même produire des résultats utiles. La tâche est partiellement définie. Les entrées arrivent dans des formats variables. Des choses inattendues se produisent régulièrement. Le succès est une question de degré et nécessite du jugement pour être évalué.
Quatre propriétés déterminent si un agent survit au contact du monde réel :
Définition robuste de la tâche. L'agent sait non seulement quoi faire, mais aussi comment gérer les vingt variations de la tâche qu'il rencontrera en pratique. Les instructions couvrent les cas limites, pas seulement le chemin heureux.
Mémoire persistante. L'agent accumule du contexte entre les sessions. Le travail effectué la semaine dernière éclaire le travail d'aujourd'hui. Il ne repart pas de zéro à chaque session.
Gestion élégante des échecs. Quand quelque chose tourne mal, l'agent se rétablit plutôt que de s'arrêter. Il enregistre ce qui s'est passé, essaie des alternatives et n'alerte un humain que lorsque la récupération est impossible.
Auto-vérification de la qualité. L'agent vérifie ses propres résultats par rapport à des normes définies avant de les livrer. Il ferme sa propre boucle de rétroaction plutôt que de renvoyer ce qu'il a produit en premier.
La plupart des agents de tutoriel n'ont aucune de ces propriétés. Ce guide construit les quatre.
L'architecture de l'agent
L'architecture comporte quatre composants qui fonctionnent ensemble.
La couche de définition de tâche
Un fichier de compétence structuré qui définit la tâche, le processus, la gestion des cas limites et le standard de qualité. Ce n'est pas une invite. C'est une spécification opérationnelle complète que l'agent lit avant chaque exécution.
La couche mémoire
Une base de données persistante qui stocke ce que l'agent a fait, ce qu'il a appris et ce qu'il doit retenir entre les sessions. Construite sur SQLite via Hermes Agent ou implémentée manuellement avec une journalisation basée sur des fichiers.
La couche d'exécution
Les appels réels à l'API Claude qui effectuent le travail. Structurée pour utiliser le bon modèle, le bon contexte et les bons outils pour chaque étape du workflow.
La couche qualité
La boucle de vérification qui contrôle les résultats par rapport à des normes définies avant de les livrer et réessaie avec des corrections spécifiques lorsque les résultats sont insuffisants.
Mettre en place les fondations
Installer les outils nécessaires :
Installer Hermes Agent pour l'orchestration et la mémoire
git clone https://github.com/NousResearch/hermes-agent
cd hermes-agent
npm install
Installer les serveurs MCP pour l'accès aux outils
npm install -g @modelcontextprotocol/server-filesystem
npm install -g @modelcontextprotocol/server-brave-search
Configurer votre environnement :
Configuration principale
MODEL_PROVIDER=anthropic
MODEL_NAME=claude-opus-4-8
ANTHROPIC_API_KEY=your-api-key-here
Configuration mémoire — utiliser des chemins absolus
MEMORY_BACKEND=sqlite
MEMORY_PATH=/Users/yourname/agent-data/memory.db
Configuration du planificateur
ENABLE_SCHEDULER=true
SCHEDULER_TIMEZONE=America/New_York
Configuration de sortie — où les résultats atterrissent
OUTPUT_PATH=/Users/yourname/agent-outputs
Récupération après échec
SKILL_RETRY_ENABLED=true
SKILL_RETRY_MAX=3
SKILL_RETRY_DELAY=300
Notifications
NOTIFICATION_GATEWAY=telegram
TELEGRAM_BOT_TOKEN=your-bot-token
TELEGRAM_CHAT_ID=your-chat-id
Écrire le CLAUDE.md :
C'est le fichier le plus important de toute la configuration. Chaque session d'agent commence par le lire. La qualité de chaque résultat dépend de la spécificité de ce qui s'y trouve.
Configuration de l'agent — CLAUDE.md
Identité et objectif
[Décrivez en un paragraphe spécifique ce que fait cet agent.
Pas ce qu'est Claude en général. Ce que cet agent spécifique
est configuré pour faire pour cette opération spécifique.]
Contexte opérationnel
[Décrivez le contexte professionnel ou personnel dans lequel
cet agent opère. Que fait la personne qui a configuré cet
agent ? Quels sont ses standards et ses priorités ?]
Tâches actives en cours
[Listez les tâches récurrentes spécifiques que cet agent exécute.
Pour chacune : ce qu'elle fait, quand elle s'exécute, à quoi ressemble un bon résultat.]
Autorisations d'outils
Vous êtes autorisé à utiliser ces outils de manière autonome :
- Système de fichiers : lire et écrire dans [CHEMINS SPÉCIFIQUES]
- Recherche web : pour la recherche sur [SUJETS SPÉCIFIQUES]
- [Autres outils avec un périmètre spécifique]
Vous ne devez pas :
- Écrire dans un chemin en dehors du répertoire de sortie configuré
- Effectuer des appels API externes non listés ci-dessus
- Prendre toute action qui affecte des systèmes externes sans approbation explicite
Standards de qualité
[Décrivez à quoi ressemble un bon résultat pour chaque type de tâche.
Incluez des exemples si possible.
Soyez suffisamment précis pour que l'agent puisse s'auto-évaluer.]
Instructions mémoire
Stocker en mémoire :
- Chaque résultat significatif avec sa date et son évaluation de qualité
- Chaque cas limite rencontré et comment il a été géré
- Chaque échec de qualité et sa cause
- Chaque modèle identifié à travers les résultats
Gestion des erreurs
En cas d'échec d'outil : réessayer une fois, enregistrer l'échec, continuer
avec les outils disponibles.
En cas d'échec de qualité : réessayer avec des corrections spécifiques,
pas une réécriture complète. Maximum trois tentatives.
En cas d'échec irrécupérable : sauvegarder le travail partiel,
enregistrer l'échec spécifique, envoyer une notification,
s'arrêter proprement.
Construire la couche de définition de tâche
La couche de définition de tâche est l'endroit où la plupart des agents du monde réel échouent.
Les gens écrivent une invite qui décrit le chemin heureux et s'arrêtent là. L'agent gère bien le chemin heureux et se casse sur tout le reste.
Une définition de tâche robuste couvre la réalité opérationnelle complète de la tâche. Voici le modèle :
[NOM DE LA TÂCHE]
Objectif
[Une phrase : qu'est-ce que cette compétence accomplit ?]
Déclencheur
[Conditions exactes qui provoquent l'exécution :
heure programmée, apparition d'un fichier, commande manuelle, etc.]
Vérifications pré-exécution
Avant de commencer, vérifier :
- [L'entrée requise existe et est accessible]
- [Les outils requis sont connectés et répondent]
- [Le chemin de sortie est accessible en écriture]
- [La mémoire est accessible et à jour]
Si une vérification échoue : enregistrer l'échec et s'arrêter.
Ne pas continuer avec des prérequis manquants.
Processus principal
Étape 1 : Chargement du contexte
Lire CLAUDE.md pour le contexte opérationnel complet.
Lire la mémoire pour l'historique pertinent étiqueté : [TAG-TÂCHE]
Noter les modèles des exécutions précédentes
qui devraient éclairer celle-ci.
Étape 2 : Traitement de l'entrée
[Décrire exactement quoi faire avec l'entrée.
Couvrir le format principal ET les formats alternatifs
qui apparaissent en pratique.]
Pour le format d'entrée standard :
[Étapes de traitement exactes]
Pour le format d'entrée alternatif A :
[Comment le gérer]
Pour le format d'entrée alternatif B :
[Comment le gérer]
Pour une entrée malformée ou manquante :
[Comment la gérer — ne jamais échouer silencieusement]
Étape 3 : Exécution principale
[Le travail réel de la compétence.
Diviser en sous-étapes. Chaque sous-étape doit être
suffisamment spécifique pour qu'une nouvelle instance de Claude
puisse l'exécuter sans contexte supplémentaire.]
Étape 4 : Vérification de la qualité
Avant de sauvegarder la sortie, vérifier selon ces normes :
REQUIS : [Propriétés de sortie non négociables]
PRÉFÉRÉ : [Propriétés de qualité qui améliorent la sortie]
INTERDIT : [Choses qui ne doivent jamais apparaître dans la sortie]
Si la sortie échoue aux vérifications requises :
- Identifier spécifiquement ce qui a échoué
- Réessayer avec une correction ciblée
- Maximum trois tentatives
- Si toujours en échec après trois : sauvegarder avec un indicateur d'échec
Étape 5 : Sortie et stockage
Sauvegarder la sortie dans : [CHEMIN SPÉCIFIQUE ET FORMAT DE NOM DE FICHIER]
Stocker en mémoire étiqueté : [TAG-TÂCHE, DATE]
Mettre à jour CLAUDE.md si des informations actuelles ont changé.
Envoyer une notification : [QUOI INCLURE DANS LA NOTIFICATION]
Cas limites
[Nom du cas limite 1]
Condition : [Quand cela se produit]
Détection : [Comment le reconnaître]
Réponse : [Que faire]
[Nom du cas limite 2]
Condition : [Quand cela se produit]
Détection : [Comment le reconnaître]
Réponse : [Que faire]
[Nom du cas limite 3]
Condition : [Quand cela se produit]
Détection : [Comment le reconnaître]
Réponse : [Que faire]
Standard de qualité
Un excellent résultat : [Description spécifique]
Un résultat acceptable : [Barre minimale]
Un résultat inacceptable : [Ce qui doit déclencher une nouvelle tentative]
Instructions mémoire
Après chaque exécution, stocker :
- Date et durée de l'exécution
- Évaluation de la qualité du résultat (excellent/acceptable/échoué)
- Tout cas limite rencontré et comment il a été géré
- Tout modèle digne d'être noté pour les exécutions futures
Votre premier agent réel : l'agent de recherche et de briefing
Voici un agent réel complet construit avec cette architecture. Cet agent surveille quotidiennement un ensemble de sources, recherche des sujets pertinents pour votre travail et fournit un briefing structuré chaque matin.
Ce n'est pas une tâche jouet. C'est un workflow réel qui remplace quarante-cinq minutes de compilation manuelle de recherche chaque jour.
Créer skills/research-brief.md :
research-brief
Objectif
Surveiller les sources configurées et produire un
briefing d'intelligence structuré couvrant les développements
pertinents pour les projets et priorités en cours.
Déclencheur
Programmé quotidiennement à 6h00.
Manuel : « Research brief » ou « Morning brief »
Vérifications pré-exécution
Avant de commencer, vérifier :
- CLAUDE.md est lisible dans 07-SYSTEM/CLAUDE.md
- Brave Search MCP répond
- Le chemin de sortie est accessible en écriture dans outputs/briefings/
- La base de données mémoire est accessible
Processus principal
Étape 1 : Chargement du contexte
Lire CLAUDE.md complètement. Noter :
- Les projets actifs en cours et leur statut
- Les sujets signalés pour surveillance
- Toute décision en attente nécessitant des renseignements
- Les standards de qualité pour ce briefing
Lire la mémoire étiquetée : research-brief
Noter : ce qui a été couvert dans les briefings récents
pour éviter les répétitions.
Étape 2 : Recherche de sources
Pour chaque sujet dans la liste de surveillance de CLAUDE.md :
Requête de recherche : « [SUJET] nouvelles dernières 24 heures »
Collecter : titre, source, date, affirmation clé
Appliquer le filtre de signal :
INCLURE : Nouveau développement, donnée, lancement de produit,
déclaration significative, résultat de recherche
EXCLURE : Répétition d'une couverture existante,
opinion sans information nouvelle,
tout ce qui a été couvert dans les 3 derniers briefings
Pour chaque résultat qui passe le filtre de signal :
Approfondir la recherche avec une requête de suivi si
le résultat initial suggère un développement significatif.
Étape 3 : Synthèse
Regrouper les résultats par sujet.
Pour chaque groupe de sujets, identifier :
- Le développement le plus significatif
- Pourquoi il est important pour les projets en cours
- Quelle action, le cas échéant, il implique
Synthèse inter-sujets :
- Y a-t-il deux résultats ou plus qui se connectent pour suggérer un modèle plus large ?
- Un résultat impacte-t-il directement un projet actif ou une décision en attente ?
Étape 4 : Vérification de la qualité
Avant de finaliser, vérifier :
REQUIS :
- Minimum 3 éléments de signal (pas de bruit)
- Chaque élément ancré dans une source spécifique
- Chaque élément explique sa pertinence pour le travail en cours
- Aucun élément répété des 5 derniers briefings
PRÉFÉRÉ :
- Au moins une connexion inter-sujets
- Au moins un élément qui implique une action spécifique
- Reconnaissance honnête s'il s'agit d'un jour creux dans l'actualité
INTERDIT :
- Analyse générique sans preuve spécifique
- Éléments intéressants mais non pertinents
- Bourrage pour faire paraître le briefing plus complet
Si le briefing échoue aux vérifications requises : identifier spécifiquement
ce qui manque et rechercher des sources supplémentaires
avant de réessayer. Ne pas bourrer avec des signaux faibles.
Étape 5 : Génération de la sortie
Générer le briefing dans ce format exact :
Briefing matinal — [DATE]
LE PLUS IMPORTANT AUJOURD'HUI
[Développement le plus significatif et pourquoi il
est important pour le travail en cours. Spécifique. Fondé.]
ÉLÉMENTS DE SIGNAL
[Sujet 1]
\\Développement :\\ [Ce qui s'est passé]
\\Source :\\ [Publication, date]
\\Pertinence :\\ [Pourquoi cela importe pour les projets en cours]
\\Implication :\\ [Action éventuelle suggérée]
[Sujet 2]
[Même format]
[Continuer pour chaque élément de signal]
CONNEXION
[Si deux éléments ou plus se connectent pour suggérer un
modèle plus large, le décrire ici. Ignorer s'il n'y a pas de connexion réelle.]
PERTINENCE DÉCISIONNELLE
[Si un élément est directement pertinent pour une décision
en attente dans CLAUDE.md, le signaler ici avec des détails.]
NOTE DE COUVERTURE
[Évaluation honnête : journée complète / jour creux.
Nombre de sources consultées.]
Étape 6 : Stockage et notification
Sauvegarder dans : outputs/briefings/[DATE]-morning-brief.md
Stocker en mémoire :
- Date : [AUJOURD'HUI]
- Éléments couverts : [LISTE DES SUJETS]
- Qualité : [excellent/acceptable/échoué]
- Notable : [Tout cas limite ou modèle] Tag : research-brief
Envoyer une notification Telegram :
« Briefing matinal prêt : [N] éléments de signal.
[LE PLUS IMPORTANT AUJOURD'HUI en une ligne] »
Cas limites
Aucun signal trouvé pour un sujet
Condition : Les recherches ne renvoient aucun nouveau développement
Détection : Tous les résultats datent de plus de 48 heures
Réponse : Noter « Aucun nouveau développement » pour ce sujet.
Ne pas fabriquer ni bourrer. Passer au sujet suivant.
La source renvoie des informations contradictoires
Condition : Deux sources rapportent des faits contradictoires
Détection : Contradiction directe sur une affirmation spécifique
Réponse : Rapporter les deux versions, citer les deux sources,
signaler comme contradictoire. Ne pas choisir l'une plutôt que l'autre.
Outil de recherche indisponible
Condition : Brave Search MCP ne répond pas
Détection : L'appel d'outil renvoie une erreur
Réponse : Enregistrer l'échec. Notifier via Telegram.
Sauvegarder un briefing partiel avec la note : « Recherche indisponible —
briefing basé uniquement sur le contexte mémoire. »
Ne pas échouer silencieusement.
Le briefing répéterait l'élément principal d'hier
Condition : Le développement le plus significatif est le même qu'hier
Détection : Recouper avec le briefing d'hier en mémoire
Réponse : Noter « Développement en cours depuis [DATE] »
et se concentrer sur ce qui est spécifiquement nouveau aujourd'hui.
Standard de qualité
Excellent briefing : 4-6 éléments de signal. Chaque élément pertinent.
Au moins un aperçu inter-sujets. Se lit en moins de 5 minutes.
Briefing acceptable : 3 éléments de signal. Tous pertinents.
Pas d'aperçu inter-sujets. Se lit en moins de 5 minutes.
Briefing inacceptable : Moins de 3 éléments de signal.
Tout élément générique ou non pertinent pour le travail en cours.
Tout élément répété des 3 derniers briefings.
Construire la couche de vérification de la qualité
La couche de vérification de la qualité est ce qui distingue les agents qui produisent des résultats cohérents des agents qui produisent des résultats variables.
La plupart des agents ignorent complètement cette couche. Ils génèrent une sortie et la renvoient. La qualité dépend entièrement de la qualité de la génération. Certaines sessions sont excellentes. D'autres sont médiocres. Vous ne savez jamais ce que vous allez obtenir.
Une couche de vérification de la qualité rend la qualité de la sortie cohérente en vérifiant chaque sortie par rapport à des normes définies et en réessayant avec des corrections spécifiques lorsque les normes ne sont pas respectées.
Voici le modèle d'appel API Claude qui implémente la vérification de la qualité :
1async function executeWithQualityVerification(prompt, qualityStandard, maxRetries = 3) {2 let attempt = 0;3 let lastOutput = null;4 let lastFailure = null;56 while (attempt < maxRetries) {7 // Generate the output8 const response = await fetch('https://api.anthropic.com/v1/messages', {9 method: 'POST',10 headers: {11 'Content-Type': 'application/json',12 'x-api-key': process.env.ANTHROPIC_API_KEY,13 'anthropic-version': '2023-06-01'14 },15 body: JSON.stringify({16 model: 'claude-opus-4-8',17 max_tokens: 4096,18 messages: [19 {20 role: 'user',21 content: attempt === 022 ? prompt23 : `$ {prompt}\n\nPrevious attempt failed quality check: $ {lastFailure}\nCorrect specifically for this failure. Do not rewrite everything.`24 }25 ]26 })27 });2829 const data = await response.json();30 lastOutput = data.content[0].text;3132 // Verify quality33 const verificationResponse = await fetch('https://api.anthropic.com/v1/messages', {34 method: 'POST',35 headers: {36 'Content-Type': 'application/json',37 'x-api-key': process.env.ANTHROPIC_API_KEY,38 'anthropic-version': '2023-06-01'39 },40 body: JSON.stringify({41 model: 'claude-opus-4-8',42 max_tokens: 1000,43 messages: [44 {45 role: 'user',46 content: `You are a quality checker. Evaluate this output against these standards:4748$ {qualityStandard}4950Output to evaluate:5152$ {lastOutput}5354Respond with ONLY:55PASS if the output meets all required standards56FAIL: [specific description of what failed] if it does not meet required standards5758Do not explain. Do not suggest improvements. Just PASS or FAIL with specific failure description.`59 }60 ]61 })62 });6364 const verificationData = await verificationResponse.json();65 const verificationResult = verificationData.content[0].text.trim();6667 if (verificationResult.startsWith('PASS')) {68 return { output: lastOutput, attempts: attempt + 1, passed: true };69 }7071 lastFailure = verificationResult.replace('FAIL:', '').trim();72 attempt++;73 }7475 // All retries exhausted76 return {77 output: lastOutput,78 attempts: maxRetries,79 passed: false,80 failure: lastFailure81 };82}
Ce modèle génère une sortie, la vérifie par rapport à des normes définies et réessaie avec des corrections spécifiques en cas d'échec. Si toutes les tentatives échouent, il renvoie la meilleure sortie avec un indicateur d'échec plutôt que de planter.
Le modèle d'intégration de la mémoire
La mémoire est ce qui transforme un agent compétent en un agent apprenant.
Sans mémoire, chaque session repart de zéro. L'agent ne sait pas ce qu'il a fait auparavant. Il ne peut pas appliquer les apprentissages des exécutions passées. Il ne peut pas éviter les erreurs qu'il a déjà commises.
Avec mémoire, chaque session s'appuie sur la précédente. L'agent sait ce qui a fonctionné et ce qui n'a pas fonctionné. Il applique le contexte accumulé pour améliorer les résultats actuels. Il s'améliore sur la tâche spécifique au fil du temps.
Voici le modèle d'intégration de la mémoire pour tout agent Claude :
Au début de chaque exécution :
Lire les entrées mémoire étiquetées : [TAG-TÂCHE]
Limite : 20 entrées les plus pertinentes
Stratégie : pertinence (pas seulement récence)
Appliquer ce contexte :
- Noter les modèles des exécutions précédentes
- Noter les cas limites rencontrés précédemment
- Noter les problèmes de qualité identifiés précédemment
- Appliquer les apprentissages à l'exécution en cours
À la fin de chaque exécution :
Stocker en mémoire :
date : [AUJOURD'HUI]
tâche : [NOM DE LA TÂCHE]
qualité : [excellent/acceptable/échoué]
notable : [tout ce qui mérite d'être retenu]
cas_limite : [tout cas limite rencontré]
modèle : [tout modèle observé]
Tag : [TAG-TÂCHE], [DATE]
Consolidation mensuelle :
Lire toutes les entrées mémoire étiquetées : [TAG-TÂCHE]
Identifier :
- Les modèles qui apparaissent dans plusieurs entrées
- Les cas limites qui reviennent
- Les problèmes de qualité qui reviennent
- Ce qui corrèle avec des résultats excellents ou acceptables
Consolider en une seule entrée de contexte mise à jour
Archiver les entrées individuelles de plus de 90 jours
Le système de récupération après échec
Les agents du monde réel rencontrent des échecs. Les sources se déconnectent. Les API limitent le débit. Les fichiers ne sont pas là où on les attend. Les sorties échouent aux vérifications de qualité après le nombre maximum de tentatives.
Le système de récupération après échec détermine si ces échecs sont des incidents invisibles ou des arrêts catastrophiques.
Trois niveaux de gestion des échecs :
Niveau 1 : Récupération automatique
Échecs transitoires qui se résolvent par une nouvelle tentative. Outil indisponible. Délai d'attente réseau. Limite de débit atteinte.
Protocole de récupération niveau 1
En cas d'échec d'appel d'outil :
- Attendre 60 secondes
- Réessayer exactement le même appel
- Si la nouvelle tentative réussit : continuer normalement, enregistrer l'incident
- Si la nouvelle tentative échoue : passer au niveau 2
Niveau 2 : Dégradation élégante
Échecs qui ne peuvent pas être résolus mais permettent une réalisation partielle. Une source indisponible. Un outil qui ne répond pas. Une section de la sortie qui échoue aux vérifications de qualité.
Protocole de récupération niveau 2
En cas d'échec partiel irrésolvable :
- Réaliser ce qui peut être réalisé
- Noter spécifiquement ce qui a été sauté et pourquoi
- Marquer la sortie comme partielle dans le nom du fichier
- Inclure une note explicite dans la sortie elle-même
- Envoyer une notification : « Sortie partielle — [raison spécifique] »
- NE PAS faire échouer toute la tâche parce qu'un composant a échoué
Niveau 3 : Arrêt élégant
Échecs qui rendent la tâche entière impossible. CLAUDE.md introuvable. Chemin de sortie non accessible en écriture. Base de données mémoire inaccessible.
Protocole de récupération niveau 3
En cas d'échec complet :
- Identifier le point d'échec spécifique
- Sauvegarder tout travail réalisé dans un emplacement temporaire
- Enregistrer le contexte complet de l'échec
- Envoyer une notification : « Tâche échouée — [raison spécifique] »
- S'arrêter proprement sans corrompre les sorties existantes
- Ne PAS réessayer automatiquement — attendre une intervention humaine
Tester votre agent avant le déploiement
L'erreur la plus courante dans le déploiement d'agents réels est de sauter les tests structurés.
Trois phases de test avant qu'un agent ne soit mis en service :
Phase 1 : Test des composants
Tester chaque composant isolément avant de tester l'ensemble du workflow.
Tester que la mémoire persiste
hermes chat
Quelle est l'entrée mémoire la plus ancienne que vous avez stockée ?
Attendu : Doit signaler une entrée ou signaler une base de données vide
Si retourne une erreur : la configuration mémoire est incorrecte
Tester l'accès aux outils
Listez les fichiers dans [CHEMIN DE SORTIE]
Attendu : Doit lister les fichiers réels
Si retourne une erreur : le MCP du système de fichiers n'est pas configuré correctement
Tester la recherche
Recherchez « actualités IA aujourd'hui » et dites-moi le premier résultat
Attendu : Doit renvoyer des résultats de recherche réels
Si retourne une erreur : le MCP Brave Search n'est pas configuré correctement
Phase 2 : Test du chemin heureux
Exécuter la compétence manuellement sur une entrée standard propre et vérifier que la sortie répond au standard de qualité.
Exécuter la compétence manuellement
hermes run research-brief
Vérifier la sortie
cat outputs/briefings/[AUJOURD'HUI]-morning-brief.md
Vérifier selon le standard de qualité :
- Minimum 3 éléments de signal ?
- Chaque élément pertinent pour le travail en cours ?
- Pas d'analyse générique ?
- Se lit en moins de 5 minutes ?
Phase 3 : Test des cas limites
Déclencher délibérément chaque cas limite documenté et vérifier le comportement de récupération.
Test : pas d'accès internet
Désactiver Brave Search dans .env
Exécuter la compétence
Attendu : Échec niveau 3, arrêt propre, notification envoyée
Test : chemin de sortie non accessible en écriture
Modifier OUTPUT_PATH vers un répertoire inexistant
Exécuter la compétence
Attendu : Échec niveau 3, arrêt propre, notification envoyée
Test : jour creux dans l'actualité
Exécuter un week-end ou un jour férié
Attendu : Sortie niveau 2 avec NOTE DE COUVERTURE indiquant un jour creux
Exécuter votre agent en production
Une fois les trois phases de test réussies, configurer le planificateur et passer en production.
1{2 "schedules": [3 {4 "skill": "research-brief",5 "cron": "0 6 * * *",6 "description": "Tous les jours à 6h00",7 "timeout_minutes": 15,8 "on_failure": "notify_and_stop"9 }10 ]11}
Démarrer Hermes en mode arrière-plan :
npm run start -- --daemon
Vérifier la première exécution planifiée :
Vérifier les logs après 6h00
cat logs/hermes-[DATE].log
Vérifier que la sortie a été produite
ls outputs/briefings/
Vérifier que la mémoire a été mise à jour
hermes chat
Combien d'entrées mémoire research-brief avez-vous ?
Si la première exécution automatisée produit une bonne sortie, l'agent est en production.
Ce qui change au 3e mois
Mois un : L'agent fonctionne de manière fiable. Les sorties sont cohérentes. Les échecs sont gérés avec élégance. Vous économisez quarante-cinq minutes chaque matin.
Deuxième mois : la couche mémoire commence à produire une amélioration visible. L’agent a traité soixante jours de sources et accumulé un contexte sur les sources qui génèrent un contenu de grande valeur par rapport au bruit. La qualité du filtrage du signal s’améliore parce que l’agent a appris quelles sources méritent d’être suivies.
Troisième mois : la consolidation de la mémoire a eu lieu deux fois. L’agent a identifié des tendances sur quatre-vingt-dix jours de recherche. Les briefs font référence au contexte accumulé, ce qui les rend plus solides et plus précis que toute recherche effectuée en une seule session.
L’agent au troisième mois n’exécute pas le même workflow qu’au premier mois.
Il exécute une version améliorée de ce workflow, basée sur quatre-vingt-dix jours d’intelligence opérationnelle accumulée.
C’est la différence entre un agent de tutoriel et un agent du monde réel.
L’agent de tutoriel exécute la tâche.
L’agent du monde réel apprend à mieux exécuter la tâche.
Construisez les bases ce week-end.
Faites-le tourner une semaine. Réparez ce qui casse.
Faites-le tourner un mois. Regardez-le s’améliorer.
Faites-le tourner trois mois. Construisez les bases ce week-end.
Faites-le tourner une semaine. Réparez ce qui casse.
Faites-le tourner un mois. Regardez-le s’améliorer.
Faites-le tourner trois mois. Observez ce qu’il sait que vous n’auriez pas pu lui dire le premier jour.
Voilà à quoi ressemble la construction d’un agent Claude qui fonctionne réellement dans le monde réel.
Suivez @cyrilXBT pour chaque architecture d’agent, modèle de compétence et modèle de déploiement en production qui permet à vos agents Claude de survivre au contact avec le monde réel.
