123 lines
3.5 KiB
Markdown
123 lines
3.5 KiB
Markdown
# 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]]
|