Gedächtnis und Wissen
Wozu das Gedächtnis da ist
Abschnitt betitelt „Wozu das Gedächtnis da ist“Ohne Gedächtnis beginnt jedes Agentengespräch bei null: dieselbe Konvention muss neu erklärt, dieselbe Entscheidung neu ausgehandelt, dieselbe Sackgasse neu erkundet werden. Das Gedächtnis ist der Speicher auf Ebene des Arbeitsbereichs, der Läufe überdauert. Es ist dazu da, dass Wissen, das ein Agent erzeugt, später von einem anderen gefunden werden kann.
Es hat drei Schichten, und sie beantworten verschiedene Fragen:
- Fakten — was wahr ist (eine Konvention, ein Ergebnis, eine Entscheidung).
- Richtlinien — was Agenten damit tun müssen (eine normative Regel).
- Arbeitsgedächtnis — womit ein Agent gerade mitten drin war.
Die Unterscheidung ist wichtig, weil die Schichten den Agenten auf verschiedenen Wegen erreichen. Fakten werden gesucht. Richtlinien werden zugeschoben. Das Arbeitsgedächtnis ist privat.
Ein MemoryFact ist eine Wissenseinheit, begrenzt auf einen Arbeitsbereich und eine Domäne.
| Attribut | Was es ist |
|---|---|
domain |
Die Wissensdomäne (“conventions”, “decisions”, “codebase”) |
topic |
Eine kurze Themenbezeichnung |
content |
Der Wissenstext |
confidence |
0.0–1.0, aus der Herkunft gesetzt und durch erneute Erwähnung angehoben |
memoryType |
Die Art des Fakts — bestimmt seine zeitliche Zerfallskurve |
veracity |
Wie er bekannt wurde — setzt die Konfidenz und bemisst jeden Zuschlag bei erneuter Erwähnung |
sourceObservationIds |
Welche Beobachtungen zu ihm geführt haben |
supersededBy |
Der neuere Fakt, der ihn ersetzt hat, falls vorhanden |
validUntil, recallCount, mentionCount |
Ablauf und Nutzungssignale, die beim Abruf verwendet werden |
Die letzten beiden Zeilen übersiehst du leicht, und sie entscheiden, welcher Fakt auftaucht. memoryType trägt je Art Weibull-Zerfallsparameter, sodass eine befristete Zusage schnell verblasst, ein stabiler Profilfakt dagegen nicht. veracity hält die Herkunft fest — von einem Menschen geäußert (Gewicht 1.0), von einem Agenten erschlossen (0.7), von einem Werkzeug erzeugt (0.5), importiert (0.6) — und dieses Gewicht setzt die Startkonfidenz des Fakts.
Fakten werden bei einem Widerspruch nie an Ort und Stelle geändert. Das Schreiben eines Fakts lässt die Konflikterkennung gegen Fakten derselben Domäne und desselben Themas laufen und löst den unterlegenen ab, wobei eine Konfliktzeile festgehalten wird. Der Prüfpfad ist der Zweck: du siehst immer, was vorher geglaubt wurde und was es ersetzt hat.
Richtlinien
Abschnitt betitelt „Richtlinien“Eine MemoryPolicy ist eine normative Regel, abgeleitet aus Fakten, begrenzt auf einen Arbeitsbereich und eine Domäne, mit einem Aktiv-Kennzeichen und einer optionalen requiredRole.
Jede aktive Richtlinie im Arbeitsbereich wird in jede Ausführung injiziert, ungefiltert — ohne Filter nach Domäne, Rolle, Aufgabe oder Bereich. Das solltest du wissen, bevor du deine zwanzigste Richtlinie schreibst, denn Richtlinien konkurrieren mit der Aufgabe um dasselbe Kontextfenster. Deshalb ist requiredRole an einer Richtlinie nur ein Hinweis: sie beschreibt, an wen die Regel sich richtet, und sie hält die Regel nicht davon ab, alle anderen zu erreichen.
Domänen
Abschnitt betitelt „Domänen“Eine MemoryDomain gruppiert Fakten und Richtlinien innerhalb eines Arbeitsbereichs. Domänen geben dem Wissen eine organisatorische Struktur, und sie sind die Einheit, gegen die Grants geschrieben werden. Lies die Warnung unten, bevor du eine Domäne als Vertraulichkeitsgrenze behandelst.
Eine Domäne ist entweder arbeitsbereichsweit (architecture) oder auf ein Repository begrenzt (repo:<slug>/architecture). Derselbe Name in beiden Geltungsbereichen bezeichnet zwei unabhängige Speicher: ein Fakt, der für eine Codebasis gilt, überschreibt den arbeitsbereichsweiten nicht. search_memory und die Präambel der Ausführung stellen Gedächtnis mit Repo-Bezug nach vorn, wenn der Agent in diesem Repo arbeitet; den Rest blenden sie nicht aus. Übergib repo an propose_fact / propose_policy / search_memory, um in diesen Geltungsbereich zu schreiben oder ihn anzuheben.
Die Zugriffskontrolle erlaubt Lesezugriffe im Zweifel
Abschnitt betitelt „Die Zugriffskontrolle erlaubt Lesezugriffe im Zweifel“MemoryAccessGrant ordnet einer Agentenrolle und einer Domäne eine von drei Berechtigungsstufen zu:
| Berechtigung | Bedeutung |
|---|---|
none |
Kein Zugriff |
read |
Kann Fakten suchen und abrufen |
write |
Von propose_policy verlangt. Schreibvorgänge an Fakten (propose_fact, supersede_fact) hängen nicht an einem Grant |
Die Asymmetrie — weich beim Lesen, hart beim Schreiben von Richtlinien — ist ein bewusster Tausch. Gedächtnis nützt am meisten, wenn es zirkuliert, und eine verweigerte Lesung erzeugt einen Agenten, der still weniger weiß, statt einen, der ein Problem meldet. Eine verweigerte Richtlinien-Schreibung ist laut und lässt sich korrigieren, deshalb sitzt die Durchsetzung dort. Eine neu angelegte Domäne vergibt write an jede Rolle; sie danach enger zu fassen ist eine Änderung nur über RPC, weil es keine Grant-Oberfläche gibt.
Arbeitsgedächtnis
Abschnitt betitelt „Arbeitsgedächtnis“Jeder Agent hat ein AgentWorkingMemory: einen Freitext-Notizblock, dessen Schlüssel Arbeitsbereich und Agent sind. Er bleibt über Läufe hinweg erhalten, ist für diesen Agenten privat und wird bei jeder Ausführung in seinen Prompt injiziert. Hier lebt „Ich war mitten im Refactoring der Authentifizierung“ — der Zustand, den der nächste Lauf mitnehmen soll, der aber kein dauerhafter Fakt werden muss.
Was tatsächlich im Prompt eines Agenten ankommt
Abschnitt betitelt „Was tatsächlich im Prompt eines Agenten ankommt“Bei der Ausführung setzt sich die Gedächtnis-Präambel aus genau drei Teilen zusammen:
- Jede aktive Richtlinie des Arbeitsbereichs, als Zeilen
- [domain] rule. - Das eigene Arbeitsgedächtnis des Agenten, wortgetreu.
- Eine per Schlüsselwort getroffene Kurzliste von Fakten für diese Aufgabe — höchstens fünf, im Rahmen von etwa 1.200 Zeichen und nur, wenn die Aufgabenbeschreibung mindestens 20 Zeichen lang ist. Kürzere Aufgaben erhalten keine Fakten.
Die Kurzliste arbeitet nur mit FTS und Schlüsselwörtern und ist absichtlich begrenzt. Eine Anfrage in ein Embedding zu überführen ist langsam, und auf dem Ausführungspfad ist Latenz sofort sichtbar, deshalb bleibt der langsame semantische Pfad dort bewusst außen vor. Die Präambel schließt mit der Anweisung an den Agenten, tragende Punkte mit search_memory zu prüfen. Dort liegt das volle Abrufmodell.
Auf diesem Pfad wird keine Zugriffsberechtigung gelesen. Was die Kurzliste findet, das sieht der Agent.
Abruf: eine Anfrage, vier Stimmen
Abschnitt betitelt „Abruf: eine Anfrage, vier Stimmen“Das Werkzeug search_memory, das der Agent sieht, hat drei Modi, und das sind wirklich verschiedene Suchen:
keyword— nur FTS5.semantic— BM25- und Vektorergebnisse, per Reciprocal Rank Fusion zusammengeführt.hybrid(die Voreinstellung) — polyphoner Abruf: vier gereihte Stimmen, zusammengeführt und danach diversifiziert.
Die vier Stimmen sind lexikalisch (FTS), semantisch (Vektor-KNN), zeitlich (kürzlich aktive Fakten) und der Graph — ein Gang über zwei Hops entlang episodischer Kanten, ausgehend von den stärksten lexikalischen und semantischen Startpunkten. Die Graph-Stimme ist der Grund, warum es episodische Kanten überhaupt gibt: sie holt den Fakt nach oben, der mit deiner Antwort verbunden ist, ohne eines deiner Wörter zu treffen. Die Stimmen werden nach einer klassifizierten Absicht der Anfrage gewichtet (semantisch trägt standardmäßig am meisten, danach Graph und lexikalisch, dann Aktualität), die Punktzahl jedes Kandidaten wird mit seinem Weibull-Zerfall skaliert, und die Ergebnismenge wird per MMR diversifiziert, damit fünf Neuformulierungen eines Fakts nicht vier andere verdrängen.
Die Gedächtnissuche auf Desktop und im Web ist ein eigener, einfacherer Pfad: die RPC-Operation memory_fact.search ist nur FTS5, weil ein dünner Client kein Anfrage-Embedding mitschicken kann und der hybride Pfad im Host bleibt. Die Reihenfolge, die du im Gedächtnisbrowser siehst, ist deshalb eine andere als die, die ein Agent von search_memory erhält. Das ist vorgesehen. „Ich habe gesucht und es nicht gefunden“ in der Oberfläche belegt nicht, dass der Agent es nicht findet.
Wo das Gedächtnis liegt und wer es schreibt
Abschnitt betitelt „Wo das Gedächtnis liegt und wer es schreibt“Der Gedächtnisbrowser liegt unter Einstellungen → Arbeitsbereich → Gedächtnis
(/workspaces/<id>/settings/memory), mit den Reitern Fakten, Richtlinien und Wissensgraph.
Dort gibt es eine Asymmetrie, die überrascht: Gedächtnis lässt sich bearbeiten und löschen. Anlegen lässt es sich nicht. Weder der Reiter Fakten noch der Reiter Richtlinien bietet eine Aktion zum Hinzufügen. Verfasst wird auf der Seite des Agenten, über propose_fact und propose_policy (supersede_fact / supersede_policy zum Ersetzen). remember schreibt einen auf die Sitzung begrenzten Eintrag der heißen Stufe, den consolidate_memory später zu einem Fakt befördern kann; record_observation und update_my_notes schreiben den privaten Notizblock, der bei der Ausführung injiziert wird. Der Browser dient dem Prüfen und Korrigieren. Einen Fakt legst du an, indem du es einem Agenten sagst.
Zwei Wartungsoperationen ruft ebenfalls der Agent auf, ein Zeitplan tut es nicht: consolidate_memory führt angesammelte Fakten zusammen und lichtet sie, und harmonize_memory gleicht Überzeugungen ab, die zwischen Agenten auseinanderlaufen. list_memory_conflicts zeigt, was die Konflikterkennung bereits festgehalten hat. Nichts startet sie für dich zeitgesteuert. Entscheidungen aus Besprechungen landen in der Domäne decisions, wenn ein Persistenzschritt der Besprechung sie festhält; das ist kein Zeitplan über abgeschlossene Agentenläufe.
Verwandte Konzepte
Abschnitt betitelt „Verwandte Konzepte“- Das Agentenmodell: Rollen sind das, worauf Grants geschrieben werden
- Arbeitsbereiche und Isolation: das Gedächtnis gilt für einen Arbeitsbereich und liegt in der eigenen Datenbankdatei dieses Arbeitsbereichs
- Arbeitsbereichs-Gedächtnis verwalten: mit dem Gedächtnis in der Praxis arbeiten