Connic Dev Server führt lokale Agentenprojekte in einer isolierten Entwicklungsumgebung in der Cloud aus. Der Befehl connic dev lädt das Projekt hoch und synchronisiert Änderungen an unterstützten Dateien. So lassen sich geänderte Prompts mit echten Modellaufrufen und Verbindungen testen, ohne Git-Push oder Deployment in die Produktivumgebung. Die entstandenen Ausführungen lassen sich im Dashboard untersuchen.
Was läuft in der Cloud?
Connic stellt für die Entwicklungssitzung einen Cloud-Runner bereit. Dieser führt die hochgeladenen Agenten und den Python-Code aus, einschließlich der Aufrufe von Modellen und externen Diensten. Lokal gespeicherte Änderungen aktualisieren die Sitzung und benötigen keine Veröffentlichung über die Deployment-Pipeline für den Produktivbetrieb. Auf der Seite Deployments kennzeichnet das Dashboard die Sitzung mit dem Badge Dev session.
Die Einführung zum Composer SDK beschrieb Hot Reload als eine Funktion der CLI. Zum vollständigen Entwicklungsablauf gehören auch dauerhaft gespeicherte Testkonfigurationen, Testsuiten auf Abruf und die Untersuchung von Ausführungen. Der separate Beitrag zu Environments behandelt Veröffentlichungen über Git-Branches in Staging und der Produktivumgebung.
Eine Entwicklungssitzung starten
Voraussetzung sind ein Connic-Projekt und lokale Composer-Dateien mit mindestens einem gültigen Agenten in agents/. Die Einrichtung eines ersten Projekts beschreibt der Quickstart. Im lokalen Projektverzeichnis installieren diese Befehle das SDK, starten die Anmeldung und öffnen eine benannte Sitzung:
pip install connic-composer-sdk
connic login
connic dev my-featureDie Anmeldung speichert die Projektzugangsdaten in .connic. Diese Datei gehört in .gitignore und ist nicht Teil des hochgeladenen Agenten-Bundles. Die CLI gibt einen Dashboard-Link zu den Agenten der Sitzung aus. Der erste Aufruf kann erfolgen, sobald der Runner bereit ist.
Welche lokalen Änderungen synchronisiert connic dev?
Die CLI überwacht die unterstützten Projektverzeichnisse samt Unterverzeichnissen und fasst Änderungen zu einem Upload zusammen. Die Agentenkonfiguration ist nur ein Teil dieses Bundles:
agents/ # Agent YAML
tools/ # Python tools
middleware/ # Before and after middleware
hooks/ # Tool hooks
schemas/ # Output schemas
guardrails/ # Custom guardrails
tests/ # Test suites and supporting filesNach der Synchronisierung verwenden neue Ausführungen die geänderten Dateien. Das Speichern eines Prompts allein startet keine weitere Ausführung des Agenten.
In einem interaktiven Terminal mit Unterstützung für die Einzeltastensteuerung erzwingt r einen Upload, t startet die Testsuiten und q beendet die Sitzung. Die Dev-Server-Dokumentation enthält die Referenz zu Befehlen und Konfiguration.
Temporäre oder benannte Umgebung wählen
Eine temporäre Umgebung beginnt ohne bestehende Konfiguration und wird beim regulären Aufräumen nach der Sitzung entfernt. Eine benannte Umgebung behält ihre Konfiguration für die nächste Sitzung. So stehen dieselben Testzugangsdaten und Verbindungen auch bei späteren Änderungen an einer Funktion zur Verfügung.
| Variante | Befehl | Nach dem Sitzungsende |
|---|---|---|
| Temporär | connic dev | Die Umgebung wird entfernt; die nächste Sitzung beginnt mit einer neuen Umgebung. |
| Benannt | connic dev my-feature | Der Runner stoppt; Umgebung, Variablen und Verbindungen bleiben erhalten. |
Beide Varianten nutzen eine Entwicklungsumgebung, die von den regulären Umgebungen getrennt ist. Neue Dev-Umgebungen übernehmen Variablen oder Verbindungen der Produktivumgebung nicht automatisch. Die für den Test nötigen Werte und Verbindungen werden im Dashboard in der ausgewählten Dev-Umgebung eingerichtet. Eine dort erstellte Webhook-Verbindung kann den hochgeladenen Agenten beispielsweise über ihren eigenen Endpunkt auslösen.
Der Runner lädt Variablen beim Start. Nach dem Hinzufügen oder Ändern von Variablen in einer benannten Umgebung muss die Sitzung beendet und mit connic dev my-feature neu gestartet werden, damit der Runner die neuen Werte erhält. Derselbe Ablauf gilt für die erstmalige Konfiguration einer benannten Umgebung.
Ein Python-Tool mit produktiven Zugangsdaten kann weiterhin in ein externes Produktivsystem schreiben. Für solche Aufrufe eignen sich Testkonten, Sandbox-Endpunkte und entsprechende Zugangsdaten. Im Projekt hinterlegte API-Schlüssel der Modellanbieter stehen auch dem Dev-Runner zur Verfügung; Umgebungsvariablen und Verbindungskonfiguration gelten für die jeweils ausgewählte Umgebung. Die Dokumentation zu Environments beschreibt die Verwaltung dieser Konfiguration.
Prompt ändern, Agenten erneut ausführen, Trace prüfen
Mit einer Prompt-Änderung lässt sich der gesamte Ablauf in wenigen Schritten wiederholen. Bei einem vorhandenen Agenten namens assistant bleiben Modell und Tools unverändert; nur der system_prompt wird angepasst. Dieser Auszug legt eine Vorgabe für die Antwort fest, die sich nach dem nächsten Aufruf prüfen lässt:
system_prompt: |
Answer the request in no more than three sentences.
If information needed to answer is missing, ask for it.- Führe den Agenten einmal über den Dashboard-Link der Sitzung aus, um einen Ausgangspunkt für den Vergleich zu erhalten.
- Speichere die Prompt-Änderung lokal, warte auf die Upload-Meldung der CLI und darauf, dass der Cloud-Runner das Projekt neu lädt.
- Rufe den Agenten in der ausgewählten Dev-Umgebung mit derselben Eingabe erneut auf.
- Öffne die neue Ausführung und klappe ihren Modell-Span auf, um Eingabe und Antwort zu prüfen.
Ein Span bildet einen Vorgang innerhalb einer Ausführung ab. Tool-Spans zeigen Argumente und Ergebnisse; Middleware-Spans zeigen die Verarbeitung rund um den Agentenaufruf. Das Dashboard aktualisiert laufende Ausführungen während der Verarbeitung. Die neue Antwort lässt sich mit der vorherigen vergleichen und darauf prüfen, ob sie die beabsichtigte Vorgabe erfüllt.
Um auch die Ereigniszustellung zu testen, lässt sich eine in der Dev-Umgebung konfigurierte Verbindung auslösen und die daraus entstandene Ausführung öffnen. So werden Verbindung und hochgeladener Agent gemeinsam geprüft. Der Leitfaden zu Ausführungen und Traces erklärt die Trace-Ansicht und die einzelnen Span-Typen.
Tests in der aktiven Dev-Umgebung ausführen
Testdateien werden mit dem Projekt synchronisiert, beim Speichern aber nicht automatisch ausgeführt. Nach der Synchronisierung startet t im Dev-Terminal die Testsuiten aus tests/ in der Umgebung dieser Sitzung. Die Ergebnisse enthalten einen Dashboard-Link für die weitere Untersuchung. Für die Testausführung wird aus dem hochgeladenen Projekt ein Image gebaut und ein separater Test-Runner gestartet. Dieser Startvorgang kommt zum interaktiven Hot Reload hinzu.
In einem zweiten Terminal muss die Dev-Umgebung ausdrücklich angegeben werden. Der Platzhalter im folgenden Befehl steht für ihre Umgebungs-ID:
connic test --env <dev-environment-id>Ohne weitere Angaben verwendet connic test die konfigurierte Testumgebung der als Standard festgelegten regulären Umgebung oder diese reguläre Umgebung selbst. Der Befehl wählt die laufende Dev-Sitzung nicht automatisch aus. Die Referenz zur Testausführung beschreibt Umgebungsauswahl und Filterung; der Beitrag zum Testframework erklärt das Schreiben der Testfälle.
Abhängigkeiten, Konflikte und das Sitzungsende
Abhängigkeiten aus requirements.txt werden beim Sitzungsstart installiert. Wird diese Datei während einer aktiven Sitzung geändert, werden nachfolgende Uploads mit den geänderten Anforderungen abgelehnt. Ein Neustart der Sitzung installiert die neuen Abhängigkeiten. Dev Server akzeptiert einfache Paketanforderungen mit Binärdistributionen; lokale Pfade und Git-Abhängigkeiten werden bei diesem Installationsschritt nicht unterstützt. Bei einer benannten Umgebung erhält ein erneutes connic dev my-feature die vorhandenen Variablen und Verbindungen.
Pro benannter Umgebung kann nur eine Dev-Sitzung aktiv sein. Ist der Name bereits belegt, lässt sich die bestehende Sitzung in ihrem Terminal beenden, ein anderer Name wählen oder eine temporäre Sitzung verwenden. Mit getrennten Namen können Entwickler im selben Projekt an unterschiedlichen Änderungen arbeiten, solange dessen Limit für aktive Sitzungen eingehalten wird.
Die Taste q beendet die Sitzung gezielt; ohne Einzeltastensteuerung steht Ctrl+C zur Verfügung. Beim regulären Aufräumen stoppt der Runner; eine temporäre Umgebung ist danach samt ihren Verbindungen nicht mehr nutzbar. Benannte Umgebungen bleiben für spätere Sitzungen verfügbar, ihre gestoppten Runner führen aber keine Agenten mehr aus. Ein Hintergrundprozess räumt auch inaktive Sitzungen auf und wiederholt fehlgeschlagene Versuche, die Infrastruktur zu entfernen. Schlägt das Entfernen der Infrastruktur fehl, kann das Aufräumen unvollständig bleiben.
Erstelle ein Connic-Projekt, starte eine Dev-Server-Sitzung und prüfe die nächste Ausführung deines Agenten mit Eingabe, Tool-Aufrufen und Ergebnissen.
Starte mit ConnicFür ein bestehendes Projekt beschreibt die Dev-Server-Anleitung die Einrichtung und den Sitzungsstart aus dem lokalen Projektverzeichnis.