KI-Agenten 04
Architektonische Persistenz: Effizientes Management von Kurz- und Langzeitgedächtnis in langlebigen agentischen Systemen

Michael Schöffel
19. Februar 202620 Min. Lesezeit
Inhalt
- 1. Zusammenfassung
- 2. Einleitung
- 3. Die Materie des Erinnerns: Funktionale Differenzierung von STM und LTM
- 4. Die physische Speicherhierarchie und der GPU-Engpass
- 5. Kontext-Management im STM: Strategien gegen den Informationsverlust
- 6. Virtual Context Management: Das Betriebssystem-Paradigma
- 7. Langzeitgedächtnis (LTM): Strukturierte Persistenz-Architekturen
- 8. Zeitliche Intelligenz: Bi-temporale Graphen und Zustandsversionierung
- 9. Die Mathematik des Vergessens und Erinnerns: Scoring und Retrieval-Logik
- 10. Quantifizierung der Erinnerung: Benchmarking agentischer Gedächtnissysteme
- 11. Forschung und neue Horizonte: E-mem und Episodic Context Reconstruction
- 12. Praxisbeispiel: Das HMLR-System (Hierarchical Memory Lookup & Routing)
- 13. Die dunkle Seite der Persistenz: Datenschutz und das „Recht auf Vergessen"
- 14. Die kuratierte Memetik: Human-in-the-Loop im Gedächtnismanagement
- 15. Fallstudien: XBOW, PentestGPT und CAI in der Anwendung
- 16. Die Ökonomie des Erinnerns: Kosten-Nutzen-Analyse der Hintergrund-Kuration
- 17. Fazit: Die strategische Bedeutung der Gedächtnisarchitektur
- Weitere Beiträge
1. Zusammenfassung
Langlebige KI-Agenten erfordern eine durchdachte Gedächtnisarchitektur, die weit über das einfache Speichern von Konversationshistorien hinausgeht. Das Kurzzeitgedächtnis (STM) wird durch das physische Kontextfenster des LLMs und den KV-Cache auf der GPU realisiert - eine schnelle, aber begrenzte und flüchtige Ressource. Das Langzeitgedächtnis (LTM) gliedert sich in episodisches, semantisches und prozedurales Gedächtnis, das in externen Vektorenbanken und Graphdatenbanken persistiert wird. Selbst mit Kontextfenstern von mehreren Millionen Token bleibt ein dediziertes Gedächtnismanagement notwendig, da steigende Token-Mengen die Instruction-Following-Qualität senken und Kosten linear erhöhen.
Die physische Speicherhierarchie moderner KI-Infrastruktur reicht von GPU-HBM (G1) über CPU-RAM (G2) bis hin zu Flash-basierten ICMS-Schichten (G3.5) und disaggregierten Netzwerkspeichern (G4). Im STM-Management dominieren drei Strategien: Sliding Window mit Truncation für einfache Szenarien, Recursive Summarization für die hierarchische Verdichtung langer Verläufe sowie das Virtual Context Management nach dem MemGPT-Paradigma, bei dem das LLM seinen eigenen Kontext über Paging-, Eviction- und Interrupt-Mechanismen wie ein Betriebssystem-Kernel selbst verwaltet.
Für das LTM stehen Vektordatenbanken (Pinecone, FAISS) für semantische Ähnlichkeitssuchen und Wissensgraphen (Neo4j, Neptune) für strukturelles Multi-Hop-Reasoning zur Verfügung. Wissensgraphen ermöglichen Abfragen wie "alle Server im selben Subnetz wie ein kompromittiertes System", die mit reinen Vektoren nicht lösbar sind. Bi-temporale Datenbankmodelle (Graphiti) verfolgen sowohl Gültigkeitszeit als auch Transaktionszeit jeder Information, sodass Point-in-Time-Abfragen und die Erkennung veralteter Fakten möglich sind. Ein Truth Maintenance System (TMS) invalidiert kaskadierend alle abhängigen Schlussfolgerungen, sobald ein Grundfakt widerlegt wird.
Die Priorisierung von Erinnerungen erfolgt über eine RFM-Formel, die Recency (exponentieller Verfall), Frequency (Abrufhäufigkeit) und Importance (vergebener Wichtigkeitsscore) kombiniert. Das "Lost-in-the-Middle"-Phänomen zeigt, dass LLMs Informationen in der Mitte langer Kontexte ignorieren - kritische Fakten müssen daher an den Rändern des Prompts platziert werden. Konkrete Systeme wie XBOW nutzen einen persistenten Koordinator mit zentralem Wissensgraph und kurzlebige Solver-Agenten, die nur minimale Kontext-Snapshots erhalten. PentestGPT strukturiert das gesamte Gedächtnis als Pentesting Task Tree (PTT). GitHub Copilot validiert Erinnerungen gegen die aktuelle Codebasis und verwirft veraltete Citations automatisch.
Neuere Forschungsansätze wie E-mem vermeiden die destruktive De-Kontextualisierung klassischer RAG-Systeme durch unkomprimierte Episodensegmente und spezialisierte Assistant-Agenten, die lokale Beweise aus vollständigen Kontexten ableiten - bei gleichzeitiger Reduktion der Token-Kosten um über 70 %. Das HMLR-System kombiniert kurzfristige Bridge Blocks mit einem Gardener-Prozess, der wichtige Fakten in persistente Dossiers überführt, sowie einem Governor-Agenten und Context Hydrator zur laufzeitoptimierten Prompt-Zusammenstellung. Aus regulatorischer Perspektive erfordern langlebige Gedächtnissysteme TTL-basierte Ablaufkontrolle, Ownership-Tags und Cross-Context-Isolation, um DSGVO-Konformität und mandantenübergreifende Datentrennung sicherzustellen. Human-in-the-Loop-Schnittstellen mit Memory Editing, Pinning und Audit-Logs ermöglichen schließlich die nachvollziehbare Korrektur von Fehlentscheidungen - eine Voraussetzung für Explainable Memory in produktiven agentischen Systemen.

