LLM Agent Capability Evaluation and Selection: A Practical Guide

From Q&A to Agent Capability: The Shift in Evaluation

In the early stage of LLM applications, the industry usually paid more attention to question-answering quality, such as whether the model can accurately explain concepts, whether it has strong text generation capabilities, and whether it can understand complex instructions. These capabilities are certainly important, but they mainly remain at the level of “single-turn or few-turn interaction”: the user asks a question, the model gives an answer, and the system can judge the effect accordingly.

However, as agent application scenarios continue to grow, models are no longer expected only to “answer,” but also to “act.” For example, automatically organizing materials, automatically querying system status, automatically executing multi-step operational workflows, automatically repairing failed tasks, and automatically generating and validating outputs. These tasks usually have the following characteristics:

1. Multi-step execution: A task may be broken down into a dozen or even hundreds of sub-steps.
2. Strong tool dependency: The model needs to call tools such as retrieval, databases, APIs, scripting environments, forms, and file systems.
3. Context-dependent results: The output of a previous step affects decisions in later steps, and errors have cumulative effects.
4. Active verification: The model cannot only “execute”; it must also determine whether the execution result meets expectations.
5. Error recovery: When tool calls fail, permissions are insufficient, data is missing, or output formats are abnormal, the model should be able to identify the problem and attempt to correct it.
6. Termination judgment: Not all tasks can be successfully completed. Agents need to decide whether to continue, retry, degrade, or exit.

Therefore, when evaluating LLMs, it is not enough to look only at whether the model can “speak well.” It is also necessary to assess whether it can “act reliably,” and not only its single-point capability, but also its stability, efficiency, and controllability within a complete task closed loop.

What Is LLM Agent Capability?

LLM agent capability can be summarized as the model’s ability to autonomously complete the following closed loop without continuous human intervention:

Understand the goal → Plan the steps → Call tools → Check results → Correct errors → Output results

This closed loop is fundamentally different from traditional question-answering capability. In Q&A tasks, the model’s main responsibility is to generate reasonable text; in agent tasks, the model also takes on the role of an “execution controller.” It must determine which tool to call, what parameters to pass, when to stop, and how to adjust the plan when a failure occurs.

Agent capability can be understood through six dimensions:

1. Goal Understanding

An agent must first extract the real goal from a natural-language instruction. For example, if a user says, “Help me organize last week’s sales data into a report,” the model needs to identify information such as the data scope, time range, output format, and potential dependent systems. If goal understanding is inaccurate, even carefully executed later steps may still deviate from the business intent.

2. Task Planning

Complex tasks usually cannot be completed in a single step. The model needs to break a large goal into executable subtasks, such as “query data — clean data — generate charts — write a summary — export the file.” Models with stronger planning capabilities usually reduce unnecessary steps and improve task completion efficiency.

3. Tool Calling

Tool calling is key to bringing agents into production. The model needs to understand tool descriptions, parameter structures, and return-value meanings, and call the right tool at the right time. Common problems include missing parameters, incorrect parameter types, wrong tool selection, repeated calls, and incorrect call order.

4. Environment Awareness

The environment an agent faces is usually not static text, but dynamic state. For example, command-line output, API responses, file contents, web elements, and system prompts can all affect subsequent behavior. The model needs to understand environmental feedback rather than mechanically execute a preset flow.

5. Result Verification

Execution does not mean completion. An agent needs to determine whether the tool return is successful, whether the data is complete, and whether the output meets format requirements. For example, after generating a report, the agent needs to verify whether the fields are complete, whether the values are reasonable, and whether the file can be opened. Agents lacking verification capability can easily produce results that “look complete but are not actually usable.”

6. Error Recovery and Termination

Agents will inevitably encounter failures in real environments. A strong agent should be able to identify the cause of failure and choose an appropriate response, such as retrying, switching paths, supplementing context, requesting human confirmation, or terminating safely. Conversely, if the model cannot recognize errors, it may fall into infinite loops, amplify errors, or output misleading conclusions.

Why Agent Evaluation Should Not Rely on a Single Score

