Design wechseln

Continuum: Worauf Sie bei einer OpenAI-kompatiblen Agent Runtime achten sollten

Easton editorial illustration: seven-slot runtime readiness console centered on a durable execution core

"Die Continuum-Dokumentation beschreibt Positionierung, Python 3.13, Smart Inference, MCP-native Tools, dauerhafte Temporal-Workflows, Langfuse-Tracing und neun Multi-Agent-Patterns."

"Das Continuum-GitHub-Repository ist die primäre Quelle für Installation, APIs, Modulnamen und Projektreife."

"Das MCP-Tool-Ökosystem verändert sich schnell; Aussagen zu Serverzahlen und breiter Anbieterunterstützung sollten daher vorsichtig formuliert und regelmäßig geprüft werden."

Läuft Ihr Agent noch im Notebook? Dann fehlt wahrscheinlich eine produktionsreife Runtime. Frameworks gibt es genug: LangGraph, CrewAI, AutoGen, DeepAgents. Die Namen kennen viele, aber bei der echten Auswahl geht es darum, welche Dimensionen Sie bewerten müssen.

Continuum ist eine Enterprise-Agent-Runtime von ShyftLabs mit klarer Positionierung: gebaut für Teams, die liefern müssen. Es ist kein Prototyping-Tool und kein Notebook-Spielzeug, sondern ein Python-Framework, das Multi-Agent-Kollaboration, Kostenkontrolle, dauerhafte Ausführung und Observability hinter einer type-safe API bündelt.

Wenn Sie eine Agent Runtime bewerten, läuft es auf sieben Dimensionen hinaus: Orchestrierungsmuster, Modellrouting, Speicher, Tool-Standards, dauerhafte Ausführung, Observability und Deployment-Governance. Continuum ist nur ein Beispiel, aber dieses vollständige Bewertungsraster sollte die Entscheidung tragen.

Positionierung: Was Continuum ist und warum es als Beispiel dient

Eine Agent Runtime sollte einen klaren Agent Core, Multi-Model Reasoning, zustandsbehafteten Speicher, Tool Calling, dauerhafte Ausführung und Observability zu einem kombinierbaren Produktionssystem bündeln.

Continuum zeigt diese sechs Fähigkeiten recht vollständig:

  • typisierter Agent Core (BaseAgent, AgentRunner)
  • Multi-Model Inference, laut Projekt mit Unterstützung für 250+ Modelle und 45+ Provider
  • Kurzzeit- und Langzeitspeicher, mit Redis-Session-Historie plus mem0-Vektorspeicher
  • native MCP-Tool-Unterstützung
  • dauerhafte Temporal-Workflows
  • Langfuse-Tracing für Observability

Continuum ist nicht die einzige Antwort. Es ist aber ein vollständiges Beispiel dafür, welche Bausteine eine produktionsreife Runtime mitbringen sollte.

Auswahlframework: 7 Kernfähigkeiten für Agent Runtimes

Orchestrierung und Multi-Agent-Muster

Orchestrierung ist die Kernfrage einer Runtime: Unterstützt sie Multi-Agent-Kollaboration, und welche Muster bietet sie?

Continuum stellt neun Multi-Agent-Muster bereit:

MusterEinsatzzweck
sequentialmehrere Agents nacheinander ausführen
parallelunabhängige Tasks parallel ausführen
loopiterieren, bis eine Bedingung erfüllt ist
routingEingaben an unterschiedliche Agents weiterleiten
planningein Ziel in Teilaufgaben zerlegen
reflectioneinen Agent seine eigene Arbeit prüfen und verbessern lassen
debatemehrere Agents um eine Entscheidung konkurrieren oder verhandeln lassen
scatterAufgaben verteilen und Ergebnisse zusammenführen
supervisedÜberwachung und Human Review an kritischen Stellen einfügen

Auswahlfrage: Welche Muster braucht Ihr Szenario, und unterstützt die Runtime diese Muster?

Wenn Ihr Agent nur eine single-threaded sequenzielle Ausführung braucht, reicht sequential möglicherweise aus. Wenn es um parallele Aufgaben, Abstimmung zwischen Agents oder menschliche Freigabe an kritischen Stellen geht, sollten Sie prüfen, ob die Runtime parallel, debate und supervised unterstützt. Für ein praktisches LangGraph-Orchestrierungsbeispiel siehe LangGraph State Management in der Praxis.

Modellzugang und Kostenrouting

