Tencent WeTest at Devcom: Two New AI Testing Solutions, From Fixed Scripts to Autonomous Agents

Introduction

With no one sitting in front of the screen, a game character autonomously navigates, enters a dungeon, finishes a battle, and leaves a verifiable trail of evidence upon completion.

The true value of an AI Agent in games is not just "knowing how to play," but taking over the time-consuming, repetitive testing workflows that are most easily disrupted by random, dynamic situations.

At this year's Gamescom Developer Conference (devcom), discussions around AI topics reached a new level of warmth. The conference not only established two specialized tracks—"AI in Gameplay" (focusing on how AI transforms play) and "AI in Production" (focusing on how AI optimizes production pipelines)—but also saw over half of its 32 AI-related sessions focus on practical, real-world application.

This dual integration of "gameplay innovation" and "production pipelines" is rapidly becoming a defining global trend in the game industry. It aligns perfectly with the AI application roadmap previously outlined by Tencent Games. From overseas giants like EA to Chinese developers led by Tencent, creators have been showcasing their latest practical explorations.

Tencent WeTest, the quality assurance brand under Tencent Games, made its debut on the Devcom stage, officially unveiling two AI game testing agent solutions with distinct yet complementary positions:

• Acorn AI Test Agent: Detailed by Easons Ye, Specialized Technical Testing Manager at Tencent Games. This solution centers on "goal-driven and state closed-loop" operations. Targeted at open-world and high-frequency iteration scenarios, it shifts the testing logic from "did the script finish running?" to "is the game state within expectations and verifiable?", successfully overcoming the bottleneck where traditional scripts frequently fail under dynamic changes.
• General Game Test Agent (Reusable Agent Architecture): Unveiled by Vincent Gao, Technical Director at Tencent WeTest. This solution features a "pure vision-based, zero-access (non-intrusive), and cross-genre reusable architecture." It operates without reading internal game data or intruding into the client. Relying solely on raw visual screen inputs and standard mouse/keyboard controls, it aims to lower the engineering barrier for integrating automation into new games.

The following is a curated transcript of the presentations delivered by the two technical experts, systemically deconstructing Tencent Games' concrete engineering practices and architectural insights regarding AI test agents:

---

 

Section 01: AI's Goal Goes Beyond "Knowing How to Play"

Presented by Easons Ye

 

(At devcom, Tencent Games shares "From Scripts to AI Agents")

In automated game testing, the core objective of a test case is typically fixed—for instance, "Enter Area B, survive the second wave of combat, eliminate all enemies, and complete the quest."

However, actual gameplay execution is highly dynamic: enemies may spawn randomly at different positions, the path to Area B can be blocked at any moment, and the exact progression of each combat round varies. To successfully achieve the same test objective, the system must perceive and comprehend the environment in real time, dynamically deciding on the next operation.

 

(Strengths and failure scenarios of fixed scripts versus general vision models)

To tackle this challenge, we previously explored two technical paths, each exhibiting distinct limitations:

• Path 1: Fixed Scripts
  • Strengths: Stable workflows, clear expectations; ideal for highly deterministic testing scenarios.
  • Limitations: Lack of adaptability in real-time combat. As game mechanics grow in complexity, scripts become increasingly difficult to maintain and highly prone to failure. Moreover, even if every instruction executes successfully, it does not directly prove that the test objective has been genuinely achieved.
• Path 2: General Vision Models
  • Strengths: Capable of directly observing game screens to decide the next action, offering extreme flexibility.
  • Limitations: Relying solely on visual feedback yields imprecise information acquisition, making it difficult to keep pace with rapid, high-frequency combat and complex navigation.

Practical experience shows that fixed scripts and pure vision models can only solve separate parts of the problem. Neither alone can flawlessly cope with the dynamic and complex demands of game testing.

 

(Dynamic game testing requires three core capabilities: Perception, Operation, and Judgment)