During model selection, many people tend to refer to a benchmark score or a specific evaluation result. However, agent capability is different from single-point Q&A capability. It is affected by multiple factors, including task type, tool environment, context length, invocation cost, latency requirements, and safety policies. A single score can hardly fully represent real business capability.

1. Different Tasks Require Different Capabilities

Some tasks emphasize long-horizon planning, such as cross-system data integration; some emphasize fast response, such as real-time customer service assistance; some emphasize file operations, such as automated document processing; and some emphasize web operations, such as browser automation. A model that performs well on one type of task does not necessarily perform equally well in all scenarios.

2. The Evaluation Environment Significantly Affects Results

The same model may perform well in an environment with clear tool descriptions, reasonable permission configuration, and standardized error messages. However, if tool definitions are vague, API responses are messy, or permission restrictions are strict, task success rates may drop significantly. Therefore, agent selection must be evaluated together with the actual engineering environment.

3. Success Rate Is Not the Only Factor; Efficiency and Cost Also Matter

Some models can complete tasks, but with too many steps, excessive token consumption, or excessive latency, the final cost becomes unacceptable. Other models may be slightly weaker in single-call capability, but with better routing strategies, context compression, and caching mechanisms, the overall system cost may be lower. Therefore, selection should not only consider “whether it can complete the task,” but also “how much cost and how much latency it takes to complete the task.”

4. Stability Matters More Than Peak Performance

A successful demo does not mean production readiness. Agents in production need to run for long periods and face many edge cases, abnormal inputs, permission restrictions, and tool failures. Therefore, evaluation should focus on average success rate, failure distribution, recovery rate, human intervention rate, and regression stability, rather than only looking at the best samples.

Benchmark Dimensions for LLM Agent Evaluation

When building an evaluation system, it is recommended to cross-validate across multiple dimensions rather than relying on a single metric. Common agent capability evaluation dimensions include the following categories.

1. Interactive Task Evaluation

This type of task simulates real user sessions and focuses on whether the model understands requirements during continuous interaction and whether it can adjust its strategy based on feedback. Evaluation focuses include instruction following, context retention, clarifying questions, and plan revision.

2. Command-Line and System Operation Evaluation

This type of task examines the model’s ability to execute operations, parse output, and handle exceptions in a command-line environment. For example, generating commands based on task goals, determining whether commands succeeded, and correcting commands based on error messages. Evaluation should focus on parameter correctness, error recovery capability, and risk control capability.

3. Desktop GUI Operation Evaluation

This type of task simulates human operation of desktop software, including opening applications, clicking buttons, filling out forms, and reading window content. The difficulty lies in complex interface states, diverse operation paths, and feedback that depends on visual or structured interface information. Evaluation should focus on operation success rate, step redundancy, and exception handling capability.

4. Browser Automation Evaluation

Browser tasks are common agent scenarios, such as information retrieval, form submission, content extraction, and flow navigation. Evaluation should focus on page understanding, element location, dynamic content handling, anti-scraping limitations, login-state management, and task completion.

5. Autonomous Retrieval and Information Aggregation Evaluation

This type of task requires the model to actively search for information, filter sources, summarize information, and form conclusions. The evaluation focus is not whether a single answer is fluent, but whether the information is accurate, whether citations are traceable, whether conclusions are evidence-based, and whether conflicting information can be identified.

6. Code Generation and Repair Evaluation

Code tasks require not only generating code, but also understanding the runtime environment, dependencies, error logs, and test feedback. Evaluation should include code correctness, runnability, repair efficiency, boundary-condition handling, and security.

Build an Agent Selection Scorecard

To avoid overly subjective model selection, it is recommended to establish a unified scorecard. The scorecard should combine technical indicators with business goals to form quantifiable and comparable decision-making criteria.