Modellunabhängigkeit ist die erste Frage: Unterstützt die Runtime mehrere Modelle wie OpenAI, Claude, Llama oder lokale Modelle? Ist sie OpenAI-kompatibel?

Continuum ist so aufgebaut, dass der Agent nur einen OpenAI-kompatiblen Endpoint aufruft. Dahinter verteilt Smart Inference Anfragen laut Projekt über 250+ Modelle hinweg nach Komplexität und Kosten. Dieses Design hat einige zentrale Konzepte:

  • ein Endpoint: Der Agent muss das konkrete Modell nicht kennen und ruft nur SMART_GATEWAY_URL auf
  • Classifier-Routing: Smart Inference wählt ein Modell nach Task-Komplexität und Kostenbudget
  • Budget-Ledger: dynamische Ausgabelimits sollen Token-Explosionen verhindern
  • Qualitätsstufen: pro Agent lassen sich Stufen wie strict, modest oder quality wählen

Auswahlfrage: Hat die Runtime kostenbewusstes Routing? Können Qualitätsstufen pro Agent unterschiedlich sein?

Kostenkontrolle bedeutet nicht nur, Geld zu sparen. Es geht darum, ausufernde Rechnungen zu verhindern. Multi-Model Calls, Langläufer und wiederholte Reflection-Schleifen können ohne Budgetgrenze und kostenbewusstes Routing deutlich mehr Token verbrauchen als erwartet.

Speicher: Kurzzeit-Sessions plus Langzeit-Vektorspeicher

Speicher ist die Kontextbasis eines Agents. Kurzzeit-Session-Historie unterstützt die aktuelle Konversation, Langzeit-Vektorspeicher ermöglicht Retrieval über Sessions hinweg.

Continuums Umsetzung:

  • kurzfristig: Redis-Session-Historie im Session-Modul
  • langfristig: mem0 plus Qdrant/Milvus-Vektorspeicher im Memory-Modul

Auswahlfrage: Trennt die Runtime Kurzzeit- und Langzeitspeicher? Sind Vektordatenbank-Integrationen flexibel?

Wenn Ihr Agent nur die aktuelle Konversation braucht, reichen Redis oder In-Memory-State oft aus. Wenn er Nutzerpräferenzen, historische Entscheidungen oder Projektdokumente über Sessions hinweg abrufen soll, prüfen Sie, ob die Runtime Vektorspeicher unterstützt und ob sich Vektordatenbanken wie Qdrant, Milvus oder Chroma austauschen lassen. Mehr zum Design von Speichersystemen finden Sie unter Agent Memory System Design.

Tool-Standards: native MCP-Unterstützung

Tool Calling ist die Hand des Agents. Welche Protokollschicht sollte sie nutzen?

MCP (Model Context Protocol) ist zu einem wichtigen Standard für Tool-Integrationen von AI Agents geworden. MCP nutzt JSON-RPC-Transport und bietet drei Primitive: Tools, Resources und Prompts.

Continuums Umsetzung: native MCP-Server-Unterstützung über ein einheitliches ToolExecutor-Interface.

Auswahlfrage: Ist die Runtime MCP-nativ oder nutzt sie eine Custom API?

Native MCP-Unterstützung bedeutet, dass Sie bestehende MCP-Server für Dateisysteme, Datenbanken, API-Tools und mehr nutzen können, ohne einen eigenen Protokolladapter zu schreiben. Nutzt eine Runtime eine Custom API, pflegen Sie einen weiteren Tool-Interface-Standard, und die Erweiterung des Ökosystems wird teurer. Für den Einstieg in MCP Server siehe MCP Server entwickeln: Grundlagen.

Dauerhafte Ausführung und menschliche Freigabe

Lang laufende Tasks brauchen Dauerhaftigkeit: Wiederaufnahme ab Checkpoints und Pausen für Approval Gates.

Continuum nutzt dauerhafte Temporal-Workflows und unterstützt:

  • Wiederaufnahme nach Unterbrechung: Nach einem Abbruch am unterbrochenen Punkt fortsetzen
  • Approval Gates: An kritischen Knoten vor der Fortsetzung menschliche Freigabe verlangen

Auswahlfrage: Unterstützt die Runtime dauerhafte Ausführung? Kann Human Review den Ablauf unterbrechen und wieder aufnehmen?

Wenn ein Agent-Task stundenlang laufen kann oder kritische Entscheidungen wie Überweisungen, Veröffentlichungen oder Freigaben betrifft, sind dauerhafte Ausführung und Human Review Produktionsanforderungen. Sonst kann ein Netzwerkfehler oder Timeout den ganzen Task verlieren, oder der Agent läuft an einer Stelle weiter, an der er hätte pausieren müssen.

