initial commit
This commit is contained in:
122
04-Zarządzanie-Agentami/Persistent Memory.md
Normal file
122
04-Zarządzanie-Agentami/Persistent Memory.md
Normal 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]]
|
||||
Reference in New Issue
Block a user