Dimension	Key Question	Evaluation Method
Task success rate	Can the agent complete tasks stably?	Measure success rate using a business task set
Step efficiency	Does it complete the goal with fewer steps?	Count average steps and the proportion of redundant steps
Tool-call accuracy	Does it select the right tools and parameters?	Analyze call logs and failure causes
Error recovery rate	Can it correct errors after failure?	Create abnormal samples and observe recovery behavior
Latency performance	Does it meet real-time requirements?	Measure average latency and tail latency
Cost performance	Is the cost per task acceptable?	Evaluate input/output consumption and number of calls
Controllability	Can permissions and behavior boundaries be restricted?	Review sandboxing, permissions, auditing, and termination mechanisms
Extensibility	Is it easy to integrate more tools?	Evaluate tool registration, description standards, and context management
Security	Is there a risk of data leakage or incorrect operations?	Conduct security reviews and permission tests

A simplified overall score can be represented as:

Overall score =
    Task success rate weight × Success rate
  + Step efficiency weight × Efficiency score
  + Tool accuracy weight × Tool accuracy
  + Error recovery weight × Recovery rate
  - Cost weight × Cost index
  - Latency weight × Latency index
  - Risk weight × Risk index

Weights should be adjusted according to business scenarios. For example, real-time interaction scenarios should increase the weight of latency, high-risk operation scenarios should increase the weight of security and controllability, and large-scale batch processing scenarios should increase the weight of cost and throughput.

Selection Strategies for Typical Scenarios

Different business scenarios have very different requirements for agent capabilities. It is not appropriate to use the same standard to select all models.

1. High-Complexity Long-Horizon Tasks

Examples include cross-system data analysis, complex workflow automation, code refactoring, and project-level document processing. These tasks involve many steps, strong dependencies, and high error costs. Selection should prioritize task planning capability, long-context understanding, tool-call stability, and error recovery capability. At the same time, strict verification mechanisms should be established to prevent the agent from continuing execution on an incorrect path.

2. High-Frequency Lightweight Tasks

Examples include intent classification, summary generation, ticket routing, and simple Q&A enhancement. These tasks usually involve few steps but are sensitive to latency and cost. Selection should not blindly pursue the strongest model. Instead, it should prioritize response speed, stability, unit cost, and batch processing capability.

3. Batch Data Processing Tasks

Examples include log analysis, batch document extraction, and structured information organization. These tasks usually have high throughput and lower latency requirements for individual tasks, but higher requirements for total cost, stability, and retryability. Costs can be reduced through task tiering, asynchronous execution, batch processing APIs, and caching mechanisms.

4. Real-Time Interaction Tasks

Examples include online assistants, office collaboration, and customer service assistance. These tasks require low latency and stable output. Selection should focus on tail latency, concurrency capability, context management, and abnormal degradation mechanisms. If model inference time is too long, even a high task success rate may still make it unsuitable for real-time scenarios.

5. Security-Sensitive Tasks

Examples include internal system operations, permission-related operations, data writes, and approval workflows. These tasks must emphasize least privilege, operation auditing, sandbox isolation, human confirmation, and rollback mechanisms. Model capability is important, but security boundaries are even more critical.

6. Information Retrieval and Aggregation Tasks

Examples include industry research, document organization, competitive analysis, and policy review. These tasks should focus on retrieval accuracy, source traceability, summary quality, and factual consistency. The agent should not only generate answers, but also provide an evidence chain and avoid unsupported inference.

Putting LLM Agent Evaluation into Practice

To make evaluation results closer to production environments, it is recommended to establish a standardized evaluation process.

1. Clarify the Business Closed Loop

First, clarify what task the agent needs to complete, what the input is, what the output is, what the success criteria are, and what impact failures may cause. Tasks without clear success criteria are not suitable as evaluation benchmarks.

2. Build a Representative Task Set

The task set should cover common scenarios, boundary scenarios, and abnormal scenarios. It is recommended to include:

1. Normal tasks: Verify basic capabilities.
2. Complex tasks: Verify planning and long-horizon execution capabilities.
3. Abnormal tasks: Verify error recovery capabilities.
4. Permission-restricted tasks: Verify security and boundary control.
5. High-concurrency tasks: Verify stability and resource consumption.
6. Ambiguous-instruction tasks: Verify clarification and follow-up questioning capabilities.

3. Define Unified Metrics

Metrics should include success rate, number of steps, tool-call accuracy, error recovery rate, average latency, tail latency, cost per task, and human intervention rate. Metrics should be as automatically measurable as possible to reduce manual judgment bias.

