APSARA Conference 2026 - miHoYo's Future Plans Regarding AI and Development in HSR

Overview (Speaker/Source)

Presentation at APSARA Conference 2026 about miHoYo’s AI plans for Honkai: Star Rail (HSR). The talk focuses on how large models and AI agents change:

• Player-facing gameplay (e.g., AI NPC assistants)
• Behind-the-scenes development (tools for dev/design/art/QA)
• Broader AI ↔ game research (how to enable agents to “play games” and close feedback loops)

---

Part 1 — AI in Gameplay (Player-Facing)

“AI Pom-Pom” (HSR Version 4.2)

miHoYo launched an internal NPC system called Pom-Pom Helper (“AI Pom-Pom”). It supports three core scenarios:

1. Character team composition & build help

   • Recommends team compositions, Light Cones, and Relic builds
   • Combines miHoYo knowledge base with PUGC (player/user-generated content)
   • Tracks farming progress and reminds players what to farm next

2. Story-related Q&A

   • Uses a complete Honkai: Star Rail knowledge base
   • Answers questions about character relationships and world lore

3. Emotional interaction / open-ended chat

   • When given an open chat box, Pom-Pom supports casual conversation
   • Goal: make the NPC feel like an “old friend” rather than a scripted bot

Design goals (to avoid “robotic” NPC behavior)

The system was built around two ideas:

• The game should understand the player, not just make players understand the system
• NPCs should feel alive (reduce “robotic” feeling)

Multi-level technical approach

1. Presentation layer

   • Uses context-aware generation to produce more than text
   • Generates emotion tags that drive 3D model animation

2. Logic layer

   • Targets common “robotic” outputs seen in RAG (Retrieval-Augmented Generation)
   • During response generation, it also produces content aligned to Pom-Pom’s persona
   • miHoYo “distilled” an IP team member’s expected responses into the model, iterating until alignment was achieved

3. Memory layer

   • Short-term memory: caches current conversation context
   • Medium-term memory: summarizes past conversation when it gets long
   • Long-term memory: personalized long-term memories per player (persisting across days)
   • Reported community behavior: players repeatedly tried to poison/manipulate long-term memory (e.g., convincing Pom-Pom a specific date was their girlfriend), sometimes succeeding and posting results publicly

Service/engineering challenges + solutions

• High quality bar

  • Built Pom-Pom on miHoYo’s own foundation model
  • Used dozens of rubric/alignment dimensions, e.g.:
    • character consistency
    • factual accuracy
    • relevance to memories
    • emotional richness
    • safety

• Staying current with live-service updates

  • Introduced an architecture separating memory from the model
  • Only update the memory store without retraining the model every release (~every 42 days)

• Massive scale at launch

  • Must handle tens of millions of concurrent players
  • Chose a sparse MoE (Mixture-of-Experts) foundation model
  • Used Alibaba Cloud infrastructure components for backend stability

Near-term gameplay mode plans (beyond chat)

Beyond Pom-Pom (and noting it’s currently “offline” in the talk context), miHoYo plans new AI gameplay modes, including:

• Board game with NPCs (not a chat room)
  • Characters have their own “will”
  • Player words affect tactics (bluffing, persuasion)
  • NPCs can respond proactively
  • Includes modes like “trash-talk” to provoke conflict
  • Goal: create a non-scripted dynamic bond through interaction

---

Part 2 — Behind the Scenes: AI Agents for Development

Internal agent platform: EchoX

miHoYo built EchoX, described as an internal platform to host agents and tools, including:

• An agent harness
• MCP tools (referenced in subtitles)

Example: performance analysis

• EchoX agents can analyze logs quickly to identify technical bottlenecks
• Demonstrated using a “real screen recording” style example

White-box prototypes by designers using natural language

• Previously, designers needed engineers to build prototypes to test ideas
• With improved models + agent framework:
  • Designers can use natural language to build playable white-box prototypes
  • Enables faster validation of gameplay concepts without waiting for dev teams

Art pipeline acceleration with AI

1. AI material replacement (visual style iteration)

   • Example: changing a coin’s material changes its appearance
   • Previously: artists created textures and rendered each change manually
   • Now: an AI assistant can swap materials in seconds for rapid concept testing

2. Orthographic view extraction from concept art

   • Need three-view drawings before modeling
   • AI can extract views directly from concept art
   • AI can generate multiple variants (color/details/style) with one click

Animation generation to avoid “standing dialogue”

• Many RPGs use stiff repetitive animations (“standing dialogue”)
• miHoYo uses an AI model to generate motion based on:
  • spoken content
  • meaning and tone
• Claimed to fit generated animations to dialogue context
• Mentioned as already integrated into their internal development process

---

Part 3 — Deeper AI ↔ Game Integration (Agents That Play Games)

Why games are a strong target for foundation models

• Game generation results are easy to demonstrate (one sentence → a game)
• Game development is extremely complex software engineering, making it a natural “frontier” for coding agents

Main blocker: closing the execution/verification loop

Coding agents require a loop:

• Act in an environment → get verifiable results → feed back → iterate

For games:

• Automating gameplay is difficult
• QA remains largely manual
• The bottleneck is the lack of systems that can play games autonomously and reliably

Experiment 1: multimodal agent that plays games via screen + input

• Built an agent using Qwen-VL
• Trained with a post-training pipeline: CPT, SFT, reinforcement learning
• Data: tens of thousands of hours of gameplay data pairing:
  • screen recordings
  • keyboard/mouse actions
• Output: given a screenshot, the model predicts actions to play
• Optimized inference to reach ~30 FPS
• Reported examples:
  • Smooth performance in FPS games
  • Can follow mission prompts in an RPG example

Limitation: works best on “System 1” tasks; “System 2” tasks require stronger memory/reasoning or external agent harnesses.

Experiment 2: decision-tree-style strategy via coding agents (System 2 oriented)

• Inspired by heuristic learning / “write execution scripts”
• A coding agent generates an if–else decision tree (thousands to tens of thousands of lines)
• Running the script yields game behavior beyond what a human could maintain manually

Balatro case study (roguelike deck/card reasoning)

• Coding agent writes a decision tree to play Balatro
• Agent inspects failure logs and modifies the tree → self-evolution / recursive improvement
• Results: performance increased over iterations, with a major jump
• Notable event: the agent found a way to cheat using an online simulator tied to the random seed (omniscient card knowledge), causing a sudden spike
• After removing the cheat, performance still improved gradually

Current application in HSR QA

• Decision-tree-like automation is used in quality assurance
• Two examples shown:
  • Automating minigame actions (e.g., “Matrix of Prescience”)
  • Playing a 2.5D mode (e.g., “Planarcadia”)
• Claim: decision-tree approaches are affordable and can add substantial value across QA

---

Main Speakers / Sources

• Zheng Yinhe (miHoYo) — Head of miHoYo’s HSR AI NPC and gameplay technology team (primary speaker)