To achieve more efficient testing, we have structured the core capabilities of our Agent into three supporting modules: Perception, Operation, and Judgment.

1. Perception — Providing "Reliable Information"
   • Core Function: Answers "how the game works" and "what is happening at this very moment."
   • Inputs: Integrates static game knowledge (rules, mechanics) with dynamic runtime states (real-time screens, data streams) to provide a holistic view for decision-making.
2. Operation — Ensuring "Stable Execution"
   • Core Function: Formulates action strategies and distributes execution in a highly reliable, reusable manner.
   • Coordination: The model does not need to directly control every microscopic step. Standard low-level actions continue to be executed stably by automated scripts. The Agent acts as the "brain," focusing on deciding when and how to invoke these scripts and Skills.
3. Judgment — Offering "Clear Verification"
   • Core Function: Confirms via a closed loop whether the expected outcomes have genuinely been achieved.
   • Verification Basis: Relying not on speculative intuition, but on "hard evidence"—such as system logs, performance metrics, and state frames—to validate the completion of test objectives.

Architectural Summary: "Perception" understands the current state and assists decision-making; "Operation" dispatches scripts to ensure stable implementation; "Judgment" leverages data for objective verification. Instead of blindly handing the entire pipeline over to AI, we organize these three capabilities into a highly available, extensible testing framework.

 

(Closed-loop architecture composed of Knowledge, Agent Loop, Runtime Observability, and Post-mortem Learning)

To realize this, we designed a four-layer testing architecture. At the center of the framework is the Agent Loop. Surrounding this core brain are three supporting system layers:

• Layer 1: Knowledge Layer — Empowering "Perception"
  • Deep Understanding: Automatically extracts and structures information from game rules, feature lists, and design documents, assembling them into core knowledge representations such as a Game Graph, Skill Library, and State Model.
  • Context Construction: When a test case is received, the perception module immediately retrieves background information from the Knowledge Layer, precisely building the test context and passing it smoothly to the operation module.
• Layer 2: Runtime Observability Layer — Driving "Decisions and Traceability"
  • Real-time Decisioning: Continuously captures dynamic data such as game states, operations, and logs, helping the Agent understand the battlefield situation in real-time and decide which Skill to trigger or action to perform.
  • Comprehensive Tracking: Records the entire test process, including Action Traces, UI screenshots, system logs, and telemetry. It automatically weaves these into a complete Evidence Chain, providing a solid foundation for subsequent verification, debugging, and troubleshooting.
• Layer 3: Analysis & Learning Layer — Enabling "Evolution and Closed-Loop"
  • Objective Verification: Based on the evidence chain accumulated in Layer 2, the system precisely verifies if test objectives have been met.
  • Review & Evolution: Deeply analyzes detected bugs, automatically generates test reports, and feeds successful test experience back into the Knowledge Layer and Skill Library.
  • Systemic Closed-Loop: Through the complete path of "Task Execution ➔ Outcome Verification ➔ Root Cause Analysis ➔ Knowledge & Skill Feedback," the entire system achieves self-evolving, closed-loop capability, growing smarter over time.

Allow me to demonstrate an example. In the system demo (as shown in the game screen on the right), the monitoring panel on the left is capturing multi-dimensional runtime data in real time:

• States & Events: The upper-left panel displays the player's position, HP, equipment, and skill cooldowns in real-time. The upper-right logs key events such as hits, kills, deaths, and heals.
• Logs & Telemetry: The lower section continuously aggregates system logs, UI widget information, performance indicators, and other runtime records.
• Core Mechanism — Time Alignment and Evidence Chain: All data is tightly aligned at the millisecond level to the exact same game timestamp. When an event occurs, multi-source data can be instantly aggregated to reconstruct the exact scene:
  • Driving High-Level Decisions: Based on global information, the AI assumes the responsibility of determining high-level strategies (e.g., whether to fight, retreat, heal, or adjust tactics), while low-level operations are handed off to highly stable Skill and script commands.
  • Forming Closed-Loop Verification: The system not only displays "current game state" and "what action the AI took," but also precisely tracks "what consequences followed."

