- Ein Open-Source-Standard und Ökosystem mit dem Ziel der Interoperabilität zwischen mehreren LLM-Anbietern, das auf der OpenAI Responses API basiert und eine gemeinsame Schnittstelle definiert
- Beschreibt Anfragen und Antworten mit einem gemeinsamen Schema, sodass sie mit minimalem Konvertierungsaufwand bei verschiedenen Modellanbietern auf dieselbe Weise ausgeführt werden können
- Organisiert gemeinsame Komponenten wie Nachrichten, Tool-Aufrufe, Streaming und multimodale Eingaben in einer konsistenten Struktur und eignet sich damit für die Implementierung von Agent-Workflows
- Verfolgt gleichzeitig Erweiterbarkeit und Nicht-Fragmentierung, indem auf einem stabilen Kern anbieterspezifische Erweiterungen erlaubt werden
- Wird gemeinschaftsbasiert von zahlreichen teilnehmenden Buildern wie OpenRouter, Vercel, Hugging Face, LM Studio, Ollama, OpenAI und vLLM betrieben
Überblick
- Open Responses ist ein Open-Source-Standard und Tool-Ökosystem, das auf der OpenAI Responses API basiert
- Es wurde so entworfen, dass Aufrufe von Sprachmodellen, die Verarbeitung von Streaming-Ergebnissen und der Aufbau von Agenten anbieterunabhängig möglich sind
- Über ein gemeinsames Schema und eine Tooling-Schicht bietet es die Erfahrung einer einheitlichen Schnittstelle
Warum Open Responses?
- LLM-APIs teilen ähnliche Komponenten wie Nachrichten, Tool-Aufrufe, Streaming und multimodale Eingaben, verwenden jedoch jeweils unterschiedliche Kodierungsformen
- Open Responses stellt einen offenen gemeinsamen Standard bereit, der diese vereinheitlicht und den Aufwand für doppelte Implementierungen reduziert
- Einmal definierte Anfrage- und Ausgabestrukturen lassen sich bei mehreren Anbietern wiederverwenden
Designprinzipien
- Mit einem Multi-Anbieter-First-Design kann ein einzelnes Schema auf verschiedene Modellanbieter abgebildet werden
- Für Streaming-Events, Tool-Aufrufmuster und als kleinste Einheit von Modellausgaben wird das Items-Konzept verwendet, was eine agentenfreundliche Struktur schafft
- Nicht verallgemeinerbare Funktionen dürfen als anbieterspezifische Erweiterungen ergänzt werden, wobei die Stabilität des Kerns Vorrang hat
Community und Ökosystem
- Wird als offenes Community-Projekt betrieben, das eine Multi-Vendor-Umgebung voraussetzt
- Verschiedene Organisationen wie OpenRouter, Vercel, Hugging Face, LM Studio, Ollama, OpenAI und vLLM sind mit ihren Logos als Beteiligte aufgeführt
- Es bildet sich eine entwicklerzentrierte Community, die Portabilität, Interoperabilität und eine gemeinsame Grundlage betont
Merkmale der Spezifikation
- Mit einem Items-zentrierten gemeinsamen Schema werden Nachrichten, Tool-Aufrufe und Inferenzzustände in derselben Einheit dargestellt; sowohl Eingaben als auch Ausgaben bewegen sich als Items durch das System
- Antworten und Items werden als Zustandsmaschine definiert, sodass Lebenszyklen wie
in_progress→completed/failed/incomplete explizit verwaltet werden
- Streaming wird nicht als Textfragmente, sondern als semantic events standardisiert; das feste Muster beginnt mit
response.output_item.added und endet über delta→done
- Tools werden in externe Ausführung (Entwickler/Drittanbieter) und interne Ausführung (anbietergehostet) unterteilt; mit
tool_choice/allowed_tools gibt es eine Steuerungsebene, die den aufrufbaren Bereich erzwingt
- Mit
previous_response_id rekonstruiert der Server frühere Eingaben und Ausgaben als Kontext und unterstützt so Fortsetzung von Konversationen/minimierte erneute Übertragung; mit truncation kann zwischen „Abschneiden erlaubt“ und „bei Überschreitung fehlschlagen“ gewählt werden
- Erweiterungen außerhalb des Standards werden mit dem Präfix
provider_slug: getrennt; benutzerdefinierte hosted tools müssen einen entsprechenden Item-Typ bereitstellen, damit ein protokollierbarer, roundtrip-fähiger „Beleg“ hinterlassen wird
- Fehler werden als strukturiertes Error-Objekt zurückgegeben, und Fehler während des Streamings enden mit dem Event
response.failed
Noch keine Kommentare.