Wann ein Harness verwendet werden sollte
Registrieren Sie ein Agent-Harness, wenn eine Modellfamilie über eine eigene native Session- Runtime verfügt und der normale OpenClaw-Provider-Transport die falsche Abstraktion darstellt:- ein nativer Coding-Agent-Server, der Threads und Compaction verwaltet
- eine lokale CLI oder ein Daemon, die bzw. der native Planungs-, Reasoning- und Tool-Ereignisse streamen muss
- eine Modell-Runtime, die zusätzlich zum OpenClaw- Session-Transkript eine eigene Fortsetzungs-ID benötigt
Wofür Core weiterhin zuständig ist
Bevor ein Harness ausgewählt wird, hat OpenClaw bereits Folgendes aufgelöst:- Provider und Modell
- Runtime-Authentifizierungsstatus, sofern das Harness nicht angibt, den Authentifizierungs-Bootstrap selbst zu verwalten
- Thinking-Level und Kontextbudget
- die OpenClaw-Transkript-/Session-Datei
- Workspace-, Sandbox- und Tool-Richtlinie
- Callbacks für Kanalantworten und Streaming
- Richtlinie für Modell-Fallback und Live-Modellwechsel
Harness-eigener Authentifizierungs-Bootstrap
Standardmäßig löst Core die Provider-Anmeldedaten auf, bevor ein Harness aufgerufen wird. Ein vertrauenswürdiges Harness, das sich über seine eigene native Runtime authentifizieren kann, darfauthBootstrap: "harness" in seiner statischen AgentHarness-Registrierung festlegen. Core überspringt dann
seinen generischen Bootstrap der Provider-Anmeldedaten sowie den Fehler bei fehlenden Anmeldedaten
für jeden von diesem Harness übernommenen Versuch.
Core leitet weiterhin ein kompatibles, explizit ausgewähltes oder geordnetes OpenClaw-Authentifizierungs-
profil und dessen bereichsgebundenen Store weiter, sofern eines vorhanden ist. Das Harness muss dieses
Profil oder seine nativen Anmeldedaten auflösen, bevor es Modellanfragen sendet, Secrets
auf den Versuch beschränken und aussagekräftige Authentifizierungsfehler melden. Legen Sie
diese Fähigkeit nicht für ein Harness fest, das die Authentifizierung nur gelegentlich verwaltet.
Verifizierte Runtime-Artefakte der Einrichtung
Ein lokales Harness, das Inferenz für die Ersteinrichtung bereitstellen kann, muss die Implementierung bestätigen, die den Probevorgang abgeschlossen hat. Wennparams.captureRuntimeArtifact den Wert „true“ hat, geben Sie ein opakes
result.runtimeArtifact mit einer stabilen ID und einem Inhaltsfingerabdruck zurück. Registrieren Sie eine
entsprechende runtimeArtifact.validate(...)-Fähigkeit, die diese Bindung erneut prüft,
ohne ein anderes Harness zu laden oder nicht zugehörige Plugins zu durchsuchen.
Verifizierte OpenClaw-Fortsetzungen übergeben außerdem params.expectedRuntimeArtifact.
Das Harness muss diesen Wert mit dem exakt erworbenen nativen Prozess vergleichen und einen Fehler auslösen,
bevor es einen nativen Thread startet oder fortsetzt, wenn sie nicht übereinstimmen. Gewöhnliche Agent-
Turns lassen beide Felder aus, damit Inhalts-Hashing nicht in den normalen Hot Path für Anfragen gelangt.
Remote-/WebSocket-Harnesses benötigen einen Server-Bestätigungsvertrag, bevor
sie teilnehmen können; eine Versionszeichenfolge allein ist keine Artefaktidentität.
Der vorbereitete Versuch umfasst außerdem params.runtimePlan, ein OpenClaw-eigenes
Richtlinienpaket für Runtime-Entscheidungen, die über OpenClaw und
native Harnesses hinweg einheitlich bleiben müssen:
runtimePlan.tools.normalize(...)undruntimePlan.tools.logDiagnostics(...)für Provider-spezifische Tool-Schema-RichtlinienruntimePlan.transcript.resolvePolicy(...)für Transkriptbereinigung und Richtlinien zur Reparatur von Tool-AufrufenruntimePlan.delivery.isSilentPayload(...)für gemeinsameNO_REPLYund die Unterdrückung der Medien- zustellungruntimePlan.outcome.classifyRunResult(...)für die Klassifizierung von Modell-FallbacksruntimePlan.observabilityfür aufgelöste Provider-/Modell-/Harness-Metadaten
Vertrag für den Anfrage-Transport
supports(ctx) empfängt den aufgelösten Modelltransport in ctx.modelProvider.
Zwei Secret-freie, Provider-eigene Fakten beschreiben die ausgewählte Route:
runtimePolicy.compatibleIdslistet die Runtime-IDs auf, die der Provider als mit dieser konkreten Route kompatibel deklariert. Eine fehlende Richtlinie bedeutet, dass der Provider keine Kompatibilität auf Routenebene deklariert hat; sie ist keine Berechtigung, Unterstützung anzunehmen.requestTransportOverrides: "none"bedeutet, dass keine vom Autor festgelegte Provider-/Modellanfrage- Überschreibung reproduziert werden muss."present"bedeutet, dass vom Autor festgelegte Header, Authentifizierungs- transport-, Proxy-, TLS-, lokaler Dienst-, privates Netzwerk-Verhalten oder Anfrage- parameter vorhanden sind. Das Faktum legt diese Werte nicht offen.
{ supported: false, reason } zurück, wenn das Harness den
vorbereiteten Transport nicht reproduzieren kann. Leiten Sie die Unterstützung nach der Auswahl nicht durch Lesen der Rohkonfiguration ab.
Wenn die Authentifizierungsvorbereitung mehrere Wiederholungsrouten ergibt, muss ein Harness
alle unterstützen, bevor die Weiterleitung erfolgt. Bei impliziter Auswahl wird OpenClaw verwendet, wenn kein Plugin
den vollständigen Satz verwalten kann; eine explizite oder persistierte Plugin-Auswahl schlägt geschlossen fehl.
Ein Harness registrieren
Import:openclaw/plugin-sdk/agent-harness
authBootstrap fehlt in diesem generischen Beispiel bewusst. Fügen Sie
authBootstrap: "harness" nur hinzu, wenn das Harness den oben beschriebenen Vertrag erfüllt.
Delegierte Ausführung
Ein Harness-Eigentümer darfdelegatedExecutionPluginIds auf die IDs vertrauenswürdiger
Plugins setzen, die eine vorhandene modellgebundene Session ausführen müssen, beispielsweise ein Sprach-
transport, der eine Codex-gestützte Unterhaltung fortsetzt. Dies ist eine statische Zustimmung des Eigentümers
und keine Core-Zulassungsliste. Halten Sie sie eng begrenzt.
Delegierte erhalten nur die Arbeitsannahme und die eingebettete Ausführung. OpenClaw verlangt
den exakt gespeicherten Session-Schlüssel, Store-Pfad und die Session-ID; modelSelectionLocked: true; sowie übereinstimmende Werte für agentHarnessId und agentHarnessRuntimeOverride.
Die Ausführung wird anschließend über den Harness-Eigentümer begrenzt. Session-Erstellung, Patching,
Zurücksetzen, Löschen, Archivieren und Gateway-Mutationen bleiben ausschließlich dem Eigentümer vorbehalten.
Auswahlrichtlinie
OpenClaw wählt nach der Auflösung von Provider und Modell ein Harness aus:- Die modellspezifische Runtime-Richtlinie hat Vorrang.
- Danach folgt die Provider-spezifische Runtime-Richtlinie.
autofragt registrierte Harnesses, ob sie die aufgelöste effektive Route unterstützen. Provider-/Modellpräfixe allein wählen niemals ein Harness aus.- Wenn kein registriertes Harness übereinstimmt, verwendet OpenClaw seine eingebettete Runtime.
auto
gilt der eingebettete Fallback nur, wenn kein registriertes Plugin-Harness den aufgelösten
Provider bzw. das Modell unterstützt. Sobald ein Plugin-Harness eine Ausführung übernommen hat, spielt OpenClaw
denselben Turn nicht über eine andere Runtime erneut ab, da dies
Authentifizierungs-/Runtime-Semantik ändern oder Nebenwirkungen duplizieren kann.
Die konfigurierte Runtime-Richtlinie bleibt maßgeblich für die gewünschte Runtime. Ein
persistiertes Session-agentHarnessId behält die Zuständigkeit für sein natives Transkript,
während die Routen-/Authentifizierungsvorbereitung noch aussteht. Beides macht eine inkompatible
Route nicht kompatibel: Sobald vorbereitete Fakten vorliegen, muss das ausgewählte oder angeheftete Harness
sie unterstützen, andernfalls schlägt die Ausführung geschlossen fehl. /status zeigt die effektive Runtime,
die anhand von Richtlinie, persistierter Zuständigkeit und Routenunterstützung ausgewählt wurde.
Der Vorbereitungsstatus ist explizit: Ein fehlendes runtimePolicy bleibt undeklariert,
anstatt aus zufällig vorhandenen Transportfeldern abgeleitet zu werden.
Wenn eine Harness-eigene Authentifizierung mehrere physische Routen unaufgelöst lässt, ist das
vorbereitete Unterstützungsfaktum die Schnittmenge ihrer kompatiblen Runtime-IDs und
meldet Anfrageüberschreibungen, falls ein Kandidat solche besitzt. Ein nicht deklarierter Kandidat
macht die native Kompatibilität daher leer; preparedAuth.source: "harness"
ist ein Authentifizierungseigentümer und keine Berechtigung, Routenunterstützung abzuleiten.
Wenn das ausgewählte Harness unerwartet ist, aktivieren Sie das Debug-Logging agents/harness
und prüfen Sie den strukturierten agent harness selected-Datensatz des Gateways: Er
enthält die ID des ausgewählten Harnesses, den Auswahlgrund, die Runtime-/Fallback-Richtlinie
und im Modus auto das Unterstützungsergebnis jedes Plugin-Kandidaten.
Das gebündelte Codex-Plugin registriert codex als seine Harness-ID. Core behandelt diese
wie eine gewöhnliche Plugin-Harness-ID; Codex-spezifische Aliasse gehören in das Plugin
oder die Betreiberkonfiguration und nicht in den gemeinsamen Runtime-Selektor.
Kopplung von Provider und Harness
Die meisten Harnesses sollten außerdem einen Provider registrieren. Der Provider macht Modellreferenzen, Authentifizierungsstatus, Modellmetadaten und die Auswahl/model für den Rest von
OpenClaw sichtbar. Das Harness übernimmt diesen Provider anschließend in supports(...).
Das gebündelte Codex-Plugin folgt diesem Muster:
- bevorzugte Benutzer-Modellreferenzen:
openai/gpt-5.6-sol - Kompatibilitätsreferenzen: Veraltete
codex/gpt-*-Referenzen werden weiterhin akzeptiert, neue Konfigurationen sollten sie jedoch nicht als normale Provider-/Modellreferenzen verwenden - Harness-ID:
codex - Authentifizierung: synthetische Provider-Verfügbarkeit, da das Codex-Harness die native Codex-Anmeldung/-Session verwaltet
- App-Server-Anfrage: OpenClaw sendet die reine Modell-ID an Codex und lässt das Harness mit dem nativen App-Server-Protokoll kommunizieren
auto ist, darf OpenAI
Codex nur auswählen, wenn sein Provider-eigener Routenvertrag codex
als kompatibel deklariert: eine exakte offizielle HTTPS-Route für Platform Responses oder ChatGPT Responses
ohne vom Autor festgelegte Anfrageüberschreibung. Das Präfix openai/* allein
wählt Codex niemals aus. Benutzerdefinierte Endpunkte, Completions-Adapter und vom Autor festgelegtes Anfrage-
verhalten verbleiben bei OpenClaw. Offizielle Klartext-HTTP-Endpunkte werden abgelehnt. Ältere codex/gpt-*-
Referenzen bleiben Kompatibilitätseingaben. Siehe
Implizite OpenAI-Agent-Runtime.
Informationen zur Einrichtung durch Betreiber, Beispiele für Modellpräfixe und reine Codex-Konfigurationen finden Sie unter
Codex-Harness.
Das Codex-Plugin erzwingt die unter
Codex-Harness dokumentierte minimale App-Server-Version. Es prüft den Initialisierungs-Handshake und
blockiert ältere oder nicht versionierte Server, damit OpenClaw nur mit der getesteten
Protokollschnittstelle arbeitet.
Tool-Ergebnis-Middleware
Gebündelte Plugins und explizit aktivierte installierte Plugins mit passenden Manifestverträgen können überapi.registerAgentToolResultMiddleware(...) Runtime-neutrale Tool-Ergebnis-Middleware anhängen, wenn ihr Manifest die
anvisierten Runtime-IDs in contracts.agentToolResultMiddleware deklariert. Diese vertrauenswürdige
Schnittstelle ist für asynchrone Transformationen von Tool-Ergebnissen vorgesehen, die ausgeführt werden müssen, bevor OpenClaw oder
Codex Tool-Ausgaben wieder an das Modell übergibt.
Gebündelte Legacy-Plugins können weiterhin
api.registerCodexAppServerExtensionFactory(...) für Middleware verwenden, die ausschließlich für den Codex-App-Server
bestimmt ist, neue Ergebnistransformationen sollten jedoch die laufzeitneutrale API verwenden. Der
ausschließlich für den eingebetteten Runner bestimmte Hook api.registerEmbeddedExtensionFactory(...) wurde
entfernt; Transformationen eingebetteter Werkzeugergebnisse müssen laufzeitneutrale Middleware verwenden.
Klassifizierung des terminalen Ergebnisses
Native Harnesses, die ihre eigene Protokollprojektion verwalten, könnenclassifyAgentHarnessTerminalOutcome(...) aus
openclaw/plugin-sdk/agent-harness-runtime verwenden, wenn ein abgeschlossener Turn keinen
sichtbaren Assistententext erzeugt hat. Der Helfer gibt empty, reasoning-only oder
planning-only zurück, damit die Fallback-Richtlinie von OpenClaw entscheiden kann, ob ein erneuter Versuch mit einem
anderen Modell erfolgen soll. planning-only erfordert das explizite Feld planText
des Harnesses; OpenClaw leitet es nicht aus Assistentenprosa ab. Der Helfer
lässt Prompt-Fehler, laufende Turns und absichtlich stille
Antworten wie NO_REPLY bewusst unklassifiziert.
Nebeneffekte am Agentenende
Native Harnesses müssenrunAgentEndSideEffects(...) aus
openclaw/plugin-sdk/agent-harness-runtime aufrufen, nachdem sie einen Versuch abgeschlossen haben. Die Funktion
löst den portablen Hook agent_end und die Forschungserfassung von OpenClaw aus,
ohne interaktive Antworten zu verzögern. Verwenden Sie awaitAgentEndSideEffects(...) für
lokale, nicht interaktive Ausführungen, bei denen der Versuch erst aufgelöst werden darf, nachdem diese
Nebeneffekte abgeschlossen sind. Beide Helfer akzeptieren dieselbe { event, ctx }-Nutzlast wie
runAgentHarnessAgentEndHook(...); ihre Fehler verändern das Ergebnis des abgeschlossenen
Versuchs nicht.
Benutzereingabe- und Werkzeugoberflächen
Native Harnesses, die eine Benutzereingabeanforderung auf Laufzeitebene bereitstellen, sollten die Benutzereingabe-Helfer ausopenclaw/plugin-sdk/agent-harness-runtime verwenden, um
den Prompt zu formatieren, ihn über den blockierenden Antwortpfad von OpenClaw zuzustellen und
Auswahlantworten beziehungsweise Freitextantworten wieder in die native Antwortstruktur der Laufzeit zu normalisieren. Der
Helfer sorgt für eine konsistente Darstellung in Kanälen und der TUI, während jedes Harness seine
eigene Protokollanalyse und den Lebenszyklus ausstehender Anforderungen verwaltet.
Native Harnesses, die eine kompakte PI-ähnliche Werkzeugweiterleitung benötigen, sollten
createAgentHarnessToolSurfaceRuntime(...) aus
openclaw/plugin-sdk/agent-harness-tool-runtime verwenden. Die Funktion verwaltet
die Auswahl der Steuerung für Werkzeugsuche und Codemodus, schlanke Standardwerte für lokale Modelle,
laufzeitkompatible Schemafilterung, die Ausführung des verborgenen Katalogs, die
Verzeichnis-Hydratisierung und die Katalogbereinigung. Harnesses sind weiterhin für ihre SDK-spezifische
Werkzeugkonvertierung und den nativen Ausführungs-Callback verantwortlich.
Nativer Codex-Harness-Modus
Das gebündelte Harnesscodex ist der native Codex-Modus für eingebettete OpenClaw-
Agenten-Turns. Aktivieren Sie zuerst das gebündelte Plugin codex und nehmen Sie codex in
plugins.allow auf, wenn Ihre Konfiguration eine restriktive Zulassungsliste verwendet. Native App-Server-
Konfigurationen sollten openai/gpt-* verwenden; OpenAI-Agenten-Turns wählen das Codex-Harness
nur aus, wenn die effektive Route Codex-Kompatibilität deklariert. Legacy-Codex-Modell-
Referenzen sollten mit openclaw doctor --fix repariert werden, und Legacy-Modellreferenzen vom Typ codex/*
bleiben Kompatibilitätsaliase für das native Harness.
Wenn dieser Modus ausgeführt wird, verwaltet Codex die native Thread-ID, das Fortsetzungsverhalten,
Compaction und die App-Server-Ausführung. OpenClaw verwaltet weiterhin den Chatkanal,
die sichtbare Transkriptspiegelung, die Werkzeugrichtlinie, Genehmigungen, die Medienzustellung und die Sitzungs-
auswahl. Verwenden Sie Provider/Modell agentRuntime.id: "codex", wenn Sie
nachweisen müssen, dass ausschließlich der Codex-App-Server-Pfad die Ausführung übernehmen kann. Explizite Plugin-
Laufzeiten schlagen geschlossen fehl; Auswahlfehler und Laufzeitfehler des Codex-App-Servers
werden nicht über eine andere Laufzeit erneut versucht.
Laufzeitstrenge
Standardmäßig verwendet OpenClaw die Provider/Modell-Laufzeitrichtlinieauto: Registrierte
Plugin-Harnesses können kompatible effektive Routen übernehmen, und die eingebettete
Laufzeit verarbeitet den Turn, wenn kein Harness übereinstimmt. Ein Provider/Modell-Präfix allein
wählt niemals ein Harness aus. Verwenden Sie eine explizite Provider/Modell-Plugin-Laufzeit wie
agentRuntime.id: "codex", wenn eine fehlende Harness-Auswahl fehlschlagen soll,
anstatt über die eingebettete Laufzeit weitergeleitet zu werden. Eine explizite Auswahl macht eine
inkompatible Route nicht kompatibel. Fehler ausgewählter Plugin-Harnesses führen immer
zu einem harten Fehlschlag. Dies blockiert kein explizites Provider/Modell-
agentRuntime.id: "openclaw".
Für ausschließlich Codex verwendende eingebettete Ausführungen:
Native Sitzungen und Transkriptspiegelung
Ein Harness kann eine native Sitzungs-ID, Thread-ID oder ein daemonseitiges Fortsetzungs- Token beibehalten. Halten Sie diese Bindung ausdrücklich mit der OpenClaw-Sitzung verknüpft und spiegeln Sie weiterhin für Benutzer sichtbare Assistenten- und Werkzeugausgaben in das OpenClaw- Transkript. Das OpenClaw-Transkript bleibt die Kompatibilitätsschicht für:- im Kanal sichtbaren Sitzungsverlauf
- Transkriptsuche und -indizierung
- den Wechsel zurück zum integrierten OpenClaw-Harness bei einem späteren Turn
- generisches Verhalten von
/new,/resetund beim Löschen von Sitzungen
reset(...), damit OpenClaw
sie löschen kann, wenn die zugehörige OpenClaw-Sitzung zurückgesetzt wird.
Werkzeug- und Medienergebnisse
Der Core erstellt die OpenClaw-Werkzeugliste und übergibt sie an den vorbereiteten Versuch. Wenn ein Harness einen dynamischen Werkzeugaufruf ausführt, geben Sie das Werkzeugergebnis über die Ergebnisstruktur des Harnesses zurück, anstatt selbst Kanalmedien zu senden. Dadurch verwenden Text-, Bild-, Video-, Musik-, TTS-, Genehmigungs- und Messaging-Werkzeug- Ausgaben denselben Zustellungspfad wie von OpenClaw unterstützte Ausführungen. Setzen SieAgentHarnessAttemptResult.hostOwnedToolMediaUrls nur für native Artefakte,
die die vertrauenswürdige Harness-Laufzeit selbst erstellt und dauerhaft gespeichert hat. Jeder Eintrag muss
auch in toolMediaUrls enthalten sein. Nehmen Sie niemals vom Modell ausgewählte Medien dynamischer Werkzeuge oder
OpenClaw-Werkzeugmedien auf. Auf message_tool_only-Routen ermöglicht diese enge Herkunftszuordnung,
dass Artefakte nativer Laufzeiten die Unterdrückung der Quellantwort überstehen; die normale Senderichtlinie
und die Zulassung für Umgebungsräume gelten weiterhin.
Terminale Werkzeugergebnisse
AgentHarnessAttemptParams.observeToolTerminal ist der vom Host verwaltete Akkumulator für terminale
Ergebnisse. Ein Harness, das dynamische OpenClaw-Werkzeuge oder native
Werkzeuge ausführt, muss ihn aufrufen, sobald jedes Werkzeug genau ein terminales Ergebnis erreicht, bevor das
Versuchsergebnis abgeschlossen wird. Harnesses, die keine Werkzeuge ausführen, müssen ihn nicht
aufrufen.
Melden Sie Fakten von der Ausführungsgrenze:
- Übergeben Sie die Protokollaufruf-ID, sofern vorhanden, den kanonischen Werkzeugnamen und die Argumente, die nach der Vorbereitung oder Umschreibung durch Hooks tatsächlich beim Werkzeug ankamen.
- Setzen Sie
executionStarted: false, wenn Validierung, Genehmigung oder eine andere Schutzmaßnahme den Aufruf gestoppt hat, bevor die Werkzeugimplementierung begann. Sobald eine Weiterleitung stattgefunden haben könnte, melden Sie konservativtrue. - Melden Sie
outcome: "success"oderoutcome: "failure". Nehmen Sie die strukturierten Fehlerfelder auf, die von der Laufzeit verfügbar sind, anstatt einen Fehler aus dem Anzeigetext abzuleiten. - Verwenden Sie
nativeMutationnur für native Werkzeuge, die keine OpenClaw-Werkzeug- definition verwenden. Geben Sie dort protokolleigene Mutations- und Wiedergabefakten an; kopieren Sie den Mutationsklassifizierer von OpenClaw nicht in das Harness.
lastToolError in AgentHarnessAttemptResult und verwenden Sie dessen Ausführungs-,
Argument- und Nebeneffektfakten in der Harness-Projektion, anstatt
parallelen Zustand abzuleiten. Der Host bewahrt einen nicht aufgelösten mutierenden Fehler über nicht zusammenhängende
erfolgreiche Werkzeuge hinweg auf und löscht ihn erst, nachdem die entsprechende Aktion erfolgreich ist.
Der Callback bleibt aus Gründen der Quellkompatibilität mit älteren experimentellen
Harnesses optional. Optional bedeutet für ein Harness, das Werkzeuge ausführt, nicht, dass er ignoriert werden darf:
Ohne terminale Meldungen kann OpenClaw die Wahrheit eines Fehlers mutierender Werkzeuge
über spätere Werkzeugaufrufe hinweg nicht bewahren, einschließlich des stillen Abschlusses eines Heartbeat.
Finalisierung abgeschlossener Werkzeuge
OpenClaw benötigt möglicherweise eine letzte sichtbare Antwort, nachdem ein Harness jeden Werkzeugaufruf abgeschlossen hat, sein nativer Turn jedoch ohne Assistententext endete. Ein Harness kann diese Wiederherstellung durch Implementierung vonfinalizeSettledTurn({ attempt, settledAttempt }) aktivieren.
Der Callback ist eine separate Fähigkeit und kein weiterer gewöhnlicher Versuch. Er muss:
- entweder das exakt eingeschränkte native Transkript oder ein vollständiges Anwendungs- transkript verwenden, das bis einschließlich der Grenze des abgeschlossenen Werkzeugergebnisses eingefroren ist;
- keine Werkzeuge, Funktionen zum Erteilen von Berechtigungen oder für Benutzereingaben, native Ausführungs- Hooks, Agenten, Skills, Speicher, Zeitplanung, Erweiterungen oder Fernsteuerung bereitstellen;
- ausschließlich den vom Host bereitgestellten Finalisierungs-Prompt senden; und
- geschlossen fehlschlagen, wenn die ausgewählte Transkript-/Isolationsstrategie diese Einschränkungen nicht durchsetzen kann.
before_agent_run, LLM-Eingabe/-Ausgabe, terminale Überarbeitung und
agent_end. Die Core-Diagnose zeichnet die Operation und ihren Fehler weiterhin auf.
Der Callback gibt AgentHarnessSettledTurnFinalizationResult zurück, kein
gewöhnliches Versuchsergebnis. Seine öffentlichen Felder sind auf die abgeschlossene
Assistentennachricht, die Nutzung des Finalisierungsaufrufs, Metadaten zur Transkriptzuständigkeit und
die Diagnosespur beschränkt. Werkzeug-, Zustellungs-, Medien-, Erzeugungs-, Lebenszyklus-, Wiedergabe-, Sitzungs- und
Fallback-Zustand können diese Ergebnisgrenze nicht überschreiten. Unbekannte Felder und Assistenten-
Werkzeugaufrufe schlagen geschlossen fehl.
Ein Harness, das intern seine vollständige Versuchs-Engine wiederverwendet, kann vor der Rückgabe
projectSettledTurnFinalizationAttemptResult(...) aufrufen. Der Helfer
weist kanonische Fehler-, Werkzeug-, Zustellungs-, Wiedergabe- und Lebenszyklusnachweise zurück und
projiziert anschließend nur das enge Ergebnis. Dies dient als gestaffelte Absicherung nach der nativen Isolation
und ersetzt nicht das Entfernen der nativen Fähigkeitsoberfläche.
Ein projektionsgestütztes Harness muss den vollständigen Kontext in
settledAttempt.settledTurnFinalizationContext mit
source: "openclaw-transcript" ablegen. Es muss den aktiven Zweig erfassen, nachdem der
abgeschlossene Turn gespiegelt wurde, nachweisen, dass der aktuelle Prompt und jeder aktuelle Werkzeug-
aufruf sowie jedes Ergebnis bis zu dieser Grenze vorhanden sind, und das resultierende Nachrichten-
Array vor der Rückgabe des Versuchs einfrieren. Der Finalisierer muss einen fehlenden,
nicht unterstützten, mehrdeutigen oder übergroßen Kontext zurückweisen. Er darf Nachrichten nicht kürzen,
frühere Verlaufsdaten nicht verwerfen und dieses Anwendungstranskript nicht als exakten nativen
Verlauf bezeichnen. Harnesses, die eine einzelne eingeschränkte native Sitzung fortsetzen, benötigen dieses
Projektionsfeld nicht.
Implementieren Sie diesen Callback nicht, indem Sie runAttempt mit einem Best-Effort-
Hinweis disableTools aufrufen. Der Harness-Eigentümer muss die vollständige native
Fähigkeitsgrenze durchsetzen. OpenClaw stellt keinen generischen Fallback bereit, da es
nicht bestätigen kann, dass eine beliebige native Laufzeit diese Einschränkungen eingehalten hat.
Der Callback bleibt für die Kompatibilität mit experimentellen Harnesses von Drittanbietern optional. Wenn der ausgewählte Harness ihn nicht bereitstellt, behält OpenClaw den bestehenden Fehler für einen unvollständigen Turn bei, anstatt wiederholte Seiteneffekte zu riskieren.
Aktuelle Einschränkungen
- Der öffentliche Importpfad ist generisch, einige Typaliase für Versuche und Ergebnisse tragen aus Kompatibilitätsgründen jedoch weiterhin veraltete Namen.
- Die Installation von Harnesses von Drittanbietern ist experimentell. Bevorzugen Sie Provider-Plugins, bis Sie eine native Sitzungs-Runtime benötigen.
- Der Wechsel zwischen Harnesses wird über mehrere Turns hinweg unterstützt. Wechseln Sie den Harness nicht mitten in einem Turn, nachdem native Tools, Genehmigungen, Assistententext oder das Senden von Nachrichten begonnen haben.