---
read_when:
    - Hiểu cách ngăn xếp QA phối hợp với nhau
    - Mở rộng qa-lab, qa-channel hoặc bộ điều hợp truyền tải
    - Thêm các kịch bản QA dựa trên repo
    - Xây dựng tự động hóa QA có độ chân thực cao hơn quanh bảng điều khiển Gateway
summary: 'Tổng quan về ngăn xếp QA: qa-lab, qa-channel, các kịch bản dựa trên repo, các làn truyền tải trực tiếp, bộ điều hợp truyền tải và báo cáo.'
title: Tổng quan về đảm bảo chất lượng
x-i18n:
    generated_at: "2026-05-02T20:43:38Z"
    model: gpt-5.5
    provider: openai
    source_hash: 1f1cba04d6624bb1e0fc54105bd836f16ada0ba1cc1de9ab7065b90220e23bdf
    source_path: concepts/qa-e2e-automation.md
    workflow: 16
---

Ngăn xếp QA riêng tư nhằm kiểm thử OpenClaw theo cách thực tế hơn,
mang dáng dấp kênh hơn so với một kiểm thử đơn vị đơn lẻ.

Các phần hiện tại:

- `extensions/qa-channel`: kênh tin nhắn tổng hợp với các bề mặt DM, kênh, luồng,
  phản ứng, chỉnh sửa và xóa.
- `extensions/qa-lab`: giao diện gỡ lỗi và bus QA để quan sát transcript,
  chèn tin nhắn gửi vào và xuất báo cáo Markdown.
- `extensions/qa-matrix`, các Plugin chạy trong tương lai: bộ điều hợp truyền tải trực tiếp
  điều khiển một kênh thực bên trong Gateway QA con.
- `qa/`: tài nguyên hạt giống được lưu trong repo cho tác vụ khởi động và các
  kịch bản QA cơ sở.

## Bề mặt lệnh

Mọi luồng QA chạy dưới `pnpm openclaw qa <subcommand>`. Nhiều luồng có bí danh script `pnpm qa:*`;
cả hai dạng đều được hỗ trợ.

