LLM Agent Evaluation Explained: Core Metrics and Model Selection in Practice

1. From Leaderboard Chasing to Real Work: Why Agent Evaluation Must Look at Real Sessions

For the past few years, the dominant way to evaluate a large language model was through static benchmarks: a fixed question set, fixed scoring, and a single overall leaderboard. In the agent era, this approach has exposed three structural weaknesses:

1. Data contamination and benchmark saturation: Popular question sets may leak into training data, so a high score no longer equals true capability.
2. Mismatch with real task distributions: Competition-style problems cannot measure the ability to “work continuously for two hours in a messy environment.”
3. No coverage of multi-step execution: The core of an agent is calling tools, reading and writing files, executing commands, and correcting course based on feedback. Single-turn Q&A evaluation is nearly powerless here.

As a result, evaluation is shifting toward arena-style assessment built on real users, real tasks, and long-horizon sessions. The basic approach: users submit open-ended tasks, the model executes multiple steps in an isolated sandbox, users provide feedback or preferences on both process and outcome, and a statistical model (such as Bradley-Terry-style algorithms) aggregates massive pairwise comparisons into a ranking.

The credibility of such leaderboards depends on two things: task diversity and sample size. Empirically, rankings only have sufficiently narrow confidence intervals when session samples reach the thousands or even tens of thousands and cover multiple categories such as work, coding, and everyday conversation. So the first thing to check when reading a leaderboard is not the ranking itself, but the methodology notes and sample size.

2. Five Core Metrics: What Each One Actually Measures

2.1 Net Improvement Rate

Think of it as the share of sessions where the user’s task state “got better” after model intervention, minus the share where it “got worse.” It combines positive and negative outcomes into a single ledger and answers the most fundamental question—did this model actually help?

• Reading tip: The absolute value alone means little; what is more valuable is generational comparison under the same methodology. For example (illustrative data): a generational model moving from near zero to a few percentage points positive suggests its net positive contribution on complex tasks is expanding.
• Limitation: It is affected by task difficulty distribution; user population composition differs across time periods, so cross-time comparisons require caution.

2.2 Command Execution Reliability

A substantial portion of agent work is done through terminal commands: installing dependencies, running scripts, checking logs, modifying configurations. This metric typically measures the first-attempt success rate of model-generated commands and whether the model can recover within a limited number of steps after an error. Common failure modes include:

• Wrong environment/path assumptions (e.g., assuming a dependency is already installed);
• Destructive operations without confirmation;
• Mechanically repeating the same command after failure instead of changing approach.

Engineering takeaway: even if model reliability is high, the host side should still enforce safeguards:

import subprocess
def run_cmd(cmd: str, timeout: int = 60):
    """Command execution wrapper with timeout, output capture, and policy interception (illustrative)"""
    blocked = ("rm -rf /", "mkfs", "dd if=")   # simple blocklist example
    if any(b in cmd for b in blocked):
        return False, "blocked by policy"
    try:
        p = subprocess.run(cmd, shell=True, capture_output=True,
                           text=True, timeout=timeout)
        ok = (p.returncode == 0)
        return ok, (p.stdout if ok else p.stderr)
    except subprocess.TimeoutExpired:
        return False, "timeout"

Evaluation scores are statistical; a single session can still go wrong, so fallback strategies are indispensable.

2.3 Praise-to-Complaint Ratio

Natural language feedback within a session is a high-value signal: a “exactly what I wanted” or “went off track again” is more authentic than a scale rating. This metric counts the net difference between positive and negative feedback and approximates end-to-end satisfaction. Note its subjective noise: for the same outcome, novice and expert users may have very different feedback tendencies.

2.4 Steerability

This refers to the model’s ability to adjust its execution direction based on mid-course user feedback. Long-horizon agent tasks almost never get done right in one pass, so “can it be pulled back on track” is often more critical than “getting it right the first time.” A typical sign of poor steerability: the user has already pointed out a wrong direction, yet the model stubbornly runs the original path to completion. Common improvement measures include: more frequent intermediate confirmations, plan-first execution (outline before acting), and explicitly writing user feedback into task state for later steps to reference.

2.5 Task Confirmation Success Rate

Only sessions where the user explicitly confirms “done/usable” count as successes. It is more conservative than automated scoring but closer to real delivery standards. Together with net improvement rate, command reliability, and steerability, it forms a two-dimensional “process-outcome” view: individual metrics show process quality, while the overall ledger shows final results.

3. Three Architectural Elements Behind Agent Capability

3.1 Mixture of Experts (MoE)

