基准测试

通过统一的官方 QitOS benchmark 路径运行 desktop-starter、OSWorld、GAIA、Tau-Bench 与 CyBench，并产出统一结果与 trace artifacts。

在 QitOS 里，benchmark 不是另一套平行 runtime，而是同一条 agent runtime 叙事的延伸。

这意味着 benchmark execution、replay、export 与结果聚合都建立在同一组核心原语之上：

• Task
• RunSpec
• ExperimentSpec
• TraceWriter
• BenchmarkRunResult
• qita

​

支持的 benchmarks

Benchmark	领域	主指标
Desktop Starter	Computer use starter baseline	Success / failure taxonomy
OSWorld	Desktop / computer-use benchmark adapter	OSWorld evaluator score
GAIA	通用 AI assistant 任务	Exact match
Tau-Bench	Tool-agent-user 交互	Reward / pass^k
CyBench	CTF 风格安全评测	Guided subtask score

​

官方 benchmark 入口

qit bench run ...
qit bench eval ...
qit bench replay ...
qit bench export ...

examples/benchmarks/ 仍然保留，但在 v0.3 中它们已经是同一条官方结果与 trace 契约上的薄包装。

QitOS 现在也把 benchmark 工作明确拆成三层：

• framework：共享 runtime、env、harness 与 qita 能力
• benchmark：放在 qitos.benchmark.* 下的数据集 / runtime / evaluator / scorer 集成
• recipe：放在 qitos.recipes.* 下的可复现 baseline method

正是这套拆分，让 starter benchmark、真实 benchmark adapter 和可复用 baseline 能同时存在，而不会重新泄漏回 examples/。

​

这为什么重要

因为 benchmark 输出形状统一之后，你就可以：

• 跨 benchmark 比较 runs
• 无需每个 benchmark 单独写聚合脚本
• 始终使用同一套 replay / export 表面
• 用和普通 run 一样的 qita 工作流分析 benchmark 回归
• 在不改变 artifact 契约的前提下，同时保留 starter benchmark 与真实 benchmark adapter

​

benchmark run 会产出什么

一条 benchmark 路径通常会留下两层 artifact：

1. trace 目录：manifest.json、events.jsonl、steps.jsonl
2. 统一的 BenchmarkRunResult JSONL

每一行结果至少包含：

• task_id
• benchmark
• split
• prediction
• success
• stop_reason
• steps
• latency_seconds
• token_usage
• cost
• trace_run_dir
• run_spec_ref

​

示例

qit bench run \
  --benchmark tau-bench \
  --split test \
  --subset retail \
  --limit 10 \
  --output ./results/tau_retail_test.jsonl \
  --model-name "Qwen/Qwen3-8B"

然后继续聚合与检查：

qit bench eval --input ./results/tau_retail_test.jsonl --json
qita board --logdir ./runs

​

继续阅读

• Official runs
• Benchmark 与 Recipe
• 第三方 Benchmark 接入规范
• CLI 参考
• 可复现 benchmark run 教程