Sympozium vs frameworki in-process

#sympozium #porównanie #langchain #crewai

Kontekst

Frameworki in-process (LangChain, CrewAI, AutoGen, LlamaIndex) uruchamiają agentów w jednym procesie. Sympozium reprezentuje podejście "infrastructure-native".

Porównanie architektoniczne

Aspekt	In-process frameworks	Sympozium (K8s-native)
Wykonanie agenta	Shared memory, single process	Ephemeral Pod per invocation
Orkiestracja	In-process registry + queue	CRD-based + controller reconciliation
Sandbox	Docker sidecar (long-lived)	Pod SecurityContext + Agent Sandbox
IPC	In-process EventEmitter	Filesystem sidecar + NATS JetStream
Tool gating	In-process pipeline	Admission webhooks + SympoziumPolicy
Persistent memory	Files on disk	SQLite + FTS5 na PVC
Scheduled tasks	Cron jobs / external	SympoziumSchedule CRD
State	SQLite + flat files	etcd + PostgreSQL
Multi-tenancy	Single-instance file lock	Namespaced CRDs + RBAC
Scaling	Vertical only	Horizontal - stateless control plane
Channels	In-process per channel	Dedicated Deployment per channel
External tools	Plugin SDKs	MCPServer CRD + auto-discovery
Observability	Application logs	kubectl, OTel, TUI, Web UI

Dlaczego "infrastructure-native"?

Sympozium nie implementuje orkiestracji w kodzie aplikacji. Zamiast tego mapuje koncepty agentowe na prymitywy Kubernetes:

LangChain concept     →  Sympozium concept    →  K8s primitive
─────────────────────────────────────────────────────────────
Agent                 →  AgentRun              →  Job/Pod
Tool                  →  SkillPack sidecar     →  Container + RBAC
Memory                →  Memory server         →  Deployment + PVC
Chain                 →  Sub-agents            →  Parent-child Jobs
Guard rail            →  SympoziumPolicy       →  Admission Webhook
Scheduler             →  SympoziumSchedule     →  CRD + Controller
Callback handler      →  NATS events           →  JetStream pub/sub
Vector store          →  SQLite FTS5           →  PVC-backed DB

Analiza trade-offs

Complexity

In-process: Prosty pip install, kilka linii Pythona
Sympozium: K8s cluster, Helm install, CRDs, controllers

Flexibility

In-process: Dowolny Python code, łatwe prototyping
Sympozium: Deklaratywny YAML, ograniczony do tego co CRDs oferują

Production readiness

In-process: Trzeba samemu zbudować izolację, scaling, monitoring
Sympozium: Built-in isolation, scaling, monitoring, multi-tenancy

Debugging

In-process: Standard Python debugger, print statements
Sympozium: kubectl logs, OTel traces, TUI, CRD status

Kiedy co?

Scenariusz	In-process	Sympozium
Prototyping	Idealne	Overkill
Single developer	Idealne	Za dużo overhead
Production multi-tenant	Trudne	Idealne
Cluster operations	Niebezpieczne	Bezpieczne
Scheduled automation	Wymaga dodatkowej infra	Built-in
Compliance/audit	Wymaga budowy	Native

Powiązane: Sympozium vs kagent | Kluczowe decyzje projektowe | Model efemerycznych agentów

3.5 KiB Raw Blame History