initial commit

This commit is contained in:
2026-03-25 00:05:57 +01:00
commit 25c7d598ca
63 changed files with 5257 additions and 0 deletions

View File

@@ -0,0 +1,122 @@
# Persistent Memory
#sympozium #agenty #memory
## Problem
W modelu efemerycznym agent traci pamięć po zakończeniu runu. Sympozium rozwiązuje to dwoma mechanizmami.
## Mechanizm 1: Legacy ConfigMap Memory
Prostszy, starszy system:
```
Agent output zawiera markery:
__SYMPOZIUM_MEMORY__
Key insight: Pod X has recurring OOM issues
__SYMPOZIUM_MEMORY_END__
Controller parsuje logi poda
Patch ConfigMap: <instance>-memory
Data:
MEMORY.md: |
# Agent Memory
- Key insight: Pod X has recurring OOM issues
Następny run montuje ConfigMap w /memory/MEMORY.md
```
### Ograniczenia
- Flat file (Markdown)
- Brak wyszukiwania semantycznego
- Max rozmiar: `maxSizeKB` (domyślnie 256KB)
- Brak tagowania/kategoryzacji
## Mechanizm 2: SQLite + FTS5 Memory (SkillPack-based)
Zaawansowany system z dedykowanym serwerem:
```
┌─────────────────────────────────────┐
│ Memory Server (Deployment+Service) │
│ │
│ ┌──────────────────┐ │
│ │ SQLite + FTS5 │ │
│ │ na PVC (1Gi) │ │
│ └──────────────────┘ │
│ HTTP API: :8080 │
│ /health - readiness/liveness │
│ /memory/store - zapis │
│ /memory/search - wyszukiwanie FTS │
└──────────┬──────────────────────────┘
Agent Pod (z memory skill):
- memory_store → HTTP POST
- memory_search → HTTP GET
```
### Aktywacja
Dodanie skillu `memory` do SympoziumInstance:
```yaml
skills:
- skillPackRef: memory
```
### Co controller tworzy
1. **PVC**: `<instance>-memory-db` (1Gi) - persystencja SQLite DB
2. **Deployment**: `<instance>-memory` - memory-server z PVC
3. **Service**: `<instance>-memory` - ClusterIP na port 8080
### Zalety vs ConfigMap
- **Full-text search** (FTS5) - agent szuka w pamięci semantycznie
- **Tagging** - memories mogą być kategoryzowane
- **Skalowalne** - DB na PVC, nie ConfigMap (1MB limit)
- **Upgradeable** - można dodać vector search w przyszłości
- **API-driven** - agent używa HTTP API, nie plików
## Memory w scheduled tasks
```yaml
# SympoziumSchedule
spec:
includeMemory: true # Memory context wstrzyknięty do każdego runu
```
To enabler dla **uczących się agentów**:
```
Run 1: Agent odkrywa problem → zapisuje do memory
Run 2: Agent czyta memory → kontynuuje od ostatniego stanu
Run 3: Agent widzi trend → eskaluje
```
## Memory seeds (PersonaPack)
```yaml
personas:
- name: sre-watchdog
memory:
enabled: true
seeds:
- "Track repeated pod restarts for trend analysis"
- "Remember previous node capacity assessments"
```
Seeds to **początkowa pamięć** - instrukcje dla agenta co śledzić.
## Architektura memory w podzie
```
Agent Pod:
├── Init Container: wait-for-memory
│ └── curl http://<instance>-memory:8080/health
│ (czeka aż memory server jest ready)
├── Agent Container:
│ ├── memory_search("previous issues") → HTTP GET
│ └── memory_store("New issue found: ...") → HTTP POST
└── (memory server jest ZEWNĘTRZNY - Deployment, nie sidecar)
```
---
Powiązane: [[Model efemerycznych agentów]] | [[Scheduled Tasks - heartbeaty i swepy]] | [[SympoziumInstance]]