Einen Gedächtnisdienst für KI-Agenten bauen, ohne die Erinnerungen von Benutzern zu vermischen

## Gedächtnisarten trennen und keine Daten zwischen Banken vermischen Halte die Arten gespeicherten Wissens getrennt, da Aufnahme, Abruf und Schlussfolgerung sie unterschiedlich nutzen. ### Gedächtnis explizit modellieren - Weltfakten stellen allgemeines Wissen dar. - Erfahrungsfakten stellen persönliche Ereignisse dar, die einem Benutzer oder Agenten zugeordnet sind. - Mentale Modelle bündeln Muster, die aus mehreren Fakten abgeleitet wurden. - Jede Gedächtnisbank darf Hintergrundkontext und Dispositionsmerkmale wie Skepsis, Wörtlichkeit und Empathie auf einer Skala von 1–5 enthalten. - Wende Dispositionen nur auf reflektierendes Schlussfolgern an; sie dürfen den Abruf von Fakten nicht verändern. ### Banken isolieren - Behandle jede Bank als unabhängigen Gedächtnisspeicher für einen Benutzer oder Agenten. - Verhindere bankübergreifende Datenlecks bei Speicherung, Abruf, Schlussfolgerung und Tests. - Arbeite pro API-Anfrage mit genau 1 Bank. - Lass die Clients jeden Ablauf mit mehreren Banken orchestrieren, statt die Servergrenze aufzuweichen. ## Aufnahme, Abruf und Schlussfolgern trennen und mehrere Suchwege kombinieren Trenne die drei primären Operationen, während sie stabile Abstraktionen für Modelle, Einbettungen, Entitäten und Rangbildung gemeinsam nutzen. ### Semantik der Operationen bewahren - Retain nimmt Inhalte auf und extrahiert Fakten, Entitäten und Beziehungen. - Recall ruft vorhandene Erinnerungen ab, ohne Dispositionsmerkmale anzuwenden. - Reflect führt dispositionsbezogene Schlussfolgerungen über Erinnerungen und konsolidierte mentale Modelle durch. - Halte die Orchestrierung von Faktenextraktion, Entitätsnormalisierung, Verknüpfungsverwaltung und Anbieteradaptern getrennt. ### Abruf als Pipeline aufbauen - Führe 4 sich ergänzende Abrufstrategien parallel aus: semantischen Abruf, lexikalischen BM25-Abruf, Graphabruf und zeitlichen Abruf. - Führe die Ranglisten mit reziproker Rangfusion zusammen, bevor ein Cross-Encoder sie neu sortiert. - Kapsle die Grapherweiterung hinter einer Abrufschnittstelle, damit alternative Strategien austauschbar bleiben. - Unterstütze lokale und entfernte Anbieter für Modelle, Einbettungen und Neusortierung über schlanke Wrapper. ### API-Verträge synchronisieren - Erzeuge die OpenAPI-Spezifikation nach Änderungen an Endpunkten neu. - Erzeuge nach Spezifikationsänderungen jedes unterstützte Client-SDK neu, einschließlich Python, TypeScript und Rust. - Wenn sich ein API-Parameter ändert, aktualisiere gemeinsam die Proxy-Route, die Anfrageextraktion, den SDK-Aufruf, den Client-Typ und jede nutzende Schnittstelle. ## Eine Migration schreiben, die auf PostgreSQL und Oracle läuft Verwende für alle unterstützten Datenbanken einen gemeinsamen Migrationsverlauf und bilde Dialektunterschiede ausdrücklich ab. ### Revision definieren - Gib jeder Migration eine eindeutige 12-stellige hexadezimale Revisionskennung und verweise mit `down_revision` auf ihren Vorgänger. - Halte das Verhalten von Upgrade und Downgrade aufeinander abgestimmt. - Leite die Ausführung durch einen einzigen Dialekt-Router, der anhand der aktiven Verbindung die Implementierung auswählt. - Der Test der Migrationsform muss fehlschlagen, wenn der Dispatcher fehlt. ### Jeden Dialekt implementieren - Stelle getrennte Upgrade- und Downgrade-Funktionen für PostgreSQL und Oracle-kompatible Datenbanken bereit. - Qualifiziere rohes PostgreSQL-SQL mit dem konfigurierten Mandantenschema, sofern eines vorhanden ist. - Nutze die Ausführung auf Treiberebene nur für Datenbankoperationen, die das Migrationsframework nicht abbilden kann, etwa spezielle Vektor-, Text- oder Partitionsoperationen. - Wenn eine Migration tatsächlich nur für 1 Dialekt gilt, lasse die andere Position bewusst aus; sie darf niemals versehentlich leer bleiben. - Berücksichtige bei der Prüfung Schemaabweichungen zwischen den Dialekten. ### Ausführung prüfen - Führe Migrationen für das Basisschema und alle Mandantenschemata aus. - Unterstütze für eine gezielte Prüfung auch einen Lauf für 1 namentlich genanntes Mandantenschema. - Wenn Migrationen beim Dienststart automatisch laufen, teste den Start für jeden unterstützten Dialekt und Mandantenumfang. ## Vor dem Push Pflichtprüfungen und Code-Review bestehen Nutze nach jeder Implementierungsänderung die kanonische Werkzeugkette und unterscheide blockierende Mängel von unverbindlichen Bereinigungen. ### Erforderliche Prüfungen ausführen - Führe nach Änderungen an Python oder TypeScript Formatierung, Linting und Typprüfung aus. - Behandle ungenutzte Imports und Variablen, verwaiste Client-Dateien und nicht aufgeführte Paketabhängigkeiten als blockierende Fehler. - Behandle vollständig ungenutzte Funktionen und bewusst breit angelegte Exporte von Komponentenbibliotheken als Hinweise, sofern die Projektrichtlinie sie nicht zu blockierenden Fehlern hochstuft. - Führe Unit-Tests, API-Integrationstests und relevante Benchmarks über die Standardbefehle des Repositorys aus. - Erzeuge API-Spezifikationen und Clients bei Bedarf neu und stelle anschließend sicher, dass keine nicht eingecheckten Unterschiede an erzeugten Dateien verbleiben. ### Vor der Veröffentlichung prüfen - Führe nach der Implementierung eine strukturierte Codeprüfung durch. - Behebe jeden zwingenden Befund zu fehlenden Tests, totem Code, Typsicherheit, Datenisolation oder Abweichungen erzeugter Dateien. - Übertrage keinen Code und erstelle keine Änderungsanfrage, bevor alle zwingenden Befunde behoben sind. - Füge unveröffentlichte Einträge im Änderungsprotokoll nicht manuell hinzu; der Veröffentlichungsprozess soll versionierte Einträge erstellen. ## Feste Logik direkt testen und Modellantworten von einem zweiten Modell bewerten lassen Wähle Zusicherungen danach aus, ob das Verhalten mechanisch deterministisch ist oder von der Interpretation des Modells abhängt. ### Deterministische Mechanismen direkt testen - Verwende direkte Zusicherungen für Anzahlen, Pflichtfelder, Prompt-Zusammenstellung, Unterdrückungslogik und eingefügte Teilzeichenfolgen. - Halte die meisten Tests mit simulierten Modellen oder reinen Funktionen schnell. - Ergänze Modellverhaltenstests um Unit-Tests, die ihre deterministische Vorbereitung abdecken. ### Semantisches Modellverhalten beurteilen 1. Markiere einen semantischen Test für den Kernmodelllauf eines einzelnen Anbieters; reserviere die Anbietermatrix-Markierung für die anbieterübergreifende Abnahme. 2. Rufe die tatsächlich konfigurierte Pipeline statt einer Simulation auf. 3. Fasse die Antwort mit den für die Bewertung erforderlichen semantischen Bezeichnungen zusammen. 4. Lass ein unabhängiges Bewertungsmodell entscheiden, ob die Antwort die ausdrücklichen Kriterien im bereitgestellten Kontext erfüllt. 5. Bewerte niemals mit demselben Modellaufruf, der getestet wird. - Verwende Bewertungen des Prüfmodells für Klassifizierung, Zuordnung, Erhaltung der Dimensionen und Befolgung von Anweisungen. - Kodiere keine exakten Zeichenfolgen oder Aufzählungswerte fest für Verhalten, das sich zwischen Modellen und Läufen berechtigterweise unterscheiden kann. ## API-Änderungen in alle Clients übernehmen und CI für neue Integrationen ergänzen Eine Integration ist erst vollständig, wenn Laufzeitverhalten, Tests, kontinuierliche Integration, Veröffentlichungsregistrierung und Client-Schnittstellen übereinstimmen. ### API-Nutzer aktualisieren - Wenn du ein Anfragefeld hinzufügst, extrahiere es in der Proxy-Route und übergib es an den SDK-Aufruf. - Aktualisiere den Typ der Client-Methode und jede Schnittstelle, die das Feld bereitstellt oder liest. - Begrenze jede Anfrage auf 1 Bank und erhalte die clientseitige Orchestrierung für Anwendungsfälle mit mehreren Banken. ### Eine Integration vervollständigen - Füge Tests hinzu, die die Schnittstelle des externen Frameworks simulieren oder ausführen, und prüfe, ob die Integration den Gedächtnisdienst korrekt aufruft. - Betrachte Unit-Tests, die nur Hilfsfunktionen testen, nicht als ausreichende Integrationsabdeckung. - Füge einen auf die Änderung begrenzten Auftrag für kontinuierliche Integration hinzu, der den Build ausführt, Abhängigkeiten installiert und die Integrationstests ausführt. - Registriere die Integration im standardmäßigen Veröffentlichungsablauf. - Verwende typisierte Strukturen statt unbearbeiteter Wörterbücher für strukturierte Daten und vermeide Rückgaben von Tupeln mit mehreren Elementen. - Führe weder einen Merge noch eine Veröffentlichung durch, solange Tests, CI-Änderungserkennung oder Veröffentlichungsregistrierung fehlen. ## Vor dem Hinzufügen klären, ob eine Einstellung pro Mandant oder Bank änderbar ist Ordne jede Einstellung vor der Implementierung ein, damit Überschreibungsumfang und Dokumentation konsistent bleiben. ### Konfigurationsebene wählen - Löse hierarchische Einstellungen von globalen Umgebungswerten über Mandantenüberschreibungen bis zu Datenbanküberschreibungen auf Bankebene auf. - Nutze hierarchische Konfiguration für Modellanbieter, Modellnamen, API-Schlüssel, operationsspezifische Optionen und kundenspezifische Funktionsschalter. - Halte Datenbankadressen, Hosts, Ports, globale Parallelitätsgrenzen und systemweite Schalter auf Serverebene statisch. - Füge kein statisches Feld zur Menge der fernkonfigurierbaren Felder hinzu. ### Ein Feld vollständig hinzufügen 1. Definiere den Namen der Umgebungsvariable und den Standardwert. 2. Füge dem zentralen Konfigurationsobjekt ein typisiertes Feld hinzu. 3. Füge es nur dann zur Zulassungsliste konfigurierbarer Felder hinzu, wenn Überschreibungen auf Mandanten- oder Bankebene zulässig sind. 4. Initialisiere es aus der Umgebung. 5. Füge nur dann eine Befehlszeilenoption hinzu, wenn eine Überschreibung über die Befehlszeile erforderlich ist. 6. Lies hierarchische Werte über den Resolver pro Bank und statische Werte über den globalen Zugriff. 7. Aktualisiere die Konfigurationsreferenz und die Umgebungsvorlage mit Beschreibung, Standardwert und Hierarchiestatus. 8. Synchronisiere jede mitgelieferte Kopie der Umgebungsvorlage und stelle sicher, dass der Vorlagensynchronisationstest weiterhin besteht. - Lege niemals echte Zugangsdatenwerte in Dokumentation, Vorlagen, Protokollen oder Tests offen.