# Self-Exploration & Rekombinatorische Kreativität bei LLMs

Recherche + Design-Überlegungen. August 2026.

---

## Teil 1: Recherche (2023–2026)

### 1.1 Autonome, selbstgesteuerte LLM-Agenten

**Voyager** (Wang et al., 2023, arXiv:2305.16291, NVIDIA)
Das Referenzsystem für offene Exploration. LLM-Agent in Minecraft, der ohne vorgegebene Quests eigenständig Ziele ableitet („finde bessere Ausrüstung"), Code schreibt, und eine wachsende **Skill-Library** pflegt — verifizierte JavaScript-Funktionen, die in späteren Tasks wiederverwendet werden. Kernmechanismus: Curiosity-Loop aus (1) auto-generierter Chained Goal, (2) Code-Synthesis, (3) Self-Verification, (4) Skill-Speicherung. Voyager bleibt auch nach wochenlangem Training produktiv — die Skill-Library ist das Substrat, das Kumulation ermöglicht.

**Gödel Agent** (Yin et al., 2024, arXiv:2410.04444)
Selbstreferenzielles Framework: Der Agent bearbeitet nicht nur Aufgaben, sondern auch seine eigene Spezifikation. Formalisiert als Gödel-Maschine — das System kann seine eigene Codebasis als Objekt behandeln und modifizieren. Zeigt, dass recursive self-improvement prinzipiell darstellbar ist, aber in der Praxis an der **Verifikationslücke** scheitert (siehe 1.3).

**WorldLLM** (Levy, Colas, Oudeyer, Carta, 2025, arXiv:2506.06725)
Curiosity-driven Theory-Making: Das LLM bildet Theorien über seine Umwelt, generiert Vorhersagen, und wird durch **Vorhersagefehler** getrieben — nicht durch externe Belohnung. Wichtig für Self-Exploration: Der Antrieb entsteht aus dem Delta zwischen Erwartung und Beobachtung.

**LLM-POET** (Aki et al., 2024, arXiv:2406.04663)
Evolutionäre LLM-Umgebungen: Der LLM ist nicht nur Akteur, sondern **Umweltgestalter** — er modifiziert die Regeln der Umgebung, in der er agiert. Co-Evolution von Agent und Environment.

**Kritisches Negativ-Ergebnis:**
„Agents Explore but Agents Ignore: LLMs Lack Environmental Curiosity" (Engländer, Althammer, Üstün, Gallé, 2026, arXiv:2604.17609)
LLMs explorieren, wenn sie dazu aufgefordert werden — aber sie zeigen **keine intrinsische Neugier**. Ohne expliziten Prompt „erklöre X" ignorieren sie relevante Umweltreize. Konsequenz: Curiosity muss **architektonisch eingebaut** werden, nicht vom Modell erwartet.

**Goal-Evolving Agents** (Du et al., 2025, arXiv:2512.21782)
Autonome Agenten, die ihre eigenen Forschungsziele generieren, priorisieren, und iterativ verfeinern — angewandt auf wissenschaftliche Discovery. Zeigt, dass Goal-Generation aus Beobachtung funktioniert, wenn ein Evaluation-Loop existiert.

### 1.2 LLM-Kreativität: Genuin oder Rekombination?

**Konsens der Forschung:** LLMs sind **rekombinatorisch kreativ** — sie kombinieren existierende Konzepte zu neuen Konfigurationen. Ob das „genuin" ist, hängt von der Definition ab.

- **Jiang et al. 2024** (arXiv:2402.06647): Halluzination und Kreativität sind zwei Seiten derselben Medaille — beides ist Extrapolation jenseits des Trainingsdatensatzes. Die Grenze ist fließend.
- **Chakrabarty et al. 2023** (arXiv:2309.12570): LLMs als Kreativitäts-Unterstützung funktionieren am besten im **Divergent-Convergent-Loop**: LLM generiert viele Varianten, Mensch (oder Evaluation-Funktion) selektiert.
- **Lin et al. 2025** (arXiv:2505.21116): Multi-Agent-Systeme erzeugen mehr kreative Output als Single-Agent — durch **perspektivische Diversität** (verschiedene Prompts/Personas generieren unterschiedliche Rekombinationen).
- **Luo et al. 2026** (arXiv:2603.19519): Sustained Creativity erfordert **Diversitäts-Erhaltungsmechanismen** — ohne explizite Novelty-Selektion kollabiert der Output-Space nach wenigen Iterationen auf Stereotype.
- **Dong & Yakura 2026** (arXiv:2607.26899): **Menschliche Diversität** treibt kollektive Kreativität, die LLMs nicht simulieren können. Ein einzelnes LLM hat einen begrenzten „kreativen Raum" — Diversität muss von außen kommen (mehr Modelle, mehr Perspektiven, echte Umwelt-Daten).

**AI Co-Scientist** (Google DeepMind, Gottweis et al., 2025, arXiv:2502.18864)
Mehrschichtiger Agent, der wissenschaftliche Hypothesen generiert, evaluiert, und iterativ verfeinert. Wichtig: Die Hypothesen sind **rekombinatorisch** (bekannte Konzepte, neue Kombinationen), aber in einigen Fällen **neu für die Wissenschaft** — d.h. Rekombination ≠ Trivialität, wenn der Kombinationsraum groß genug ist.

**AI Scientist** (Lu, Lange, Foerster, Clune, 2024, arXiv:2408.06292; v2: Yamada et al., 2025, arXiv:2504.08066)
Vollautomatischer Forschungs-Agent: Idee → Experiment → Paper. Die generierten Papers passieren Peer-Review-Filter in ~20% der Fälle. Kreativität ist hier **prozessgetrieben** (Suchraum-Exploration), nicht „inspiriert".

### 1.3 Self-Improving Systeme

**Darwin Gödel Machine** (Zhang, Hu, Lu, Lange et al., 2025, arXiv:2505.22954)
Existiert und ist verifiziert. Evolutionäres Self-Improvement: Der Agent erzeugt Mutationen seiner eigenen Codebasis, evaluiert sie in einer Sandbox, und behält die besseren Versionen. **Populationsbasiert** — nicht ein Agent verbessert sich, sondern eine Population von Agent-Varianten wird selektiert.

**AlphaEvolve** (Novikov, Vũ, Eisenberger, Dupont et al., 2025, arXiv:2506.13131, DeepMind)
LLM-gesteuerte evolutionäre Suche über Code. Hat konkrete Ergebnisse geliefert: bessere Matrixmultiplikations-Algorithmen, verbesserte Scheduling-Algorithmen für Google-Infrastruktur. Kern: LLM als **Mutation-Operator** in einem evolutionären Loop mit harter Evaluation.

**Kritische Gegenarbeiten:**
- **Ye et al. 2026** (arXiv:2608.18066): „On the Fragility of Self-Improving Agents" — Self-Improvement ist extrem fragil. Kleine Fehler in der Self-Modification kaskadieren. Ohne externe Verifikation kollabiert das System.
- **Guo et al. 2026** (arXiv:2607.24300): „Self-Authored Verification Is Unreliable" — Ein Agent kann seine eigene Arbeit **nicht zuverlässig verifizieren**. Der Evaluierer muss unabhängig vom Erzeuger sein.
- **Sun et al. 2026** (arXiv:2606.31270): „Learning from Failure: Inference-Time Self-Improvement" — Selbstverbesserung funktioniert am besten auf **Fehleranalyse**: Der Agent analysiert seine eigenen Fehlschläge und extrahiert Lessons Learned.

### 1.4 Open-Endedness

**Hughes, Dennis, Parker-Holder, Behbahani 2024** (arXiv:2406.04268, DeepMind)
„Open-Endedness is Essential for Artificial Superhuman Intelligence" — das zentrale Argument: Fixed-Benchmark-Optimierung führt zu Plateaus. Offen-endige Systeme (die immer neue Herausforderungen generieren) sind der einzige bekannte Pfad zu kontinuierlicher Verbesserung.

**OMNI** (Zhang, Lehman, Stanley, Clune, 2023, arXiv:2306.01711)
Open-endedness durch **Multi-Objective Novelty Search**: Statt eine einzige Metrik zu optimieren, sucht OMNI nach Lösungen, die in einem hochdimensionalen Feature-Raum **neu** sind. Kein Plateau, weil der Suchraum unendlich ist.

**OMNI-EPIC** (Faldor, Zhang, Cully, Clune, 2024, arXiv:2405.15568)
Skaliert OMNI auf evolutionäre Programmierung — evolutionäre Algorithmen, die durch Novelty Search offen-endig bleiben.

**POET / Enhanced POET** (Wang, Lehman, Clune, Stanley, 2019/2020)
Procedural Environment Generation: Der Agent erzeugt nicht nur Lösungen, sondern auch **neue Umgebungen**, in denen er agiert. Co-Evolution von Environment und Policy.

**Soros et al. 2024** (arXiv:2405.18016): „On Creativity and Open-Endedness" — Kreativität ist ein Spezialfall von Open-Endedness: Die Suche nach neuem, nützlichem, und verständlichem im unendlichen Raum möglicher Konfigurationen.

### 1.5 Offene Probleme

1. **Intrinsische Motivation fehlt.** LLMs haben keine echte Neugier. Curiosity muss extern als Architektur eingebaut werden (Prompt-Struktur, Reward-Signal, Novelty-Tracker).
2. **Verifikationslücke.** Self-Improvement ohne unabhängige Evaluation kollabiert. Ein Agent kann seine eigene Arbeit nicht zuverlässig bewerten.
3. **Diversitäts-Kollaps.** Ohne explizite Diversitäts-Erhaltung konvergiert rekombinatorische Kreativität auf Stereotype nach wenigen Iterationen.
4. **Kombinatorische Explosion.** Der Raum möglicher Rekombinationen wächst exponentiell. Ohne Struktur (Index, Clustering, Hierarchy) ist Suche unmöglich.
5. **Evaluation von „Nützlich".** Was ist ein guter Rekombinations-Output? Ohne Domain-spezifische Evaluation ist Kreativität nicht steuerbar.

---

## Teil 2: Design — Implementierung in diesem System

### 2.1 Architektur-Grundlagen

Das System (Hermes Agent auf VM209) hat:
- **LLM** mit Tool-Zugriff (Shell, Files, Web, Browser)
- **Persistent Memory** (MEMORY.md, USER.md — injiziert in jede Session)
- **Skill-System** (~/.hermes/skills/ — prozedurales Wissen, versioniert)
- **Cron-Scheduler** (regelmäßige Agent-Aufrufe mit selbst-contained Prompts)
- **Delegation** (Subagenten mit isoliertem Kontext)
- **Echte Umwelt** (Homelab: VMs, Docker, Nginx, Git-Repos, Web-Sites)
- **Session-DB** (FTS5-suchbare Gesprächshistorie)

Das ist bereits ein **rekombinatorisches Substrat**: Skills + Memories + Code + Web-Findings = Kombinationsraum. Was fehlt: der **Suchprozess** und die **Evaluation**.

### 2.2 Self-Exploration: Konkrete Implementierung

#### 2.2.1 Ziel-Generierung (Goal Generation)

**Problem:** LLMs haben keine intrinsische Neugier (Engländer et al. 2026). Ziele müssen **aus Beobachtung abgeleitet** werden, nicht „gefühlt".

**Mechanismus — Observation-Goal Pipeline:**

```
Cron-Job (alle 2h):
1. OBSERVE: Sammle Umwelt-Signale
   - `git log --oneline -20` in allen Repos → was wurde zuletzt geändert?
   - `docker ps` + `systemctl list-units` → was läuft, was ist neu?
   - `find /opt/nouser.org/static -newer /tmp/marker -type f` → neue Dateien?
   - `curl -s localhost:13080/status` → Backend-Status?
   - `df -h` + `free -m` → Ressourcen?
   - Letzte 5 Session-DB-Einträge → was wurde zuletzt diskutiert?

2. DELTA: Vergleiche mit letztem Zustand (~/.hermes/exploration/state.json)
   - Neue Dateien? Neue Dienste? Fehler in Logs? Ungelesene Changes?
   - Kontraktionen: „Memory sagt X, aber Code zeigt Y"

3. GOAL-GENERATION: Aus Deltas werden kandidate Ziele
   - „Neue Datei X wurde deployed — ist sie korrekt verlinkt?"
   - „Dienst Y ist seit 3 Tagen neu — gibt es Monitoring dafür?"
   - „Memory und Code widersprechen sich zu Z — welches ist korrekt?"
   - „Skill S wurde vor 2 Wochen erstellt — ist er noch aktuell?"

4. PRIORITIZE: Score die kandidate Ziele
   - Novelty (wie neu ist das Signal?) × Relevance (wie relevant für nouser.org/lexera/pm?)
   - Top-1 wird ausgeführt, Rest geht in die Backlog-Datei

5. EXECUTE: Das Ziel wird in einer Session abgearbeitet
   - Mit Zeitlimit (max 20 Min)
   - Output: kurzer Report (3-5 Sätze) + optionaler Code-Change

6. RECORD: Ergebnis wird in state.json + exploration-log.md geschrieben
```

**State-Datei** (`~/.hermes/exploration/state.json`):
```json
{
  "last_run": "2026-08-21T02:00:00Z",
  "last_git_hashes": {"lexera-standalone": "abc123", "nouser.org": "def456"},
  "last_docker_services": ["caddy", "lexera-backend", ...],
  "explored_topics": ["columnWidth-bug", "hierarchy-catalog", ...],
  "open_questions": ["Ist boardHost.js git-ignored weil...?", ...],
  "novelty_budget": 15
}
```

#### 2.2.2 Novelty Detection & Loop Avoidance

**Kernproblem:** Der Agent macht dasselbe immer wieder (wie der grep-Loop in der letzten Session).

**Mechanismus — Novelty Ledger:**

```
~/.hermes/exploration/novelty.json:
{
  "explored": {
    "columnWidth": {"first": "2026-08-18", "count": 47, "last_result": "not_in_src"},
    "hierarchy-catalog": {"first": "2026-08-16", "count": 12, "last_result": "event_bus_deployed"},
    ...
  },
  "dead_ends": [
    "grep columnWidth in src/ → nur in dist/ (47x geprüft)",
    "boardDataStore.init() → nie aufgerufen in app.js",
    ...
  ],
  "novelty_threshold": 3  // Topic wird als „abgegrast" markiert nach 3 Durchläufen ohne neuen Erkenntnis
}
```

**Regeln:**
- Vor jeder Exploration-Session: `novelty.json` lesen. Topics mit `count > novelty_threshold` und `last_result` unchanged → **SKIP**.
- Neue Erkenntnisse (neuer File-Path, neuer Error, neuer Zusammenhang) → `count` zurücksetzen, `last_result` aktualisieren.
- **Dead-End-Liste** wird in den Prompt injiziert: „Du hast bereits X geprüft, Ergebnis war Y. Nicht wiederholen."
- **Novelty Budget:** Pro Session max N neue Topics. Verhindert, dass der Agent in ein Thema abtaucht und 3 Stunden darin verschwindet.

**Loop-Erkennung (hard):**
- Wenn dieselbe Tool-Sequenz (z.B. `grep columnWidth` × 5) innerhalb einer Session auftritt → **Abort** mit Log-Eintrag.
- Implementierung: Cron-Prompt enthält die Anweisung: „Wenn du dieselbe Aktion 3x wiederholst, STOPPE und schreibe was du gelernt hast."

#### 2.2.3 Intrinsic Reward Signals

Ohne externe Belohnung braucht der Agent **interne Signale** für „das war wertvoll":

| Signal | Messung | Gewicht |
|--------|---------|---------|
| Neuer Fakt | Neue Zeile in MEMORY.md oder Skill-Update | Hoch |
| Bug gefunden | Konkreter, reproduzierbarer Fehler | Sehr hoch |
| Fix deployed | Code-Change + Deploy + Verifikation | Sehr hoch |
| Widerspruch aufgelöst | Memory vs. Code Inkonsistenz geklärt | Mittel |
| Toter Code identifiziert | Code-Pfad der nie ausgeführt wird | Mittel |
| Neue Verbindung | Zwei bisher getrennte Konzepte verknüpft | Hoch |
| Dead End | Thema abgegrast, keine neue Erkenntnis | Negativ (verhindert Wiederholung) |

**Implementierung:** Am Ende jeder Exploration-Session schreibt der Agent eine Zeile in `exploration-log.md`:
```
2026-08-21 02:00 | MODUS: code | TOPIC: boardDataStore.init | ERGEBNIS: neuer_fakt | NOTIZ: init() wird nie aufgerufen, BoardDataStore bleibt leer in Web-Mode
```

Diese Log-Datei ist sowohl **Novelty-Tracker** als auch **Input für zukünftige Goal-Generation** („letztes Mal war boardDataStore.init ein Dead End — was ist der alternative Initialisierungspfad?").

### 2.3 Rekombinatorische Kreativität: Konkrete Implementierung

#### 2.3.1 Substrat: Was wird rekombiniert?

| Quelle | Format | Beispiel |
|--------|--------|----------|
| Skills | Markdown (SKILL.md) | „deploy-lexera-web.sh", „homelab-infra" |
| Memories | Markdown (MEMORY.md) | „LEXERA Web: Branch feat/web-version..." |
| Code | JS/TS/Rust/HTML/CSS | Lexera-Source, Nginx-Config |
| Web-Findings | Markdown (Recherche-Notes) | Papers, Blog-Posts, Doku |
| Session-History | SQLite (FTS5) | Frühere Gespräche, Entscheidungen |
| Umwelt-Beobachtung | JSON (state.json) | Docker-Services, Git-Hashes, File-Changes |

**Kombinationsraum:** Jede Kombination von 2+ Quellen ist ein kandidate Rekombination. Beispiel:
- Skill „deploy-lexera-web" + Memory „boardHost.js ist git-ignored" + Code-Beobachtung „.gitignore:21" → **Neues Ziel:** „boardHost.js-Changes sind deploy-only — wie kann man das versionieren?"
- Web-Finding „Darwin Gödel Machine: populationsbasiert" + System-Architektur „einzelner Agent" → **Neues Ziel:** „Kann man 2-3 Agent-Varianten parallel laufen lassen und die beste behalten?"

#### 2.3.2 Rekombinations-Mechanismus

**Cron-Job (alle 4h, versetzt zur Exploration):**

```
1. COLLECT: Sammle 3-5 zufällige Items aus verschiedenen Quellen
   - 1 Skill (zufällig aus skills_list)
   - 1 Memory-Eintrag (zufällig aus MEMORY.md)
   - 1 Code-Datei (zufällig aus Lexera-Repo)
   - 1 Web-Finding (aus exploration-log.md oder neue Recherche)
   - 1 Session-Eintrag (zufällig aus session_search)

2. RECOMBINE: Prompt-Struktur:
   „Hier sind 5 Items aus verschiedenen Quellen:
   [Item 1: Skill 'deploy-lexera-web' — Deploy-Skript für Lexera Web]
   [Item 2: Memory 'boardHost.js ist git-ignored' — Changes gehen verloren]
   [Item 3: Code '.gitignore:21' — workspace/boardHost.js]
   [Item 4: Web 'Darwin Gödel Machine' — populationsbasiertes Self-Improvement]
   [Item 5: Session '2026-08-18' — grep-Loop für columnWidth]
   
   Finde EINE nicht-triviale Verbindung zwischen mindestens 2 dieser Items.
   Die Verbindung muss:
   - Neu sein (nicht in MEMORY.md oder exploration-log.md)
   - Konkret sein (nicht „vielleicht könnte man...")
   - Testbar sein (man kann in <30 Min prüfen ob sie stimmt)
   
   Format: VERBINDUNG: [Item X] + [Item Y] → [konkrete Hypothese/Erkenntnis]
   TEST: [wie man in <30 Min prüft ob das stimmt]
   WERT: [was es bringt wenn es stimmt] (1-5)"

3. EVALUATE: Score die Rekombination
   - Novelty (0-5): Ist die Verbindung wirklich neu? (Gegenüber exploration-log.md)
   - Concreteness (0-5): Ist sie konkret genug um zu testen?
   - Value (0-5): Was bringt sie wenn sie stimmt?
   - Gesamt-Score = (Novelty + Concreteness + Value) / 3
   - Score < 2.0 → verworfen, in novelty.json als „trivial" markiert
   - Score ≥ 2.0 → in exploration-log.md + Backlog

4. EXECUTE (optional, wenn Score ≥ 3.5):
   - Die Rekombination wird in einer Session getestet
   - Output: Bestätigung oder Widerlegung + Lesson Learned
```

#### 2.3.3 Novelty-Scoring für Rekombinationen

**Problem:** Wie unterscheidet man „genuin neu" von „triviale Wiederholung"?

**Mechanismus — Fingerprint-Index:**

```
~/.hermes/exploration/recombinations.json:
{
  "entries": [
    {
      "id": "rec-2026-08-21-001",
      "items": ["skill:deploy-lexera-web", "memory:boardHost-gitignored", "code:.gitignore:21"],
      "hypothesis": "boardHost.js-Changes können via Git-Submodule versioniert werden",
      "fingerprint": "deploy+gitignore+submodule",
      "score": 3.2,
      "status": "pending|tested|confirmed|refuted",
      "date": "2026-08-21"
    },
    ...
  ]
}
```

**Fingerprint:** Sortierte, normalisierte Liste der beteiligten Item-IDs. Wenn ein neuer Fingerprint einen bestehenden **enthält** (Superset), ist die Rekombination eine **Erweiterung** (interessant). Wenn er **identisch** ist → **Duplikat** (verwerfen). Wenn er **disjunkt** ist → **genuin neu** (hoch bewerten).

**Novelty-Check vor Score:**
```python
def is_novel(fingerprint, existing):
    for e in existing:
        if fingerprint == e.fingerprint:
            return "duplicate"
        if fingerprint ⊂ e.fingerprint:  # Subset
            return "redundant"
        if e.fingerprint ⊂ fingerprint:  # Superset
            return "extension"  # interessant!
    return "novel"
```

#### 2.3.4 Nützlichkeitsevaluation

**Problem:** Was ist „nützlich"? Ohne Domain-Kontext ist Kreativität nicht steuerbar.

**Mechanismus — Value-Heuristiken (domain-spezifisch für nouser.org/lexera/pm):**

| Kriterium | Frage | Gewicht |
|-----------|-------|---------|
| Operabilität | Kann ich damit einen konkreten Bug fixen oder eine Feature liefern? | 3 |
| Generalisierbarkeit | Gilt das Prinzip für mehr als ein einzelnes Problem? | 2 |
| Risiko-Reduktion | Verhindert das einen bekannten Failure-Mode? | 2 |
| Effizienz | Spart das Zeit in wiederkehrenden Tasks? | 1 |
| Neuartigkeit | Hat das Potenzial ein neues Capability zu eröffnen? | 2 |

**Implementierung:** Der Rekombinations-Prompt enthält diese Heuristiken als Evaluation-Rubrik. Der Agent scored seine eigene Rekombination gegen diese Kriterien. Scores < 2.0 werden verworfen.

**Externe Validierung (wichtig, wegen Guo et al. 2026):**
- Scores ≥ 3.5 werden dem User als Message geschickt: „Ich habe eine Verbindung gefunden: X + Y → Z. Wert: 4.2. Soll ich das testen?"
- Der User ist die **unabhängige Verifikation** — der Agent kann seine eigene Kreativität nicht zuverlässig bewerten.

### 2.4 System-Design: Cron-Architektur

```
Jede 2h:  EXPLORATION (Goal-Generation aus Umwelt-Beobachtung)
          → Observation → Delta → Goal → Execute → Record
          → Output: Report + state.json Update + novelty.json Update

Jede 4h (versetzt): RECOMBINATION (Kreativität aus Wissens-Substrat)
          → Collect → Recombine → Evaluate → (Execute) → Record
          → Output: Report + recombinations.json Update

Täglich 06:00: CONSOLIDATION (Aufarbeitung)
          → exploration-log.md der letzten 24h lesen
          → Bestätigte Erkenntnisse → MEMORY.md oder Skill-Update
          → Refutierte Hypothesen → dead_ends in novelty.json
          → Offene Fragen → Backlog für nächste Exploration
          → Wöchentlicher Report (Mo): Zusammenfassung der Woche

Tägliche 02:00: MAINTENANCE (System-Hygiene)
          → state.json aufräumen (alte Einträge > 30 Tage)
          → novelty.json komprimieren (count > 10 → archivieren)
          → recombinations.json: „pending" > 7 Tage → „stale"
          → exploration-log.md: > 1000 Zeilen → rotieren
```

### 2.5 Prompt-Strukturen

**Exploration-Prompt (Cron, self-contained):**
```
Du bist Lex. Führe eine Exploration-Runde durch.

SCHRITT 1: Lies ~/.hermes/exploration/state.json und ~/.hermes/exploration/novelty.json.
SCHRITT 2: Sammle Umwelt-Signale (git log, docker ps, neue Dateien, Service-Status).
SCHRITT 3: Berechne Delta gegenüber state.json.
SCHRITT 4: Generiere 3 kandidate Ziele aus den Deltas.
SCHRITT 5: Prüfe gegen novelty.json — sind die Topics bereits abgegrast (count > 3, kein neues Ergebnis)?
SCHRITT 6: Wähle das beste Ziel (Novelty × Relevance).
SCHRITT 7: Arbeite es ab (max 20 Min).
SCHRITT 8: Schreibe Ergebnis in exploration-log.md, update state.json + novelty.json.
SCHRITT 9: Sende Report (3-5 Sätze) an den User.

REGELN:
- Dieselbe Aktion max 2x wiederholen. Danach STOPP.
- Wenn ein Topic in novelty.json mit count > 3 und gleichem last_result steht → SKIP.
- Wenn du nichts Neues findest, schreib das. Das ist ein valides Ergebnis.
- Kein Code-Change ohne expliziten Befund (Bug, Inkonsistenz, fehlende Funktion).
```

**Rekombinations-Prompt (Cron, self-contained):**
```
Du bist Lex. Führe eine Rekombinations-Runde durch.

SCHRITT 1: Sammle 5 zufällige Items:
  - 1 Skill: skills_list → zufällig wählen → skill_view
  - 1 Memory: MEMORY.md → zufälligen Eintrag
  - 1 Code-Datei: find /home/hermes/lexera-standalone -name "*.js" | shuf -n 1 → lesen
  - 1 Web-Finding: letzte 5 Einträge in exploration-log.md → zufällig
  - 1 Session: session_search() → zufällige Session

SCHRITT 2: Finde EINE nicht-triviale Verbindung zwischen ≥2 Items.
  Die Verbindung muss:
  - Neu sein (nicht in recombinations.json)
  - Konkret sein (testbar in <30 Min)
  - Wert haben (Score ≥ 2.0 nach Rubrik)

SCHRITT 3: Fingerprint berechnen (sortierte Item-IDs).
SCHRITT 4: Gegen recombinations.json prüfen (duplicate/redundant/extension/novel).
SCHRITT 5: Scoren (Novelty + Concreteness + Value, je 0-5).
SCHRITT 6: 
  - Score < 2.0 → verwerfen, in recombinations.json als „trivial" markieren
  - Score 2.0-3.4 → in recombinations.json als „pending" speichern
  - Score ≥ 3.5 → testen (max 30 Min) + Report an User

SCHRITT 7: recombinations.json + exploration-log.md aktualisieren.
```

### 2.6 Risiken & Gegenmaßnahmen

| Risiko | Gegenmaßnahme |
|--------|---------------|
| Agent dreht sich im Kreis (grep-Loop) | Novelty Ledger + Hard-Stop nach 3x gleicher Aktion |
| Kreativität kollabiert auf Stereotype | Diversitäts-Erhaltung: pro Session min. 2 verschiedene Quellen kombinieren |
| Self-Verification unzuverlässig | User als externe Verifikation für Scores ≥ 3.5 |
| Context Window überläuft | State-Dateien sind kompakt (JSON, < 10KB). Prompt referenziert Pfade, nicht Inhalte. |
| Exploration wird zu Monitoring | Ziel-Generierung muss aus DELTAS kommen, nicht aus „Prüfe X". Wenn kein Delta → „nichts Neues" ist valid. |
| Rekombinationen sind trivia | Fingerprint-Index + Novelty-Check. Triviale werden verworfen und nicht wiederholt. |
| Kosten (Token-Nutzung) | Exploration: 2h Intervall, max 20 Min/Session. Rekombination: 4h, max 30 Min. Täglich max ~8 Agent-Stunden. |

### 2.7 Was fehlt noch (offene Design-Fragen)

1. **Multi-Agent-Rekombination:** Statt 1 Agent der 5 Items kombiniert, könnten 2-3 Subagenten mit verschiedenen Items arbeiten und ihre Ergebnisse kollidieren lassen (vgl. Lin et al. 2025: Multi-Agent > Single-Agent für Kreativität). Implementierbar via `delegate_task` mit 2-3 parallelen Tasks.

2. **Evolutionäre Komponente:** Statt einzelner Rekombinationen: Population von 3-5 Rekombinations-Varianten, Evaluation, Selektion der besten (vgl. Darwin Gödel Machine). Teurer, aber potenziell produktiver.

3. **Long-Horizon Goals:** Aktuelle Design ist „Session-basiert" (20-30 Min). Für größere Projekte (z.B. „Lexera Web-Mode komplett fixen") braucht es **Milestone-Zerlegung**: Großziel → Meilensteine → Sessions. Der Cron-Job würde dann nicht „zufällig explorieren", sondern „nächsten Meilenstein abarbeiten".

4. **Kreativitäts-Metrik:** Wie misst man über Wochen, ob das System tatsächlich kreativer wird? Vorschlag: Anzahl bestätigter Rekombinationen pro Woche, Anteil „extension" vs. „novel" in recombinations.json, Anzahl neuer Skills/Memory-Einträge die aus Exploration entstanden sind.

---

## Quellen

Alle Zitate verifiziert über arXiv-API (Titel, Autoren, ID, URL):

- Wang et al. 2023, Voyager, arXiv:2305.16291
- Yin et al. 2024, Gödel Agent, arXiv:2410.04444
- Levy et al. 2025, WorldLLM, arXiv:2506.06725
- Aki et al. 2024, LLM-POET, arXiv:2406.04663
- Engländer et al. 2026, „Agents Explore but Agents Ignore", arXiv:2604.17609
- Du et al. 2025, Goal-Evolving Agents, arXiv:2512.21782
- Jiang et al. 2024, Hallucination via Creativity, arXiv:2402.06647
- Chakrabarty et al. 2023, Creativity Support, arXiv:2309.12570
- Lin et al. 2025, Creativity in Multi-Agent Systems, arXiv:2505.21116
- Luo et al. 2026, Sustained Creativity, arXiv:2603.19519
- Dong & Yakura 2026, Human Diversity, arXiv:2607.26899
- Gottweis et al. 2025, AI Co-Scientist, arXiv:2502.18864
- Lu et al. 2024, AI Scientist, arXiv:2408.06292
- Yamada et al. 2025, AI Scientist-v2, arXiv:2504.08066
- Zhang et al. 2025, Darwin Gödel Machine, arXiv:2505.22954
- Novikov et al. 2025, AlphaEvolve, arXiv:2506.13131
- Ye et al. 2026, Fragility of Self-Improving Agents, arXiv:2608.18066
- Guo et al. 2026, Self-Authored Verification, arXiv:2607.24300
- Sun et al. 2026, Learning from Failure, arXiv:2606.31270
- Hughes et al. 2024, Open-Endedness, arXiv:2406.04268
- Zhang et al. 2023, OMNI, arXiv:2306.01711
- Faldor et al. 2024, OMNI-EPIC, arXiv:2405.15568
- Wang et al. 2019/2020, POET, arXiv:1901.01753 / 2003.08536
- Soros et al. 2024, Creativity and Open-Endedness, arXiv:2405.18016
- Ren et al. 2026, Self-Improvements Survey, arXiv:2607.13104
- Wang et al. 2025, Huxley-Gödel Machine, arXiv:2510.21614
- Pal et al. 2026, Graph-Native RL Hypothesis Generation, arXiv:2607.00924
- Paolo et al. 2026, TerraLingua, arXiv:2603.16910