Observability: Tracing, Metriken und Fehlerberichte

Agent-Ausführungsketten sind lang, daher ist Observability eine Produktionsanforderung.

Continuum integriert Langfuse-Tracing und bietet:

  • Execution Tracing für jeden Agent, jeden Model Call und jeden Tool Call
  • Metriken wie Latenz, Kosten und Erfolgsrate
  • Fehlerberichte für Exceptions, Timeouts und fehlgeschlagene Knoten

Auswahlfrage: Enthält die Runtime eine Tracing-Integration? Wie stark ist ihr Error Tracking?

Ohne Tracing ist ein Agent-System in Produktion eine Black Box. Sie wissen nicht, welcher Knoten langsam ist, welcher Model Call fehlschlägt oder welches Tool timeoutet. Debugging fällt dann auf Log-Grep zurück. Für Monitoring- und Recovery-Design siehe AI-Agent-Monitoring, Alerts und Fehlerwiederherstellung.

Deployment und Governance: Self-Hosting, Cloud-Unabhängigkeit und Enterprise Compliance

Deployment-Modell: self-hosted und cloud-unabhängig.

Continuum ist als Enterprise- und Self-Hosted-Lösung positioniert. Es hängt von Docker, Redis, Vektordatenbanken, Temporal und Langfuse ab, die alle auf eigener Infrastruktur laufen können.

Auswahlfrage: Unterstützt die Runtime Self-Hosting? Bringt sie ein Enterprise-Governance-Design mit?

Wenn Ihr Projekt verlangt, dass Daten im Unternehmen bleiben, oder wenn Audit- und Compliance-Nachweise erforderlich sind, wird Self-Hosting zur harten Bedingung. Hängt eine Runtime stark von Managed Services eines bestimmten Cloud-Anbieters ab, kann Data Compliance unmöglich werden.

Fähigkeitscheckliste: Continuum als vollständige Tabelle

Nutzen Sie diese Tabelle, um Continuums Fähigkeiten mit anderen Runtimes zu vergleichen.

ModulFähigkeitUmsetzungAuswahlfrage
Agent Coretypisierte Agents, BaseAgent, AgentRunnerPython Type SafetyGibt es ein typisiertes Design?
Multi-Agent-Orchestrierungneun Muster wie sequential, parallel und routingorchestrator.agentUnterstützt es mehrere Orchestrierungsmuster?
ModellroutingSmart-Inference-Kostenroutingein Endpoint plus Classifier-RoutingGibt es Kostenkontrolle?
SpeicherKurzzeit-Sessions plus Langzeit-VektorspeicherRedis + mem0 + Qdrant/MilvusTrennt es Kurzzeit- und Langzeitspeicher?
Toolsnative MCP-Server-Unterstützungeinheitliches ToolExecutor-InterfaceIst es MCP-nativ?
dauerhafte AusführungTemporal-Workflows und Checkpoint-RecoveryTemporal-ModulUnterstützt es dauerhafte Ausführung?
ObservabilityTracing, Metriken und FehlerberichteLangfuse-IntegrationGibt es Tracing-Integration?
Deploymentself-hosted und cloud-unabhängigDocker + Redis + VektordatenbankUnterstützt es Self-Hosting?

Das ist kein Produktpitch für Continuum. Es ist ein Auswahlframework: Jede Zeile ist eine Dimension, und jede Dimension führt zu einer Frage, die Sie beantworten müssen.

Vergleich ähnlicher Frameworks: Wo Continuum im Ökosystem steht

Wichtige Agent-Runtime-Optionen im Jahr 2026:

FrameworkProduktionsreifeKostenroutingMCP-Unterstützungdauerhafte AusführungPositionierung
LangGraphhochnicht eingebautIntegration nötigjagraphbasierte Runtime mit reifem Ökosystem
DeepAgentshochübernimmt LangGraphIntegration nötigjaBattery-included Harness auf Basis von LangGraph + LangChain
ContinuumhochSmart InferencenativTemporalEnterprise-Self-Hosting mit besonderem Kostenrouting
CrewAImittelkeinesIntegration nötigneineinfache Multi-Agent-Orchestrierung
OpenAI Swarmniedrig, experimentellkeineskeinesneinleichtgewichtiges Experiment, nicht für Produktion

Continuums besondere Kombination ist Smart-Inference-Kostenrouting, native MCP-Unterstützung und Enterprise-Self-Hosting.

