diff --git a/docs/uk/concepts/messages.md b/docs/uk/concepts/messages.md index dc5451ae3..f6b5fc595 100644 --- a/docs/uk/concepts/messages.md +++ b/docs/uk/concepts/messages.md @@ -1,21 +1,20 @@ --- read_when: - - Пояснення того, як вхідні повідомлення стають відповідями - - Уточнення сесій, режимів черги або поведінки потокового передавання - - Документування видимості міркувань і наслідків для використання + - Пояснення того, як вхідні повідомлення перетворюються на відповіді + - Уточнення сесій, режимів постановки в чергу або поведінки потокової передачі + - Документування видимості міркувань і наслідків використання summary: Потік повідомлень, сесії, постановка в чергу та видимість міркувань title: Повідомлення x-i18n: - generated_at: "2026-04-24T03:43:53Z" + generated_at: "2026-04-25T17:09:45Z" model: gpt-5.4 provider: openai - source_hash: 22a154246f47b5841dc9d4b9f8e3c5698e5e56bc0b2dbafe19fec45799dbbba9 + source_hash: 1e085e778b10f9fbf3ccc8fb2939667b3c2b2bc88f5dc0be6c5c4fc1fc96e9d0 source_path: concepts/messages.md workflow: 15 --- -Ця сторінка об’єднує пояснення того, як OpenClaw обробляє вхідні повідомлення, сесії, постановку в чергу, -потокове передавання та видимість міркувань. +Ця сторінка об’єднує інформацію про те, як OpenClaw обробляє вхідні повідомлення, сесії, постановку в чергу, потокову передачу та видимість міркувань. ## Потік повідомлень (загальний рівень) @@ -27,27 +26,27 @@ Inbound message -> outbound replies (channel limits + chunking) ``` -Ключові параметри містяться в конфігурації: +Ключові параметри розташовані в конфігурації: -- `messages.*` для префіксів, постановки в чергу та поведінки груп. -- `agents.defaults.*` для типових значень block streaming і chunking. -- Перевизначення каналів (`channels.whatsapp.*`, `channels.telegram.*` тощо) для лімітів і перемикачів потокового передавання. +- `messages.*` для префіксів, постановки в чергу та поведінки в групах. +- `agents.defaults.*` для типових налаштувань блокової потокової передачі та розбиття на частини. +- Перевизначення каналів (`channels.whatsapp.*`, `channels.telegram.*` тощо) для обмежень і перемикачів потокової передачі. -Див. [Конфігурація](/uk/gateway/configuration) для повної схеми. +Повну схему див. у [Configuration](/uk/gateway/configuration). -## Усунення дублікатів вхідних повідомлень +## Усунення дублювання вхідних повідомлень -Канали можуть повторно доставляти те саме повідомлення після повторного підключення. OpenClaw зберігає -короткочасний кеш із ключем channel/account/peer/session/message id, щоб дублікати -доставки не запускали ще один запуск агента. +Канали можуть повторно доставляти те саме повідомлення після перепідключень. OpenClaw зберігає +короткочасний кеш, прив’язаний до channel/account/peer/session/message id, щоб повторні +доставлення не запускали ще один запуск агента. -## Дебаунсинг вхідних повідомлень +## Антидребезг вхідних повідомлень -Швидкі послідовні повідомлення від **того самого відправника** можна об’єднати в один -хід агента через `messages.inbound`. Дебаунсинг має область дії per channel + conversation -і використовує найновіше повідомлення для тредингу/ID відповіді. +Швидкі послідовні повідомлення від **того самого відправника** можуть бути об’єднані в один +хід агента через `messages.inbound`. Антидребезг застосовується окремо для кожного каналу + розмови +і використовує найновіше повідомлення для зв’язування відповіді/ID. -Конфігурація (глобальне типове значення + перевизначення для каналу): +Конфігурація (глобальне значення за замовчуванням + перевизначення для окремих каналів): ```json5 { @@ -66,119 +65,121 @@ Inbound message Примітки: -- Дебаунсинг застосовується до повідомлень **лише з текстом**; медіа/вкладення надсилаються негайно. -- Керівні команди обходять дебаунсинг, щоб залишатися окремими — **окрім** випадків, коли канал явно вмикає об’єднання DM від того самого відправника (наприклад, [BlueBubbles `coalesceSameSenderDms`](/uk/channels/bluebubbles#coalescing-split-send-dms-command--url-in-one-composition)), де DM-команди очікують у межах вікна дебаунсингу, щоб payload розділеного надсилання міг увійти до того самого ходу агента. +- Антидребезг застосовується до повідомлень **лише з текстом**; медіа/вкладення скидають буфер негайно. +- Керівні команди обходять антидребезг, щоб залишатися окремими — **окрім** випадків, коли канал явно вмикає об’єднання DM від одного відправника, наприклад [BlueBubbles `coalesceSameSenderDms`](/uk/channels/bluebubbles#coalescing-split-send-dms-command--url-in-one-composition), де команди в DM чекають у межах вікна антидребезгу, щоб розділене надсилання могло потрапити в той самий хід агента. ## Сесії та пристрої Сесіями володіє Gateway, а не клієнти. -- Прямі чати згортаються в ключ головної сесії агента. +- Прямі чати згортаються в основний ключ сесії агента. - Групи/канали отримують власні ключі сесій. -- Сховище сесій і транскрипти розміщені на хості Gateway. +- Сховище сесій і транскрипти розміщуються на хості Gateway. -Кілька пристроїв/каналів можуть зіставлятися з тією самою сесією, але історія не повністю +Кілька пристроїв/каналів можуть відображатися на ту саму сесію, але історія не повністю синхронізується назад на кожен клієнт. Рекомендація: використовуйте один основний пристрій для довгих -розмов, щоб уникнути розходження контексту. UI керування і TUI завжди показують -транскрипт сесії з Gateway, тому саме вони є джерелом істини. +розмов, щоб уникнути розходження контексту. Control UI і TUI завжди показують +транскрипт сесії, що зберігається в Gateway, тому саме вони є джерелом істини. -Докладніше: [Керування сесіями](/uk/concepts/session). +Докладніше: [Session management](/uk/concepts/session). -## Вхідні тіла повідомлень і контекст історії +## Вхідні тіла повідомлень та контекст історії -OpenClaw розділяє **тіло prompt** і **тіло команди**: +OpenClaw розділяє **тіло запиту** та **тіло команди**: -- `Body`: текст prompt, надісланий агенту. Він може містити channel envelope і - необов’язкові history wrapper. -- `CommandBody`: сирий текст користувача для розбору директив/команд. -- `RawBody`: застарілий псевдонім для `CommandBody` (збережений для сумісності). +- `Body`: текст запиту, надісланий агенту. Він може містити обгортки каналу та + необов’язкові обгортки історії. +- `CommandBody`: необроблений текст користувача для розбору директив/команд. +- `RawBody`: застарілий псевдонім для `CommandBody` (залишений для сумісності). -Коли канал надає історію, він використовує спільну обгортку: +Коли канал надає історію, використовується спільна обгортка: - `[Chat messages since your last reply - for context]` - `[Current message - respond to this]` -Для **непрямих чатів** (груп/каналів/кімнат) **тіло поточного повідомлення** має префікс із -міткою відправника (у тому ж стилі, що використовується для записів історії). Це зберігає -узгодженість повідомлень у реальному часі та в черзі/історії в prompt агента. +Для **непрямих чатів** (груп/каналів/кімнат) **тіло поточного повідомлення** отримує префікс із +міткою відправника (той самий стиль, що використовується для записів історії). Це забезпечує +узгодженість повідомлень у реальному часі та відкладених/історичних повідомлень у запиті агента. -Буфери історії є **лише pending**: вони включають групові повідомлення, які _не_ -запустили виконання (наприклад, повідомлення, що вимагають згадки) і **не включають** повідомлення, +Буфери історії є **лише pending**: вони включають повідомлення групи, які _не_ +запустили виконання (наприклад, повідомлення, що вимагають згадки), і **не включають** повідомлення, які вже є в транскрипті сесії. -Видалення директив застосовується лише до секції **поточного повідомлення**, тому історія -залишається недоторканою. Канали, які обгортають історію, мають встановлювати `CommandBody` (або -`RawBody`) в оригінальний текст повідомлення і зберігати `Body` як об’єднаний prompt. +Видалення директив застосовується лише до секції **поточного повідомлення**, щоб історія +залишалася недоторканою. Канали, які обгортають історію, повинні встановлювати `CommandBody` (або +`RawBody`) в оригінальний текст повідомлення та залишати `Body` як об’єднаний запит. Буфери історії налаштовуються через `messages.groupChat.historyLimit` (глобальне -типове значення) і перевизначення для каналу, як-от `channels.slack.historyLimit` або +значення за замовчуванням) і перевизначення для окремих каналів, наприклад `channels.slack.historyLimit` або `channels.telegram.accounts..historyLimit` (встановіть `0`, щоб вимкнути). -## Постановка в чергу та followup +## Постановка в чергу та подальші повідомлення -Якщо виконання вже активне, вхідні повідомлення можна поставити в чергу, спрямувати до -поточного виконання або зібрати для followup-ходу. +Якщо виконання вже активне, вхідні повідомлення можна поставити в чергу, спрямувати в +поточне виконання або зібрати для наступного ходу. - Налаштовується через `messages.queue` (і `messages.queue.byChannel`). -- Режими: `interrupt`, `steer`, `followup`, `collect`, а також варіанти backlog. +- Режими: `interrupt`, `steer`, `followup`, `collect`, а також варіанти для беклогу. -Докладніше: [Черга](/uk/concepts/queue). +Докладніше: [Queueing](/uk/concepts/queue). -## Потокове передавання, chunking і batching +## Потокова передача, розбиття на частини та пакетування -Block streaming надсилає часткові відповіді в міру того, як модель створює текстові блоки. -Chunking враховує обмеження каналів на текст і уникає розриву fenced code. +Блокова потокова передача надсилає часткові відповіді в міру того, як модель створює текстові блоки. +Розбиття на частини враховує обмеження каналу на текст і уникає розриву огороджених блоків коду. -Ключові параметри: +Ключові налаштування: -- `agents.defaults.blockStreamingDefault` (`on|off`, типово off) +- `agents.defaults.blockStreamingDefault` (`on|off`, за замовчуванням off) - `agents.defaults.blockStreamingBreak` (`text_end|message_end`) - `agents.defaults.blockStreamingChunk` (`minChars|maxChars|breakPreference`) -- `agents.defaults.blockStreamingCoalesce` (batching на основі idle) -- `agents.defaults.humanDelay` (людиноподібна пауза між block-відповідями) +- `agents.defaults.blockStreamingCoalesce` (пакетування на основі простою) +- `agents.defaults.humanDelay` (людиноподібна пауза між блоковими відповідями) - Перевизначення каналів: `*.blockStreaming` і `*.blockStreamingCoalesce` (для каналів, відмінних від Telegram, потрібно явно вказати `*.blockStreaming: true`) -Докладніше: [Потокове передавання + chunking](/uk/concepts/streaming). +Докладніше: [Streaming + chunking](/uk/concepts/streaming). ## Видимість міркувань і токени OpenClaw може показувати або приховувати міркування моделі: - `/reasoning on|off|stream` керує видимістю. -- Вміст міркувань усе одно враховується у використанні токенів, якщо його створила модель. -- Telegram підтримує потокове передавання міркувань у чернеткову бульбашку. +- Вміст міркувань усе одно враховується у використанні токенів, якщо його створює модель. +- Telegram підтримує потокову передачу міркувань у чернетку-бульбашку. -Докладніше: [Thinking + reasoning directives](/uk/tools/thinking) і [Використання токенів](/uk/reference/token-use). +Докладніше: [Thinking + reasoning directives](/uk/tools/thinking) і [Token use](/uk/reference/token-use). ## Префікси, трединг і відповіді -Форматування вихідних повідомлень централізоване в `messages`: +Форматування вихідних повідомлень централізовано в `messages`: -- `messages.responsePrefix`, `channels..responsePrefix` і `channels..accounts..responsePrefix` (каскад префіксів вихідних повідомлень), а також `channels.whatsapp.messagePrefix` (префікс вхідних повідомлень WhatsApp) -- Трединг відповідей через `replyToMode` і типові значення для кожного каналу +- `messages.responsePrefix`, `channels..responsePrefix` і `channels..accounts..responsePrefix` (каскад вихідних префіксів), а також `channels.whatsapp.messagePrefix` (вхідний префікс WhatsApp) +- Трединг відповідей через `replyToMode` і типові налаштування для окремих каналів -Докладніше: [Конфігурація](/uk/gateway/config-agents#messages) і документація каналів. +Докладніше: [Configuration](/uk/gateway/config-agents#messages) і документацію каналів. ## Тихі відповіді Точний тихий токен `NO_REPLY` / `no_reply` означає «не надсилати видиму для користувача відповідь». +Коли хід також має очікувані медіа від інструментів, наприклад згенероване аудіо TTS, OpenClaw +видаляє тихий текст, але все одно доставляє медіавкладення. OpenClaw визначає цю поведінку за типом розмови: -- Прямі розмови типово не дозволяють тишу й переписують голу тиху - відповідь на короткий видимий резервний варіант. -- Групи/канали типово дозволяють тишу. -- Внутрішня оркестрація типово дозволяє тишу. +- Прямі розмови за замовчуванням не дозволяють тишу та переписують голу тиху + відповідь на короткий видимий запасний варіант. +- Групи/канали за замовчуванням дозволяють тишу. +- Внутрішня оркестрація за замовчуванням дозволяє тишу. Типові значення розміщені в `agents.defaults.silentReply` і `agents.defaults.silentReplyRewrite`; `surfaces..silentReply` і -`surfaces..silentReplyRewrite` можуть перевизначати їх для кожної surface. +`surfaces..silentReplyRewrite` можуть перевизначати їх для кожної поверхні. -Коли батьківська сесія має один або більше pending spawned subagent run, -голі тихі відповіді відкидаються на всіх surfaces замість переписування, щоб -батьківський процес залишався тихим, доки подія завершення дочірнього агента не доставить справжню відповідь. +Коли батьківська сесія має один або більше очікуваних породжених запусків субагентів, +голі тихі відповіді відкидаються на всіх поверхнях замість переписування, щоб +батьківський агент залишався тихим, доки подія завершення дочірнього агента не доставить справжню відповідь. ## Пов’язане -- [Потокове передавання](/uk/concepts/streaming) — доставка повідомлень у реальному часі -- [Повтор](/uk/concepts/retry) — поведінка повторної доставки повідомлень -- [Черга](/uk/concepts/queue) — черга обробки повідомлень -- [Канали](/uk/channels) — інтеграції з платформами обміну повідомленнями +- [Streaming](/uk/concepts/streaming) — доставка повідомлень у реальному часі +- [Retry](/uk/concepts/retry) — поведінка повторної доставки повідомлень +- [Queue](/uk/concepts/queue) — черга обробки повідомлень +- [Channels](/uk/channels) — інтеграції платформ обміну повідомленнями diff --git a/docs/uk/help/gpt54-codex-agentic-parity-maintainers.md b/docs/uk/help/gpt54-codex-agentic-parity-maintainers.md deleted file mode 100644 index ff529440d..000000000 --- a/docs/uk/help/gpt54-codex-agentic-parity-maintainers.md +++ /dev/null @@ -1,203 +0,0 @@ ---- -read_when: - - Перегляд серії PR паритету GPT-5.4 / Codex - - Підтримка шестиконтрактної агентної архітектури, що лежить в основі програми паритету -summary: Як переглянути програму паритету GPT-5.4 / Codex як чотири одиниці злиття -title: Примітки супровідника паритету GPT-5.4 / Codex -x-i18n: - generated_at: "2026-04-25T10:35:04Z" - model: gpt-5.4 - provider: openai - source_hash: 162ea68476880d4dbf9b8c3b9397a51a2732c3eb10ac52e421a9c9d90e04eec2 - source_path: help/gpt54-codex-agentic-parity-maintainers.md - workflow: 15 ---- - -Ця примітка пояснює, як переглядати програму паритету GPT-5.4 / Codex як чотири одиниці злиття, не втрачаючи початкову шестиконтрактну архітектуру. - -## Одиниці злиття - -### PR A: суворе агентне виконання - -Відповідає за: - -- `executionContract` -- GPT-5-first same-turn follow-through -- `update_plan` як нетермінальне відстеження прогресу -- явні заблоковані стани замість мовчазних зупинок лише з планом - -Не відповідає за: - -- класифікацію збоїв auth/runtime -- правдивість permission -- перероблення replay/continuation -- бенчмаркінг паритету - -### PR B: правдивість runtime - -Відповідає за: - -- коректність OAuth scope у Codex -- типізовану класифікацію збоїв provider/runtime -- правдиву доступність `/elevated full` і причини блокування - -Не відповідає за: - -- нормалізацію схем інструментів -- стан replay/liveness -- benchmark gating - -### PR C: коректність виконання - -Відповідає за: - -- сумісність інструментів OpenAI/Codex, що належить provider -- сувору обробку схем без параметрів -- відображення replay-invalid -- видимість станів paused, blocked і abandoned для довгих завдань - -Не відповідає за: - -- самостійно обране continuation -- загальну поведінку діалекту Codex поза provider hooks -- benchmark gating - -### PR D: набір засобів паритету - -Відповідає за: - -- першу хвилю набору сценаріїв GPT-5.4 vs Opus 4.6 -- документацію паритету -- механіку звіту про паритет і release gate - -Не відповідає за: - -- зміни поведінки runtime поза QA-lab -- симуляцію auth/proxy/DNS усередині набору засобів - -## Відображення назад до початкових шести контрактів - -| Початковий контракт | Одиниця злиття | -| ---------------------------------------- | -------------- | -| Коректність provider transport/auth | PR B | -| Сумісність контрактів/схем інструментів | PR C | -| Виконання в межах того самого ходу | PR A | -| Правдивість permission | PR B | -| Коректність replay/continuation/liveness | PR C | -| Benchmark/release gate | PR D | - -## Порядок перегляду - -1. PR A -2. PR B -3. PR C -4. PR D - -PR D — це рівень доказовості. Він не повинен бути причиною, через яку затримуються PR із коректністю runtime. - -## На що звертати увагу - -### PR A - -- запуски GPT-5 виконують дію або завершуються у безпечний спосіб, а не зупиняються на коментарі -- `update_plan` більше не виглядає як прогрес сам по собі -- поведінка залишається GPT-5-first і обмеженою embedded-Pi - -### PR B - -- збої auth/proxy/runtime перестають зводитися до загальної обробки “model failed” -- `/elevated full` описується як доступний лише тоді, коли він справді доступний -- причини блокування видимі і моделі, і runtime, видимому для користувача - -### PR C - -- сувора реєстрація інструментів OpenAI/Codex поводиться передбачувано -- інструменти без параметрів не провалюють перевірки суворої схеми -- результати replay і Compaction зберігають правдивий стан liveness - -### PR D - -- набір сценаріїв зрозумілий і відтворюваний -- набір містить маршрут mutating replay-safety, а не лише read-only потоки -- звіти читабельні для людей і автоматизації -- твердження про паритет підтверджені доказами, а не анекдотичні - -Очікувані артефакти від PR D: - -- `qa-suite-report.md` / `qa-suite-summary.json` для кожного запуску моделі -- `qa-agentic-parity-report.md` з агрегованим і посценарним порівнянням -- `qa-agentic-parity-summary.json` із вердиктом у машиночитному форматі - -## Release gate - -Не заявляйте про паритет або перевагу GPT-5.4 над Opus 4.6, доки: - -- PR A, PR B і PR C не злиті -- PR D не запускає чисто першу хвилю набору паритету -- набори регресійної перевірки правдивості runtime залишаються зеленими -- звіт про паритет не показує випадків фальшивого успіху і регресії в поведінці зупинки - -```mermaid -flowchart LR - A["PR A-C merged"] --> B["Run GPT-5.4 parity pack"] - A --> C["Run Opus 4.6 parity pack"] - B --> D["qa-suite-summary.json"] - C --> E["qa-suite-summary.json"] - D --> F["qa parity-report"] - E --> F - F --> G["Markdown report + JSON verdict"] - G --> H{"Pass?"} - H -- "yes" --> I["Parity claim allowed"] - H -- "no" --> J["Keep runtime fixes / review loop open"] -``` - -Набір засобів паритету — не єдине джерело доказів. Під час перегляду чітко зберігайте цей поділ: - -- PR D відповідає за порівняння GPT-5.4 vs Opus 4.6 на основі сценаріїв -- детерміновані набори PR B все ще відповідають за докази auth/proxy/DNS і правдивості повного доступу - -## Короткий робочий процес злиття для супровідника - -Використовуйте це, коли ви готові зливати parity PR і хочете повторювану послідовність із низьким ризиком. - -1. Підтвердьте, що планка доказовості досягнута перед злиттям: - - відтворюваний симптом або тест, що падає - - перевірена першопричина в зачепленому коді - - виправлення в ураженому шляху - - регресійний тест або явна примітка про ручну перевірку -2. Проведіть тріаж/маркування перед злиттям: - - застосуйте всі авто-закривальні мітки `r:*`, якщо PR не повинен бути злитий - - кандидати на злиття мають бути без нерозв’язаних блокувальних обговорень -3. Перевірте локально зачеплену поверхню: - - `pnpm check:changed` - - `pnpm test:changed`, якщо тести змінювалися або впевненість у виправленні бага залежить від покриття тестами -4. Злийте через стандартний процес супровідника (`/landpr`), а потім перевірте: - - поведінку авто-закриття пов’язаних issues - - CI і статус після злиття на `main` -5. Після злиття виконайте пошук дублікатів серед пов’язаних відкритих PR/issues і закривайте лише з канонічним посиланням. - -Якщо бракує хоча б одного елемента планки доказовості, запитуйте зміни замість злиття. - -## Мапа цілей до доказів - -| Елемент completion gate | Основний відповідальний | Артефакт перегляду | -| ---------------------------------------- | ----------------------- | ------------------------------------------------------------------- | -| Немає зависань лише на плані | PR A | тести runtime суворого агентного режиму і `approval-turn-tool-followthrough` | -| Немає фальшивого прогресу чи фальшивого завершення інструмента | PR A + PR D | кількість фальшивих успіхів у паритеті плюс деталі посценарного звіту | -| Немає хибних підказок `/elevated full` | PR B | детерміновані набори перевірки правдивості runtime | -| Збої replay/liveness залишаються явними | PR C + PR D | набори lifecycle/replay плюс `compaction-retry-mutating-tool` | -| GPT-5.4 відповідає Opus 4.6 або перевершує його | PR D | `qa-agentic-parity-report.md` і `qa-agentic-parity-summary.json` | - -## Скорочення для рецензента: до vs після - -| Видима для користувача проблема до | Сигнал після перегляду | -| --------------------------------------------------------- | -------------------------------------------------------------------------------------- | -| GPT-5.4 зупинявся після планування | PR A показує поведінку дії-або-блокування замість завершення лише на коментарі | -| Використання інструментів здавалося крихким із суворими схемами OpenAI/Codex | PR C зберігає передбачуваність реєстрації інструментів і виклику без параметрів | -| Підказки `/elevated full` інколи вводили в оману | PR B прив’язує підказки до реальних можливостей runtime і причин блокування | -| Довгі завдання могли зникати в неоднозначності replay/Compaction | PR C видає явний стан paused, blocked, abandoned і replay-invalid | -| Твердження про паритет були анекдотичними | PR D формує звіт і JSON-вердикт з однаковим покриттям сценаріїв для обох моделей | - -## Пов’язане - -- [Агентний паритет GPT-5.4 / Codex](/uk/help/gpt54-codex-agentic-parity) diff --git a/docs/uk/help/gpt54-codex-agentic-parity.md b/docs/uk/help/gpt54-codex-agentic-parity.md deleted file mode 100644 index d03f8d2de..000000000 --- a/docs/uk/help/gpt54-codex-agentic-parity.md +++ /dev/null @@ -1,239 +0,0 @@ ---- -read_when: - - Налагодження агентної поведінки GPT-5.4 або Codex - - Порівняння агентної поведінки OpenClaw у різних frontier-моделях - - Огляд виправлень strict-agentic, схем інструментів, підвищення привілеїв і відтворення -summary: Як OpenClaw закриває прогалини агентного виконання для GPT-5.4 і моделей у стилі Codex -title: Агентна паритетність GPT-5.4 / Codex -x-i18n: - generated_at: "2026-04-24T04:14:46Z" - model: gpt-5.4 - provider: openai - source_hash: 9f8c7dcf21583e6dbac80da9ddd75f2dc9af9b80801072ade8fa14b04258d4dc - source_path: help/gpt54-codex-agentic-parity.md - workflow: 15 ---- - -# Агентна паритетність GPT-5.4 / Codex в OpenClaw - -OpenClaw уже добре працював із frontier-моделями, що використовують інструменти, але GPT-5.4 і моделі у стилі Codex усе ще відставали в кількох практичних аспектах: - -- вони могли зупинятися після планування замість виконання роботи -- вони могли неправильно використовувати строгі схеми інструментів OpenAI/Codex -- вони могли запитувати `/elevated full`, навіть коли повний доступ був неможливий -- вони могли втрачати стан довготривалого завдання під час відтворення або Compaction -- твердження про паритет із Claude Opus 4.6 ґрунтувалися на анекдотах, а не на відтворюваних сценаріях - -Ця програма паритетності закриває ці прогалини чотирма придатними до рев’ю частинами. - -## Що змінилося - -### PR A: strict-agentic виконання - -Ця частина додає контракт виконання `strict-agentic` з увімкненням за бажанням для вбудованих запусків Pi GPT-5. - -Коли його ввімкнено, OpenClaw більше не приймає ходи лише з планом як “достатньо добре” завершення. Якщо модель лише каже, що вона збирається зробити, але фактично не використовує інструменти й не просувається далі, OpenClaw повторює спробу з настановою діяти негайно, а потім завершує роботу в закритому режимі з явним заблокованим станом замість тихого завершення завдання. - -Найбільше це покращує досвід GPT-5.4 у таких випадках: - -- короткі уточнення на кшталт “гаразд, зроби це” -- задачі з кодом, де перший крок очевидний -- потоки, у яких `update_plan` має відстежувати прогрес, а не бути текстом-заповнювачем - -### PR B: правдивість часу виконання - -Ця частина змушує OpenClaw казати правду про дві речі: - -- чому виклик провайдера/часу виконання не вдався -- чи справді доступний `/elevated full` - -Це означає, що GPT-5.4 отримує кращі сигнали часу виконання щодо відсутньої області дії, збоїв оновлення автентифікації, збоїв автентифікації HTML 403, проблем із проксі, збоїв DNS або тайм-аутів, а також заблокованих режимів повного доступу. Імовірність того, що модель вигадає неправильний спосіб виправлення або й далі проситиме режим дозволів, який середовище виконання не може надати, зменшується. - -### PR C: коректність виконання - -Ця частина покращує два типи коректності: - -- сумісність схем інструментів OpenAI/Codex, що належать провайдеру -- видимість відтворення та живучості довгих завдань - -Робота над сумісністю інструментів зменшує тертя зі схемами для суворої реєстрації інструментів OpenAI/Codex, особливо навколо інструментів без параметрів і суворих очікувань кореня-об’єкта. Робота над відтворенням/живучістю робить довготривалі завдання більш спостережуваними, тож призупинені, заблоковані та покинуті стани стають видимими замість того, щоб губитися в загальному тексті помилки. - -### PR D: каркас паритетності - -Ця частина додає перший набір паритетності QA-lab, щоб GPT-5.4 і Opus 4.6 можна було запускати через однакові сценарії та порівнювати за спільними доказами. - -Набір паритетності є рівнем доказу. Сам по собі він не змінює поведінку часу виконання. - -Після того як у вас буде два артефакти `qa-suite-summary.json`, згенеруйте порівняння для релізного шлюзу так: - -```bash -pnpm openclaw qa parity-report \ - --repo-root . \ - --candidate-summary .artifacts/qa-e2e/gpt54/qa-suite-summary.json \ - --baseline-summary .artifacts/qa-e2e/opus46/qa-suite-summary.json \ - --output-dir .artifacts/qa-e2e/parity -``` - -Ця команда записує: - -- Markdown-звіт, придатний для читання людиною -- JSON-результат, придатний для читання машиною -- явний результат шлюзу `pass` / `fail` - -## Чому це покращує GPT-5.4 на практиці - -До цієї роботи GPT-5.4 в OpenClaw міг здаватися менш агентним, ніж Opus, у реальних сесіях програмування, тому що середовище виконання допускало поведінку, особливо шкідливу для моделей стилю GPT-5: - -- ходи лише з коментарями -- тертя зі схемами навколо інструментів -- нечіткий зворотний зв’язок щодо дозволів -- тихе ламання відтворення або Compaction - -Мета не в тому, щоб змусити GPT-5.4 імітувати Opus. Мета в тому, щоб дати GPT-5.4 контракт часу виконання, який винагороджує реальний прогрес, надає чистішу семантику інструментів і дозволів та перетворює режими збоїв на явні машиночитані й людиночитані стани. - -Це змінює користувацький досвід із: - -- “модель мала хороший план, але зупинилася” - -на: - -- “модель або подіяла, або OpenClaw явно показав точну причину, чому не зміг” - -## До і після для користувачів GPT-5.4 - -| До цієї програми | Після PR A-D | -| ------------------------------------------------------------------------------------------- | ------------------------------------------------------------------------------------------- | -| GPT-5.4 міг зупинитися після розумного плану, не зробивши наступного кроку з інструментом | PR A перетворює “лише план” на “дій зараз або покажи заблокований стан” | -| Строгі схеми інструментів могли плутано відхиляти інструменти без параметрів або форми OpenAI/Codex | PR C робить реєстрацію та виклик інструментів, що належать провайдеру, передбачуванішими | -| Підказки для `/elevated full` могли бути нечіткими або неправильними в заблокованих середовищах | PR B дає GPT-5.4 і користувачу правдиві підказки часу виконання та дозволів | -| Збої відтворення або Compaction могли виглядати так, ніби завдання тихо зникло | PR C явно показує призупинені, заблоковані, покинуті та replay-invalid результати | -| “GPT-5.4 здається гіршим за Opus” було переважно анекдотичним | PR D перетворює це на однаковий набір сценаріїв, однакові метрики та жорсткий шлюз pass/fail | - -## Архітектура - -```mermaid -flowchart TD - A["User request"] --> B["Embedded Pi runtime"] - B --> C["Strict-agentic execution contract"] - B --> D["Provider-owned tool compatibility"] - B --> E["Runtime truthfulness"] - B --> F["Replay and liveness state"] - C --> G["Tool call or explicit blocked state"] - D --> G - E --> G - F --> G - G --> H["QA-lab parity pack"] - H --> I["Scenario report and parity gate"] -``` - -## Потік релізу - -```mermaid -flowchart LR - A["Merged runtime slices (PR A-C)"] --> B["Run GPT-5.4 parity pack"] - A --> C["Run Opus 4.6 parity pack"] - B --> D["qa-suite-summary.json"] - C --> E["qa-suite-summary.json"] - D --> F["openclaw qa parity-report"] - E --> F - F --> G["qa-agentic-parity-report.md"] - F --> H["qa-agentic-parity-summary.json"] - H --> I{"Gate pass?"} - I -- "yes" --> J["Evidence-backed parity claim"] - I -- "no" --> K["Keep runtime/review loop open"] -``` - -## Набір сценаріїв - -Поточний перший набір паритетності охоплює п’ять сценаріїв: - -### `approval-turn-tool-followthrough` - -Перевіряє, що модель не зупиняється на “я це зроблю” після короткого підтвердження. Вона має виконати першу конкретну дію в тому самому ході. - -### `model-switch-tool-continuity` - -Перевіряє, що робота з використанням інструментів залишається узгодженою при переході між моделями/середовищами виконання, а не скидається до коментарів чи не втрачає контекст виконання. - -### `source-docs-discovery-report` - -Перевіряє, що модель може читати вихідний код і документацію, синтезувати висновки та продовжувати завдання агентно, а не видавати тонкий підсумок і зупинятися зарано. - -### `image-understanding-attachment` - -Перевіряє, що змішані задачі з вкладеннями залишаються придатними до дії й не зводяться до нечіткої оповіді. - -### `compaction-retry-mutating-tool` - -Перевіряє, що завдання з реальною змінювальною операцією запису зберігає явну небезпеку відтворення, а не тихо виглядає безпечним для відтворення, якщо виконання зазнає Compaction, повторюється або втрачає стан відповіді під навантаженням. - -## Матриця сценаріїв - -| Сценарій | Що він перевіряє | Хороша поведінка GPT-5.4 | Сигнал збою | -| ---------------------------------- | --------------------------------------- | -------------------------------------------------------------------------------- | -------------------------------------------------------------------------------- | -| `approval-turn-tool-followthrough` | Короткі ходи підтвердження після плану | Негайно починає першу конкретну дію з інструментом замість повторення наміру | уточнення лише планом, відсутність активності інструментів або заблокований хід без реального блокера | -| `model-switch-tool-continuity` | Перемикання середовища виконання/моделі під час використання інструментів | Зберігає контекст завдання й продовжує діяти узгоджено | скидається до коментарів, втрачає контекст інструментів або зупиняється після перемикання | -| `source-docs-discovery-report` | Читання джерел + синтез + дія | Знаходить джерела, використовує інструменти й створює корисний звіт без зависання | тонкий підсумок, відсутня робота з інструментами або зупинка на неповному ході | -| `image-understanding-attachment` | Агентна робота на основі вкладень | Інтерпретує вкладення, пов’язує його з інструментами й продовжує завдання | нечітка оповідь, вкладення проігноровано або відсутня конкретна наступна дія | -| `compaction-retry-mutating-tool` | Змінювальна робота під тиском Compaction | Виконує реальний запис і зберігає явну небезпеку відтворення після побічного ефекту | змінювальний запис відбувається, але безпечність відтворення мається на увазі, відсутня або суперечлива | - -## Релізний шлюз - -GPT-5.4 можна вважати таким, що досяг паритету або перевершує його, лише коли об’єднане середовище виконання проходить набір паритетності та регресії правдивості часу виконання одночасно. - -Потрібні результати: - -- жодного зависання на одному лише плані, коли наступна дія інструмента очевидна -- жодного фальшивого завершення без реального виконання -- жодних неправильних підказок для `/elevated full` -- жодного тихого покидання через відтворення або Compaction -- метрики набору паритетності щонайменше не слабші за узгоджену базову лінію Opus 4.6 - -Для першого каркаса шлюз порівнює: - -- рівень завершення -- рівень ненавмисних зупинок -- рівень коректних викликів інструментів -- кількість фальшивих успіхів - -Докази паритетності навмисно розділено на два шари: - -- PR D доводить поведінку GPT-5.4 проти Opus 4.6 на однакових сценаріях через QA-lab -- детерміновані набори PR B доводять правдивість автентифікації, проксі, DNS і `/elevated full` поза каркасом - -## Матриця відповідності цілей і доказів - -| Елемент шлюзу завершення | Власний PR | Джерело доказів | Сигнал проходження | -| -------------------------------------------------------- | ----------- | ----------------------------------------------------------------- | --------------------------------------------------------------------------------------- | -| GPT-5.4 більше не зависає після планування | PR A | `approval-turn-tool-followthrough` плюс набори часу виконання PR A | ходи підтвердження запускають реальну роботу або явний заблокований стан | -| GPT-5.4 більше не підробляє прогрес або фальшиве завершення інструменту | PR A + PR D | результати сценаріїв у звіті паритетності та кількість фальшивих успіхів | немає підозрілих результатів проходження й немає завершення лише коментарем | -| GPT-5.4 більше не дає хибних підказок `/elevated full` | PR B | детерміновані набори правдивості | причини блокування й підказки повного доступу залишаються точними щодо часу виконання | -| Збої відтворення/живучості залишаються явними | PR C + PR D | набори життєвого циклу/відтворення PR C плюс `compaction-retry-mutating-tool` | змінювальна робота зберігає явну небезпеку відтворення замість тихого зникнення | -| GPT-5.4 відповідає або перевершує Opus 4.6 за узгодженими метриками | PR D | `qa-agentic-parity-report.md` і `qa-agentic-parity-summary.json` | однакове покриття сценаріїв і відсутність регресії у завершенні, поведінці зупинок або коректному використанні інструментів | - -## Як читати вердикт паритетності - -Використовуйте вердикт у `qa-agentic-parity-summary.json` як остаточне машиночитане рішення для першого набору паритетності. - -- `pass` означає, що GPT-5.4 покрив ті самі сценарії, що й Opus 4.6, і не показав регресії за узгодженими агрегованими метриками. -- `fail` означає, що спрацював принаймні один жорсткий шлюз: слабше завершення, гірші ненавмисні зупинки, слабше коректне використання інструментів, будь-який випадок фальшивого успіху або невідповідне покриття сценаріїв. -- “shared/base CI issue” сам по собі не є результатом паритетності. Якщо шум CI поза PR D блокує запуск, вердикт має чекати чистого виконання об’єднаного середовища, а не виводитися з логів епохи гілки. -- Правдивість автентифікації, проксі, DNS і `/elevated full`, як і раніше, походить із детермінованих наборів PR B, тому для фінального релізного твердження потрібні обидва пункти: позитивний вердикт паритетності PR D і зелене покриття правдивості PR B. - -## Кому слід увімкнути `strict-agentic` - -Використовуйте `strict-agentic`, коли: - -- очікується, що агент діятиме негайно, якщо наступний крок очевидний -- основним середовищем виконання є GPT-5.4 або моделі сімейства Codex -- ви надаєте перевагу явним заблокованим станам замість “корисних” відповідей лише з переказом - -Залишайте типовий контракт, коли: - -- вам потрібна наявна м’якша поведінка -- ви не використовуєте моделі сімейства GPT-5 -- ви тестуєте підказки, а не примусове застосування правил часу виконання - -## Пов’язане - -- [Нотатки для супроводу паритетності GPT-5.4 / Codex](/uk/help/gpt54-codex-agentic-parity-maintainers) diff --git a/docs/uk/help/gpt55-codex-agentic-parity-maintainers.md b/docs/uk/help/gpt55-codex-agentic-parity-maintainers.md new file mode 100644 index 000000000..b2e34c13a --- /dev/null +++ b/docs/uk/help/gpt55-codex-agentic-parity-maintainers.md @@ -0,0 +1,203 @@ +--- +read_when: + - Перегляд серії PR паритету GPT-5.5 / Codex + - Підтримка шестиконтрактної агентної архітектури, що лежить в основі програми паритету +summary: Як переглянути програму паритету GPT-5.5 / Codex як чотири одиниці злиття +title: Нотатки супровідника паритету GPT-5.5 / Codex +x-i18n: + generated_at: "2026-04-25T17:09:45Z" + model: gpt-5.4 + provider: openai + source_hash: 8de69081f5985954b88583880c36388dc47116c3351c15d135b8ab3a660058e3 + source_path: help/gpt55-codex-agentic-parity-maintainers.md + workflow: 15 +--- + +Ця нотатка пояснює, як переглядати програму паритету GPT-5.5 / Codex як чотири одиниці злиття, не втрачаючи початкову шестиконтрактну архітектуру. + +## Одиниці злиття + +### PR A: strict-agentic виконання + +Відповідає за: + +- `executionContract` +- GPT-5-first same-turn follow-through +- `update_plan` як нетермінальне відстеження прогресу +- явні заблоковані стани замість тихих зупинок лише на рівні плану + +Не відповідає за: + +- класифікацію збоїв auth/runtime +- правдивість permission +- redesign replay/continuation +- parity benchmarking + +### PR B: правдивість runtime + +Відповідає за: + +- коректність Codex OAuth scope +- типізовану класифікацію збоїв provider/runtime +- правдиву доступність `/elevated full` і причини блокування + +Не відповідає за: + +- нормалізацію схеми tool +- стан replay/liveness +- benchmark gating + +### PR C: коректність виконання + +Відповідає за: + +- сумісність tool OpenAI/Codex, якою володіє provider +- обробку strict schema без параметрів +- відображення replay-invalid +- видимість станів paused, blocked і abandoned для довгих завдань + +Не відповідає за: + +- self-elected continuation +- загальну поведінку Codex dialect поза provider hooks +- benchmark gating + +### PR D: parity harness + +Відповідає за: + +- first-wave GPT-5.5 vs Opus 4.6 scenario pack +- документацію parity +- механіку parity report і release-gate + +Не відповідає за: + +- зміни поведінки runtime поза QA-lab +- симуляцію auth/proxy/DNS усередині harness + +## Відображення назад на початкові шість контрактів + +| Початковий контракт | Одиниця злиття | +| --------------------------------------- | -------------- | +| Коректність provider transport/auth | PR B | +| Сумісність contract/schema для tool | PR C | +| Виконання в тому самому ході | PR A | +| Правдивість permission | PR B | +| Коректність replay/continuation/liveness | PR C | +| Benchmark/release gate | PR D | + +## Порядок перегляду + +1. PR A +2. PR B +3. PR C +4. PR D + +PR D — це доказовий шар. Він не має бути причиною затримки PR із коректністю runtime. + +## На що звертати увагу + +### PR A + +- запуски GPT-5 виконують дію або fail closed замість зупинки на commentary +- `update_plan` більше не виглядає як прогрес сам по собі +- поведінка залишається GPT-5-first і обмеженою embedded-Pi scope + +### PR B + +- збої auth/proxy/runtime більше не згортаються в загальну обробку “model failed” +- `/elevated full` описується як доступний лише тоді, коли він справді доступний +- причини блокування видимі і моделі, і user-facing runtime + +### PR C + +- strict реєстрація tool OpenAI/Codex поводиться передбачувано +- tools без параметрів не провалюють перевірки strict schema +- результати replay і Compaction зберігають правдивий стан liveness + +### PR D + +- scenario pack зрозумілий і відтворюваний +- pack включає mutating replay-safety lane, а не лише read-only flows +- звіти читабельні для людей і automation +- твердження про parity підкріплені доказами, а не анекдотами + +Очікувані артефакти від PR D: + +- `qa-suite-report.md` / `qa-suite-summary.json` для кожного запуску моделі +- `qa-agentic-parity-report.md` з aggregate і comparison на рівні scenario +- `qa-agentic-parity-summary.json` з verdict у machine-readable форматі + +## Release gate + +Не стверджуйте про паритет або перевагу GPT-5.5 над Opus 4.6, доки: + +- PR A, PR B і PR C не злиті +- PR D не виконає first-wave parity pack без помилок +- regression suites для runtime-truthfulness залишаються зеленими +- parity report не показує випадків fake-success і regressions у stop behavior + +```mermaid +flowchart LR + A["PR A-C merged"] --> B["Run GPT-5.5 parity pack"] + A --> C["Run Opus 4.6 parity pack"] + B --> D["qa-suite-summary.json"] + C --> E["qa-suite-summary.json"] + D --> F["qa parity-report"] + E --> F + F --> G["Markdown report + JSON verdict"] + G --> H{"Pass?"} + H -- "yes" --> I["Parity claim allowed"] + H -- "no" --> J["Keep runtime fixes / review loop open"] +``` + +Parity harness — не єдине джерело доказів. Явно зберігайте цей поділ під час перегляду: + +- PR D відповідає за scenario-based comparison GPT-5.5 vs Opus 4.6 +- детерміновані suites PR B і надалі відповідають за докази щодо auth/proxy/DNS і правдивості full-access + +## Швидкий робочий процес злиття для супровідника + +Використовуйте це, коли готові зливати parity PR і хочете повторювану послідовність із низьким ризиком. + +1. Підтвердьте, що планка доказів досягнута перед злиттям: + - відтворюваний симптом або failing test + - підтверджена root cause у зміненому коді + - виправлення в шляху, якого стосується проблема + - regression test або явна примітка про manual verification +2. Виконайте triage/label перед злиттям: + - застосуйте будь-які `r:*` auto-close labels, якщо PR не має бути злитий + - не залишайте кандидатів на злиття з невирішеними blocker threads +3. Локально перевірте змінену поверхню: + - `pnpm check:changed` + - `pnpm test:changed`, якщо змінювалися тести або впевненість у bug fix залежить від test coverage +4. Виконайте злиття через стандартний maintainer flow (процес `/landpr`), потім перевірте: + - поведінку auto-close для пов’язаних issues + - статус CI і post-merge на `main` +5. Після злиття виконайте пошук дублікатів пов’язаних відкритих PR/issues і закривайте їх лише з канонічним посиланням. + +Якщо бракує хоча б одного пункту з планки доказів, запитуйте зміни замість злиття. + +## Відображення цілей на докази + +| Пункт completion gate | Основний відповідальний | Артефакт перегляду | +| ---------------------------------------- | ----------------------- | -------------------------------------------------------------------- | +| Немає зависань лише на рівні плану | PR A | strict-agentic runtime tests і `approval-turn-tool-followthrough` | +| Немає fake progress або fake tool completion | PR A + PR D | кількість fake-success у parity плюс деталі звіту на рівні scenario | +| Немає хибних підказок `/elevated full` | PR B | детерміновані suites runtime-truthfulness | +| Збої replay/liveness залишаються явними | PR C + PR D | suites lifecycle/replay плюс `compaction-retry-mutating-tool` | +| GPT-5.5 відповідає або перевершує Opus 4.6 | PR D | `qa-agentic-parity-report.md` і `qa-agentic-parity-summary.json` | + +## Скорочення для рецензента: до vs після + +| Видима для користувача проблема до | Сигнал під час перегляду після | +| -------------------------------------------------------- | -------------------------------------------------------------------------------------- | +| GPT-5.5 зупинявся після планування | PR A показує поведінку act-or-block замість завершення лише з commentary | +| Використання tool здавалося крихким зі strict schema OpenAI/Codex | PR C зберігає передбачуваність реєстрації tool і викликів без параметрів | +| Підказки `/elevated full` іноді вводили в оману | PR B прив’язує підказки до фактичних можливостей runtime і причин блокування | +| Довгі завдання могли зникати в неоднозначності replay/Compaction | PR C виводить явний стан paused, blocked, abandoned і replay-invalid | +| Твердження про parity були анекдотичними | PR D створює звіт і JSON verdict з однаковим покриттям scenario для обох моделей | + +## Пов’язане + +- [Агентний паритет GPT-5.5 / Codex](/uk/help/gpt55-codex-agentic-parity) diff --git a/docs/uk/help/gpt55-codex-agentic-parity.md b/docs/uk/help/gpt55-codex-agentic-parity.md new file mode 100644 index 000000000..169bbea70 --- /dev/null +++ b/docs/uk/help/gpt55-codex-agentic-parity.md @@ -0,0 +1,239 @@ +--- +read_when: + - Налагодження агентної поведінки GPT-5.5 або Codex + - Порівняння агентної поведінки OpenClaw у різних frontier-моделях + - Огляд виправлень strict-agentic, tool-schema, elevation і replay +summary: Як OpenClaw закриває прогалини агентного виконання для GPT-5.5 і моделей у стилі Codex +title: Паритет агентної роботи GPT-5.5 / Codex +x-i18n: + generated_at: "2026-04-25T17:09:50Z" + model: gpt-5.4 + provider: openai + source_hash: 8a3b9375cd9e9d95855c4a1135953e00fd7a939e52fb7b75342da3bde2d83fe1 + source_path: help/gpt55-codex-agentic-parity.md + workflow: 15 +--- + +# Паритет агентної роботи GPT-5.5 / Codex в OpenClaw + +OpenClaw уже добре працював із frontier-моделями, що використовують інструменти, але GPT-5.5 і моделі у стилі Codex все ще показували гірші результати в кількох практичних аспектах: + +- вони могли зупинятися після планування замість виконання роботи +- вони могли некоректно використовувати суворі схеми інструментів OpenAI/Codex +- вони могли запитувати `/elevated full`, навіть коли повний доступ був неможливий +- вони могли втрачати стан довготривалих завдань під час replay або Compaction +- твердження про паритет із Claude Opus 4.6 ґрунтувалися на анекдотичних випадках, а не на відтворюваних сценаріях + +Ця програма паритету усуває ці прогалини чотирма окремими частинами, придатними для рев'ю. + +## Що змінилося + +### PR A: суворе агентне виконання + +Ця частина додає опціональний контракт виконання `strict-agentic` для вбудованих запусків Pi GPT-5. + +Коли його ввімкнено, OpenClaw більше не вважає ходи лише з планом «достатньо хорошим» завершенням. Якщо модель лише каже, що збирається зробити, але фактично не використовує інструменти й не просувається вперед, OpenClaw повторює спробу з настановою діяти негайно, а потім завершує із явним заблокованим станом замість того, щоб мовчки завершити завдання. + +Це найбільше покращує роботу GPT-5.5 у таких випадках: + +- короткі уточнення на кшталт «ок, зроби це» +- завдання з кодом, де перший крок очевидний +- потоки, де `update_plan` має бути відстеженням прогресу, а не текстом-заповнювачем + +### PR B: правдивість середовища виконання + +Ця частина змушує OpenClaw говорити правду про дві речі: + +- чому виклик провайдера/середовища виконання завершився помилкою +- чи справді доступний `/elevated full` + +Це означає, що GPT-5.5 отримує кращі сигнали від середовища виконання щодо відсутнього scope, збоїв оновлення auth, помилок auth HTML 403, проблем із proxy, DNS або таймаутами, а також заблокованих режимів повного доступу. Модель з меншою ймовірністю вигадуватиме неправильний спосіб виправлення або продовжуватиме просити режим дозволів, який середовище виконання не може надати. + +### PR C: коректність виконання + +Ця частина покращує два види коректності: + +- сумісність схем інструментів OpenAI/Codex, якими володіє провайдер +- видимість replay і життєздатності довгих завдань + +Робота над сумісністю інструментів зменшує тертя зі схемами під час суворої реєстрації інструментів OpenAI/Codex, особливо навколо інструментів без параметрів і суворих очікувань щодо кореня-об'єкта. Робота над replay/життєздатністю робить довготривалі завдання більш спостережуваними, тож стани паузи, блокування та покинутості стають видимими замість того, щоб зникати в загальному тексті про помилку. + +### PR D: набір перевірок паритету + +Ця частина додає першу хвилю набору перевірок паритету QA-lab, щоб GPT-5.5 і Opus 4.6 можна було проганяти через однакові сценарії й порівнювати за спільними доказами. + +Набір перевірок паритету — це доказовий шар. Сам по собі він не змінює поведінку середовища виконання. + +Після того як у вас буде два артефакти `qa-suite-summary.json`, згенеруйте порівняння для release gate за допомогою: + +```bash +pnpm openclaw qa parity-report \ + --repo-root . \ + --candidate-summary .artifacts/qa-e2e/gpt55/qa-suite-summary.json \ + --baseline-summary .artifacts/qa-e2e/opus46/qa-suite-summary.json \ + --output-dir .artifacts/qa-e2e/parity +``` + +Ця команда записує: + +- Markdown-звіт, зручний для читання людиною +- JSON-версію рішення, зручну для читання машиною +- явний результат перевірки `pass` / `fail` + +## Чому це практично покращує GPT-5.5 + +До цієї роботи GPT-5.5 в OpenClaw міг здаватися менш агентним, ніж Opus, у реальних сесіях програмування, тому що середовище виконання допускало поведінку, яка особливо шкідлива для моделей у стилі GPT-5: + +- ходи лише з коментарями +- тертя зі схемами навколо інструментів +- нечіткий зворотний зв'язок щодо дозволів +- тихі збої replay або Compaction + +Мета не в тому, щоб змусити GPT-5.5 імітувати Opus. Мета в тому, щоб дати GPT-5.5 контракт середовища виконання, який винагороджує реальний прогрес, надає чистішу семантику інструментів і дозволів та перетворює режими відмови на явні стани, читабельні і для машини, і для людини. + +Це змінює користувацький досвід із такого: + +- «модель мала хороший план, але зупинилася» + +на такий: + +- «модель або виконала дію, або OpenClaw показав точну причину, чому вона не змогла цього зробити» + +## До і після для користувачів GPT-5.5 + +| До цієї програми | Після PR A-D | +| --------------------------------------------------------------------------------------------- | ---------------------------------------------------------------------------------------- | +| GPT-5.5 міг зупинитися після розумного плану, не зробивши наступний крок з інструментом | PR A перетворює «лише план» на «дій зараз або покажи заблокований стан» | +| Суворі схеми інструментів могли незрозуміло відхиляти інструменти без параметрів або OpenAI/Codex-подібні інструменти | PR C робить реєстрацію та виклик інструментів, якими володіє провайдер, передбачуванішими | +| Вказівки щодо `/elevated full` могли бути нечіткими або неправильними в заблокованих середовищах виконання | PR B дає GPT-5.5 і користувачеві правдиві підказки про середовище виконання й дозволи | +| Збої replay або Compaction могли виглядати так, ніби завдання просто тихо зникло | PR C явно показує результати paused, blocked, abandoned і replay-invalid | +| «GPT-5.5 відчувається гірше за Opus» було переважно анекдотичним | PR D перетворює це на один і той самий набір сценаріїв, ті самі метрики й жорстку перевірку pass/fail | + +## Архітектура + +```mermaid +flowchart TD + A["User request"] --> B["Embedded Pi runtime"] + B --> C["Strict-agentic execution contract"] + B --> D["Provider-owned tool compatibility"] + B --> E["Runtime truthfulness"] + B --> F["Replay and liveness state"] + C --> G["Tool call or explicit blocked state"] + D --> G + E --> G + F --> G + G --> H["QA-lab parity pack"] + H --> I["Scenario report and parity gate"] +``` + +## Потік релізу + +```mermaid +flowchart LR + A["Merged runtime slices (PR A-C)"] --> B["Run GPT-5.5 parity pack"] + A --> C["Run Opus 4.6 parity pack"] + B --> D["qa-suite-summary.json"] + C --> E["qa-suite-summary.json"] + D --> F["openclaw qa parity-report"] + E --> F + F --> G["qa-agentic-parity-report.md"] + F --> H["qa-agentic-parity-summary.json"] + H --> I{"Gate pass?"} + I -- "yes" --> J["Evidence-backed parity claim"] + I -- "no" --> K["Keep runtime/review loop open"] +``` + +## Набір сценаріїв + +Наразі набір перевірок паритету першої хвилі охоплює п'ять сценаріїв: + +### `approval-turn-tool-followthrough` + +Перевіряє, що модель не зупиняється на «я це зроблю» після короткого підтвердження. Вона має виконати першу конкретну дію в тому самому ході. + +### `model-switch-tool-continuity` + +Перевіряє, що робота з використанням інструментів залишається узгодженою під час перемикання моделі/середовища виконання, а не скидається до коментарів чи не втрачає контекст виконання. + +### `source-docs-discovery-report` + +Перевіряє, що модель може читати вихідний код і документацію, синтезувати висновки та продовжувати завдання агентно, а не видавати поверхневе резюме й зупинятися зарано. + +### `image-understanding-attachment` + +Перевіряє, що завдання змішаного типу з вкладеннями залишаються придатними до дії й не скочуються до розпливчастого опису. + +### `compaction-retry-mutating-tool` + +Перевіряє, що завдання з реальним записом, який змінює стан, зберігає явну небезпеку replay замість того, щоб тихо виглядати replay-safe, якщо під час виконання відбуваються Compaction, повторна спроба або втрата стану відповіді під навантаженням. + +## Матриця сценаріїв + +| Сценарій | Що він перевіряє | Хороша поведінка GPT-5.5 | Сигнал збою | +| ---------------------------------- | ---------------------------------------- | ------------------------------------------------------------------------------- | -------------------------------------------------------------------------------- | +| `approval-turn-tool-followthrough` | Короткі підтвердження після плану | Одразу починає першу конкретну дію з інструментом замість повторення наміру | хід лише з планом, відсутність активності інструментів або blocked-хід без реальної причини | +| `model-switch-tool-continuity` | Перемикання середовища виконання/моделі під час використання інструментів | Зберігає контекст завдання і продовжує діяти узгоджено | скидання до коментарів, втрата контексту інструментів або зупинка після перемикання | +| `source-docs-discovery-report` | Читання джерел + синтез + дія | Знаходить джерела, використовує інструменти й створює корисний звіт без зависання | поверхневе резюме, відсутня робота інструментів або зупинка на незавершеному ході | +| `image-understanding-attachment` | Агентна робота на основі вкладення | Інтерпретує вкладення, пов'язує його з інструментами й продовжує завдання | розпливчастий опис, ігнорування вкладення або відсутність конкретної наступної дії | +| `compaction-retry-mutating-tool` | Робота зі змінами під тиском Compaction | Виконує реальний запис і зберігає явну небезпеку replay після побічного ефекту | запис, що змінює стан, відбувається, але безпека replay мається на увазі, відсутня або суперечлива | + +## Перевірка релізу + +GPT-5.5 можна вважати таким, що досяг паритету або перевищив його, лише коли об'єднане середовище виконання одночасно проходить набір перевірок паритету та регресійні перевірки правдивості середовища виконання. + +Необхідні результати: + +- жодного зависання на плані, коли наступна дія з інструментом очевидна +- жодного фальшивого завершення без реального виконання +- жодних неправильних вказівок щодо `/elevated full` +- жодного тихого покидання через replay або Compaction +- метрики набору перевірок паритету щонайменше не гірші за узгоджену базову лінію Opus 4.6 + +Для набору перевірок першої хвилі gate порівнює: + +- рівень завершення +- рівень ненавмисних зупинок +- рівень коректних викликів інструментів +- кількість fake-success + +Докази паритету навмисно розділено на два шари: + +- PR D доводить поведінку GPT-5.5 проти Opus 4.6 в однакових сценаріях за допомогою QA-lab +- детерміновані набори перевірок PR B доводять правдивість auth, proxy, DNS і `/elevated full` поза межами цього набору перевірок + +## Матриця «ціль → доказ» + +| Пункт перевірки завершення | Відповідальний PR | Джерело доказу | Сигнал проходження | +| ------------------------------------------------------- | ----------------- | ----------------------------------------------------------------- | -------------------------------------------------------------------------------------- | +| GPT-5.5 більше не зависає після планування | PR A | `approval-turn-tool-followthrough` плюс набори перевірок середовища виконання PR A | ходи підтвердження запускають реальну роботу або явний заблокований стан | +| GPT-5.5 більше не імітує прогрес чи фальшиве завершення інструмента | PR A + PR D | результати сценаріїв у звіті паритету та кількість fake-success | немає підозрілих результатів проходження й немає завершення лише з коментарями | +| GPT-5.5 більше не дає хибних вказівок щодо `/elevated full` | PR B | детерміновані набори перевірок правдивості | причини блокування та підказки щодо повного доступу залишаються точними щодо середовища виконання | +| Збої replay/життєздатності залишаються явними | PR C + PR D | набори перевірок життєвого циклу/replay PR C плюс `compaction-retry-mutating-tool` | робота зі змінами зберігає явну небезпеку replay замість того, щоб тихо зникати | +| GPT-5.5 відповідає Opus 4.6 або перевершує його за узгодженими метриками | PR D | `qa-agentic-parity-report.md` і `qa-agentic-parity-summary.json` | однакове покриття сценаріїв і відсутність регресій у завершенні, поведінці зупинки чи коректному використанні інструментів | + +## Як читати рішення про паритет + +Використовуйте рішення у `qa-agentic-parity-summary.json` як фінальне машинно-читабельне рішення для набору перевірок паритету першої хвилі. + +- `pass` означає, що GPT-5.5 охопив ті самі сценарії, що й Opus 4.6, і не показав регресії за узгодженими агрегованими метриками. +- `fail` означає, що спрацювала принаймні одна жорстка перевірка: слабше завершення, гірші ненавмисні зупинки, слабше коректне використання інструментів, будь-який випадок fake-success або невідповідне покриття сценаріїв. +- «shared/base CI issue» саме по собі не є результатом паритету. Якщо шум у CI поза межами PR D блокує запуск, рішення має чекати на чисте виконання об'єднаного середовища виконання, а не виводитися з логів епохи гілки. +- Правдивість auth, proxy, DNS і `/elevated full` як і раніше походить із детермінованих наборів перевірок PR B, тому фінальне твердження для релізу потребує обох умов: рішення про паритет PR D зі статусом проходження і зеленого покриття правдивості PR B. + +## Хто має вмикати `strict-agentic` + +Використовуйте `strict-agentic`, коли: + +- очікується, що агент діятиме негайно, якщо наступний крок очевидний +- моделі GPT-5.5 або сімейства Codex є основним середовищем виконання +- ви віддаєте перевагу явним заблокованим станам замість «корисних» відповідей лише з підсумком + +Залишайте типовий контракт, коли: + +- вам потрібна наявна, менш сувора поведінка +- ви не використовуєте моделі сімейства GPT-5 +- ви тестуєте prompt-и, а не примусове дотримання правил середовища виконання + +## Пов'язане + +- [Нотатки для супроводу паритету GPT-5.5 / Codex](/uk/help/gpt55-codex-agentic-parity-maintainers)