106 lines
3.0 KiB
Markdown
106 lines
3.0 KiB
Markdown
# Scheduled Tasks - heartbeaty i swepy
|
|
|
|
#sympozium #agenty #scheduling
|
|
|
|
## Koncepcja
|
|
|
|
Sympozium traktuje **agentów jak CronJob'y** - mogą być uruchamiane cyklicznie bez interwencji użytkownika. To enabler dla scenariuszy DevOps/SRE.
|
|
|
|
## Typy scheduli
|
|
|
|
| Typ | Cel | Typowy interwał | Przykład |
|
|
|-----|-----|-----------------|---------|
|
|
| **heartbeat** | Regularne sprawdzanie stanu | 5-30 min | "Sprawdź czy wszystkie pody są healthy" |
|
|
| **scheduled** | Zaplanowane zadania | 1-24h | "Poranny raport z kosztów klastra" |
|
|
| **sweep** | Przeglądy i cleanup | 1-7 dni | "Znajdź i zgłoś nieużywane PVC" |
|
|
|
|
## Self-scheduling
|
|
|
|
Wyjątkowa cecha: **agenty mogą same zarządzać swoimi schedulami**:
|
|
|
|
```
|
|
Agent dostaje task: "Monitor klaster"
|
|
↓
|
|
Agent decyduje: "Powinienem sprawdzać co 15 minut"
|
|
↓
|
|
Agent wywołuje tool: schedule_task(
|
|
action: "create",
|
|
schedule: "*/15 * * * *",
|
|
task: "Sprawdź stan podów w namespace production"
|
|
)
|
|
↓
|
|
/ipc/schedules/create.json → IPC Bridge → NATS: schedule.upsert
|
|
↓
|
|
Schedule Router → tworzy SympoziumSchedule CRD
|
|
↓
|
|
SympoziumSchedule Controller → tworzy AgentRun co 15 min
|
|
```
|
|
|
|
Agent może też: update, suspend, resume, delete swoje schedules.
|
|
|
|
## Concurrency control
|
|
|
|
```yaml
|
|
spec:
|
|
concurrencyPolicy: Forbid # Nie twórz nowego jeśli poprzedni działa
|
|
```
|
|
|
|
| Polityka | Zachowanie | Use case |
|
|
|----------|------------|----------|
|
|
| **Forbid** | Pomiń trigger jeśli run active | Health checks (nie chcemy pile-up) |
|
|
| **Allow** | Twórz nowy niezależnie | Niezależne analizy |
|
|
| **Replace** | Anuluj stary, twórz nowy | Real-time monitoring |
|
|
|
|
## Memory context
|
|
|
|
```yaml
|
|
spec:
|
|
includeMemory: true # Inject MEMORY.md do każdego runu
|
|
```
|
|
|
|
Dzięki temu scheduled run:
|
|
1. Czyta pamięć z poprzednich runów
|
|
2. Kontynuuje od miejsca gdzie skończył
|
|
3. Buduje kontekst między uruchomieniami
|
|
|
|
Przykład: agent monitorujący w heartbeat co 30 min:
|
|
- Run 1: "Wykryłem 3 restarty poda X"
|
|
- Memory: "Pod X ma problem z restartami (3 do tej pory)"
|
|
- Run 2: "Pamięć mówi o restartach poda X. Sprawdzam - już 7 restartów. Eskalaruję."
|
|
|
|
## Przykład z PersonaPack
|
|
|
|
```yaml
|
|
personas:
|
|
- name: sre-watchdog
|
|
schedule:
|
|
type: heartbeat
|
|
interval: "5m"
|
|
task: |
|
|
Check cluster health:
|
|
- Pod restarts > 3
|
|
- Node conditions
|
|
- PVC usage > 80%
|
|
Report and create issues for anomalies.
|
|
memory:
|
|
enabled: true
|
|
seeds:
|
|
- "Track repeated issues for trend analysis"
|
|
- "Escalate if same issue persists > 3 checks"
|
|
```
|
|
|
|
## Architektoniczne znaczenie
|
|
|
|
Scheduled tasks transformują Sympozium z "narzędzia do chatowania z AI" w **autonomiczną platformę operacyjną**:
|
|
|
|
- Agenty działają 24/7 bez ludzkiej interwencji
|
|
- Budują pamięć i kontekst
|
|
- Mogą eskalować do ludzi (via kanały)
|
|
- Mogą same modyfikować swoje harmonogramy
|
|
|
|
To "sel-healing infrastructure" driven by AI.
|
|
|
|
---
|
|
|
|
Powiązane: [[SympoziumSchedule]] | [[Persistent Memory]] | [[PersonaPacks - zespoły agentów]]
|