Runtime-Architektur¶

Verstehen Sie die Architektur des Symbi-Laufzeitsystems und die Kernkomponenten.

Inhaltsverzeichnis¶

Überblick¶

Die umgesetzten Änderungen zur Eindämmung beschreibt der Betreiber- und Architektur-Leitfaden zur Eindämmung. Die Runtime bindet vorbereitete Aufrufe über Validierung, Genehmigung, Cedar, erforderliches Audit und einmaligen Dispatch; ein unabhängiger Supervisor verwaltet die eingedaemmten Worker. Die abgedeckten CLI-, HTTP-, Scheduler- und DSL-Standardwege verwenden geschützte Journale. Die nachfolgenden Prinzipien beschreiben den Entwurf; verbleibende Ausführungs- und Audit-Pfade verhindern eine vollständige Aussage zur Eindämmung.

Das Symbi-Laufzeitsystem bietet eine sichere, skalierbare und richtlinienorientierte Ausführungsumgebung für autonome Agenten. Auf Rust für Leistung und Sicherheit aufgebaut, implementiert es ein mehrstufiges Sicherheitsmodell mit umfassenden Audit-Funktionen.

Grundprinzipien¶

Sicherheit per Standard: Jede Operation unterliegt der Richtliniendurchsetzung
Zero Trust: Alle Komponenten und Kommunikationen werden verifiziert
Vollständige Auditierbarkeit: Jede Aktion wird mit kryptographischer Integrität protokolliert
Richtliniengesteuert: Deklarative Richtlinien steuern das gesamte Systemverhalten
Hohe Leistung: Native Rust-Implementierung für Produktionsarbeitslasten

Systemarchitektur¶

graph TB
    subgraph "Runtime Core"
        ARS[Agent Runtime Scheduler]
        ALC[Agent Lifecycle Controller]
        ARM[Agent Resource Manager]
        ACB[Agent Communication Bus]
        AEH[Agent Error Handler]
    end

    subgraph "Context and Knowledge"
        ACM[Agent Context Manager]
        VDB[Vector Database]
        RAG[RAG Engine]
        KB[Knowledge Base]
    end

    subgraph "Security and Policy"
        PE[Policy Engine]
        AT[Audit Trail]
        SO[Sandbox Orchestrator]
        CRYPTO[Crypto Operations]
    end

    subgraph "External Integration"
        MCP[MCP Client]
        TV[Tool Verification]
        API[HTTP API]
    end

    subgraph "Sandbox Tiers"
        T1[Tier 1: Docker]
        T2[Tier 2: gVisor]
        T3[Tier 3: Firecracker microVM]
    end

    ARS --> ACM
    ARS --> PE
    ALC --> SO
    ACB --> CRYPTO
    ACM --> VDB
    ACM --> RAG
    SO --> T1
    SO --> T2
    SO --> T3
    MCP --> TV
    PE --> AT

Kernkomponenten¶

Agent Runtime Scheduler¶

Der zentrale Orchestrator, der für die Verwaltung der Agentenausführung verantwortlich ist.

Hauptverantwortlichkeiten: - Task-Scheduling: Prioritätsbasierte Planung mit Ressourcenbewusstsein - Lastverteilung: Verteilung auf verfügbare Ressourcen - Ressourcenzuteilung: Speicher-, CPU- und I/O-Zuweisung - Richtlinienkoordination: Integration mit Richtliniendurchsetzung

Leistungsmerkmale: - Unterstützung für 10.000+ gleichzeitige Agenten - Sub-Millisekunden-Planungsentscheidungen - Prioritätsbasierte Verdrängung - Ressourcenbewusste Platzierung

pub struct AgentScheduler {
    priority_queues: Vec<PriorityQueue<AgentTask>>,
    resource_pool: ResourcePool,
    policy_engine: Arc<PolicyEngine>,
    load_balancer: LoadBalancer,
}

impl AgentScheduler {
    pub async fn schedule_agent(&self, config: AgentConfig) -> Result<AgentId>;
    pub async fn get_system_status(&self) -> SystemStatus;
}

