Kiedy używać środowiska wykonawczego
Środowisko wykonawcze agenta należy zarejestrować, gdy rodzina modeli ma własne natywne środowisko uruchomieniowe sesji, a standardowy transport dostawcy OpenClaw jest niewłaściwą abstrakcją:- natywny serwer agenta programistycznego, który zarządza wątkami i Compaction
- lokalny CLI lub demon, który musi strumieniować natywne zdarzenia planu, rozumowania i narzędzi
- środowisko uruchomieniowe modelu, które oprócz transkrypcji sesji OpenClaw wymaga własnego identyfikatora wznowienia
Za co nadal odpowiada rdzeń
Przed wybraniem środowiska wykonawczego OpenClaw ma już określone:- dostawcę i model
- stan uwierzytelniania środowiska uruchomieniowego, chyba że środowisko wykonawcze deklaruje, że odpowiada za inicjalizację uwierzytelniania
- poziom rozumowania i budżet kontekstu
- plik transkrypcji/sesji OpenClaw
- obszar roboczy, piaskownicę i zasady dotyczące narzędzi
- wywołania zwrotne odpowiedzi kanału i wywołania zwrotne przesyłania strumieniowego
- zasady awaryjnego wyboru modelu i przełączania modelu na żywo
Inicjalizacja uwierzytelniania zarządzana przez środowisko wykonawcze
Domyślnie rdzeń rozpoznaje dane uwierzytelniające dostawcy przed wywołaniem środowiska wykonawczego. Zaufane środowisko wykonawcze, które może uwierzytelnić się za pomocą własnego natywnego środowiska uruchomieniowego, może ustawićauthBootstrap: "harness" w swojej statycznej rejestracji AgentHarness. Rdzeń pomija wtedy ogólną inicjalizację danych uwierzytelniających dostawcy i błąd braku danych uwierzytelniających dla każdej próby przejętej przez to środowisko wykonawcze.
Rdzeń nadal przekazuje zgodny, jawnie wybrany lub uporządkowany profil uwierzytelniania OpenClaw i jego magazyn o ograniczonym zakresie, jeśli taki istnieje. Środowisko wykonawcze musi przed wysłaniem żądań do modelu rozpoznać ten profil lub swoje natywne dane uwierzytelniające, ograniczać sekrety do zakresu próby i zgłaszać umożliwiające podjęcie działań błędy uwierzytelniania. Nie należy ustawiać tej możliwości dla środowiska wykonawczego, które tylko czasami odpowiada za uwierzytelnianie.
Zweryfikowane artefakty środowiska uruchomieniowego konfiguracji
Lokalne środowisko wykonawcze, które może zapewnić inferencję podczas początkowej konfiguracji, musi poświadczyć implementację, która ukończyła test. Gdyparams.captureRuntimeArtifact ma wartość true, należy zwrócić nieprzezroczysty result.runtimeArtifact ze stabilnym identyfikatorem i odciskiem zawartości. Należy zarejestrować pasującą możliwość runtimeArtifact.validate(...), która ponownie sprawdza to powiązanie bez ładowania innego środowiska wykonawczego ani skanowania niepowiązanych pluginów.
Zweryfikowane kontynuacje OpenClaw przekazują również params.expectedRuntimeArtifact. Środowisko wykonawcze musi porównać go z dokładnie tym natywnym procesem, który pozyskało, i zakończyć się niepowodzeniem przed rozpoczęciem lub wznowieniem natywnego wątku, jeśli wartości się różnią. Zwykłe tury agenta pomijają oba pola, dzięki czemu obliczanie skrótu zawartości nie trafia na standardową ścieżkę krytyczną żądania. Zdalne środowiska wykonawcze lub środowiska oparte na WebSocket wymagają kontraktu poświadczenia serwera, zanim będą mogły uczestniczyć; sam ciąg wersji nie stanowi tożsamości artefaktu.
Przygotowana próba zawiera również params.runtimePlan, pakiet zasad zarządzany przez OpenClaw na potrzeby decyzji środowiska uruchomieniowego, które muszą pozostać wspólne dla OpenClaw i natywnych środowisk wykonawczych:
runtimePlan.tools.normalize(...)iruntimePlan.tools.logDiagnostics(...)dla zależnych od dostawcy zasad schematu narzędziruntimePlan.transcript.resolvePolicy(...)dla zasad oczyszczania transkrypcji i naprawiania wywołań narzędziruntimePlan.delivery.isSilentPayload(...)dla współdzielonegoNO_REPLYi wyłączania dostarczania multimediówruntimePlan.outcome.classifyRunResult(...)dla klasyfikacji awaryjnego wyboru modeluruntimePlan.observabilitydla określonych metadanych dostawcy/modelu/środowiska wykonawczego
Kontrakt transportu żądania
supports(ctx) otrzymuje określony transport modelu w ctx.modelProvider. Wybraną trasę opisują dwa fakty zarządzane przez dostawcę, które nie zawierają sekretów:
runtimePolicy.compatibleIdszawiera identyfikatory środowisk uruchomieniowych, które dostawca deklaruje jako zgodne z daną trasą. Brak zasad oznacza, że dostawca nie zadeklarował zgodności na poziomie trasy; nie stanowi to pozwolenia na założenie obsługi.requestTransportOverrides: "none"oznacza, że nie trzeba odtwarzać żadnego jawnie zdefiniowanego nadpisania żądania dostawcy/modelu."present"oznacza, że istnieją jawnie zdefiniowane nagłówki, transport uwierzytelniania, proxy, TLS, zachowanie usługi lokalnej lub sieci prywatnej albo parametry żądania. Fakt ten nie ujawnia tych wartości.
{ supported: false, reason }. Nie należy wnioskować o obsłudze przez odczytywanie surowej konfiguracji po dokonaniu wyboru. Jeśli przygotowanie uwierzytelniania tworzy wiele tras ponownych prób, jedno środowisko wykonawcze musi obsługiwać je wszystkie przed wysłaniem. Wybór niejawny używa OpenClaw, jeśli żaden plugin nie może obsłużyć pełnego zestawu; jawny lub utrwalony wybór pluginu kończy się bezpiecznym niepowodzeniem.
Rejestrowanie środowiska wykonawczego
Import:openclaw/plugin-sdk/agent-harness
authBootstrap celowo pominięto w tym ogólnym przykładzie. authBootstrap: "harness" należy dodać tylko wtedy, gdy środowisko wykonawcze spełnia powyższy kontrakt.
Delegowane wykonywanie
Właściciel środowiska wykonawczego może ustawićdelegatedExecutionPluginIds na identyfikatory zaufanych pluginów, które muszą wykonywać istniejącą sesję powiązaną z modelem, na przykład transport głosowy kontynuujący konwersację obsługiwaną przez Codex. Jest to statyczna zgoda właściciela, a nie lista dozwolonych elementów rdzenia. Zakres powinien pozostać wąski.
Delegaci otrzymują wyłącznie zgodę na pracę i osadzone wykonywanie. OpenClaw wymaga dokładnego zapisanego klucza sesji, ścieżki magazynu i identyfikatora sesji; modelSelectionLocked: true; oraz zgodnych wartości agentHarnessId i agentHarnessRuntimeOverride. Wykonanie jest następnie ograniczone zakresem właściciela środowiska wykonawczego. Tworzenie, modyfikowanie, resetowanie, usuwanie i archiwizowanie sesji oraz modyfikowanie Gateway pozostają dostępne wyłącznie dla właściciela.
Zasady wyboru
OpenClaw wybiera środowisko wykonawcze po określeniu dostawcy/modelu:- Pierwszeństwo mają zasady środowiska uruchomieniowego dotyczące modelu.
- Następne są zasady środowiska uruchomieniowego dotyczące dostawcy.
autopyta zarejestrowane środowiska wykonawcze, czy obsługują określoną efektywną trasę. Same prefiksy dostawcy/modelu nigdy nie wybierają środowiska wykonawczego.- Jeśli żadne zarejestrowane środowisko wykonawcze nie pasuje, OpenClaw używa osadzonego środowiska uruchomieniowego.
auto osadzony mechanizm awaryjny ma zastosowanie tylko wtedy, gdy żadne zarejestrowane środowisko wykonawcze pluginu nie obsługuje określonego dostawcy/modelu. Gdy środowisko wykonawcze pluginu przejmie wykonanie, OpenClaw nie odtwarza tej samej tury w innym środowisku uruchomieniowym, ponieważ mogłoby to zmienić semantykę uwierzytelniania/środowiska uruchomieniowego lub powielić skutki uboczne.
Skonfigurowane zasady środowiska uruchomieniowego pozostają miarodajne w kwestii żądanego środowiska uruchomieniowego. Utrwalona sesja agentHarnessId zachowuje własność swojej natywnej transkrypcji, gdy przygotowanie trasy/uwierzytelniania nadal trwa. Żaden z tych mechanizmów nie sprawia, że niezgodna trasa staje się zgodna: gdy przygotowane fakty są dostępne, wybrane lub przypięte środowisko wykonawcze musi je obsługiwać, w przeciwnym razie wykonanie kończy się bezpiecznym niepowodzeniem. /status pokazuje efektywne środowisko uruchomieniowe wybrane na podstawie zasad, utrwalonej własności i obsługi trasy. Stan przygotowania jest jawny: brak runtimePolicy pozostaje niezadeklarowany, zamiast być wywnioskowanym z przypadkowo dostępnych pól transportu. Gdy uwierzytelnianie zarządzane przez środowisko wykonawcze pozostawia nierozstrzygniętych wiele tras fizycznych, przygotowany fakt obsługi stanowi część wspólną ich zgodnych identyfikatorów środowisk uruchomieniowych i zgłasza nadpisania żądań, jeśli występują u któregokolwiek kandydata. Dlatego jeden kandydat bez deklaracji sprawia, że zgodność natywna jest pusta; preparedAuth.source: "harness" jest właścicielem uwierzytelniania, a nie pozwoleniem na wnioskowanie o obsłudze trasy.
Jeśli wybrane środowisko wykonawcze jest zaskakujące, należy włączyć rejestrowanie debugowania agents/harness i sprawdzić ustrukturyzowany rekord agent harness selected bramy: zawiera identyfikator wybranego środowiska wykonawczego, powód wyboru, zasady środowiska uruchomieniowego/mechanizmu awaryjnego oraz, w trybie auto, wynik obsługi każdego kandydata pluginu.
Wbudowany plugin Codex rejestruje codex jako swój identyfikator środowiska wykonawczego. Rdzeń traktuje go jak zwykły identyfikator środowiska wykonawczego pluginu; aliasy specyficzne dla Codex należą do pluginu lub konfiguracji operatora, a nie do współdzielonego selektora środowiska uruchomieniowego.
Parowanie dostawcy ze środowiskiem wykonawczym
Większość środowisk wykonawczych powinna również rejestrować dostawcę. Dostawca udostępnia pozostałej części OpenClaw odwołania do modeli, stan uwierzytelniania, metadane modelu oraz wybór/model. Następnie środowisko wykonawcze przejmuje tego dostawcę w supports(...).
Wbudowany plugin Codex korzysta z tego wzorca:
- preferowane odwołania do modeli użytkownika:
openai/gpt-5.6-sol - odwołania zgodności: starsze odwołania
codex/gpt-*pozostają akceptowane, ale nowe konfiguracje nie powinny używać ich jako standardowych odwołań dostawcy/modelu - identyfikator środowiska wykonawczego:
codex - uwierzytelnianie: syntetyczna dostępność dostawcy, ponieważ środowisko wykonawcze Codex zarządza natywnym logowaniem/sesją Codex
- żądanie serwera aplikacji: OpenClaw wysyła sam identyfikator modelu do Codex i pozwala środowisku wykonawczemu komunikować się z natywnym protokołem serwera aplikacji
auto, OpenAI może wybrać Codex tylko wtedy, gdy zarządzany przez dostawcę kontrakt trasy deklaruje zgodność z codex: dokładna oficjalna trasa HTTPS Platform Responses lub ChatGPT Responses bez jawnie zdefiniowanego nadpisania żądania. Sam prefiks openai/* nigdy nie wybiera Codex. Niestandardowe punkty końcowe, adaptery Completions i jawnie zdefiniowane zachowanie żądań pozostają obsługiwane przez OpenClaw. Oficjalne punkty końcowe używające nieszyfrowanego HTTP są odrzucane. Starsze odwołania codex/gpt-* pozostają danymi wejściowymi zgodności. Zobacz Niejawne środowisko uruchomieniowe agenta OpenAI.
Konfigurację operatora, przykłady prefiksów modeli i konfiguracje przeznaczone wyłącznie dla Codex opisano w sekcji Środowisko wykonawcze Codex.
Plugin Codex wymusza minimalną wersję serwera aplikacji udokumentowaną w sekcji Środowisko wykonawcze Codex. Sprawdza uzgadnianie inicjalizacyjne oraz blokuje starsze serwery i serwery bez wersji, dzięki czemu OpenClaw działa wyłącznie z przetestowaną powierzchnią protokołu.
Oprogramowanie pośredniczące wyników narzędzi
Wbudowane pluginy i jawnie włączone zainstalowane pluginy z pasującymi kontraktami manifestu mogą dołączać niezależne od środowiska uruchomieniowego oprogramowanie pośredniczące wyników narzędzi za pomocąapi.registerAgentToolResultMiddleware(...), gdy ich manifest deklaruje docelowe identyfikatory środowisk uruchomieniowych w contracts.agentToolResultMiddleware. Ta zaufana powierzchnia służy do asynchronicznych przekształceń wyników narzędzi, które muszą zostać wykonane, zanim OpenClaw lub Codex przekaże dane wyjściowe narzędzia z powrotem do modelu.
Starsze dołączone Pluginy mogą nadal używać
api.registerCodexAppServerExtensionFactory(...) dla oprogramowania pośredniczącego przeznaczonego wyłącznie dla
serwera aplikacji Codex, ale nowe transformacje wyników powinny korzystać z API niezależnego od środowiska uruchomieniowego. Punkt zaczepienia api.registerEmbeddedExtensionFactory(...), przeznaczony
wyłącznie dla osadzonego modułu wykonawczego, został usunięty; transformacje wyników narzędzi osadzonych muszą korzystać z oprogramowania pośredniczącego niezależnego od środowiska uruchomieniowego.
Klasyfikacja wyniku końcowego
Natywne mechanizmy testowe, które zarządzają własną projekcją protokołu, mogą używaćclassifyAgentHarnessTerminalOutcome(...) z
openclaw/plugin-sdk/agent-harness-runtime, gdy ukończona tura nie wygenerowała
widocznego tekstu asystenta. Funkcja pomocnicza zwraca empty, reasoning-only lub
planning-only, aby zasady obsługi awaryjnej OpenClaw mogły zdecydować, czy ponowić próbę z
innym modelem. planning-only wymaga jawnego pola planText
mechanizmu testowego; OpenClaw nie wywnioskuje go z prozy asystenta. Funkcja pomocnicza
celowo nie klasyfikuje błędów monitu, trwających tur ani zamierzonych cichych
odpowiedzi, takich jak NO_REPLY.
Efekty uboczne zakończenia agenta
Natywne mechanizmy testowe muszą wywołaćrunAgentEndSideEffects(...) z
openclaw/plugin-sdk/agent-harness-runtime po sfinalizowaniu próby. Funkcja ta
uruchamia przenośny punkt zaczepienia agent_end oraz przechwytywanie danych badawczych OpenClaw
bez opóźniania odpowiedzi interaktywnych. Użyj awaitAgentEndSideEffects(...) w przypadku
lokalnych, nieinteraktywnych uruchomień, w których próba nie może się zakończyć przed ukończeniem tych
efektów ubocznych. Obie funkcje pomocnicze przyjmują ten sam ładunek { event, ctx } co
runAgentHarnessAgentEndHook(...); ich błędy nie zmieniają wyniku ukończonej
próby.
Dane wejściowe użytkownika i powierzchnie narzędzi
Natywne mechanizmy testowe udostępniające żądanie danych wejściowych użytkownika na poziomie środowiska uruchomieniowego powinny korzystać z funkcji pomocniczych danych wejściowych użytkownika zopenclaw/plugin-sdk/agent-harness-runtime, aby formatować
monit, dostarczać go przez blokującą ścieżkę odpowiedzi OpenClaw oraz normalizować
odpowiedzi wyboru lub w formie dowolnego tekstu z powrotem do natywnego formatu odpowiedzi środowiska uruchomieniowego. Funkcja
pomocnicza zapewnia spójną prezentację w kanale/TUI, podczas gdy każdy mechanizm testowy zachowuje
własne parsowanie protokołu i cykl życia oczekujących żądań.
Natywne mechanizmy testowe wymagające kompaktowego routingu narzędzi podobnego do PI powinny używać
createAgentHarnessToolSurfaceRuntime(...) z
openclaw/plugin-sdk/agent-harness-tool-runtime. Funkcja ta zarządza
wyborem sterowania wyszukiwaniem narzędzi/trybem kodu, odchudzonymi ustawieniami domyślnymi modeli lokalnych,
filtrowaniem schematów zgodnym ze środowiskiem uruchomieniowym, ukrytym wykonywaniem katalogu, wypełnianiem
katalogów oraz czyszczeniem katalogu. Mechanizmy testowe nadal odpowiadają za konwersję narzędzi
specyficzną dla własnego SDK oraz natywne wywołanie zwrotne wykonania.
Natywny tryb mechanizmu testowego Codex
Dołączony mechanizm testowycodex jest natywnym trybem Codex dla osadzonych tur agenta OpenClaw.
Najpierw włącz dołączony Plugin codex i dodaj codex do
plugins.allow, jeśli konfiguracja używa restrykcyjnej listy dozwolonych elementów. Natywne konfiguracje serwera aplikacji
powinny używać openai/gpt-*; tury agenta OpenAI wybierają mechanizm testowy Codex
tylko wtedy, gdy efektywna trasa deklaruje zgodność z Codex. Starsze odwołania do modeli Codex
należy naprawić za pomocą openclaw doctor --fix, a starsze odwołania do modeli codex/*
pozostają aliasami zgodności dla natywnego mechanizmu testowego.
Podczas działania tego trybu Codex zarządza natywnym identyfikatorem wątku, zachowaniem wznawiania,
Compaction oraz wykonywaniem przez serwer aplikacji. OpenClaw nadal zarządza kanałem czatu,
widoczną kopią transkrypcji, zasadami narzędzi, zatwierdzeniami, dostarczaniem multimediów oraz wyborem
sesji. Użyj dostawcy/modelu agentRuntime.id: "codex", gdy trzeba
wykazać, że uruchomienie może zostać przejęte wyłącznie przez ścieżkę serwera aplikacji Codex. Jawne środowiska uruchomieniowe
Pluginów działają w trybie zamknięcia przy błędzie; błędy wyboru serwera aplikacji Codex i błędy środowiska uruchomieniowego
nie są ponawiane za pośrednictwem innego środowiska uruchomieniowego.
Rygor środowiska uruchomieniowego
Domyślnie OpenClaw używa zasad środowiska uruchomieniowego dostawcy/modeluauto: zarejestrowane
mechanizmy testowe Pluginów mogą przejmować zgodne efektywne trasy, a osadzone
środowisko uruchomieniowe obsługuje turę, gdy żaden z nich nie pasuje. Sam prefiks dostawcy/modelu nigdy
nie wybiera mechanizmu testowego. Użyj jawnego środowiska uruchomieniowego Pluginu dla dostawcy/modelu, takiego jak
agentRuntime.id: "codex", gdy brak wyboru mechanizmu testowego powinien powodować błąd zamiast
przekierowania przez osadzone środowisko uruchomieniowe. Jawny wybór nie zapewnia
zgodności niezgodnej trasy. Błędy wybranych mechanizmów testowych Pluginów zawsze powodują
błąd krytyczny. Nie blokuje to jawnego agentRuntime.id: "openclaw"
dostawcy/modelu.
Dla osadzonych uruchomień wyłącznie z Codex:
Natywne sesje i kopia transkrypcji
Mechanizm testowy może przechowywać natywny identyfikator sesji, identyfikator wątku lub token wznawiania po stronie demona. Powiązanie to należy jawnie skojarzyć z sesją OpenClaw oraz nadal kopiować widoczne dla użytkownika dane wyjściowe asystenta/narzędzi do transkrypcji OpenClaw. Transkrypcja OpenClaw pozostaje warstwą zgodności dla:- historii sesji widocznej w kanale
- wyszukiwania i indeksowania transkrypcji
- powrotu do wbudowanego mechanizmu testowego OpenClaw podczas późniejszej tury
- ogólnego działania
/new,/resetoraz usuwania sesji
reset(...), aby OpenClaw
mógł je wyczyścić podczas resetowania nadrzędnej sesji OpenClaw.
Wyniki narzędzi i multimediów
Rdzeń tworzy listę narzędzi OpenClaw i przekazuje ją do przygotowanej próby. Gdy mechanizm testowy wykonuje dynamiczne wywołanie narzędzia, zwróć wynik narzędzia za pośrednictwem formatu wyniku mechanizmu testowego zamiast samodzielnie wysyłać multimedia do kanału. Dzięki temu dane wyjściowe tekstu, obrazów, filmów, muzyki, TTS, zatwierdzeń i narzędzi komunikacyjnych korzystają z tej samej ścieżki dostarczania co uruchomienia obsługiwane przez OpenClaw.Końcowe wyniki narzędzi
AgentHarnessAttemptParams.observeToolTerminal jest zarządzanym przez hosta akumulatorem
końcowych wyników. Mechanizm testowy wykonujący dynamiczne narzędzia OpenClaw lub narzędzia natywne
musi go wywołać, gdy każde narzędzie osiągnie jeden końcowy wynik, przed
sfinalizowaniem wyniku próby. Mechanizmy testowe, które nie wykonują narzędzi, nie muszą
go wywoływać.
Zgłaszaj fakty z granicy wykonania:
- Przekaż identyfikator wywołania protokołu, jeśli istnieje, kanoniczną nazwę narzędzia oraz argumenty, które rzeczywiście dotarły do narzędzia po przygotowaniu lub przekształceniach punktów zaczepienia.
- Ustaw
executionStarted: false, gdy walidacja, zatwierdzenie lub inny mechanizm ochronny zatrzymał wywołanie przed rozpoczęciem implementacji narzędzia. Gdy wysłanie mogło już nastąpić, ostrożnie zgłośtrue. - Zgłoś
outcome: "success"luboutcome: "failure". Uwzględnij ustrukturyzowane pola błędu dostępne w środowisku uruchomieniowym zamiast wnioskować o błędzie z wyświetlanego tekstu. - Używaj
nativeMutationwyłącznie dla narzędzi natywnych, które nie korzystają z definicji narzędzia OpenClaw. Podaj tam fakty dotyczące modyfikacji i ponownego odtwarzania zarządzane przez protokół; nie kopiuj klasyfikatora modyfikacji OpenClaw do mechanizmu testowego.
lastToolError do AgentHarnessAttemptResult i użyj jego faktów dotyczących wykonania,
argumentów oraz efektów ubocznych w projekcji mechanizmu testowego zamiast wyprowadzać
równoległy stan. Host zachowuje nierozstrzygnięty błąd modyfikujący pomimo niepowiązanych
udanych narzędzi i usuwa go dopiero po pomyślnym wykonaniu pasującej czynności.
Wywołanie zwrotne pozostaje opcjonalne w celu zachowania zgodności źródłowej ze starszymi eksperymentalnymi
mechanizmami testowymi. Opcjonalność nie oznacza, że mechanizm testowy wykonujący narzędzia może je ignorować:
bez raportów końcowych OpenClaw nie może zachować prawdziwego stanu błędu narzędzia modyfikującego
w kolejnych wywołaniach narzędzi, w tym podczas cichego ukończenia Heartbeat.
Obecne ograniczenia
- Publiczna ścieżka importu jest ogólna, ale niektóre aliasy typów prób/wyników nadal zawierają starsze nazwy w celu zachowania zgodności.
- Instalowanie mechanizmów testowych innych firm jest eksperymentalne. Preferuj Pluginy dostawców, dopóki natywne środowisko uruchomieniowe sesji nie będzie potrzebne.
- Przełączanie mechanizmów testowych między turami jest obsługiwane. Nie przełączaj mechanizmów testowych w trakcie tury po rozpoczęciu działania natywnych narzędzi, zatwierdzeń, tekstu asystenta lub wysyłania wiadomości.