Un système de mémoire Codex pour débutants : configuration en un clic et analyse approfondie

Fable5 a fait un retour triomphal, et en tant qu'utilisateur vétéran de Codex, je n'ai pas pu résister à l'envie de le tester pour voir s'il est à la hauteur du battage médiatique — en particulier, s'il pourrait remplacer Codex ou aider à itérer sur le système de mémoire que j'ai optimisé à l'extrême. J'ai rechargé 10 $ sur Zenmux et connecté Fable5 à Claude Code. En résumé : Fable5 est le « papa » de l'intelligence « ultra-élevée » de Codex !!! (Lien vers la compétence du système de mémoire à la fin).

Concernant mon précédent système de mémoire semi-fini :

https://x.com/gengdaJ/status/2067985719675773192

https://x.com/evermind/status/2063262473357336824

https://x.com/gengdaJ/status/2068555151733043504

Fable5 est en effet cher, alors j'ai suivi les conseils d'experts sur mon fil d'actualité et j'ai laissé Fable5 gérer les phases de conseil et de planification pour le système de mémoire Codex.

On ne sait pas tant qu'on n'a pas demandé — la première vérification utilisant les « Premiers principes » a identifié un tas de bugs et d'opportunités d'optimisation. Son professionnalisme technique est incontestable, comme Codex lui-même l'a admis. Bien que les suggestions de Fable5 aient parfois manqué de rigueur, dans une comparaison 4:1, Fable5 a gagné haut la main.

Ce n'était que la première étape. Les capacités incroyables de Fable5 commençaient tout juste à se manifester. J'ai demandé à Codex d'organiser un plan de développement et je l'ai envoyé à Fable5 pour révision. Fable5 a continué à le remettre en question, et Codex a continué à être d'accord.

J'ai ensuite demandé à Codex d'optimiser en fonction des suggestions de Fable5. Pensant que c'était parfait, je l'ai renvoyé à Fable.

Au final, Fable a encore trouvé de nombreux problèmes. Je suis vraiment impressionné. J'ai rapidement fait reconnaître à Codex son « père » le plus strict.

Après le développement, Fable5 est resté incisif, écrasant la phase de révision de code.

Après ce test, je dois admettre que Fable5 est incroyablement solide dans la prise de décision et le jugement. Même en tant qu'utilisateur fidèle de Codex, je dois le féliciter. Je vais continuer à utiliser Fable5 pour les systèmes complexes (comme l'optimisation des systèmes de recherche d'Agent ensuite). C'est cher, mais ça vaut le coup quand on l'utilise là où il faut.

Si vous voulez essayer les capacités de planification terrifiantes de Fable5, vous pouvez appeler l'API Zenmux comme je l'ai fait (ils ont, à mon avis, la meilleure qualité de source Claude) : https://zenmux.ai/invite/GYMUHL. J'ai remarqué aujourd'hui que les abonnés gratuits peuvent essayer la version web, et les utilisateurs payants (crédits > 0) peuvent appeler l'API directement gratuitement, avec un bonus de 20 % sur les rechargements — un petit avantage sympa !

Parlons maintenant de cette architecture de système de mémoire reconstruite par Fable5. Vous comprendrez à quel point elle est puissante grâce à cette simple décomposition :

Mon système de mémoire Codex actuel est un coffre-fort de mémoire Agent Obsidian local, vérifiable, consultable et maintenable. Il transforme de manière transparente les projets, les pièges, les préférences, les décisions et les workflows réutilisables partagés avec Codex en documents Markdown dans Obsidian. Il utilise ensuite SQLite, la recherche en texte intégral, la recherche sémantique, Git, les hooks et les scripts de clôture pour atteindre l'auto-fonctionnement et l'auto-itération.

Concepts de base

Avant de plonger dans les fonctions, vous devez comprendre huit concepts de base :

• Obsidian Markdown : Les archives mémoire originales Ce sont essentiellement des fichiers texte .md standard. Pourquoi ne pas utiliser une base de données ? Parce qu'Obsidian est plus convivial pour les non-programmeurs — les humains peuvent les lire et les éditer directement, et Git peut suivre les modifications. C'est la « source de vérité » du système de mémoire.