Agent Lifecycle Controller¶

Verwaltet den vollständigen Lebenszyklus von Agenten von der Initialisierung bis zur Beendigung.

Lebenszyklus-Zustände: 1. Initialisierung: DSL-Parsing und Konfigurationsvalidierung 2. Bereit: Warten auf Aufgabenzuweisung 3. Laufend: Aktive Ausführung von Aufgaben 4. Suspendiert: Pausiert aufgrund von Richtlinienverletzung oder Ressourcenbeschränkungen 5. Beendet: Ordnungsgemäßes Herunterfahren oder erzwungener Stopp

stateDiagram-v2
    [*] --> Initializing
    Initializing --> Ready: Valid Config
    Initializing --> Failed: Invalid Config
    Ready --> Running: Task Assigned
    Running --> Suspended: Policy Violation
    Running --> Ready: Task Complete
    Suspended --> Running: Policy Cleared
    Suspended --> Terminated: Manual Override
    Ready --> Terminated: Shutdown
    Failed --> Terminated
    Terminated --> [*]

Ressourcenverwaltung¶

Verwaltete Ressourcentypen: - Speicher: Heap-Zuteilung mit Grenzen und Überwachung - CPU: Kernzuteilung und Nutzungsverfolgung - Festplatten-I/O: Lese-/Schreibbandbreitengrenzen - Netzwerk-I/O: Bandbreiten- und Verbindungsgrenzen - Ausführungszeit: Timeout-Durchsetzung

Ressourcenzuteilungsstrategien: - First Fit: Schnellste Zuteilung für Niedriglatenz-Szenarien - Best Fit: Optimale Nutzung für Ressourceneffizienz - Prioritätsbasiert: Ressourcengarantie für kritische Agenten

pub struct ResourceLimits {
    pub memory_mb: usize,
    pub cpu_cores: f32,
    pub disk_io_mbps: usize,
    pub network_io_mbps: usize,
    pub execution_timeout: Duration,
}

Mehrstufige Sicherheit¶

Sandbox-Architektur¶

Die Laufzeit liefert vier Host-Isolations-Backends — alle OSS — plus ein separates Hosted-Cloud-Backend (E2B). Drei davon sind nummeriert (Docker, gVisor, Firecracker); landlock ist benannt statt nummeriert und bildet einen separaten Zulassungszweig. Es isoliert native beaufsichtigte Worker ohne Container-Daemon. Betreiber wählen das Backend pro Agent über den DSL-Block with { sandbox = ... } oder setzen einen Projekt-Standard in [sandbox] tier = "...". Registrierte HTTP- und geplante Agenten koennen Landlock explizit wählen; ohne Sandbox-Angabe bleibt Docker/Tier1 ihr Standard.

Die Zulassung verwendet SecurityTier::satisfies. Hosted < Tier1 < Tier2 < Tier3 ist die nummerierte Leiter. Landlock erfuellt nur eine explizite Landlock-Anforderung oder das Minimum ohne Isolation und kann keine Container- oder VM-Anforderung ersetzen.

Stufe 1: Docker-Isolation¶

Anwendungsfall: Risikoarme Operationen, Entwicklungsaufgaben - Container-basierte Isolation - Ressourcengrenzen und Capability-Entfernung - Netzwerkisolation und schreibgeschützte Dateisysteme - Geeignet für vertrauenswürdigen Code mit minimalen Sicherheitsanforderungen

Stufe 2: gVisor-Isolation¶

Anwendungsfall: Standard-Produktionsaufgaben, Datenverarbeitung, nicht vertrauenswuerdiger Code - Userspace-Kernel mit Systemaufruf-Abfangung - Speicherschutz und I/O-Virtualisierung - Verbesserte Sicherheit mit minimalen Leistungsauswirkungen - Erfordert runsc, registriert als Docker-Runtime

Stufe 3: Firecracker microVM¶

