Перейти до основного вмісту

Documentation Index

Fetch the complete documentation index at: https://docs.openclaw.ai/llms.txt

Use this file to discover all available pages before exploring further.

OpenClaw застосовує виправлення, специфічні для провайдера, до транскриптів перед запуском (побудовою контексту моделі). Більшість із них — це коригування в пам’яті, які потрібні для виконання суворих вимог провайдерів. Окремий прохід відновлення файла сесії також може переписати збережений JSONL перед завантаженням сесії, але лише для некоректно сформованих рядків або збережених ходів, які є недійсними довговічними записами. Доставлені відповіді асистента зберігаються на диску; видалення assistant-prefill, специфічне для провайдера, відбувається лише під час побудови вихідних payload. Коли відбувається відновлення, резервна копія оригінального файла зберігається поруч із файлом сесії. Область охоплює:
  • Контекст prompt лише для runtime, який не потрапляє в видимі користувачу ходи транскрипту
  • Санітизацію ідентифікаторів викликів інструментів
  • Валідацію вхідних даних викликів інструментів
  • Відновлення парності результатів інструментів
  • Валідацію / впорядкування ходів
  • Очищення підписів думок
  • Очищення thinking-підписів
  • Санітизацію image payload
  • Очищення порожніх текстових блоків перед повторним відтворенням у провайдера
  • Позначення походження користувацького вводу (для prompt, маршрутизованих між сесіями)
  • Відновлення порожніх error-ходів асистента для повторного відтворення Bedrock Converse
Якщо вам потрібні подробиці про зберігання транскриптів, див.:

​
Глобальне правило: runtime-контекст не є користувацьким транскриптом

Runtime/system-контекст може бути доданий до prompt моделі для ходу, але це не вміст, створений кінцевим користувачем. OpenClaw зберігає окреме тіло prompt, звернене до транскрипту, для відповідей Gateway, поставлених у чергу followup, ACP, CLI та вбудованих запусків Pi. Збережені видимі ходи користувача використовують це тіло транскрипту замість prompt, збагаченого runtime. Для застарілих сесій, у яких уже збережено runtime-обгортки, поверхні історії Gateway застосовують проєкцію відображення перед поверненням повідомлень клієнтам WebChat, TUI, REST або SSE.

​
Де це виконується

Уся гігієна транскриптів централізована у вбудованому runner:
  • Вибір політики: src/agents/transcript-policy.ts
  • Застосування санітизації/відновлення: sanitizeSessionHistory у src/agents/pi-embedded-runner/replay-history.ts
Політика використовує provider, modelApi і modelId, щоб вирішити, що застосовувати. Окремо від гігієни транскриптів, файли сесій відновлюються (за потреби) перед завантаженням:
  • repairSessionFileIfNeeded у src/agents/session-file-repair.ts
  • Викликається з run/attempt.ts і compact.ts (вбудований runner)

​
Глобальне правило: санітизація зображень

Image payload завжди санітизується, щоб запобігти відхиленню на боці провайдера через обмеження розміру (зменшення масштабу/повторне стискання завеликих base64-зображень). Це також допомагає контролювати image-driven token pressure для моделей із підтримкою vision. Менші максимальні розміри зазвичай зменшують використання токенів; більші розміри зберігають деталізацію. Реалізація:
  • sanitizeSessionMessagesImages у src/agents/pi-embedded-helpers/images.ts
  • sanitizeContentBlocksImages у src/agents/tool-images.ts
  • Максимальна сторона зображення налаштовується через agents.defaults.imageMaxDimensionPx (типово: 1200).
  • Порожні текстові блоки видаляються, поки цей прохід обходить вміст для повторного відтворення. Ходи асистента, які стають порожніми, вилучаються з копії для повторного відтворення; ходи користувача та tool-result, які стають порожніми, отримують непорожній placeholder пропущеного вмісту.

​
Глобальне правило: некоректно сформовані виклики інструментів

Блоки assistant tool-call, у яких немає ані input, ані arguments, вилучаються перед побудовою контексту моделі. Це запобігає відхиленням провайдером через частково збережені виклики інструментів (наприклад, після помилки rate limit). Реалізація:
  • sanitizeToolCallInputs у src/agents/session-transcript-repair.ts
  • Застосовується в sanitizeSessionHistory у src/agents/pi-embedded-runner/replay-history.ts

​
Глобальне правило: походження міжсесійного вводу

Коли агент надсилає prompt в іншу сесію через sessions_send (включно з кроками reply/announce між агентами), OpenClaw зберігає створений хід користувача з:
  • message.provenance.kind = "inter_session"
OpenClaw також додає на початку того самого ходу маркер [Inter-session message ... isUser=false] перед текстом маршрутизованого prompt, щоб активний виклик моделі міг відрізнити вихід чужої сесії від зовнішніх інструкцій кінцевого користувача. Цей маркер містить джерельну сесію, канал і інструмент, коли вони доступні. Транскрипт усе ще використовує role: "user" для сумісності з провайдерами, але і видимий текст, і metadata походження позначають хід як міжсесійні дані. Під час перебудови контексту OpenClaw застосовує той самий маркер до старіших збережених міжсесійних ходів користувача, які мають лише metadata походження.

​
Матриця провайдерів (поточна поведінка)

OpenAI / OpenAI Codex
  • Лише санітизація зображень.
  • Вилучати осиротілі reasoning-підписи (окремі reasoning items без наступного блоку вмісту) для транскриптів OpenAI Responses/Codex і вилучати придатний до повторного відтворення OpenAI reasoning після перемикання маршруту моделі.
  • Зберігати payload придатних до повторного відтворення OpenAI Responses reasoning item, включно із зашифрованими елементами з порожнім summary, щоб ручне/WebSocket повторне відтворення зберігало потрібний стан rs_* у парі з output items асистента.
  • Native ChatGPT Codex Responses дотримується parity дротового протоколу Codex, повторно відтворюючи попередні Responses reasoning/message/function payload без попередніх item IDs, водночас зберігаючи session prompt_cache_key.
  • Без санітизації ідентифікаторів викликів інструментів.
  • Відновлення парності результатів інструментів може переміщувати справжні зіставлені outputs і синтезувати Codex-стиль aborted outputs для відсутніх викликів інструментів.
  • Без валідації або перевпорядкування ходів.
  • Відсутні outputs інструментів родини OpenAI Responses синтезуються як aborted, щоб відповідати нормалізації повторного відтворення Codex.
  • Без видалення підписів думок.
OpenAI-сумісні Chat Completions
  • Історичні блоки thinking/reasoning асистента видаляються перед повторним відтворенням, щоб локальні та proxy-style OpenAI-сумісні сервери не отримували поля reasoning попередніх ходів, як-от reasoning або reasoning_content.
  • Поточні продовження tool-call у межах того самого ходу зберігають reasoning-блок асистента, прикріплений до виклику інструмента, доки результат інструмента не буде повторно відтворено.
  • Винятки, що належать провайдеру, можуть відмовитися від цього, коли їхній дротовий протокол вимагає повторно відтворюваної reasoning metadata.
Google (Generative AI / Gemini CLI / Antigravity)
  • Санітизація ідентифікаторів викликів інструментів: суворо буквено-цифрові.
  • Відновлення парності результатів інструментів і синтетичні результати інструментів.
  • Валідація ходів (Gemini-style чергування ходів).
  • Виправлення впорядкування ходів Google (додавання крихітного user bootstrap на початку, якщо історія починається з асистента).
  • Antigravity Claude: нормалізувати thinking-підписи; вилучати непідписані thinking-блоки.
Anthropic / Minimax (Anthropic-сумісний)
  • Відновлення парності результатів інструментів і синтетичні результати інструментів.
  • Валідація ходів (об’єднання послідовних ходів користувача для дотримання суворого чергування).
  • Кінцеві assistant prefill-ходи видаляються з вихідних payload Anthropic Messages, коли thinking увімкнено, включно з маршрутами Cloudflare AI Gateway.
  • Thinking-блоки з відсутніми, порожніми або blank підписами повторного відтворення видаляються перед конвертацією провайдера. Якщо це спорожнює хід асистента, OpenClaw зберігає форму ходу з непорожнім omitted-reasoning текстом.
  • Старіші thinking-only ходи асистента, які потрібно видалити, замінюються непорожнім omitted-reasoning текстом, щоб provider adapters не відкидали хід повторного відтворення.
Amazon Bedrock (Converse API)
  • Порожні stream-error ходи асистента відновлюються до непорожнього fallback text block перед повторним відтворенням. Bedrock Converse відхиляє повідомлення асистента з content: [], тому збережені ходи асистента з stopReason: "error" і порожнім вмістом також відновлюються на диску перед завантаженням.
  • Stream-error ходи асистента, що містять лише blank text blocks, вилучаються з in-memory копії для повторного відтворення замість повторного відтворення недійсного blank block.
  • Claude thinking-блоки з відсутніми, порожніми або blank підписами повторного відтворення видаляються перед повторним відтворенням Converse. Якщо це спорожнює хід асистента, OpenClaw зберігає форму ходу з непорожнім omitted-reasoning текстом.
  • Старіші thinking-only ходи асистента, які потрібно видалити, замінюються непорожнім omitted-reasoning текстом, щоб повторне відтворення Converse зберігало сувору форму ходу.
  • Повторне відтворення фільтрує OpenClaw delivery-mirror і gateway-injected ходи асистента.
  • Санітизація зображень застосовується через глобальне правило.
Mistral (включно з detection на основі model-id)
  • Санітизація ідентифікаторів викликів інструментів: strict9 (буквено-цифрові, довжина 9).
OpenRouter Gemini
  • Очищення підписів думок: видаляти не-base64 значення thought_signature (залишати base64).
OpenRouter Anthropic
  • Кінцеві assistant prefill-ходи видаляються з payload перевірених OpenRouter OpenAI-сумісних Anthropic-моделей, коли reasoning увімкнено, відповідно до поведінки повторного відтворення прямого Anthropic і Cloudflare Anthropic.
Усе інше
  • Лише санітизація зображень.

​
Історична поведінка (до 2026.1.22)

До релізу 2026.1.22 OpenClaw застосовував кілька шарів гігієни транскриптів:
  • transcript-sanitize extension запускався на кожній побудові контексту і міг:
    • Відновлювати парність tool use/result.
    • Санітизувати ідентифікатори викликів інструментів (включно з non-strict режимом, який зберігав _/-).
  • Runner також виконував специфічну для провайдера санітизацію, що дублювало роботу.
  • Додаткові мутації відбувалися поза політикою провайдера, включно з:
    • Видаленням тегів <final> з тексту асистента перед збереженням.
    • Вилученням порожніх error-ходів асистента.
    • Обрізанням вмісту асистента після викликів інструментів.
Ця складність спричиняла кроспровайдерні регресії (особливо openai-responses парність call_id|fc_id). Очищення 2026.1.22 видалило extension, централізувало логіку в runner і зробило OpenAI no-touch поза санітизацією зображень.

​
Пов’язане