Gib deinen KI-Agenten ein dauerhaftes Gedächtnis: Das LLM-Wiki-Pattern in Symfony

Um diese chronische Amnesie zu heilen, ohne direkt schwere RAG-Pipelines (Retrieval-Augmented Generation), komplexe MCP-Server aufzusetzen oder dich auf proprietäre Cloud-Chat-Verläufe zu verlassen, gibt es einen einfachen, universellen und unglaublich effektiven Ansatz: die Kombination einer globalen AGENTS.md-Konfiguration mit dem LLM Wiki-Pattern. Dieses Konzept wurde von Andrej Karpathy popularisiert, dem ehemaligen KI-Direktor bei Tesla und Mitgründer von OpenAI.

Die Falle des Einweg-Kontexts in der PHP-Entwicklung

Wenn du einen KI-Agenten bittest, eine Komponente zu implementieren – zum Beispiel ein Caching-System für einen externen HTTP-Client –, ist dein erster Reflex meist, einen riesigen, detaillierten Prompt zu schreiben. Ohne bestehenden Kontext musst du die PHP-Version, die Regeln zur Dependency Injection, die gewählte Symfony-Cache-Komponente (cache.app, Redis, ein Custom-Adapter) und die Struktur deiner PHPUnit-Tests angeben.

Wenn man das mit Dutzenden von täglichen Interaktionen multipliziert, leidet die Produktivität massiv. Das Ziel ist es, dem Agenten ein dauerhaftes, portables Gedächtnis zu geben, das völlig unabhängig vom zugrunde liegenden LLM-Modell ist.

Schritt 1: Instruktionen strukturieren mit einer zweistufigen AGENTS.md

Das Dateiformat AGENTS.md hat sich schnell als unumgänglicher Standard etabliert, um Coding-Assistenten direkt von der Root deines Repos aus anzuleiten. Es definiert deinen Stack, deine Test-Befehle und die Richtlinien deines Teams. Diese Datei jedoch strikt auf Projektebene zu halten, löst das Problem deines eigenen, persönlichen Entwickler-Kontexts nicht.

Der erste Schritt besteht darin, zwei verschiedene Ebenen von Instruktionen zu nutzen:

• Die Projektebene (./AGENTS.md): Spezifisch für die Symfony-App, an der du gerade arbeitest. Sie enthält Projektkonventionen, Sprachpräferenzen, CI/CD-Regeln des Teams usw.

Zum Beispiel: 

## Stack
- Symfony 7, PHP 8.3, Doctrine, Twig, PostgreSQL.

## Conventions
- Schlanke Controller, Logik bleibt in autowired Services.
- Doctrine-Migrations; niemals schema:update nutzen.

## Qualität
- Alles über das Makefile ausführen: make test, make stan.
- PHPStan Level 8, php-cs-fixer. Null Warnungen.

• Die Benutzerebene (die globalen Instruktionsdateien deiner Agenten): Geteilt über all deine Projekte. Jeder Agent hat seinen eigenen Einstiegspunkt: ~/.codex/AGENTS.md, ~/.claude/CLAUDE.md oder ~/.gemini/GEMINI.md.

Hier definierst du deine persönlichen Präferenzen. Zum Beispiel: PHP-8-Attribute nutzen, Strict Types erzwingen (declare(strict_types=1)), Git-Konventionen oder die Anforderung, dass der Agent vor destruktiven Datenbankbefehlen wie doctrine:schema:drop um Bestätigung bittet.

## Über mich
- Clément, Tech Lead. Antworte mir auf Französisch.

## Default (Überall)
- Code und Dokumentation auf Englisch schreiben.
- PHP/Symfony, einfacher Monolith. PHPStan Level 4 Minimum.
- Niemals ohne mein grünes Licht zu Git pushen.

Das Beste daran? Diese Dateien können alle symbolische Links (Symlinks) sein, die auf eine einzige Quelldatei verweisen, die du nur ein einziges Mal pflegen musst:

➜  ls -l ~/.codex/AGENTS.md ~/.claude/CLAUDE.md ~/.gemini/GEMINI.md

/Users/cb/.claude/CLAUDE.md -> /Users/cb/.config/AGENTS.md
/Users/cb/.codex/AGENTS.md  -> /Users/cb/.config/AGENTS.md
/Users/cb/.gemini/GEMINI.md -> /Users/cb/.config/AGENTS.md

Allerdings stößt du schnell an eine technische Grenze: das Kontextfenster. Das ist die begrenzte Menge an Daten, die eine KI in ihrem aktiven Gedächtnis halten kann, um Anfragen zu verarbeiten und zu beantworten. Anthropic und OpenAI empfehlen, diese AGENTS.md-Dateien unter 200 bis 300 Zeilen zu halten, um eine Sättigung des Modells oder das Risiko von Halluzinationen durch eine Überflutung mit Instruktionen zu vermeiden.

Schritt 2: Skalieren mit dem LLM-Wiki-Pattern

