AI Agent Performance Evaluation: Two Paths and Testing in Practice

Traditional software testing's "fixed input, fixed output" approach often fails when applied to LLM-driven AI Agents: answers may differ each time, context changes results, and performance metrics go beyond response time. In a Bilibili open class, the instructor approaches "AI testing" from a test engineer's perspective, breaks it into two paths, and explains why quality assurance for AI products requires a different mindset.

First, Distinguish the Two Paths: AI-Empowered Testing vs. Testing AI Products Themselves

Instructor Tracy divides AI applications in software testing into two directions.

The first is AI-empowered testing: using AI tools, agents, and skills to generate test cases, write automation scripts, and assist with performance testing—essentially improving efficiency. This is the part most testers are already engaging with, for example using AI coding tools for automated test development.

The second is testing AI products themselves: the company already has an AI agent or AI application about to launch, and testers need to ensure its quality. This path is not about "using AI to help testing" but about "how to test AI."

The two paths are not mutually exclusive, nor is there a strict order. The instructor recommends learning both: traditional software roles can use AI tools to boost efficiency, while AI product testing is a job direction growing with the spread of agents.

Why Traditional Testing Methods Fail on AI Agents

Intelligent customer service is a typical example. Past customer service bots were jokingly called "artificial stupidity" by users, with very fixed interaction logic; now many customer service applications are built on generative large models, giving more precise answers, but outputs are no longer enumerable.

This brings three direct changes: asking the same question multiple times may yield different answers; conversation context affects subsequent results; and performance evaluation cannot focus only on average response time but must also consider generation quality and stability. Traditional equivalence class, boundary value, and fixed expected result assertion methods are hard to apply directly.

Therefore, before launching an AI product, both functional testing and non-functional testing (performance being one category) require redesigning the test objects and quality risk models.

Traditional functional testing relies on the "oracle problem"—that is, the existence of a deterministic expected result as the basis for judgment. Methods such as equivalence class partitioning and boundary value analysis assume a stable mapping between input and output, and test cases pass or fail by asserting whether the actual output equals the expected output. The output of generative large models is essentially the result of probabilistic sampling; the same input under different sampling parameters (such as temperature, top-p) produces different text, so there is no unique correct answer. Common alternative approaches in the industry include: rubric- or scoring-criteria-based evaluation, using an LLM as a judge (LLM-as-a-Judge) to score outputs, and soft assertions based on semantic similarity or key information coverage. These methods transform "is it right" into "is it good enough," which is fundamentally different from traditional assertions in judgment logic.

Which Real Product Scenarios Have Agents Already Been Embedded In

The scenarios listed in the course are very down-to-earth: automatic subtitle and video description generation in video software, resume optimization assistants on recruitment platforms, homework grading agents on teaching platforms, and intelligent customer service in Taobao and banking applications. These functions used to be done manually and are now handled by embedded AI modules.

As product forms change, test objects change accordingly: not just pages and interfaces, but also the reasonableness of model outputs, context handling capabilities, and performance under high-concurrency calls. This is where the value of performance testing shows—AI services often have high invocation costs and long response chains, and stress testing can expose bottlenecks in advance.

Where Performance Testing Fits in Agent Evaluation

The original title mentioned Python+Locust automation and the AIES evaluation platform, and the course also positions performance testing as a type of non-functional testing scenario. Python-based stress testing tools like Locust are suitable for simulating concurrent users sending requests to agent interfaces, while evaluation platforms like AIES focus more on evaluating the quality of model or agent outputs.

The combined approach is: use stress testing tools to answer "can the system handle it," and use evaluation platforms to answer "are the answers good." For AI Agents, both questions are indispensable—testing only throughput misses quality degradation, while testing only quality cannot guarantee post-launch stability.

Locust is an open-source load testing tool based on Python. Testers define user behavior in ordinary Python code and simulate large numbers of virtual users concurrently through coroutines, without writing a separate complex stress testing scripting language. It supports distributed deployment to generate higher concurrency and provides a Web UI for real-time viewing of request rates, response time distributions, and failure rates. Compared with tools like JMeter, Locust's advantage is that scripts are code, making it easy to integrate with CI/CD pipelines and reuse the existing Python ecosystem. When stress testing large model interfaces, special attention is needed: token-level streaming responses change the meaning of response time metrics, so first token latency (TTFT) and overall generation duration must be measured separately; meanwhile, as concurrency rises, the server may trigger rate limiting or degradation, all of which require corresponding observation points designed in the script.

Evaluation platforms like AIES are aimed at quantitative evaluation of model or agent output quality, which is a different dimension from what stress testing tools focus on. They usually design evaluation sets around dimensions such as accuracy, relevance, safety, and instruction following, and give comparable scores through automatic scoring or human annotation. In agent scenarios, evaluation also needs to consider context consistency across multi-turn dialogues, tool invocation accuracy, and task completion rate. The value of incorporating evaluation platforms into the launch process lies in establishing a quality baseline: after each model version iteration or prompt adjustment, rerun the evaluation set and use score changes to determine whether quality degradation has occurred. This complements the stress testing answer to "can the system handle it," and together they form the quality gate before an AI product launch.

Practical Advice for Testing Practitioners

In class, the instructor directly asked students: when testing an AI intelligent assistant, is the method the same as for traditional software? This interaction itself shows that most people's intuition is "not the same," but exactly where it differs and how to test it still require systematic learning.

From a career perspective, learning both paths is the more cost-effective choice. AI-empowered testing can be applied immediately in existing work, while testing AI products corresponds to an expanding job demand—every company is embedding AI modules into its products, and pre-launch quality control is unavoidable.

The course itself is introductory in nature. When it comes to how to write Locust scripts and how to use the AIES platform, hands-on materials are still needed for practice. For testers who want to get started, first building the cognitive framework of "two paths" and then choosing one to go deeper is a more pragmatic route.

One-line Summary

AI testing has two paths: using AI to make testing more efficient, and testing the quality of AI products themselves.

Paragraph Summary

From a test engineer's perspective, the article breaks down the two paths of AI testing: first, AI-empowered testing, using AI tools to generate test cases and write automation scripts to improve efficiency; second, testing AI products themselves, ensuring the launch quality of agent applications. Because generative large model outputs are not enumerable and context affects results, traditional equivalence class, boundary value, and fixed assertion testing methods are hard to apply directly, and both functional and non-functional testing require redesigned quality risk models. The article lists product scenarios that already embed AI modules, such as intelligent customer service, resume optimization, and homework grading, points out that test objects have expanded from interfaces to model output reasonableness and concurrency performance, and explains that stress testing tools and evaluation platforms answer "can it handle it" and "are the answers good," respectively.