openai, zarówno do bezpośredniego uwierzytelniania kluczem API, jak i
uwierzytelniania w ramach subskrypcji ChatGPT/Codex. openai/* jest kanoniczną trasą modelu.
W przypadku tur osadzonego agenta, gdy zasady środowiska uruchomieniowego nie są ustawione lub mają wartość auto, fakty
dotyczące trasy OpenAI decydują, czy OpenClaw może niejawnie wybrać dołączone środowisko uruchomieniowe serwera aplikacji Codex.
Sam prefiks openai/* nie wybiera środowiska uruchomieniowego.
- Modele agenta —
openai/*za pośrednictwem środowiska uruchomieniowego wybranego przez jawną konfiguracjęagentRuntimelub niejawne zasady tras OpenAI. Do korzystania z subskrypcji ChatGPT/Codex należy zalogować się za pomocą uwierzytelniania Codex albo skonfigurować profil uwierzytelniania kluczem API, gdy rozliczenia mają odbywać się na podstawie klucza. - Interfejsy API OpenAI niezwiązane z agentem — bezpośredni dostęp do OpenAI Platform, rozliczany za użycie,
za pośrednictwem
OPENAI_API_KEYlub profilu uwierzytelniania kluczem APIopenai. - Starsza konfiguracja — odwołania
codex/*iopenai-codex/*są naprawiane do postaciopenai/*orazagentRuntime.id: "codex"o zakresie ograniczonym do modelu przezopenclaw doctor --fix.
Śledzenie użycia i kosztów
OpenClaw rozdziela limit subskrypcji od rozliczeń interfejsu API Platform:- OAuth ChatGPT/Codex pokazuje plan subskrypcji, okresy limitów i saldo środków.
OPENAI_ADMIN_KEYpokazuje w sekcji Użycie interfejsu Control UI 30 dni zgłoszonych przez dostawcę kosztów organizacji i użycia uzupełnień, w tym dzienne wydatki, łączne liczby żądań/tokenów, najczęściej używane modele i kategorie kosztów.OPENAI_PROJECT_IDopcjonalnie ogranicza historię interfejsu Admin API do jednego projektu.- OpenClaw nigdy nie wysyła
OPENAI_API_KEYani profilu wnioskowaniaopenaido interfejsów API organizacji; te dane uwierzytelniające mogą należeć do niestandardowych punktów końcowych, Azure lub punktów końcowych lokalnych dla agenta.
Szybki wybór
Mapa nazw
Niejawne środowisko uruchomieniowe agenta
Gdy zasadyagentRuntime dostawcy/modelu nie są ustawione lub mają wartość auto,
należące do dostawcy OpenAI zasady tras wybierają niejawne środowisko uruchomieniowe na podstawie efektywnego
punktu końcowego i adaptera:
Jawna, niedomyślna wartość
agentRuntime.id dostawcy/modelu pozostaje rozstrzygająca.
Na przykład agentRuntime.id: "openclaw" pozostawia w OpenClaw trasę, która w przeciwnym razie
kwalifikowałaby się do Codex, natomiast agentRuntime.id: "codex" wymaga Codex i kończy
działanie błędem, gdy efektywna trasa nie jest zadeklarowana jako zgodna z Codex.
Wybór środowiska uruchomieniowego nie zmienia typu danych uwierzytelniających ani sposobu rozliczania: uwierzytelnianie kluczem API
Platform i uwierzytelnianie w ramach subskrypcji ChatGPT/Codex pozostają odrębne.
openclaw doctor --fix migruje starsze odwołania modeli codex/* i openai-codex/*,
starsze identyfikatory profili uwierzytelniania Codex oraz starsze wpisy kolejności uwierzytelniania Codex do
kanonicznej trasy openai. Zmigrowane odwołania modeli otrzymują
agentRuntime.id: "codex" o zakresie ograniczonym do modelu; w nowej konfiguracji kolejności uwierzytelniania należy używać auth.order.openai.
Nowa konfiguracja OpenAI ustawia model główny GPT-5.6 tylko wtedy, gdy nie skonfigurowano
modelu głównego. Dodanie lub odświeżenie uwierzytelniania OpenAI zachowuje istniejący jawny
wybór, w tym
openai/gpt-5.5, chyba że jawnie użyto
models auth login --set-default lub models set. Profilu uwierzytelniania kluczem API
należy używać tylko wtedy, gdy model agenta ma korzystać z uwierzytelniania kluczem API.Ograniczona wersja zapoznawcza GPT-5.6
OpenClaw rozpoznaje dokładne identyfikatory modeliopenai/gpt-5.6-sol,
openai/gpt-5.6-terra i openai/gpt-5.6-luna. Wszystkie trzy udostępniają
poziomy rozumowania xhigh i max w bieżącym katalogu. OpenAI opisuje Sol jako
flagową warstwę, Terra jako warstwę zrównoważoną, a Luna jako warstwę szybką
i tańszą. Zobacz
ogłoszenie wydania GPT-5.6
oraz przewodnik po dostępie.
Przy bezpośrednim uwierzytelnianiu OpenAI kluczem API sam identyfikator openai/gpt-5.6 jest aliasem
Sol i domyślnym ustawieniem nowej konfiguracji. Natywny katalog Codex nie stosuje
tego aliasu bezpośredniego API po stronie klienta; zależnie od dostępu obszaru roboczego może pokazywać
dokładne identyfikatory Sol, Terra i Luna. Dlatego nowa konfiguracja OAuth ChatGPT/Codex
używa openai/gpt-5.6-sol. Bieżące konto można sprawdzić za pomocą:
Kwalifikujące się dokładne oficjalne trasy HTTPS mogą wybrać dołączony Plugin serwera aplikacji
Codex, gdy zasady środowiska uruchomieniowego nie są ustawione lub mają wartość
auto; utworzone ręcznie trasy Completions,
niestandardowe punkty końcowe i nadpisania transportu żądań pozostają w OpenClaw. Oficjalne
punkty końcowe HTTP przesyłające dane zwykłym tekstem są odrzucane. Jawna konfiguracja środowiska uruchomieniowego dostawcy/modelu pozostaje
rozstrzygająca. Należy uruchomić openclaw doctor --fix, aby naprawić nieaktualne starsze odwołania modeli Codex,
odwołania codex-cli/* lub stare przypięcia sesji środowiska uruchomieniowego, które nie zostały ustawione przez
jawną konfigurację środowiska uruchomieniowego.Zakres obsługiwanych funkcji OpenClaw
Głos OpenAI Realtime korzysta z publicznego interfejsu OpenAI Platform Realtime
API i wymaga klucza API Platform. Tokeny OAuth Codex uwierzytelniają
natomiast zaplecze ChatGPT Codex; nie są wymienne z kluczami API Platform
dla publicznych punktów końcowych Realtime.Jeśli uwierzytelnianie kluczem API zgłasza brak rozliczeń, należy zasilić środki Platform na stronie
platform.openai.com/account/billing
dla organizacji obsługującej dane uwierzytelniające Realtime podczas korzystania z uwierzytelniania
kluczem API. Głos Realtime akceptuje profil uwierzytelniania kluczem API
openai utworzony przez
openclaw onboard --auth-choice openai-api-key, klucz API Platform ustawiony przez
talk.realtime.providers.openai.apiKey dla rozmowy w interfejsie sterowania lub
plugins.entries.voice-call.config.realtime.providers.openai.apiKey dla Voice
Call, albo zmienną środowiskową OPENAI_API_KEY.Osadzenia pamięci
OpenClaw może używać OpenAI lub punktu końcowego osadzeń zgodnego z OpenAI do indeksowaniamemory_search i osadzeń zapytań:
queryInputType i documentInputType w memorySearch. OpenClaw
przekazuje je jako pola żądań input_type specyficzne dla dostawcy: osadzenia
zapytań używają queryInputType; indeksowane fragmenty pamięci i indeksowanie wsadowe używają
documentInputType. Pełny przykład zawiera
dokumentacja konfiguracji pamięci.
Pierwsze kroki
- Klucz API (OpenAI Platform)
- Subskrypcja Codex
Najlepsze zastosowanie: bezpośredni dostęp do API i rozliczanie według użycia.Można też przekazać klucz bezpośrednio:Podstawowy identyfikator bezpośredniego API
1
Uzyskanie klucza API
Utwórz lub skopiuj klucz API z panelu OpenAI Platform.
2
Uruchomienie konfiguracji początkowej
3
Sprawdzenie dostępności modelu
Podsumowanie tras
Gdy środowisko uruchomieniowe nie jest ustawione lub ma wartość
auto, tylko kwalifikująca się dokładna oficjalna natywna
trasa HTTPS może niejawnie wybrać środowisko uruchomieniowe app-server Codex. W przypadku uwierzytelniania kluczem API
dla modelu agenta należy utworzyć profil uwierzytelniania kluczem API openai i ustawić jego kolejność za pomocą
auth.order.openai; OPENAI_API_KEY pozostaje bezpośrednią opcją awaryjną dla
powierzchni API OpenAI innych niż agentowe. Uruchom openclaw doctor --fix, aby zmigrować starsze
wpisy kolejności uwierzytelniania starszego Codex.Przykład konfiguracji
gpt-5.6 wskazuje warstwę Sol. Jeśli ta organizacja
API nie udostępnia GPT-5.6, należy jawnie ustawić model podstawowy na
openai/gpt-5.5.Aby wypróbować bieżący model Instant z ChatGPT za pośrednictwem API OpenAI, należy ustawić model
na openai/chat-latest:chat-latest jest zmiennym aliasem. Nowa konfiguracja klucza API OpenAI używa zamiast niego
openai/gpt-5.6, którego podstawowy identyfikator bezpośredniego API wskazuje Sol. Istniejące
jawne modele podstawowe, w tym openai/gpt-5.5, pozostają bez zmian. Alias
chat-latest akceptuje tylko szczegółowość tekstu medium; OpenClaw wymusza
dla tego modelu wartość medium przy każdej innej żądanej szczegółowości.Uwierzytelnianie natywnego serwera aplikacji Codex
Natywne środowisko serwera aplikacji Codex używa odwołań modeliopenai/*, gdy kwalifikująca się
dokładna oficjalna trasa HTTPS wybiera je niejawnie lub gdy agentRuntime.id: "codex"
dostawcy/modelu wybiera je jawnie. Uwierzytelnianie nadal opiera się
na koncie. OpenClaw wybiera uwierzytelnianie w następującej kolejności:
- Uporządkowane profile uwierzytelniania OpenAI dla agenta, najlepiej w
auth.order.openai. Należy uruchomićopenclaw doctor --fix, aby zmigrować starsze identyfikatory profili uwierzytelniania Codex i kolejność uwierzytelniania. - Istniejące konto serwera aplikacji, takie jak lokalne logowanie ChatGPT w CLI Codex. W przypadku domyślnego izolowanego katalogu domowego agenta OpenClaw przekazuje to natywne konto CLI do serwera aplikacji za pośrednictwem jego RPC logowania; nie współdzieli konfiguracji, pluginów ani magazynu wątków CLI.
- Tylko dla lokalnych uruchomień serwera aplikacji przez stdio i tylko wtedy, gdy serwer aplikacji
nie zgłasza konta:
CODEX_API_KEY, a następnieOPENAI_API_KEY.
OPENAI_API_KEY dla bezpośrednich modeli OpenAI lub
osadzania. Awaryjne użycie klucza API ze środowiska dotyczy wyłącznie lokalnej ścieżki stdio bez konta;
nigdy nie jest wysyłane przez połączenia WebSocket z serwerem aplikacji. Gdy zostanie
wybrany profil Codex typu subskrypcyjnego, OpenClaw nie przekazuje również
CODEX_API_KEY ani OPENAI_API_KEY do uruchomionego procesu potomnego serwera aplikacji stdio
i zamiast tego wysyła wybrane poświadczenia za pośrednictwem RPC logowania serwera aplikacji.
Gdy ten profil subskrypcji zostanie zablokowany przez limit użycia Codex, OpenClaw
oznacza profil jako zablokowany do czasu resetowania podanego przez Codex i pozwala, aby kolejność
uwierzytelniania przeszła do następnego profilu openai:*, bez zmiany wybranego
modelu ani opuszczania środowiska Codex. Po upływie czasu resetowania
profil subskrypcji ponownie staje się dostępny.
Generowanie obrazów
Dołączony pluginopenai rejestruje generowanie obrazów za pośrednictwem
narzędzia image_generate. Obsługuje generowanie obrazów zarówno z kluczem API OpenAI, jak i OAuth Codex
za pomocą tego samego odwołania modelu openai/gpt-image-2.
Więcej informacji o wspólnych parametrach narzędzia, wyborze dostawcy i zachowaniu
awaryjnym zawiera sekcja Generowanie obrazów.
gpt-image-2 jest wartością domyślną dla generowania obrazów z tekstu i edycji obrazów
w OpenAI. gpt-image-1.5, gpt-image-1 i gpt-image-1-mini nadal mogą być używane
jako jawne zastąpienia modelu. Należy użyć openai/gpt-image-1.5 do uzyskania
wyjścia PNG/WebP z przezroczystym tłem; bieżące API gpt-image-2 odrzuca
background: "transparent".
W przypadku żądania przezroczystego tła należy wywołać image_generate z
model: "openai/gpt-image-1.5", outputFormat: "png" lub "webp" oraz
background: "transparent"; starsza opcja dostawcy openai.background jest
nadal akceptowana. OpenClaw chroni również publiczne trasy OpenAI i OAuth OpenAI Codex,
przepisując domyślne przezroczyste żądania openai/gpt-image-2 na
gpt-image-1.5; Azure i niestandardowe punkty końcowe zgodne z OpenAI zachowują
skonfigurowane nazwy wdrożeń/modeli.
To samo ustawienie jest dostępne dla bezobsługowych uruchomień CLI:
--output-format i --background należy użyć z
openclaw infer image edit podczas rozpoczynania od pliku wejściowego.
--openai-background pozostaje dostępne jako alias specyficzny dla OpenAI. Należy użyć
--quality low|medium|high|auto, aby kontrolować jakość i koszt obrazów OpenAI.
Należy użyć --openai-moderation low|auto, aby przekazać wskazówkę moderacji OpenAI z
image generate lub image edit.
W instalacjach z OAuth ChatGPT/Codex należy zachować to samo odwołanie openai/gpt-image-2. Gdy
skonfigurowany jest profil OAuth openai, OpenClaw odczytuje zapisany token dostępu OAuth
i wysyła żądania obrazów przez zaplecze Codex Responses; nie próbuje najpierw użyć
OPENAI_API_KEY ani po cichu przełączyć się awaryjnie na klucz API.
Należy jawnie skonfigurować models.providers.openai z kluczem API, niestandardowym bazowym
adresem URL lub punktem końcowym Azure, jeśli zamiast tego ma być używana bezpośrednia trasa API obrazów OpenAI.
Jeśli ten niestandardowy punkt końcowy obrazów znajduje się pod zaufanym adresem sieci LAN/prywatnym,
należy również ustawić browser.ssrfPolicy.dangerouslyAllowPrivateNetwork: true; OpenClaw
blokuje prywatne/wewnętrzne punkty końcowe obrazów zgodne z OpenAI, jeśli ta zgoda nie jest obecna.
Generowanie:
Generowanie filmów
Dołączony pluginopenai rejestruje generowanie filmów za pośrednictwem
narzędzia video_generate.
Żądania OpenAI dotyczące konwersji obrazu na wideo używają
POST /v1/videos z obrazem
input_reference. Edycje pojedynczego wideo używają POST /v1/videos/edits z
przesłanym wideo w polu video.
Zobacz Generowanie wideo, aby uzyskać informacje o wspólnych parametrach narzędzia,
wyborze dostawcy i zachowaniu mechanizmu przełączania awaryjnego.Dostawca OpenAI deklaruje
supportsSize, ale nie supportsAspectRatio ani
supportsResolution. Wspólna warstwa normalizacji OpenClaw konwertuje żądany
aspectRatio na najbliższy pasujący size OpenAI, zanim
żądanie dotrze do dostawcy, dlatego żądania dotyczące proporcji obrazu zazwyczaj nadal działają.
resolution nie ma wartości zastępczej rozmiaru i jest pomijany, co jest zgłaszane wywołującemu jako
Ignored unsupported overrides for openai/<model>: resolution=<value>.Uzupełnienie promptu GPT-5
OpenClaw dodaje wspólne uzupełnienie promptu GPT-5 dla modeli z rodziny GPT-5 u dostawcyopenai (w tym starszych, niepoprawionych odwołań Codex, które są normalizowane
do openai/*). Inni dostawcy, którzy również udostępniają identyfikatory modeli z rodziny GPT-5, tacy
jak OpenRouter lub trasy opencode, nie otrzymują tej nakładki; jest ona uzależniona od
identyfikatora dostawcy openai, a nie wyłącznie od identyfikatora modelu. Starsze modele GPT-4.x nigdy
jej nie otrzymują.
Natywny mechanizm serwera aplikacji Codex nie otrzymuje kontraktu zachowania dotyczącego persony i
dyscypliny korzystania z narzędzi ani przyjaznej nakładki stylu interakcji za pośrednictwem
instrukcji deweloperskich; natywny Codex zachowuje należące do Codex zachowanie bazowe, modelu i
dokumentacji projektu, a OpenClaw wyłącza wbudowaną osobowość Codex dla
natywnych wątków, dzięki czemu pliki osobowości w obszarze roboczym agenta pozostają nadrzędne.
OpenClaw przekazuje natywnym wątkom Codex wyłącznie kontekst środowiska uruchomieniowego: dostarczanie
przez kanał, dynamiczne narzędzia OpenClaw, delegowanie ACP, kontekst obszaru roboczego i
Skills OpenClaw. Tekst wskazówek dotyczących Heartbeat z tego samego uzupełnienia jest
jedynym wyjątkiem: natywne tury Heartbeat Codex go otrzymują, wstrzykniętego jako dedykowane
instrukcje współpracy, a nie za pośrednictwem wspólnego mechanizmu
uzupełniania promptu.
Uzupełnienie GPT-5 dodaje oznaczony kontrakt zachowania dotyczący trwałości
persony, bezpieczeństwa wykonywania, dyscypliny korzystania z narzędzi, formatu wyników, kontroli
ukończenia i weryfikacji w pasujących promptach tworzonych przez OpenClaw. Zachowanie odpowiedzi
specyficzne dla kanału i zachowanie cichych wiadomości pozostają we wspólnym prompcie systemowym OpenClaw
oraz zasadach dostarczania wychodzącego. Warstwa przyjaznego stylu interakcji jest
oddzielna i konfigurowalna.
- Konfiguracja
- CLI
Starsze ustawienie
plugins.entries.openai.config.personality jest nadal odczytywane jako
zapasowe ustawienie zgodności, gdy wspólne ustawienie
agents.defaults.promptOverlays.gpt5.personality nie jest określone.Głos i mowa
Synteza mowy (TTS)
Synteza mowy (TTS)
Dołączony Plugin
openai rejestruje syntezę mowy dla
interfejsu messages.tts.Dostępne modele:
gpt-4o-mini-tts, tts-1, tts-1-hd. Dostępne głosy:
alloy, ash, ballad, cedar, coral, echo, fable, juniper,
marin, onyx, nova, sage, shimmer, verse.extraBody jest scalane z danymi JSON żądania /audio/speech po polach
wygenerowanych przez OpenClaw, dlatego należy go używać w punktach końcowych zgodnych z OpenAI, które wymagają
dodatkowych kluczy, takich jak lang. Klucze prototypu są ignorowane.Ustaw
OPENAI_TTS_BASE_URL, aby zastąpić bazowy adres URL TTS bez wpływu na
punkt końcowy interfejsu API czatu. Zarówno TTS OpenAI, jak i głos Realtime są konfigurowane
za pomocą klucza API platformy OpenAI; instalacje korzystające wyłącznie z OAuth mogą nadal używać
modeli czatu obsługiwanych przez Codex, ale nie funkcji rozmowy głosowej na żywo OpenAI.Konwersja mowy na tekst
Konwersja mowy na tekst
Dołączony Plugin Wskazówki dotyczące języka i promptu są przekazywane do OpenAI, gdy dostarcza je
wspólna konfiguracja multimediów audio lub żądanie transkrypcji dla danego wywołania.
openai rejestruje wsadową konwersję mowy na tekst za pośrednictwem
interfejsu transkrypcji analizy multimediów OpenClaw.- Model domyślny:
gpt-4o-transcribe - Punkt końcowy: OpenAI REST
/v1/audio/transcriptions - Ścieżka wejściowa: przesyłanie pliku audio w formacie multipart
- Używane wszędzie tam, gdzie transkrypcja przychodzącego dźwięku odczytuje
tools.media.audio, w tym dla segmentów kanałów głosowych Discord i załączników audio kanałów
Transkrypcja w czasie rzeczywistym
Transkrypcja w czasie rzeczywistym
Dołączony Plugin
openai rejestruje transkrypcję w czasie rzeczywistym dla
Pluginu Voice Call.Używa połączenia WebSocket z
wss://api.openai.com/v1/realtime z dźwiękiem
G.711 u-law (g711_ulaw / audio/pcmu). W przypadku profilu klucza API
openai Gateway generuje tymczasowy sekret klienta transkrypcji Realtime
przed otwarciem połączenia WebSocket. Ten dostawca strumieniowy jest przeznaczony dla ścieżki
transkrypcji w czasie rzeczywistym Pluginu Voice Call; funkcja głosowa Discord obecnie nagrywa krótkie
segmenty i zamiast tego używa ścieżki transkrypcji wsadowej tools.media.audio.Głos w czasie rzeczywistym
Głos w czasie rzeczywistym
Dołączony Plugin
openai rejestruje głos w czasie rzeczywistym dla Pluginu Voice Call.Dostępne wbudowane głosy Realtime dla
gpt-realtime-2.1: alloy, ash,
ballad, coral, echo, sage, shimmer, verse, marin, cedar.
OpenAI zaleca marin i cedar, aby uzyskać najlepszą jakość Realtime. Jest to
oddzielny zestaw od powyższych głosów syntezy mowy; głos przeznaczony wyłącznie do TTS,
taki jak fable, nova lub onyx, nie jest prawidłowy dla sesji Realtime.
Ustaw model jawnie na gpt-realtime-2.1-mini, jeśli preferowany jest
mniejszy i tańszy wariant Realtime 2.1.GPT-Live (wkrótce). Pełnodupleksowe modele OpenAI
gpt-live-1 i
gpt-live-1-mini zastąpiły tryb głosowy ChatGPT w lipcu 2026 r.; interfejs
API dla deweloperów jest stopniowo udostępniany organizacjom z wczesnym dostępem. OpenClaw
rozpoznaje rodzinę modeli, ale jeszcze jej nie obsługuje: sesje GPT-Live działają
wyłącznie przez WebRTC, samodzielnie zarządzają kolejnością wypowiedzi (bez VAD) i delegują pracę agenta
za pośrednictwem protokołu zdarzeń przekazania, którego transporty Realtime OpenClaw
jeszcze nie implementują. Skonfigurowanie modelu gpt-live-* kończy się bezpiecznym błędem
ze wskazówkami dotyczącymi zarówno mostu WebSocket, jak i sesji Talk w przeglądarce, zamiast
po cichu łączyć dźwięk bez dostępu agenta. Dostęp do API jest również ograniczony
dla poszczególnych organizacji OpenAI podczas wczesnego dostępu. Zachowaj gpt-realtime-2.1 (
wartość domyślną) do czasu dodania obsługi GPT-Live.Backendowe mosty Realtime OpenAI używają ogólnie dostępnego formatu sesji Realtime
WebSocket, który nie akceptuje
session.temperature. Wdrożenia Azure OpenAI
pozostają dostępne przez azureEndpoint i azureDeployment oraz
zachowują format sesji zgodny z wdrożeniem (w tym temperature).
Obsługuje dwukierunkowe wywoływanie narzędzi i dźwięk G.711 u-law.Głos czasu rzeczywistego jest wybierany podczas tworzenia sesji. OpenAI pozwala później
zmienić większość pól sesji, ale głosu nie można zmienić po tym, jak
model wyemituje dźwięk w tej sesji. OpenClaw obecnie udostępnia
wbudowane identyfikatory głosów czasu rzeczywistego jako ciągi znaków.
Funkcja rozmowy w interfejsie sterowania korzysta z sesji czasu rzeczywistego OpenAI w przeglądarce, z
efemerycznym sekretem klienta wygenerowanym przez Gateway oraz bezpośrednią wymianą SDP WebRTC
między przeglądarką a interfejsem OpenAI Realtime API. Gateway generuje ten sekret klienta przy użyciu
wybranego poświadczenia
openai. Skonfigurowane klucze, profile kluczy API oraz
OPENAI_API_KEY mają pierwszeństwo; profil OAuth openai lub zewnętrzne
logowanie Codex stanowi rozwiązanie rezerwowe. Przekaźnik Gateway i mosty WebSocket czasu rzeczywistego
zaplecza połączeń głosowych używają tej samej kolejności poświadczeń dla natywnych punktów końcowych OpenAI.
Weryfikacja na żywo dla opiekunów jest dostępna za pomocą
OPENAI_API_KEY=... GEMINI_API_KEY=... node --import tsx scripts/dev/realtime-talk-live-smoke.ts;
etapy OpenAI weryfikują zarówno most WebSocket zaplecza, jak i wymianę
SDP WebRTC w przeglądarce bez rejestrowania sekretów.
Przekaż --openai-only, aby uruchomić te dwa etapy bez poświadczeń Google.Punkty końcowe Azure OpenAI
Dołączony dostawcaopenai może korzystać z zasobu Azure OpenAI do generowania
obrazów przez zastąpienie bazowego adresu URL. Na ścieżce generowania obrazów OpenClaw
wykrywa nazwy hostów Azure w models.providers.openai.baseUrl i automatycznie przełącza się na
format żądań Azure.
Głos czasu rzeczywistego korzysta z oddzielnej ścieżki konfiguracji
(
plugins.entries.voice-call.config.realtime.providers.openai.azureEndpoint)
i models.providers.openai.baseUrl nie ma na niego wpływu. Ustawienia Azure opisano w panelu Głos
czasu rzeczywistego w sekcji Głos i mowa.- Istnieje już subskrypcja Azure OpenAI, limit lub umowa korporacyjna
- Wymagane są regionalne przechowywanie danych lub mechanizmy zgodności oferowane przez Azure
- Ruch ma pozostać w ramach istniejącej dzierżawy Azure
Konfiguracja
Aby generować obrazy w Azure za pośrednictwem dołączonego dostawcyopenai, należy skierować
models.providers.openai.baseUrl do zasobu Azure i ustawić apiKey na
klucz Azure OpenAI (nie klucz platformy OpenAI):
*.openai.azure.com*.services.ai.azure.com*.cognitiveservices.azure.com
- Wysyła nagłówek
api-keyzamiastAuthorization: Bearer - Używa ścieżek ograniczonych do wdrożenia (
/openai/deployments/{deployment}/...) - Dołącza
?api-version=...do każdego żądania - Używa domyślnego limitu czasu żądania wynoszącego 600s dla wywołań generowania obrazów w Azure.
Wartości
timeoutMsposzczególnych wywołań nadal zastępują tę wartość domyślną.
Trasowanie Azure dla ścieżki generowania obrazów dostawcy
openai wymaga
OpenClaw 2026.4.22 lub nowszego. Wcześniejsze wersje traktują każdy niestandardowy
openai.baseUrl jak publiczny punkt końcowy OpenAI i nie działają z wdrożeniami obrazów
Azure.Wersja API
UstawAZURE_OPENAI_API_VERSION, aby przypiąć określoną wersję zapoznawczą lub GA Azure
dla ścieżki generowania obrazów w Azure:
2024-12-01-preview.
Nazwy modeli są nazwami wdrożeń
Azure OpenAI wiąże modele z wdrożeniami. W przypadku żądań generowania obrazów w Azure trasowanych przez dołączonego dostawcęopenai pole model w OpenClaw
musi zawierać nazwę wdrożenia Azure skonfigurowaną w portalu Azure, a nie
identyfikator publicznego modelu OpenAI.
Jeśli zostanie utworzone wdrożenie o nazwie gpt-image-2-prod, które udostępnia gpt-image-2:
openai.
Dostępność regionalna
Generowanie obrazów w Azure jest obecnie dostępne tylko w części regionów (na przykładeastus2, swedencentral, polandcentral, westus3,
uaenorth). Przed utworzeniem wdrożenia należy sprawdzić aktualną listę regionów Microsoft
i potwierdzić, że dany model jest oferowany w odpowiednim regionie.
Różnice w parametrach
Azure OpenAI i publiczny OpenAI nie zawsze akceptują te same parametry obrazów. Azure może odrzucać opcje dozwolone przez publiczny OpenAI (na przykład niektóre wartościbackground w gpt-image-2) lub udostępniać je tylko w określonych wersjach
modelu. Różnice te wynikają z Azure i modelu bazowego, a nie z
OpenClaw. Jeśli żądanie Azure zakończy się błędem walidacji, należy sprawdzić
zestaw parametrów obsługiwany przez dane wdrożenie i wersję API w
portalu Azure.
Azure OpenAI używa natywnego transportu i zachowania zgodności, ale nie otrzymuje
ukrytych nagłówków atrybucji OpenClaw — zobacz panel Trasy natywne a trasy zgodne z OpenAI
w sekcji Konfiguracja zaawansowana.Dla ruchu czatu lub Responses w Azure (poza generowaniem obrazów) należy użyć
procesu wdrażania lub dedykowanej konfiguracji dostawcy Azure; sam
openai.baseUrl
nie przejmuje formatu API/uwierzytelniania Azure. Istnieje oddzielny
dostawca azure-openai-responses/*; zobacz panel Compaction po stronie
serwera poniżej.Konfiguracja zaawansowana
Poniższe przykładyparams dla poszczególnych modeli kształtują osadzone żądanie dostawcy
OpenClaw. Ich skonfigurowanie stanowi jawnie określone zachowanie żądania, dlatego kwalifikująca się
trasa auto pozostaje w OpenClaw zamiast niejawnie wybierać Codex. Natywny
mechanizm serwera aplikacji Codex zarządza własnym transportem i ustawieniami żądań; jawne
agentRuntime.id: "codex" kończy działanie błędem, gdy wynikowa trasa nie jest zadeklarowana jako
zgodna z Codex.
Transport (WebSocket a SSE)
Transport (WebSocket a SSE)
OpenClaw używa najpierw WebSocket z awaryjnym przejściem na SSE (Powiązana dokumentacja OpenAI:
"auto") dla openai/*.W trybie "auto" OpenClaw:- Ponawia jedną wczesną próbę po awarii WebSocket, zanim przejdzie na SSE
- Po awarii oznacza WebSocket jako zdegradowany na 60 sekund i używa SSE w okresie schładzania
- Dołącza stabilne nagłówki tożsamości sesji i tury na potrzeby ponownych prób oraz ponownych połączeń
- Normalizuje liczniki użycia (
input_tokens/prompt_tokens) między wariantami transportu
Tryb szybki
Tryb szybki
OpenClaw udostępnia wspólny przełącznik trybu szybkiego dla
openai/*:- Czat/interfejs:
/fast status|auto|on|off - Konfiguracja:
agents.defaults.models["<provider>/<model>"].params.fastMode
service_tier = "priority"). Istniejące wartości service_tier są
zachowywane, a tryb szybki nie zmienia reasoning ani
text.verbosity. fastMode: "auto" rozpoczyna nowe wywołania modelu w trybie szybkim aż do
automatycznego progu, a następnie rozpoczyna późniejsze ponowienia, rozwiązania rezerwowe, wyniki narzędzi lub
wywołania kontynuacji bez trybu szybkiego. Domyślny próg wynosi 60 sekund;
aby go zmienić, ustaw params.fastAutoOnSeconds w aktywnym modelu.Zastąpienia sesji mają pierwszeństwo przed konfiguracją. Wyczyszczenie zastąpienia sesji w
interfejsie Sessions przywraca sesji skonfigurowaną wartość domyślną.
Przetwarzanie priorytetowe (service_tier)
Przetwarzanie priorytetowe (service_tier)
Interfejs API OpenAI udostępnia przetwarzanie priorytetowe przez Obsługiwane wartości:
service_tier. Ustawia się je dla każdego
modelu w OpenClaw:auto, default, flex, priority.Compaction po stronie serwera (Responses API)
Compaction po stronie serwera (Responses API)
W przypadku bezpośrednich modeli OpenAI Responses (
openai/* w api.openai.com)
opakowanie strumienia OpenClaw we wtyczce OpenAI automatycznie włącza Compaction po stronie
serwera:- Wymusza
store: true(chyba że zgodność modelu ustawiasupportsStore: false) - Wstrzykuje
context_management: [{ type: "compaction", compact_threshold: ... }] - Domyślne
compact_threshold: 70% zcontextWindow(lub80000, gdy jest niedostępne)
- Włącz jawnie
- Niestandardowy próg
- Wyłącz
Przydatne w przypadku zgodnych punktów końcowych, takich jak Azure OpenAI Responses:
responsesServerCompaction steruje wyłącznie wstrzykiwaniem context_management.
Bezpośrednie modele OpenAI Responses nadal wymuszają store: true, chyba że zgodność
ustawia supportsStore: false.Ścisły tryb agentowy GPT
Ścisły tryb agentowy GPT
W przypadku modeli z rodziny GPT-5 dostawcy Jawne ustawienie
openai, uruchamianych w osadzonym
środowisku uruchomieniowym OpenClaw, OpenClaw domyślnie stosuje już bardziej rygorystyczny kontrakt wykonywania o nazwie
strict-agentic. Aktywuje się on automatycznie, gdy rozpoznanym dostawcą jest
openai, a identyfikator modelu pasuje do rodziny GPT-5, chyba że konfiguracja
jawnie z niego rezygnuje:"strict-agentic" nie powoduje żadnych zmian w obsługiwanym wariancie (jest
już wartością domyślną) i pozostaje nieaktywne dla nieobsługiwanych par dostawca/model.Gdy strict-agentic jest aktywne, OpenClaw:- Automatycznie włącza
update_plandla złożonych zadań - Ponawia strukturalnie puste tury lub tury zawierające wyłącznie rozumowanie, używając kontynuacji z widoczną odpowiedzią
- Używa jawnych zdarzeń planu mechanizmu wykonawczego, gdy wybrany mechanizm je udostępnia
Ten kontrakt działa wyłącznie w osadzonym mechanizmie uruchamiania agenta OpenClaw. Nie
ma zastosowania do natywnego mechanizmu serwera aplikacji Codex, który samodzielnie zarządza
zachowaniem tur i planów; w przypadku natywnych uruchomień Codex wybór mechanizmu ma większe znaczenie niż
ustawienie kontraktu wykonania.
Trasy natywne a zgodne z OpenAI
Trasy natywne a zgodne z OpenAI
OpenClaw traktuje bezpośrednie punkty końcowe OpenAI, Codex i Azure OpenAI
inaczej niż ogólne serwery proxy
/v1 zgodne z OpenAI:Trasy natywne (openai/*, Azure OpenAI):- Zachowują
reasoning: { effort: "none" }tylko dla modeli obsługujących poziomnoneOpenAI - Pomijają wyłączone rozumowanie w przypadku modeli lub serwerów proxy, które odrzucają
reasoning.effort: "none" - Domyślnie używają trybu ścisłego dla schematów narzędzi
- Dołączają ukryte nagłówki atrybucji wyłącznie na zweryfikowanych hostach natywnych (Azure OpenAI nie otrzymuje tych nagłówków, mimo że jest trasą natywną)
- Zachowują kształtowanie żądań przeznaczone wyłącznie dla OpenAI (
service_tier,store, zgodność rozumowania, wskazówki dotyczące pamięci podręcznej promptów)
- Używają mniej rygorystycznego zachowania zgodności
- Usuwają
storeCompletions z nienatywnych ładunkówopenai-completions - Akceptują zaawansowany przekazywany bez zmian kod JSON
params.extra_body/params.extraBodydla serwerów proxy Completions zgodnych z OpenAI - Akceptują
params.chat_template_kwargsdla serwerów proxy Completions zgodnych z OpenAI, takich jak vLLM - Nie wymuszają ścisłych schematów narzędzi ani nagłówków przeznaczonych wyłącznie dla tras natywnych
Powiązane materiały
Wybór modelu
Wybieranie dostawców, odwołań do modeli i sposobu działania mechanizmu przełączania awaryjnego.
Generowanie obrazów
Wspólne parametry narzędzia do obrazów i wybór dostawcy.
Generowanie wideo
Wspólne parametry narzędzia do wideo i wybór dostawcy.
OAuth i uwierzytelnianie
Szczegóły uwierzytelniania i reguły ponownego używania danych uwierzytelniających.