4. Automate Execution and Retain Logs

Each evaluation run should preserve a complete execution trace, including inputs, plans, tool calls, return values, error information, final outputs, and verification results. Logs are an important foundation for subsequent root-cause analysis and continuous optimization.

5. Perform Failure Root-Cause Analysis

When a task fails, it is necessary to distinguish whether the cause is a model problem, a tool problem, an environment problem, or a design problem. Common causes include:

1. Incorrect goal understanding;
2. Missing planning steps;
3. Incorrect tool selection;
4. Incorrect parameter generation;
5. Incorrect parsing of environmental feedback;
6. Failed error recovery;
7. Missing verification logic;
8. Insufficient permission configuration.

6. Use Gray Release and Continuous Regression

After an agent goes live, it should not be switched over in a single full-scale release. It is recommended to observe real traffic performance through gray release and establish a regression test set to prevent capability degradation caused by model upgrades, tool changes, or prompt adjustments.

7. Build an Evaluation Dashboard

Evaluation results should be visualized so that teams can continuously track them. The dashboard can include success-rate trends, cost trends, failure-type distribution, average steps, recovery rate, human intervention rate, and other metrics.

Example Evaluation Pseudocode

The following is a general example of an agent evaluation process. It does not depend on a specific model or platform:

task_set = [
  {
    "task_id": "T001",
    "goal": "Query order data within a specified period and generate a summary report",
    "required_tools": ["data_query", "report_generation"],
    "expected_result": {"field_count": 8, "file_format": "spreadsheet"},
    "max_steps": 30,
    "timeout_seconds": 120
  },
  {
    "task_id": "T002",
    "goal": "Search information on the web and organize it into a summary",
    "required_tools": ["web_search", "content_extraction", "summary_generation"],
    "expected_result": {"citation_count": 3, "summary_length": 300},
    "max_steps": 40,
    "timeout_seconds": 180
  }
]
function evaluate_agent(task_set, model, validator):
    metric_list = []
    for task in task_set:
        execution_result = model.execute(
            goal = task.goal,
            tools = task.required_tools,
            max_steps = task.max_steps,
            timeout = task.timeout_seconds
        )
        success = validator(task, execution_result)
        metric_list.append({
            "task_id": task.task_id,
            "success": success,
            "steps": execution_result.steps,
            "tool_errors": execution_result.tool_errors,
            "recovered": execution_result.recovery_successful,
            "elapsed_time": execution_result.elapsed_time,
            "cost": execution_result.cost
        })
    return aggregate_metrics(metric_list)

The key point of this process is not the code itself, but the three engineering principles it emphasizes: standardized tasks, verifiable results, and quantifiable metrics.

Engineering Practices for Improving Agent Stability

Model capability is only one part of an agent system. To truly bring it into production, supporting engineering capabilities are also required.

1. Tool Descriptions Must Be Clear

Tool names, functional descriptions, parameter meanings, return-value structures, error codes, and invocation limits should all be clearly expressed. Vague tool descriptions significantly increase the probability of incorrect model usage.

2. Control Context Length

Long contexts can help understand complex tasks, but they also increase cost, latency, and noise. It is recommended to compress or filter historical messages, tool returns, and retrieval results, keeping only information relevant to the current decision.

3. Use Structured Output

For parts that require programmatic processing, the model should be required to output structured formats, such as JSON, tables, or state-machine fields. Structured output is easier to validate and reduces the risk of downstream parsing failures.

4. Establish Sandbox and Permission Boundaries

When agents perform operations, they should be limited in terms of accessible resources, executable commands, callable APIs, and data scope. For high-risk operations, human confirmation or secondary approval should be introduced.

5. Design Retry and Circuit-Breaker Mechanisms

When tools fail repeatedly or the error rate exceeds a threshold, the system should automatically trigger circuit-breaking to prevent the agent from falling into an ineffective loop. The retry mechanism should also have a maximum attempt limit and record failure reasons.

6. Improve Logging, Tracing, and Replay Capabilities

Every task execution should be traceable and replayable. This helps locate problems and also provides a basis for model optimization, prompt optimization, and tool improvement. In cloud environments, a complete observability system can be built using common capabilities such as logging services, monitoring alerts, object storage, message queues, and container platforms.