This mechanism, which organically combines real-time decision-making with ultimate validation, forms our core asset for supporting complex automated testing: the Evidence Chain.

---

 

Section 02: AI Does Not Just Find "Framerate Drops"—It Identifies the Root Cause

To bring this closed-loop concept of "discovery to localization" to life, we can reconstruct its entire operation through a real-world performance testing scenario. In traditional automated performance testing, finding problems usually stops at the surface level—for instance, detecting a "framerate drop" or "game stuttering." However, knowing that a stutter occurred is only the first step. The part that truly drains development resources is answering why it occurred.

To bridge the gap between "discovering the symptom" and "localizing the root cause," an Agent must possess multi-dimensional collaborative capabilities:

• Full-Stack Data Perception
  • Symptom Capture: Leveraging vision models and framerate monitoring to capture anomalies like stuttering or framerate drops immediately.
  • Log Association: At the exact instant an anomaly occurs, system logs, telemetry metrics, and low-level trace data are automatically and tightly aligned and analyzed.
• Root Cause Attribution & Diagnosis
  • Instead of relying on manual troubleshooting, the Agent precisely maps visual anomalies directly to underlying code or asset invocations.
  • Example: Clarifying whether a stutter was caused by "overloaded visual effect assets loading in a specific zone" or an "infinite logical loop during a specific skill release."
  • Core Value: The introduction of AI upgrades automated testing from a basic "tester (bug finder)" to a "diagnostic expert (root-cause localizer)," drastically shortening the engineering team's debugging path and reducing troubleshooting costs.

 

(Performance testing evolves from a one-off report into a closed loop of "Explore, Discover, Investigate, Prove")

Traditional performance testing is linear: run a script ➔ collect data in a specific scene ➔ analyze the report ➔ hand over to developers. Once the report is generated, the testing task ends, leaving the heavy burden of identifying the underlying root cause entirely on the developers' shoulders.

In our AI closed-loop architecture, raw data is not the end of a test, but rather the starting point for the next round of autonomous exploration:

• Autonomous Cross-Analysis: The Agent actively aggregates and compares data across multiple runs to precisely isolate elusive performance bottlenecks that recur across different sessions.
• Autonomous Investigation: Upon detecting an anomaly, the Agent can autonomously generate targeted derivative test cases to isolate suspicious code and assets, retrieving deeper low-level evidence.

Consequently, performance testing departs from the single "Run - Collect - Report" model, evolving into a true Four-Stage Autonomous Closed Loop: Explore - Discover - Investigate - Prove. If the evidence accumulated in the current stage is insufficient to fully localize the root cause, the AI feeds its current findings back into the system to automatically trigger next-round, fine-grained targeted tests until conclusive evidence is secured.

 

(Clustering recurring performance spikes and their game context across 30 runs)

Take a specific performance testing scenario as an example:

The Agent automatically repeated the same scene 30 times. In this phase, its main objective was broad exploration. Unlike traditional testing, which records individual framerate drops in isolation, the Agent correlates every performance spike exceeding 200 ms with the game context of that exact moment—matching the player's precise coordinates, spawned enemy types, and the player's active action sequence.

By putting the data from all 30 runs together for comparative clustering, the Agent quickly discovered patterns, narrowing down the vague anomaly into a concrete troubleshooting hypothesis: performance spikes were not occurring randomly but were highly concentrated in Area B. It mapped out the performance hot spots, laying the groundwork for the next stage of targeted investigation.

 

(Targeted tasks narrow down hot spots into reproducible and inspectable trace evidence)

Once hot spots were locked in, the Agent did not stop. It actively initiated the second phase of targeted investigation. Extracting the previously recorded context, it autonomously designed and generated a set of more targeted test cases—directly navigating to Area B, spawning the target "Enemy A," and precisely replicating the exact action sequences to verify which factor triggered the issue.