• INDEX.md : Le bureau d'orientation et de navigation INDEX.md n'est pas la mémoire elle-même mais une « carte d'entrée ». Si Markdown est une bibliothèque, INDEX.md est le catalogue du bureau d'accueil indiquant à l'Agent quels fichiers sont importants et où trouver les réponses.

• SQLite / FTS : Les fiches de récupération rapide SQLite est une petite base de données locale, et FTS est sa capacité de recherche en texte intégral. Ce n'est pas la « source des faits » mais un « index de recherche », comme les fiches de bibliothèque pour les titres, les mots-clés et les résumés.

• Zvec : La recherche sémantique Zvec est la récupération vectorielle, ce qui signifie « rechercher par le sens ». Alors que la recherche standard nécessite des mots-clés exacts, la recherche sémantique peut trouver des souvenirs pertinents même si vous n'utilisez pas les termes exacts.

• Git : L'assurance des enregistrements de modifications et du retour en arrière Git est un système de contrôle de version. Il répond à : Qui a modifié cela et quand ? Quelles lignes ont été modifiées ? Peut-on revenir en arrière en cas d'erreur ?

• Script closeout : L'organisateur automatique post-tâche Closeout automatise le processus de nettoyage. Il garantit que la mise à jour des souvenirs, l'actualisation des index et le commit sur Git ne sont pas laissés à la « mémoire » de l'Agent, mais sont gérés par une seule commande.

• Script audit : Le médecin des bilans de santé périodiques Au fur et à mesure que le coffre-fort grandit, les choses deviennent désordonnées. Audit identifie les souvenirs obsolètes, les boucles ouvertes non résolues depuis longtemps et les fichiers en double pour un examen humain.

• AGENTS.md : La constitution du système AGENTS.md définit les règles de comportement de l'Agent : quand lire la mémoire, quoi écrire, et quand il DOIT demander à l'utilisateur (par exemple, pour des données sensibles ou des suppressions).

Flux de travail du système de mémoire

1. Entrée de la tâche : L'utilisateur pose une question.
2. Lire AGENTS.md : Déterminer les limites et les règles opérationnelles.
3. Lire INDEX.md : Localiser les fichiers pertinents avec un faible coût en tokens.
4. Récupération unifiée : Utiliser SQLite/Zvec si nécessaire pour trouver des souvenirs spécifiques.
5. Lire la source Markdown : Confirmer les faits à partir des fichiers lisibles réels.
6. Exécuter la tâche : Travailler avec un contexte à long terme.
7. Juger la valeur de la mémoire : Décider si la nouvelle information mérite d'être sauvegardée.
8. Concilier avant d'écrire : Vérifier les doublons ou les conflits avec les anciens souvenirs.
9. Écrire dans Markdown : Catégoriser et sauvegarder dans le répertoire correct.
10. Exécuter Closeout : Actualiser les index, vérifier les informations sensibles et enregistrer la session.
11. Journalisation Git : Créer une piste vérifiable des modifications.
12. Audit périodique : Maintenir la santé du coffre-fort grâce à des vérifications hebdomadaires.

Avantages du système de mémoire

1. Source de faits contrôlable : Stockée dans du Markdown local, non enfermée dans une plateforme.
2. Récupération complète : Combine la navigation, la recherche par mots-clés et la recherche sémantique.
3. Réconciliation : Empêche les doublons et les conflits avant l'écriture.
4. Boucle Closeout : Transforme la sauvegarde de la mémoire en un processus standardisé.
5. Versionnage Git : Offre une traçabilité complète et des capacités de retour en arrière.
6. Mécanisme d'audit : Maintient le coffre-fort de mémoire propre et pertinent.
7. Automatisation maîtrisée : Les actions à haut risque nécessitent toujours une confirmation humaine.
8. Auto-évolution : Permet à l'Agent de développer ses capacités grâce à une expérience vérifiée.

Enfin, j'ai encapsulé ce système de mémoire dans une compétence : https://github.com/mcncarl/codex-memory. Vous pouvez le connecter à Codex ou continuer à l'optimiser pour vos propres besoins ! ☺️