| Lệnh                                                | Mục đích                                                                                                                                                               |
| --------------------------------------------------- | ---------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
| `qa run`                                            | Tự kiểm tra QA đi kèm; ghi báo cáo Markdown.                                                                                                                          |
| `qa suite`                                          | Chạy các kịch bản được lưu trong repo trên làn Gateway QA. Bí danh: `pnpm openclaw qa suite --runner multipass` cho một VM Linux dùng một lần.                         |
| `qa coverage`                                       | In bản kiểm kê phạm vi bao phủ kịch bản dạng markdown (`--json` cho đầu ra máy đọc).                                                                                   |
| `qa parity-report`                                  | So sánh hai tệp `qa-suite-summary.json` và ghi báo cáo tương đồng agentic.                                                                                             |
| `qa character-eval`                                 | Chạy kịch bản QA nhân vật trên nhiều mô hình trực tiếp với báo cáo được chấm. Xem [Báo cáo](#reporting).                                                              |
| `qa manual`                                         | Chạy prompt một lần trên làn nhà cung cấp/mô hình đã chọn.                                                                                                             |
| `qa ui`                                             | Khởi động giao diện gỡ lỗi QA và bus QA cục bộ (bí danh: `pnpm qa:lab:ui`).                                                                                            |
| `qa docker-build-image`                             | Xây dựng ảnh Docker QA dựng sẵn.                                                                                                                                       |
| `qa docker-scaffold`                                | Ghi scaffold docker-compose cho bảng điều khiển QA + làn Gateway.                                                                                                      |
| `qa up`                                             | Xây dựng site QA, khởi động ngăn xếp dùng Docker, in URL (bí danh: `pnpm qa:lab:up`; biến thể `:fast` thêm `--use-prebuilt-image --bind-ui-dist --skip-ui-build`).     |
| `qa aimock`                                         | Chỉ khởi động máy chủ nhà cung cấp AIMock.                                                                                                                            |
| `qa mock-openai`                                    | Chỉ khởi động máy chủ nhà cung cấp `mock-openai` nhận biết kịch bản.                                                                                                   |
| `qa credentials doctor` / `add` / `list` / `remove` | Quản lý nhóm thông tin xác thực Convex dùng chung.                                                                                                                     |
| `qa matrix`                                         | Làn truyền tải trực tiếp trên homeserver Tuwunel dùng một lần. Xem [QA Matrix](/vi/concepts/qa-matrix).                                                                  |
| `qa telegram`                                       | Làn truyền tải trực tiếp trên một nhóm Telegram riêng tư thực.                                                                                                         |
| `qa discord`                                        | Làn truyền tải trực tiếp trên một kênh guild Discord riêng tư thực.                                                                                                    |

## Luồng vận hành

Luồng vận hành QA hiện tại là một site QA hai khung:

- Trái: bảng điều khiển Gateway (Control UI) với agent.
- Phải: QA Lab, hiển thị transcript kiểu Slack và kế hoạch kịch bản.

Chạy bằng:

```bash
pnpm qa:lab:up
```

Lệnh đó xây dựng site QA, khởi động làn Gateway dùng Docker và mở trang
QA Lab, nơi người vận hành hoặc vòng lặp tự động hóa có thể giao cho agent một
nhiệm vụ QA, quan sát hành vi kênh thực và ghi lại những gì hoạt động, thất bại hoặc
vẫn bị chặn.

Để lặp nhanh hơn trên giao diện QA Lab mà không cần xây dựng lại ảnh Docker mỗi lần,
hãy khởi động ngăn xếp với gói QA Lab được mount bind:

```bash
pnpm openclaw qa docker-build-image
pnpm qa:lab:build
pnpm qa:lab:up:fast
pnpm qa:lab:watch
```

`qa:lab:up:fast` giữ các dịch vụ Docker trên một ảnh dựng sẵn và bind-mount
`extensions/qa-lab/web/dist` vào container `qa-lab`. `qa:lab:watch`
xây dựng lại gói đó khi có thay đổi, và trình duyệt tự động tải lại khi hash tài nguyên QA Lab
thay đổi.

Để chạy smoke trace OpenTelemetry cục bộ, dùng:

```bash
pnpm qa:otel:smoke
```

Script đó khởi động một bộ nhận trace OTLP/HTTP cục bộ, chạy kịch bản QA
`otel-trace-smoke` với Plugin `diagnostics-otel` được bật, rồi
giải mã các span protobuf đã xuất và xác nhận hình dạng quan trọng cho phát hành:
`openclaw.run`, `openclaw.harness.run`, `openclaw.model.call`,
`openclaw.context.assembled` và `openclaw.message.delivery` phải có mặt;
các lệnh gọi mô hình không được xuất `StreamAbandoned` trên các lượt thành công; ID chẩn đoán thô và
thuộc tính `openclaw.content.*` phải không xuất hiện trong trace. Script ghi
`otel-smoke-summary.json` cạnh các artifact của bộ QA.

QA quan sát được chỉ duy trì trên bản checkout nguồn. Tarball npm cố ý bỏ qua
QA Lab, nên các làn phát hành Docker package không chạy lệnh `qa`. Dùng
`pnpm qa:otel:smoke` từ một bản checkout nguồn đã xây dựng khi thay đổi phần đo lường chẩn đoán.

Để chạy làn smoke Matrix dùng truyền tải thực, dùng:

```bash
pnpm openclaw qa matrix --profile fast --fail-fast
```

Tài liệu tham chiếu CLI đầy đủ, danh mục hồ sơ/kịch bản, biến môi trường và bố cục artifact cho làn này nằm trong [QA Matrix](/vi/concepts/qa-matrix). Nhìn nhanh: nó cấp phát một homeserver Tuwunel dùng một lần trong Docker, đăng ký người dùng tạm thời cho driver/SUT/observer, chạy Plugin Matrix thực bên trong Gateway QA con được giới hạn vào truyền tải đó (không có `qa-channel`), rồi ghi báo cáo Markdown, tóm tắt JSON, artifact sự kiện quan sát được và log đầu ra kết hợp trong `.artifacts/qa-e2e/matrix-<timestamp>/`.

Để chạy các làn smoke Telegram và Discord dùng truyền tải thực:

```bash
pnpm openclaw qa telegram
pnpm openclaw qa discord
```

Cả hai nhắm tới một kênh thực đã tồn tại với hai bot (driver + SUT). Các biến môi trường bắt buộc, danh sách kịch bản, artifact đầu ra và nhóm thông tin xác thực Convex được ghi lại trong [Tài liệu tham chiếu QA Telegram và Discord](#telegram-and-discord-qa-reference) bên dưới.

Trước khi dùng thông tin xác thực trực tiếp trong nhóm, chạy:

```bash
pnpm openclaw qa credentials doctor
```

Doctor kiểm tra môi trường broker Convex, xác thực cài đặt endpoint và xác minh khả năng truy cập admin/list khi có secret của maintainer. Nó chỉ báo cáo trạng thái đã đặt/thiếu cho secret.

## Phạm vi bao phủ truyền tải trực tiếp

Các làn truyền tải trực tiếp dùng chung một hợp đồng thay vì mỗi làn tự phát minh hình dạng danh sách kịch bản riêng. `qa-channel` là bộ hành vi sản phẩm tổng hợp rộng và không thuộc ma trận phạm vi bao phủ truyền tải trực tiếp.

| Làn      | Canary | Cổng mention | Bot-với-bot | Chặn allowlist | Trả lời cấp cao nhất | Tiếp tục sau khởi động lại | Theo dõi luồng | Cô lập luồng | Quan sát phản ứng | Lệnh trợ giúp | Đăng ký lệnh native |
| -------- | ------ | ------------ | ----------- | -------------- | -------------------- | -------------------------- | --------------- | ------------ | ------------------ | ------------ | ------------------- |
| Matrix   | x      | x            | x           | x              | x                    | x                          | x               | x            | x                  |              |                     |
| Telegram | x      | x            | x           |                |                      |                            |                 |              |                    | x            |                     |
| Discord  | x      | x            | x           |                |                      |                            |                 |              |                    |              | x                   |

Điều này giữ `qa-channel` là bộ hành vi sản phẩm rộng, trong khi Matrix,
Telegram và các truyền tải trực tiếp trong tương lai cùng chia sẻ một danh sách kiểm tra
hợp đồng truyền tải rõ ràng.

Để chạy làn VM Linux dùng một lần mà không đưa Docker vào đường dẫn QA, chạy:

```bash
pnpm openclaw qa suite --runner multipass --scenario channel-chat-baseline
```

Lệnh này khởi động một guest Multipass mới, cài đặt phụ thuộc, xây dựng OpenClaw
bên trong guest, chạy `qa suite`, rồi sao chép báo cáo QA và
tóm tắt thông thường về `.artifacts/qa-e2e/...` trên host.
Nó tái sử dụng cùng hành vi chọn kịch bản như `qa suite` trên host.
Các lần chạy bộ trên host và Multipass thực thi nhiều kịch bản đã chọn song song
với các worker Gateway cô lập theo mặc định. `qa-channel` mặc định concurrency
4, giới hạn bởi số lượng kịch bản đã chọn. Dùng `--concurrency <count>` để tinh chỉnh
số lượng worker, hoặc `--concurrency 1` để thực thi tuần tự.
Lệnh thoát khác 0 khi có bất kỳ kịch bản nào thất bại. Dùng `--allow-failures` khi
bạn muốn có artifact mà không có mã thoát thất bại.
Các lần chạy trực tiếp chuyển tiếp những đầu vào xác thực QA được hỗ trợ và thực tế cho
guest: khóa nhà cung cấp dựa trên môi trường, đường dẫn cấu hình nhà cung cấp trực tiếp QA và
`CODEX_HOME` khi có. Giữ `--output-dir` dưới gốc repo để guest
có thể ghi ngược qua workspace đã mount.

## Tài liệu tham chiếu QA Telegram và Discord

Matrix có một [trang riêng](/vi/concepts/qa-matrix) do số lượng kịch bản và việc cấp phát homeserver dùng Docker của nó. Telegram và Discord nhỏ hơn — chỉ vài kịch bản mỗi loại, không có hệ thống hồ sơ, chạy trên các kênh thực đã tồn tại — nên tài liệu tham chiếu của chúng nằm ở đây.

### Cờ CLI dùng chung

Cả hai làn đăng ký qua `extensions/qa-lab/src/live-transports/shared/live-transport-cli.ts` và chấp nhận cùng các cờ:

| Cờ                                    | Mặc định                                                 | Mô tả                                                                                                               |
| ------------------------------------- | --------------------------------------------------------- | ------------------------------------------------------------------------------------------------------------------- |
| `--scenario <id>`                     | —                                                         | Chỉ chạy kịch bản này. Có thể lặp lại.                                                                              |
| `--output-dir <path>`                 | `<repo>/.artifacts/qa-e2e/{telegram,discord}-<timestamp>` | Nơi ghi báo cáo/tóm tắt/thông báo đã quan sát và nhật ký đầu ra. Đường dẫn tương đối được phân giải theo `--repo-root`. |
| `--repo-root <path>`                  | `process.cwd()`                                           | Thư mục gốc kho mã khi gọi từ một cwd trung lập.                                                                    |
| `--sut-account <id>`                  | `sut`                                                     | Id tài khoản tạm thời bên trong cấu hình Gateway QA.                                                                |
| `--provider-mode <mode>`              | `live-frontier`                                           | `mock-openai` hoặc `live-frontier` (`live-openai` cũ vẫn hoạt động).                                                |
| `--model <ref>` / `--alt-model <ref>` | mặc định của nhà cung cấp                                 | Ref mô hình chính/thay thế.                                                                                         |
| `--fast`                              | tắt                                                       | Chế độ nhanh của nhà cung cấp khi được hỗ trợ.                                                                      |
| `--credential-source <env\|convex>`   | `env`                                                     | Xem [nhóm thông tin xác thực Convex](#convex-credential-pool).                                                      |
| `--credential-role <maintainer\|ci>`  | `ci` trong CI, ngược lại là `maintainer`                  | Vai trò được dùng khi `--credential-source convex`.                                                                 |

Cả hai đều thoát khác 0 khi có bất kỳ kịch bản nào thất bại. `--allow-failures` ghi artifact mà không đặt mã thoát thất bại.

### QA Telegram

```bash
pnpm openclaw qa telegram
```

Nhắm tới một nhóm Telegram riêng tư thật với hai bot riêng biệt (driver + SUT). Bot SUT phải có tên người dùng Telegram; quan sát bot-với-bot hoạt động tốt nhất khi cả hai bot đều bật **Chế độ giao tiếp bot-với-bot** trong `@BotFather`.

Env bắt buộc khi `--credential-source env`:

- `OPENCLAW_QA_TELEGRAM_GROUP_ID` — id chat dạng số (chuỗi).
- `OPENCLAW_QA_TELEGRAM_DRIVER_BOT_TOKEN`
- `OPENCLAW_QA_TELEGRAM_SUT_BOT_TOKEN`

Tùy chọn:

- `OPENCLAW_QA_TELEGRAM_CAPTURE_CONTENT=1` giữ nội dung thông báo trong artifact thông báo đã quan sát (mặc định che lại).

Kịch bản (`extensions/qa-lab/src/live-transports/telegram/telegram-live.runtime.ts:44`):

- `telegram-canary`
- `telegram-mention-gating`
- `telegram-mentioned-message-reply`
- `telegram-help-command`
- `telegram-commands-command`
- `telegram-tools-compact-command`
- `telegram-whoami-command`
- `telegram-context-command`

Artifact đầu ra:

- `telegram-qa-report.md`
- `telegram-qa-summary.json` — bao gồm RTT theo từng phản hồi (driver gửi → quan sát phản hồi SUT), bắt đầu bằng canary.
- `telegram-qa-observed-messages.json` — nội dung bị che trừ khi `OPENCLAW_QA_TELEGRAM_CAPTURE_CONTENT=1`.

### QA Discord

```bash
pnpm openclaw qa discord
```

Nhắm tới một kênh guild Discord riêng tư thật với hai bot: một bot driver do harness điều khiển và một bot SUT được Gateway OpenClaw con khởi động thông qua Plugin Discord được đóng gói. Xác minh xử lý đề cập kênh và việc bot SUT đã đăng ký lệnh gốc `/help` với Discord.

Env bắt buộc khi `--credential-source env`:

- `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` — phải khớp với id người dùng bot SUT do Discord trả về (nếu không lane sẽ thất bại nhanh).

Tùy chọn:

- `OPENCLAW_QA_DISCORD_CAPTURE_CONTENT=1` giữ nội dung thông báo trong artifact thông báo đã quan sát.

Kịch bản (`extensions/qa-lab/src/live-transports/discord/discord-live.runtime.ts:36`):

- `discord-canary`
- `discord-mention-gating`
- `discord-native-help-command-registration`

Artifact đầu ra:

- `discord-qa-report.md`
- `discord-qa-summary.json`
- `discord-qa-observed-messages.json` — nội dung bị che trừ khi `OPENCLAW_QA_DISCORD_CAPTURE_CONTENT=1`.

### Nhóm thông tin xác thực Convex

Cả hai lane Telegram và Discord đều có thể thuê thông tin xác thực từ một nhóm Convex dùng chung thay vì đọc các biến env ở trên. Truyền `--credential-source convex` (hoặc đặt `OPENCLAW_QA_CREDENTIAL_SOURCE=convex`); QA Lab lấy một lease độc quyền, gửi Heartbeat cho lease đó trong suốt thời gian chạy, và giải phóng khi tắt. Các loại nhóm là `"telegram"` và `"discord"`.

Dạng payload mà broker xác thực trên `admin/add`:

- Telegram (`kind: "telegram"`): `{ groupId: string, driverToken: string, sutToken: string }` — `groupId` phải là chuỗi chat-id dạng số.
- Discord (`kind: "discord"`): `{ guildId: string, channelId: string, driverBotToken: string, sutBotToken: string, sutApplicationId: string }`.

Các biến env vận hành và hợp đồng điểm cuối broker Convex nằm trong [Kiểm thử → Thông tin xác thực Telegram dùng chung qua Convex](/vi/help/testing#shared-telegram-credentials-via-convex-v1) (tên mục có trước hỗ trợ Discord; ngữ nghĩa broker giống hệt nhau cho cả hai loại).

## Seed dựa trên kho mã

Asset seed nằm trong `qa/`:

- `qa/scenarios/index.md`
- `qa/scenarios/<theme>/*.md`

Các asset này được chủ ý đưa vào git để kế hoạch QA hiển thị với cả con người và agent.

`qa-lab` nên tiếp tục là một runner markdown chung. Mỗi tệp markdown kịch bản là nguồn sự thật cho một lần chạy kiểm thử và nên định nghĩa:

- siêu dữ liệu kịch bản
- siêu dữ liệu danh mục, năng lực, lane và rủi ro tùy chọn
- ref tài liệu và mã
- yêu cầu Plugin tùy chọn
- bản vá cấu hình Gateway tùy chọn
- `qa-flow` có thể thực thi

Bề mặt runtime tái sử dụng hỗ trợ `qa-flow` được phép tiếp tục chung và xuyên suốt. Ví dụ, các kịch bản markdown có thể kết hợp helper phía transport với helper phía trình duyệt điều khiển Control UI nhúng thông qua seam `browser.request` của Gateway mà không thêm runner trường hợp đặc biệt.

Các tệp kịch bản nên được nhóm theo năng lực sản phẩm thay vì thư mục cây nguồn. Giữ ổn định ID kịch bản khi di chuyển tệp; dùng `docsRefs` và `codeRefs` để truy vết triển khai.

Danh sách baseline nên đủ rộng để bao phủ:

- DM và chat kênh
- hành vi thread
- vòng đời thao tác thông báo
- callback Cron
- truy hồi bộ nhớ
- chuyển đổi mô hình
- bàn giao subagent
- đọc kho mã và đọc tài liệu
- một tác vụ build nhỏ như Lobster Invaders

## Lane mock nhà cung cấp

`qa suite` có hai lane mock nhà cung cấp cục bộ:

- `mock-openai` là mock OpenClaw nhận biết kịch bản. Nó vẫn là lane mock xác định mặc định cho QA dựa trên kho mã và các cổng parity.
- `aimock` khởi động một máy chủ nhà cung cấp dựa trên AIMock cho phạm vi phủ thử nghiệm giao thức, fixture, ghi/phát lại và chaos. Nó là phần bổ sung và không thay thế bộ điều phối kịch bản `mock-openai`.

Triển khai lane nhà cung cấp nằm dưới `extensions/qa-lab/src/providers/`. Mỗi nhà cung cấp sở hữu mặc định của mình, khởi động máy chủ cục bộ, cấu hình mô hình Gateway, nhu cầu dàn dựng auth-profile và cờ năng lực live/mock. Mã suite và Gateway dùng chung nên định tuyến qua registry nhà cung cấp thay vì rẽ nhánh theo tên nhà cung cấp.

## Adapter transport

`qa-lab` sở hữu một seam transport chung cho các kịch bản QA markdown. `qa-channel` là adapter đầu tiên trên seam đó, nhưng mục tiêu thiết kế rộng hơn: các kênh thật hoặc tổng hợp trong tương lai nên cắm vào cùng runner suite thay vì thêm runner QA riêng theo transport.

Ở cấp kiến trúc, phần tách là:

- `qa-lab` sở hữu thực thi kịch bản chung, đồng thời worker, ghi artifact và báo cáo.
- Adapter transport sở hữu cấu hình Gateway, trạng thái sẵn sàng, quan sát inbound và outbound, thao tác transport và trạng thái transport đã chuẩn hóa.
- Các tệp kịch bản markdown dưới `qa/scenarios/` định nghĩa lần chạy kiểm thử; `qa-lab` cung cấp bề mặt runtime tái sử dụng để thực thi chúng.

### Thêm một kênh

Thêm một kênh vào hệ thống QA markdown yêu cầu đúng hai thứ:

1. Một adapter transport cho kênh.
2. Một gói kịch bản kiểm tra hợp đồng kênh.

Không thêm root lệnh QA cấp cao mới khi host `qa-lab` dùng chung có thể sở hữu luồng.

`qa-lab` sở hữu cơ chế host dùng chung:

- root lệnh `openclaw qa`
- khởi động và tháo dỡ suite
- đồng thời worker
- ghi artifact
- tạo báo cáo
- thực thi kịch bản
- alias tương thích cho các kịch bản `qa-channel` cũ hơn

Các Plugin runner sở hữu hợp đồng transport:

- cách `openclaw qa <runner>` được gắn bên dưới root `qa` dùng chung
- cách Gateway được cấu hình cho transport đó
- cách kiểm tra trạng thái sẵn sàng
- cách tiêm sự kiện inbound
- cách quan sát thông báo outbound
- cách transcript và trạng thái transport đã chuẩn hóa được phơi bày
- cách thực thi thao tác dựa trên transport
- cách xử lý reset hoặc dọn dẹp riêng theo transport

Ngưỡng chấp nhận tối thiểu cho một kênh mới:

1. Giữ `qa-lab` làm chủ sở hữu root `qa` dùng chung.
2. Triển khai runner transport trên seam host `qa-lab` dùng chung.
3. Giữ cơ chế riêng theo transport bên trong Plugin runner hoặc harness kênh.
4. Gắn runner dưới dạng `openclaw qa <runner>` thay vì đăng ký một root command cạnh tranh. Các Plugin runner nên khai báo `qaRunners` trong `openclaw.plugin.json` và export một mảng `qaRunnerCliRegistrations` khớp từ `runtime-api.ts`. Giữ `runtime-api.ts` nhẹ; CLI lazy và thực thi runner nên ở sau các entrypoint riêng.
5. Viết mới hoặc điều chỉnh các kịch bản markdown dưới các thư mục `qa/scenarios/` theo chủ đề.
6. Dùng helper kịch bản chung cho kịch bản mới.
7. Giữ các alias tương thích hiện có hoạt động trừ khi kho mã đang thực hiện một lần migration có chủ ý.

Quy tắc quyết định là nghiêm ngặt:

- Nếu hành vi có thể được biểu đạt một lần trong `qa-lab`, đặt nó trong `qa-lab`.
- Nếu hành vi phụ thuộc vào một transport kênh, giữ nó trong Plugin runner hoặc harness Plugin đó.
- Nếu một kịch bản cần một năng lực mới mà nhiều hơn một kênh có thể dùng, thêm một helper chung thay vì một nhánh riêng theo kênh trong `suite.ts`.
- Nếu một hành vi chỉ có ý nghĩa với một transport, giữ kịch bản riêng theo transport và làm rõ điều đó trong hợp đồng kịch bản.

### Tên helper kịch bản

Các helper chung ưu tiên cho kịch bản mới:

- `waitForTransportReady`
- `waitForChannelReady`
- `injectInboundMessage`
- `injectOutboundMessage`
- `waitForTransportOutboundMessage`
- `waitForChannelOutboundMessage`
- `waitForNoTransportOutbound`
- `getTransportSnapshot`
- `readTransportMessage`
- `readTransportTranscript`
- `formatTransportTranscript`
- `resetTransport`

Các alias tương thích vẫn có sẵn cho kịch bản hiện có — `waitForQaChannelReady`, `waitForOutboundMessage`, `waitForNoOutbound`, `formatConversationTranscript`, `resetBus` — nhưng tác giả kịch bản mới nên dùng các tên chung. Các alias tồn tại để tránh một lần migration đồng loạt, không phải làm mô hình trong tương lai.

## Báo cáo

`qa-lab` export một báo cáo giao thức Markdown từ timeline bus đã quan sát.
Báo cáo nên trả lời:

- Điều gì hoạt động
- Điều gì thất bại
- Điều gì vẫn bị chặn
- Những kịch bản tiếp theo nào đáng thêm

Để xem danh mục các kịch bản có sẵn — hữu ích khi ước lượng công việc tiếp theo hoặc nối một transport mới — hãy chạy `pnpm openclaw qa coverage` (thêm `--json` để có đầu ra máy có thể đọc).

Để kiểm tra nhân vật và phong cách, hãy chạy cùng một kịch bản trên nhiều tham chiếu mô hình live
và ghi một báo cáo Markdown đã được đánh giá:

```bash
pnpm openclaw qa character-eval \
  --model openai/gpt-5.5,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.5,thinking=xhigh,fast \
  --judge-model anthropic/claude-opus-4-6,thinking=high \
  --blind-judge-models \
  --concurrency 16 \
  --judge-concurrency 16
```

Lệnh này chạy các tiến trình con Gateway QA cục bộ, không phải Docker. Các kịch bản đánh giá nhân vật
nên đặt persona thông qua `SOUL.md`, rồi chạy các lượt người dùng thông thường
như chat, hỗ trợ workspace và các tác vụ tệp nhỏ. Không nên cho mô hình ứng viên
biết rằng nó đang được đánh giá. Lệnh giữ lại từng transcript đầy đủ,
ghi lại thống kê chạy cơ bản, rồi yêu cầu các mô hình giám khảo ở chế độ nhanh với
lập luận `xhigh` khi được hỗ trợ để xếp hạng các lượt chạy theo độ tự nhiên, sắc thái và tính hài hước.
Dùng `--blind-judge-models` khi so sánh các nhà cung cấp: prompt của giám khảo vẫn nhận
mọi transcript và trạng thái chạy, nhưng các tham chiếu ứng viên được thay bằng nhãn trung lập
như `candidate-01`; báo cáo ánh xạ thứ hạng trở lại tham chiếu thật sau khi
phân tích cú pháp.
Các lượt chạy ứng viên mặc định dùng thinking `high`, với `medium` cho GPT-5.5 và `xhigh`
cho các tham chiếu đánh giá OpenAI cũ hơn có hỗ trợ. Ghi đè một ứng viên cụ thể trực tiếp bằng
`--model provider/model,thinking=<level>`. `--thinking <level>` vẫn đặt một
giá trị dự phòng toàn cục, và dạng cũ hơn `--model-thinking <provider/model=level>` được
giữ lại để tương thích.
Các tham chiếu ứng viên OpenAI mặc định dùng chế độ nhanh để sử dụng xử lý ưu tiên ở những nơi
nhà cung cấp hỗ trợ. Thêm `,fast`, `,no-fast`, hoặc `,fast=false` trực tiếp khi một
ứng viên hoặc giám khảo riêng lẻ cần ghi đè. Chỉ truyền `--fast` khi bạn muốn
buộc bật chế độ nhanh cho mọi mô hình ứng viên. Thời lượng của ứng viên và giám khảo được
ghi trong báo cáo để phân tích benchmark, nhưng prompt của giám khảo nêu rõ
không xếp hạng theo tốc độ.
Các lượt chạy mô hình ứng viên và giám khảo đều mặc định dùng concurrency 16. Giảm
`--concurrency` hoặc `--judge-concurrency` khi giới hạn của nhà cung cấp hoặc áp lực Gateway
cục bộ làm lượt chạy quá nhiễu.
Khi không truyền ứng viên `--model`, đánh giá nhân vật mặc định dùng
`openai/gpt-5.5`, `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`, và
`google/gemini-3.1-pro-preview` khi không truyền `--model`.
Khi không truyền `--judge-model`, các giám khảo mặc định là
`openai/gpt-5.5,thinking=xhigh,fast` và
`anthropic/claude-opus-4-6,thinking=high`.

## Tài liệu liên quan

- [QA ma trận](/vi/concepts/qa-matrix)
- [Kênh QA](/vi/channels/qa-channel)
- [Kiểm thử](/vi/help/testing)
- [Bảng điều khiển](/vi/web/dashboard)
