Arrêtez de déverser la mémoire de l'agent dans le prompt

La plupart des développeurs construisent des boucles d'agents en ajoutant tout au prompt suivant.

Vous ajoutez les observations précédentes, les appels d'outils et les traces de raisonnement. Vous continuez à ajouter des données jusqu'à ce que le prompt devienne un tiroir à bric-à-brac. Le modèle voit plus de choses, mais vous perdez le contrôle. Vous ne savez plus quel élément de mémoire a provoqué une décision spécifique.

Un nouvel article intitulé AgenticSTS suggère une approche différente. Il traite la mémoire comme une interface plutôt que comme une compétition pour obtenir la fenêtre de contexte la plus large.

L'article utilise le jeu Slay the Spire 2 comme banc d'essai. Cet environnement nécessite des centaines de décisions stratégiques. Il ne s'agit pas d'un simple chatbot.

L'idée centrale est la suivante : la mémoire est un contrat définissant ce qu'une décision future est autorisée à voir.

Au lieu de transcriptions brutes, les auteurs composent de nouveaux prompts en utilisant cinq couches spécifiques :

  • Instructions de protocole fixes
  • État actuel et schémas d'action
  • Règles de jeu récupérées
  • Résumés des exécutions précédentes
  • Compétences stratégiques déclenchées

Cette structure change tout. Vous pouvez inspecter, figer ou désactiver chaque couche. Vous transformez la mémoire, passant d'un tas de données à des preuves sélectionnées.

De nombreux échecs d'agents en production ne sont pas des échecs du modèle. Ce sont des échecs de contexte. L'agent mélange l'ancien état avec le nouvel état ou prolonge des réflexions obsolètes. Si votre seule politique consiste à ajouter du texte, le débogage ressemble à de l'archéologie.

Une interface de mémoire typée vous donne un élément de comparaison.

Pour les agents de longue durée, une fenêtre de contexte immense est un piège. Elle devient un mélange de faits, de faits obsolètes et de tentatives infructueuses. Plus la fenêtre est grande, plus il est facile de confondre les sédiments avec la mémoire.

Pour construire de meilleurs agents, suivez ces modèles :

  • Séparez les instructions stables de l'état actuel
  • Gardez les règles dans une couche de récupération
  • Stockez l'expérience sous forme d'enregistrements explicites, et non comme des résidus de chat
  • Transformez les corrections répétées en compétences déclenchées
  • Rendez chaque couche de mémoire supprimable pour les tests

Si vous ne pouvez pas désactiver une couche de mémoire, vous ne savez pas si elle aide réellement. Vous savez seulement que l'ensemble du tas fonctionne parfois.

Arrêtez de traiter la mémoire de l'agent comme une couche de « vibes ». Passez à un système où vous savez exactement ce qui alimente la décision suivante, d'où cela vient et comment le désactiver.

Si votre agent ne peut pas expliquer ce qu'il était autorisé à mémoriser, il n'a pas de mémoire. Il a simplement un prompt avec un sous-sol.

Source: https://dev.to/komo/stop-dumping-agent-memory-into-the-prompt-58ka

Communauté d'apprentissage optionnelle: https://t.me/GyaanSetuAi