83 lines
3.1 KiB
Markdown
83 lines
3.1 KiB
Markdown
# Model efemerycznych agentów
|
|
|
|
#sympozium #agenty #architektura #ephemeral
|
|
|
|
## Fundamentalna decyzja
|
|
|
|
Sympozium implementuje **model efemeryczny**: każde wywołanie agenta tworzy nowy Kubernetes [[Job]], który po zakończeniu jest usuwany. To odwrotność podejścia "persistent engine" stosowanego w kagent, LangChain, CrewAI.
|
|
|
|
## Jak to działa
|
|
|
|
```
|
|
Wiadomość użytkownika
|
|
↓
|
|
Channel Router tworzy AgentRun CR
|
|
↓
|
|
AgentRun Reconciler tworzy Job:
|
|
- Agent container (LLM loop)
|
|
- IPC Bridge sidecar
|
|
- Skill sidecars (z efemerycznym RBAC)
|
|
- Opcjonalnie: sandbox, MCP bridge
|
|
↓
|
|
Agent wykonuje zadanie (sekundy-minuty)
|
|
↓
|
|
Job ends → Pod usunięty → RBAC usunięty → Zasoby zwolnione
|
|
```
|
|
|
|
## Implikacje
|
|
|
|
### Izolacja (zalety)
|
|
- **Blast-radius** ograniczony do jednego poda - misbehaving agent nie wpływa na innych
|
|
- **Resource limits** per invocation - każdy run ma własne CPU/memory limits
|
|
- **[[SecurityContext]]** per run - każdy pod ma hardened security context
|
|
- **[[NetworkPolicy]]** per run - deny-all egress, tylko IPC bridge ma sieć
|
|
- **[[RBAC]]** per run - credentials istnieją tylko przez czas trwania runu
|
|
|
|
### Skalowanie (zalety)
|
|
- **Horizontal scaling** natywne - K8s scheduler rozkłada pody po nodach
|
|
- **No contention** - każdy run to osobny pod, brak współdzielenia procesora
|
|
- **Auto-cleanup** - Kubernetes garbage collection czyści po zakończeniu
|
|
|
|
### Cold start (wady i mitygacja)
|
|
- **Problem:** Każdy run = nowy pod = scheduling + image pull + container start
|
|
- **Typowy czas:** 5-30 sekund
|
|
- **Mitygacja 1:** Warm Pools (SandboxWarmPool) - pre-provisioned sandboxes
|
|
- **Mitygacja 2:** ImagePullPolicy: IfNotPresent - obrazy cache'owane na nodach
|
|
- **Mitygacja 3:** Tryb Server - Deployment zamiast Job dla long-lived scenarios
|
|
|
|
### Brak stanu (wady i mitygacja)
|
|
- **Problem:** Agent nie pamięta poprzednich konwersacji
|
|
- **Mitygacja 1:** Persistent Memory (SQLite + FTS5 na PVC)
|
|
- **Mitygacja 2:** Legacy Memory (ConfigMap MEMORY.md)
|
|
- **Mitygacja 3:** Session persistence (PostgreSQL)
|
|
|
|
## Porównanie z persistent engine
|
|
|
|
| Aspekt | Ephemeral (Sympozium) | Persistent (kagent, LangChain) |
|
|
|--------|----------------------|-------------------------------|
|
|
| Izolacja | [[Pod]]-level per run | Shared process |
|
|
| Cold start | 5-30s (mitygowany WarmPool) | ~0s (process already running) |
|
|
| State | External (memory, sessions) | In-process |
|
|
| Scaling | Horizontal native | Vertical only |
|
|
| Resource utilization | Pay-per-invocation | Always-on |
|
|
| Failure blast radius | Single pod | Entire engine |
|
|
| Audit trail | Pod logs, CRD status | Engine logs |
|
|
| RBAC | Ephemeral per-run | Standing ServiceAccount |
|
|
|
|
## Kiedy model efemeryczny?
|
|
|
|
Idealny dla:
|
|
- **Cluster operations** - kubectl, helm z izolacją
|
|
- **Scheduled tasks** - health checks, sweeps
|
|
- **Multi-tenant** - izolacja między tenantami
|
|
- **Security-sensitive** - untrusted agent code
|
|
- **Batch processing** - one-shot tasks
|
|
|
|
Mniej idealny dla:
|
|
- **Real-time chat** - cold start jest widoczny (ale tryb Server to rozwiązuje)
|
|
- **State-heavy workflows** - wymagają persistent memory
|
|
|
|
---
|
|
|
|
Powiązane: [[Cykl życia AgentRun]] | [[Agent Sandbox - gVisor i Kata]] | [[Sympozium vs kagent]]
|