LangChain-KI-Agenten in den Produktivbetrieb migrieren

Ein LangChain-Prototyp kann Stakeholder überzeugen und in der Demo funktionieren. Für den Einsatz durch echte Nutzer gelten jedoch andere Anforderungen.

Ein Framework-Projekt in den Produktivbetrieb zu bringen bedeutet, isolierte Ausführung, Parallelitätssteuerung, Deployment-Pipelines, Observability, Kostenverfolgung und Retries umzusetzen. Unsere Plattform stellt diese Funktionen rund um den Agenten bereit, damit sich das Team auf das Produkt konzentrieren kann, statt eine Plattform zu bauen.

Die Migration eines bestehenden LangChain- oder ADK-Projekts zu Connic erhält meist die wiederverwendbare Python-Tool-Logik. Unsere verwaltete Plattform übernimmt die Aufgaben des Produktivbetriebs; geändert wird vor allem die Projektstruktur rund um den Agenten.

Warum Teams aus Frameworks herauswachsen

LangChain, CrewAI und Google ADK sind Agenten-Frameworks. Sie bieten Abstraktionen zur Definition von Agenten, Tools und Chains. LangChain bietet inzwischen auch LangSmith Deployment, eine verwaltete Runtime mit Observability und Evaluation. Connic ist die Alternative für Teams, die deklarative Agenten, Python-Tools, verwaltete Verbindungen, Guardrails, Freigaben, Kostenverfolgung und Deployment in einem Workflow benötigen.

Unsere Plattform übernimmt folgende Aufgaben rund um den Agenten-Code:

Bei der Migration bleibt die bestehende Agentenlogik erhalten. Sie wird in eine Umgebung verschoben, die die Anforderungen des Produktivbetriebs abdeckt und keinen Plattformbau von Grund auf erfordert.

Weiterführende Quellen: Deployment-Plattformen für KI-Agenten, Observability.

Umfang der Migration

Tool-Logik in reinem Python ist meist wiederverwendbar. Eine Funktion, die eine Datenbank abfragt, bleibt eine Python-Funktion mit derselben Aufgabe. Geändert werden die Agentendefinition und die Projektstruktur.

Vorher und nachher

Als Beispiel dient ein LangChain-Support-Agent mit zwei Tools.

from langchain_openai import ChatOpenAI
from langchain.agents import create_react_agent
from langchain.tools import tool

@tool
def search_docs(query: str) -> str:
    """Search the documentation for relevant articles."""
    # Your search logic here
    return results

@tool
def create_ticket(summary: str, priority: str) -> str:
    """Create a support ticket in the system."""
    # Your ticket creation logic here
    return ticket_id

llm = ChatOpenAI(model="gpt-4o")
agent = create_react_agent(
    llm=llm,
    tools=[search_docs, create_ticket],
    prompt="You are a customer support agent..."
)

Nach der Migration werden daraus zwei Dateien: eine YAML-Konfiguration und ein Tool-Modul.

version: "1.0"
name: support-agent
description: "Handles customer support queries"
model: connic/gpt-5.6-terra  # or openai/gpt-5-mini with OpenAI BYOK configured
system_prompt: |
  You are a customer support agent. Search the docs first,
  then create a ticket if the issue cannot be resolved.
tools:
  - support.search_docs
  - support.create_ticket
retry_options:
  attempts: 3
  initial_delay: 10
  max_delay: 30

def search_docs(query: str) -> str:
    """Search the documentation for relevant articles."""
    # Same logic as before - no changes needed
    return results

def create_ticket(summary: str, priority: str) -> str:
    """Create a support ticket in the system."""
    # Same logic as before - no changes needed
    return ticket_id

Die Tool-Funktionen sind identisch. Die Decorators entfallen, KI-Modell und Prompt stehen in YAML, und die Agentendefinition liegt als deklarative Konfiguration statt als imperativer Code vor.

Automatisierte Migration mit der CLI

Für Projekte mit vielen Agenten und Tools enthält die Connic-CLI einen migrate-Befehl, der die strukturelle Konvertierung automatisiert. Er durchsucht den Python-Code des Projekts, extrahiert Agenten und Tools und erzeugt ein Connic-Projekt mit der passenden Struktur.

$ pip install connic

$ connic migrate --source ./my-langchain-project --dest ./my-connic-project

  Scanning source project...
  Framework: langchain
  Agents found: 3
  Tools found: 8

  Generated Connic project in ./my-connic-project
  Running validation...

  Migration complete
    Projekt: ./my-connic-project
    Report:  ./my-connic-project/MIGRATION_REPORT.md

