Hey zusammen, Alex hier von agntai.net. Es ist März 2026, und ich habe mit etwas zu kämpfen, das viele von euch, die mit KI-Agenten arbeiten, wahrscheinlich auch empfinden: die schiere Komplexität, diese Dinge tatsächlich zuverlässig in der Wildnis funktionieren zu lassen. Wir sind über die Phase der „coolen Demo“ für viele agentischen Systeme hinweg. Jetzt geht es um Stabilität, Vorhersehbarkeit und Debugging, wenn die Dinge unvermeidlich schiefgehen.
Konkret möchte ich über das Gedächtnis von Agenten sprechen. Nicht nur über den Vektorstore für RAG, den jeder und sein Hund implementieren, sondern über die nuancierteren, mehrschichtigen Gedächtnissysteme, die es einem Agenten ermöglichen, zu lernen, sich anzupassen und den Kontext über längere Zeiträume und verschiedene Aufgaben hinweg zu bewahren. Das ist es, was einen glorifizierten API-Wrapping von etwas trennt, das sich wirklich wie ein intelligenter Assistent anfühlt.
Als ich vor etwas mehr als einem Jahr begann, meinen „Projektmanager“-Agenten zu bauen, war mein Gedächtnissystem… primitiv. Eine einfache Liste von vergangenen Interaktionen, vielleicht eine schnelle Zusammenfassung, die an die Eingabeaufforderung für den nächsten Durchlauf angefügt war. Es funktionierte für kurze Gespräche, aber bei allem Komplexen, alles, was vom Agenten verlangte, eine Entscheidung von vor drei Tagen oder eine Präferenz aus einem ganz anderen Kontext abzurufen, fiel einfach auseinander. Es fühlte sich an, als würde ich mit jemandem sprechen, der unter schwerem Kurzzeitgedächtnisverlust leidet.
Über den Vektorstore hinaus: Die Notwendigkeit eines mehrschichtigen Gedächtnisses
Derzeit ist der Standardansatz, und ein guter Ausgangspunkt, eine Vektordatenbank zum Abrufen relevanter Informationsausschnitte. Man wirft die vergangenen Gespräche, Dokumente, Beobachtungen – was auch immer – des Agenten in Embeddings, und verwendet dann semantische Ähnlichkeit, um herauszufinden, was für die aktuelle Aufgabe nützlich sein könnte. Es ist effektiv für den Kontext, aber es ist nicht wirklich „Gedächtnis“ im menschlichen Sinne. Es ist mehr wie eine hocheffiziente Suchmaschine für frühere Erfahrungen.
Denke darüber nach, wie wir Dinge erinnern. Wir haben Kurzzeitgedächtnis (unseren Arbeitskontext), Langzeitgedächtnis (Fakten, Fähigkeiten, vergangene Ereignisse) und episodisches Gedächtnis (spezifische Erfahrungen, die an Zeit und Ort gebunden sind). Wir haben auch die Fähigkeit, aus Erfahrungen zu verallgemeinern, Gewohnheiten zu bilden und unsere Überzeugungen zu aktualisieren. Ein einfacher Vektorstore hat mit all dem zu kämpfen.
Mein „Projektmanager“-Agent, nennen wir sie „Orion“, musste mehr tun, als nur vergangene Nachrichten abzurufen. Sie musste:
- Meine spezifischen Vorlieben dafür, wie Aufgaben aufgeteilt werden.
- Die übergeordneten Projektziele im Blick behalten, selbst wenn über ein minutäres Detail gesprochen wird.
- Aus vergangenen Misserfolgen lernen – z.B., wenn eine bestimmte Aufgabenaufteilung konsequent zu Verzögerungen führte, sollte sie beim nächsten Mal Alternativen vorschlagen.
- Die Beziehungen zwischen verschiedenen Informationsstücken verstehen.
Das führte mich in einen Kaninchenbau, um eine ausgeklügeltere Gedächtnisarchitektur zu entwickeln. Hier ist, was ich als praktischen, wenn auch noch sich entwickelnden Ansatz entdeckt habe.
Ebene 1: Der flüchtige Kontext (Arbeitsgedächtnis)
Für Orion wäre das die aktuelle Aufgabe, die ich ihr gebe, etwaige sofortige Folgefragen und die letzten 3-5 Austausch, die wir hatten. Ich begrenze dies normalerweise auf eine Token-Anzahl, um Prompt-Stuffing zu verhindern.
Ebene 2: Das semantische Archiv (Langzeit-, deklaratives Gedächtnis)
Hier kommt dein Vektorstore ins Spiel. Es ist dein Repository aller vergangenen Interaktionen, Beobachtungen, generierten Gedanken und aller externen Dokumente, auf die der Agent Zugriff hat. Wenn der flüchtige Kontext nicht ausreicht, fragt Orion dieses Archiv ab, um relevante Informationen abzurufen.
Der Schlüssel hier ist, nicht einfach alles hineinzukippen. Es geht darum, wie du aufteilst und einbettet. Anstatt einfach nur rohe Gesprächsdurchgänge einzubetten, lasse ich Orion oft Zusammenfassungen oder wichtige Fakten/Entscheidungen aus Interaktionen extrahieren und diese dann einbetten. Das reduziert das Rauschen und verbessert die Relevanz der Abrufe.
def store_fact(agent_id, fact_text, fact_embedding, timestamp):
# Dies ist ein vereinfachtes Beispiel. In Wirklichkeit würdest du einen Vektor-Datenbank-Client verwenden.
db.insert_embedding(
collection_name=f"{agent_id}_facts",
text=fact_text,
embedding=fact_embedding,
metadata={"timestamp": timestamp}
)
def retrieve_relevant_facts(agent_id, query_embedding, k=5):
# Wiederum vereinfacht. Nutzt die Suchfunktion deiner Vektor-Datenbank.
results = db.query_embeddings(
collection_name=f"{agent_id}_facts",
query_embedding=query_embedding,
top_k=k
)
return [r.text for r in results]
# Beispielverwendung:
# user_query = "Was haben wir letzte Woche über das Marketingbudget entschieden?"
# query_embedding = get_embedding(user_query)
# relevante_fakten = retrieve_relevant_facts("Orion", query_embedding)
# print(relevante_fakten)
Ich fand es auch nützlich, Orion aktiv „reflektieren“ zu lassen über ihre vergangenen Handlungen oder eine Reihe von abgerufenen Fakten. Dies beinhaltet, das LLM mit einer Reihe von abgerufenen Erinnerungen aufzufordern und es zu bitten, neue, höherstufige Einsichten zu synthetisieren oder Muster zu verallgemeinern. Diese synthetisierten Einsichten werden dann ebenfalls im semantischen Archiv gespeichert, was einen Feedbackloop für das Lernen schafft.
Ebene 3: Der Wissensgraph (relationale Erinnerung)
Hier wird es wirklich interessant, und hier begann Orion, sich tatsächlich fähiger zu fühlen. Ein Wissensgraph ermöglicht es, die Beziehungen zwischen Entitäten zu speichern, nicht nur isolierte Fakten. Anstatt nur zu wissen, dass „Aufgabe A von Aufgabe B abhängig war“, kann ein Graph zeigen, dass „Aufgabe A Teil von Projekt X ist“, „Projekt X wird von Alex geleitet“ und „Aufgabe B beim letzten Mal wegen Ressource Y gescheitert ist“.
Ich verwende eine einfache Property-Graph-Datenbank (wie Neo4j oder sogar eine benutzerdefinierte SQLAlchemy-Konfiguration für kleinere Projekte), um Entitäten und deren Beziehungen zu speichern. Orion wird nach der Verarbeitung einer Interaktion oder dem Abruf von Fakten aufgefordert, Entitäten und Beziehungen zu extrahieren. Diese werden dann dem Graphen hinzugefügt.
Wenn ich zum Beispiel Orion sage: „Das neue Feature ‚Dunkelmodus‘ muss bis Ende nächsten Monats implementiert werden, und es hängt davon ab, dass das UI-Update zuerst abgeschlossen wird“, würde Orion:
- Entitäten identifizieren: „Dunkelmodus“ (Feature), „UI-Update“ (Aufgabe), „Ende nächsten Monats“ (Frist).
- Beziehungen identifizieren: „Dunkelmodus“ hat_frist „Ende nächsten Monats“, „Dunkelmodus“ hängt_ab „UI-Update“.
Später, wenn ich nach dem „Dunkelmodus“ frage, kann Orion den Graphen abfragen, um nicht nur die Frist zu erhalten, sondern auch sofort die Abhängigkeit zu sehen. Das ermöglicht informiertere Entscheidungen und proaktive Vorschläge.
# Vereinfachte Funktion zum Aktualisieren des Wissensgraphen
from py2neo import Graph, Node, Relationship
graph = Graph("bolt://localhost:7687", auth=("neo4j", "password"))
def update_knowledge_graph(agent_id, entities_relationships_json):
tx = graph.begin()
for item in entities_relationships_json:
if item["type"] == "entity":
node = Node(item["label"], name=item["name"])
tx.merge(node, item["label"], "name")
elif item["type"] == "relationship":
source = Node(item["source_label"], name=item["source_name"])
target = Node(item["target_label"], name=item["target_name"])
rel = Relationship(source, item["relationship_type"], target)
tx.merge(rel, item["relationship_type"])
tx.commit()
# Beispiel LLM-Ausgabe zum Parsen für die Graphaktualisierung:
# {
# "entities": [
# {"type": "entity", "label": "Feature", "name": "Dunkelmodus"},
# {"type": "entity", "label": "Task", "name": "UI-Update"}
# ],
# "relationships": [
# {"type": "relationship", "source_label": "Feature", "source_name": "Dunkelmodus",
# "relationship_type": "HÄNGT_AB", "target_label": "Task", "target_name": "UI-Update"}
# ]
# }
# update_knowledge_graph("Orion", parsed_llm_output)
Die Schönheit davon ist, dass der Abruf aus dem Graphen nicht nur semantisch ist; er ist strukturell. Du kannst nach „allen Aufgaben fragen, die vom UI-Update abhängen“ oder „allen Projekten, die von Alex geleitet werden.“ Das fügt der Argumentationsfähigkeit eines Agenten eine ganz neue Dimension hinzu.
Ebene 4: Das Glaubenssystem (adaptives Gedächtnis)
Das ist die schwierigste Ebene, und die, mit der ich weiterhin aktiv experimentiere. Es geht darum, dem Agenten zu erlauben, seine internen Modelle, Überzeugungen oder Vorlieben basierend auf Erfahrungen zu aktualisieren. Dabei geht es nicht nur darum, eine Tatsache abzurufen; es geht darum, sein Verhalten oder seinen Entscheidungsprozess zu ändern.
Für Orion bedeutet das Dinge wie:
- Wenn ich eine bestimmte Aufgabenaufteilungsstrategie wiederholt ablehne, sollte Orion lernen, sie nicht wieder vorzuschlagen oder sie zumindest mit Vorbehalten vorzuschlagen.
- Wenn ein bestimmtes Teammitglied konsequent Fristen verpasst, sollte Orion das in zukünftige Planungen oder Aufgabenverteilungen berücksichtigen.
- Wenn ich immer detaillierte Erklärungen über hochrangige Zusammenfassungen bevorzuge, sollte Orion ihren Kommunikationsstil anpassen.
Mein aktueller Ansatz hier umfasst eine Kombination aus zwei Dingen:
- Explizite Präferenzspeicherung: Ich habe eine dedizierte Tabelle (oder einen Abschnitt im Wissensgraphen) zur Speicherung expliziter Präferenzen oder „Regeln“, die Orion gelernt hat. Diese werden oft von Orion selbst durch Reflexion erzeugt (z. B. „Der Benutzer zieht detaillierte Aufgabenauflistungen vor“) oder ihm wird dies explizit mitgeteilt. Diese Präferenzen werden dann in den Prompt eingespeist, wenn sie relevant sind.
- Verstärkendes Lernen-light: Dies steht noch am Anfang, aber für bestimmte Entscheidungs- punkte (z. B. Wahl einer Aufgabenstrategiefür die Aufteilung) erkunde ich die Verwendung eines einfachen Feedbackmechanismus. Wenn ich einen Vorschlag akzeptiere, erhält er ein positives Signal. Wenn ich ihn ablehne, ein negatives. Dieses Signal aktualisiert nicht direkt ein neuronales Netzwerk, könnte aber einen „Vertrauenswert“ beeinflussen, der mit einer bestimmten Strategie verbunden ist, den Orion dann bei zukünftigen Vorschlägen berücksichtigt. Es geht weniger darum, eine Politik zu optimieren, und mehr darum, ihre internen „Heuristiken“ zu gewichten.
Diese Schicht dreht sich weniger um Abruf und mehr um proaktive Anpassung. Es ist der Unterschied zwischen einem Agenten, der ein Faktum kennt, und einem Agenten, der eine Lektion verinnerlicht hat.
Alles zusammenfügen: Ein Gedächtnisorchestrator
Diese Schichten zu haben, ist das eine; sie zum Zusammenarbeiten zu bringen, das andere. Ich habe festgestellt, dass man eine Komponente „Gedächtnisorchestrator“ benötigt, die entscheidet, welches Gedächtnissystem abgefragt werden soll und wann. Dies ist oft ein weiterer LLM-Aufruf, der als Router fungiert.
Wenn Orion einen neuen Input erhält:
- Der Orchestrator überprüft zuerst den Ephemeren Kontext. Ist die Antwort sofort verfügbar?
- Wenn nicht, wird eine Abfrage erstellt und das Semantische Archiv (Vektorstore) nach relevanten vergangenen Interaktionen oder Fakten durchsucht.
- Gleichzeitig, oder wenn der semantische Abruf nicht ausreicht, könnte eine Graphabfrage für den Wissensgraph erstellt werden, um relationale Informationen (Abhängigkeiten, Eigentum usw.) abzurufen.
- Schließlich, bevor eine Antwort generiert wird, konsultiert er das Glaubenssystem, um zu sehen, ob es erlernte Präferenzen oder Regeln gibt, die den Output beeinflussen sollten.
All diese abgerufenen Informationen werden dann zusammengestellt und an das Haupt-LLM weitergeleitet, um die endgültige Antwort oder Aktion zu generieren. Es ist eine Reihe von aufeinanderfolgenden Abrufen und Filtern, die einen umfassenden Kontext schafft.
Herausforderungen und zukünftige Richtungen
Der Aufbau dieses mehrschichtigen Gedächtnissystems war nicht ohne seine Kopfschmerzen:
- Kosten und Latenz: Jeder zusätzliche Abrufschritt erhöht die API-Kosten und die Latenz. Sie benötigen intelligentes Routing und Caching.
- Konsistenz: Es ist schwierig, Fakten über den Vektorstore, den Wissensgraphen und das Glaubenssystem konsistent zu halten. Manchmal lernt Orion in einer Schicht etwas, das mit einer anderen im Widerspruch steht.
- Debugging: Wenn Orion eine schlechte Entscheidung trifft, ist es ein Albtraum zurückzuverfolgen, welches Gedächtnis- komponent die irreführenden Informationen geliefert hat oder es versäumt hat, etwas Entscheidendes abzurufen.
- Schema-Evolution: Das Schema des Wissensgraphen ist nicht statisch. Wenn Orion über neue Arten von Entitäten oder Beziehungen lernt, muss ich die Graphstruktur und ihren Prompt für die Extraktion aktualisieren.
In die Zukunft blickend, bin ich wirklich daran interessiert, solidere Wege zu erkunden, wie der Agent sein Gedächtnis selbst organisieren kann. Kann Orion automatisch Lücken in ihrem Wissensgraph erkennen? Kann sie proaktiv Erinnerungen zusammenfassen und verdichten, ohne explizite Aufforderungen? Wie können wir das „Glaubenssystem“ besser mit der Kerndenk- schleife integrieren, ohne einfach mehr in den Prompt zu stopfen?
Handlungsfähige Erkenntnisse für Ihre Agenten
Wenn Sie einen KI-Agenten erstellen und an die Grenzen des einfachen Vektor-Abrufs stoßen, hier sind einige Vorschläge, die Sie in Betracht ziehen sollten:
- Einfach starten, dann erweitern: Versuchen Sie nicht, alle Schichten auf einmal zu erstellen. Lassen Sie zuerst Ihren ephemeren Kontext und einen grundlegenden Vektorstore funktionieren.
- Über „Was“ und „Wie“ nachdenken:
- Was für eine Art von Informationen muss erinnert werden? (Fakten, Beziehungen, Präferenzen, vergangene Aktionen, Pläne?)
- Wie sollten diese Informationen abgerufen und verwendet werden? (Semantische Suche, Graphdurchlauf, direkte Abfrage, Regelanwendung?)
- Reflexion annehmen: Fordern Sie Ihren Agenten regelmäßig auf, über seine vergangenen Aktionen nachzudenken, Einblicke zu synthetisieren und seine Gedächtnis- speicher zu aktualisieren. Dies ist entscheidend für das Lernen.
- Denken Sie an einen Wissensgraph für relationale Daten: Wenn Ihr Agent Abhängigkeiten, Hierarchien oder komplexe Beziehungen verstehen muss, ist eine Graph-Datenbank unglaublich leistungsfähig.
- Mit adaptiven Komponenten experimentieren: Für Präferenzen oder erlernte Verhaltensweisen erkunden Sie einfache Präferenzspeicher oder gewichtete Heuristiken, bevor Sie in das vollständige verstärkende Lernen einsteigen.
- Ein Gedächtnisorchestrator aufbauen: Dumpen Sie nicht einfach alles Gedächtnis in den Prompt. Entwerfen Sie eine Komponente, die intelligente Abfragen an verschiedene Gedächtnisschichten basierend auf dem aktuellen Kontext und der Aufgabe stellt.
- Iterieren und Debuggen: Gedächtnissysteme sind komplex. Erwarten Sie, viel Zeit mit dem Testen, Debuggen und Verfeinern zu verbringen, wie Ihr Agent Informationen speichert und abruft.
Der Weg zu wirklich intelligenten Agenten ist lang, aber der Aufbau komplexer, mehrschichtiger Gedächtnissysteme ist ein wichtiger Schritt. Es bringt uns über reaktive Chatbots hinaus zu Agenten, die wirklich lernen, sich anpassen und mit einem tieferen Verständnis ihrer Welt agieren können. Ich würde mich freuen, von Ihren Erfahrungen und Ansätzen zur Agentenspeicherung zu hören – hinterlassen Sie einen Kommentar unten!
🕒 Published: