agent harness — це низькорівневий виконавець для одного підготовленого ходу агента OpenClaw. Він не є постачальником моделі, каналом чи реєстром інструментів. Опис користувацької ментальної моделі дивіться в середовищах виконання агентів. Використовуйте цю поверхню лише для вбудованих або довірених нативних plugins. Контракт досі експериментальний, оскільки типи параметрів навмисно віддзеркалюють поточний вбудований runner.Documentation Index
Fetch the complete documentation index at: https://docs2.openclaw.ai/llms.txt
Use this file to discover all available pages before exploring further.
Коли використовувати harness
Реєструйте agent harness, коли сімейство моделей має власне нативне середовище виконання сесій, а звичайний транспорт постачальника OpenClaw є хибною абстракцією. Приклади:- нативний сервер coding-agent, який володіє потоками та compaction
- локальний CLI або daemon, який має транслювати нативні події плану/міркувань/інструментів
- середовище виконання моделі, якому потрібен власний resume id на додачу до транскрипту сесії OpenClaw
Чим досі володіє core
Перш ніж буде вибрано harness, OpenClaw уже визначає:- постачальника та модель
- стан автентифікації середовища виконання
- рівень thinking і бюджет контексту
- файл транскрипту/сесії OpenClaw
- workspace, sandbox і політику інструментів
- callbacks відповіді каналу та callbacks streaming
- політику fallback моделі та live перемикання моделей
params.runtimePlan, пакет політик, яким володіє OpenClaw,
для рішень середовища виконання, що мають лишатися спільними для PI та нативних
harnesses:
runtimePlan.tools.normalize(...)іruntimePlan.tools.logDiagnostics(...)для політики схем інструментів з урахуванням постачальникаruntimePlan.transcript.resolvePolicy(...)для sanitization транскрипту та політики repair викликів інструментівruntimePlan.delivery.isSilentPayload(...)для спільногоNO_REPLYта приглушення доставки mediaruntimePlan.outcome.classifyRunResult(...)для класифікації fallback моделіruntimePlan.observabilityдля визначених metadata постачальника/моделі/harness
Реєстрація harness
Імпорт:openclaw/plugin-sdk/agent-harness
Політика вибору
OpenClaw вибирає harness після визначення постачальника/моделі:- Спершу застосовується runtime policy на рівні моделі.
- Далі застосовується runtime policy на рівні постачальника.
autoзапитує зареєстровані harnesses, чи підтримують вони визначену пару постачальник/модель.- Якщо жоден зареєстрований harness не збігається, OpenClaw використовує PI, якщо PI fallback не вимкнено.
auto PI fallback
використовується лише тоді, коли жоден зареєстрований plugin harness не підтримує визначену
пару постачальник/модель. Щойно plugin harness заявив право на запуск, OpenClaw не
відтворює той самий хід через PI, оскільки це може змінити семантику auth/runtime
або дублювати побічні ефекти.
Pins середовища виконання для цілої сесії та цілого агента ігноруються під час вибору. Це
включає застарілі значення сесії agentHarnessId, agents.defaults.agentRuntime,
agents.list[].agentRuntime і OPENCLAW_AGENT_RUNTIME. /status показує
ефективне середовище виконання, вибране з маршруту постачальник/модель.
Якщо вибраний harness несподіваний, увімкніть debug logging agents/harness і
перегляньте структурований запис gateway agent harness selected. Він містить
id вибраного harness, причину вибору, політику runtime/fallback і, у режимі
auto, результат підтримки кожного кандидата plugin.
Вбудований Codex plugin реєструє codex як свій harness id. Core трактує це
як звичайний plugin harness id; специфічні для Codex aliases мають бути в plugin
або operator config, а не в спільному selector середовища виконання.
Поєднання постачальника та harness
Більшість harnesses також мають реєструвати постачальника. Постачальник робить refs моделей, статус auth, metadata моделей і вибір/model видимими для решти
OpenClaw. Після цього harness заявляє цього постачальника в supports(...).
Вбудований Codex plugin дотримується цього шаблону:
- бажані refs користувацьких моделей:
openai/gpt-5.5 - refs сумісності: застарілі refs
codex/gpt-*досі приймаються, але нові configs не повинні використовувати їх як звичайні refs постачальник/модель - harness id:
codex - auth: синтетична доступність постачальника, оскільки Codex harness володіє нативним login/session Codex
- запит app-server: OpenClaw надсилає Codex лише bare model id і дозволяє harness працювати з нативним protocol app-server
openai/gpt-* на офіційному
постачальнику OpenAI за замовчуванням вибирають Codex harness. Старі refs codex/gpt-*
досі вибирають Codex provider і harness для сумісності.
Для налаштування operator, прикладів model prefix і configs лише для Codex дивіться
Codex Harness.
OpenClaw потребує Codex app-server 0.125.0 або новішого. Codex plugin перевіряє
initialize handshake app-server і блокує старіші або безверсійні сервери, щоб
OpenClaw запускався лише проти protocol surface, з якою його тестували. Поріг
0.125.0 включає підтримку payload нативного MCP hook, яка зʼявилася в
Codex 0.124.0, водночас привʼязуючи OpenClaw до новішої протестованої stable line.
Middleware результатів інструментів
Вбудовані plugins можуть приєднувати runtime-neutral middleware результатів інструментів черезapi.registerAgentToolResultMiddleware(...), коли їхній manifest оголошує
цільові runtime ids у contracts.agentToolResultMiddleware. Цей довірений
seam призначений для async перетворень результатів інструментів, які мають виконатися до того, як PI або Codex передасть
вивід інструменту назад у модель.
Застарілі вбудовані plugins усе ще можуть використовувати
api.registerCodexAppServerExtensionFactory(...) для middleware лише Codex app-server,
але нові result transforms повинні використовувати runtime-neutral API.
Pi-only hook api.registerEmbeddedExtensionFactory(...) вилучено;
Pi tool-result transforms мають використовувати runtime-neutral middleware.
Класифікація terminal outcome
Нативні harnesses, які володіють власною protocol projection, можуть використовуватиclassifyAgentHarnessTerminalOutcome(...) з
openclaw/plugin-sdk/agent-harness-runtime, коли завершений хід не створив
видимого тексту assistant. Helper повертає empty, reasoning-only або
planning-only, щоб fallback policy OpenClaw могла вирішити, чи повторювати спробу на
іншій моделі. Він навмисно не класифікує prompt errors, in-flight turns і
навмисні silent replies, такі як NO_REPLY.
Нативний режим Codex harness
Вбудований harnesscodex є нативним режимом Codex для вбудованих ходів агента OpenClaw.
Спершу ввімкніть вбудований plugin codex і додайте codex до
plugins.allow, якщо ваш config використовує restrictive allowlist. Нативні configs app-server
мають використовувати openai/gpt-*; ходи агентів OpenAI за замовчуванням вибирають Codex harness.
Застарілі маршрути openai-codex/* слід виправити за допомогою
openclaw doctor --fix, а застарілі refs моделей codex/* лишаються compatibility
aliases для нативного harness.
Коли цей режим працює, Codex володіє нативним thread id, поведінкою resume,
compaction і виконанням app-server. OpenClaw досі володіє chat channel,
видимим дзеркалом транскрипту, політикою інструментів, approvals, media delivery і вибором
сесії. Використовуйте provider/model agentRuntime.id: "codex", коли потрібно довести,
що лише шлях Codex app-server може заявити запуск. Явні plugin runtimes
завершуються fail-closed; збої вибору Codex app-server і runtime failures не
повторюються через PI.
Суворість runtime
За замовчуванням OpenClaw використовує runtime policy постачальник/модельauto: зареєстровані
plugin harnesses можуть заявити пару постачальник/модель, а PI обробляє хід, коли
збігів немає. Refs агентів OpenAI на офіційному постачальнику OpenAI за замовчуванням використовують Codex.
Використовуйте явний provider/model plugin runtime, наприклад
agentRuntime.id: "codex", коли відсутній вибір harness має завершуватися помилкою замість
маршрутизації через PI. Збої вибраних plugin harness завжди завершуються жорсткою помилкою. Це
не блокує явний provider/model agentRuntime.id: "pi".
Для вбудованих запусків лише Codex:
Нативні сесії та дзеркало транскрипту
Harness може зберігати нативний session id, thread id або resume token на боці daemon. Тримайте цю привʼязку явно повʼязаною із сесією OpenClaw і продовжуйте дзеркалити видимий для користувача assistant/tool output у транскрипт OpenClaw. Транскрипт OpenClaw лишається compatibility layer для:- видимої в каналі історії сесії
- пошуку та індексації транскриптів
- перемикання назад на вбудований PI harness у пізнішому ході
- generic поведінки
/new,/resetі видалення сесії
reset(...), щоб OpenClaw міг
очистити її, коли відповідну сесію OpenClaw скинуто.
Результати інструментів і media
Core створює список інструментів OpenClaw і передає його до підготовленої спроби. Коли harness виконує dynamic tool call, поверніть результат інструменту через форму результату harness замість самостійного надсилання channel media. Це тримає text, image, video, music, TTS, approval і messaging-tool outputs на тому самому delivery path, що й запуски з підтримкою PI.Поточні обмеження
- Публічний шлях імпорту є generic, але деякі aliases типів attempt/result досі
містять назви
Piдля сумісності. - Встановлення third-party harness є експериментальним. Віддавайте перевагу provider plugins, доки вам не потрібне нативне середовище виконання сесії.
- Перемикання harness підтримується між ходами. Не перемикайте harnesses посередині ходу після запуску native tools, approvals, assistant text або message sends.