Evaluation Entry Point AgentEvaluator
AgentEvaluator is the evaluation entry for users. It organizes an evaluation run by evalSetID, reads evaluation sets and metrics, drives the evaluation service for inference and scoring, aggregates multi-run results, and persists outputs.
Interface Definition
The AgentEvaluator interface is defined as follows.
Structure Definition
The structures of EvaluationResult and EvaluationCaseResult are defined as follows.
EvalResult contains the aggregated EvalSetResult that can be persisted by EvalResultManager. The set-level InferenceStats is returned on EvaluationResult; persisted EvalSetResult values retain case/run statistics, so no database schema change is required. RunDetails is filled only when run details are enabled, and each item is associated with a specific run ID.
InferenceStats follows the same aggregation levels: EvaluationInferenceDetails contains one run's statistics, EvaluationCaseResult sums statistics across runs for one case, and EvaluationResult sums statistics across cases. It reports usage from the target Agent only; evaluator, expected-runner, and trace-replay usage are not included. The persisted EvalSetResult keeps statistics in its case/run results and does not add a set-level field.
ExecutionTime covers the complete evaluation flow, including inference and metric evaluation. InferenceStats.Duration sums actual agent inference time across cases and runs. With run-level parallelism, it can exceed the end-to-end wall-clock duration.
By default, evaluation.New creates AgentEvaluator and uses in-memory EvalSetManager, MetricManager, EvalResultManager, and the default Registry, and also creates a local Service. If you want to read EvalSet and metric configuration from local files and write results to files, you need to inject Local Managers explicitly.
AgentEvaluator supports running the same evaluation set multiple times via WithNumRuns. With the default single run, OverallStatus comes from that run's EvalCaseResult.finalEvalStatus. When WithNumRuns is greater than 1, aggregation is performed by case: metrics with the same name are averaged and compared with thresholds, and the aggregated metric statuses are then used to compute the case OverallStatus. Each run's raw results are preserved in EvalCaseResults, and aggregated metric results are written to MetricResults for display and diagnosis.
NumRuns: Repeated Runs
Because Agent execution may be nondeterministic, evaluation.WithNumRuns provides repeated runs to reduce randomness from a single run. The default is 1. When evaluation.WithNumRuns(n) is specified with n greater than 1, the same evaluation set performs n rounds of inference and evaluation within a single Evaluate, averages metrics with the same name at case granularity, and computes the case status from the aggregated metric statuses.
The number of result files does not increase linearly with repeated runs. One Evaluate writes a single result file corresponding to one EvalSetResult. When NumRuns is greater than 1, the file contains detailed results for multiple runs. Results for the same case across different runs appear in EvalCaseResults and are distinguished by runId.
NumRuns-Level Parallel Execution
When the same evaluation set needs to be run repeatedly, total duration grows with numRuns. The framework supports run-level parallel execution for repeated runs to reduce overall duration.
Specify the repeated run count and explicitly enable run-level parallelism when creating AgentEvaluator. There is currently no separate run-level parallelism option. Once enabled, the framework runs numRuns runs concurrently. If it is not enabled, runs remain serial even when evaluation.WithNumRuns(n) is set.
Run-level parallelism works at the level of full runs. Each run still performs a complete inference and evaluation cycle independently, and the final results are aggregated into the same EvalSetResult. Detailed results for the same EvalCase across different runs are written into EvalCaseResults and distinguished by runId.
After enabling concurrency, ensure that Runner, tool implementations, external dependencies, and callback logic are safe for concurrent calls. In particular, set-level callbacks from different runs within the same Evaluate may run concurrently. If they rely on shared mutable state, you must ensure concurrency safety yourself.