# Braucht ein Agent ein eigenes Gedächtnis, wenn der Engineering-Kontext schon in GitHub liegt? > Canonical: https://vxi.me/de/posts/beacon-local-memory-capture-causality/ > Locale: de-de > Published: 2026-10-27 > Updated: 2026-10-27 > Markdown: https://vxi.me/de/posts/beacon-local-memory-capture-causality.md

Beide öffentlichen Testsuiten bestanden; beide unabhängigen Hidden-Checks scheiterten. Der Geltungsbereich ist ein plausibler Hinweis, keine bewiesene Ursache.

Die ersten beiden Beiträge dieser Reihe behandelten [GitHub-first-Übergaben](https://vxi.me/posts/github-first-ai-coding-context-handoff-workflow/) und die [Grenze zwischen Local-first und GitHub-first](https://vxi.me/posts/local-first-vs-github-first-architecture/). Nun bleibt die Frage: Was bringt ein separates Agent Memory, wenn der Engineering-Kontext bereits im Repository liegt? Meine Kurzfassung: **Führe keine zusätzliche Memory-Schicht ein, nur weil du dir davon schnelleres Coden versprichst.** Was ein Agent aus README, AGENTS.md, Makefile und Tests ableiten kann, gehört dorthin. Ein separates Gedächtnis ist eher für historische Entscheidungen interessant, die das aktuelle Repository nicht mehr erklärt. In diesen drei Experimentrunden funktionierte der Abruf über Harness-Grenzen tatsächlich; die unabhängige Abnahme der Consumer-Aufgabe verbesserte sich dadurch aber nicht. ## Was das Repository schon weiß, ist kein Verdienst des Memory Runde eins lief mit Beacon 1.3.46 (Build `f8177a68`) und Codex CLI 0.162.1 auf macOS arm64 mit Local Endpoint. Das synthetische Projekt enthielt eine API-Definition, ein README zum eingecheckten generierten Code, ein Makefile-Ziel und Tests auf Konsistenz. Zunächst sah es so aus, als scheitere die speicherlose Kontrollgruppe A0, während der Beacon-Pfad 3/3 Tests bestand. Die Nachprüfung zeigte jedoch zwei Störfaktoren: A0 lief in einer schreibgeschützten Sandbox und konnte keine Dateien ändern; außerdem verriet die erste Fehlermeldung das Ziel `make gen`. Das ist keine gültige Kontrolle und kein Beleg für einen Memory-Effekt. In Runde zwei war die Sandbox beschreibbar und der Hinweis entfernt. A0 ohne Gedächtnis las README, Makefile und Tests, leitete die Generierungsregel ab und bestand den Test mit 1/1. Ich strich die Behauptung, Memory habe die Wiederverwendung der Repository-Regel verursacht. Wenn die Antwort bereits im Repository steht, sollte Memory dafür nicht den Ruhm bekommen. | Experiment | Beobachtung | Zulässige Schlussfolgerung | |---|---|---| | Runde 1: A0 / Beacon | A0-Kontrolle ungültig; genehmigter Beacon-Kandidat wurde als Skill materialisiert und in neuer Sitzung gelesen, danach 3/3 bestanden | Kein kausaler Memory-Nutzen ableitbar | | Runde 2: A0 ohne Memory | Regel aus dem Repository abgeleitet; 1/1 bestanden | Repository-Information reichte für diese Aufgabe | | Manueller Checkpoint | `CHECKPOINT.md` gelesen; 2/2 bestanden | Explizite, versionierte Übergabe funktioniert ebenfalls; kein fairer Zeitvergleich | | Runde 3 Training | TSV-Tests 3/3 PASS, Hidden-Check des Controllers PASS | Kein Beleg für automatische Destillation oder Cross-Harness-Wiederverwendung | | Runde 3 Consumer | Antigravity A0 und MCP: CSV-Tests jeweils 3/3 PASS, Hidden-Checks beide FAIL | Abruf fand statt, Aufgabenverbesserung nicht belegt | Die Runden nutzten unterschiedliche synthetische Fixtures. Die Werte 1/1, 2/2, 3/3 und 4/4 sind keine gemeinsame, wachsende Testsuite. ## Checkpoint und Agent Memory erfüllen unterschiedliche Aufgaben Ich habe Laufzeit und Tokenverbrauch von manuellem Checkpoint und Beacon nicht nach derselben Methode gemessen; auch die Korrekturschritte unterschieden sich. Nachträglich vergleichbare Zahlen zu erfinden wäre Scheingenauigkeit. Der technische Unterschied bleibt klar: Ein Checkpoint ist eine sichtbare Übergabe, die mit Git versioniert und geprüft werden kann. Agent Memory ähnelt einem automatisch geführten Notizbuch. Es bewahrt Entscheidungsgründe, kann aber ebenso veraltete Entscheidungen konservieren. | Wissen | Bevorzugter Ort | Separates Memory? | |---|---|---| | Aktuelle Regeln, Build-Schritte und Invarianten | README, AGENTS.md, Makefile, Tests | Meist nein; das Repository bleibt maßgeblich | | Fortschritt, geprüfter SHA, Blocker, nächster Schritt | Issue, PR, Checkpoint, CI | Nur bei einer echten Lücke beim Sitzungswechsel | | Historische Entscheidung, die im Repo fehlt | Prüfbare Entscheidungsnotiz oder genehmigtes Memory | Möglich, mit Quelle und Geltungsbereich | | Geänderte Regeln und Ausnahmen | Repository aktualisieren und alte Regel außer Kraft setzen | Nicht einfach immer neue Memories anhängen | | Kontext, der eine Datengrenze nicht verlassen darf | Innerhalb der genehmigten lokalen Grenze | Nicht allein fürs Erinnern in die Cloud kopieren | ## Runde drei: Memory gelesen, Aufgabe trotzdem nicht bestanden Diese Runde prüfte eine historische Kompatibilitätsregel, die sich nicht aus dem aktuellen Repository ableiten ließ: Beim CSV- und TSV-Export soll Python-`None` als wörtliches `\N` serialisiert werden; leere Strings bleiben leer und der String `NULL` bleibt unverändert. Der Codex-Trainings-Trace wurde als Kandidat geprüft, genehmigt und materialisiert. Danach las Antigravity das freigegebene Memory über Beacon Local MCP. Die lokale Ausführungszusammenfassung verzeichnete einen Aufruf von `get_memory` und zwei Aufrufe von `search_memory`. Das belegt den Abruf in diesem Lauf, nicht die erfolgreiche Wiederverwendung. | Antigravity-Consumer | Memory gelesen? | Öffentliche CSV-Tests | Unabhängiger Hidden-Check | |---|---|---|---| | A0 ohne Memory | Nein | 3/3 PASS | FAIL | | MCP mit Memory | Ja | 3/3 PASS | FAIL | Der wichtigste Hinweis ist ein Konflikt beim Geltungsbereich. Der Memory-Text erwähnt CSV und TSV, aber die `applicability`-Metadaten nennen nur `render_tsv` beziehungsweise TSV-Kompatibilität. Laut Ausführungszusammenfassung behandelte Antigravity beide Exportfunktionen als getrennte Implementierungen und übertrug die TSV-Regel deshalb nicht auf CSV. Das ist eine starke Erklärung, aber keine bestätigte alleinige Ursache: Der Hidden-Checker lieferte nur ein Gesamt-FAIL und keine konkrete fehlgeschlagene Assertion. Da beide Consumer-Gruppen scheiterten, beweist das Ergebnis auch nicht, dass Memory die Aufgabe verschlechtert hat. Pro Gruppe gab es nur eine synthetische Aufgabe; die zugrunde liegenden Modelleinstellungen wurden nicht als kontrollierter Vergleich dokumentiert. Nach dem FAIL die Applicability von Hand so lange zu erweitern, bis PASS erscheint, würde nicht natürliche Wiederverwendung historischer Erinnerung testen, sondern meine Fähigkeit, Memory anhand der Antwort zu optimieren. Ich habe deshalb gestoppt, statt ein Happy End zu konstruieren. ## Veraltete Erinnerung, lokale Logs und Quellgrenzen In einem separaten Fixture wurde das Makefile-Ziel von `gen` auf `generate` geändert, während ein alter Skill weiterhin `make gen` verlangte. Der Agent stieß auf den Fehler, las das Makefile erneut, wechselte zu `make generate` und bestand 4/4 Tests. Der alte Skill blieb bestehen. Das zeigt, dass ein Agent sich durch Prüfung aktueller Repository-Fakten erholen kann; es zeigt nicht, dass Beacon alte Memories automatisch aktualisiert oder ausmustert. Im lokalen Runtime-Log erschien der synthetische Marker `PLUMOTTER9917` wörtlich; die Zahl passender Zeilen stieg von 7 auf 25. Der Token-ähnliche Canary `sk-canaryfake` stieg von 0 auf 4, `REDACTED` von 1 auf 6. Ich habe die vier Canary-Zeilen nicht geprüft und kann deshalb nicht sagen, ob sie den Testwert, ein verbliebenes Präfix oder protokollierten Such-/Testtext enthalten. Das Redaktionsergebnis bleibt unklar. Beacon Cloud war nicht verbunden; lokale Logs belegen keine Cloud-Weiterleitung. Die Quellprüfung war auf [Beacon-Commit d7a3a72](https://github.com/Asymptote-Labs/agent-beacon/tree/d7a3a72fdc0a864655cf2e85fb7de5ba974cde72) fixiert. Die [Redaktionslogik](https://github.com/Asymptote-Labs/agent-beacon/blob/d7a3a72fdc0a864655cf2e85fb7de5ba974cde72/pkg/asymptoteobserve/privacy.go#L322-L395) stützt sich auf Feldnamen und bekannte Muster, nicht auf eine universelle Erkennung beliebiger Geheimnisse in natürlicher Sprache. In der geprüften Snapshot-Version fand sich in der Codex-Erfassungsmatrix und im OTLP-Konverter keine Zuordnung für Codex-File/MCP-Ereignisse. Das war eine Quellprüfung, kein Laufzeit-Paketmitschnitt. Auch Jevs Evaluator wurde nur im Quellcode geprüft, nie ausgeführt; es gibt daher weder Scores noch gemessene Destillationsgenauigkeit. ## Memory soll Lücken im Repository füllen, es nicht duplizieren Die Experimente belegen weder eine allgemeine Wirksamkeit von Agent Memory noch seine völlige Nutzlosigkeit. Aktuelle, testbare Fakten gehören ins Repository; explizite Übergaben in einen Checkpoint; nur historische Entscheidungen, die im Repo fehlen, kommen als separates Memory infrage—mit Quelle und Geltungsbereich. Veraltete Memories müssen auffindbar, begrenzbar und stilllegbar sein. Lokale Logs, MCP, gehostete Evaluierung und Cloud-Weiterleitung sind getrennt zu prüfen. Das Fazit ist schlicht: **Cross-Harness-Abruf wurde bestätigt; ein zusätzlicher Aufgaben-Nutzen nicht.** Der nächste sinnvolle Versuch würde die versteckte Assertion offenlegen und reproduzierbare kontrollierte Aufgaben nutzen, statt nach einem Fehlschlag die Metadaten manuell passend zu machen. Experimentdaten: Runde eins und zwei am 26. Oktober 2026; der Antigravity-MCP-Consumer-Test am 27. Oktober 2026.