Open Agent SDK: Flexible LLM-Anbieter und Echtzeit-Steuerung im Überblick

Die Auswahl des richtigen Sprachmodells (LLM) entscheidet oft über Effizienz und Kosten in KI-Anwendungen. Doch was, wenn eine einzige Aufgabe mehrere Modelle erfordert? Der Open Agent SDK löst dieses Problem durch eine flexible Architektur, die nahtlos zwischen Anbietern wie Anthropic, OpenAI und lokalen Modellen wechseln lässt – und das sogar während der Laufzeit.

Mit einem einheitlichen LLMClient-Protokoll und dynamischen Steuerungsoptionen zeigt der SDK, wie Entwickler ihre KI-Agenten an wechselnde Anforderungen anpassen können – ohne Code-Änderungen. Dieser Artikel beleuchtet die technischen Grundlagen und zeigt, wie Runtime-Kontrollen wie Thinking-Tiefe und Budgetüberwachung funktionieren.

Ein einheitliches Protokoll für alle LLM-Anbieter

Der Kern des Open Agent SDKs ist das LLMClient-Protokoll, das eine konsistente Schnittstelle für alle unterstützten Sprachmodell-Anbieter definiert. Dieses Protokoll umfasst zwei zentrale Methoden:

• sendMessage: Eine blockierende Anfrage, die eine vollständige Antwort des Modells liefert.
• streamMessage: Eine asynchrone Streaming-Methode für Echtzeit-Antworten.

Beide Methoden akzeptieren identische Parameter, darunter:

• model: Identifiziert das zu verwendende Sprachmodell.
• messages: Die Nachrichtenhistorie für den Kontext.
• maxTokens: Begrenzt die Ausgabe in Tokens.
• system: Der System-Prompt für das Modell.
• tools: Definiert verfügbare Tools (z. B. Funktionen für die Tool-Nutzung).
• toolChoice: Legt fest, ob und wie Tools eingesetzt werden sollen.
• thinking: Konfiguriert die "Extended Thinking"-Funktionalität.
• temperature: Steuert die Kreativität der Antworten.

Ein entscheidender Designaspekt ist die standardisierte Antwortstruktur: Unabhängig vom verwendeten Anbieter liefert das SDK Antworten im Anthropic-Format. Dies bedeutet, dass Entwickler nicht zwischen verschiedenen API-Antwortformaten unterscheiden müssen. Die Antworten enthalten stets:

• Ein content-Array mit Blöcken des Typs text oder tool_use.
• Ein stop_reason-Feld, das den Grund für den Abbruch angibt (z. B. end_turn, tool_use oder max_tokens).

Für Streaming-Antworten nutzt das SDK ein AsyncThrowingStream-Modell mit dem SSEEvent-Enum. Dieses Enum definiert sieben Ereignistypen, die alle relevanten Streaming-Events abdecken:

public enum SSEEvent: @unchecked Sendable {
    case messageStart(message: [String: Any])
    case contentBlockStart(index: Int, contentBlock: [String: Any])
    case contentBlockDelta(index: Int, delta: [String: Any])
    case contentBlockStop(index: Int)
    case messageDelta(delta: [String: Any], usage: [String: Any])
    case messageStop
    case ping
    case error(data: [String: Any])
}

Diese Struktur stellt sicher, dass Streaming-Antworten – unabhängig vom zugrunde liegenden Anbieter – konsistent verarbeitet werden können.

AnthropicClient: Native Integration für Claude-Modelle

Der AnthropicClient ist die native Implementierung des LLMClient-Protokolls für Anthropic-Modelle wie Claude. Er nutzt das actor-Modell für sichere Nebenläufigkeit und kommuniziert direkt mit der Anthropic-API über den Endpunkt /v1/messages.

Die Initialisierung erfordert lediglich einen API-Schlüssel und optional eine benutzerdefinierte Basis-URL:

public actor AnthropicClient: LLMClient {
    private let apiKey: String
    private let baseURL: URL
    private let urlSession: URLSession

    public init(apiKey: String, baseURL: String? = nil, urlSession: URLSession? = nil) {
        self.apiKey = apiKey
        self.baseURL = URL(string: baseURL ?? " pic.com")!
        self.urlSession = urlSession ?? URLSession.shared
    }
}

Jede Anfrage wird als POST an /v1/messages gesendet und enthält die Header x-api-key sowie anthropic-version. Die Anfragekörper werden direkt aus den Parametern des LLMClient-Protokolls konstruiert, da Anthropic native Unterstützung für erweiterte Funktionen wie thinking bietet.

