/always-on-agent-architecture — Agenten bauen, die nie vergessen
Du entwirfst die Architektur für einen immer aktiven KI-Agenten mit episodischem Gedächtnis. Das ist kein Chatbot mit einem langen Kontextfenster. Das ist ein System, das Zustände über Sitzungen hinweg speichert, seine eigene Gedächtnishierarchie verwaltet, als Dienst läuft und seine Identität über Wochen und Monate bewahrt. Die Kernidee: Behandle das LLM wie eine CPU, die auf verwaltetem Speicher arbeitet, nicht wie eine zustandslose Funktion.
Entscheidungspunkte
Gedächtnisframework-Auswahlbaum
Q1: Möchtest du eine vollständige Agenten-Laufzeitumgebung (Server, APIs, Tools)?
├─ Ja → Verwende Letta (vollständigste, produktionsreife Lösung)
└─ Nein, ich habe meine eigene Agenten-Schleife
├─ Q2: Benötigst du zeitliche/Beziehungsverfolgung?
│ ├─ Ja → Verwende Zep/Graphiti (bestes temporäres Wissensgraph)
│ └─ Nein → Gehe zu Q3
│ ├─ Q3: Benötigst du einen Graph + Vektor-Hybrid?
│ │ ├─ Ja → Verwende Mem0 (Graph-Modus)
│ │ └─ Nein → Gehe zu Q4
│ │ ├─ Q4: Arbeitest du bereits mit LangGraph?
│ │ │ ├─ Ja → Verwende LangMem
│ │ │ └─ Nein → Verwende pgvector oder Chroma
└─ Null Abhängigkeiten gewünscht? → Benutzerdefiniertes SQLite + lokale Embeddings
Kernspeicher-Räumungsauslöser
| Auslöser | Schwelle | Aktion |
|---|---|---|
| Größenüberlauf | Kernspeicher > 4KB | Zusammenfassen des am wenigsten kürzlich verwendeten Blocks, Zusammenfassung ins Archiv verschieben |
| Altersabfall | Daten > 30 Tage ungenutzt | Für Komprimierungsüberprüfung markieren |
| Relevanzabfall | Zugriffsbewertung < 0.3 | Mit Verfallskennzeichnung ins Archivspeicher verschieben |
| Benutzerüberschreibung | Benutzer sagt "vergiss X" | Sofortige Entfernung + Archiv-Grabstein |
| Konflikterkennung | Widersprüchliche Fakten gespeichert | Agenten zur Abstimmung oder Benutzerfrage auffordern |
Vektordatenbank-Auswahlkriterien
Wenn query_latenzanforderung < 10ms UND datenmenge > 100M Vektoren:
→ Verwende Qdrant (für Geschwindigkeit optimiert)
Sonst wenn bereits_postgresql_im_einsatz:
→ Verwende pgvector (einzelne DB, einfachere Operationen)
Sonst wenn hybridsuche_benötigt (Stichwort + semantisch):
→ Verwende Weaviate (bester Hybrid)
Sonst wenn null_ops_bevorzugt:
→ Verwende Pinecone (vollständig verwaltet)
Sonst:
→ Verwende Chroma (lokal zuerst, einfache API)
Speicherstufen-Routing-Entscheidung
Eingabe: Benutzernachricht oder Agentenbeobachtung
│
├─ Enthält Identitäts-/Präferenzaktualisierung?
│ └─ Ja → Kernspeicher aktualisieren, sofort speichern
├─ Benötigt Gesprächskontext?
│ └─ Ja → Abrufspeicher durchsuchen (Gesprächsverlauf)
├─ Benötigt Faktenwissen?
│ └─ Ja → Archivspeicher durchsuchen (Vektorspeicher)
└─ Externe Daten benötigt?
└─ Ja → Externe Tools verwenden (APIs, Dateien usw.)
Fehlermodi
Speicherkorruptionskaskade
Symptome: Persönlichkeitsdrift des Agenten, widersprüchliche Antworten, Kernspeicherkonflikte Ursache: Gleichzeitige Schreibzugriffe auf den Kernspeicher ohne Sperrung, oder fehlgeschlagene Teilaktualisierungen Erkennungsregel: Wenn die Kernspeichergröße plötzlich um >50% abfällt oder fehlerhaftes JSON/YAML enthält Wiederherstellungsverfahren:
- Agent sofort stoppen, um weitere Korruption zu verhindern
- Kernspeicher aus dem letzten bekannten guten Backup (<1 Stunde alt) wiederherstellen
- Gesprächsprotokoll seit dem Backup wiedergeben, um verlorene Aktualisierungen zu rekonstruieren
- Schreibsperren für Kernspeicheraktualisierungen vor dem Neustart implementieren
Vektorsuche-Degradation
Symptome: Zunehmend irrelevante Suchergebnisse, Agent kann kürzlich gespeicherte Fakten nicht finden Ursache: Embedding-Modell-Drift, Index-Korruption oder keine Speicherkomprimierung Erkennungsregel: Wenn die durchschnittliche Kosinus-Ähnlichkeit der Top-3-Ergebnisse <0,7 für bekannte Abfragen beträgt Wiederherstellungsverfahren:
- Embedding-Konsistenzprüfung an einer Zufallsstichprobe von 100 Vektoren durchführen
- Wenn >10% anomale Embeddings aufweisen, gesamten Index neu aufbauen
- Embedding-Modell-Version-Pinning implementieren
- Embedding-Drift-Überwachung hinzufügen, um Wiederholung zu verhindern
Persistenzschicht-Verklemmung
Symptome: Agent hängt bei Speicheroperationen, Datenbankverbindungs-Timeouts Ursache: Gleichzeitiges Lesen/Schreiben auf denselben Speicherblöcken, unzureichendes Verbindungspooling Erkennungsregel: Wenn eine Speicheroperation >30s dauert oder die Datenbank Sperrwartezeit-Überschreitungen anzeigt Wiederherstellungsverfahren:
- Hängende Verbindungen beenden, um Sperren freizugeben
- Exponentiellen Backoff-Wiederholungslogik für Speicheroperationen implementieren
- Verbindungspooling mit maximalen Verbindungslimits hinzufügen
- Transaktionsisolationsstufen für Speicheraktualisierungen überprüfen
Kontextfenster-Explosion
Symptome: API-Kosten steigen, Antwortlatenz erhöht sich, Token-Limit-Fehler Ursache: Kernspeicher-Aufblähung, Abruf zu vieler Archivblöcke pro Abfrage Erkennungsregel: Wenn die durchschnittlichen Token pro Anfrage >80% des Modell-Kontextlimits betragen Wiederherstellungsverfahren:
- Kernspeichergröße prüfen – überdimensionierte Blöcke komprimieren oder archivieren
- Anzahl der Archivsuchergebnisse reduzieren (Standard 10 → 5)
- Token-Zählung vor LLM-Aufrufen implementieren
- Kostenüberwachungsbenachrichtigungen für >$1/Gespräch hinzufügen
Speicherleck - Unbegrenztes Wachstum
Symptome: Datenbankgröße wächst linear, Suchleistung verschlechtert sich mit der Zeit Ursache: Keine Speicherkomprimierung, doppelte Fakteneinfügung, fehlende Speicherbereinigung Erkennungsregel: Wenn die gesamte Speichergröße bei normaler Nutzung um >100MB/Monat wächst Wiederherstellungsverfahren:
- Fakten-Deduplizierung über den Archivspeicher durchführen (Kosinus-Ähnlichkeit >0,92)
- Gesprächszusammenfassung für Abrufspeicher >7 Tage alt implementieren
- Relevanzbewertung mit automatischem Beschneiden von niedrig bewerteten Speicherinhalten hinzufügen
- Wöchentliche Komprimierungsjobs planen
Arbeitsbeispiele
Beispiel: Bau eines persönlichen Forschungsassistenten
Szenario: Architektur für einen Agenten entwerfen, der bei technischer Recherche hilft, deine Vorlieben merkt und über Monate hinweg Wissen aufbaut.
Schritt 1 - Speicherstufen-Design
Kernspeicher (2KB):
- Benutzername: "Sarah"
- Forschungsdomänen: ["maschinelles Lernen", "verteilte Systeme"]
- Bevorzugte Paper-Quellen: ["arxiv", "acm digital library"]
- Schreibstil: "detailliert mit Codebeispielen"
- Aktuelles Projekt: "Optimierung des verteilten Trainings"
Abrufspeicher:
- Alle Gespräche in PostgreSQL mit Volltextsuche
- 30-tägiges Aufbewahrungsfenster, dann zusammengefasst
Archivspeicher:
- Paper-Zusammenfassungen, extrahierte Erkenntnisse, Code-Ausschnitte
- pgvector auf PostgreSQL (bereits für den Abruf verwendet)
- nomic-embed-text für lokale Embeddings (Datenschutz + Kosten)
Schritt 2 - Framework-Auswahlentscheidung Entscheidungsbaum folgend:
- Vollständige Agenten-Laufzeitumgebung benötigt? Nein (benutzerdefiniert)
- Zeitliche Verfolgung benötigt? Nein (Forschungserkenntnisse sind weitgehend zeitlos)
- Graph+Vektor benötigt? Nein (einfache semantische Suche ausreichend)
- Bereits auf LangGraph? Nein
- → Entscheidung: pgvector + PostgreSQL
Schritt 3 - Agenten-Schleifen-Implementierung
async def research_step(user_query: str):
# Kernspeicher laden
core = load_core_memory() # Benutzerpräferenzen, aktives Projekt
# Prüfen, ob die Abfrage mit dem aktuellen Projekt zusammenhängt
if "optimierung" in user_query.lower():
# Archiv nach projektspezifischem Wissen durchsuchen
relevant_papers = search_archival("Optimierung des verteilten Trainings")
context = f"Aktueller Projektkontext: {relevant_papers}"
else:
# Nach allgemeinem Bereichswissen suchen
context = search_archival(user_query)
# Prompt mit Kernspeicher + abgerufenem Kontext erstellen
system_prompt = f"""
Du bist Sarahs Forschungsassistent.
Benutzerpräferenzen: {core['preferences']}
Aktuelles Projekt: {core['current_project']}
Abgerufener Kontext: {context}
"""
response = await llm.chat([
{"role": "system", "content": system_prompt},
{"role": "user", "content": user_query}
])
# Interaktion speichern
save_to_recall(user_query, response)
return response
Was ein Anfänger übersehen würde:
- Rohe Paper anstelle von extrahierten Erkenntnissen im Archivspeicher ablegen
- Keine Gesprächssuche implementieren (Abrufspeicher)
- Zu viel in den Kernspeicher legen (Forschungsdomänen-Liste mit 50 Einträgen)
- Keine Speicherkomprimierungsstrategie
Was ein Experte erkennt:
- Kernspeicher konzentriert sich auf "arbeitende Identität", nicht auf Wissen
- Archivspeicher enthält kuratierte Fakten, keine Rohdokumente
- Implementiert Suche vor dem Abruf (Agent entscheidet, was relevant ist)
- Plant Speicherwachstum von Anfang an ein
Qualitätsgates
Checkliste für die Bereitstellungsvalidierung
- Speicherlatenz-SLO: Kernspeicher wird in <100ms geladen, Archivsuche wird in <500ms abgeschlossen
- Speicherkonsistenz: Kernspeicher überlebt Agentenneustart ohne Korruption (mit absichtlichem Kill testen)
- Suchrelevanz: Top-3-Archivergebnisse haben Kosinus-Ähnlichkeit >0,6 für bekannte Abfragen
- Speichergrößenregeln: Kernspeicher ≤4KB, Abrufspeicher-Aufbewahrung ≤30 Tage, Archivblöcke ≤1KB
- Persistenz-Dauerhaftigkeit: Alle Speicheraktualisierungen überleben Datenbank-Neustart (ACID-Konformität überprüft)
- Kostenkontrollen: Speicheroperationen kosten <$0,01/Gespräch bei 100 Gesprächen/Tag
- Komprimierungsplan: Speicherkomprimierung läuft wöchentlich und reduziert die Gesamtgröße um ≥10%
- Identitätskonsistenz: Die Persönlichkeit des Agenten bleibt über 50+ Gesprächssitzungen stabil
- Kaltstart-Wiederherstellung: Agent behandelt leeren Speicherzustand elegant (Onboarding-Ablauf funktioniert)
- Backup-Überprüfung: Speicher-Backup wird erfolgreich wiederhergestellt und bewahrt die Identität des Agenten
NICHT-FÜR-Grenzen
Verwende dieses Skill NICHT für:
- Trainingsdaten für Agenten auswählen → Verwende stattdessen
/always-on-agent-inputs– dieses Skill behandelt, welche Daten dem Agenten zugeführt werden, dieses hier behandelt, wie sie gespeichert und abgerufen werden - Brainstorming von Agentenanwendungen → Verwende stattdessen
/always-on-agent-applications– dieses Skill behandelt Ideenfindung für Anwendungsfälle, dieses hier behandelt die technische Implementierung - Sicherheit und Datenschutz von Agenten → Verwende stattdessen
/always-on-agent-safety– dieses Skill behandelt Daten-Governance, Einwilligung und Sicherheit; dieses hier setzt voraus, dass diese bereits entworfen sind - Allgemeine agentische Muster → Verwende stattdessen
/agentic-patterns– dieses Skill behandelt ReAct-Schleifen, Tool-Nutzung, Planung; dieses hier behandelt die darunterliegende Persistenzschicht - Einmalige Agentenaufgaben → Verwende stattdessen
/agent-creator– wenn der Agent sich nicht über Sitzungen hinweg erinnern muss, brauchst du keine Always-On-Architektur - Datenbankschema-Design → Dieses Skill setzt voraus, dass du grundlegende Datenbankkonzepte verstehst; verwende datenbankspezifische Skills für Schema-Optimierung
- Kostenoptimierungsstrategien → Dieses Skill erwähnt Kostenüberlegungen, taucht aber nicht tief in die Optimierung ein; delegiere an kostenspezifische Skills