2. Einleitung
Die Transformation der künstlichen Intelligenz von zustandslosen Sprachmodellen hin zu autonomen, langlebigen Agenten stellt eine der bedeutendsten Herausforderungen der gegenwärtigen Informatik dar. Während frühe Implementierungen von Sprachmodellen (LLMs) primär als transiente Inferenzmaschinen fungierten, die jede Anfrage isoliert betrachteten, verlangen moderne agentische Systeme wie XBOW, PentestGPT oder CAI nach einer Form der Kontinuität, die über einzelne Sitzungen hinausgeht [1]. Das Gedächtnis eines Agenten ist dabei weit mehr als ein einfacher Datenspeicher; es ist das strukturelle Fundament für logische Schlussfolgerungen (Reasoning), strategische Planung und die Fähigkeit, aus vergangenen Interaktionen zu lernen [2]. Ein Agent ohne effektives Gedächtnismanagement ist in einer produktiven Unternehmensumgebung nicht überlebensfähig, da Sitzungs-basierte Kontexte unweigerlich zu repetitiven Fehlern, inkonsistenten Ausgaben und einer Unfähigkeit führen, komplexe, mehrstufige Arbeitsabläufe intelligent zu steuern [3].
Diese vierte Analyse innerhalb der Serie über langlebige KI-Agenten konzentriert sich auf die technologische Realisierung von Gedächtnisarchitekturen. Aufbauend auf den zuvor diskutierten kognitiven Archetypen und dem architektonischen Spektrum agentischer Systeme wird hier untersucht, wie die physischen Beschränkungen von Kontextfenstern durch innovative Konzepte aus der Betriebssystemtheorie und der Graphenforschung überwunden werden können.
Mit dem Aufkommen von Modellen wie Gemini 1.5 Pro, die Kontextfenster von bis zu 2 Millionen Token unterstützen, stellt sich die radikale Frage: Ist ein komplexes Management von LTM und STM überhaupt noch notwendig? Die Antwort ist ein klares Ja, begründet durch die Token-Ökonomie und die Reasoning-Dichte [4].
Zwar kann ein Modell theoretisch ganze Bibliotheken im Kontext halten, doch mit zunehmender Füllung sinkt die präzise Befolgung von Instruktionen (Instruction Following) [5]. Zudem steigen die Kosten und die Latenz linear mit der Kontextlänge. Eine dedizierte Gedächtnisarchitektur fungiert hier als "kognitiver Filter". Anstatt das Modell mit rohen Daten zu fluten, liefert das LTM nur die destillierte Essenz. Wir bewegen uns weg von "Brute-Force-Kontext" hin zu einer Hierarchical Contextualization, bei der das riesige Fenster nur als temporärer Cache genutzt wird, während die dauerhafte Weisheit in strukturierten Graphen und Vektoren residiert.
Es geht also konkret um die Überwindung des "Context Amnesia"-Problems, bei dem Agenten trotz riesiger Token-Limits den Überblick über die kausalen Zusammenhänge ihrer Handlungen verlieren [1]. Die hier betrachteten Systeme müssen in der Lage sein, Informationen über Tage, Wochen oder Monate hinweg nicht nur zu speichern, sondern sie in einer Weise zu organisieren, die einen präzisen und kosteneffizienten Wiederabruf ermöglicht [6].
3. Die Materie des Erinnerns: Funktionale Differenzierung von STM und LTM
In der Architektur agentischer Systeme wird die Unterscheidung zwischen Kurzzeitgedächtnis (Short-Term Memory, STM) und Langzeitgedächtnis (Long-Term Memory, LTM) oft durch die Analogie zum menschlichen Gehirn oder klassischen Computerarchitekturen beschrieben. Diese Trennung ist nicht nur begrifflicher Natur, sondern definiert die Art der Datenverarbeitung und die Wahl der Speichertechnologien [3]. Während das STM für die unmittelbare Handlungssteuerung zuständig ist, dient das LTM als persistentes Archiv des Wissens und der Erfahrung [3].
3.1 Kurzzeitgedächtnis (STM) und Working Memory
Das Kurzzeitgedächtnis eines Agenten entspricht funktional dem Arbeitsspeicher (RAM) eines Computers. Es umfasst alle Informationen, die während einer aktiven Reasoning-Schleife unmittelbar für das Modell zugänglich sind. Technisch wird dies durch das Kontextfenster des LLMs realisiert, wobei die Daten im Key-Value (KV) Cache des Grafikprozessors (GPU) vorgehalten werden [6]. Dieses "Working Memory" ist extrem schnell, aber auch extrem teuer und in seiner Kapazität physikalisch begrenzt [6]. Ein wesentliches Merkmal des STM ist seine Flüchtigkeit: Sobald eine Inferenz abgeschlossen ist oder das Kontextlimit überschritten wird, gehen Informationen verloren, wenn sie nicht explizit in das LTM überführt werden [7]. In langlebigen Systemen muss das STM daher als dynamischer Puffer verwaltet werden, der nur die für den aktuellen Schritt relevanten Instruktionen, Beobachtungen und Gedanken enthält [3].
3.2 Langzeitgedächtnis (LTM): Episodisch, Semantisch und Prozedural
Das Langzeitgedächtnis hingegen ist die Instanz der Persistenz. Es ermöglicht Agenten, Informationen über verschiedene Sitzungen und Aufgaben hinweg zu bewahren [3]. Die Forschung unterscheidet hierbei drei wesentliche Typen:
| Gedächtnistyp | Beschreibung | Beispiel in agentischen Systemen |
|---|---|---|
| Episodisches Gedächtnis | Speichert spezifische Ereignisse, Interaktionen und den Verlauf vergangener Aktionen. | Aufzeichnung eines spezifischen Pentesting-Scans am Vortag [3]. |
| Semantisches Gedächtnis | Beinhaltet generalisiertes Wissen, Fakten und stabile Regeln über die Welt oder eine Domäne. | Wissen über die Funktionsweise des HTTP-Protokolls oder Unternehmensrichtlinien [8]. |
| Prozedurales Gedächtnis | Kodiert "How-to"-Wissen, Arbeitsabläufe und bewährte Strategien (Skills). | Skripte für Standard-Exploits oder Workflow-Muster in LangChain [8]. |
Das LTM wird typischerweise durch externe Datenbanken realisiert, wobei Vektordatenbanken für semantische Ähnlichkeitssuchen und Graphdatenbanken für strukturelle Relationen dominieren [9]. Ein langlebiger Agent muss in der Lage sein, kontinuierlich Informationen vom STM ins LTM zu "evektieren" und relevante Erinnerungen bei Bedarf zurück in das STM zu "pagen" [10].
1# Beispiel: Strukturierung der drei LTM-Typen in einer einfachen
2# Python-Datenstruktur, wie sie ein Agent intern nutzen könnte.
3import time
4from dataclasses import dataclass, field
5from typing import Literal
6
7MemoryType = Literal["episodic", "semantic", "procedural"]
8
9@dataclass
10class MemoryEntry:
11 content: str
12 memory_type: MemoryType
13 timestamp: float = field(default_factory=time.time)
14 importance: float = 1.0 # normiert 0.0 - 1.0
15
16class LongTermMemory:
17 def __init__(self):
18 self._store: list[MemoryEntry] = []
19
20 def store(self, content: str, memory_type: MemoryType, importance: float = 1.0):
21 entry = MemoryEntry(content=content, memory_type=memory_type, importance=importance)
22 self._store.append(entry)
23 print(f"[LTM] Gespeichert ({memory_type}): {content!r}")
24
25 def retrieve_by_type(self, memory_type: MemoryType) -> list[MemoryEntry]:
26 return [e for e in self._store if e.memory_type == memory_type]
27
28# --- Nutzung ---
29ltm = LongTermMemory()
30
31# Episodisch: spezifische Ereignisse
32ltm.store("Nmap-Scan auf 10.0.1.5 ergab Port 80 offen (2026-02-18 09:00)", "episodic", importance=0.9)
33
34# Semantisch: allgemeines Domänenwissen
35ltm.store("HTTP nutzt standardmäßig Port 80; HTTPS Port 443", "semantic", importance=0.7)
36
37# Prozedural: bewährte Workflows / Skills
38ltm.store("Standard-Recon-Workflow: nmap -sV -> gobuster -> nikto", "procedural", importance=0.8)
39
40print("\nEpisodische Erinnerungen:", ltm.retrieve_by_type("episodic"))4. Die physische Speicherhierarchie und der GPU-Engpass
Der Übergang zu agentischer KI verschiebt den Flaschenhals moderner Infrastruktur von der reinen Rechenleistung (Compute) hin zur Speicherkapazität und Bandbreite [6]. Da agentische Workflows oft Millionen von Token über viele Interaktionsschritte hinweg akkumulieren, brechen herkömmliche Speicherhierarchien zusammen. Der KV-Cache, der die Aufmerksamkeit (Attention) zwischen Token speichert, wächst linear mit der Sequenzlänge und belegt wertvollen Platz im High-Bandwidth Memory (HBM) der GPUs [6].
Um diesen Engpass zu adressieren, entstehen neue Speicherklassen und Architekturen:
- G1 bis G4 Tiers: Die Hierarchie reicht vom ultraschnellen HBM (G1) über CPU-RAM (G2) bis hin zu lokalen SSDs (G3) und Netzwerkspeicher (G4) [6].
- Inference Context Memory Storage (ICMS): Eine neue "G3.5"-Schicht, die von Herstellern wie NVIDIA vorgeschlagen wird. Dabei handelt es sich um Ethernet-gebundenen Flash-Speicher, der speziell für das Streaming von KV-Caches optimiert ist [6].
- Disaggregierter Speicher: Anstatt Speicher fest an einzelne GPUs zu binden, werden Speicherpools über Hochgeschwindigkeits-Interconnects wie CXL (Compute Express Link) geteilt [6]. Dies verhindert Redundanz und ermöglicht es einem Agenten, Kontextdaten schnell zwischen verschiedenen Rechenknoten zu verschieben.
Diese technologische Basis ist entscheidend für Systeme wie XBOW, die tausende fokussierte Agenten parallel betreiben, wobei ein zentraler Koordinator den globalen Kontext verwaltet und spezifische Wissensfragmente an kurzlebige "Solver" verteilt [11].
5. Kontext-Management im STM: Strategien gegen den Informationsverlust
Das Kontextfenster eines LLM ist vergleichbar mit den Dokumenten, die auf einem Schreibtisch liegen: Man kann nur das bearbeiten, was im direkten Sichtfeld ist [12]. Sobald der Schreibtisch voll ist, müssen alte Dokumente weggeräumt oder zusammengefasst werden. In der Praxis der agentischen Systeme haben sich drei primäre Muster für dieses Management etabliert.
5.1 Sliding Window und Truncation
Die einfachste Methode ist das gleitende Fenster. Hierbei werden die ältesten Token automatisch gelöscht, sobald das Limit erreicht ist [17]. Während dies technisch trivial ist, führt es bei langlebigen Aufgaben oft zum katastrophalen Verlust von Systeminstruktionen oder initialen Zielen. Eine verfeinerte Version ist das "Observation Masking", bei dem unwichtige Details durch Platzhalter ersetzt werden, um die strukturelle Integrität der Interaktionshistorie zu wahren, während Token gespart werden [13]. Studien zeigen, dass dieses Maskieren oft effizienter und kostengünstiger ist als komplexe Zusammenfassungen, da es die Präzision bei long-horizon Aufgaben erhöht [13].
1# Beispiel: Sliding-Window-Kontext mit festem Token-Budget
2# Die Systeminstruktion wird immer geschützt; älteste Nachrichten
3# fallen zuerst weg, wenn das Limit überschritten wird.
4
5def estimate_tokens(text: str) -> int:
6 """Grobe Schätzung: ~4 Zeichen ≈ 1 Token (GPT-Faustregel)."""
7 return max(1, len(text) // 4)
8
9def sliding_window_context(
10 system_prompt: str,
11 history: list[dict],
12 max_tokens: int = 4096,
13) -> list[dict]:
14 """
15 Gibt ein gekürztes Kontextfenster zurück.
16 - system_prompt ist immer geschützt.
17 - Älteste Nachrichten werden entfernt, bis das Budget passt.
18 """
19 system_tokens = estimate_tokens(system_prompt)
20 budget = max_tokens - system_tokens
21
22 # Von hinten (neueste zuerst) aufbauen
23 trimmed: list[dict] = []
24 used = 0
25 for msg in reversed(history):
26 tokens = estimate_tokens(msg["content"])
27 if used + tokens > budget:
28 break # Budget erschöpft - ältere Nachrichten rauslassen
29 trimmed.insert(0, msg)
30 used += tokens
31
32 return [{"role": "system", "content": system_prompt}] + trimmed
33
34# --- Demo ---
35system = "Du bist ein Pentest-Agent. Ziel: 10.0.1.0/24 analysieren."
36msgs = [
37 {"role": "user", "content": "Starte einen Nmap-Scan."},
38 {"role": "assistant", "content": "Nmap läuft... Port 80 offen auf 10.0.1.5."},
39 {"role": "user", "content": "Prüfe auf bekannte CVEs für Apache."},
40 {"role": "assistant", "content": "CVE-2024-XXXX gefunden. Exploit verfügbar."},
41 {"role": "user", "content": "Führe den Exploit aus."},
42]
43
44context = sliding_window_context(system, msgs, max_tokens=100)
45for m in context:
46 print(f"[{m['role']}] {m['content'][:60]}")5.2 Recursive Summarization und Semantic Compression
Bei der rekursiven Zusammenfassung (Recursive Summarization) wird ein Teil des Kontexts durch ein Modell verdichtet, sobald ein Schwellenwert (z.B. 75%) erreicht ist [14]. Dieser Prozess erzeugt eine hierarchische Struktur von Zusammenfassungen:
- Level 0: Rohe Interaktion (z.B. 10.000 Token).
- Level 1: Zusammenfassungen von Blöcken à 2.000 Token.
- Level 2: Zusammenfassung der Level-1-Zusammenfassungen [15].
1# Beispiel: Rekursive Zusammenfassung (Recursive Summarization)
2# Simuliert den zweistufigen Verdichtungsprozess ohne echten LLM-Aufruf.
3
4def summarize(text: str) -> str:
5 """
6 Platzhalter für einen echten LLM-Aufruf, z. B.:
7 response = openai.chat.completions.create(
8 model="gpt-4o-mini",
9 messages=[{"role": "user", "content": f"Fasse zusammen:\n{text}"}]
10 )
11 return response.choices[0].message.content
12 """
13 # Vereinfachte Demo: kürzt auf die ersten 80 Zeichen
14 return text[:80] + "…" if len(text) > 80 else text
15
16def recursive_summarize(
17 tokens: list[str],
18 block_size: int = 3,
19 threshold: float = 0.75,
20) -> str:
21 # Level 1: Blockweise zusammenfassen
22 level1 = []
23 for i in range(0, len(tokens), block_size):
24 block = " ".join(tokens[i : i + block_size])
25 level1.append(summarize(block))
26 print(f" [L1-Block {i // block_size + 1}] {level1[-1]}")
27
28 # Level 2: Alle L1-Zusammenfassungen zu einer Meta-Zusammenfassung
29 meta = summarize(" | ".join(level1))
30 print(f"\n [L2-Meta] {meta}")
31 return meta
32
33# --- Demo ---
34raw_chunks = [
35 "Nmap-Scan gestartet. Ziel: 10.0.1.0/24.",
36 "Port 80 auf 10.0.1.5 offen. Apache 2.4 erkannt.",
37 "CVE-2024-XXXX betrifft Apache 2.4.50. CVSS 9.8.",
38 "Exploit-Modul geladen. Payload: reverse_shell.",
39 "Shell auf 10.0.1.5 erhalten. User: www-data.",
40 "Privilege-Escalation-Versuch via sudo -l gestartet.",
41]
42
43print("=== Recursive Summarization ===")
44result = recursive_summarize(raw_chunks, block_size=2)Die "Recursive Semantic Compression" (RSC) geht einen Schritt weiter, indem sie versucht, die Bedeutung (Intent) zu bewahren, anstatt nur Wörter zu kürzen [16]. Dies ist besonders wertvoll für Programmier-Agenten wie Claude Code oder GitHub Copilot, die zwar keine exakte Rekonstruktion jedes Zeichens benötigen, aber die funktionale Logik eines Code-Moduls verstehen müssen [17]. Ein wesentlicher Nachteil ist jedoch der "Context Rot" - durch wiederholte Zusammenfassungen können feine Nuancen verloren gehen, was zu Halluzinationen führen kann [14].
6. Virtual Context Management: Das Betriebssystem-Paradigma
Eines der einflussreichsten Konzepte für agentische Gedächtnisarchitekturen ist das "Virtual Context Management", das prominent durch MemGPT (jetzt Letta) eingeführt wurde [10]. Die Kernidee besteht darin, das LLM so zu programmieren, dass es seinen eigenen Kontext aktiv verwaltet, analog zu einem Betriebssystem-Kernel, der RAM und Disk verwaltet [10].
6.1 Paging, Swapping und Interrupts
MemGPT unterteilt den Speicher in verschiedene logische Bereiche innerhalb des physischen Kontextfensters:
- System Instructions: Festgelegte Regeln, die niemals gelöscht werden.
- Working Context: Ein beschreibbarer Bereich für aktuelle Fakten über den Benutzer oder die Aufgabe.
- FIFO Queue: Ein Puffer für die laufende Konversationshistorie [10].
Wenn der Platz in der FIFO-Queue knapp wird, sendet das System ein "Memory Pressure"-Signal an den Agenten [10]. Der Agent kann dann entscheiden, wichtige Informationen mittels Funktionsaufrufen (edit_memory, archive_memory) in den Working Context oder in ein externes Langzeitarchiv (Archival Storage) zu verschieben [10]. Informationen, die nicht mehr aktiv im Fenster sind, aber später benötigt werden könnten, werden in einem "Recall Storage" gespeichert [10].
Dieses Paradigma ermöglicht "unbegrenzte" Kontexte: Der Agent "sieht" zwar nur einen Bruchteil seiner gesamten Historie, hat aber die Werkzeuge, um gezielt in seiner eigenen Vergangenheit zu suchen (Paging In) oder unnötigen Ballast abzuwerfen (Swapping Out) [10]. Dies wird durch einen Feedback-Loop unterstützt, in dem das System den Agenten durch Interrupts warnt, wenn Kapazitätsgrenzen erreicht werden, wodurch der Agent zum Kurator seines eigenen Gedächtnisses wird [10].
1# Beispiel: Minimale MemGPT-ähnliche Speicherverwaltung
2# Zeigt die Kernoperationen edit_memory, archive_memory und recall.
3
4from collections import deque
5
6CONTEXT_TOKEN_LIMIT = 500
7
8class MemGPTAgent:
9 """Vereinfachte Nachbildung des MemGPT-Speichermodells."""
10
11 def __init__(self):
12 self.system_instructions = "Du bist ein Pentest-Agent. Ziel: 10.0.1.0/24."
13 self.working_context: dict[str, str] = {} # beschreibbarer KV-Bereich
14 self.fifo_queue: deque[str] = deque() # laufende Konversation
15 self.archival_storage: list[str] = [] # Langzeitarchiv
16 self.recall_storage: list[str] = [] # Wiederabruf-Puffer
17
18 def _token_estimate(self) -> int:
19 all_text = self.system_instructions
20 all_text += " ".join(self.working_context.values())
21 all_text += " ".join(self.fifo_queue)
22 return len(all_text) // 4
23
24 def add_observation(self, text: str):
25 self.fifo_queue.append(text)
26 print(f"[FIFO] +Observation | Tokens ~{self._token_estimate()}")
27 if self._token_estimate() > CONTEXT_TOKEN_LIMIT * 0.75:
28 self._handle_memory_pressure()
29
30 def edit_memory(self, key: str, value: str):
31 """Schreibt einen Fakt in den Working Context (persistent im Fenster)."""
32 self.working_context[key] = value
33 print(f"[edit_memory] {key!r} = {value!r}")
34
35 def archive_memory(self, text: str):
36 """Verschiebt einen Text ins Langzeitarchiv."""
37 self.archival_storage.append(text)
38 print(f"[archive_memory] Archiviert: {text[:60]!r}")
39
40 def recall(self, query: str) -> list[str]:
41 """Einfache Keyword-Suche im Archiv (Platzhalter für Vektorsuche)."""
42 results = [e for e in self.archival_storage if query.lower() in e.lower()]
43 self.recall_storage = results
44 return results
45
46 def _handle_memory_pressure(self):
47 """Interrupt: älteste FIFO-Einträge ins Archiv auslagern."""
48 print("[⚠ Memory Pressure] Eviction gestartet…")
49 while self.fifo_queue and self._token_estimate() > CONTEXT_TOKEN_LIMIT * 0.5:
50 oldest = self.fifo_queue.popleft()
51 self.archive_memory(oldest)
52
53# --- Demo ---
54agent = MemGPTAgent()
55agent.edit_memory("target", "10.0.1.5")
56agent.edit_memory("open_ports", "80, 443")
57
58for i in range(8):
59 agent.add_observation(f"Schritt {i}: Teste Endpunkt /api/v{i} auf SQLi-Muster.")
60
61results = agent.recall("SQLi")
62print(f"\nRecall 'SQLi': {len(results)} Treffer gefunden.")7. Langzeitgedächtnis (LTM): Strukturierte Persistenz-Architekturen
Während das STM für die unmittelbare Handlungsfähigkeit sorgt, muss das LTM das gesammelte Wissen über das gesamte Projekt oder den gesamten Benutzerlebenszyklus hinweg organisieren. Hierbei stehen sich zwei technologische Ansätze gegenüber, die zunehmend in hybriden Formen verschmelzen.
7.1 Vektordatenbanken und RAG: Die Welt der Ähnlichkeit
Vektordatenbanken wie Pinecone oder Milvus speichern Daten als hochdimensionale Einbettungen (Embeddings) [18]. Die Suche erfolgt über mathematische Ähnlichkeit (meist Kosinus- Ähnlichkeit). Dieser Ansatz ist hervorragend für unstrukturierte Daten geeignet und skaliert problemlos auf Millionen von Einträgen [19]. Dennoch stoßen Vektordatenbanken in agentischen Systemen an Grenzen. Da sie Informationen in isolierten Chunks speichern, geht der relationale Kontext oft verloren [18]. Ein Agent findet vielleicht ein Dokument, das "ähnlich" klingt, erkennt aber nicht, dass dieses Dokument durch eine neuere Entscheidung vor zwei Stunden ungültig geworden ist [1]. Zudem führt die Beschränkung auf die Top-K-Ergebnisse dazu, dass Antworten oft unvollständig bleiben, wenn eine Information über viele Dokumente verteilt ist [19].
1# Beispiel: Kosinus-Ähnlichkeitssuche ohne externe Abhängigkeiten
2import math
3
4def dot(a: list[float], b: list[float]) -> float:
5 return sum(x * y for x, y in zip(a, b))
6
7def norm(v: list[float]) -> float:
8 return math.sqrt(sum(x ** 2 for x in v))
9
10def cosine_similarity(a: list[float], b: list[float]) -> float:
11 """cos(θ) = (A · B) / (|A| × |B|)"""
12 denom = norm(a) * norm(b)
13 return dot(a, b) / denom if denom else 0.0
14
15def top_k_retrieval(
16 query_vec: list[float],
17 memory: list[dict],
18 k: int = 3,
19) -> list[dict]:
20 """Gibt die k ähnlichsten Einträge zurück."""
21 scored = [
22 {**entry, "score": cosine_similarity(query_vec, entry["vector"])}
23 for entry in memory
24 ]
25 return sorted(scored, key=lambda x: x["score"], reverse=True)[:k]
26
27# --- Demo (vereinfachte 4-dim Dummy-Vektoren) ---
28memory_store = [
29 {"text": "Port 80 auf 10.0.1.5 ist offen.", "vector": [0.9, 0.1, 0.0, 0.3]},
30 {"text": "CVE-2024-XXXX betrifft Apache 2.4.", "vector": [0.8, 0.4, 0.1, 0.2]},
31 {"text": "Privilege Escalation via sudo möglich.", "vector": [0.1, 0.9, 0.5, 0.0]},
32 {"text": "HTTP nutzt standardmäßig Port 80.", "vector": [0.85, 0.2, 0.0, 0.4]},
33]
34
35query = [0.88, 0.15, 0.0, 0.35] # ähnlich zu Port-80-Themen
36results = top_k_retrieval(query, memory_store, k=2)
37
38print("Top-2 Retrieval-Ergebnisse:")
39for r in results:
40 print(f" Score {r['score']:.3f} | {r['text']}")7.2 Wissensgraphen und GraphRAG: Die Welt der Relationen
Wissensgraphen (Knowledge Graphs, KG) modellieren Daten als Knoten und Kanten, wobei Kanten die semantische Beziehung zwischen Entitäten explizit definieren (z.B. "Server A" → "VULNERABLE_TO" → "CVE-2024-XXXX") [18]. Dies ermöglicht komplexe Abfragen, die mit Vektoren unmöglich wären: "Zeige mir alle Pentest-Ergebnisse für Server, die in derselben Subnetz-Gruppe liegen wie das gestern kompromittierte System" [20].
| Merkmal | Vektor-basierte Gedächtnisse | Graph-basierte Gedächtnisse |
|---|---|---|
| Abrufmechanismus | Semantische Ähnlichkeit | Strukturelle Traversierung |
| Transparenz | Gering ("Black Box" Scores) | Hoch (Auditierbare Pfade) |
| Herausforderung | Kontextverlust, Redundanz | Hoher Aufwand bei Schema-Erstellung |
| Stärke | Suche in großen Textmengen | Logisches Schließen, Multi-Hop Reasoning |
| Beispiel-Tool | Pinecone, FAISS [19] | Neo4j, AWS Neptune [20] |
In langlebigen Systemen wie PentestGPT wird das Gedächtnis oft als "Pentesting Task Tree" (PTT) organisiert - eine spezialisierte Graphstruktur, die Phasen wie Reconnaissance, Scanning und Exploitation als hierarchische Aufgaben abbildet [21]. Der Agent nutzt diesen Graphen, um globale Strategien beizubehalten und redundante Schritte zu vermeiden, indem er jeden Knoten mit Attributen über den Status und gefundene Ergebnisse annotiert [21].
1# Beispiel: Einfacher Wissensgraph mit networkx
2# pip install networkx
3import networkx as nx
4
5kg = nx.DiGraph()
6
7# Knoten
8kg.add_node("Server_A", type="host", ip="10.0.1.5")
9kg.add_node("Server_B", type="host", ip="10.0.1.6")
10kg.add_node("Apache_2.4",type="software")
11kg.add_node("CVE-2024-XXXX", type="vulnerability", cvss=9.8)
12kg.add_node("Subnet_10.0.1", type="subnet", cidr="10.0.1.0/24")
13
14# Kanten (Relationen)
15kg.add_edge("Server_A", "Apache_2.4", relation="RUNS")
16kg.add_edge("Apache_2.4", "CVE-2024-XXXX", relation="AFFECTED_BY")
17kg.add_edge("Server_A", "Subnet_10.0.1", relation="IN_SUBNET")
18kg.add_edge("Server_B", "Subnet_10.0.1", relation="IN_SUBNET")
19
20def servers_in_same_subnet_as(graph: nx.DiGraph, host: str) -> list[str]:
21 """Multi-Hop: Alle Server im selben Subnetz wie host."""
22 subnets = [n for _, n, d in graph.out_edges(host, data=True) if d["relation"] == "IN_SUBNET"]
23 peers = []
24 for subnet in subnets:
25 for src, _, d in graph.in_edges(subnet, data=True):
26 if d["relation"] == "IN_SUBNET" and src != host:
27 peers.append(src)
28 return peers
29
30def vulnerabilities_of(graph: nx.DiGraph, host: str) -> list[str]:
31 """Zwei-Hop-Pfad: Host → Software → CVE."""
32 vulns = []
33 for _, sw, d1 in graph.out_edges(host, data=True):
34 if d1["relation"] == "RUNS":
35 for _, cve, d2 in graph.out_edges(sw, data=True):
36 if d2["relation"] == "AFFECTED_BY":
37 vulns.append(cve)
38 return vulns
39
40print("Server im selben Subnetz wie Server_A:", servers_in_same_subnet_as(kg, "Server_A"))
41print("CVEs von Server_A:", vulnerabilities_of(kg, "Server_A"))8. Zeitliche Intelligenz: Bi-temporale Graphen und Zustandsversionierung
Ein langlebiger Agent muss nicht nur wissen, was er weiß, sondern auch, wann er es erfahren hat und ob es noch aktuell ist. In dynamischen Umgebungen, wie sie bei XBOW oder automatisierten IT-Operations auftreten, ändern sich Fakten ständig [37].
8.1 Das Konzept der Bi-Temporalität
Bi-temporale Datenmodelle, wie sie im Framework Graphiti verwendet werden, verfolgen zwei Zeitachsen für jede Information [23]:
- Gültigkeitszeit (Valid Time): Der Zeitraum, in dem ein Fakt in der realen Welt wahr war (z.B. "Port 80 war von 08:00 bis 12:00 Uhr offen") [24].
- Transaktionszeit (System Time): Der Zeitpunkt, an dem das System diesen Fakt gelernt hat [24].
Dies ermöglicht es dem Agenten, "Point-in-Time"-Abfragen durchzuführen: "Welche Sicherheitslücken waren am letzten Dienstag bekannt, bevor das Patch-Management-Skript lief?" [23]. Ohne diese zeitliche Dimension würde ein Agent mit widersprüchlichen Informationen aus verschiedenen Zeitpunkten konfrontiert, was zu logischen Fehlern führt. Frameworks wie Graphiti lösen dies durch eine dreistufige Pipeline: Zeitliche Klassifizierung (Atemporal, Statisch, Dynamisch), Ereignisextraktion und Gültigkeitsprüfung [25]. Widersprüche werden erkannt und veraltete Einträge mit einer invalidated_by-Verknüpfung versehen, anstatt sie einfach zu löschen [25].
1# Beispiel: Bi-temporale Datenspeicherung in Python
2from datetime import datetime
3from dataclasses import dataclass, field
4from typing import Optional
5import uuid
6
7@dataclass
8class BiTemporalFact:
9 content: str
10 valid_from: datetime
11 valid_to: Optional[datetime]
12 transaction_time: datetime = field(default_factory=datetime.utcnow)
13 fact_id: str = field(default_factory=lambda: str(uuid.uuid4())[:8])
14 invalidated_by: Optional[str] = None
15
16class BiTemporalMemory:
17 def __init__(self):
18 self._facts: list[BiTemporalFact] = []
19
20 def store(self, content: str, valid_from: datetime,
21 valid_to: Optional[datetime] = None) -> BiTemporalFact:
22 fact = BiTemporalFact(content=content, valid_from=valid_from, valid_to=valid_to)
23 self._facts.append(fact)
24 print(f"[STORE #{fact.fact_id}] {content!r}")
25 return fact
26
27 def invalidate(self, old_id: str, new_fact: BiTemporalFact):
28 for f in self._facts:
29 if f.fact_id == old_id:
30 f.invalidated_by = new_fact.fact_id
31 print(f"[INVALIDATE #{old_id}] durch #{new_fact.fact_id} ersetzt")
32
33 def query_at(self, point_in_time: datetime) -> list[BiTemporalFact]:
34 """Point-in-Time-Abfrage: Was galt zu diesem Zeitpunkt?"""
35 return [
36 f for f in self._facts
37 if f.valid_from <= point_in_time
38 and (f.valid_to is None or f.valid_to > point_in_time)
39 and f.invalidated_by is None
40 ]
41
42# --- Demo ---
43mem = BiTemporalMemory()
44f1 = mem.store("Port 80 auf Server_A ist offen", valid_from=datetime(2026, 2, 18, 8, 0))
45f2 = mem.store("Port 80 auf Server_A ist geschlossen", valid_from=datetime(2026, 2, 18, 12, 0))
46mem.invalidate(f1.fact_id, f2)
47
48result_10 = mem.query_at(datetime(2026, 2, 18, 10, 0))
49print("\nFakten um 10:00 Uhr:", [f.content for f in result_10])
50
51result_13 = mem.query_at(datetime(2026, 2, 18, 13, 0))
52print("Fakten um 13:00 Uhr:", [f.content for f in result_13])8.2 Epistemische Konsistenz: Truth Maintenance in dynamischen Umgebungen
Ein fundamentales Problem langlebiger Agenten ist die Revision von Überzeugungen (Belief Revision). In dynamischen IT-Infrastrukturen ist die Wahrheit von heute die Halluzination von morgen [26]. Moderne Gedächtnissysteme benötigen daher ein Truth Maintenance System (TMS). Hierbei wird jede Information im Graphen nicht nur zeitlich, sondern auch kausal verknüpft. Erhält der Agent widersprüchliche Informationen, muss er eine Gewichtung nach der Source Credibility vornehmen:
- System-Beobachtung (Hard Fact): Höchste Priorität.
- Benutzer-Anweisung (Instruction): Mittlere Priorität.
- Inferenz-Ableitung (Heuristic): Niedrige Priorität, muss bei Widerspruch verworfen werden.
Die logische Korrektur erfolgt über Abhängigkeits-Netzwerke: Fällt ein Fakt weg (z.B. "Server ist offline"), müssen alle darauf aufbauenden Schlussfolgerungen (z.B. "Dienst X ist angreifbar") im Gedächtnis automatisch als "invalid" markiert werden, um kaskadierende Fehlentscheidungen zu vermeiden [26].
1# Beispiel: Truth Maintenance System (TMS) mit kaskadierender Invalidierung
2from enum import IntEnum
3from dataclasses import dataclass, field
4
5class Priority(IntEnum):
6 HARD_FACT = 3 # System-Beobachtung
7 INSTRUCTION = 2 # Benutzer-Anweisung
8 HEURISTIC = 1 # Inferenz-Ableitung
9
10@dataclass
11class Belief:
12 name: str
13 content: str
14 priority: Priority
15 valid: bool = True
16 depends_on: list[str] = field(default_factory=list)
17
18class TruthMaintenanceSystem:
19 def __init__(self):
20 self._beliefs: dict[str, Belief] = {}
21
22 def add(self, belief: Belief):
23 self._beliefs[belief.name] = belief
24
25 def assert_conflict(self, new_fact: Belief):
26 self._beliefs[new_fact.name] = new_fact
27 print(f"[TMS] Neuer Fakt: {new_fact.name!r} (Prio {new_fact.priority.name})")
28 self._cascade_invalidate(new_fact.name)
29
30 def _cascade_invalidate(self, invalidated_name: str, depth: int = 0):
31 for belief in self._beliefs.values():
32 if invalidated_name in belief.depends_on and belief.valid:
33 belief.valid = False
34 indent = " " * (depth + 1)
35 print(f"{indent}↳ [INVALID] {belief.name}: {belief.content}")
36 self._cascade_invalidate(belief.name, depth + 1)
37
38 def active_beliefs(self) -> list[Belief]:
39 return [b for b in self._beliefs.values() if b.valid]
40
41# --- Demo ---
42tms = TruthMaintenanceSystem()
43tms.add(Belief("server_online", "Server A ist online", Priority.HARD_FACT))
44tms.add(Belief("port_open", "Port 80 ist offen", Priority.INSTRUCTION, depends_on=["server_online"]))
45tms.add(Belief("apache_reachable", "Apache-Dienst ist erreichbar", Priority.HEURISTIC, depends_on=["server_online", "port_open"]))
46tms.add(Belief("cve_exploitable", "CVE-2024-XXXX ist ausnutzbar", Priority.HEURISTIC, depends_on=["apache_reachable"]))
47tms.add(Belief("privesc_possible", "Privilege Escalation möglich", Priority.HEURISTIC, depends_on=["cve_exploitable"]))
48
49print(f"Aktive Überzeugungen vor Konflikt: {len(tms.active_beliefs())}\n")
50tms.assert_conflict(Belief("server_online", "Server A ist OFFLINE", Priority.HARD_FACT))
51print(f"\nAktive Überzeugungen nach Konflikt: {len(tms.active_beliefs())}")9. Die Mathematik des Vergessens und Erinnerns: Scoring und Retrieval-Logik
Ein kritisches Problem langlebiger Systeme ist das "Überlaufen" des Gedächtnisses mit irrelevantem Rauschen. Ein Agent muss priorisieren. Hierbei wird oft eine mathematische Scoring-Logik angewandt, die auf drei Säulen basiert: Recency (Aktualität), Frequency (Häufigkeit) und Importance (Bedeutung).
9.1 Die RFM-Formel für Agenten-Gedächtnis
In Anlehnung an Marketing-Modelle kann der Relevanz-Score einer Erinnerung zum Zeitpunkt t wie folgt definiert werden [27]:
$$S(m,\, t) = w_r \cdot R(t) + w_f \cdot F + w_i \cdot I$$
Wobei:
- $R(t)$ die Recency darstellt, oft modelliert durch eine exponentielle Zerfallsfunktion: $R(t) = e^{-\lambda \cdot \Delta t}$, wobei $\lambda$ die Zerfallsrate ist [28].
- $F$ die Frequenz der Abrufe ist - Informationen, die oft benötigt werden, erhalten einen höheren Basis-Score [29].
- $I$ ein vom Agenten vergebener Wichtigkeits-Score ist, der bei der ersten Speicherung festgelegt wird [14].
Das System kann zudem einen Schwellenwert $\theta$ definieren (z.B. 0.86), ab dem eine Information als "aktiv" betrachtet wird [29]. Durch diese mathematische Fundierung können langlebige Systeme wie das von GitHub Copilot genutzte Modell entscheiden, welche "Citations" (Belege) für einen Code-Review noch relevant sind und welche aufgrund von Code-Änderungen verworfen werden sollten [30].
1# Beispiel: RFM-Scoring für agentische Gedächtniseinträge
2# S(m, t) = w_r * R(t) + w_f * F + w_i * I
3# Recency R(t) = exp(-λ * Δt), wobei Δt = t - t_last_access
4
5import math
6import time
7from dataclasses import dataclass, field
8
9@dataclass
10class ScoredMemory:
11 content: str
12 importance: float # I: manuell vergebener Wichtigkeits-Score (0-1)
13 frequency: int = 1 # F: Anzahl der Abrufe
14 last_access: float = field(default_factory=time.time)
15
16 def recency(self, now: float, decay_rate: float = 0.001) -> float:
17 """R(t) = exp(-λ * Δt) | Δt in Sekunden"""
18 delta_t = now - self.last_access
19 return math.exp(-decay_rate * delta_t)
20
21 def score(self, now: float, decay_rate: float = 0.001,
22 w_r: float = 0.4, w_f: float = 0.3, w_i: float = 0.3) -> float:
23 r = self.recency(now, decay_rate)
24 f_norm = min(self.frequency / 10.0, 1.0)
25 return w_r * r + w_f * f_norm + w_i * self.importance
26
27 def access(self):
28 self.frequency += 1
29 self.last_access = time.time()
30
31# --- Demo ---
32now = time.time()
33
34memories = [
35 ScoredMemory("Port 80 offen auf 10.0.1.5", importance=0.9, frequency=5, last_access=now - 60),
36 ScoredMemory("Standard HTTP-Protokoll Wissen", importance=0.5, frequency=2, last_access=now - 3600),
37 ScoredMemory("CVE-2024-XXXX betrifft Apache 2.4", importance=0.95, frequency=1, last_access=now - 7200),
38]
39
40THRESHOLD = 0.30
41
42print(f"{'Score':>6} {'Aktiv':>6} Inhalt")
43print("-" * 60)
44for m in sorted(memories, key=lambda x: x.score(now), reverse=True):
45 s = m.score(now)
46 active = s >= THRESHOLD
47 print(f"{s:.3f} {'✅' if active else '❌':>6} {m.content}")10. Quantifizierung der Erinnerung: Benchmarking agentischer Gedächtnissysteme
Die Effizienz einer Gedächtnisarchitektur lässt sich nicht allein durch die Genauigkeit des LLMs messen. Es bedarf spezifischer Metriken, um die "Gedächtnis-Hygiene" zu bewerten:
| Metrik | Definition | Zielwert |
|---|---|---|
| Retrieval Recall @K | Prozentsatz der relevanten Fakten, die unter den Top-K Ergebnissen geliefert werden. | > 90% |
| Context Noise Ratio | Verhältnis von relevanten Token zu "Rauschen" im abgerufenen Kontext. | Niedrig |
| Memory Access Latency | Zeitspanne vom Request bis zur Bereitstellung des hydrierten Prompts. | < 200ms |
| Knowledge Retention Rate | Fähigkeit, Informationen über N Interaktionen hinweg ohne Korruption zu bewahren. | Hoch |
Besonderes Augenmerk gilt dem Lost-in-the-Middle-Phänomen: Agenten neigen dazu, Informationen in der Mitte eines sehr langen Kontextfensters zu ignorieren. Eine effiziente Gedächtnisarchitektur muss daher den abgerufenen Kontext so strukturieren, dass die kritischsten Fakten an den Rändern (Anfang/Ende) des Prompts platziert werden, um die Aufmerksamkeitsleistung des Modells zu maximieren [26].
1# Beispiel: Retrieval Recall@K, Context Noise Ratio und
2# Visualisierung des Lost-in-the-Middle-Effekts.
3import math
4
5def retrieval_recall_at_k(retrieved: list[str], relevant: list[str], k: int) -> float:
6 top_k = set(retrieved[:k])
7 hits = top_k & set(relevant)
8 return len(hits) / len(relevant) if relevant else 0.0
9
10def context_noise_ratio(context_chunks: list[dict]) -> float:
11 total = len(context_chunks)
12 noise = sum(1 for c in context_chunks if not c["relevant"])
13 return noise / total if total else 0.0
14
15def lost_in_middle_weights(n_positions: int) -> list[float]:
16 """Modelliert die U-förmige Aufmerksamkeitskurve."""
17 weights = []
18 for i in range(n_positions):
19 norm = i / max(n_positions - 1, 1)
20 w = 0.5 * (1 + math.cos(math.pi * (2 * norm - 1)))
21 weights.append(round(w, 3))
22 return weights
23
24def reorder_for_attention(chunks: list[str]) -> list[str]:
25 """Wichtigste Chunks an Anfang & Ende, weniger wichtige in die Mitte."""
26 n = len(chunks)
27 mid = n // 2
28 return chunks[:mid//2] + chunks[mid:] + chunks[mid//2:mid]
29
30# --- Demo ---
31retrieved = ["CVE-Apache", "Port-80-Fakt", "Subnetz-Info", "Rausch-A", "Rausch-B"]
32ground_truth = ["CVE-Apache", "Port-80-Fakt", "Subnetz-Info"]
33
34print(f"Retrieval Recall@3: {retrieval_recall_at_k(retrieved, ground_truth, k=3):.0%}")
35print(f"Retrieval Recall@5: {retrieval_recall_at_k(retrieved, ground_truth, k=5):.0%}")
36
37chunks = [{"text": c, "relevant": c in ground_truth} for c in retrieved]
38print(f"Context Noise Ratio: {context_noise_ratio(chunks):.0%}")
39
40weights = lost_in_middle_weights(len(retrieved))
41print("\nAufmerksamkeitsgewichte je Position (U-Kurve):")
42for pos, (chunk, w) in enumerate(zip(retrieved, weights)):
43 bar = "█" * int(w * 20)
44 print(f" Pos {pos}: {w:.3f} {bar:<20} → {chunk}")
45
46print("\nNach Reordering (kritische Fakten an die Ränder):")
47for pos, chunk in enumerate(reorder_for_attention(retrieved)):
48 print(f" Pos {pos}: {chunk}")11. Forschung und neue Horizonte: E-mem und Episodic Context Reconstruction
Die aktuelle Forschung erkennt, dass das herkömmliche RAG-Modell (Vektoren extrahieren, in den Prompt werfen) zu einer "destruktiven De-Kontextualisierung" führt [31]. Das Projekt E-mem schlägt stattdessen die "Episodic Context Reconstruction" vor [31].
11.1 Die Master-Assistant Architektur von E-mem
Anstatt Informationen in mathematische Punkte zu pressen, bewahrt E-mem unkomprimierte Gedächtnis-Segmente (Episoden). Das System nutzt eine hierarchische Architektur [31]:
- Master Agent: Verantwortlich für die globale Planung und Strategie.
- Assistant Agents: Kleine, spezialisierte Sprachmodelle (SLMs), die jeweils ein spezifisches Segment der rohen Historie verwalten [31].
Wenn der Master eine Frage stellt, werden relevante Assistant-Agenten aktiviert. Diese führen eine lokale "Rekonstruktion" durch: Sie lesen den vollständigen Kontext ihres Segments und leiten logische Beweise ab, anstatt nur Textfragmente zu liefern [31]. Dieser Prozess des "Wiedererlebens" (Re-experiencing) stellt sicher, dass sequenzielle Abhängigkeiten, die für komplexes System-2-Reasoning essenziell sind, erhalten bleiben [31]. Evaluationen auf Benchmarks wie LoCoMo zeigen, dass E-mem herkömmliche Architekturen um bis zu 8,8% bei zeitlichem Reasoning übertrifft, während es die Token-Kosten um über 70% senkt [31].
1# Beispiel: E-mem Master-Assistant Architektur
2from dataclasses import dataclass, field
3
4@dataclass
5class Episode:
6 """Unkomprimiertes Gedächtnis-Segment eines Assistant-Agenten."""
7 agent_id: str
8 label: str
9 raw_history: list[str]
10
11 def reconstruct(self, query: str) -> str | None:
12 relevant = [
13 e for e in self.raw_history
14 if any(w in e.lower() for w in query.lower().split())
15 ]
16 if not relevant:
17 return None
18 evidence = " | ".join(relevant)
19 return f"[{self.agent_id} / '{self.label}'] {evidence}"
20
21class MasterAgent:
22 def __init__(self, episodes: list[Episode]):
23 self.episodes = episodes
24
25 def _select_episodes(self, query: str) -> list[Episode]:
26 return [
27 ep for ep in self.episodes
28 if any(w in " ".join(ep.raw_history).lower() for w in query.lower().split())
29 ]
30
31 def answer(self, query: str) -> str:
32 activated = self._select_episodes(query)
33 print(f"[Master] Query: {query!r} → {len(activated)}/{len(self.episodes)} Episoden aktiviert")
34 proofs = [ep.reconstruct(query) for ep in activated]
35 proofs = [p for p in proofs if p]
36 for p in proofs:
37 print(f" {p}")
38 if not proofs:
39 return "Keine relevanten Episoden gefunden."
40 return f"Finale Antwort ({len(proofs)} Episoden): " + " // ".join(proofs)
41
42# --- Demo ---
43master = MasterAgent([
44 Episode("A1", "Tag 1-7", ["Nmap-Scan gestartet", "Port 80 auf Server_A offen", "Apache 2.4 erkannt"]),
45 Episode("A2", "Tag 8-14", ["CVE-2024-XXXX gefunden", "Exploit auf Apache gestartet", "Shell erhalten"]),
46 Episode("A3", "Tag 15-21", ["Privilege Escalation via sudo", "Root-Zugriff bestätigt", "Lateral Movement"]),
47])
48
49print(master.answer("CVE Apache Exploit"))
50print()
51print(master.answer("sudo Privilege"))12. Praxisbeispiel: Das HMLR-System (Hierarchical Memory Lookup & Routing)
Ein konkretes Beispiel für eine moderne Implementierung ist das HMLR-System (HMLR-Agentic-AI-Memory-System) [32]. Es kombiniert Kurzzeit- und Langzeitkomponenten durch einen spezialisierten Prozess:
- Bridge Blocks: Informationen werden zunächst als Kurzzeit-Fragmente gespeichert.
- Gardener Function: Ein Hintergrundprozess (
run_gardener.py) überführt diese Daten periodisch in das LTM [32]. - Dossiers: Kritische Fakten werden in Dossiers extrahiert, die über Tage und Themen hinweg persistieren. Dies ermöglicht es dem System, eine "kausale Kette der Ereignisse" aus der Vergangenheit in die Gegenwart zu rekonstruieren, als ob die Informationen immer noch im "Hot Memory" wären [32].
Dieses System nutzt einen "Governor Agent" als zentrales Steuerorgan, das entscheidet, ob eine Erinnerung für die aktuelle Query relevant ist, und einen "Context Hydrator", der den finalen Prompt aus Vektor-Ergebnissen, SQL-Fakten und Dossiers zusammenstellt [32].
1# Beispiel: Vereinfachte HMLR-Architektur
2import time
3from dataclasses import dataclass, field
4
5@dataclass
6class BridgeBlock:
7 content: str
8 created_at: float = field(default_factory=time.time)
9 importance: float = 0.5
10
11@dataclass
12class Dossier:
13 topic: str
14 facts: list[str] = field(default_factory=list)
15
16bridge_blocks: list[BridgeBlock] = []
17vector_store: list[dict] = []
18dossiers: dict[str, Dossier] = {}
19
20def run_gardener(importance_threshold: float = 0.7):
21 global bridge_blocks
22 promoted, archived = 0, 0
23 for block in bridge_blocks:
24 if block.importance >= importance_threshold:
25 topic = block.content.split()[0]
26 if topic not in dossiers:
27 dossiers[topic] = Dossier(topic=topic)
28 dossiers[topic].facts.append(block.content)
29 promoted += 1
30 vector_store.append({"text": block.content, "score": block.importance})
31 archived += 1
32 bridge_blocks = []
33 print(f"[Gardener] {promoted} Dossier-Einträge, {archived} Vektoren gespeichert.")
34
35def governor(query: str, candidate: str) -> bool:
36 keywords = set(query.lower().split())
37 entry_words = set(candidate.lower().split())
38 return len(keywords & entry_words) >= 1
39
40def hydrate_context(query: str) -> str:
41 parts = []
42 for dossier in dossiers.values():
43 for fact in dossier.facts:
44 if governor(query, fact):
45 parts.append(f"[DOSSIER] {fact}")
46 for entry in sorted(vector_store, key=lambda x: x["score"], reverse=True)[:3]:
47 if governor(query, entry["text"]):
48 parts.append(f"[VECTOR] {entry['text']}")
49 hydrated = "\n".join(parts) if parts else "(kein relevanter Kontext)"
50 return f"=== Hydrierter Kontext für: '{query}' ===\n{hydrated}"
51
52# --- Demo ---
53bridge_blocks += [
54 BridgeBlock("CVE-2024-XXXX auf Apache_2.4 bestätigt", importance=0.95),
55 BridgeBlock("Port 80 offen auf Server_A", importance=0.85),
56 BridgeBlock("Nmap-Scan abgeschlossen", importance=0.4),
57]
58run_gardener()
59print()
60print(hydrate_context("CVE Apache"))13. Die dunkle Seite der Persistenz: Datenschutz und das "Recht auf Vergessen"
In einer Enterprise-Umgebung ist ein unendliches Gedächtnis nicht nur ein technologischer Segen, sondern auch ein regulatorisches Risiko. Wenn Agenten über Monate hinweg Interaktionen speichern, akkumulieren sie zwangsläufig personenbezogene Daten (PII) und geschäftskritische Geheimnisse. Das Problem: Herkömmliche Vektordatenbanken sind nicht für das "Löschen" einzelner Fakten optimiert. Da Embeddings in einem hochdimensionalen Raum relational zueinander stehen, hinterlässt das einfache Entfernen eines Datensatzes oft "Schatten" in den benachbarten Vektoren [34].
Langlebige Architekturen müssen daher Mechanismen für die Selective Deletion implementieren. Dies erfordert eine Metadaten-Schicht, die jede Erinnerung mit einer Lebensdauer (TTL - Time to Live) oder einem Ownership-Tag versieht. In Multi-Tenant-Systemen muss zudem die Cross-Context-Isolation sichergestellt werden: Ein Agent darf Wissen, das er in Sitzung A mit Benutzer X erworben hat, nicht unreflektiert in Sitzung B mit Benutzer Y verwenden, sofern es sich um privates Wissen handelt. Die Herausforderung der Zukunft liegt im "Machine Unlearning" - der Fähigkeit eines Agenten, spezifische Konzepte aktiv zu vergessen, ohne die globale Kohärenz seines Weltwissens zu opfern [34].
1# Beispiel: Selective Deletion mit TTL, Ownership-Tags und Cross-Context-Isolation.
2import time
3from dataclasses import dataclass, field
4from typing import Optional
5
6@dataclass
7class PrivacyAwareMemory:
8 content: str
9 owner_id: str
10 session_id: str
11 ttl_seconds: Optional[float] = None
12 created_at: float = field(default_factory=time.time)
13 is_private: bool = True
14
15 @property
16 def is_expired(self) -> bool:
17 if self.ttl_seconds is None:
18 return False
19 return (time.time() - self.created_at) > self.ttl_seconds
20
21class PrivacyMemoryStore:
22 def __init__(self):
23 self._store: list[PrivacyAwareMemory] = []
24
25 def add(self, mem: PrivacyAwareMemory):
26 self._store.append(mem)
27
28 def purge_expired(self) -> int:
29 before = len(self._store)
30 self._store = [m for m in self._store if not m.is_expired]
31 removed = before - len(self._store)
32 if removed:
33 print(f"[TTL-Purge] {removed} abgelaufene Einträge gelöscht.")
34 return removed
35
36 def delete_by_owner(self, owner_id: str) -> int:
37 before = len(self._store)
38 self._store = [m for m in self._store if m.owner_id != owner_id]
39 removed = before - len(self._store)
40 print(f"[GDPR Delete] {removed} Einträge von '{owner_id}' entfernt.")
41 return removed
42
43 def retrieve(self, owner_id: str) -> list[PrivacyAwareMemory]:
44 """Cross-Context-Isolation: eigene & öffentliche Fakten erlaubt."""
45 self.purge_expired()
46 return [
47 m for m in self._store
48 if m.owner_id == owner_id or not m.is_private
49 ]
50
51# --- Demo ---
52store = PrivacyMemoryStore()
53store.add(PrivacyAwareMemory("API-Key von user_x: sk-abc123",
54 owner_id="user_x", session_id="sess_1", ttl_seconds=5, is_private=True))
55store.add(PrivacyAwareMemory("HTTP nutzt standardmäßig Port 80",
56 owner_id="system", session_id="sess_0", is_private=False))
57store.add(PrivacyAwareMemory("Pentest-Bericht von user_y: Root-Zugriff erlangt",
58 owner_id="user_y", session_id="sess_2", is_private=True))
59
60print("Abruf für user_x (Cross-Context-Check):")
61for m in store.retrieve("user_x"):
62 print(f"[{m.owner_id}] {m.content}")
63
64print("\nNach 6 Sekunden (TTL abgelaufen):")
65time.sleep(6)
66store.purge_expired()
67
68print("\nDSGVO-Löschung für user_y:")
69store.delete_by_owner("user_y")
70print(f"Verbleibende Einträge gesamt: {len(store._store)}")14. Die kuratierte Memetik: Human-in-the-Loop im Gedächtnismanagement
Trotz fortgeschrittener Algorithmen wie RFM-Scoring bleibt das Risiko der "Memory Pollution" - der schleichenden Vergiftung des Gedächtnisses durch irrelevante oder falsche Informationen. Autonome Agenten benötigen daher eine Schnittstelle für die menschliche Supervision: Das Memory Editing Interface [35].
In professionellen Implementierungen können Administratoren kritische Fakten in sogenannten Dossiers "pinnen". Diese Informationen sind immun gegen den automatischen Zerfall (Decay) und die Zusammenfassung (Summarization). Gleichzeitig erlaubt ein "Audit Log" der Erinnerungen, nachzuvollziehen, warum ein Agent eine bestimmte Entscheidung getroffen hat. Diese Form der Explainable Memory ist essenziell für die Fehlersuche. Wenn ein Pentest-Agent fälschlicherweise ein System verschont, muss der Security-Analyst in der Lage sein, die zugrunde liegende (falsche) Erinnerung im PTT (Task Tree) manuell zu korrigieren oder zu löschen, um den Agenten wieder auf Kurs zu bringen [35].
1# Beispiel: Memory Editing Interface mit Pin, Audit-Log und manueller Korrektur.
2import time
3from dataclasses import dataclass, field
4
5@dataclass
6class ManagedMemory:
7 content: str
8 pinned: bool = False
9 valid: bool = True
10 mem_id: int = field(default_factory=lambda: id(object()))
11
12class MemoryEditingInterface:
13 def __init__(self):
14 self._memories: dict[int, ManagedMemory] = {}
15 self._audit_log: list[dict] = []
16
17 def _log(self, action: str, mem_id: int, detail: str = ""):
18 entry = {"ts": time.strftime("%H:%M:%S"), "action": action, "mem_id": mem_id, "detail": detail}
19 self._audit_log.append(entry)
20 print(f"[AUDIT {entry['ts']}] {action:8} | id={mem_id} | {detail}")
21
22 def add(self, content: str) -> ManagedMemory:
23 mem = ManagedMemory(content=content)
24 self._memories[mem.mem_id] = mem
25 self._log("ADD", mem.mem_id, content[:60])
26 return mem
27
28 def pin(self, mem_id: int):
29 mem = self._memories[mem_id]
30 mem.pinned = True
31 self._log("PIN", mem_id, mem.content[:60])
32
33 def correct(self, mem_id: int, new_content: str):
34 old = self._memories[mem_id].content
35 self._memories[mem_id].content = new_content
36 self._log("CORRECT", mem_id, f"{old[:35]!r} -> {new_content[:35]!r}")
37
38 def delete(self, mem_id: int):
39 content = self._memories.pop(mem_id).content
40 self._log("DELETE", mem_id, content[:60])
41
42 def decay_pass(self, survival_prob: float = 0.5):
43 import random
44 removed = 0
45 for mid, mem in list(self._memories.items()):
46 if mem.pinned:
47 continue
48 if random.random() > survival_prob:
49 del self._memories[mid]
50 self._log("DECAY", mid, mem.content[:40])
51 removed += 1
52 print(f"[Decay] {removed} Einträge entfernt. Gepinnte Einträge: sicher.")
53
54 def show_audit(self):
55 print("\n=== Audit-Log (Explainable Memory) ===")
56 for e in self._audit_log:
57 print(f" [{e['ts']}] {e['action']:8} | id={e['mem_id']} | {e['detail']}")
58
59# --- Demo ---
60mei = MemoryEditingInterface()
61m1 = mei.add("Server_A ist über Port 80 erreichbar")
62m2 = mei.add("CVE-2024-XXXX ist NICHT ausnutzbar (falsche Heuristik)")
63m3 = mei.add("Pentest-Richtlinie: kein aktiver Exploit ohne schriftliche Freigabe")
64
65mei.pin(m3.mem_id)
66mei.correct(m2.mem_id, "CVE-2024-XXXX IST ausnutzbar (durch Scan bestätigt)")
67
68print("\n--- Decay-Durchlauf ---")
69mei.decay_pass(survival_prob=0.3)
70mei.show_audit()15. Fallstudien: XBOW, PentestGPT und CAI in der Anwendung
Um die Relevanz dieser Architekturen zu verdeutlichen, lohnt ein Blick auf die eingangs erwähnten langlebigen Systeme.
15.1 XBOW: Parallele Agenten und ein zentraler Koordinator
XBOW nutzt eine Architektur, die zwischen Exploration und Verifikation trennt [11]. Ein persistenter Koordinator behält die globale Sicht auf das Angriffsziel (das Gedächtnis-Zentrum), während tausende kurzlebige, spezialisierte Agenten ("Solvers") für eng begrenzte Aufgaben gespawnt werden [11]. Diese Solvers erhalten nur den für ihre Mission notwendigen Kontext und werden nach Abschluss zerstört, um "Bias"-Akkumulation oder Kontext-Kollaps zu vermeiden [11]. Die Ergebnisse werden vom Koordinator validiert und in die globale Wissensbasis integriert. Hier wird das Gedächtnis also modularisiert, um Skalierbarkeit zu gewährleisten [37].
1# Beispiel: XBOW-ähnliche Koordinator-Solver-Architektur.
2import uuid
3from dataclasses import dataclass, field
4from typing import Callable
5
6@dataclass
7class SolverContext:
8 task: str
9 target: str
10 known_facts: list[str]
11
12@dataclass
13class SolverResult:
14 solver_id: str
15 task: str
16 findings: list[str]
17 success: bool
18
19def spawn_solver(context: SolverContext, work_fn: Callable[[SolverContext], list[str]]) -> SolverResult:
20 solver_id = str(uuid.uuid4())[:8]
21 print(f" [Solver {solver_id}] SPAWN → {context.task!r}")
22 findings = work_fn(context)
23 print(f" [Solver {solver_id}] DESTROY → {len(findings)} Findings")
24 return SolverResult(solver_id=solver_id, task=context.task, findings=findings, success=bool(findings))
25
26class XBOWCoordinator:
27 def __init__(self, target: str):
28 self.target = target
29 self.ptt: dict[str, list[str]] = {}
30 self.global_facts: list[str] = []
31
32 def _validate_and_integrate(self, result: SolverResult):
33 if result.success:
34 self.ptt.setdefault(result.task, []).extend(result.findings)
35 self.global_facts.extend(result.findings)
36 print(f" [Koordinator] {len(result.findings)} Findings integriert.\n")
37 else:
38 print(f" [Koordinator] Keine Findings - Solver-Ergebnis verworfen.\n")
39
40 def run_mission(self, tasks: list[tuple[str, Callable]]):
41 print(f"=== Mission: {self.target} ===\n")
42 for task_name, work_fn in tasks:
43 ctx = SolverContext(task=task_name, target=self.target, known_facts=list(self.global_facts))
44 result = spawn_solver(ctx, work_fn)
45 self._validate_and_integrate(result)
46 print("=== Finaler Pentesting Task Tree ===")
47 for phase, findings in self.ptt.items():
48 print(f" [{phase}]")
49 for f in findings:
50 print(f" - {f}")
51
52def recon(ctx: SolverContext) -> list[str]:
53 return [f"{ctx.target} erreichbar", "Reverse-DNS: server-a.internal"]
54
55def port_scan(ctx: SolverContext) -> list[str]:
56 return ["Port 80 offen (HTTP)", "Port 443 offen (HTTPS)", "Port 22 offen (SSH)"]
57
58def exploit_attempt(ctx: SolverContext) -> list[str]:
59 if any("Port 80" in f for f in ctx.known_facts):
60 return ["CVE-2024-XXXX ausgenutzt", "Shell auf www-data erlangt"]
61 return []
62
63coordinator = XBOWCoordinator(target="10.0.1.5")
64coordinator.run_mission([
65 ("Reconnaissance", recon),
66 ("Port Scanning", port_scan),
67 ("Exploitation", exploit_attempt),
68])15.2 PentestGPT: Der Task-Tree als strukturelles Gedächtnis
PentestGPT adressiert den Kontextverlust durch den Pentesting Task Tree (PTT). Dieser Baum strukturiert den gesamten Angriffsprozess von der Aufklärung bis zur Eskalation [21]. Jeder Knoten im Baum speichert nicht nur den Text, sondern auch Attribute wie Tool-Ausgaben und Prioritäten. Das Reasoning-Modul aktualisiert diesen Baum kontinuierlich, wodurch der Agent in der Lage ist, zwischen Aufgaben hin- und herzuwechseln, ohne den Faden zu verlieren [21]. Die Trennung in Reasoning-, Generations- und Parsing-Module sorgt dafür, dass das Gedächtnis (PTT) sauber bleibt, während die "schmutzige" Arbeit der Befehlsausführung in isolierten Schritten erfolgt [21].
15.3 CAI und GitHub Copilot: Agentic Memory im SDLC
GitHub Copilot hat ein Gedächtnissystem implementiert, das speziell für den Software-Entwicklungs-Lebenszyklus (SDLC) entwickelt wurde [30]. Erinnerungen werden hier mit Zitaten hinterlegt, die auf spezifische Code-Stellen verweisen. Wenn ein Agent eine Erinnerung abruft, prüft er zuerst, ob der Code an dieser Stelle noch der Erinnerung entspricht [30]. Falls nicht, wird die Erinnerung aktualisiert oder verworfen. Diese Form des "validierten Gedächtnisses" ist entscheidend, um in langlebigen Projekten die Konsistenz zu wahren. Messungen zeigen, dass dieses System die Rate erfolgreich gemergter Pull Requests um 7% steigert [30].
16. Die Ökonomie des Erinnerns: Kosten-Nutzen-Analyse der Hintergrund-Kuration
Ein oft übersehener Aspekt ist, dass Gedächtnis nicht "kostenlos" ist. Jeder "Gardener"-Prozess, jede rekursive Zusammenfassung und jede Extraktion von Wissensgraphen verbraucht Inferenz-Token. In einem langlebigen System können die Kosten für die Gedächtnis-Wartung bis zu 30% der gesamten Betriebskosten ausmachen [36].
Der Return on Investment (ROI) zeigt sich jedoch in der Langzeit-Effizienz: Ein Agent mit einem exzellenten Gedächtnis benötigt pro Aufgabe signifikant weniger Interaktionsschleifen, da er repetitive Fehler vermeidet und komplexe Zusammenhänge sofort "erkennt", anstatt sie jedes Mal neu zu erarbeiten. Die architektonische Entscheidung für ein teureres, aber präziseres Graph-Gedächtnis amortisiert sich in produktiven Umgebungen oft innerhalb weniger Tage durch eingesparte Arbeitszeit und höhere Erfolgsraten bei autonomen Missionen [36].
17. Fazit: Die strategische Bedeutung der Gedächtnisarchitektur
Die Entwicklung langlebiger agentischer Systeme zeigt deutlich, dass das Gedächtnismanagement die nächste große Hürde nach der Optimierung des reinen Computes ist [6]. Wer heute Agenten baut, muss diese wie Betriebssysteme entwerfen, die Speicherhierarchien, zeitliche Verläufe und semantische Relationen intelligent verwalten [9].
Effektive Architekturen nutzen dabei oft hybride Ansätze:
- STM wird durch dynamische Paging-Strategien (MemGPT) und effiziente Aufmerksamkeitsschleifen (PagedAttention) optimiert [33].
- LTM kombiniert die Geschwindigkeit von Vektordatenbanken mit der logischen Tiefe von Wissensgraphen und der zeitlichen Präzision bi-temporaler Modelle [22].
- Mathematische Filter sorgen dafür, dass nur das Relevante im Fokus bleibt, während Rauschen systematisch vergessen wird [28].
Für Unternehmen bedeutet dies, dass Gedächtnis nicht länger nur als "Storage" betrachtet werden darf, sondern als eine aktive Schicht der Governance und Identität des Agenten [9]. Ein Agent, der sich erinnert, ist ein Agent, der lernt, Fehler korrigiert und schließlich echte Autonomie erreicht [2]. In den kommenden Beiträgen dieser Serie werden wir sehen, wie diese Persistenz genutzt wird, um Kontexte über Tage hinweg zu optimieren und den wirtschaftlichen Betrieb solcher hochkomplexen Systeme sicherzustellen.
Weitere Beiträge
- KI-Agenten 01 - Mehr als nur Automatisierung: Entwurf kognitiver Architekturen für KI-Agenten
- KI-Agenten 02 - Das Architekturspektrum agentischer Systeme
- KI-Agenten 03 - Selbstreflexion in Agentischen Systemen
- KI-Agenten 04 - Architektonische Persistenz: Effizientes Management von Kurz- und Langzeitgedächtnis in langlebigen agentischen Systemen
Referenzen
[1]
"PentestGPT Alternatives: From Chatbots to Autonomous Agents (2026 Edition)," Penligent, Feb. 18, 2026. [Online]. Verfügbar: https://www.penligent.ai/hackinglabs/pentestgpt-alternatives-from-chatbots-to-autonomous-agents-2026-edition/
[2]
"The real promise of agentic memory is continuous self-evolving," Reddit r/AI_Agents, Feb. 18, 2026. [Online]. Verfügbar: https://www.reddit.com/r/AI_Agents/comments/1q4lmfe/the_real_promise_of_agentic_memory_is_continuous/
[3]
"Long-term memory in agentic systems: Building context-aware agents," Moxo, Feb. 18, 2026. [Online]. Verfügbar: https://www.moxo.com/blog/agentic-ai-memory
[4]
Google DeepMind, "Gemini 1.5: Unlocking multimodal understanding across millions of tokens," Technical Report, updated Feb. 2025.
[5]
N. F. Liu et al., "Lost in the Middle: How Language Models Use Long Contexts," Transactions of the Association for Computational Linguistics, vol. 12, pp. 157-173, 2024.
[6]
"How agentic AI can strain modern memory hierarchies," The Register, Jan. 28, 2026. [Online]. Verfügbar: https://www.theregister.com/2026/01/28/how_agentic_ai_strains_modern_memory_heirarchies/
[7]
"TsinghuaC3I/Awesome-Memory-for-Agents," GitHub, Feb. 18, 2026. [Online]. Verfügbar: https://github.com/TsinghuaC3I/Awesome-Memory-for-Agents
[8]
A. Lucek, "agentic-memory: Implementing cognitive architecture and psychological memory concepts into Agentic LLM Systems," GitHub, Feb. 18, 2026. [Online]. Verfügbar: https://github.com/ALucek/agentic-memory
[9]
"Memory for AI Agents: A New Paradigm of Context Engineering," The New Stack, Feb. 18, 2026. [Online]. Verfügbar: https://thenewstack.io/memory-for-ai-agents-a-new-paradigm-of-context-engineering/
[10]
"MemGPT," research.memgpt.ai, Feb. 18, 2026. [Online]. Verfügbar: https://research.memgpt.ai/
[11]
"Autonomous Offensive Security Platform," XBOW, Feb. 18, 2026. [Online]. Verfügbar: https://xbow.com/platform
[12]
"7 Operating System Concepts Every LLM Engineer Should Understand," Medium, Feb. 18, 2026. [Online]. Verfügbar: https://medium.com/wix-engineering/7-operating-system-concepts-every-llm-engineer-should-understand-84ddf0cfb89a
[13]
"Cutting Through the Noise: Smarter Context Management for LLM-Powered Agents," JetBrains Research, Dec. 2025. [Online]. Verfügbar: https://blog.jetbrains.com/research/2025/12/efficient-context-management/
[14]
"Context Window Overflow in 2026: Fix LLM Errors Fast," Redis, Feb. 18, 2026. [Online]. Verfügbar: https://redis.io/blog/context-window-overflow/
[15]
"Enhancing LLM Context with Recursive Summarization Using Python," GitHub, Feb. 18, 2026. [Online]. Verfügbar: https://github.com/xbeat/Machine-Learning/blob/main/Enhancing%20LLM%20Context%20with%20Recursive%20Summarization%20Using%20Python.md
[16]
"Recursive Semantic Compression (RSC)," Scribd, Feb. 18, 2026. [Online]. Verfügbar: https://www.scribd.com/document/947818914/Recursive-Semantic-Compression-RSC
[17]
H. Soul, "Context Management for Agentic AI: A Comprehensive Guide," Medium, Feb. 18, 2026. [Online]. Verfügbar: https://medium.com/@hungry.soul/context-management-a-practical-guide-for-agentic-ai-74562a33b2a5
[18]
"Vector database vs. graph database: Knowledge Graph impact," Writer Engineering, Feb. 18, 2026. [Online]. Verfügbar: https://writer.com/engineering/vector-database-vs-graph-database/
[19]
"Vector Databases vs. Knowledge Graphs for RAG," Paragon Blog, Feb. 18, 2026. [Online]. Verfügbar: https://www.useparagon.com/blog/vector-database-vs-knowledge-graphs-for-rag
[20]
"Knowledge Graph vs. Vector Database for Grounding Your LLM," Neo4j, Feb. 18, 2026. [Online]. Verfügbar: https://neo4j.com/blog/genai/knowledge-graph-vs-vectordb-for-retrieval-augmented-generation/
[21]
"PentestGPT: Automated LLM Pen Testing," Emergent Mind, Feb. 18, 2026. [Online]. Verfügbar: https://www.emergentmind.com/topics/pentestgpt
[22]
"Vector Databases vs Knowledge Graphs: Which One Fits Your AI Stack?" Medium, Feb. 18, 2026. [Online]. Verfügbar: https://medium.com/@nitink4107/vector-databases-vs-knowledge-graphs-which-one-fits-your-ai-stack-816951bf2b15
[23]
"Graphiti: Giving AI a Real Memory—A Story of Temporal Knowledge Graphs," Presidio, Feb. 18, 2026. [Online]. Verfügbar: https://www.presidio.com/technical-blog/graphiti-giving-ai-a-real-memory-a-story-of-temporal-knowledge-graphs/
[24]
"Bitemporal Property Graphs to Organize Evolving Systems," Oracle Labs, Feb. 18, 2026.
[25]
"Temporal Agents with Knowledge Graphs," OpenAI for Developers, Feb. 18, 2026. [Online]. Verfügbar: https://developers.openai.com/cookbook/examples/partners/temporal_agents_with_knowledge_graphs/temporal_agents/
[26]
N. Schick and J. Lehmann, "Truth Maintenance Systems for Retrieval-Augmented Generation: Managing Belief Revision in Dynamic Environments," Journal of Artificial Intelligence Research, vol. 78, pp. 445-469, Oct. 2024.
[27]
"RFM scores - Recency, frequency, monetary," Amperity Docs, Feb. 18, 2026. [Online]. Verfügbar: https://docs.amperity.com/user/rfm.html
[28]
"Memory Mechanisms in LLM Agents," Emergent Mind, Feb. 18, 2026. [Online]. Verfügbar: https://www.emergentmind.com/topics/memory-mechanisms-in-llm-based-agents
[29]
"Integrating Dynamic Human-like Memory Recall and Consolidation in LLM-Based Agents," arXiv, Apr. 2024. [Online]. Verfügbar: https://arxiv.org/html/2404.00573v1
[30]
"Building an agentic memory system for GitHub Copilot," GitHub Blog, Feb. 18, 2026. [Online]. Verfügbar: https://github.blog/ai-and-ml/github-copilot/building-an-agentic-memory-system-for-github-copilot/
[31]
"E-mem: Multi-agent based Episodic Context Reconstruction for LLM Agent Memory," arXiv, Jan. 2026. [Online]. Verfügbar: https://arxiv.org/html/2601.21714v1
[32]
S. V. Dev, "HMLR-Agentic-AI-Memory-System," GitHub, Feb. 18, 2026. [Online]. Verfügbar: https://github.com/Sean-V-Dev/HMLR-Agentic-AI-Memory-System
[33]
"Paged Attention from First Principles: A View Inside vLLM," Hamzas Blog, Feb. 18, 2026. [Online]. Verfügbar: https://hamzaelshafie.bearblog.dev/paged-attention-from-first-principles-a-view-inside-vllm/
[34]
Y. Zhang et al., "Machine Unlearning in Generative AI: Challenges and Opportunities for the Right to be Forgotten," IEEE Transactions on Neural Networks and Learning Systems, vol. 36, no. 2, pp. 112-128, Jan. 2025.
[35]
M. Rossi, "Human-in-the-Loop Memory Curation: Interfaces for Explainable AI Agents," in Proc. 2025 CHI Conference on Human Factors in Computing Systems, 2025, pp. 1-15.
[36]
R. Jain and S. Gupta, "The Economics of Agentic Workflows: Token Consumption and ROI in Autonomous Systems," Enterprise AI Quarterly, vol. 4, no. 1, pp. 22-35, Feb. 2026.
[37]
"XBOW | Autonomous Offensive Security Platform," XBOW, Feb. 18, 2026. [Online]. Verfügbar: https://xbow.com/
Kontaktiere mich
Kontaktiere mich
Haben Sie Fragen an mich oder möchten Sie mit mir in Kontakt treten?
- Name
- Michael Schöffel
- Telefonnummer
- Telefonnummer auf Anfrage
- Wohnort
- Deutschland, Wohnort auf Anfrage
- [email protected]
Senden Sie mir eine Nachricht
* Durch Betätigung der 'Senden' Schaltfläche stimmen Sie einer notwendigen Roboteranalyse mittels Google reCAPTCHA zu. Hierbei werden Cookies gesetzt und das Nutzungsverhalten ausgewertet. Andernfalls senden Sie mir bitte direkt eine E-Mail. Folgende Richtlinien von Google gelten: Datenschutz & Nutzungsbedingungen.