一个AI能把游戏从头打到尾，很多人会顺理成章地觉得它已经具备了测试能力。爱游戏测试AI不这么看：通关和测试是两种目标完全相反的能力。通关Agent要的是又快又稳地走到胜利条件，路上会主动避开一切可能失败的分支；测试Agent恰恰要往那些分支里钻——装备栏溢出、任务状态冲突、存档读档之间的数值错位，这些普通玩家几乎不会主动触碰的角落。爱游戏为什么把“玩家Agent”和“测试Agent”分开说的就是这件事。
这个栏目关心的是自动游戏测试和游戏QA Agent怎样在真实项目里落地：测试机器人应该执行什么样的动作序列、遇到异常之后怎么判断这是不是BUG、怎么把一次偶发故障整理成可以复现的步骤，以及这套体系和爱游戏玩家AI、爱游戏AI大模型之间的边界在哪里。这里不承诺“自动化能发现一切问题”，AI测试可以承担真人测试员很难长时间坚持的重复探索，但替代不了真人的主观体验判断。
把一个擅长通关的Agent直接拿来做测试，最常见的问题是它会像玩家一样“绕开麻烦”：遇到卡视觉的角落就走开，遇到看起来无意义的操作就跳过。可是很多BUG恰恰藏在这些被绕开的地方。测试Agent需要一套不同的奖励设计：走到没人走过的状态比走到终点更值钱，触发一次异常比顺利过关更值钱。这也是爱游戏把玩家Agent和测试Agent分成两套目标、两套评价标准的原因，而不是给同一个模型换个说法。两套Agent甚至可以共用同一份地图和规则数据，区别只在于“走到终点”和“走到没人验证过的状态”，哪一个才是它的加分项。
普通玩家的操作大体是一条向前的路径；测试机器人更像是故意找茬：重复点击同一个交互点、在过场动画中途读档、把任务A做到一半再去接任务B、在资源耗尽的边界状态下切换装备。测试机器人应该像普通玩家一样玩吗？答案可能恰恰相反把这类探索策略拆得比较细：为什么要专门去撞边界、为什么要在中途退出，以及这些“反常操作”覆盖的其实是最容易被开发过程遗漏的状态组合。
假设一个测试脚本沿着一条很长的任务链持续运行了数小时，中途一切正常，直到某个不起眼的数值累积到某个临界点才出现状态错位——这类问题很难靠短流程复现，必须依赖持续记录的行动轨迹（Action Trace，即按时间顺序保存的操作与状态记录）。游戏测试机器人为什么最怕“跑了8小时以后才出BUG”讨论了状态覆盖和轨迹压缩：怎么在不无限增加日志体积的前提下，把出问题之前的关键几步提炼出来，变成可以直接交给开发的复现路径。
AI测试真正的难点往往不是探索，而是判断：角色穿墙一瞬间，是关卡设计允许的瞬移机制，还是不该发生的碰撞穿透？没有一套判断标准，再多探索也只是收集了一堆截图。测试Oracle（用来判断当前结果是否符合预期规则的判定层）需要结合关卡规则、任务状态和角色能力表来裁决。爱游戏为什么需要“测试Oracle”说明了这层判定为什么不能省略，以及规则库覆盖不到的模糊地带该怎样标注成“待人工复核”而不是硬判对错。规则写得太严格，会把设计师故意留下的“隐藏机制”误报成BUG；写得太宽松，又会漏掉真正的异常，这个尺度需要和关卡设计反复对齐，不是一次配置就能定死的。
一个关卡对新手太难还是对高手太简单，靠人工试玩很难覆盖足够多的组合。游戏平衡能不能让机器人先测？介绍了一种思路：用新手、普通、高手三种不同水平设定的AI玩家（Skill Agents）各跑若干轮，对比通过率和死亡位置的分布差异，把明显失衡的区域提前标出来，再交给真人设计师复核和调整，而不是拿机器人的结果直接当结论。假设某个区域里高手Agent和新手Agent的死亡位置几乎重叠，这通常提示问题出在关卡结构本身，而不是难度曲线；如果只有新手Agent频繁卡死，则更可能是引导信息不够，两种情况对应完全不同的修改方向。
测试Agent发现的异常状态，很多来自玩家真实行为里没被覆盖到的组合，这部分内容可以参考爱游戏玩家AI；而测试Agent需要的长期记忆和多模型协作方式，则在爱游戏AI大模型栏目有更完整的讨论。
会通关的AI很可能是一个很差的测试员。玩家Agent的目标函数是赢，奖励来自通关、得分和存活；测试Agent的目标函数是找问题，奖励来自新状态、异常信号和可复现的证据。前者会把路径收敛到最优，后者必须主动偏离：在过场动画里读档、边跳边切装备、重复开关同一扇门、中途退出任务。爱游戏的做法是把两类Agent拆开设计，测试Agent使用结构化状态加截图旁证的观察空间，动作空间里除了基础输入还包含存档、读档、切图、中断等游戏级动作，探索上采用状态覆盖、好奇心和目标导向的混合策略，并用崩溃、卡死、数值越界、状态不一致等信号触发记录。通关率高只能说明主路径健壮，不能说明测得好，还可能因为奖励信号鼓励利用BUG而虚高。机器人擅长夜间批量运行、海量重复与组合爆炸，乐趣、手感和公平感仍然要靠真人判断，两者的合理分工是让Agent产出带证据的异常清单，再由人排序确认。
有些BUG不会立刻触发，需要完成二十个任务、切几次地图、换过装备、存档退出再重进之后，在第二十一步才出错。对这类问题，测试机器人真正的价值不是报告“坏了”，而是告诉开发怎样稳定复现。爱游戏的设计思路是：全程保存行动轨迹，每一步记录地图、角色、状态、任务、装备、操作、时间顺序与随机种子；用“区域、任务阶段、装备组合”这样的状态抽象来定义覆盖，避免把无穷的原始状态当成目标；发现异常后，用二分和依赖分析把几千步的轨迹缩减为最短复现路径，再用固定种子和确定性回放验证；对随机性、网络与帧率造成的不稳定复现，则记录环境并给出复现概率。最终输出的是一份带前置状态、步骤、实际与预期、复现概率的简洁报告，而不是一段录像，并按“是否玩家可达、是否影响存档进度”排序去重。成本上以检查点、分段回放和增量记录控制，长程测试同样不能取代真人对体验的判断。
让测试机器人照着普通玩家的方式通关，只能验证“主流程没坏”，而大多数线上问题恰恰出在主流程之外。对抗式测试的思路是让机器人故意做奇怪操作，并按八类整理：异常顺序、边界区域、重复操作、中途退出、存档读档、任务冲突、装备切换、极端资源状态。每一类对应一批典型问题，比如状态没有回滚、任务标记残留、背包溢出、存档与场景不一致。但“奇怪”不等于“乱按”，纯随机输入的效率很低，所以要用目标导向的探索：给每个动作挂上它想触碰的状态，优先补覆盖不足的角落，并把每次动作记入轨迹以便复现。这种测试成本不低，需要预算和取舍，也不能替代真人对手感与乐趣的判断。
自动测试最难的一步往往不是“操作”，而是“判定”：测试Agent看到一个结果，怎么知道它是不是BUG。这个判定依据就是测试Oracle，即对预期行为的定义。爱游戏把Oracle分成几层：崩溃与卡死等通用信号、代码断言、始终应成立的不变量、来自设计文档与配置表的规则库、与旧版本对比的差分，以及由LLM根据规则和证据给出的辅助判断。层级越靠上越确定、误报越少，越靠下覆盖越广、越需要人工复核。LLM Oracle尤其要谨慎，它可能误报也可能漏报，必须附带可核对的证据，并进入人工复核。规则从哪里来、如何随版本更新，决定了Oracle能否长期可信。
平衡测试的目标是在真人试玩之前，先估计一个关卡对不同水平玩家意味着什么。爱游戏AI的思路是把测试写成一次实验：先提出假设，再构造新手、普通、高手三类Skill Agent，用反应延迟、动作噪声、信息可见范围和训练阶段来限制它们的能力，然后让它们在同一关卡中重复运行，读取通过率、资源消耗、死亡位置和策略分布。读数之后还要做解读：死亡集中在哪里，是数值问题还是提示问题，资源是否被单一打法垄断。这种方法的局限同样明确：机器人的策略与真人不同，测不出乐趣、挫败感和主观公平感，因此只适合做真人测试前的筛查和回归对照，不能替代真人。
请留下您的联系方式，我们会尽快与您联系。
