Zum Hauptinhalt springen
Connic

Entwickle Agenten.
Connic übernimmt den Betrieb.

Versioniere die Betriebseinstellungen zusammen mit deinem Agent-Code in Git. Connic übernimmt Builds und Deployments, steuert parallele Ausführungen und Wiederholungen und stellt Ausführungsprotokolle sowie Rollbacks bereit.

Mit Basic startenDeployment-Leitfaden ansehen
Deployment-Dokumentation lesen
  1. 1

    Bundle erstellen

  2. 2

    Build

  3. 3

    Test

  4. 4

    Aktivieren

  • customer_acme
    Tool: ledger.lookup
    läuft
  • customer_acme
    wartet auf den Run mit demselben Schlüssel
    wartet
  • customer_north
    wartet auf freie Ausführungskapazität des Agenten
    wartet

Der Agent ist nur ein kleiner Teil des Systems, das ihn ausführt.

Wenn Modellaufrufe und Python-Tools funktionieren, fehlen für den Produktivbetrieb oft noch Builds, Tests vor der Veröffentlichung, Regeln für parallele Ausführungen, Wiederholungen, Sessions und Rollbacks. Connic verwaltet diese Funktionen zusammen mit den Runs und Deployments.

Release
Image erstellen, erforderliche Tests ausführen und eine bereitstellbare Version aktivieren
Ausführen
Iterationen, Zeit, Retries und gleichzeitige Runs begrenzen
Koordinieren
Weitere Runs mit demselben Schlüssel in eine Queue stellen oder verwerfen
Wiederherstellen
Die aktive Version verarbeitet weiter Anfragen; ein früheres Deployment lässt sich erneut aktivieren

Lege fest, wie deine Agenten ausgeführt werden

Konfiguriere Ausführungslimits und parallele Verarbeitung je Schlüssel direkt in der Agent-Datei. So bleiben die Einstellungen versioniert und im Review nachvollziehbar.

agents/invoice-processor.yaml
version: "1.0"

name: invoice-processor
type: llm
model: connic/gemini-3.7-flash
description: "Validiert und routet eingehende Rechnungen."
system_prompt: "Validiere die Rechnung, ermittle ihren Ledger-Status und weise anschließend die Review Queue zu."

tools:
  - ledger.lookup
  - routing.assign_queue

max_concurrent_runs: 1
max_iterations: 40
timeout: 120

retry_options:
  attempts: 5
  initial_delay: 10
  max_delay: 60

concurrency:
  key: "data.customer_id"
  on_conflict: queue
  • customer_acme
    Tool: ledger.lookup
    läuft
  • customer_acme
    wartet auf den Run mit demselben Schlüssel
    wartet
  • customer_north
    wartet auf freie Ausführungskapazität des Agenten
    wartet
  • customer_orbit
    wartet auf freie Ausführungskapazität des Agenten
    wartet
  • customer_south
    wartet auf freie Ausführungskapazität des Agenten
    wartet
Unterschiedliche Keys können parallel ausgeführt werden, wenn max_concurrent_runs größer als 1 ist. Die Einstellung on_conflict: drop bricht doppelte Arbeit ab, statt sie in die Queue zu stellen.

  • Loop begrenzen

    Gleichzeitige Runs, LLM-Iterationen und die gesamte verstrichene Zeit je Agent begrenzen.

  • Fehlgeschlagene Operation wiederholen

    Modellanfragen werden am einzelnen Aufruf wiederholt; die Runtime spielt nicht den gesamten LLM-Agenten erneut ab.

  • Runs mit demselben Schlüssel nacheinander ausführen

    Verhindere parallele Runs mit demselben Schlüssel. Das übergreifende Limit gleichzeitiger Runs je Agent gilt weiterhin.

Prüfe neue Versionen, bevor sie aktiv werden

Nutze Git oder die CLI für dein Deployment. Connic führt vorhandene Tests aus und aktiviert nur eine Version, die bereit für den Betrieb ist. Fehlgeschlagene Versuche bleiben nachvollziehbar. Mit --skip-tests lassen sich Tests ausschließlich bei CLI-Deployments überspringen.

  1. 1

    Bundle erstellen

    Agent Spec + Python

  2. 2

    Build

    Dependencies installiert

  3. 3

    Test

    Deploy Gate bestanden

  4. 4

    Aktivieren

    Traffic umgestellt

Neues Deployment fehlgeschlagen

Ein Fehler im Build oder Deploy Gate markiert dieses Deployment als fehlgeschlagen.