Anwendungsfall: Workloads mit hoechster Isolation — mandantenfaehiger nicht vertrauenswuerdiger Code, regulierte Daten, Blast-Radius-Eindaemmung - Hardware-Virtualisierung via KVM mit einem dedizierten Kernel pro Ausfuehrung - Vom Betreiber bereitgestellte vmlinux + rootfs (standardmaessig schreibgeschuetzt) - Keine geteilte Kernel-Oberflaeche mit dem Host - Erfordert das firecracker-Binary plus den passenden symbi-sandbox-guest PID-1-Dienst und Supervisor — siehe docs/firecracker-setup.md.

Hosted-Ausfuehrung: E2B (keine Stufe)¶

E2B ist ein separates Hosted-Cloud-Backend, kein Peer von Stufe ½/3. Es wird auf SecurityTier::Hosted unterhalb von Tier1 in der nummerierten Leiter abgebildet. Richtlinien verwenden SecurityTier::satisfies; Anforderungen des separaten Landlock-Zweigs lehnen Hosted-Ausfuehrung ebenfalls ab. Opt-in ausschliesslich ueber DSL (with { sandbox = "e2b" }).

Kommunikationssystem¶

Nachrichtentypen¶

Die Laufzeit unterstützt mehrere Kommunikationsmuster:

Direktnachrichten: Punkt-zu-Punkt-Kommunikation mit Zustellungsgarantien

let response = agent_bus.send_message(
    target_agent_id, 
    SecureMessage::new(payload)
).await?;

Publish-Subscribe: Themenbasierte Ereignisverteilung

agent_bus.publish("data_processing.completed", event_data).await?;
agent_bus.subscribe("security.alerts", alert_handler).await?;

Request-Response: Synchrone Kommunikation mit Timeout

let result = agent_bus.request(
    target_agent, 
    request_payload,
    timeout_duration
).await?;

Sicherheitsfeatures¶

Nachrichtenverschlüsselung: AES-256-GCM für Payload-Schutz Digitale Signaturen: Ed25519-Signaturen für Authentizität Nachrichtenrouting: Richtlinienbasierte Routing-Kontrollen Rate Limiting: Pro-Agent-Nachrichtenraten-Durchsetzung

pub struct SecureMessage {
    pub id: MessageId,
    pub sender: AgentId,
    pub recipient: Option<AgentId>,
    pub encrypted_payload: Vec<u8>,
    pub signature: Ed25519Signature,
    pub timestamp: SystemTime,
}

Communication Policy Gate¶

Das CommunicationPolicyGate befindet sich zwischen den DSL-Builtins und dem CommunicationBus. Alle fuenf Inter-Agent-Builtins (ask, delegate, send_to, parallel, race) werden hindurchgeleitet:

Richtlinienbewertung -- Cedar-Stil-Regeln werden geprueft, bevor eine Nachricht gesendet wird
Nachrichtenerstellung -- SecureMessage mit Ed25519-Signatur und AES-256-GCM-Verschluesselung
Zustellungsverfolgung -- Nachrichtenstatus und Audit-Spur ueber den CommunicationBus
Antwortprotokollierung -- Request/Response-Paare werden mit RequestId-Korrelation verfolgt

Wenn das Policy Gate nicht konfiguriert ist (z.B. bei einem eigenstaendigen REPL), verhalten sich die Builtins identisch zur urspruenglichen Implementierung -- keine Richtlinienpruefung, keine Nachrichtenverfolgung. Dies bewahrt die Rueckwaertskompatibilitaet.

Der ReasoningBuiltinContext traegt drei optionale Felder: - sender_agent_id -- Identitaet des aufrufenden Agenten - comm_bus -- Referenz auf den CommunicationBus fuer Nachrichtenrouting - comm_policy -- Referenz auf das CommunicationPolicyGate fuer Autorisierung

Instanzenuebergreifendes Agent-Messaging¶

Der In-Process-CommunicationBus hat ein verteiltes Gegenstueck -- RemoteCommunicationBus -- das dieselben Nachrichtentypen (ask, send_to, delegate, parallel, race) per HTTP zwischen separaten Runtime-Instanzen weiterleitet. Dadurch kann ein auf einem Host bereitgestellter Koordinator mit auf einem anderen Host bereitgestellten Workern kommunizieren, ohne auf Richtliniendurchsetzung, Signaturen oder Audit-Trails zu verzichten.

