Ogólne

Modele OpenAI w OpenClaw zrobione po właściwemu

OpenClaw już wcześniej obsługiwał modele OpenAI, ale najnowsza zmiana porządkuje to w dużo dojrzalszy sposób. Zamiast prowadzić całą pętlę modelu po swojej stronie, OpenClaw domyślnie przekazuje tury agentów openai/gpt-* do natywnego runtime’u Codex app-server.

W praktyce oznacza to, że OpenClaw nadal odpowiada za to, co czyni asystenta „Twoim”: kanały komunikacji, personę, pamięć, sesje, harmonogramy, media, przeglądarkę, gateway i narzędzia OpenClaw. Natomiast Codex przejmuje niskopoziomową pętlę pracy modelu: stan wątku, kontynuację narzędzi, kompakcję kontekstu, tryb kodowania i dynamiczne wyszukiwanie narzędzi.

Najkrótsza wersja

  • tury agentów openai/gpt-* domyślnie działają przez natywną ścieżkę Codex app-server,
  • OpenClaw nadal obsługuje kanały, pamięć, sesje, crony, media, gateway i własne narzędzia,
  • Codex prowadzi wewnętrzną pętlę OpenAI: stan wątku, narzędzia, kompakcję i tryb pracy z kodem,
  • wnioski z tej integracji wracają też do domyślnego harnessu OpenClaw, więc z czasem korzystają na tym także inne modele.

Jeśli chcesz przejść przez konfigurację prowadzoną krok po kroku, użyj:

openclaw onboard

Możesz też zalogować OpenAI bezpośrednio:

openclaw models auth login --provider openai

Dlaczego runtime ma znaczenie?

OpenClaw nie jest tylko okienkiem czatu. To platforma agentowa, która działa tam, gdzie ją uruchomisz, i komunikuje się przez kanały, których już używasz: Slack, Telegram, Discord, WhatsApp, Matrix, web chat i inne.

Warstwa zewnętrzna to miejsce, w którym OpenClaw powinien być opiniotwórczy. Zna kanały, konfigurację agenta, pamięć, zadania cykliczne, zasady mediów, uprawnienia narzędzi i lokalny gateway. Wewnętrzna pętla modelu to inny problem: tam model rozumuje, wywołuje narzędzia, wznawia stan wątku, korzysta z wykonywania kodu i utrzymuje spójność długich tur.

Dla modeli OpenAI najlepszym właścicielem tej pętli jest dziś Codex app-server. Dlatego granica została przesunięta: Codex prowadzi turę OpenAI, a OpenClaw prowadzi produkt wokół tej tury.

Mniej tłumaczenia, mniej wahań, więcej działania

Ta zmiana usuwa sporo tarcia. Model nie musi wybierać między zdublowanymi narzędziami workspace’u. Może korzystać bezpośrednio z natywnych narzędzi Codex, takich jak odczyt plików, edycja, patchowanie, wykonywanie poleceń, zarządzanie procesami czy planowanie. OpenClaw nie musi udawać, że są to zwykłe narzędzia pluginowe, a jednocześnie może nadal udostępniać własne integracje bez ładowania wszystkich schematów do pierwszego promptu.

Efekt jest prosty: mniej translacji między warstwami, mniej niepewności po stronie modelu i więcej konkretnych działań.

Widoczne odpowiedzi są intencjonalne

W wielu systemach agentowych finalny tekst asystenta staje się wiadomością widoczną dla użytkownika trochę „przy okazji”. W zwykłym czacie to wystarcza. W asystencie wielokanałowym — który może odpowiadać w grupie, DM-ie, wątku lub z zadania cyklicznego — to za mało.

Tury OpenAI obsługiwane przez Codex preferują teraz narzędzie wiadomości OpenClaw do widocznych odpowiedzi. Jeśli agent chce coś powiedzieć użytkownikowi, używa narzędzia, którego zadaniem jest właśnie dostarczenie wiadomości.

  • praca wewnętrzna i narzędziowa zostaje prywatna,
  • widoczne odpowiedzi są świadome,
  • ciche tury naprawdę mogą pozostać ciche,
  • odpowiedzi z multimediami mają właściwą ścieżkę dostarczenia.

Podobnie potraktowano heartbeat’y. Zamiast opierać się na tekstowych sygnałach typu HEARTBEAT_OK, agent może przekazać jawny wynik: „nie ma nic do zgłoszenia”, „powiadom użytkownika” albo „zaplanuj follow-up”. To ważne, bo osobisty agent nie powinien być gadatliwy przez przypadek — powinien przerywać wtedy, gdy ma coś wartego pokazania.

Dynamiczne wyszukiwanie narzędzi zamiast puchnącego promptu

Największą praktyczną wygraną jest dynamiczne ładowanie narzędzi. Agent OpenClaw może mieć ich dużo: wiadomości, sesje, media, crony, przeglądarkę, node’y, gateway, web search, MCP, pluginy i akcje specyficzne dla kanałów.