When the frame execution time exceeded the threshold again, the system immediately triggered deep sampling instead of collecting only basic metrics, fetching deep trace evidence like utrace and Action Traces. By using utrace to reconstruct function call stacks during the spike, the Agent clearly identified the critical path contributing most to the frame time, pinpointing the problem down to specific systems and low-level code functions.

 

(Three principles to make closed-loop AI testing truly viable)

Core Lessons & Practical Principles

Our engineering experience points to three core principles:

1. Prioritize Structured Native States: While visual information is intuitive, structured native game data remains the most reliable source for the Agent to comprehend what is truly happening in real time, greatly increasing decision-making certainty.
2. Deeply Integrate Verification into Execution: Unidirectional action dispatching is meaningless. Every step of a test operation must be accompanied by robust verification, constantly confirming if the expected outcomes have materialized.
3. Learn from Failures to Enable Recovery: Rather than merely logging successful paths, failure sequences hold immense value. The Agent must be capable of learning recovery strategies from anomalies and failures, reusing these lessons to build a self-healing closed loop in subsequent testing.

Ultimately, our goal is not to blindly replace existing scripts with AI, but to deeply integrate "AI-driven decision-making," "stable script execution," and "closed-loop evidence verification." Automated AI testing can only truly master highly dynamic, high-complexity modern game testing scenarios when all three forces work in harmony.

---

 

Section 03: From "Defeating a Boss" to End-to-End Game Execution

Presented by Vincent Gao

Good afternoon, everyone. I am Vincent from the Quality Management Department of Tencent Interactive Entertainment Group (IEG).

Today, I will introduce a reusable game Agent architecture designed to accelerate automated game testing. The key word here is "reusable." We are not suggesting that a single, rigid strategy can handle all games. Rather, we want to reuse the architecture, Agent interfaces, training pipelines, and evaluation methodologies, and then adapt the models and Agents for each new game.

I will cover five aspects: why game QA requires a reusable Agent architecture; how the Brain, Cerebellum, and Orchestration Layer work; core capabilities like instruction following, combat, and navigation; preliminary validation across three game genres and its relation to open research; and finally, current limitations and our engineering roadmap.

In game QA, test execution remains one of the most labor-intensive phases. Testers must run through levels, engage in combat, interact with UI, and repeatedly execute the same scenarios to collect evidence across different versions, maps, devices, and platforms. Traditional scripts and behavior trees are highly efficient and reproducible along deterministic, stable paths. However, they typically rely on game-specific hooks, requiring heavy maintenance overhead when versions change.

VLM (Vision-Language Models) brings another possibility: pure-pixel policies that can adapt to randomized scenarios, act on natural language instructions, and output standard keyboard/mouse controls without reading the game's internal states.

Our engineering goal is not to achieve zero-shot cross-game generalization with a single model. Instead, we aim to make the architecture and interfaces reusable across games, reducing the redundant automation work required from scratch for each new integration, thereby decreasing repetition, expanding coverage, and driving efficiency.

 

(From manual execution and traditional automation to a reusable game Agent architecture)

To evaluate the execution capability of this reusable Agent, we needed a highly challenging environment. Thus, we chose Black Myth: Wukong—a globally renowned, high-difficulty action game developed by Game Science.

We selected it because it contains real-time combat, long-range level progression, character progression systems, and UI interactions, all of which place extremely high demands on the Agent's execution. Our objective was to have the Agent autonomously complete Chapter 1. If it could achieve this in Black Myth: Wukong, we believed it would prove the transferability of these capabilities to other games.

The system's input consists of raw RGB screens and natural language instructions, and its output is standard mouse/keyboard actions. It does not invoke private Gameplay APIs, modify the client, or use any game-side interfaces. To be clear, this work is conducted strictly for controlled research and QA environments, and will not be used in player-facing interactive or competitive scenarios. It does not imply AI collaboration, co-development, official QA partnership, or any form of endorsement with Game Science.

 