Ein wichtiger Sicherheitsaspekt ist die Maskierung des API-Schlüssels in Fehlermeldungen, um unbeabsichtigte Protokollierung zu vermeiden:

let safeMessage = errorMessage.replacingOccurrences(of: apiKey, with: "***")

OpenAI-kompatible Schicht: Flexibilität für externe Anbieter

Der OpenAIClient fungiert als Adapter für alle OpenAI-kompatiblen Anbieter wie GLM, Ollama oder OpenRouter. Sein Ziel ist es, die Anthropic-konformen Eingaben des LLMClient-Protokolls in das OpenAI-Format zu konvertieren und umgekehrt die OpenAI-Antworten zurück in das Anthropic-Format zu übersetzen. Entwickler bleiben dadurch von den Details der zugrunde liegenden API unberührt.

Die Implementierung ähnelt der des AnthropicClient, nutzt jedoch den Endpunkt /chat/completions mit einer Bearer-Token-Authentifizierung – dem Standard für OpenAI-kompatible APIs. Jeder Anbieter, der diesen Endpunkt unterstützt, kann nahtlos integriert werden.

Wichtige Konvertierungsregeln

Mehrere Formatunterschiede zwischen Anthropic und OpenAI erfordern besondere Beachtung:

1. System-Prompt-Position Anthropic erwartet den System-Prompt als separaten Parameter, während OpenAI ihn als erste Nachricht mit der Rolle system behandelt. Der OpenAIClient konvertiert dies automatisch:

if let system {
    result.append(["role": "system", "content": system])
}

2. Tool-Ergebnis-Darstellung Anthropic fasst mehrere tool_result-Blöcke in einer einzigen Nachricht zusammen, während OpenAI jede Tool-Nutzung als separate Nachricht mit der Rolle tool darstellt. Der Adapter aggregiert diese Nachrichten, um das Anthropic-Format zu wahren.

3. Streaming-Antworten OpenAI-kompatible APIs senden Streaming-Antworten als Server-Sent-Events (SSE). Der OpenAIClient wandelt diese in die standardisierten SSEEvent-Objekte des SDKs um, sodass Entwickler eine einheitliche Schnittstelle erhalten.

Dynamische Runtime-Steuerung: Budget, Thinking und Anbieterwechsel

Ein zentrales Feature des Open Agent SDKs ist die Fähigkeit, Anbieter und Modelle während der Laufzeit zu wechseln. Dies ermöglicht es Entwicklern, auf folgende Szenarien zu reagieren:

• Kosteneffizienz: Wechsel zu günstigeren Modellen für einfache Aufgaben.
• Leistungsanforderungen: Nutzung leistungsstarker Modelle für komplexe Analysen.
• Datenschutz: Einsatz lokaler Modelle, wenn sensible Daten verarbeitet werden.
• Budgetkontrolle: Dynamische Anpassung der Token-Nutzung zur Vermeidung von Kostenüberschreitungen.
• Thinking-Tiefe: Erhöhte Denktiefe bei schwierigen Aufgaben.

Die Konfiguration erfolgt über eine zentrale Steuerungsdatei, in der Anbieter, Modelle und Runtime-Parameter definiert werden. Ein Beispiel:

{
  "provider": "anthropic",
  "model": "claude-3-opus-20240229",
  "maxTokens": 4096,
  "thinking": {
    "type": "enabled",
    "budgetTokens": 100000
  },
  "budget": {
    "maxCost": 10,
    "currency": "USD"
  }
}

Durch die Trennung der Konfiguration von der Implementierung können Entwickler diese Parameter sogar während einer aktiven Sitzung anpassen, ohne den Agenten neu starten zu müssen.

Fazit: Ein SDK für zukunftssichere KI-Agenten

Der Open Agent SDK setzt neue Maßstäbe für Flexibilität in der KI-Entwicklung, indem er mehrere LLM-Anbieter unter einer einheitlichen Schnittstelle vereint und Runtime-Steuerungen ermöglicht. Entwickler profitieren von:

• Kosteneffizienz durch gezielte Anbieterauswahl.
• Skalierbarkeit dank dynamischem Anbieterwechsel.
• Datenschutz durch lokale Modellunterstützung.
• Präzision durch standardisierte Antwortformate.

Mit der wachsenden Zahl an Sprachmodellen und Anbietern wird eine solche Abstraktion immer wichtiger. Der Open Agent SDK bietet Entwicklern das notwendige Werkzeug, um KI-Agenten anpassungsfähig und zukunftssicher zu gestalten – ohne Kompromisse bei Leistung oder Kontrolle.