Wichtige Eigenschaften:

Gleicher Kontrakt -- RemoteCommunicationBus implementiert dasselbe Trait wie der lokale Bus, sodass sich Agent-Code und DSL-Builtins zwischen In-Process- und instanzenuebergreifenden Topologien nicht aendern.
HTTP-Messaging-Endpunkte -- auf der Runtime-HTTP-API exponiert und in den Standardkontext des RuntimeBridge eingebunden, sodass symbi up an einem Standort Nachrichten von symbi up an anderer Stelle empfangen kann.
AgentPin-verankerte Identitaet -- Sender praesentieren ein AgentPin ES256-Token; Empfaenger verifizieren gegen den domainverankerten Schluessel des Senders, bevor das Policy Gate laeuft.
SchemaPin-Verifikation -- alle ueber Instanzen hinweg referenzierten Tool-Manifeste werden vor der Ausfuehrung gegen ihre gepinnten Signaturen verifiziert.
Audit -- Remote-Nachrichtensendung und -empfang werden im selben kryptographisch manipulationssicheren Format wie lokale Nachrichten protokolliert, sodass der Audit-Trail dem Nachrichten-Hop folgt.

Die Deployment-Topologie besteht typischerweise aus einer Koordinator-Instanz und einer oder mehreren Worker-Instanzen, die jeweils via symbi shell /deploy … (Beta) auf Docker, Cloud Run oder App Runner deployt werden. Siehe den Symbi Shell-Deployment-Leitfaden.

Kontext- und Wissenssysteme¶

Agent Context Manager¶

Bietet persistente Speicher- und Wissensverwaltung für Agenten.

Kontexttypen: - Kurzzeitgedächtnis: Kürzliche Interaktionen und unmittelbarer Kontext - Langzeitgedächtnis: Persistentes Wissen und gelernte Muster - Arbeitsgedächtnis: Aktive Verarbeitung und temporärer Zustand - Geteiltes Wissen: Agentenübergreifender Wissensaustausch

pub trait ContextManager {
    async fn store_context(&self, agent_id: AgentId, context: AgentContext) -> Result<ContextId>;
    async fn retrieve_context(&self, agent_id: AgentId, query: ContextQuery) -> Result<Vec<ContextItem>>;
    async fn search_knowledge(&self, agent_id: AgentId, query: &str) -> Result<Vec<KnowledgeItem>>;
}

RAG Engine Integration¶

RAG-Pipeline: 1. Query-Analyse: Verständnis der Informationsbedürfnisse des Agenten 2. Vektorsuche: Semantische Ähnlichkeitssuche in der Wissensbasis 3. Dokumentenabruf: Abruf relevanter Wissensdokumente 4. Kontextranking: Relevanz-Scoring und Filterung 5. Antwortgenerierung: Kontexterweiterte Antwortsynthese

Leistungsziele: - Kontextabruf: <50ms im Durchschnitt - Vektorsuche: <100ms für 1M+ Einbettungen - RAG-Pipeline: <500ms Ende-zu-Ende

Vektordatenbank¶

Unterstützte Operationen: - Semantische Suche: Ähnlichkeitsbasierter Dokumentenabruf - Metadatenfilterung: Beschränkungsbasierte Suchverfeinerung - Batch-Operationen: Effiziente Massenoperationen - Echtzeit-Updates: Dynamische Wissensbasis-Updates

Vektordatenbank-Abstraktion:

Symbi verwendet ein austauschbares Vektordatenbank-Backend. LanceDB ist der konfigurationsfreie Standard (eingebettet, kein externer Dienst erforderlich). Qdrant ist als optionales Backend hinter dem Feature-Flag vector-qdrant verfügbar.

Backend	Feature-Flag	Konfiguration	Anwendungsfall
LanceDB (Standard)	integriert	Keine (Zero-Config)	Entwicklung, Einzelknoten, eingebettete Deployments
Qdrant	`vector-qdrant`	`SYMBIONT_VECTOR_HOST`	Verteilte Produktionscluster