Die CLI automatisiert die strukturellen Schritte:

Was automatisch und was manuell migriert wird

Nicht alles wird automatisch migriert. Das ist eine realistische Aufteilung:

Automatisch

• Agentendefinitionen (create_agent, create_react_agent, LlmAgent, SequentialAgent)
• Tool-Funktionen (Decorators entfernt, Logik erhalten)
• Aus Funktionsargumenten extrahierte System-Prompts
• Erkennung und Normalisierung von KI-Modellnamen
• Dateiübergreifende Importe und Tool-Abhängigkeiten
• Erzeugung der requirements.txt aus den Abhängigkeiten des Quellcodes

Manuelle Prüfung erforderlich

• Komplexe Orchestrierungs-Workflows: LangGraph-Zustandsgraphen, parallele Ausführung und bedingtes Routing müssen als Sequential-Agenten oder eigene Tool-Logik neu strukturiert werden
• RAG-Pipelines: Retrieval-Chains sollten auf das integrierte Retrieval umgestellt oder als Tools neu implementiert werden
• Zustand und Speicher: Checkpointer und eigene Speicher sollten durch persistente Sessions oder die verwaltete Datenbank ersetzt werden
• Callbacks und Hooks: Framework-Callbacks sollten in Middleware umgewandelt werden
• Tracing-Integrationen: LangSmith oder eigenen Tracing-Code entfernen, sobald die integrierte Connic-Observability ihn ersetzt

Die Struktur eines Connic-Projekts

Nach der Migration folgt das Projekt einer klaren, bewusst vorgegebenen Struktur. Dieselbe Struktur gilt für migrierte und neue Projekte:

my-project/
├── agents/              # YAML agent configurations
│   ├── support.yaml
│   └── classifier.yaml
├── tools/               # Python tool functions
│   ├── support.py
│   └── classify.py
├── middleware/           # Before/after hooks
├── guardrails/          # Custom safety checks
├── schemas/             # Output schemas
└── requirements.txt     # Dependencies

Im Unterschied zu Framework-Projekten sind Konfiguration und Logik getrennt. Agentendefinitionen stehen in deklarativem YAML, die Tool-Logik in reinem Python. Framework-Boilerplate, Runner-Skripte und eine selbst zu pflegende Deployment-Konfiguration entfallen.

Was Teams nach der Migration erhalten

Nach der Migration übernimmt Connic die Anforderungen des Produktivbetriebs:

Schrittweise Migrationscheckliste

Unabhängig davon, ob ein Team die automatisierte CLI verwendet oder manuell migriert, sieht der Ablauf so aus:

• 1.Migration ausführen: connic migrate --source ./your-project --dest ./connic-project
• 2.Migrationsbericht lesen. Jeden offenen Punkt in MIGRATION_REPORT.md bearbeiten
• 3.Agentenkonfigurationen prüfen. Jede YAML-Datei in agents/ öffnen und System-Prompt, KI-Modell und Tool-Verweise prüfen
• 4.Tool-Importe prüfen. Sicherstellen, dass die Funktionen in tools/ alle Abhängigkeiten enthalten
• 5.Framework-Code entfernen. Ersetzte LangSmith-Integrationen, eigene Runner und Deployment-Skripte löschen
• 6.Komplexe Muster neu strukturieren. RAG-Pipelines in Retrieval-Tools, Callbacks in Middleware und Zustände in Sessions umwandeln
• 7.Entwickeln und testen. connic lint ausführen, mit connic dev entwickeln und connic test ausführen, wenn das Projekt eine deklarative Test-Suite besitzt
• 8.Agenten bereitstellen. connic deploy ausführen oder in das verbundene Git-Repository pushen

Was nach der Migration bleibt

Bei der Migration von LangChain oder ADK müssen bestehende Agenten nicht neu geschrieben werden. Wiederverwendbare Tool-Logik bleibt meist gleich. Geändert wird die Infrastruktur rundherum: Deployment, Observability, Retries, Guardrails und Integrationen, die Connic ab dem ersten Run bereitstellt.

Die automatisierte CLI übernimmt die strukturelle Konvertierung. Der Migrationsbericht benennt den verbleibenden manuellen Handlungsbedarf. Komplexe Graphen, Persistenz, Retrieval und externe Integrationen müssen weiterhin geprüft werden; Ausgangspunkt ist jedoch ein konvertiertes Projekt.

Detaillierte Anleitungen stehen in den LangChain-Migrationsdokumenten oder den ADK-Migrationsdokumenten. Für ein neues Projekt zeigt der Quickstart die vollständige Einrichtung.