传统游戏 QA 高度依赖人工测试人员反复执行游戏流程，这种模式在面对现代游戏的复杂状态空间时面临显著的效率瓶颈。一个开放世界的角色扮演游戏可能包含数万条任务线、数千个可交互对象和指数级组合的场景状态，人工测试难以在合理周期内覆盖所有关键路径。更关键的是，许多可玩性问题 —— 如难度曲线失衡、引导流程遗漏、边界条件下的交互异常 —— 往往在特定状态序列下才会暴露，而这些序列极难被人工测试计划预先覆盖。近年来，大语言模型（LLM）驱动的自主代理为这一领域带来了新的解题思路：通过构建能够感知游戏状态、规划长期行为、检测异常的自动化测试代理，可以在无需针对每个游戏进行专项训练的前提下，实现更广泛的状态空间探索和更高效的可玩性问题发现。
架构核心：四模块协同的测试代理
当前主流的 LLM 驱动游戏测试框架采用感知、推理、动作和诊断四个核心模块的协同架构。以 TITAN 框架为代表的研究表明，这种模块化设计能够在无需任务特定微调的情况下实现跨游戏的零样本泛化。感知模块负责将高维游戏状态转换为 LLM 可处理的结构化描述，这一过程通常涉及状态抽象 —— 将连续的数值数据（如角色坐标、生命值、资源量）离散化为有意义的状态桶，并提取与当前测试目标相关的关键信息。动作模块则维护一个预定义的动作模板库（如移动、对话、攻击、使用道具、探索等），通过动作优化层过滤掉在当前状态下不合理或低优先级的动作选项，从而将 LLM 的决策空间限制在可信范围内。推理模块采用长程记忆机制，使代理能够追踪多轮决策的执行历史，在遇到死锁或异常时回溯并重新规划。诊断预言机则实时监控代理的执行状态，检测崩溃、任务失败、状态异常等可测试问题，并生成结构化的缺陷报告供开发团队后续分析。
这种架构的关键优势在于其通用性：状态抽象和动作模板可以根据不同游戏类型进行适配，而核心的 LLM 推理能力则保持不变。这意味着同一个测试代理经过少量领域适配后即可用于测试不同风格的游戏，从回合制策略到即时动作冒险均可适用。
状态抽象的设计原则与参数选择
状态抽象是整个测试代理的感知基础，其设计直接决定了代理能否有效理解游戏并做出合理决策。在工程实践中，状态抽象通常遵循三个核心原则：相关性过滤、粒度平衡和信息压缩。相关性过滤意味着只保留与当前测试任务相关的状态变量 —— 测试战斗系统时关注生命值、攻击力、护甲值等属性，而测试经济系统时则关注货币存量、交易价格、物品数量等。粒度平衡要求在状态描述的精细程度和 token 消耗之间找到合适区间 —— 过于粗糙的抽象会丢失关键信息，过于细致的描述则会导致上下文溢出并降低推理效率。
具体实现时，连续数值通常采用分桶策略进行处理。例如，角色生命值可以映射为「满血」「中等」「低血量」「濒死」四个离散状态；角色坐标可以转换为所在区域标识而非精确数值。这种离散化处理不仅降低了状态描述的复杂度，还能使 LLM 更容易进行推理和决策。实践表明，将连续变量映射为三到五个语义化的状态桶是一个较好的起点，后续可根据测试反馈进行针对性调整。
另一个关键参数是历史状态的压缩方式。代理在执行长程任务时需要记忆过往决策，但将完整执行历史全部纳入上下文会导致 token 消耗急剧增长。常见的解决方案包括：只保留关键决策节点的状态快照、使用摘要方式压缩历史轨迹、以及设置记忆衰减机制淡化远期信息。实验数据显示，采用分层记忆结构的代理在执行超过二十步的测试任务时，其任务完成率比使用扁平记忆的代理高出约十五个百分点。
动作优化的工程化实现
动作优化层的作用是在每个决策点从所有可能的动作候选中筛选出最值得考虑的子集。这一步骤对于控制 token 消耗和提高决策质量都至关重要。原始的游戏引擎可能支持数百种动作（各种方向移动、技能释放、物品交互等），而 LLM 的上下文窗口和推理能力都无法有效处理如此庞大的候选集。
动作模板是实现动作优化的主要手段。开发者需要为特定游戏类型定义一组高层动作类别，例如角色扮演游戏通常包含移动、对话、战斗、物品交互、菜单操作等核心动作类别。每个类别下可以进一步定义具体动作，但这些具体动作在传递给 LLM 之前会经过初步过滤。例如，当代理处于战斗状态时，非战斗相关的动作可以被暂时排除；当代理处于探索状态时，攻击类动作的优先级可以降低。
实践中有两种值得关注的动作优化策略：基于规则的过滤和基于语义相似度的过滤。基于规则的过滤根据当前游戏状态直接排除明显不适用或危险的動作，例如当生命值过低时排除主动寻求战斗的动作。基于语义相似度的过滤则利用 LLM 本身的能力，在动作候选集中选择与当前任务目标语义最接近的动作子集。两种策略可以结合使用，规则过滤作为第一层筛选排除明显不合理的选择，语义过滤作为第二层筛选从剩余选项中聚焦与目标最相关的动作。
反思推理与长程规划
游戏可玩性测试的核心难点在于许多问题只在特定的状态序列下才会暴露。一个任务失败可能源于五分钟前的一个错误决策，代理需要具备回溯和重新规划的能力才能发现这类问题。反思推理模块正是为了解决这一挑战而设计的。
在实现层面，反思推理通常采用两类机制：显式回溯和隐式学习。显式回溯是指代理在检测到任务进展停滞或出现异常时，主动回顾历史决策，识别可能导致问题的关键节点，并尝试不同的行动路径。这种机制需要代理具备对自身执行历史的理解和分析能力 —— 不仅仅是记录做了什么，还要理解为什么某些决策导致了不良后果。隐式学习则通过在提示中加入策略指导来实现，例如在系统提示中写入「如果任务失败率超过阈值，分析最近五次决策中是否存在重复模式，并尝试打破该模式」之类的元策略。
长程规划的另一关键要素是目标分解。复杂的可玩性测试任务往往涉及多个子目标的完成顺序，例如「先获取任务物品 A，然后与 NPC B 对话，最后到达地点 C」。代理需要能够将这样的高层目标分解为可执行的中层动作序列，并在执行过程中根据状态变化动态调整计划。实践中发现，采用「目标 - 子目标 - 动作」三层结构的代理在处理复杂任务时，其任务完成率显著高于只有「目标 - 动作」两层结构的代理。
诊断预言机与缺陷报告
诊断预言机是测试代理与人工 QA 流程衔接的关键组件。一个有效的诊断预言机需要能够在代理执行过程中实时检测多种类型的可玩性问题，并生成结构化、可操作的缺陷报告。
常见的诊断类型包括：崩溃检测（通过监控进程退出码和异常日志识别）、任务失败检测（通过比对预期任务状态和实际任务状态识别）、时间异常检测（通过监控任务执行时间是否超出合理阈值识别）、状态一致性检测（通过检测游戏状态中的矛盾或不可能值识别）。每种诊断类型都需要定义相应的检测规则和阈值参数。
在缺陷报告的生成方面，理想的输出应包含以下信息：问题类型和严重等级、触发该问题的完整状态序列、问题发生时的游戏状态快照、代理的推理轨迹和决策依据、以及建议的复现步骤。这些信息对于开发团队定位和修复问题至关重要。实践表明，包含决策轨迹的缺陷报告的修复效率比仅包含状态快照的报告高出约百分之四十，因为开发人员可以理解代理为什么走到了导致问题的状态路径。
集成到 QA 流水线
将 LLM 驱动的测试代理集成到现有的 QA 流水线中需要考虑几个工程化要点。首先是任务调度：测试代理的执行时间通常远长于单元测试，需要设计合理的任务队列和超时机制。其次是资源管理：LLM 的调用成本和游戏模拟的资源消耗都需要纳入成本效益分析。第三是结果聚合：多个测试代理的缺陷报告需要统一归集、去重和优先级排序。
一个可行的集成模式是将测试代理作为持续集成流程的扩展组件。在代码提交后，自动化构建流程首先执行传统的单元测试和集成测试，随后启动测试代理执行可玩性测试任务。测试代理的缺陷报告通过统一的缺陷跟踪系统进行管理，并与人工测试的缺陷报告进行关联分析。这种模式可以在不显著增加人工测试负担的前提下，提高可玩性问题的发现效率和覆盖范围。
需要指出的是，当前的 LLM 驱动测试代理在以下方面仍存在局限：对于需要真实视觉反馈的图形渲染问题检测能力有限、对涉及多人交互的社交玩法测试覆盖不足、以及在极端边界条件下的行为可能不够稳定。这些问题需要结合计算机视觉模型、多代理协同框架和更鲁棒的异常处理机制来逐步解决。
资料来源：本文技术细节主要参考 arXiv 论文「Leveraging LLM Agents for Automated Video Game Testing」中描述的 TITAN 框架架构设计，以及 GitHub 开源项目 awesome-LLM-game-agent-papers 中整理的游戏代理相关研究综述。