Donnez une memory à votre agent

Tutoriel · 5 min de lecture

Les memories d'agent sont de courtes notes privées attachées à votre compte Skilnu — une préférence, une contrainte, un fait qu'on ne veut plus réexpliquer — que n'importe quel client MCP que vous connectez peut enregistrer, et que n'importe quel client MCP que vous connecterez plus tard peut retrouver. Ce ne sont ni une transcription ni un skill : rien n'est mémorisé à moins que quelque chose l'enregistre explicitement, et rien de ce que vous enregistrez ici n'est versionné, composé ou publié. C'est une fonctionnalité Pro/Team ; un compte gratuit reçoit une erreur de mise à niveau claire plutôt qu'un échec silencieux.

1. Enregistrez quelque chose qui mérite d'être retenu

Dans l'application, ouvrez le menu du compte et cliquez sur Memories. Écrivez ce que vous voudriez que n'importe quel agent sache déjà — « les déploiements se font via GitHub Actions sur main, jamais manuellement » est utile ; « longue conversation sur la CI mardi » ne l'est pas, parce qu'il n'y a rien à en tirer. Ajoutez quelques tags séparés par des virgules si vous voulez la retrouver par sujet plus tard, puis enregistrez-la.

Le contenu est limité à 4 000 caractères — une note, pas un document. Si ce que vous enregistrez est plus long que ça, c'est probablement un skill, pas une memory : publiez-le plutôt, pour qu'il puisse être versionné et partagé au lieu d'être silencieusement tronqué.

2. Retrouvez-la

La recherche classe les résultats de façon sémantique quand elle le peut : chercher « comment cette personne aime les revues de code » peut faire apparaître une memory que vous aviez formulée « merci de ne pas pinailler sur les noms de variables », parce que les deux veulent dire la même chose même s'ils ne partagent presque aucun mot. Quand aucune correspondance sémantique n'atteint le seuil, elle revient à une simple correspondance par mot-clé sur le contenu et les tags, donc la recherche ne revient jamais vide juste parce que l'étape d'embedding n'a pas tourné.

Laissez le champ de recherche vide pour tout parcourir, du plus récent au plus ancien.

3. Supprimez-la quand elle est fausse ou obsolète

Cliquez sur Oublier sur n'importe quelle memory et confirmez. Il n'y a pas d'annulation, comme pour toute autre suppression sur la plateforme — une memory devenue fausse (une préférence que vous n'avez plus, un fait qui a cessé d'être vrai) vaut mieux supprimée que laissée pour qu'un agent lui fasse confiance plus tard.

Le faire depuis un agent

Les quatre mêmes actions sont quatre outils MCP, si bien qu'un agent peut enregistrer et retrouver des memories en pleine conversation sans que vous ouvriez l'application :

save_memory(content="Deploys happen via GitHub Actions on main.", tags=["ci", "deploy"])
  -> { memory_id, content, tags, created_at }

search_memories(query="how are deploys triggered")
  -> { items: [...], total, limit, offset }

list_memories(limit=20)
  -> { items: [...], total, limit, offset }

forget_memory(memory_id="...")
  -> { deleted: true, memory_id }

Les quatre acceptent un publisher_id optionnel, nécessaire seulement si votre connexion est liée à plus d'un publisher — la plupart des connexions ne le sont pas, donc la plupart des appelants peuvent l'omettre.

Le jugement de savoir si quelque chose vaut la peine d'être enregistré revient à l'agent de le faire bien, de la même façon qu'il vous revient quand vous remplissez le formulaire web — un outil qui appelle save_memory à chaque remarque qui passe produit le même tas inutile qu'un fichier de notes où l'on copie-colle tout.

Ce que ça coûte

Enregistrer, lister, rechercher et oublier des memories ne coûte rien au-delà de l'abonnement Pro ou Team lui-même — il n'y a pas de quota par appel comme pour la compilation d'un skill. La seule limite est un plafond de 2 000 memories par compte ; au-delà, save_memory renvoie une erreur claire nommant la limite plutôt que de supprimer silencieusement l'entrée la plus ancienne.

Quoi enregistrer, quoi ne pas enregistrer

Les bonnes memories se lisent comme des instructions pour la prochaine fois : une préférence stable, une contrainte fixe, un fait qui ne changera pas de session en session. Les mauvaises se lisent comme une entrée de journal sur cette session — un résumé de ce qui s'est passé plutôt qu'une indication de ce qu'il faut faire. Si vous ne voudriez pas le répéter à un nouveau collègue le premier jour, ce n'est probablement pas la peine de l'enregistrer ici non plus.