chore(i18n): refresh uk translations
This commit is contained in:
openclaw-docs-i18n[bot]
parent
84778f5e42
commit
034664fcdc
@ -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.<id>.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.<channel>.responsePrefix` і `channels.<channel>.accounts.<id>.responsePrefix` (каскад префіксів вихідних повідомлень), а також `channels.whatsapp.messagePrefix` (префікс вхідних повідомлень WhatsApp)
|
||||
- Трединг відповідей через `replyToMode` і типові значення для кожного каналу
|
||||
- `messages.responsePrefix`, `channels.<channel>.responsePrefix` і `channels.<channel>.accounts.<id>.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.<id>.silentReply` і
|
||||
`surfaces.<id>.silentReplyRewrite` можуть перевизначати їх для кожної surface.
|
||||
`surfaces.<id>.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) — інтеграції платформ обміну повідомленнями
|
||||
|
||||
@ -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)
|
||||
@ -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)
|
||||
203
docs/uk/help/gpt55-codex-agentic-parity-maintainers.md
Normal file
203
docs/uk/help/gpt55-codex-agentic-parity-maintainers.md
Normal file
@ -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)
|
||||
239
docs/uk/help/gpt55-codex-agentic-parity.md
Normal file
239
docs/uk/help/gpt55-codex-agentic-parity.md
Normal file
@ -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)
|
||||
Loading…
Reference in New Issue
Block a user