Um eine größere Wissensmenge zu speichern, ohne deine Hauptinstruktionsdatei zu überladen, hat Karpathy das LLM Wiki-Pattern formalisiert.

Die Kernidee ist einfach: Baue eine Markdown-basierte Wissensdatenbank auf, die wie ein Wiki strukturiert ist, lokal gespeichert wird und vom Agenten selbst gepflegt und referenziert wird. Keine neuen Tools zu installieren – nur eine saubere Ordnerstruktur mit Textdateien, die du mit Git tracken kannst.

Dieses Pattern funktioniert wunderbar für ein Symfony-Projekt und ist ebenso mächtig für die persönliche Wissensdatenbank eines Entwicklers. Es kann wie folgt organisiert sein:

~/knowledge/

├── projects/      # App-Kontexte (ProjektA, API-Core, Legacy-App)

├── tech/          # PHP 8 Konventionen, Symfony Best Practices, Test-Patterns

├── people/        # Kontakte, Teammitglieder, Rollen der Stakeholder

├── index.md       # Globale Map und Einstiegspunkt

└── log.md         # Datierter, von der KI verwalteter Changelog

Beispiel für index.md

# Personal Knowledge Index

Durable personal base, maintained as a lightweight LLM Wiki-style knowledge layer. **Do not load the whole directory** -- read this index, then open only the files relevant to the question.

## Profile
- `profile/about-me.md` -- who I am, background, side projects.
- `profile/roles-and-context.md` -- SensioLabs roles, client missions, mandates, durable context.

## Projects
- `projects/index.md` -- map of local projects and repositories, mostly under `~/Sites/`.

## People
- `people/contacts.md` -- durable professional relationship context, contact importance signals, and domain heuristics for calendar/mail prioritization.

## Tech
- `tech/php-symfony-style.md` -- durable PHP/Symfony preferences, patterns I like/refuse, architectural posture.
- `tech/code-review-preferences.md` -- recurring review criteria.
- `tech/makefile-task-runner.md` -- preference for self-documented Makefiles as project task runners and operational maps.
- `tech/docs-methodology.md` -- index of documentation surfaces (ADR, plans, audits, wiki, handoffs, articles) and where each goes; read this first, it points to the richer plan doc below.
- `tech/agent-executable-plans.md` -- global convention for where to store agent execution plans, how to number them, and how to track them with lightweight indexes.
- `tech/agentic-tools.md` -- cross-project inventory of agent-accessible tools, integrations, MCP endpoints, and usage conventions.
…

Orchestration: On-Demand-Injektion

Damit deine Assistenten dieses lokale Wiki nutzen, brauchst du nur eine einzige Zeile in deiner ~/.config/AGENTS.md-Datei:

- Durable personal context: `~/knowledge/` (read the index before opening anything else).

Beim Start einer neuen Session liest der Agent zuerst den Wiki-Index (~/knowledge/index.md). Betrachte diesen Index wie eine Routing-Tabelle. Je nach deiner aktuellen Aufgabe lädt der Agent nur die zwei oder drei Dateien, die er tatsächlich benötigt, anstatt seinen Arbeitsspeicher mit dem gesamten Ordner zu verstopfen.

Ein weiterer großer Vorteil liegt in der Pflege. Nach einer tiefgehenden Refactoring-Session oder beim Festlegen eines komplexen Architektur-Fixes kann der Agent das relevante Tech-Dokument in ~/knowledge/tech/ selbst aktualisieren und die Änderung in log.md eintragen. Du behältst die volle Kontrolle über einfache Git-Commits.

In der Praxis: Die Macht minimalistischer Prompts

Sobald dieses Setup steht, ändert sich die Art und Weise, wie du Prompts schreibst, komplett. Ein super prägnanter Prompt wird von deinem Assistenten nun perfekt verstanden:

Dank der automatischen Suche in deinem lokalen Wiki kann der Agent jeden Kontext auflösen. Er findet für jedes Element in der Eingabeaufforderung den entsprechenden Kontext in der angegebenen Datei:

🔵 Project1/Project2 -> knowledge/projects/index.md

🟢 Symfony preferences -> knowledge/tech/php-symfony-style.md

🟡 todo -> knowledge/todo/index.md

🟣 my CTO -> knowledge/people/contacts.md

🔴 Jira -> Geteilte Konfiguration, Skills und MCP-Endpoints

Ein maßgeschneidertes Gedächtnis für saubereren Code

Durch die Kombination der Klarheit einer globalen AGENTS.md-Datei mit der Flexibilität des LLM-Wiki-Patterns gibst du deinen Coding-Assistenten ein echtes Langzeitgedächtnis, ohne die Souveränität deiner Daten zu gefährden.

Dieser Ansatz passt perfekt zur Philosophie von Einfachheit und Wartbarkeit des Symfony-Ökosystems: keine Blackboxen, keine versteckten Abhängigkeiten – nur versionierter Klartext, der für Menschen lesbar und bereit für jedes aktuelle oder zukünftige LLM ist.