Interactif3 min de lecture
Dreaming : apprendre en dormant
Le jour, des agents travaillent et notent ce qu'ils apprennent dans une mémoire partagée. La nuit, un agent séparé lit les transcriptions de toutes les sessions, repère ce qu'aucun agent seul ne pouvait voir, et propose un diff de la mémoire, que l'on relit avant de l'appliquer. Les agents du lendemain démarrent plus intelligents.
- Source
- Anthropic · Claude Managed Agents — Lamis Mukta, AI Native DevCon · Mahesh, Claude channel
- Tags
Mémoire : bêta publique. Dreaming : aperçu de recherche. note:20
D'après deux conférences d'Anthropic : le concept (Lamis Mukta) et le lancement et la démonstration (Mahesh).
Comment en est-on arrivé à une mémoire sous forme de fichiers ?
Quatre étapes de l'ingénierie du contexte. À chaque étape, l'agent gagne en autonomie, mais un problème reste à régler. Parcourez-les.
Que se passe-t-il si deux agents modifient la même note en même temps ?
L'API mémoire utilise la concurrence optimiste : l'agent lit le hachage du contenu, rédige sa modification, puis vérifie que le hachage n'a pas changé avant d'écrire. Sinon, il relit et recommence. Faites écrire les deux agents.
Agent SRE n° 1
Hachage lu :
Veut ajouter : « alerte P1 liée au service paiement »
Agent SRE n° 2
Hachage lu :
Veut ajouter : « redémarrage du pod sans effet »
Illustration : le « hachage » affiché est un calcul simple sur le texte, pas l'algorithme de l'API. Le mécanisme (lire, rédiger, vérifier, réessayer) est celui de la conférence. note:51
Pourquoi un agent seul ne voit-il pas le problème ?
Dans la démonstration, chaque alerte se déclenche exactement 60 s après un pic de CPU en amont. Une session voit une alerte ; seul celui qui lit beaucoup de sessions voit le schéma. Augmentez le nombre de sessions lues.
Mémoire dans la bande (un agent)
Dreaming (hors bande)
Illustration : la conférence dit seulement que l'orchestrateur ne garde que les schémas « assez fréquents pour justifier un changement ». Le seuil de 5 occurrences et la proportion d'alertes concernées (2 sessions sur 3) sont inventés pour la démonstration. note:57 note:113
Que propose le dreaming, et qui décide ?
Le dreaming n'écrit pas directement : il produit un diff, avec pour chaque changement les transcriptions qui le justifient et sa fréquence. Un humain, ou une vérification automatique, l'accepte ou le rejette. Voici le diff de la démonstration ; relisez-le.
Magasin de mémoire SRE, le lendemain :
Les quatre types de changement (un ajout, cinq doublons fusionnés, une entrée obsolète supprimée, une mention « vérifié ») viennent de la démonstration. Le texte des entrées du magasin et les justifications sont inventés pour l'exemple. note:113
Les deux boucles côte à côte
La leçon de conception : un agent travaille mieux avec un seul objectif. La qualité de la mémoire devient un objectif séparé, avec son propre budget, hors du chemin critique. note:64
| Mémoire (dans la bande) | Dreaming (hors bande) | |
|---|---|---|
| Qui | l'agent au travail | un orchestrateur et ses sous-agents |
| Quand | pendant la session | par lots : cron, à la demande, fin de tâche |
| Voit | sa propre session | de nombreuses sessions et agents |
| Coût | tokens pris sur la tâche, latence | son propre budget |
| Bon pour | apprentissages rapides et locaux | schémas, doublons, obsolescence, vérification |
note:82–87
Par où commencer ?
- Au minimum : un
CLAUDE.md, des skills, et l'agent les gère. - Beaucoup d'agents ou un domaine complexe : ajoutez versions, hachages, permissions, API portable.
- Pour boucler la boucle : une passe de consolidation hors bande, le dreaming.
note:115–118
Résultats cités par Anthropic : Rakuten, −90 % d'erreurs au premier passage grâce à la mémoire ; Harvey, taux de réussite ×6 sur un scénario juridique avec le dreaming. note:59