Przegląd
GoModel udostępnia kompatybilne z OpenAI endpointy Responses API pod/v1/responses.
Requesty tworzące odpowiedź przechodzą przez pipeline routingu modeli z translacją, więc
modele wirtualne, workflowy, guardrails, failover, logowanie użycia i cache odpowiedzi
nadal działają. Endpointy cyklu życia i pomocnicze korzystają z natywnych możliwości
providera, gdy są dostępne, i zwracają jawne błędy kompatybilności, gdy wybrany provider
nie obsługuje żądanej operacji.
Opis zachowania poszczególnych funkcji, w tym hostowanych narzędzi i providerów
z translacją do Chat Completions, znajdziesz w Kompatybilności Responses.
Obsługiwane endpointy
Zapisane odpowiedzi
Dla wywołańPOST /v1/responses, o ile request nie ustawia store: false,
GoModel zapisuje znormalizowane body odpowiedzi oraz znormalizowane elementy
wejściowe requestu w postaci wysłanej przez klienta (zanim zmodyfikują je guardrails
i bez historii dodanej przez previous_response_id lub conversation). Streamowana odpowiedź jest zapisywana na podstawie jej zdarzenia końcowego
(response.completed, response.incomplete lub response.failed). Snapshot jest zapisywany w tle po
zwróceniu odpowiedzi, więc opóźnienie storage nigdy nie spowalnia klienta.
GET /v1/responses/{id} wysłany natychmiast po POST może dotrzeć, zanim
snapshot zostanie zapisany; łagodne zamknięcie (graceful shutdown) czeka
na oczekujące zapisy snapshotów, ale twarde zakończenie procesu może utracić taki, który
nie został dokończony. Nieudany zapis snapshotu jest logowany i zliczany w metryce
gomodel_response_snapshot_store_failures_total.
Umożliwia to:
GET /v1/responses/{id}dla odpowiedzi utworzonych przez GoModel.GET /v1/responses/{id}/input_itemsdla oryginalnego znormalizowanego wejścia.DELETE /v1/responses/{id}nawet wtedy, gdy provider nie udostępnia natywnego usuwania odpowiedzi.previous_response_idu providerów z translacją do Chat Completions, takich jak Anthropic i Gemini: GoModel podąża za zapisaną odpowiedzią i każdą odpowiedzią, z której powstał łańcuch, i dokleja ich elementy wejściowe oraz wyjście na początek nowego wejścia, więc provider w każdej turze otrzymuje cały łańcuch. Odpowiedź wskazuje swoją poprzedniczkę wprevious_response_id, niezależnie od tego, czy jest streamowana. U tych providerów id, które nie jest zapisane (poprzednia odpowiedź została wysłana zstore: false) lub należy do innego tenanta, zwraca 404. Natywni providerzy Responses otrzymują samo id i rozwiązują je po swojej stronie, więc nie potrzebują snapshotu GoModel. Id wygenerowane przez GoModel dla providera z translacją jest dla nich również odtwarzane, więc łańcuch może w trakcie rozmowy przejść z Gemini lub Anthropic do OpenAI. Własność jest egzekwowana u każdego providera: id, którego zapisana odpowiedź należy do innej ścieżki użytkownika, zwraca 404 zamiast zostać rozwiązane w upstreamie, natomiast id, którego GoModel nigdy nie zapisał, jest nadal przekazywane dalej.
conversation zarządzanej przez gateway, jest
scalana z wejściem, zanim uruchomią się guardrails fazy promptu,
więc sprawdzają ją i przepisują jak każde inne wejście: zapisana odpowiedź
zawiera to, co widział jej klient, a guardrail presidio
ponownie anonimizuje przywrócone tam wartości, zanim następna tura
dotrze do providera. Natywny provider główny również otrzymuje odtworzoną historię zamiast
id, gdy na prompcie działa guardrail przepisujący treść (instancja skonfigurowana
wyłącznie do oznaczania lub blokowania się nie liczy) albo
gdy cel failoveru korzysta z translacji do Chat Completions. Bez takiego guardraila id jest
przekazywane bez zmian, więc provider nadal obsługuje łańcuch na podstawie własnego
stanu.
Odpowiedzi w tle
background: true zwraca od razu snapshot w stanie queued. Ponieważ ten
snapshot nie jest ostateczny, GET /v1/responses/{id} przy każdym odpytaniu pobiera go
ponownie od providera, który go utworzył, i zapisuje wynik, gdy odpowiedź osiągnie
status końcowy (completed, incomplete, failed lub cancelled), więc
typowa pętla SDK — odpytuj, aż status będzie końcowy, a potem odczytaj output — działa
przez gateway. Końcowe snapshoty są serwowane ze storage bez wywołania
upstreamu. Jeśli odświeżenie się nie powiedzie, zapisany snapshot zostaje zwrócony bez zmian.
Odpowiedzi tworzone w tle nigdy nie są serwowane z cache’u
odpowiedzi: body w stanie queued zawiera id należące do
odpowiedzi jednego wywołującego.
Natywne wyszukiwanie u providera
Gdy odpowiedź nie została utworzona przez bieżący proces GoModel ani nie ma jej w storage odpowiedzi, endpointy cyklu życia nadal mogą skorzystać z natywnego wyszukiwania u providera. Wskaż providera, gdy ID odpowiedzi nie jest zapisane lokalnie:Elementy wejściowe
GoModel normalizuje zapisane wejście do kompatybilnych z OpenAI elementów wejściowych odpowiedzi. Wejście w postaci stringa staje się wiadomością użytkownika z elementem treściinput_text:
Błędy kompatybilności
Niektórzy providerzy nie obsługują wszystkich endpointów cyklu życia lub pomocniczych Responses. Gdy wybrany provider nie może wykonać operacji, GoModel zwraca kompatybilny z OpenAI błąd z:invalid_request_error dla nieobsługiwanych operacji,
aby publiczny zbiór typów błędów pozostał zamknięty. Kod unsupported_response_operation
identyfikuje nieobsługiwaną operację i jest zwracany z HTTP 501 Not Implemented.