Úvod: Od experimentu k výrobě
Sestavení AI agenta, který běží na vývojářském notebooku, je poměrně jednoduché. Zavést jej do výroby se spolehlivostí, škálovatelností a pozorovatelností je naprosto náročné jiný. Podle společnosti Gartner pouze 25 % organizací že se vyvinuli prototypy agentů AI a podařilo se jim je úspěšně škálovat do produkčních prostředí. Mezera mezi prototyp a systém připravený na výrobu je obrovský a příčiny jsou téměř vždy infrastrukturní: nedostatek adekvátní kontejnerizace, absence monitorování, neefektivní škálování a správa přibližný stav.
Agenti umělé inteligence představují ve srovnání s tradičními aplikacemi jedinečné výzvy při nasazení. Agent není jednoduchá bezstavová mikroslužba: udržuje konverzační stav, funguje externí volání API s proměnnou latencí spotřebovává výpočetní zdroje nepředvídatelně a může zůstat aktivní po dobu minut (nebo hodin) u jednoho úkolu. Tyto funkce vyžadují specifické strategie nasazení, které přesahují klasický vzor žádost-odpověď.
V tomto článku budeme analyzovat celý zásobník nasazení pro agenty AI: od kontejnerizace s Dockerem po orchestraci s Kubernetes, od škálovacích strategií po pokročilé monitorování. Každá sekce obsahuje konfigurace připravené k výrobě a konsolidované architektonické vzory týmy spravující agenty ve velkém měřítku.
Co se dozvíte v tomto článku
- Jak kontejnerizovat agenta AI pomocí Dockeru a vícestupňových sestav
- Nasazení na Kubernetes s manifesty optimalizovanými pro zatížení agentů
- Horizontální, vertikální a frontové škálovací strategie
- Trvalost stavu: Redis, PostgreSQL a PersistentVolumes
- Service mesh a networking pro komunikaci mezi agenty
- Specifické zdravotní kontroly pro agenty: živost, připravenost a startovací sonda
- Monitorování pomocí Prometheus a Grafana: vlastní metriky pro agenty
- Strukturované protokolování a distribuované trasování s OpenTelemetry
Docker Containerization pro AI agenty
Kontejnerizace je kritickým prvním krokem k tomu, aby byl agent AI přenosný a reprodukovatelný. Kontejner Docker zapouzdřuje agenta, jeho závislosti, místní modely (pokud existují) a konfiguraci do rozmístitelné jednotky kdekoli. Kontejnerování agenta AI však vyžaduje pozornost na konkrétní detaily, které tradiční webové aplikace neobsahují.
Dockerfile Optimized: Vícefázové sestavení
Vícestupňový přístup k sestavení dramaticky zmenšuje velikost konečného obrazu oddělením sestavení prostředí z běhového prostředí. Pro agenta založeného na Pythonu to znamená nainstalovat vytvářet závislosti pouze ve fázi sestavení a kopírovat pouze nezbytné artefakty v konečné fázi.
# === Stage 1: Builder ===
FROM python:3.12-slim AS builder
WORKDIR /app
# Installa dipendenze di sistema per compilazione
RUN apt-get update && apt-get install -y --no-install-recommends \
build-essential \
gcc \
&& rm -rf /var/lib/apt/lists/*
# Copia e installa dipendenze Python
COPY requirements.txt .
RUN pip install --no-cache-dir --prefix=/install -r requirements.txt
# === Stage 2: Runtime ===
FROM python:3.12-slim AS runtime
WORKDIR /app
# Copia solo le dipendenze installate
COPY --from=builder /install /usr/local
# Copia il codice dell'agente
COPY src/ ./src/
COPY config/ ./config/
# Crea utente non-root per sicurezza
RUN useradd --create-home --shell /bin/bash agent
USER agent
# Variabili d'ambiente
ENV PYTHONUNBUFFERED=1
ENV AGENT_ENV=production
ENV LOG_LEVEL=INFO
# Health check integrato nel container
HEALTHCHECK --interval=30s --timeout=10s --start-period=60s --retries=3 \
CMD python -c "import requests; requests.get('http://localhost:8080/health')" || exit 1
# Esponi porta del servizio
EXPOSE 8080
# Avvia l'agente
CMD ["python", "-m", "src.agent_server"]
Tento Dockerfile implementuje několik kritických osvědčených postupů. Použití python:3.12-slim
jako základní obrázek snižuje útočnou plochu a celkovou velikost. Vícestupňová stavba
eliminuje nástroje pro vytváření z konečného obrazu. Uživatel bez oprávnění root brání útokům
eskalace privilegií. The HEALTHCHECK native umožňuje samotnému Dockeru monitorování
stav kontejneru.
Optimalizace obrazu
Pro agenty používající těžké knihovny, jako je PyTorch nebo TensorFlow, optimalizace obrazu se stává zásadní. Některé účinné strategie:
- Ukládání do mezipaměti vrstvy: Seřaďte příkazy COPY od nejméně po nejvíce nestálé (requirements.txt před zdrojovým kódem), abyste maximalizovali mezipaměť vrstvy Docker
- .dockerignore: Vyloučit testy, dokumentaci, dočasné soubory, virtuální prostředí a modely, které nejsou potřebné v produkci
- Alpine vs Slim: pro agenty Pythonu,
slima obecně lepší nežalpineprotože se vyhne problémům s kompatibilitou s balíčky, které vyžadují glibc - Distroless: pro maximální zabezpečení obrázky Google Distroless dokonce eliminují skořápku z kontejneru, čímž snižují útočnou plochu na minimum
Konfigurace specifická pro prostředí
Agent ve výrobě vyžaduje odlišné konfigurace ve srovnání s vývojem: skutečné klíče API, produkční koncové body, vhodné úrovně protokolování. Probíhá správa konfigurace prostřednictvím proměnných prostředí, konfiguračních souborů připojených jako svazky nebo externích správců tajných informací.
# config/production.yaml
agent:
name: "research-agent-v2"
max_iterations: 15
timeout_seconds: 300
model:
provider: "anthropic"
name: "claude-sonnet-4-20250514"
temperature: 0.1
max_tokens: 4096
memory:
backend: "redis"
redis_url: "${REDIS_URL}"
ttl_hours: 24
tools:
- name: "web_search"
enabled: true
rate_limit: 10 # richieste/minuto
- name: "database_query"
enabled: true
connection_pool_size: 5
observability:
metrics_port: 9090
tracing_enabled: true
log_format: "json"Nasazení Kubernetes
Kubernetes je standardní platforma pro orchestraci pro kontejnerizované úlohy v produkci. Pro agenty AI nabízí Kubernetes klíčové výhody: automatické škálování, samoléčení, tajná správa, zjišťování služeb a průběžné aktualizace bez prostojů. Nicméně, agenti AI má specifické požadavky, které vyžadují vyhrazené konfigurace Kubernetes.
Základní manifesty: Nasazení a služba
Manifest nasazení definuje, jak má Kubernetes spouštět a spravovat pody agentů. Pro agenty AI je klíčové správně nakonfigurovat zdroje (CPU a paměť), sondy zásady zdraví a restartu.
# k8s/deployment.yaml
apiVersion: apps/v1
kind: Deployment
metadata:
name: research-agent
labels:
app: research-agent
version: v2.1.0
spec:
replicas: 3
selector:
matchLabels:
app: research-agent
template:
metadata:
labels:
app: research-agent
annotations:
prometheus.io/scrape: "true"
prometheus.io/port: "9090"
spec:
containers:
- name: agent
image: registry.example.com/research-agent:v2.1.0
ports:
- containerPort: 8080
name: http
- containerPort: 9090
name: metrics
resources:
requests:
cpu: "500m"
memory: "1Gi"
limits:
cpu: "2000m"
memory: "4Gi"
env:
- name: AGENT_ENV
value: "production"
- name: ANTHROPIC_API_KEY
valueFrom:
secretKeyRef:
name: agent-secrets
key: anthropic-api-key
- name: REDIS_URL
valueFrom:
configMapKeyRef:
name: agent-config
key: redis-url
livenessProbe:
httpGet:
path: /health/live
port: 8080
initialDelaySeconds: 30
periodSeconds: 15
timeoutSeconds: 5
failureThreshold: 3
readinessProbe:
httpGet:
path: /health/ready
port: 8080
initialDelaySeconds: 10
periodSeconds: 10
timeoutSeconds: 5
startupProbe:
httpGet:
path: /health/startup
port: 8080
initialDelaySeconds: 15
periodSeconds: 10
failureThreshold: 12
---
apiVersion: v1
kind: Service
metadata:
name: research-agent-svc
spec:
selector:
app: research-agent
ports:
- name: http
port: 80
targetPort: 8080
- name: metrics
port: 9090
targetPort: 9090
type: ClusterIPConfigMaps a tajemství
Oddělení mezi konfigurací a kódem je základním principem Dvanáctifaktorové aplikace. V Kubernetes ConfigMaps spravují necitlivou konfiguraci, zatímco Secrets chrání Klíče API, přihlašovací údaje k databázi a certifikáty TLS. Pro agenty AI klíče API poskytovatelů LLM jsou tím nejdůležitějším tajemstvím, které je třeba chránit.
# k8s/configmap.yaml
apiVersion: v1
kind: ConfigMap
metadata:
name: agent-config
data:
redis-url: "redis://redis-cluster.default.svc:6379"
max-iterations: "15"
model-name: "claude-sonnet-4-20250514"
log-level: "INFO"
---
# k8s/secret.yaml (valori codificati in base64)
apiVersion: v1
kind: Secret
metadata:
name: agent-secrets
type: Opaque
data:
anthropic-api-key: <base64-encoded-key>
database-password: <base64-encoded-password>StatefulSet pro agenty s trvalým stavem
Když agent potřebuje udržovat trvalý místní stav (např. vkládání mezipaměti, místní vyladěné modely nebo historie relace na disku), a StatefulSet je lepší než nasazení. StatefulSet zaručuje stabilní identitu sítě pro každý modul, trvalé úložiště prostřednictvím PersistentVolumeClaim a deterministické řazení spouštění a vypnutí.
Strategie škálování
Škálování agentů AI je složitější než tradiční mikroslužby. Agent může zabírat vlákno na desítky sekund (nebo minut), zatímco provádí vícekrokovou úlohu, což činí tradiční metriky (CPU, paměť) nedostatečnými indikátory reálného zatížení. Je zapotřebí vícerozměrné škálovací strategie.
Horizontal Pod Autoscaler (HPA)
HPA automaticky škáluje počet replik na základě pozorovaných metrik. Pro Zásadní jsou agenti AI, vlastní metriky: počet souběžných úkolů, hloubka Významnějšími indikátory využití jsou fronta požadavků a průměrná latence na úlohu CPU.
# k8s/hpa.yaml
apiVersion: autoscaling/v2
kind: HorizontalPodAutoscaler
metadata:
name: research-agent-hpa
spec:
scaleTargetRef:
apiVersion: apps/v1
kind: Deployment
name: research-agent
minReplicas: 2
maxReplicas: 20
metrics:
# Metrica CPU standard
- type: Resource
resource:
name: cpu
target:
type: Utilization
averageUtilization: 70
# Metrica custom: task concorrenti per pod
- type: Pods
pods:
metric:
name: agent_active_tasks
target:
type: AverageValue
averageValue: "5"
# Metrica custom: profondità coda
- type: External
external:
metric:
name: task_queue_depth
target:
type: AverageValue
averageValue: "10"
behavior:
scaleUp:
stabilizationWindowSeconds: 60
policies:
- type: Pods
value: 4
periodSeconds: 60
scaleDown:
stabilizationWindowSeconds: 300
policies:
- type: Pods
value: 2
periodSeconds: 120Škálování podle fronty
Pro agenty zpracovávající asynchronní úlohy je škálování založené na hloubce fronty e nejúčinnějším vzorem. Myšlenka je jednoduchá: jak se fronta zvětšuje, přidávejte pracovníky; kdy vyprazdňuje se, redukuje. Nástroje jako KEDA (událostmi řízené automatické škálování Kubernetes) umožňují škálovat pody na základě metrik z RabbitMQ, Redis Streams, Kafka nebo SQS.
- Měřítko na nulu: Když nejsou ve frontě žádné úlohy, může KEDA snížit replikace na nulu, čímž zcela eliminuje náklady na infrastrukturu během výpadku
- Burst škálování: V případě náhlých špiček může KEDA agresivně škálovat na základě rychlosti růstu fronty
- Doba ochlazení: Období stabilizace zabraňuje drcení (nepřetržité škálování nahoru a dolů) způsobené dočasnými výkyvy zatížení
Vertikální škálování
Některé úlohy agenta vyžadují více prostředků na jednu instanci místo více instancí. Například agent, který provádí komplexní uvažování s místním modelem nebo procesy Velké dokumenty těží spíše z větší paměti a CPU na pod více modulů s omezenými zdroji. The Vertical Pod Autoscaler (VPA) pravidlo automaticky požaduje zdroje na základě historického využití.
Vytrvalost státu
Správa stavu je jednou z nejkritičtějších výzev při nasazování agentů AI. Agent který ztrácí svůj konverzační stav, dlouhodobou paměť nebo kontext úkolu probíhá kvůli restartu modulu a je nepoužitelný ve výrobě. Přetrvávání stav vyžaduje vícevrstevný přístup.
Redis pro stav relace
Redis je ideální volbou pro stav relace agenta: nízká latence (sub-milisekundy), podpora složitých datových struktur a automatické TTL pro čištění vypršelých relací. V kontextu s více replikami funguje Redis jako úložiště sdílených relací což umožňuje libovolnému modulu pokračovat v konverzaci zahájené na jiném modulu.
PostgreSQL + pgvector pro dlouhodobou paměť
Dlouhodobá paměť agentů vyžaduje databázi schopnou spravovat obě data strukturované (historie interakcí, uživatelské preference, metriky) a vyhledávání sémantika (hledání podobnosti na vektorových vloženích). PostgreSQL s pgvector splňuje oba požadavky v jediném řešení, čímž se vyhne složitosti správy relační databáze oddělená od vektorového úložiště.
PersistentVolumes pro místní mezipaměť
Když agent používá místní mezipaměti (předem vypočítaná vložení, stažené šablony, soubory
dočasné zpracování), Kubernetes PersistentVolumes zajistí, že tato data
přežít restarty modulu. Je důležité nakonfigurovat storageClassName
vhodné a zásady navrácení, aby se zabránilo ztrátě dat nebo hromadění osiřelých svazků.
Sítě a komunikace mezi agenty
V multiagentních architekturách je komunikace mezi agenty kritickým aspektem, který ovlivňuje latence, spolehlivost a bezpečnost. Síť v Kubernetes nabízí několik možností, od jednoduché zjišťování služeb až po pokročilé sítě služeb.
Servisní síť s Istio
Un servisní síť jako Istio přidává vrstvu infrastruktury vyhrazenou pro komunikace mezi službami. Pro multiagentní systémy Istio poskytuje:
- Automatické mTLS: Vzájemné šifrování mezi všemi moduly zajišťující, že komunikace mezi agenty je vždy šifrovaná a ověřená
- Jistič: Když je následný agent přetížený nebo nereaguje, jistič přeruší požadavky a zabrání tak kaskádovým poruchám
- Automatické opakování: Neúspěšné požadavky jsou opakovány s exponenciálním couváním a transparentně řeší přechodné chyby
- Pokročilé vyvažování zátěže: Inteligentní distribuce provozu pomocí algoritmů, jako je nejmenší počet spojení nebo konzistentní hašování
- Pozorovatelnost: Metriky provozu, latence a chybovosti pro každou dvojici služeb, beze změn v kódu agenta
Komunikační vzory
Výběr komunikačního vzoru závisí na typu interakce mezi agenty:
- Synchronní požadavek-odpověď: pro interakce, kdy volající agent musí čekat na výsledek (gRPC nebo REST). Vhodné pro volání nástrojů a dotazy na specializované sub-agenty
- Asynchronní fronta zpráv: pro delegované úkoly, které nevyžadují okamžitou reakci (RabbitMQ, Kafka). Ideální pro multiagentní kanály, kde každý agent zpracovává a předává výsledek dalšímu
- Událostí: pro upozornění a spouštěče (Kafka, Redis Pub/Sub). Umožňuje úplné oddělení mezi agenty, kteří produkují události, a agenty, kteří je konzumují
Kontrola stavu agentů AI
Sondy Kubernetes jsou nezbytné pro zajištění toho, že provoz přijímají pouze zdravé moduly. Pro agenty AI mají tyto tři typy sond specifický význam:
- Sonda živosti: Ověřte, zda je proces agenta aktivní a není uváznutý. Zkontrolujte, zda HTTP server odpovídá a zda není blokována hlavní smyčka. Pokud selže, Kubernetes restartuje modul.
- Sonda připravenosti: Ověřuje, že agent je připraven přijímat nové úkoly. Zkontrolujte připojení k Redis, databázi a dostupnost externích rozhraní API. Pokud selže, modul je odstraněn ze služby (žádný příchozí provoz), ale není restartován.
- Startovací sonda: Ověřte, že je inicializace dokončena. Pro agenty které potřebují načíst modely, naplnit mezipaměti nebo vytvořit více připojení, čas spuštění může být významné (30-120 sekund). Startovací sonda brání živosti/připravenosti ukončete lusk dříve, než bude připraven.
Implementace koncových bodů zdraví
# health.py - Endpoint di salute per l'agente
from fastapi import FastAPI, Response
import redis
import psycopg2
import time
app = FastAPI()
# Stato globale dell'agente
agent_ready = False
agent_start_time = time.time()
@app.get("/health/live")
async def liveness():
"""L'agente è vivo? Il processo funziona?"""
return {"status": "alive", "uptime": time.time() - agent_start_time}
@app.get("/health/ready")
async def readiness():
"""L'agente è pronto a ricevere task?"""
checks = {}
# Verifica connessione Redis
try:
r = redis.from_url("redis://redis:6379")
r.ping()
checks["redis"] = "ok"
except Exception:
checks["redis"] = "failed"
return Response(status_code=503, content="Redis non disponibile")
# Verifica connessione database
try:
conn = psycopg2.connect("postgresql://agent:pass@db:5432/agentdb")
conn.close()
checks["database"] = "ok"
except Exception:
checks["database"] = "failed"
return Response(status_code=503, content="Database non disponibile")
# Verifica API key configurata
import os
if not os.getenv("ANTHROPIC_API_KEY"):
checks["api_key"] = "missing"
return Response(status_code=503, content="API key mancante")
checks["api_key"] = "configured"
return {"status": "ready", "checks": checks}
@app.get("/health/startup")
async def startup():
"""L'inizializzazione è completata?"""
if not agent_ready:
return Response(status_code=503, content="Inizializzazione in corso")
return {"status": "started"}Monitorování a varování
Monitoring je páteří provozuschopnosti výroby. Pro agenty AI metriky Infrastrukturní standardy (CPU, paměť, síť) jsou nutné, ale nedostatečné. Jsou potřeba specifické metriky, které zachycují chování a výkon uvažování agentů.
Metriky Prometheus pro agenty
Prometheus je to de facto standard pro monitorování cloudových nativních systémů. Pro agenty AI definujeme vlastní metriky, které sledují každý kritický aspekt životního cyklu úkolu.
# metrics.py - Metriche Prometheus per agente AI
from prometheus_client import Counter, Histogram, Gauge, Summary
# --- Metriche di Task ---
TASKS_TOTAL = Counter(
"agent_tasks_total",
"Numero totale di task processati",
["agent_name", "status"] # status: success, failure, timeout
)
TASK_DURATION = Histogram(
"agent_task_duration_seconds",
"Durata del task in secondi",
["agent_name", "task_type"],
buckets=[1, 5, 10, 30, 60, 120, 300, 600]
)
# --- Metriche LLM ---
LLM_CALLS_TOTAL = Counter(
"agent_llm_calls_total",
"Numero totale di chiamate LLM",
["agent_name", "model", "status"]
)
LLM_LATENCY = Histogram(
"agent_llm_latency_seconds",
"Latenza delle chiamate LLM",
["agent_name", "model"],
buckets=[0.5, 1, 2, 5, 10, 20, 30]
)
TOKEN_USAGE = Counter(
"agent_token_usage_total",
"Token consumati (input + output)",
["agent_name", "model", "direction"] # direction: input, output
)
# --- Metriche Tool ---
TOOL_CALLS_TOTAL = Counter(
"agent_tool_calls_total",
"Numero di invocazioni tool",
["agent_name", "tool_name", "status"]
)
TOOL_LATENCY = Histogram(
"agent_tool_latency_seconds",
"Latenza delle chiamate tool",
["agent_name", "tool_name"],
buckets=[0.1, 0.5, 1, 2, 5, 10, 30]
)
# --- Metriche di Stato ---
ACTIVE_TASKS = Gauge(
"agent_active_tasks",
"Numero di task attualmente in esecuzione",
["agent_name"]
)
ITERATIONS_PER_TASK = Histogram(
"agent_iterations_per_task",
"Numero di iterazioni del loop per task",
["agent_name"],
buckets=[1, 2, 3, 5, 8, 10, 15, 20]
)Grafana Dashboard
Metriky Prometheus se zobrazují prostřednictvím Grafana v palubní desce oddaný. Efektivní řídicí panel pro agenty AI obsahuje alespoň tyto panely:
- Přehled úkolů: Dokončené, neúspěšné a vypršel časový limit za posledních 24 hodin. Procentní úspěšnost. Trend průměrné doby trvání
- Výkon LLM: P50, P90, P99 latence LLM hovorů. Spotřebované tokeny za hodinu a odhadované náklady. Chybovost na model
- Použití nástroje: rozdělení hovorů podle nástroje. Latence a chybovost pro každý nástroj. Nejpoužívanější nástroje
- Infrastruktura: Využití CPU a paměti na modul. Počet aktivních replik. Stav připojení Redis a databáze
- Upozornění: panel s aktivními výstrahami, nakonfigurovanými pravidly a historií oznámení
Upozornění pomocí PagerDuty a Slack
Výstražná pravidla musí zachytit kritické situace bez generování nadměrného hluku. Pro agenty AI patří mezi typické prahové hodnoty upozornění:
- Kritické: úspěšnost pod 90 % za posledních 15 minut (PagerDuty: okamžitá stránka)
- Varování: Latence P90 nad 60 sekund po dobu delší než 10 minut (Slack: upozornění kanálu ops)
- Kritické: hodinové náklady LLM vyšší než 200 % očekávaného rozpočtu (PagerDuty + Slack)
- Varování: průměrný počet iterací na úlohu při konstantním růstu (možná nekonečná smyčka)
- Kritické: Redis nebo připojení k databázi ztraceno na více než 2 minuty
Logování a distribuované sledování
V agentském systému může jediná uživatelská úloha generovat desítky volání LLM, vyvolání nástrojů a interakce s externími službami. Sledujte celý průběh úkolu vyžaduje strukturované protokolování a distribuované sledování.
Strukturované protokolování (JSON)
Strukturované protokolování ve formátu JSON umožňuje automatickou analýzu, indexované vyhledávání a korelace mezi událostmi. Každá položka protokolu musí obsahovat a korelační ID (nebo trasovací ID), které propojuje všechny protokoly týkající se úlohy jednoho uživatele.
# Esempio di log entry strutturato (JSON)
{
"timestamp": "2026-02-14T10:23:45.123Z",
"level": "INFO",
"service": "research-agent",
"trace_id": "abc123def456",
"span_id": "span_789",
"task_id": "task_001",
"event": "tool_call_completed",
"tool": "web_search",
"query": "AI agents market trends 2026",
"duration_ms": 1250,
"results_count": 8,
"tokens_used": 0,
"iteration": 3,
"message": "Web search completata con 8 risultati"
}OpenTelemetry pro distribuované trasování
OpenTelemetry (OTel) je open source standard pro distribuovanou pozorovatelnost. Pro agenty AI vám OTel umožňuje sledovat celou cestu úkolu napříč všemi systémové komponenty: od přijetí požadavku po každou iteraci smyčky agenta, každé volání LLM, každé vyvolání nástroje až do konečné odpovědi.
Každá významná operace je zabalena do jednoho rozpětí Otel. Rozpětí jsou organizovány hierarchicky: úloha je kořenový rozsah, každá iterace cyklu je a syn, a volání LLM a nástroj jsou vnoučata. Tato hierarchie vám umožňuje vizualizovat kompletní tok úkolu v nástrojích, jako je Jáger o Zipkins, okamžitě identifikuje úzká místa a místa selhání.
Agregace protokolů
Pro systémy s desítkami nebo stovkami instancí agentů centralizovaná agregace protokolů je to nepostradatelné. Nejrozšířenější řešení jsou:
- ELK Stack (Elasticsearch, Logstash, Kibana): Výkonné pro fulltextové vyhledávání a pokročilou analýzu protokolů, ale vyžaduje značné zdroje
- Grafana Loki: lehké a nákladově efektivní řešení, které indexuje pouze metadata protokolu (štítky), nikoli celý obsah. Ideální pro týmy, které již používají Grafana
- Datadog / New Relic: Řešení SaaS, která integrují protokoly, metriky a sledování do jediné platformy s analýzou založenou na umělé inteligenci k identifikaci anomálií
LangSmith jako platforma pozorovatelnosti
LangSmith, vyvinutá týmem LangChain, je platforma pozorovatelnosti speciálně navržený pro aplikace agentů LLM a AI. Na rozdíl od nástrojů sledování generik, LangSmith rozumí sémantice interakcí agentů:
- Stopa řetězů LLM: kompletní pohled na provádění každého řetězce/grafu se vstupem, výstupem, latencí a cenou pro každý uzel
- Integrované hřiště: Možnost znovu spustit jakýkoli krok s upravenými výzvami pro rychlé ladění
- Soubor dat a vyhodnocení: Vytváření testovacích datových sad z produkčních tras pro automatizované regresní testování
- Nativní upozornění: Pravidla založená na kvalitě odezvy specifické pro agenta, nákladech a vzorcích chyb
- Samoobslužný nebo SaaS: K dispozici jako cloudová služba i místní nasazení pro dodržování požadavků
CI/CD pro agenty AI
CI/CD potrubí pro agenty AI rozšiřuje tradiční o konkrétní kroky: ověřování výzvy, testování integrací s poskytovateli LLM a ověřování výkonu uvažování. Robustní potrubí zahrnuje:
- Jednotkové testy: testování jednotlivých nástrojů, logika směrování, správa chyb
- Integrační testy: End-to-end testování se skutečnými (nebo falešnými) LLM na předem definovaných scénářích
- Regresní testování: datová sada zlatých odpovědí pro ověření, že aktualizace výzvy nebo modelu nesnižují kvalitu
- Kanárské nasazení: postupné uvolňování při 5 %, 25 %, 50 %, 100 % provozu s automatickým sledováním metrik
- Automatické vrácení zpět: Pokud metriky během canary degradují, automaticky se vrátí na předchozí verzi
Kontrolní seznam nasazení Předprodukce
Před uvedením agenta do výroby zkontrolujte každou položku v tomto kontrolním seznamu:
- Bezpečnostní audit dokončen: klíče API chráněny, vstup vyčištěn, výstup filtrován
- Provedeno zátěžové testování: systém zvládá očekávanou zátěž s 50% rezervou
- Nakonfigurované monitorování: metriky, řídicí panely a provozní výstrahy
- Aktivní protokolování: strukturované protokoly s ID korelace, centralizovaná agregace
- Provedeny zdravotní kontroly: živost, připravenost a startovací sondy fungují
- Nakonfigurováno škálování: HPA s vlastními metrikami, příslušnými limity min/max
- Zdokumentovaný plán vrácení: testovaný postup pro návrat k předchozí verzi
- Aktivní omezení rychlosti: Ochrana proti výpadkům provozu a nekonečným smyčkám
- Nakonfigurována upozornění na rozpočet: prahové hodnoty útraty pro LLM API s upozorněními
- Testovaná obnova po havárii: záloha dat, ověřená procedura obnovy
- Aktualizovaná dokumentace: provozní runbook, architektura, eskalace
Závěry
Nasazení agentů AI do výroby vyžaduje přísný inženýrský přístup, který jde daleko nad rámec pouhého balení kódu do kontejneru. Infrastruktura se musí řídit specifika zátěže agentů: proměnná latence, nepředvídatelná spotřeba zdrojů, přetrvávající konverzační stav a závislost na externích službách.
Existují čtyři pilíře robustního nasazení: kontejnerizace optimalizované s vícestupňovým Dockerem, orchestrace Kubernetes s konfigurovaným sondováním a škálováním pro zátěž agentů, pozorovatelnost kompletní s vlastními metrikami Prometheus a distribuované sledování, např perzistence státu prostřednictvím Redis a PostgreSQL.
Mezera mezi prototypem a výrobou je vyplněna investicemi do platformy: agent s vynikající monitorování a automatické škálování je obchodním aktivem. Agent bez pozorovatelnosti je to operační riziko. Předprodukční kontrolní seznam uvedený v tomto článku představuje naprosté minimum pro zodpovědné uvedení do provozu.
V dalším článku „FinOps a optimalizace nákladů pro agenty AI“, budeme se zabývat dalším kritickým aspektem výroby: kontrolou nákladů. Budeme analyzovat ekonomika tokenů, modelové směrovací strategie ke snížení výdajů o 60–80 % a techniky rychlého inženýrství zaměřeného na úspory.