PawBench による 4,050 件のエージェント評価

Alibaba Cloud Community は、AgentScope チームの PawBench を紹介しました。9モデル、3つのエージェント実行基盤、150タスクの組み合わせで 4,050 件を評価し、モデル性能だけでは説明できないエージェント実行の差を見ようとする内容です。

要点

• PawBench は、モデル単体ではなく「LLM x harness」の組み合わせでエージェント性能を評価します。
• 150 の実世界タスク、9 つの基盤モデル、Hermes、OpenClaw、QwenPaw の 3 harness を組み合わせています。
• Docker サンドボックス、タスク分類、ルール評価、LLM-as-judge を使い、失敗原因をモデルと実行基盤の両面から見ます。

今回のブログ記事で語られていること

この記事は、AIエージェントの評価をモデルベンチマークだけで済ませられない理由を説明しています。実運用のエージェントは、モデルが直接タスクを解くのではなく、ブラウザ操作、ファイル操作、コード実行、ツール呼び出し、状態管理、ログ、再試行、サンドボックスなどを含む harness の上で動きます。モデルには十分な能力があっても、harness が観測、実行、復旧、評価をうまく支えられなければタスクは失敗します。逆に、同じモデルでも harness が違うだけで結果が変わる可能性があります。

PawBench は、この分離できない関係を正面から扱うためのベンチマークとして紹介されています。150 の実世界タスクを、9つの基盤モデルと 3つの production-grade harness、Hermes、OpenClaw、QwenPaw のすべての組み合わせで実行し、合計 4,050 のテストセルを作ります。タスクは用途シナリオ、基本能力、複雑さ、入力形式、実行環境のような軸でタグ付けされ、Docker サンドボックス内で実行されます。最終スコアはルールやサブアサーションによる自動評価と、意味的な出力を扱う LLM-as-judge を組み合わせる構成です。

実務での読みどころは、エージェント評価を「どのモデルが強いか」だけにしない点です。社内でエージェントを導入する場合、モデル選定、ツール設計、実行環境、権限、失敗時の観測性、評価データがひとつのシステムとして機能します。PawBench のような考え方は、モデルを替えれば解決するのか、harness やプロンプト、ツール接続、サンドボックス設計を直す必要があるのかを切り分ける助けになります。Qwen や Model Studio 周辺でエージェント実行基盤を評価するチームにとって、評価の粒度を上げるための参考になります。

今回のブログ記事が関係する人

AIエージェントを評価するMLエンジニア、エージェント実行基盤を作る開発チーム、Qwen/Model Studio を使った業務エージェントの品質を測りたいプラットフォーム担当に関係します。

実務で確認したいポイント

• モデルごとのスコアだけでなく、harness、ツール、実行環境ごとの失敗傾向を分けて記録する。
• 評価タスクを、実際の業務に近い複数ステップの操作、ファイル、ブラウザ、コード実行を含む形にする。
• LLM-as-judge を使う場合、ルール評価やサブアサーションと組み合わせ、評価の再現性を確認する。

結局、今回のブログ記事をどう読むべきか

PawBench は、エージェントの成否をモデルだけに帰さないための評価枠組みです。エージェント導入では、モデル選定と同じ重さで harness と観測性を検証したいです。