OpenAI-Suchqueries aus Responses parsen: Code und Randfälle

Lies Suchstrings aus den search-Aktionen von web_search_call im Responses-output. Behalte die zugehörige Aktion und den Response-Status. Der herunterladbare Parser erhält die Strings exakt und erfindet weder Queries noch Quellenbeziehungen.

Wenn du Responses-JSON verarbeiten möchtest. Alle Testantworten sind ausdrücklich synthetisch; die Anleitung benötigt keinen bezahlten Aufruf.

Prüfe anschließend ein eigenes ErgebnisDas Offline-Kit braucht keinen API-Schlüssel. Im kostenlosen Tool kannst du später einen separaten, begrenzten Lauf prüfen.Kostenloses Tool öffnen

Erst die Antwort prüfen, dann Suchaktionen lesen

Beginne mit der Aufrufschicht. Ein HTTP-Fehler oder Timeout ist kein erfolgreicher Response mit null Queries. Übergib dem Parser erst eine erhaltene JSON-Antwort; transportbezogene Fehler bleiben eigene Zustände. Das Offline-Beispiel führt selbst keine Anfrage aus und enthält deshalb keine Zugangsdaten.

Der Parser erwartet ein output-Array und wählt web_search_call-Aktionen mit type search. Er unterstützt die offengelegten Felder queries und query. open_page und find_in_page zählen getrennt als Web-Tool-Aufrufe, liefern in diesem Beispiel aber keine Suchqueries. Fehlt ein Suchstring, wird keiner aus der Eingabe oder dem Antworttext ergänzt.

Lade das ZIP herunter, entpacke es und öffne den Ordner fanout-kit-v2 im Terminal. npm ci installiert die im Lockfile festgelegten Abhängigkeiten; danach laufen Tests und Parser offline. Geprüft wurde Node.js 24.15.0. Die Strings in fixtures.mjs sind eigene Lehrdaten und kein neu gespeicherter OpenAI-Response.

Vertiefe das mit eine veröffentlichte OpenAI-Beobachtung lesen.

Nach dem Entpacken ausführen

npm ci --ignore-scripts
npm test
npm run validate

Drei Strings sind nicht drei Aktionen

Das synthetische Beispiel liefert example topic und example cost in einer Aktion, example import in einer zweiten. Der Parser gibt drei Strings und zwei Suchaktionen zurück. Eine flache Query-Liste ist für eine Auswahl nützlich; actions erhält zusätzlich den Zusammenhang, den eine spätere Quellenprüfung braucht.

Die fiktive Quelle example.com/guide bleibt an der ersten Aktion. Weil diese zwei Queries enthält, wird sie keiner einzelnen Query zugeschrieben. Eine Annotation am Antworttext geht in runSources und behält Laufumfang. Auch eine Aktion mit nur einem String beweist noch nicht, dass jede erwähnte Quelle ausschließlich diesen String beantwortet; das Lehrbeispiel bleibt bei Aktionsumfang.

Führe den kurzen Code im Kit-Ordner aus oder speichere ihn dort als eigene .mjs-Datei. Der Rückgabewert ist der Vertrag des Lehr-Parsers, nicht der JSON-Export der Website. Verwende einen eigenen Adapter, wenn dein Verbraucher einen anderen Vertrag benötigt, und halte die ursprünglichen Beleggrenzen fest.

Vertiefe das mit den Quellenumfang prüfen.

Synthetische Antwort offline parsen

import { parseOpenAiResponse } from "./parsers.mjs";
import { fixtures } from "./fixtures.mjs";
const result = parseOpenAiResponse(fixtures.openai);
console.log(result.queries); // three exposed strings
console.log(result.searchActionCount); // 2
console.log(result.actions[0].sourceScope); // search_action

Teilantworten, Normalisierung und Versionsgrenzen

Eine incomplete-Antwort mit sichtbaren Strings wird partial. Ohne sichtbare Strings bleibt ihre Zahl unbekannt. completed mit gültigem output, aber ohne Suchstrings, liefert null sichtbare Strings. Fehlender Status bleibt unknown; ein fehlerhaftes Containerfeld löst INVALID_RESPONSE aus. Damit bleiben unterschiedliche Fehlerklassen im Ergebnis sichtbar.

Der Lehr-Parser erhält Unicode, Großschreibung, Leerzeichen, Duplikate und Reihenfolge. Der aktuelle Website-Wrapper normalisiert dagegen NFC, trimmt, dedupliziert und begrenzt die sichtbare Liste auf acht Strings. Er zählt außerdem web_search_call-Objekte und verwendet teils Ersatzmetadaten. Diese absichtlichen Unterschiede sind im README beschrieben; kopiere das Beispiel nicht als ungeprüften Produktionsersatz.

Vertiefe das mit die Parser-Prüfungen ausführen.

Die Tests prüfen den Vertrag vom 10. Oktober 2026. Sie belegen das Verhalten des Codes an den enthaltenen Fällen, keine vollständige Abdeckung zukünftiger Provider-Antworten. Ergänze einen neuen Test, wenn sich ein Feld oder eine Aktion ändert. Ein bestandener Parser-Test belegt weder menschliches Suchvolumen noch eine stabile KI-Zitation.

Verwendete Quellen

Diese Quellen stützen die beschriebenen Funktionen und Grenzen. Sie belegen keine darüber hinausgehenden Aussagen.

OpenAI Responses: Felder der Web-Suchaktionen
Stützt offengelegte Query-Felder, getrennte search/open/find-Aktionstypen und URL-Annotationen. Die Dokumentation gewährt keinen privaten Endnutzer-Trace und garantiert keine sichtbaren Strings in jedem Lauf.
Quelle öffnen
Eigenes ausführbares Offline-Parser- und Randfall-Testkit
Eigener Lehrcode und 27 Offline-Prüfungen. Synthetische Antwortstrukturen sind keine Provider-Ausgaben. Geprüft werden Strings, Status, Quellenumfang und ausgeschlossene Payloads. Kein bezahlter Aufruf oder neues reales Grounding-Material; der Lehr-Parser unterscheidet sich ausdrücklich vom Website-Wrapper.
Quelle öffnen
Aktuelle Website-Exportverträge und Referenzvalidierung
Draft-2020-12-Referenz für aktuelle native/modellierte Vollruns, Query-Auswahlen und lokale Vergleiche. Geprüft gegen tatsächliche Service-/Exportfunktionen mit synthetischen Provider-Stubs und negativen Semantiktests. Vollruns erhalten keine erfundene root-schemaVersion; ältere Planner- und Handoff-Formate bleiben getrennt.
Quelle öffnen