Bei der Auswahl sind LangGraph und DeepAgents in der Produktionsreife ausgereifter, während Continuum beim Kostenrouting und bei nativem MCP ein eigenes Profil hat. Wenn Ihr Szenario kostenkritisch ist und das MCP-Tool-Ökosystem braucht, lohnt sich ein genauer Blick auf Continuums Design. Einen Vergleich von State Tracking in LangGraph und AutoGen finden Sie unter LangGraph vs AutoGen State Tracking.

Einstiegskosten und Risiken

Abhängigkeitsliste

Continuum ist kein leichtgewichtiges Framework, bei dem pip install die Sache erledigt. Eine Enterprise Runtime bringt Infrastrukturvoraussetzungen mit:

  • Python 3.13+
  • Docker
  • Redis für Session-Historie
  • Qdrant / Milvus für Vektorspeicher
  • Temporal für dauerhafte Workflows
  • Langfuse für Observability

Installationsbeispiel

# Installation
git clone https://github.com/shyftlabs/continuum
cd continuum
python3.13 -m venv .venv && source .venv/bin/activate
pip install -e ".[dev]"
docker compose up -d
echo "SMART_GATEWAY_URL=https://continuum.shyftops.io/v1" >> .env

# Minimale Form
python - <<'PY'
from orchestrator.agent import BaseAgent
from orchestrator.agent.runner import AgentRunner

agent = BaseAgent(
    name="assistant",
    instructions="You are a helpful assistant.",
    model="gpt-4o-mini",
)

# In einem echten Projekt folgen Sie den offiziellen Docs für async runner,
# session, memory und gateway configuration.
PY

docker compose up -d startet nur einen Teil der lokalen Infrastruktur. Für Production Deployment brauchen Sie zusätzlich Temporal, Langfuse, Provider Keys und Netzwerkberechtigungen. Die offizielle Dokumentation bleibt die Source of Truth.

Geeignete Szenarien

  • Enterprise-Projekte, die Kostenkontrolle, Dauerhaftigkeit und Observability brauchen
  • Self-Hosting-Anforderungen, bei denen Daten im Unternehmen bleiben und Cloud-Unabhängigkeit wichtig ist
  • Multi-Agent-Kollaboration mit mehreren Orchestrierungsmustern
  • kostenkritische Workloads, die Smart-Inference-Routing benötigen

Risikohinweise

  • Neues Projekt: etwa 70+ GitHub Stars im Zeitraum 2026-06, APIs oder Modulnamen können sich ändern.
  • Kostenangaben prüfen: 250+ Modelle und 45+ Provider sind projektseitige Angaben und sollten getestet werden.
  • Begrenzung: Die Abhängigkeit von Temporal und Langfuse passt schlecht zu leichtgewichtigen Szenarien.
  • Dokumentationsabhängigkeit: Beispiele sollten minimal bleiben, Details gehören in die offiziellen Docs.

Fazit: Bauen Sie Ihr eigenes Auswahlframework für Agent Runtimes

Die Auswahl einer Agent Runtime läuft auf sieben Dimensionen hinaus:

  1. Orchestrierungsmuster: Unterstützt sie Multi-Agent-Kollaboration, und welche Muster brauchen Sie, etwa sequential, parallel, routing, planning und reflection?
  2. Modellrouting: Gibt es kostenbewusstes Routing, und kann es ausufernde Rechnungen verhindern?
  3. Speichersystem: Trennt es Kurzzeit- und Langzeitspeicher, und sind Vektordatenbank-Integrationen flexibel?
  4. Tool-Standards: Ist es MCP-nativ, und kann es das bestehende MCP-Server-Ökosystem nutzen?
  5. Dauerhafte Ausführung: Unterstützt es Checkpoint-Recovery und menschliche Freigabe?
  6. Observability: Gibt es Tracing-Integration, und wie gut lassen sich Fehler verfolgen?
  7. Deployment-Governance: Ist es self-hosted und cloud-unabhängig, und unterstützt es Enterprise-Compliance-Anforderungen?

Continuum ist ein nützliches Beispiel, weil es einen vollständigen Produktions-Runtime-Stack zeigt: neun Multi-Agent-Muster, Smart-Inference-Kostenrouting, native MCP-Unterstützung, dauerhafte Temporal-Ausführung und Langfuse-Tracing. Auswahl bedeutet aber nicht Nachahmung. Gewichten Sie diese Dimensionen gegen Ihr eigenes Szenario und vergleichen Sie Continuum dann mit LangGraph, DeepAgents und CrewAI.