7. Provide Human Takeover Entry Points

For critical business processes, agents should not completely replace humans. When confidence is insufficient, task risk is high, or failures continue, the task should be handed over to a human in time.

Cost Optimization: From “It Runs” to “Sustainable Operation”

The cost of agent applications comes not only from model calls themselves, but also from tool calls, context length, retry counts, storage, monitoring, and human intervention. Therefore, cost optimization requires systematic design.

1. Model Routing

Use low-cost models for simple tasks and high-capability models for complex tasks. Through a routing mechanism, total cost can be reduced while maintaining effectiveness.

2. Caching and Reuse

For repeated questions, similar tasks, or stable results, a caching mechanism can be established. For example, common Q&A, fixed report generation, and standardized information extraction can reduce repeated calls through caching.

3. Context Compression

Summarize or filter historical conversations, retrieved documents, and tool returns to reduce unnecessary token consumption.

4. Asynchronous and Batch Processing

For non-real-time tasks, asynchronous queues and batch processing can improve resource utilization and reduce the cost per task.

5. Task Tiering

Divide tasks into three levels: simple, medium, and complex, and configure different models, tool permissions, and verification strategies for each level. Avoid using the highest configuration for all tasks.

6. Failure Cost Control

Failed agent executions also incur costs. Therefore, verification should be added in early steps to avoid errors accumulating and only becoming visible in later stages.

Common Selection Pitfalls

Pitfall 1: Only Looking at Leaderboard Rankings

Leaderboard scores can be used as a reference, but they cannot replace real business evaluation. Different leaderboards have different task distributions, tool environments, and scoring methods, so their results cannot be directly transferred.

Pitfall 2: Using Q&A Capability as a Substitute for Agent Capability

A model that answers well does not necessarily execute well. Agent tasks require planning, tool calling, verification, and recovery. These capabilities must be validated through closed-loop tasks.

Pitfall 3: Only Testing the Success Path

If only smooth scenarios are tested, system stability may easily be overestimated. The most common risks in production come from abnormal inputs, tool failures, permission restrictions, and edge cases.

Pitfall 4: Ignoring the Tool Environment

Model performance is often heavily affected by tool definitions. If tool descriptions are confusing, parameters are complex, or returns are unstable, even a strong model may struggle to complete tasks stably.

Pitfall 5: Ignoring Long-Term Operational Costs

After an agent goes live, it requires continuous monitoring, regression testing, log analysis, permission management, and version upgrades. If operational costs are not considered during selection, teams may face a heavy burden later.

Pitfall 6: Over-Optimizing for a Single-Point Capability

Agent systems compete on comprehensive capability, not on a single metric. Planning, tool use, stability, cost, security, and engineering adaptability are equally important.

Conclusion: Use Business Closed Loops and Overall Efficiency as Selection Criteria

LLM agent capability evaluation and selection should not stop at whether the model is “smart.” It should enter the engineering level of whether the system is reliable, whether tasks can be completed, whether costs are acceptable, and whether risks are controllable.

In practical selection, the following principles are recommended:

1. Start from business goals and clarify the closed-loop tasks the agent needs to complete.
2. Build a multi-dimensional evaluation system that considers success rate, efficiency, cost, latency, security, and controllability together.
3. Avoid single-metric decisions and cross-validate leaderboards, benchmark tests, and real business samples.
4. Value tools and engineering environments because tool descriptions, permission design, log tracing, and error recovery determine the quality of deployment.
5. Use scenario-based strategies because high-complexity tasks, high-frequency tasks, real-time tasks, and batch tasks require different solutions.
6. Continue evaluation and gray release and use regression testing and monitoring alerts to ensure long-term stability.
7. Focus on overall efficiency and seek the best balance among capability, cost, latency, and risk.

When agent capability is placed into a complete business closed loop, engineering system, and continuous operations framework, model selection truly shifts from “looking at parameters and scores” to “looking at results, stability, and long-term value.” This is also the key path for LLM agents to move from demonstrations to production and from pilots to scale.