Die aktive Version verarbeitet weiter Anfragen

Der Traffic bleibt ohne Unterbrechung auf dem zuletzt aktiven Deployment.

Lege fest, was bei Fehlern passiert

Konfiguriere, wie Connic auf Anbieterfehler, konkurrierende Anfragen, erreichte Iterationslimits und fehlgeschlagene Deployments reagiert.

Runtime-Reaktionen auf häufige Fehler
FehlerRuntime-Reaktion
Anfrage an das KI-Modell fehlgeschlagenNach einer Wartezeit erneut versuchen oder zu fallback_model wechseln und die dafür konfigurierte Anzahl von Versuchen nutzen.
Weiterer Run mit demselben SchlüsselDen neuen Run entsprechend der Concurrency-Regel des Agenten in die Queue stellen oder verwerfen.
IterationslimitDen LLM Loop stoppen, statt wiederholte Tool-Aufrufe unbegrenzt zuzulassen.
Release fehlgeschlagenDas aktive Deployment verarbeitet weiterhin Anfragen. Die Logs des fehlgeschlagenen Builds bleiben zur Prüfung erhalten.

  • Rollback ohne erneuten Build

    Ein früheres erfolgreiches Deployment aktivieren und den Traffic zurück zu seinem bestehenden Container leiten.

  • Sessions bleiben über Releases hinweg bestehen

    Persistente Sessions behalten den Gesprächsverlauf über Neustarts und Deployments hinweg, wenn ein Session Key konfiguriert ist.

  • Jeden Run vollständig tracen

    Die aktive Runtime erfasst Modellaufrufe, Tools, Middleware, Guardrails und Orchestrierung unter dem Run, der sie ausgeführt hat.

Limits, Wiederholungen, parallele Ausführungen, Sessions und Deployments sind ausführlich dokumentiert. Ausführungseinstellungen ansehen oder den Deployment-Ablauf nachvollziehen.

Entdecke weitere Features

Environments

Konfiguration, Secrets und Releases trennen.

Testing

Jedes Deployment mit realen Test Cases absichern.

Observability

Jeden Schritt jedes Runs nachvollziehen.

Verbindungen

Ereignisse aus Produktivsystemen in die Runtime bringen.

Guardrails

Prüfungen vor und nach der Ausführung durchsetzen.

Dev Server

Änderungen mit Hot Reload in der Cloud testen.

Häufig gestellte Fragen

Bei einem mit Git verbundenen Projekt startet ein Push ein Deployment in der Umgebung, die dem Branch zugeordnet ist. Ein Projekt ohne Git-Verbindung kann über die Connic CLI deployen. Connic stellt die Agent-Dateien zu einem Deployment-Bundle zusammen, baut den Container und führt die vollständige Suite aus, wenn tests/ vorhanden ist. Nur bei CLI-Deployments kann die Testphase mit --skip-tests übersprungen werden; Git Auto Deployments bieten diese Option nicht. Anschließend kann das neue Deployment aktiviert werden, wenn es bereit für den Betrieb ist.

Das neue Deployment erhält den Status Failed. Das aktive Deployment verarbeitet weiterhin Anfragen. Die Build-Logs findest du auf der Detailseite des fehlgeschlagenen Deployments.

Ja. Im Tab Deployments lässt sich ein früheres erfolgreiches Deployment aktivieren. Der Traffic wird an dessen bestehenden Container geleitet, daher ist kein neuer Build erforderlich.

Nicht bei einem LLM-Agenten. Modellanfragen werden am fehlgeschlagenen Aufruf wiederholt, während fehlgeschlagene Tool-Aufrufe an den Agenten zurückgemeldet werden. Tool- und Sequential-Agenten behalten Retries auf Operationsebene; rerun_middleware gilt nur für diese Retries.

Der Concurrency Key wird aus den Eingabedaten des Triggers gelesen. Für denselben Schlüssel ist immer nur ein Run aktiv. Weitere Runs mit diesem Schlüssel warten in einer Queue oder werden verworfen. Runs mit unterschiedlichen Schlüsseln können parallel laufen, begrenzt durch max_concurrent_runs und den Tarif des Projekts.

Ja, wenn der Agent einen persistenten Session Key definiert. Der Gesprächsverlauf bleibt über Anfragen, Neustarts und Deployments hinweg verfügbar. Die Session endet, wenn die konfigurierte Zeit ohne neue Aktivität abläuft oder sie gelöscht wird.