価値を考慮したエージェント評価（value-aware agent evaluation）とは、質問応答からタスク完遂へ：エージェントシステムとハーネス設計に関するサーベイ でなされた提案であり、エージェントの評価を、タスク成功によるスコア中心の順位付けから、タスクの価値とそれを完了するためのコスト、レイテンシ、リスク、信頼性とを結び付けた目的関数へと移行させようとするものである。このサーベイは、現在のエージェントのリーダーボードがタスク成功によってシステムを順位付けしており、API コスト、レイテンシ、安全性、トレースの品質は副次的な扱いか欠落していると指摘し、それを最先端の比較には有用だがデプロイにとっては不完全だと評している。成功のみを最大化する代わりに、サーベイはモデルとハーネスを同時に扱う最適化問題を書き下している。すなわち、タスクの効用、そのモデルとハーネスの組の成功確率、プロセス品質の要約値の積の期待値を最大化し、その際に期待コスト、レイテンシの分位点、安全性やコンプライアンス上の期待リスクにそれぞれ上限を、繰り返し実行時の信頼性に下限を課す。著者らはこれを普遍的なリーダーボードのスコアとしてではなく、デプロイの目標を明示するための、デプロイごとに固有な効用の族として提示している。
用法
サーベイは、結果をより豊かに読み解くためにカバーすべき 5 つの次元を挙げている。最終的な目的が達成されたかどうかというタスク成功、確率的な実行やリトライ、環境の変動をまたいで性能が安定しているかどうかという信頼性、トークン使用量や API・計算コストの面での効率、実時間またはやり取りの回数としてのレイテンシ、そして軌跡が検査可能で、回復可能で、証拠に裏付けられているかどうかというプロセス品質である。これらに加えて、行動が許可された範囲内にとどまり、有害な副作用を避けているかどうかという安全性を挙げている。この一連の次元を支持する論拠は、最終スコアが似ていても、ハーネスの大きな違いが隠れている場合があるというものである。あるハーネスは長い軌跡、繰り返しのリトライ、大量のコンテキストの蓄積と引き換えに高い成功率を得ている一方で、別のハーネスは成功率こそわずかに低いものの、はるかに低いコストとレイテンシで結果を出しているかもしれない。
サーベイが示す補完的な定式化が価値密度である。これは、タスクの価値に成功とプロセス品質を掛けたものを、正規化されたコスト、レイテンシ、リスクを調整可能な指数のもとで組み合わせた分母で割るもので、価値の高いタスクではより強力な検証を許容できる一方、頻度の高いワークフローではレイテンシとコストにペナルティが課される。同じ実行トレースからは、実効的な成功あたりのコストや、成功したタスクあたりのレイテンシといった、より単純な指標も報告でき、これらは成功率が似ていても実行時のプロファイルが異なるシステムを区別する。この観点から、サーベイはハーネスエンジニアリングを資源配分の問題として描いている。モデルのルーティング、コンテキストの圧縮、キャッシュの再利用、検証器の選択、回復ポリシー、早期停止は、実装上の細部ではなく、単位コストあたりの有用な進捗を決定するものだとされる。
適用される場面
これはエージェント評価をどのように行うべきかについての提案であり、確立された報告の慣行ではなく一つのサーベイが打ち出したものである。サーベイ自身もこれを今後のベンチマークの方向性として位置付けている。この提案は、実行トレースが必要なフィールド（結果、コスト、ツール呼び出し、リトライ、検証器のシグナル、回復の試み、ポリシー違反）を備えていることを前提とするが、サーベイ自身の経験では、そうでない場合が多い。Terminal-Bench の分析では、報酬、エージェントの実行時間、全体の実行時間のフィールドのカバー率は高かった一方、入力および出力トークンのフィールドは試行記録の 45.0% しかカバーしておらず、ドル建てのコストのフィールドはわずか 15.2% であった。このため、サーベイはハーネス間の比較に関する主張に金銭的コストを用いることを控えている。トレースのフィールドがまばらであったり、ハーネスごとに集計方法が異なったりする場合、この定式化は具体化できず、サーベイは成功、実行時間、タイムアウト時の挙動、そして利用可能な場合はトークン使用量に立ち戻っている。
また、これは固定された指標ではなく一つの立場として述べられている。指数や上下限はデプロイごとの選択であるため、同じシステム群にこれを適用した 2 つのチームが異なる順位付けに至ることは、設計上ありうる。形式化とは切り離して扱えるサーベイの具体的な推奨は、ベンチマークの報告に、モデルのバージョン、ハーネスの識別情報、ツールの権限、リトライとタイムアウトのポリシー、実行環境、利用可能な場合はトークンや API の使用量、そしてトレースや検証器のメタデータを含めることである。その論拠は、ベンチマークのスコアはそれを生み出した実行時の構成と併せて初めて解釈可能になる、というものである。