Wrzucanie pełnego schematu każdego narzędzia do początkowego promptu jest kosztowne i hałaśliwe. Model widzi za dużo, request robi się większy, a ryzyko wyboru niewłaściwego narzędzia rośnie.

Codex daje lepszy kształt: searchable dynamic tools. OpenClaw przekazuje swoje możliwości produktowe jako dynamiczne narzędzia, a Codex może znaleźć odpowiednie narzędzie wtedy, gdy faktycznie go potrzebuje. Natywne narzędzia workspace’u pozostają natywne, a integracje OpenClaw żyją w przestrzeni OpenClaw.

Co z modelami innymi niż OpenAI?

To nie jest zmiana tylko dla użytkowników OpenAI. OpenClaw ma dobrze działać z wieloma modelami: Anthropic, Google, lokalnymi modelami, OpenRouterem, DeepSeek, Kimi, MiniMax i własnymi providerami.

Dlatego wnioski z Codex trafiają z powrotem do domyślnego harnessu OpenClaw. Eksperymentalny PI Tool Search daje nie-Codexowym uruchomieniom kompaktową powierzchnię do szukania, opisywania i wywoływania narzędzi zamiast ładowania wszystkich schematów od razu. Nie jest to jeszcze domyślnie włączone dla wszystkich, bo poprzeczka jest wysoka: niezawodność, bezpieczeństwo i kompatybilność między providerami muszą być dopięte.

Subskrypcja ChatGPT jako źródło dostępu do modeli

Ważna wiadomość praktyczna: nie powinieneś płacić dwa razy za ten sam model. Dla standardowej ścieżki OpenAI możesz zalogować się kontem ChatGPT/Codex:

openclaw models auth login --provider openai

Jeśli chcesz mieć zapasową ścieżkę przez API key, możesz dodać ją jawnie:

openclaw models auth login --provider openai --method api-key

Referencja modelu w konfiguracji pozostaje kanoniczna:

openclaw config set agents.defaults.model.primary openai/gpt-5.5

Kluczowy szczegół: openai/gpt-* nie oznacza automatycznie „rozliczaj przez API key”. Dla tur agentowych OpenClaw domyślnie kieruje modele OpenAI przez runtime Codex. Autoryzacja może pochodzić z profilu subskrypcyjnego, uporządkowanego profilu zapasowego albo konta app-server w domu Codex danego agenta.

Izolacja per agent

OpenClaw izoluje stan Codex per agent. Agent OpenClaw dostaje własny Codex home, stan wątków, most konta i zmigrowaną konfigurację pluginów. Twoja osobista konfiguracja Codex CLI nie jest po cichu importowana do agenta OpenClaw, a stan agenta nie wycieka z powrotem do prywatnego CLI.

Guardrails pozostają jawne

Autonomiczne agenty potrzebują sensownych domyślnych ustawień, ale też czytelnych granic bezpieczeństwa. Harness Codex obsługuje zarówno lokalne wykonywanie bez dodatkowych łańcuchów zatwierdzania, jak i tryby z recenzją. OpenClaw zachowuje praktyczną automatyzację lokalną, a operator może włączyć reviewed approvals tam, gdzie wymaga tego wdrożenie.

W trybach recenzowanych żądania zatwierdzeń Codex mogą przechodzić przez mechanizmy review Codex, w tym auto_review, jeśli jest wspierane. OpenClaw nadal odpowiada za zewnętrzną warstwę zatwierdzeń, dostarczenie ich do kanału, hooki pluginów i widoczne raportowanie błędów.

Co jeszcze wchodzi w pakiecie?

  • natywne wznawianie i kompakcja wątków Codex,
  • natywny code mode i narzędzia workspace’u,
  • dynamiczne, wyszukiwalne narzędzia,
  • obsługa pluginów i aplikacji Codex tam, gdzie są włączone,
  • natywne odkrywanie modeli przez katalog app-server,
  • czytelniejsza diagnostyka błędów app-servera lub autoryzacji.

Większy obraz

Bezpośrednia korzyść to lepsze wsparcie OpenAI: mniej zagracony prompt, mniej zdublowanych narzędzi, czystsze odpowiedzi widoczne dla użytkownika, autoryzacja oparta o subskrypcję i pętla modelu zgodna z runtime’em, który OpenAI rozwija dla pracy agentowej.

Długofalowo ta zmiana jest szersza. OpenClaw pozostaje platformą multi-model. Codex nie ma być specjalną wyspą, na której tylko modele OpenAI dostają nowoczesną ergonomię agentową. Dobre wzorce — czystsze granice narzędzi, opóźnione katalogi, strukturalne „ciche” wyniki, lepsze scope’owanie promptu i mniej zdublowanych decyzji — powinny stopniowo trafiać do całego OpenClaw.

Oryginalny wpis: OpenAI Models in OpenClaw, Done Right.

Powi?zane artyku?y

Je?li chcesz pog??bi? ten temat, sprawd? te?:

← Wrocz do bloga