Einstein (module de mémoire)

Einstein est le plugin officiel de mémoire à long terme pour AiHummer. Il donne à un agent une mémoire durable et consultable qui survit aux redémarrages et aux conversations, sans jamais transformer cette mémoire en boîte noire. La règle directrice est simple : PostgreSQL est le système de stockage et le Markdown canonique est sa projection lisible par les humains, et le système indexe et propose des modifications. En mode review, chaque promotion dans la mémoire à long terme est examinée par un humain ; en mode auto (par défaut), un fait que l’agent enregistre explicitement avec l’outil memory_store devient immédiatement consultable.

Le plugin fonctionne en natif sur l’hôte en tant que petit service Python indépendant (bibliothèque standard seulement — aucun framework lourd) et communique avec la passerelle via le aihummer.memory.v1 contrat. Le sous-système mémoire de la passerelle d’entrée (réclamations, rappel, la barrière de données) est décrit sur la page du concept Mémoire (Einstein); cette page couvre le plugin qui le soutient.

Faits

Champ	Valeur
Version	1.0.0
Port	8820
Exécution	Python (bibliothèque standard), natif de l’hôte

Ce que c’est

Einstein stocke la mémoire comme Markdown lisible par l’homme — le dossier canonique qu’une personne peut ouvrir, lire et modifier. Au-dessus de ce dossier, il construit la machinerie dont un agent a besoin au moment du tour :

Récupération — récupérer la mémoire pertinente à la conversation actuelle.
Rechercher — recherche en texte intégral et basée sur les embeddings sur les faits stockés.
Incorporations — vecteurs pour le rappel sémantique, servis via HTTP.

Parce que le Markdown est canonique, rien dans les index n’est précieux : ils peuvent être reconstruits à partir de ce registre canonique à tout moment, et un réviseur lit toujours le même texte que l’agent.

Comment il est utilisé

Au moment du tour, la passerelle demande à Einstein la mémoire pertinente au contexte actuel. Le rappel est transmis au modèle en tant que résultat d’outil enveloppé dans une barrière de données, jamais comme des instructions injectées — donc une note malveillante qui se retrouve en mémoire ne peut pas détourner l’agent. Les nouveaux faits observés lors d’une conversation sont extraits comme réclamations avec des preuves et mis en file d’attente pour révision plutôt qu’écrit directement en mémoire.

Il existe un second chemin : un agent peut enregistrer un fait lui-même avec l’outil memory_store. La façon dont cette écriture atterrit est décidée par le mode de capture mémoire du noyau — avec auto (par défaut), le fait est immédiatement consultable ; avec review ou off, il devient un candidat en attente d’approbation. Le résultat de l’outil porte un champ searchable_now, de sorte que l’agent peut vous dire honnêtement si le fait qu’il vient d’enregistrer peut déjà être rappelé.

[!NOTE] Le système indexe et propose, mais ne réécrit jamais silencieusement la mémoire. En mode review, la promotion d’une réclamation dans la mémoire à long terme est une étape délibérée, examinée par des humains ; en mode auto (par défaut), les faits que l’agent enregistre explicitement sont immédiatement consultables. Le mode mémoire (auto / révision / off) et le mode de récupération (texte intégral / embeddings) sont des paramètres du noyau (AIHUMMER_MEMORY_CAPTURE / AIHUMMER_MEMORY_RETRIEVAL dans le catalogue des paramètres), pas un formulaire du plugin.

La plateforme mémoire v2 (activée par défaut)

Einstein expédie le complet plateforme de mémoire v2, et toute sa puissance est hors de la boîte — rien à câbler à la main : extraction des revendications, une file de révision, un dériveur en arrière-plan (faits, liens et entités à partir des preuves), un passage de « rêve »/consolidation (déduplication et auto-réparation de la mémoire), un graphe de mémoire et détection des contradictions. Le mode mémoire, l’incorporateur et le stockage vectoriel se configurent séparément, comme paramètres du noyau. Einstein lui-même est configuré par le fournisseur : le plugin n’expose aucun réglage opérateur, et sur la page Plugins, seule son action de mise à jour est disponible.

[!NOTE] Le seul pas humain est approuver une écriture dans la mémoire canonique (MEMORY.md). Chaque travailleur v2 écrit uniquement dans un magasin sidecar séparé et ne touche jamais le Markdown canonique. Lorsque Einstein dérive une modification qui vaut la peine d’être ajoutée au canon, il est affiché dans l’interface de révision et appliqué avec un clic. Ainsi, toute la puissance est disponible immédiatement, et pourtant la garantie centrale s’applique : La mémoire n’est jamais réécrite dans votre dos. C’est une décision de produit, pas un réglage opérateur.

Installation

Einstein est un plugin intégré: il s’installe automatiquement pour chaque locataire, transporte un Intégré badge dans la liste des plugins et ne peut pas être supprimé — la mémoire fait partie du cœur du produit. Le module lui-même est toujours présent, mais la collecte de mémoire peut être désactivée: le off mode mémoire (le paramètre du noyau AIHUMMER_MEMORY_CAPTURE) empêche la collecte de nouveaux souvenirs sans retirer le module. Il n’y a rien à installer séparément ; le cycle de vie complet des plugins réguliers est décrit dans Installation et mises à jour. Il n’y a pas de conteneurs — Einstein fonctionne comme son propre service systemd aux côtés de la passerelle.

Sécurité et limites

Le Markdown canonique est une projection lisible. Le magasin du système est PostgreSQL ; les index et les embeddings sont dérivables ; le texte canonique est ce qu’un révisions et modifications humaines.
Pas de réécritures silencieuses. La plateforme v2 fonctionne dès la sortie de l’emballage, mais une écriture vers Canon passe par une approbation humaine en un seul clic ; les travailleurs écrivent seulement au sidecar et ne touchent jamais au Markdown canonique.
Rappel protégé par des données. La mémoire atteint le modèle en tant que sortie d’outil clôturée, jamais comme instructions, ce qui bloque l’injection de prompt indirecte.
Interface Web sécurisée. L’interface de révision/gestion du plugin est contrôlée par des accès.
Hôte-natif. Fonctionne sous systemd, pas dans un conteneur.