Nächster Schritt: Schreiben Sie Ihre Szenarioanforderungen auf und bewerten Sie jede Runtime entlang dieser sieben Dimensionen.

So bewerten Sie, ob eine Agent Runtime produktionsreif ist

Nutzen Sie Continuum als Referenz und prüfen Sie in sieben Dimensionen, ob eine Agent Runtime vom Demo zur Produktion taugt.

⏱️ Estimated time: 30 min

  1. 1

    Step 1: Orchestrierungsmuster klären

    Listen Sie auf, ob Ihre Agents Kollaborationsmodi wie sequential, parallel, routing, planning, reflection, debate oder supervised execution benötigen.
  2. 2

    Step 2: Modellrouting und Budgets prüfen

    Prüfen Sie, ob die Runtime OpenAI-kompatible Endpoints, Multi-Provider-Routing, Qualitätsstufen und Budgetlimits pro Task unterstützt.
  3. 3

    Step 3: Kurzzeit- und Langzeitspeicher trennen

    Entwerfen Sie aktuelle Session-Historie, sitzungsübergreifende Präferenzen, Projektwissen und löschbaren Speicher getrennt, statt nur zu fragen, ob eine Vektordatenbank unterstützt wird.
  4. 4

    Step 4: Tool-Protokoll bewerten

    Bevorzugen Sie eine Runtime, die MCP nativ unterstützt oder zuverlässig an MCP angebunden werden kann, damit Sie später kein privates Tool-Protokoll pflegen müssen.
  5. 5

    Step 5: Fehlerwiederherstellung und menschliche Freigabe testen

    Simulieren Sie Provider-Timeouts, Worker-Neustarts, Tool-500-Antworten und Approval-Pausen, um zu sehen, ob der Task sicher wiederhergestellt, degradiert oder pausiert werden kann.

FAQ

Was ist Continuum?
Continuum ist die Enterprise-Python-Agent-Runtime von ShyftLabs. Sie soll Multi-Agent-Kollaboration, Modellrouting, Speicher, Tool Calling, dauerhafte Ausführung und Observability zu einem Produktionssystem verbinden. Es ist kein offizielles OpenAI-Produkt; die OpenAI-Formulierung im Titel bezieht sich vor allem auf die Suchintention und das OpenAI-kompatible Endpoint-Modell.
Was ist bei der Auswahl einer Agent Runtime am wichtigsten?
Nutzen Sie sieben Dimensionen: Orchestrierungsmuster, Modellzugang und Kostenrouting, Kurzzeit- und Langzeitspeicher, Tool-Standards, dauerhafte Ausführung mit menschlicher Freigabe, Tracing und Fehlerberichte sowie Deployment-Governance. Ein Demo, das einmal läuft, kann genau die Wiederherstellungs-, Budget- und Auditprobleme verdecken, die in Produktion am meisten schmerzen.
Warum ist Continuums Smart Inference nützlich?
Smart Inference legt die Modellauswahl hinter einen OpenAI-kompatiblen Endpoint. Eine Routing-Schicht wählt Modelle nach Komplexität, Kosten und Qualitätsstufen aus. Der Nutzen liegt nicht nur im Sparen: Modellauswahl, Budgetlimits und Provider-Fallbacks wandern aus dem Business-Code heraus.
Passt Continuum zu leichtgewichtigen Agent-Projekten?
Meist nicht. Der vollständige Funktionsumfang von Continuum hängt von Infrastruktur wie Redis, Vektordatenbanken, Temporal und Langfuse ab. Es passt besser zu Multi-Agent-, Langläufer-, budgetkritischen und auditierbaren Produktionssystemen als zu einem kleinen Single-Agent-Skript.
Wie sollte ich eine Agent Runtime vor dem Rollout validieren?
Führen Sie nicht nur das Happy-Path-Demo aus. Trennen Sie Redis, stoppen Sie einen Provider, lassen Sie ein Tool 500 zurückgeben, starten Sie einen Worker neu und lassen Sie die Vektordatenbank kein Ergebnis liefern. Prüfen Sie dann, ob der Task wiederholt, degradiert, pausiert oder sauber fehlschlägt und ob Traces, Budgets, Freigaben und nutzer sichtbarer Status klar bleiben.

9 Min. Lesezeit · Veröffentlicht am: 8. Juni 2026 · Aktualisiert am: 14. Juli 2026

Kommentare

Melde dich mit GitHub an, um einen Kommentar zu hinterlassen

Easton BlogEaston Blog