pub struct VectorConfig {
    pub backend: VectorBackend,       // LanceDB (Standard) oder Qdrant
    pub dimension: usize,             // 1536 für OpenAI-Einbettungen
    pub distance_metric: DistanceMetric::Cosine,
    pub index_type: IndexType::HNSW,
    pub data_path: PathBuf,           // LanceDB-Speicherpfad
}

MCP-Integration¶

Model Context Protocol Client¶

Ermöglicht Agenten den sicheren Zugriff auf externe Tools und Ressourcen.

Kernfähigkeiten: - Server-Erkennung: Automatische Erkennung verfügbarer MCP-Server - Tool-Management: Dynamische Tool-Erkennung und -Ausführung - Ressourcenzugriff: Sicherer Zugriff auf externe Datenquellen - Protokollbehandlung: Vollständige MCP-Spezifikationskonformität

Tool-Erkennungsprozess¶

sequenceDiagram
    participant Agent
    participant MCP as MCP Client
    participant Server as MCP Server
    participant Verifier as Tool Verifier

    Agent->>MCP: Request Tools
    MCP->>Server: Connect and List Tools
    Server-->>MCP: Tool Definitions
    MCP->>Verifier: Verify Tool Schemas
    Verifier-->>MCP: Verification Results
    MCP-->>Agent: Verified Tools

    Agent->>MCP: Invoke Tool
    MCP->>Server: Tool Invocation
    Server-->>MCP: Tool Response
    MCP-->>Agent: Verified Response

Tool-Verifizierung mit SchemaPin¶

Verifizierungsprozess: 1. Schema-Erkennung: Tool-Schema vom MCP-Server abrufen 2. Signaturverifizierung: Kryptographische Signatur verifizieren 3. Trust-on-First-Use: Vertrauenswürdige Schlüssel für zukünftige Verifizierung anheften 4. Richtliniendurchsetzung: Tool-Nutzungsrichtlinien anwenden 5. Audit-Protokollierung: Alle Tool-Interaktionen protokollieren

pub struct ToolVerifier {
    key_store: SchemaPinKeyStore,
    policy_engine: Arc<PolicyEngine>,
    audit_logger: AuditLogger,
}

impl ToolVerifier {
    pub async fn verify_tool(&self, tool: &MCPTool) -> VerificationResult;
    pub async fn enforce_policies(&self, agent_id: AgentId, tool: &MCPTool) -> PolicyResult;
}

Richtliniendurchsetzung¶

Policy Engine Architektur¶

Richtlinientypen: - Zugriffskontrolle: Wer kann auf welche Ressourcen zugreifen - Datenfluss: Wie Daten durch das System fließen - Ressourcennutzung: Grenzen für Rechenressourcen - Audit-Anforderungen: Was wie protokolliert werden muss

Richtlinienbewertung:

pub enum PolicyDecision {
    Allow,
    Deny { reason: String },
    AllowWithConditions { conditions: Vec<PolicyCondition> },
}

pub trait PolicyEngine {
    async fn evaluate_policy(&self, context: PolicyContext, action: Action) -> PolicyDecision;
    async fn register_policy(&self, policy: Policy) -> Result<PolicyId>;
}

Echtzeitdurchsetzung¶

Durchsetzungspunkte: - Agentenerstellung und -konfiguration - Nachrichtensendung und -routing - Ressourcenzuteilungsanfragen - Externe Tool-Ausführung - Datenzugriffsoperationen

Leistung: - Richtlinienbewertung: <1ms pro Entscheidung - Batch-Bewertung: 10.000+ Entscheidungen pro Sekunde - Echtzeit-Updates: Richtlinienänderungen sofort propagiert

Audit und Compliance¶

Kryptographische Audit-Spur¶

Audit-Event-Struktur:

pub struct AuditEvent {
    pub event_id: Uuid,
    pub timestamp: SystemTime,
    pub agent_id: AgentId,
    pub event_type: AuditEventType,
    pub details: AuditDetails,
    pub signature: Ed25519Signature,
    pub chain_hash: Hash,
}

