Echo Memory

Eine Langzeit-Speicherarchitektur für KI-Agenten. Echo Memory wurde entwickelt, um alles zu speichern, was ein Agent jemals gelernt hat, auf die bestmögliche Weise, und um diesen Speicher effizient abzurufen und zu beschreiben, egal wie viel Historie sich ansammelt – für Codierungswerkzeuge, Chatbots, DevOps-Agenten oder jedes andere agentische System, lokal oder bereitgestellt.

Warum

Jeder KI-Agent startet bei null, es sei denn, etwas erinnert sich daran, was beim letzten Mal passiert ist, und erinnert sich gut genug und schnell genug, um auch nach Monaten oder Jahren angesammelter Historie noch nützlich zu sein. Die meisten Speicherwerkzeuge lösen Kurzzeit-Erinnerung mit einfacher Vektorsuche über gespeicherte Fakten. Das verschlechtert sich, wenn die Historie wächst: mehr Kandidaten, mehr Rauschen, langsamere Abfrage. Echo Memory ist um den Lese-/Schreib-Algorithmus und die Datenstruktur herum aufgebaut, die auch über lange Zeiträume funktionieren, nicht nur am ersten Tag:

• Ein zeitlicher, sich selbst konsolidierender Speichergraph. Fakten sind Kanten zwischen Entitäten, keine flachen Vektorzeilen. Alte, selten abgerufene Erinnerungen sammeln sich nicht einfach an: Sie werden im Laufe der Zeit zu übergeordneten Zusammenfassungen konsolidiert (nie gelöscht, immer bis zum Original zurückverfolgbar), sodass die Abrufkosten durch das begrenzt bleiben, was aktuell relevant ist, nicht durch alles, was jemals geschrieben wurde. Siehe docs/designs/echo-memory-design.md für den tatsächlichen Mechanismus.

• Echte Graphstruktur, nicht nur Ähnlichkeit. Mehrstufige Abfragen wie „Wie sind wir hierher gekommen?“, beantwortbar, weil Fakten verbunden sind, nicht nur einzeln eingebettet.

• Kausale Typisierung, nicht nur Ähnlichkeit. Kanten können mit caused_by, led_to, blocked_by, contradicts getaggt werden, festgelegt durch die eigene Lektüre des Agenten des Gesprächs, nicht statistisch abgeleitet. Ehrlich darüber, was heute machbar ist und was nicht.

• Von Natur aus prüfbar. Jede Änderung am Speicher wird protokolliert, mit einem Grund in einfacher Sprache, den man zurücklesen kann (echo-memory why <fact_id>). Speicher, der sich selbst konsolidiert und bearbeitet, ist nur vertrauenswürdig, wenn man sehen kann, warum.

• Eine Speicher-Engine, jede Größenordnung. Postgres + pgvector + Apache AGE, von einem einzelnen lokalen Agenten bis zu einem organisationsweiten gemeinsamen Graphen, der jeden Agenten abdeckt, den ein Unternehmen betreibt. Keine erzwungene Migration später. (Die neuartige Arbeit ist die Speicherstruktur und der Algorithmus, die auf Postgres laufen, nicht eine neue Datenbank-Engine; siehe das Designdokument für das Warum.)

• Jeder Agent, nicht nur einer eines Anbieters. Die Schnittstelle ist MCP: jeder MCP-kompatible Agent kann denselben Speichergraphen lesen und schreiben, ob das nun ein Codierungsassistent, ein Chatbot, ein Ops-Agent oder etwas Eigenentwickeltes ist.

Related MCP server: smriti-memcore

Für wen das gedacht ist

• Ein Entwickler, der lokale Agenten betreibt, der möchte, dass Claude Code, Cursor oder etwas anderes aufhört, Kontext zwischen Sitzungen und Werkzeugen zu verlieren.

• Ein Team oder eine Organisation, die agentische Systeme in Produktion betreibt (Support-Bots, DevOps-Agenten, interne Werkzeuge), die eine gemeinsame Speicherebene benötigt statt N getrennter, mit dem Mandantenmodell (unten), um sie korrekt pro Agent, pro Team oder organisationsweit abzugrenzen.

Status

Früh und gestaffelt. Siehe docs/designs/ für die vollständige Architektur und den Build-Plan v1a → v1b. Der validierte Keil, der v1a antreibt, ist spezifisch das speicherübergreifende Codierungs-Agenten-Gedächtnis (der tägliche Schmerz des Gründers, real und getestet). Die breitere Vision oben ist das Ziel, auf das diese Architektur hinarbeitet, noch nicht etwas, das v1a selbst beweist. v1a beweist grundlegenden Abruf, bevor v1b kausale Typisierung und mehrstufigen Graphabruf hinzufügt, und bevor v1.1 die organisationsweite Mandantenfähigkeit hinzufügt, von der die breitere Vision abhängt.

Erste Schritte

Noch nicht zur Verwendung bereit; siehe docs/designs/echo-memory-design.md für den aktuellen Build-Plan und Fortschritt, und docs/DEVELOPMENT.md für die lokale Einrichtung, sobald Code existiert.

Architektur

• Speicher: PostgreSQL mit den Erweiterungen pgvector und Apache AGE

• Abruf: hybride Vektor- + Volltextsuche (v1a), mit Personalized PageRank über networkx in v1b für mehrstufigen assoziativen Abruf

• Schnittstelle: Model Context Protocol-Server: write_episode, query_memory, get_audit_log

Mitwirken

Siehe CONTRIBUTING.md. Issues und PRs willkommen; bitte zuerst die Designdokumente lesen, damit Vorschläge zum gestaffelten Build-Plan passen.

Lizenz

Apache License 2.0. Siehe LICENSE.