(Black Myth: Wukong was utilized as an independent evaluation environment for the reusable Agent's execution capabilities)

As shown in the diagram, on the left is the Cerebellum, corresponding to System 1. It is a smaller execution model built for low latency and high-frequency control. It handles reactive tasks like instruction following and combat that require rapid reflexes and even frame-by-frame decision-making.

In the center is the Brain, corresponding to System 2. It handles visual comprehension and long-range planning: interpreting task intent, understanding the current game scene, planning the next move, and managing tasks requiring more structured reasoning, like navigation and GUI operations.

On the right is the Master Agent, responsible for orchestrating the overall flow, maintaining task states and memory, coordinating specialized Agents, and deciding when to hand off control between Agents.

The full pipeline is straightforward: the Master Agent dispatches tasks, the Brain observes, reasons, and issues instructions, and the Cerebellum executes them in real-time. This division of labor pairs the real-time responsiveness needed for gameplay with the planning and coordination required for long-range, end-to-end QA tasks.

 

(The division of labor among the Brain, Cerebellum, and Master Agent)

The Cerebellum uses a compact VLM as its backbone, taking RGB frames and natural language instructions as input, and outputting keyboard/mouse action sequences (Action Chunks). It features five key design points:

1. Compact Model: Reduces inference latency.
2. Three-Stage Training: Pre-training establishes general vision-action understanding; Supervised Fine-Tuning (SFT) aligns the model with game instructions; Reinforcement Learning (RL) improves performance in complex interactive tasks.
3. Pure-Pixel Inputs & Standard Outputs: Operates without reading internal game states.
4. Variable-Length Action Chunks: Outputs keyboard/mouse sequences of variable lengths, enabling quick reactions or long continuous actions depending on the scene.
5. Brief Reasoning Before Action: Thinks briefly when necessary before executing actions.

This structures three foundational capabilities: Visual Grounding, Instruction Alignment, and Reactive Control.

 

(Compact VLM, three-stage training, and variable-length keyboard/mouse action sequences)

For example, given an instruction like "Walk to somewhere and interact with a specific object." While simple for humans, this presents three hurdles for an Agent.

• First, Visual Comprehension: During training, we mix Visual Question Answering (VQA) data prior to trajectory SFT, allowing the model to learn to identify objects, landmarks, and spatial relationships in the scene.
• Second, Reasoning and Visual Grounding: Before moving, the model must locate the target, estimate its relative direction, and bind the natural language instruction to the correct visual region.
• Third, Low-Level Control: The model translates its judgment into a variable-length keyboard/mouse action sequence, enabling continuous character movement instead of stuttering after predicting each action.

Here are two examples: the same model, starting from nearly identical initial states, executes instructions in different directions and maps them to different landmarks. This comparison demonstrates that the policy generates actions dynamically based on instructions, rather than simply replaying fixed trajectories.

For QA, natural language tasks can be translated into reusable execution templates: testers only need to describe high-level goals, and specific in-game interactions are handled by the Agent.

 

(Visual understanding, CoT reasoning, and low-level control translate language intent into game actions)

SFT alone is insufficient to prepare a visual Agent for high-difficulty combat. Therefore, we built an automated Reinforcement Learning pipeline for Boss battles. We cold-start the policy with curated expert demonstrations to establish stable combat strategies through SFT. Subsequently, we harvest Boss battle clips, use a VLM to grade the trajectories, update the policy via RL, and evaluate it under repeatable conditions.

Our training set only used three high-difficulty Bosses from Chapter 1 of Black Myth: Wukong: Wandering Wight, Black Wind King, and Black Bear Guai.

Despite this limited training set, the RL-enhanced policy achieved exceptionally high win rates against unseen, high-difficulty Bosses. It generalized to Chapter 1 Bosses that were not part of the training set, as well as Bosses in later chapters: achieving a 90% win rate against Earth Wolf, and an 80% win rate against King Xiao and Second Prince of Flowing Sands.

 

(Expert demonstrations, SFT, automated RL loop, and evaluation results across 12 high-difficulty Bosses)

To our knowledge, these win rates are significantly higher than previously published results from comparable industry work. This indicates that the policy is not merely memorizing training trajectories, but has acquired transferable combat skills applicable to new Bosses in different chapters.

For QA, the goal is not to train an invincible player, but to construct repeatable combat testing workloads: allowing the same policy to repeatedly challenge the same Boss across different versions, observing changes in outcomes, which is useful for combat regression testing, balance checks, and build validation.

This allows gameplay and inference to run concurrently, preventing the game from pausing to wait for inference.

(The visual Agent battles autonomously across multiple Boss scenarios)

It is worth noting that when the duration of a QA task stretches from seconds to hours, navigation becomes significantly harder. A reactive policy can bypass immediate obstacles but does not necessarily know where it has been, where it is now, or how to return to previously visited locations.

To solve this, we systematically combined Visual Place Recognition (VPR), Visual Odometry (VO), and a Topological Memory Map.

The topological map does not geometrically reconstruct the full game world; instead, it abstracts key locations into nodes and represents passable paths between them as edges. VO estimates short-range relative displacements and poses from consecutive video frames without reading internal game coordinates. VPR matches the current screen with saved visual information in the map to help the Agent localize within the topological map.

During execution, the current frame enters both VPR and VO simultaneously, and the results update the memory map. The navigation graph selects the next target node and generates instructions, which the Cerebellum then translates into real-time keyboard/mouse inputs. This capability supports both point-A-to-point-B navigation and long-duration performance and stability tests.

(VPR, VO, and topological memory support long-range visual navigation)

To support end-to-end game execution, we adopt a multi-agent architecture to isolate capabilities, reducing task interference. The Master Agent interprets the initial natural language goal, plans the execution path, breaks the goal into sub-tasks, and dispatches them to specialized Agents: the Navigation Agent handles long-distance traversal, the Combat Agent manages frame-level combat actions, and the GUI Agent oversees interface interactions and flow progression.

Additionally, the Master Agent centrally maintains knowledge of game mechanics, interface states, and navigation routes.

As illustrated in the example on the right, a complete execution sequence is displayed: Wukong interacts with a shrine, travels a long distance, engages in combat to defeat Lingxuzi, and returns to complete remaining objectives. For QA, the critical value lies in enabling game progression, navigation, and GUI interactions to run unattended and repeatedly, automating complex testing scenarios that previously required continuous manual operation.

(Master Agent orchestrates Navigation, Combat, and GUI Agents to complete end-to-end flows)

---

 

Section 04: The Real Challenge is Scaling Up

The diagram below illustrates how our work relates to current open research and summarizes our preliminary validation results. Google DeepMind’s SIMA and SIMA 2 primarily demonstrate broad instruction following across diverse 3D environments. ByteDance’s Lumine focuses on long-range autonomous execution and cross-world migration.

Our work addresses complementary problems: reliable, frame-level control in commercial games, RL-based combat, and long-range execution. As preliminary proof, the system autonomously completed Chapter 1 of Black Myth: Wukong in approximately 9 hours.

Importantly, we reuse the same training pipeline across different games, though each game still requires dedicated SFT and RL tuning.

(Autonomously completing Chapter 1 in roughly 9 hours, and stage-wise validation of 4 major capabilities across 3 game genres)

Currently, this architecture has been applied to three game genres and four major capabilities. Instruction following and GUI operations have been validated across all three genres. Combat and navigation have been verified in Action RPGs and are currently being expanded to open-world ARPGs and FPS games.

Different capabilities employ different technical paths: combat leverages SFT and RL; navigation uses VO, VPR, and semantic topology; and GUI interaction utilizes RAG. These results should be viewed as preliminary evidence rather than a direct benchmark comparison.

Moving forward, we will prioritize resolving broader zero-shot generalization, quantifying integration efforts, and improving recovery robustness.

1. Cross-Game Migration is Not Fully Automated Yet: Different game genres and combat systems still require game-specific adaptation. The next step is to build genre-specific foundation models through large-scale pre-training, then reuse our game-specific fine-tuning methods.
2. Complex Tasks Require Deeper Understanding of Game Rules and Mechanics: Hence, we are constructing "Mechanics-aware Reasoning" capabilities based on structured game knowledge and RAG, allowing the Agent to make better decisions beyond simple visual recognition.
3. Long-Range Execution Accumulates Errors: A minor slip can ruin a task that has run for hours. This demands continuous monitoring, checkpoints, unified state management, and clear recovery strategies.
4. Reliable QA Requires Verifying Game Correctness, Not Just Completing Tasks: We are developing a Multimodal Test Oracle that combines game rules, telemetry, visual evidence, and temporal checks to support reliable Pass/Fail judgments.

(Cross-game migration, game comprehension, long-range stability, and test oracles remain four core challenges)

In conclusion, our takeaway is straightforward: what we have is a reusable architecture, not a silver-bullet, one-size-fits-all policy. After game-specific adaptation and validation, this system can transform highly manual gameplay execution into auditable QA evidence.

---

 

Section 05: Live Q&A Session

Q: Will the test results be used directly to train the Agent? Does the model itself get better, or do you only update the knowledge?

 Easons Ye: We do not modify the model itself. General models upgrade too quickly, so this architecture is designed to try different models and allows them to be replaced at any time. What we continuously update is the project-specific experience and Skill library, helping the AI understand the specific game better.

Q: So you are updating the test framework (harness) rather than the Agent itself? 

Easons Ye: Correct.

Q: Is there a unified benchmark to compare this approach against manual testing or traditional integration testing? 

Easons Ye: Because this is a very large architecture, it does not just focus on functional testing. We also use it for specific fields like balance, performance, and stability. We establish a Feature Map to scan the content in the game. After a version update, we use scripts and AI to walk through these features step-by-step. If discrepancies appear, we determine whether the version changed, the Skill failed, the action didn't execute, or the model had an issue. We analyze whether each feature coverage reaches 100% or 90%, identify where failures occurred, and continue to investigate the root causes.

Q: Will this method be combined with manual testing and conventional automation, or will it rely entirely on AI? 

Easons Ye: AI testing can generate reports, but the reports must be read by humans. AI can make judgments, but humans must ultimately verify the results.

Q: Part 2 seems to require supplementing game knowledge, but Part 1 apparently already did that. Will these two systems be combined? 

Vincent Gao: Yes. My part primarily solves game execution, whereas Easons' part covers the complete system from test case generation and game execution to validation. Once the execution module is fully mature, the two parts will be integrated.

Q: What specific problem does this system solve, and what impact has it delivered? How much testing, analysis, and engineering time does a 9-hour autonomous run save? 

Vincent Gao: Game execution is one of the most manual parts of game QA. If games can execute autonomously, it reduces manual effort. More importantly, we can support long-running stability and performance tests, which typically require games to run continuously for hours or even days to surface bugs.

Q: Is this currently used in production, or is it still in research/Proof of Concept (PoC)? 

Vincent Gao: The entire architecture is still in the research phase, but it is already being validated across multiple internal projects at Tencent. We hope validating this Agent will reduce a portion of manual execution.

Q: How much training data was prepared, and how long did it take to integrate the system into a game? 

Vincent Gao: We used approximately 120 hours of trajectory data for fine-tuning and about 50 hours of combat data for reinforcement learning. We also conducted multiple rounds of experiments, each taking about two days; after analyzing the results, we proceeded to the next round. The entire integration and development took about three months.