Agentenspeicher benötigen einen gemeinsamen Standard wie OpenTelemetry

Das Ökosystem für den Speicher von KI-Agenten ist derzeit fragmentiert, wobei jedes Tool seine eigene Datenstruktur und Speichermechanik verwendet. Mads Thines argumentiert, dass diese Landschaft den chaotischen Zustand der Software-Observability vor 2019 widerspiegelt und ein einheitlicher Standard erforderlich ist, damit verschiedene Agenten Kontext effektiv teilen können.

Was passiert ist

Die meisten Entwicklungsumgebungen verlassen sich heute auf mehrere disjointe Systeme, um Informationen über Sitzungen hinweg zu behalten. Eine typische Konfiguration könnte Instruktionsdateien wie AGENTS.md oder CLAUDE.md, agentenverwaltete Verzeichnisse wie /memories, gehostete Fakten aus Diensten wie GitHub Copilot sowie separate Wissensgraphen umfassen, die von Model Context Protocol (MCP)-Servern gepflegt werden. Diese vier gängigen Ansätze können die Daten des jeweils anderen nicht lesen, was bedeutet, dass Erkenntnisse eines Continuous-Integration-Agenten für einen Editor-Agenten oder nachfolgende Tools unsichtbar bleiben.

Diese Fragmentierung hat zu einem Anstieg individueller Lösungen geführt, bei denen Entwickler häufig ihre eigenen Speicherschichten erstellen, um spezifische Lücken zu schließen. Während jedes einzelne Format logisch schlüssig ist, führt das kollektive Ergebnis zu einer redundanten Rekonstruktion grundlegender Konzepte: einer Notiz an einer Adresse, gültig für einen bestimmten Zeitraum. Das Kernproblem ist nicht ein Mangel an Tools, sondern ein Mangel an gemeinsamer Übereinkunft der Community über ein geteiltes Datenmodell – ein Problem, das der Observability-Sektor durch die Schaffung von OpenTelemetry erfolgreich gelöst hat.

Wie es funktioniert

Vor 2019 konkurrierten Anbieter von Observability-Lösungen, indem sie proprietäre Agents, Instrumentierungsbibliotheken und Datenformate erstellten, was es Nutzern erschwerte, den Anbieter zu wechseln. Die Industrie löste dieses Problem durch die Zusammenführung von OpenTracing und OpenCensus zu OpenTelemetry, das vier kritische Ebenen der Übereinkunft etablierte. Dazu gehörten ein einheitliches Datenmodell für Spans und Metriken, semantische Konventionen für die Benennung, ein einzelnes Transportprotokoll namens OTLP sowie Referenzimplementierungen wie gemeinsame SDKs. Anbieter konkurrierten anschließend bei Speicherung und Analyse statt bei der Datenerfassung, sodass Nutzer ihren Code nur einmal instrumentieren mussten.

Dem Agentenspeicher fehlt derzeit diese grundlegende Übereinkunft. Eine vorgeschlagene gemeinsame Spezifikation würde den Ansatz von OpenTelemetry nachahmen, indem sie standardisierte Adressstufen wie global, Projekt oder Repository definiert und semantische Konventionen für Attribute festlegt. Sie würde auch einen Vertrag für Basisoperationen wie Schreiben, Lesen und Suchen definieren, der über MCP bereitgestellt wird, während Entscheidungen über Speicherung, Ranking und Benutzeroberfläche den einzelnen Anbietern überlassen bleiben. Diese Trennung ermöglicht es Tools, auf Datenebene zu interoperieren, während sie bei Mehrwertfunktionen konkurrieren.

Wichtige Details