Integritätsgarantien: - Digitale Signaturen: Ed25519-Signaturen für alle Events - Hash-Verkettung: Events verknüpft in unveränderlicher Kette - Zeitstempel-Verifizierung: Kryptographische Zeitstempel - Batch-Verifizierung: Effiziente Massenverifizierung

Audit-Fähigkeiten: - Echtzeit-Event-Streaming - Historische Event-Abfragen - Integritätsverifizierung

Leistungsmerkmale¶

Skalierbarkeitsmetriken¶

Agentenverwaltung: - Gleichzeitige Agenten: 10.000+ simultane Agenten - Agentenstart: <1s für Standard-Agenten - Speichernutzung: 1-5MB pro Agent (variiert je nach Konfiguration) - CPU-Overhead: <5% System-Overhead für Laufzeit

Kommunikationsleistung: - Nachrichtendurchsatz: 100.000+ Nachrichten/Sekunde - Nachrichtenlatenz: <10ms für lokales Routing - Verschlüsselungs-Overhead: <1ms pro Nachricht - Memory Pooling: Zero-Allocation-Nachrichtenübertragung

Kontext & Wissen: - Kontextabruf: <50ms im Durchschnitt - Vektorsuche: <100ms für 1M+ Einbettungen - Wissens-Updates: Echtzeit mit <10ms Latenz - Speichereffizienz: Komprimierte Einbettungen mit 80% Größenreduktion

Ressourcenverwaltung¶

Speicherverwaltung: - Zuweisungsstrategie: Pool-basierte Zuweisung für Leistung - Garbage Collection: Inkrementelle Bereinigung mit begrenzten Pausenzeiten - Speicherschutz: Guard-Pages und Overflow-Erkennung - Leck-Prävention: Automatische Bereinigung und Überwachung

CPU-Auslastung: - Scheduler-Overhead: Die Latenz der Registrierung und der begrenzten Warteschlange wird getestet. Der CPU-Aufwand für 10.000 ausführende Agenten ist nicht nachgewiesen. - Kontextwechsel: Hardware-unterstützte virtuelle Threads - Lastverteilung: Dynamische Lastverteilung - Prioritäts-Scheduling: Echtzeit- und Batch-Verarbeitungsebenen

Konfiguration¶

Laufzeit-Konfiguration¶

[runtime]
max_concurrent_agents = 10000
scheduler_threads = 8
message_buffer_size = 1048576
gc_interval_ms = 100

[security]
default_sandbox_tier = "gvisor"
enforce_policies = true
audit_enabled = true
crypto_provider = "ring"

[context]
vector_backend = "lancedb"            # "lancedb" (Standard) oder "qdrant"
vector_data_path = "./data/vectors"   # LanceDB-Speicherpfad
embedding_dimension = 1536
context_cache_size = "1GB"
knowledge_retention_days = 365

# Optional: nur erforderlich wenn vector_backend = "qdrant"
# [context.qdrant]
# host = "localhost"
# port = 6334

[mcp]
discovery_enabled = true
tool_verification = "strict"
connection_timeout_s = 30
max_concurrent_connections = 100

Umgebungsvariablen¶

# Erforderlich: 32-Byte-Hex-Schluessel zur Verschluesselung des persistenten Zustands.
# `symbi init` schreibt einen in .env. Generieren mit: openssl rand -hex 32
export SYMBIONT_MASTER_KEY=...

# LLM-Anbieter (einen setzen)
export ANTHROPIC_API_KEY=...   # oder OPENAI_API_KEY / OPENROUTER_API_KEY

# Policy-Gate: Cedar ist standardmaessig aktiv und verdrahtet sich automatisch aus policies/*.cedar.
# export SYMBI_INSECURE_ALLOW_ALL=1   # NUR FUER LOKALE ENTWICKLUNG -- permissives Gate

# Scheduler-log_file-Zustellung (fuer diesen Kanal erforderlich; auf dieses Verzeichnis beschraenkt)
# export SYMBIONT_LOG_DIR=/var/log/symbiont