Leading open-weight models today generally adopt MoE designs: total parameter counts reach hundreds of billions or even trillions, while only tens of billions of parameters are activated per token.

• Mechanism: A gating network selects a few “expert” feed-forward networks from a large pool for each token, achieving sparse activation.
• Benefit: Knowledge capacity is determined by total parameters, while per-inference compute cost is determined by activated parameters, balancing capacity and cost.
• Cost: Total memory must hold all parameters, so deployment requirements are higher than dense models with the same activation scale; training requires load-balancing strategies to prevent traffic from concentrating on a few experts; inference often uses expert parallelism, making communication patterns more complex.

Selection takeaway: when looking at MoE model specs, the ratio of “total parameters to activated parameters” reflects the true cost structure better than a single parameter count.

3.2 Ultra-Long Context

Context windows ranging from tens of thousands to millions of tokens directly determine an agent’s “working memory” radius: understanding an entire medium-sized codebase at once; fully retaining the execution trajectory of a long-horizon task; analyzing a long document as a whole rather than chunking it and losing context. The engineering challenge is that attention computation and KV cache memory grow with length, typically mitigated through positional encoding extrapolation, sparse attention, and cache management. Users should focus on “effective context” rather than the nominal window—the closer to the length limit, the more likely recall quality for middle information degrades.

3.3 Native Multimodality

Agent inputs have long gone beyond text: UI screenshots, charts, scanned documents, design mockups. Native multimodality means the model jointly models images and text during pretraining rather than relying on an external recognition pipeline. It offers clear advantages in scenarios that require “understanding the environment and acting on it,” such as locating a problem from an error screenshot or generating front-end code from a design mockup.

4. Open Weights: Ecosystem Value and Deployment Considerations

The significance of open-weight models goes beyond low acquisition cost:

• Private deployment, meeting compliance requirements that data must not leave a given domain;
• Fine-tuning on business data, building domain-specific capabilities;
• Replaceability, avoiding lock-in to a single service.

For deployment form, teams can build their own inference clusters or use managed cloud services. The latter typically involves several general capabilities: GPU compute and elastic scaling, container platforms, model serving and inference acceleration, and logging and monitoring/alerting. For example, general model deployment and compute management capabilities offered by platforms such as Baidu AI Cloud can offload the operational burden of self-built clusters, letting teams focus on evaluation and business logic. Regardless of form, it is advisable to start with a small-scale gray release and expand traffic only after the self-built evaluation passes.

5. Turning Leaderboards into Decisions: A Practical Selection Workflow

1. Scenario alignment: For coding tasks, prioritize command execution reliability and code sub-scores; for customer-facing assistant tasks, prioritize satisfaction and steerability.
2. Sub-scores over composite scores: Two models with similar overall rankings may differ greatly on individual metrics, and that directly determines their performance in your scenario.
3. Verify methodology and samples: Task category distribution, session sample size, statistical method, and time window—none can be omitted.
4. Build your own evaluation set: Construct tasks sampled from real business scenarios, and combine three layers of scoring—rule-based scoring (does it compile, do assertions pass), model-based scoring (rubric-based), and manual spot checks.
5. Continuous regression: Model versions iterate frequently; run regression evaluation before rolling out any upgrade.

A minimal evaluation pipeline example:

tasks = load_tasks("business_eval.jsonl")   # sample from real business tasks
records = []
for t in tasks:
    traj = agent.run(t.instruction, tools=t.tools, sandbox=t.sandbox)
    records.append({
        "task_id": t.id,
        "confirmed": judge_by_rule(traj, t),       # task confirmation
        "cmd_ok_rate": cmd_success_rate(traj),     # command reliability
        "steer_ok": check_feedback_revision(traj), # steerability
        "steps": len(traj.steps),
    })
report = aggregate(records)   # aggregate sub-metrics and output a version comparison report

Finally, don’t forget cost accounting: activation parameter scale, context length, and concurrency together determine inference cost. Validate with stress testing against your target SLA rather than relying on leaderboards alone.

6. Conclusion

Agent evaluation is moving from “exams” to “internship reviews”: real tasks, real feedback, long-horizon observation. For developers, the value of a leaderboard is not the ranking itself but the metric language it provides, validated through large-scale sessions—net improvement rate tells you “did it help,” command reliability and steerability tell you “is the process trustworthy,” and confirmation success rate tells you “is the delivery accepted.” Bringing this metric language into your own business evaluation, together with self-built evaluation sets and continuous regression, is what truly answers the most important question: which model fits my scenario.