• Aktuelle Speicherformate umfassen Instruktionsdateien, agentenverwaltete Dateien, gehostete Repository-Fakten, Kontextblöcke, extrahierte Fakten, namensraum-basierte Stores und Wissensgraphen, von denen keiner gegenseitig lesbar ist.
• OpenTelemetry war erfolgreich, weil man sich auf ein Datenmodell, semantische Konventionen, ein Protokoll und Referenzimplementierungen einigte, wodurch Anbieter bei der Datennutzung statt bei der Erfassung konkurrieren konnten.
• Bestehende Vorschläge wie Portable Memory, Open Memory Protocol und COGX konzentrieren sich primär auf den Export von Daten zwischen Anbietern, statt auf Live-, gleichzeitige Adressierung zu ermöglichen.
• Eine vorgeschlagene Struktur für Speicherdatensätze umfasst Felder für Identität, Adresse, Schlüssel, Inhaltstyp, Lebenszyklus und Attribute, wobei der eigentliche Speicherinhalt separat abgelegt wird.
• Die Spezifikation sollte erfassen, wer die Erinnerung geschrieben hat, z. B. ein Mensch oder ein Agent, um Lesern die Bewertung der Vertrauenswürdigkeit zu erleichtern und Risiken durch Prompt-Injection zu mindern.
• LoreKit stellt sein Schema und das On-Disk-Format unter MIT-Lizenz als konkreten Input für die Entwicklung eines gemeinsamen Standards zur Verfügung.

Warum das wichtig ist

Für Ingenieure, die agentic Workflows entwickeln, bedeutet der aktuelle Mangel an Standardisierung, dass Kontext in spezifischen Tools oder bei bestimmten Anbietern isoliert bleibt. Dies verhindert eine effektive Zusammenarbeit der Agenten, da eine von einer Komponente gelernte Lektion von einer anderen nicht genutzt werden kann, ohne manuelle Eingriffe oder komplexe individuelle Integrationen. Mit der wachsenden Zahl an Agent-Tools steigen die Kosten für die Wartung dieser disjointen Speichersysteme, was zu redundanter Entwicklungsarbeit und inkonsistenten Nutzererlebnissen führt.

Die Einführung eines gemeinsamen Standards würde Entwicklern ermöglichen, ihre Agenten nur einmal zu instrumentieren und sie nahtlos über verschiedene Plattformen und Tools hinweg arbeiten zu lassen. Es würde ein lebhaftes Ökosystem ermöglichen, in dem Anbieter bei fortgeschrittenen Funktionen wie besseren Retrieval-Algorithmen oder Benutzeroberflächen konkurrieren, statt Nutzer in proprietären Datenformaten zu binden. Dieser Wandel würde Vendor Lock-in reduzieren und es Teams erleichtern, neue Tools zu übernehmen, ohne historischen Kontext zu verlieren oder ihre Speicherinfrastruktur neu konstruieren zu müssen.

Was Sie tun können

• Überprüfen Sie Ihre aktuelle Entwicklungsumgebung, um alle Orte zu identifizieren, an denen Agentenspeicher abgelegt wird, und notieren Sie die Inkompatibilitäten zwischen ihnen.
• Prüfen Sie bestehende Vorschläge wie Portable Memory, Open Memory Protocol und COGX, um deren Ansätze für Datenexport und Serialisierung zu verstehen.
• Experimentieren Sie mit dem Offline-Store von LoreKit, indem Sie npx @lorekit/cli install ausführen, um zu untersuchen, wie einfache Markdown-Dateien strukturierte Speicherdatensätze repräsentieren können.
• Vergleichen Sie die von Ihren aktuellen Tools generierten Speicherdatensätze mit der vorgeschlagenen Struktur, um fehlende Felder oder notwendige Attribute für Ihren Anwendungsfall zu identifizieren.
• Binden Sie sich in die Community ein, indem Sie Feedback dazu geben, welche Anforderungen ein gemeinsames Format für Ihren spezifischen Workflow erfüllen muss, mit Fokus auf Live-Adressierung und Vertrauensmechanismen.
• Erwägen Sie, sich an Diskussionen auf neutraler Ebene zu beteiligen, wie etwa bei der Agentic AI Foundation der Linux Foundation, um die entstehenden Standards mitzugestalten.