# Vektorsuche: LanceDB ist der konfigurationsfreie Standard. Um stattdessen Qdrant zu verwenden:
# export SYMBIONT_VECTOR_BACKEND=qdrant
# export QDRANT_URL=http://localhost:6333

# OPA-Policy-Backend, falls verwendet (https + Bearer erforderlich fuer Nicht-Loopback-Hosts):
# export SYMBIONT_OPA_URL=https://opa.internal:8181
# export SYMBIONT_OPA_AUTH_TOKEN=...

# Zulassungsliste vertrauenswuerdiger Reverse-Proxy-CIDRs fuer X-Forwarded-For
# export SYMBI_TRUSTED_PROXIES=10.0.0.0/8

Überwachung und Observabilität¶

Metriken-Sammlung¶

Systemmetriken: - Agentenzahl und Ressourcennutzung - Nachrichtendurchsatz und -latenz - Richtlinienbewertungsleistung - Sicherheitsereignisraten

Geschäftsmetriken: - Aufgabenabschlussraten - Fehlerhäufigkeiten nach Typ - Ressourcennutzungseffizienz - Compliance-Audit-Ergebnisse

Integration: - Prometheus: Metriken-Sammlung und Alarmierung - Grafana: Visualisierung und Dashboards - Jaeger: Verteiltes Tracing - ELK Stack: Log-Aggregation und -Analyse

Gesundheitsüberwachung¶

pub struct HealthStatus {
    pub overall_status: SystemStatus,
    pub component_health: HashMap<String, ComponentHealth>,
    pub resource_utilization: ResourceUtilization,
    pub recent_errors: Vec<ErrorSummary>,
}

pub async fn health_check() -> HealthStatus {
    // Comprehensive system health assessment
}

Deployment¶

Container-Deployment¶

FROM rust:1.88-slim as builder
WORKDIR /app
COPY . .
RUN cargo build --release --features production

FROM debian:bookworm-slim
RUN apt-get update && apt-get install -y ca-certificates
COPY --from=builder /app/target/release/symbi /usr/local/bin/
EXPOSE 8080
CMD ["symbi", "up"]

Kubernetes-Deployment¶

apiVersion: apps/v1
kind: Deployment
metadata:
  name: symbi-runtime
spec:
  replicas: 3
  selector:
    matchLabels:
      app: symbi-runtime
  template:
    metadata:
      labels:
        app: symbi-runtime
    spec:
      containers:
      - name: runtime
        image: ghcr.io/thirdkeyai/symbi:latest
        ports:
        - containerPort: 8080
        env:
        - name: SYMBIONT_MASTER_KEY
          valueFrom:
            secretKeyRef:
              name: symbi-secrets
              key: master-key
        resources:
          requests:
            memory: "1Gi"
            cpu: "500m"
          limits:
            memory: "4Gi"
            cpu: "2"

Entwicklung und Testing¶

Lokale Entwicklung¶

# Abhängigkeiten starten (LanceDB ist eingebettet — kein externer Dienst nötig)
docker-compose up -d redis postgres

# Run in development mode
RUST_LOG=debug cargo run --example full_system

# Run tests
cargo test --all --features test-utils

Integrationstests¶

Die Laufzeit umfasst umfassende Test-Suites:

Unit Tests: Komponenten-Level-Tests
Integration Tests: Komponenten-übergreifende Tests
Performance Tests: Last- und Stresstests
Security Tests: Penetrations- und Compliance-Tests

# Run all test suites
cargo test --workspace

# Run performance benchmarks
cargo bench

# Run security tests
cargo test --features security-tests

Nächste Schritte¶

Sicherheitsmodell - Tieferer Einblick in die Sicherheitsimplementierung
Beitragen - Entwicklungs- und Beitragsrichtlinien
API-Referenz - Vollständige API-Dokumentation
Beispiele - Laufzeit-Beispiele und Tutorials

Die Laufzeit-Architektur bietet eine robuste Grundlage für den Aufbau sicherer, skalierbarer KI-Agenten. Ihr modulares Design und das umfassende Sicherheitsmodell machen sie sowohl für Entwicklungs- als auch für Produktionsumgebungen geeignet.