Python-KI-Agenten ohne Kubernetes bereitstellen

Für das Deployment eines Python-KI-Agenten ohne Kubernetes liegen Agentendefinition, Python-Tools und Freigabetests in einem Repository; das Projekt läuft auf einer verwalteten Agenten-Runtime. Die Runtime übernimmt das Erstellen von Deployment-Bundles, Ausführung, Skalierung, Deployment und Traces. Das Anwendungsteam bleibt für Verhalten und Geschäftslogik des Agenten verantwortlich.

Das folgende Beispiel ist bewusst vollständig und klein. Es verwendet ein aktuelles, EU-gehostetes connic/* KI-Modell und ein Tool in reinem Python. Dafür sind weder ein Konto bei einem KI-Modell-Provider noch eine externe API, ein Dockerfile, ein Helm-Chart oder ein Cluster nötig. Die Dateien lassen sich unverändert kopieren; anschließend ersetzt der Anwendungsservice die beispielhafte Liefertabelle.

Was bedeutet „ohne Kubernetes“ tatsächlich?

Das Anwendungsteam überträgt die Container-Orchestrierung an eine verwaltete Runtime. Die Infrastruktur existiert weiterhin, wird jedoch vom Plattformbetreiber betrieben. Das Team stellt ein Agentenprojekt bereit, statt die zugrunde liegenden Container zu verwalten.

Kubernetes ist ein leistungsfähiger universell einsetzbarer Orchestrator. Die offizielle Dokumentation erklärt, wie ein gebautes Container-Image referenziert wird und sich anschließend Deployments, Pods und Rollouts verwalten lassen. Das ist nützliche Infrastruktur, endet aber unterhalb der agentenspezifischen Ebene: Prompts, KI-Modell-Aufrufe, Tool-Traces, Evaluation und Release-Assertions müssen Teams weiterhin selbst zusammensetzen. Die Kubernetes-Dokumentation beschreibt das Vorbereiten und Referenzieren von Container-Images und die Verwaltung von Anwendungs-Rollouts mit Deployments.

Kubernetes Horizontal Autoscaling basiert auf Ressourcenmetriken, eigenen oder externen Metriken; Queue-Länge oder Agentenlatenz benötigen üblicherweise einen expliziten Metrikpfad. Kubernetes Secrets werden standardmäßig unverschlüsselt in etcd gespeichert, sofern keine Schutzmaßnahmen aktiviert sind. Dauerhafte Log-Speicherung und Abfragen erfordern ebenfalls ein Backend auf Cluster-Ebene, da Kubernetes keines mitbringt. Die offiziellen Anleitungen zum Konfigurieren von Horizontal Pod Autoscaling, Absichern von Kubernetes Secrets und Ergänzen von Logging auf Cluster-Ebene. Ein Managed Kubernetes Service kann Control-Plane-Aufwand reduzieren, doch diese Entscheidungen auf Anwendungsebene bleiben bestehen.

Das vollständige Python-Agentenprojekt

Dieses Projekt beantwortet Lieferfragen anhand einer kleinen, deterministischen Datentabelle. Das Modell muss das Tool aufrufen, bevor es ein Lieferfenster nennt, und die Testsuite stellt sicher, dass der Tool-Aufruf im Ausführungspfad bleibt.

delivery-agent/
├── agents/
│   └── delivery-assistant.yaml
├── tools/
│   └── shipping.py
├── tests/
│   └── delivery-assistant.yaml
└── .gitignore

1. Repository-Grundgerüst erstellen

Das Composer SDK benötigt Python 3.10 oder neuer. Nach Installation des Pakets wird ein Projektverzeichnis erstellt:

python -m pip install connic-composer-sdk
connic init delivery-agent
cd delivery-agent

Im Dashboard werden ein Connic-Projekt und eine EU-Bereitstellungsregion ausgewählt. Der Befehl connic login authentifiziert das lokale Verzeichnis und schreibt die Projektzugangsdaten nach .connic. Die Datei bleibt außerhalb von Git:

.connic
.venv/
__pycache__/

2. Agenten in YAML definieren

Die YAML legt das Verhalten des Agenten fest: KI-Modell, Prompt, aufrufbare Tools und Guardrails bleiben im Code Review sichtbar. Dieses Beispiel verwendet das aktuelle KI-Modell connic/glm-5.2, das keinen separaten Provider-Schlüssel benötigt.

version: "1.0"

name: delivery-assistant
type: llm
model: connic/glm-5.2
description: "Answer delivery-window questions with verified data"

system_prompt: |
  You answer questions about delivery times.
  Always call shipping.estimate_delivery before giving an estimate.
  If the user does not name a country, ask for one without calling the tool.
  Pass an uppercase ISO country code and either standard or express.
  If the tool reports available false, say: "This route is unavailable."
  Never invent a delivery window.

tools:
  - shipping.estimate_delivery

guardrails:
  input:
    - type: prompt_injection
      mode: block
    - type: pii
      mode: redact
  output:
    - type: moderation
      mode: block
    - type: system_prompt_leakage
      mode: block

Die vier Guardrails bilden eine praktische Grundlage für den Produktivbetrieb: Prompt Injection blockieren, PII in der Eingabe maskieren, Output moderieren und System-Prompt-Leaks verhindern. Sie müssen an die Anwendung angepasst werden; die Standardwerte ersetzen keine vollständige Sicherheitsrichtlinie. Vor dem Produktivstart sensibler Workflows beschreibt die Guardrail-Dokumentation alle Modi und Ausführungsregeln.

3. Tool in reinem Python schreiben

Ein eigenes Tool ist eine normale Funktion unter tools/. Type Hints definieren das Eingabeschema, und der Docstring erklärt dem Modell, wann die Funktion nützlich ist. Connic erkennt die Funktion direkt aus der Datei.

DELIVERY_WINDOWS = {
    ("DE", "standard"): (2, 4),
    ("DE", "express"): (1, 2),
    ("FR", "standard"): (3, 5),
    ("FR", "express"): (1, 3),
    ("NL", "standard"): (2, 4),
    ("NL", "express"): (1, 2),
}


def estimate_delivery(country_code: str, service: str = "standard") -> dict:
    """Return the delivery window for a supported country and service."""
    country = country_code.upper()
    normalized_service = service.lower()
    window = DELIVERY_WINDOWS.get((country, normalized_service))

    if window is None:
        return {
            "available": False,
            "country_code": country,
            "service": normalized_service,
        }

    minimum_days, maximum_days = window
    return {
        "available": True,
        "country_code": country,
        "service": normalized_service,
        "minimum_business_days": minimum_days,
        "maximum_business_days": maximum_days,
    }

Diese Implementierung hat keine Netzwerkabhängigkeit und macht das Tutorial reproduzierbar. In einem realen Projekt ersetzt ein API- oder Datenbankaufruf die Suche im Dictionary; Zugangsdaten stammen aus Umgebungsvariablen. Bei einem privaten Service stellt Connic Bridge die Verbindung ohne eingehende Firewall-Freigabe her. Die Dokumentation beschreibt die Implementierung und Bereitstellung von Python-Tools oder Anbindung privater Dienste.

4. Release-Gate-Test hinzufügen

Dieser Agent könnte nach Prüfung der falschen Route eine plausible Zahl zurückgeben. Die Suite stellt sicher, dass der Run abgeschlossen wird und shipping.estimate_delivery mit dem angefragten Land und Service im Trace erscheint. Außerdem prüft sie das genannte Zeitfenster, die Antwort für eine nicht verfügbare Route und den Fall ohne Länderangabe.

version: "1.0"

defaults:
  runs: 1
  timeout_s: 60

tests:
  - name: estimates_standard_delivery_to_germany
    payload: "How many business days does standard delivery to DE take?"
    expected_result: status == "completed" and "2" in output and "4" in output
    expected_tool_calls:
      - shipping.estimate_delivery: params.country_code == "DE" and params.service == "standard" and invocations == 1

  - name: checks_an_unsupported_route
    payload: "Can you ship express to the US?"
    expected_result: status == "completed" and "route is unavailable" in output
    expected_tool_calls:
      - shipping.estimate_delivery: params.country_code == "US" and params.service == "express" and invocations == 1

  - name: asks_for_a_country_before_lookup
    payload: "How long does standard delivery take?"
    expected_result: status == "completed"
    expected_no_tool_calls:
      - shipping.estimate_delivery

Eine Ausführung pro Testfall hält die Deployment-Prüfung schnell. Bei schwankenden Ergebnissen kann runs erhöht und ein Erfolgsschwellenwert unter 100 gesetzt werden. Die Testreferenz zeigt, wie sich wiederholte Runs und Tool-Call-Assertions konfigurieren.

5. Projekt prüfen und im verwalteten Entwicklungs-Runner ausführen

Diese Befehle prüfen, ob alle Projektdateien erkannt werden, und starten einen isolierten Entwicklungs-Runner in der Cloud, der dasselbe Image wie der Produktivbetrieb verwendet:

connic lint
connic dev

In der interaktiven Entwicklungssitzung startet t die synchronisierten Testsuiten gegen das aktive Environment; q beendet die Sitzung. Danach startet connic test eine neue Ad-hoc-Testausführung gegen das konfigurierte Environment. Die Dokumentation zum Managed Development Loop beschreibt den Ablauf vor der Git-Anbindung.

6. Über Git veröffentlichen

Das Repository wird mit dem Connic-Projekt verbunden und das Ziel-Environment einem Branch zugeordnet. Ein Push auf diesen Branch startet die verwaltete Pipeline Build → Tests → Deploy. Das gebaute Image wird vor der Veröffentlichung getestet; jeder fehlgeschlagene Testfall stoppt die Übernahme. Mit Git verbundene Projekte werden über diesen Push-Ablauf bereitgestellt; ein Projekt ohne Git-Anbindung kann connic deploy verwenden.

git add agents tools tests .gitignore
git commit -m "Add delivery assistant"
git push origin main

Dasselbe Repository kann unterschiedliche Branches den Umgebungen Development, Staging und Produktivbetrieb zuordnen, jeweils mit isolierter Konfiguration und Run-Historie. Die Dokumentation behandelt Branch-Verbindungen und Projekt-Deployments sowie die Tests vor dem Deployment.

Was die Managed Runtime übernimmt

Ein Container-Log kann zeigen, dass ein Prozess einen Fehler geschrieben hat. Ein Agenten-Trace zeigt dagegen Input, den Modellschritt zur Tool-Auswahl, die genauen Tool-Argumente samt Ergebnis und die finale Antwort. Damit lässt sich das Verhalten des Agenten auf der passenden Ebene untersuchen. Die Dokumentation zeigt, was beim Prüfen von Runs und hierarchischen Traces erfasst wird.

Was kostet der Betrieb dieses Beispiels?

Bei der Kostenschätzung sind Plattformausführung und KI-Modell-Tokens getrennt zu betrachten. Mit den am 8. September 2026 aktualisierten veröffentlichten Preisen ergeben 1.000 monatliche LLM-Agenten-Runs mit durchschnittlich 15 Sekunden folgende Plattform-Zwischensumme:

Die Tabelle zeigt nur die Berechnung. Tatsächliche Laufzeit und Token-Verbrauch hängen von Prompt, KI-Modell, Tool-Aufrufen und Traffic ab. Vor der Budgetierung sollten die aktuellen Werte geprüft werden. Aktuelle Werte stehen in den Projektpreisen und Nutzungstarifen sowie den Angaben zu verwalteten KI-Modellen und Token-Preisen.

Wo werden die Daten verarbeitet?

Dieses Beispiel hält den von Connic betriebenen Pfad in der EU: Eine EU-Projektregion, ein connic/* KI-Modell auf EU-Inferenz-Kapazität und das reine Python-Tool in der Managed Runtime bilden diesen Pfad. Externe Komponenten können den Datenfluss verändern. BYOK-Anbieter, eigene API, Judge, Guardrail oder Ergebnisziel können Daten an andere Orte senden, wenn sie entsprechend konfiguriert sind.

Datenresidenz hängt vom vollständigen Anfragepfad ab. KI-Modell, Tools, Storage, Traces und externe Ziele beeinflussen sie alle. Die detaillierte Abgrenzung zeigt, welche Teile eines Code-first-Projekts in der EU bleiben.

Wann Kubernetes weiterhin die richtige Wahl ist

Kubernetes passt, wenn direkte Kontrolle über die Infrastruktur eine Produkt- oder Policy-Anforderung ist. Es bleibt eine gute Wahl, wenn ein Plattformteam bereits einen ausgereiften Cluster betreibt, der Workload individuelle Ablaufplanung oder spezielle Netzwerkfunktionen benötigt, eine Policy die Ausführung in direkt kontrollierter Infrastruktur vorschreibt oder ein gemessener Workload mit hohem Volumen selbst gehostet geringere Gesamtkosten verursacht.

Eine verwaltete Agenten-Runtime passt, wenn sich das Produkt durch den Agenten von anderen Angeboten abhebt: seine Tools, sein Verhalten, seine Integrationen, Qualität und Nutzererlebnis. Der Trade-off ist weniger Infrastrukturkontrolle im Austausch für eine auf Agenten zugeschnittene Release- und Betriebsebene. Teams mit einem Framework-Prototyp finden weitere Hinweise im Artikel zur Migration von LangChain oder ADK in den Produktivbetrieb.

Methodik und Offenlegung

Wir veröffentlichen dieses Tutorial und stellen die im Beispiel verwendete Managed Runtime. Aussagen zu Kubernetes wurden mit der offiziellen Kubernetes-Dokumentation abgeglichen; Syntax und Verhalten von Connic wurden am 12. August 2026 anhand des aktuellen Produktcodes und der Dokumentation geprüft. Die Preise wurden am 8. September 2026 aktualisiert. Es wurde kein Performance-Vergleich durchgeführt, und Kubernetes kann KI-Agenten ausführen. Das Kostenbeispiel schließt KI-Modell-Tokens, Storage, Retrieval, Engineering-Aufwand und Gebühren externer Services aus.