Перейти до основного вмісту
Приватний стек QA призначений для перевірки OpenClaw у більш реалістичний, орієнтований на канали спосіб, ніж це може один unit-тест. Поточні складові:
  • extensions/qa-channel: синтетичний канал повідомлень із поверхнями DM, каналу, треду, реакцій, редагування та видалення.
  • extensions/qa-lab: UI налагодження та шина QA для спостереження за транскриптом, інʼєкції вхідних повідомлень та експорту Markdown-звіту.
  • qa/: ресурси початкових даних на основі репозиторію для стартового завдання та базових QA- сценаріїв.
Поточний робочий процес QA-оператора — це двопанельний QA-сайт:
  • Ліворуч: панель Gateway (Control UI) з агентом.
  • Праворуч: QA Lab, що показує транскрипт у стилі Slack і план сценарію.
Запустіть його командою: 
pnpm qa:lab:up
Це збирає QA-сайт, запускає lane Gateway на основі Docker і відкриває сторінку QA Lab, де оператор або цикл автоматизації може дати агенту QA- місію, спостерігати реальну поведінку каналу та фіксувати, що спрацювало, що не спрацювало або що залишилося заблокованим. Для швидшої ітерації UI QA Lab без перебудови Docker-образу щоразу запустіть стек із bind-mounted збіркою QA Lab: 
pnpm openclaw qa docker-build-image
pnpm qa:lab:build
pnpm qa:lab:up:fast
pnpm qa:lab:watch
qa:lab:up:fast утримує Docker-сервіси на попередньо зібраному образі та bind-mount’ить extensions/qa-lab/web/dist у контейнер qa-lab. qa:lab:watch перебудовує цей bundle при змінах, а браузер автоматично перезавантажується, коли змінюється хеш ресурсу QA Lab. Для smoke lane Matrix із реальним транспортом виконайте: 
pnpm openclaw qa matrix
Цей lane розгортає тимчасовий homeserver Tuwunel у Docker, реєструє тимчасових користувачів driver, SUT і observer, створює одну приватну кімнату, а потім запускає реальний Plugin Matrix усередині дочірнього QA gateway. Lane із живим транспортом зберігає конфігурацію дочірнього процесу обмеженою транспортом, що тестується, тому Matrix працює без qa-channel у дочірній конфігурації. Він записує структуровані артефакти звіту та обʼєднаний лог stdout/stderr у вибраний вихідний каталог Matrix QA. Щоб також захопити зовнішній вивід збірки/запускача scripts/run-node.mjs, установіть OPENCLAW_RUN_NODE_OUTPUT_LOG=<path> на локальний щодо репозиторію файл логу. Для smoke lane Telegram із реальним транспортом виконайте: 
pnpm openclaw qa telegram
Цей lane націлюється на одну реальну приватну групу Telegram замість розгортання тимчасового сервера. Для нього потрібні OPENCLAW_QA_TELEGRAM_GROUP_ID, OPENCLAW_QA_TELEGRAM_DRIVER_BOT_TOKEN і OPENCLAW_QA_TELEGRAM_SUT_BOT_TOKEN, а також два різні боти в одній приватній групі. Бот SUT повинен мати імʼя користувача Telegram, а спостереження bot-to-bot працює найкраще, коли для обох ботів увімкнено режим Bot-to-Bot Communication Mode в @BotFather. Команда завершується ненульовим кодом, якщо будь-який сценарій не пройшов. Використовуйте --allow-failures, якщо вам потрібні артефакти без коду завершення з помилкою. Звіт і підсумок Telegram включають RTT для кожної відповіді — від запиту надсилання повідомлення driver до спостережуваної відповіді SUT, починаючи з canary. Для smoke lane Discord із реальним транспортом виконайте: 
pnpm openclaw qa discord
Цей lane націлюється на один реальний приватний канал guild Discord із двома ботами: ботом driver, яким керує harness, і ботом SUT, який запускається дочірнім Gateway OpenClaw через вбудований Plugin Discord. Для нього потрібні OPENCLAW_QA_DISCORD_GUILD_ID, OPENCLAW_QA_DISCORD_CHANNEL_ID, OPENCLAW_QA_DISCORD_DRIVER_BOT_TOKEN, OPENCLAW_QA_DISCORD_SUT_BOT_TOKEN і OPENCLAW_QA_DISCORD_SUT_APPLICATION_ID у разі використання облікових даних env. Lane перевіряє обробку згадок у каналі та перевіряє, що бот SUT зареєстрував нативну команду /help у Discord. Команда завершується ненульовим кодом, якщо будь-який сценарій не пройшов. Використовуйте --allow-failures, якщо вам потрібні артефакти без коду завершення з помилкою. Тепер lane із живим транспортом використовують один менший контракт замість того, щоб кожен вигадував власну форму списку сценаріїв: qa-channel залишається широким синтетичним набором перевірок поведінки продукту і не входить до матриці покриття live transport.
LaneCanaryГейтінг згадокБлокування allowlistВідповідь верхнього рівняВідновлення після перезапускуПодальше повідомлення в тредіІзоляція тредівСпостереження за реакціямиКоманда helpРеєстрація нативної команди
Matrixxxxxxxxx
Telegramxxx
Discordxxx
Це зберігає qa-channel як широкий набір перевірок поведінки продукту, тоді як Matrix, Telegram і майбутні живі транспорти спільно використовують один явний контрольний список транспортного контракту. Для lane з тимчасовою Linux VM без використання Docker у QA-шляху виконайте: 
pnpm openclaw qa suite --runner multipass --scenario channel-chat-baseline
Це завантажує нову гостьову машину Multipass, установлює залежності, збирає OpenClaw усередині гостьової машини, запускає qa suite, а потім копіює звичайний QA-звіт і підсумок назад у .artifacts/qa-e2e/... на хості. Він повторно використовує ту саму поведінку вибору сценаріїв, що й qa suite на хості. Запуски suite на хості та в Multipass за замовчуванням виконують кілька вибраних сценаріїв паралельно з ізольованими worker Gateway. Для qa-channel типове значення concurrency — 4, обмежене кількістю вибраних сценаріїв. Використовуйте --concurrency <count>, щоб налаштувати кількість worker, або --concurrency 1 для послідовного виконання. Команда завершується ненульовим кодом, якщо будь-який сценарій не пройшов. Використовуйте --allow-failures, якщо вам потрібні артефакти без коду завершення з помилкою. Живі запуски передають підтримувані вхідні дані автентифікації QA, які практичні для гостьової машини: ключі провайдерів на основі env, шлях до конфігурації live provider QA і CODEX_HOME, якщо він присутній. Тримайте --output-dir у межах кореня репозиторію, щоб гість міг записувати назад через змонтований workspace.

​
Початкові дані на основі репозиторію

Ресурси початкових даних знаходяться в qa/:
  • qa/scenarios/index.md
  • qa/scenarios/<theme>/*.md
Вони навмисно зберігаються в git, щоб QA-план був видимий і людям, і агенту. qa-lab має залишатися загальним runner для markdown. Кожен markdown-файл сценарію є джерелом істини для одного тестового запуску й має визначати:
  • метадані сценарію
  • необовʼязкові метадані category, capability, lane і risk
  • посилання на docs і код
  • необовʼязкові вимоги до Plugin
  • необовʼязковий patch конфігурації gateway
  • виконуваний qa-flow
Поверхня повторно використовуваного runtime, що підтримує qa-flow, може залишатися загальною і наскрізною. Наприклад, markdown-сценарії можуть поєднувати transport-side допоміжні засоби з browser-side допоміжними засобами, які керують вбудованим Control UI через seam Gateway browser.request, не додаючи спеціалізований runner. Файли сценаріїв слід групувати за можливостями продукту, а не за папкою вихідного дерева. Зберігайте стабільність ID сценаріїв під час переміщення файлів; використовуйте docsRefs і codeRefs для трасованості реалізації. Базовий список має залишатися достатньо широким, щоб охоплювати:
  • чат у DM і каналі
  • поведінку тредів
  • життєвий цикл дій із повідомленнями
  • Cron callbacks
  • виклик памʼяті
  • перемикання моделей
  • передачу підзадачі субагенту
  • читання репозиторію та документації
  • одне невелике завдання на збірку, наприклад Lobster Invaders

​
Mock lanes провайдерів

qa suite має два локальні mock lanes провайдерів:
  • mock-openai — це обізнаний про сценарії mock OpenClaw. Він залишається типовим детермінованим mock lane для QA на основі репозиторію та перевірок паритету.
  • aimock запускає сервер провайдера на основі AIMock для експериментального покриття протоколу, фікстур, record/replay і chaos. Він є доповненням і не замінює dispatcher сценаріїв mock-openai.
Реалізація lane провайдерів знаходиться в extensions/qa-lab/src/providers/. Кожен провайдер володіє своїми значеннями за замовчуванням, запуском локального сервера, конфігурацією моделі gateway, потребами staging auth-profile і прапорцями live/mock capability. Спільний код suite і gateway має маршрутизувати через registry провайдерів замість розгалуження за іменами провайдерів.

​
Адаптери транспорту

qa-lab володіє загальним seam транспорту для markdown QA-сценаріїв. qa-channel — перший адаптер на цьому seam, але ціль дизайну ширша: майбутні реальні або синтетичні канали мають підключатися до того самого runner suite замість додавання transport-specific QA runner. На рівні архітектури поділ такий:
  • qa-lab відповідає за загальне виконання сценаріїв, concurrency worker, запис артефактів і звітність.
  • адаптер транспорту відповідає за конфігурацію gateway, готовність, спостереження за вхідними та вихідними даними, транспортні дії та нормалізований стан транспорту.
  • markdown-файли сценаріїв у qa/scenarios/ визначають тестовий запуск; qa-lab надає повторно використовувану поверхню runtime, яка їх виконує.
Настанови з упровадження для нових адаптерів каналів, орієнтовані на мейнтейнерів, розміщені в Тестування.

​
Звітність

qa-lab експортує Markdown-звіт протоколу зі спостережуваної часової шкали шини. Звіт має відповідати на такі запитання:
  • Що спрацювало
  • Що не спрацювало
  • Що залишилося заблокованим
  • Які подальші сценарії варто додати
Для перевірок характеру та стилю запустіть той самий сценарій на кількох live model refs і запишіть Markdown-звіт з оцінюванням: 
pnpm openclaw qa character-eval \
  --model openai/gpt-5.4,thinking=medium,fast \
  --model openai/gpt-5.2,thinking=xhigh \
  --model openai/gpt-5,thinking=xhigh \
  --model anthropic/claude-opus-4-6,thinking=high \
  --model anthropic/claude-sonnet-4-6,thinking=high \
  --model zai/glm-5.1,thinking=high \
  --model moonshot/kimi-k2.5,thinking=high \
  --model google/gemini-3.1-pro-preview,thinking=high \
  --judge-model openai/gpt-5.4,thinking=xhigh,fast \
  --judge-model anthropic/claude-opus-4-6,thinking=high \
  --blind-judge-models \
  --concurrency 16 \
  --judge-concurrency 16
Команда запускає локальні дочірні процеси QA gateway, а не Docker. Сценарії character eval мають задавати persona через SOUL.md, а потім виконувати звичайні ходи користувача, такі як чат, допомога з workspace і невеликі файлові завдання. Моделі-кандидату не слід повідомляти, що її оцінюють. Команда зберігає кожен повний транскрипт, записує базову статистику запуску, а потім просить моделі-судді в fast mode з xhigh reasoning, де це підтримується, ранжувати запуски за природністю, вайбом і гумором. Використовуйте --blind-judge-models при порівнянні провайдерів: промпт судді все одно отримує кожен транскрипт і статус запуску, але посилання кандидатів замінюються нейтральними мітками на кшталт candidate-01; після парсингу звіт зіставляє ранжування назад із реальними ref. Для запусків кандидатів за замовчуванням використовується thinking рівня high, із medium для GPT-5.4 та xhigh для старіших OpenAI eval ref, які це підтримують. Перевизначте конкретного кандидата прямо в рядку через --model provider/model,thinking=<level>. --thinking <level> як і раніше задає глобальне резервне значення, а старіша форма --model-thinking <provider/model=level> збережена для сумісності. OpenAI candidate ref за замовчуванням використовують fast mode, щоб застосовувалася пріоритетна обробка там, де провайдер це підтримує. Додайте ,fast, ,no-fast або ,fast=false прямо в рядку, коли одному кандидату або судді потрібне перевизначення. Передавайте --fast лише тоді, коли хочете примусово ввімкнути fast mode для кожної моделі-кандидата. Тривалість роботи кандидатів і суддів записується у звіт для аналізу бенчмарків, але в промптах для суддів явно сказано не ранжувати за швидкістю. Для запусків моделей-кандидатів і моделей-суддів за замовчуванням використовується concurrency 16. Зменшуйте --concurrency або --judge-concurrency, коли ліміти провайдера або навантаження на локальний gateway роблять запуск надто шумним. Якщо не передано жодного кандидата через --model, для character eval за замовчуванням використовуються openai/gpt-5.4, openai/gpt-5.2, openai/gpt-5, anthropic/claude-opus-4-6, anthropic/claude-sonnet-4-6, zai/glm-5.1, moonshot/kimi-k2.5 і google/gemini-3.1-pro-preview, якщо не передано --model. Якщо не передано --judge-model, за замовчуванням використовуються судді openai/gpt-5.4,thinking=xhigh,fast і anthropic/claude-opus-4-6,thinking=high.

​
Повʼязана документація