Jev决策模型：从DOOM到自动化测试的智能探索实践

我第一次看到 Jev 这个项目代号时，直觉告诉我它又是某个打游戏的强化学习 Demo。毕竟 DOOM 这种老牌 FPS 游戏，几乎每年都有团队拿来做 AI 实验。真正让我改观的，是他们把同一套决策模型从 DOOM 场景平移到了自动化测试，而且不是简单写几个用例，而是让 Agent 自己决定“下一步探索哪里、点什么、不点什么”。这套思路直接戳中我这些年做测试框架的痛点：录制回放太脆、断言写死太僵、覆盖率靠人肉补。如果你也在做自动化测试，尤其是被维护成本搞到头疼的回归测试，这篇内容值得你泡杯茶慢慢看。

1. 为什么一个打 DOOM 的 AI 会出现在自动化测试的讨论里

1.1 游戏 AI 与测试 Agent 共享的核心问题：状态爆炸与决策时延

先放下“AI 玩游戏”这个噱头，我们从问题本质看。DOOM 场景里，Agent 面对的是一张三维地图、若干敌人、随时变化的血量与弹药、需要开启的门和拾取物。如果把这个环境拆成状态空间，光是位置坐标乘以朝向角度就已经是天文数字，更别提敌人数量和弹道的随机性。自动化测试也一样：一个中大型产品的页面状态、组态组合、用户路径、数据状态叠加起来，穷举式覆盖在工程上根本不可能。两边遇到的其实都是同一个问题——状态爆炸，而解决它的关键不在“穷尽状态”，在于“下一步怎么决策”。

第二个共通点是决策时延。DOOM 里敌人不会站在原地等你，每帧之间你的策略都得算得够快，否则早被打成筛子。自动化测试里虽然没人拿枪逼你，但一条流水线的构建窗口只有那么长，Agent 如果每走一步要想十分钟，那它就只是实验室里的玩具。Jev 团队在 DOOM 里被逼出来的那套快速评估机制，反而是测试场景里最稀缺的能力：如何在几十毫秒内判断“这条分支值得继续探索”而不是“赶紧回去”。

1.2 Jev 这个项目的定位：不是“打游戏 AI”而是“决策模型”

我最初以为 Jev 是一个强化学习打游戏框架，后来仔细看它的设计才发现，DOOM 对它来说只是一个验证场。Jev 的核心是一个决策模型：给定当前可观测状态，结合历史探索记录与一组可执行动作，通过模拟搜索权衡短期收益和长期回报，最终输出一个动作序列。它可以被接进任何“离散动作 + 可观测状态 + 可定义奖励”的环境，DOOM 是第一个环境，自动化测试是第二个。

这里有个很重要的认知转变：打 DOOM 厉害不等于做测试厉害，但“学会在复杂环境里做决策”这件事是可以迁移的。DOOM 教会 Jev 的是——不要只看眼前一步，要往前推演几步，同时给每步留出不确定性余量。自动化测试中最不缺的就是“眼前一步”的脚本，最缺的恰恰是“往前推演几步”的探索策略。所以后面我们讨论的所有内容，都是围绕这个决策模型本身展开，DOOM 只是它的一张成绩单。

2. DOOM 场景中 Jev 的决策链路拆解

2.1 从像素、位置、弹药到状态表征：它到底在看什么

很多文章讲游戏 AI 上来就谈“像素输入”，好像 Agent 真的在用眼睛看画面。实际情况是，Jev 采用的是一种混合状态表征：底层保留原始画面信息，但与此同时，从引擎侧提取一批高层语义特征打包进观测。比如玩家当前位置被离散化到一张网格图上，朝向被量化为八方向，血量、弹药、当前武器、附近敌人数量、最近敌人距离、可交互物体优先级等，都会被编码成一组紧凑向量。这比纯像素输入更利于决策，也更方便跨环境复用。

这个设计对自动化测试有直接的启发意义。测试 Agent 面对 Web 页面时，完全没有必要把整个 DOM 序列化成几十万字的文本喂给模型。我们应该做的是提取跟“下一步决策”相关的语义特征：当前路由、页面上哪些按钮可见且可点击、表单字段是否为空、异步请求是否完成、是否存在 toast 或弹窗、当前 URL 与预期路径的偏差。把这些特征编码成状态向量，决策模型才知道自己在哪、能干什么、有什么潜在风险。DOOM 的网格图就像是测试里的页面结构树，敌人距离就像“这个按钮触发危险操作的可能性”。

2.2 决策不是“选一个动作”，而是“选一个策略”：蒙特卡洛树搜索与策略网络的配合

Jev 决策链路中值得一提的不是“神经网络输出了动作”，而是它把动作选择拆成了两层。第一层是廉价的策略网络，用来快速给当前状态打分、推荐 3 到 5 个候选动作；第二层是蒙特卡洛树搜索，对这几个候选动作往前推演若干步，模拟不同选择可能通向的后续局面。这种“网络给方向 + 搜索给精度”的搭配，既控制了计算量，又把决策质量拉上去了。

有个细节很多人会忽略：蒙特卡洛树搜索在推演过程中不是每次都展开所有子节点，它靠 UCB 公式平衡“探索”和“利用”——前期多尝试没走过的分支，后期多走评估收益高的分支。这正好对应自动化测试里的一个核心矛盾：回归测试要覆盖所有新旧功能，但又不能把时间全花在价值很低的重复路径上。Jev 式的策略让 Agent 在有限预算内自动权衡“应该再点一遍登录流程”还是“去翻翻昨天刚改的那个设置页”。

2.3 奖励塑形：把“活下来”翻译成测试里的“通过用例”

DOOM 的原始奖励很简单，杀一个敌人给分，被敌人打了扣血，找到钥匙开门算进度。但直接把这个奖励投入到训练里，Agent 很容易变成“莽夫”：看到敌人就冲，根本不管血量，因为击杀带来的即时收益远大于血量损失。Jev 的做法是做奖励塑形，给互斥目标设置合理权重，并且把“存活”和“清图”拆成两组阶段性奖励。

迁移到测试场景时，这套奖励塑形思维特别有用。如果 Agent 的目标仅是“找到 bug”，它很容易学会制造错误：往输入框里塞超长字符、疯狂触发重复请求、甚至故意中断流程，最后确实“找到”了一堆问题，但这些问题根本不是真实用户会遇到的。而如果我们把奖励设计成“完成一条用户主路径 + 覆盖一个未访问分支 + 保持资源消耗在预算内 + 发现异常时给予额外奖励”，Agent 的行为才会收敛到“像人一样遍历产品，顺带发现异常”。

3. 从 DOOM 迁移到自动化测试：需要做的三件事

3.1 划清边界：哪些决策能力能平移，哪些必须重写

我见过太多人拿到一个游戏 AI 框架就想直接套在业务测试上，结果撞得头破血流。Jev 的参考意义在于它明确画了一条线：决策引擎、探索策略、奖励计算框架可以平移，但状态编码、动作定义、风险约束必须重写。DOOM 里的“移动一格”在测试里可能对应“点击提交按钮”，DOOM 里的“射击命中”在测试里可能对应“断言元素出现”——语义不同，但“选定一个动作 → 执行 → 观察 → 评估收益”的闭环是一样的。

另外，测试场景中必须重写的还有安全约束。游戏里惩罚 Agent 的是血量，测试里惩罚 Agent 的是“污染了线上数据”“消耗了太多测试额度”“触发了不可逆流程”。这意味着你在迁移决策模型时，必须预留一层“动作防火墙”——在 Agent 输出动作之后、真正执行之前，对这步操作做一次风险分类。比如某些面向支付、删除、批量操作的按钮，在非隔离环境下一律禁点。Jev 在 DOOM 里靠奖励塑形学到的保守策略，在测试里还得靠硬约束来兜底。

3.2 测试场景建模：把页面状态当作游戏帧

想跑通这套模型，第一步就是把测试目标体系化建模。建模的核心是定义清楚“当前测试进行到哪一步、还剩下什么可选操作、哪些操作有副作用”。我建议团队先用一个简单的元组来描述测试状态：

• 当前页面唯一标识（路由或组件树指纹）
• 可见可交互元素列表（每个元素包含类型、文案、风险等级）
• 已完成的关键操作序列（用于回溯和路径记录）
• 最近一次断言结果与环境异常标志
• 当前累计执行时间与剩余预算

这套元组就是测试 Agent 的“游戏帧”。DOOM 的每一帧渲染的是画面，测试的每一帧渲染的是产品界面与上下文的压缩摘要。关键是把状态做得“够决策用但不要太大”，否则 MCTS 的每次模拟都要背着全量 DOM 跑，性能会非常难堪。

动作空间也不宜过细。DOOM 里你不需要让 Agent 精确控制鼠标移动的每一个像素，测试里也不需要让它做 2000 个元素的自由点击。我把动作空间分成四类：点击主操作、填写关键表单、导航跳转、断言校验。每个动作带上参数和前置条件。这样 MCTS 才能在一个可控范围内做推演，而不是面对爆炸式的操作组合。

3.3 探索策略复用：用“搜索 + 评估”替代“录制回放”

传统自动化测试的逻辑是：人类定义好步骤，机器按步骤执行。这套逻辑的脆弱性不用我多说，产品稍有改版，选择器失效、流程中断。Jev 带来的新逻辑是：人类定义好目标和边界，Agent 自己决定路径，机器边执行边评估。这是“搜索 + 评估”的思路，而不是“录制 + 回放”的思路。

具体到实现上，我建议先别一上来就跑复杂模型。可以把 MCTS 的模拟策略换成很简单的规则：每次从当前状态随机选 5 条历史高收益路径，各往前推演两层，挑综合收益最高的一条执行。这个极简版本已经能覆盖很多“录制回放”做不到的场景，比如页面改版后按钮位置变了，但 Agent 通过搜索依然能找到相近功能的入口。等这套链路跑稳了，再逐步换成策略网络来指导候选动作生成。

4. 一个可以上手的演示：给回归测试套上 Jev 式决策层

4.1 最小闭环：先做一个“探索式冒烟测试”Agent

理论聊太多容易飘，落到代码上才踏实。我拿一个模拟的订单管理后台来做演示，环境里故意注入了几个“隐藏缺陷”：某个删除按钮在特定数据状态下会触发布局错乱，某个详情页只有在连续点击三次后才出现加载失败。传统冒烟测试脚本大概率发现不了这类问题，因为它们按固定路径走。而一个 Jev 式 Agent 可以在探索预算内自然撞到这些异常。

先定义最小闭环：

1. 初始化 Agent，获取初始页面状态。
2. 对当前状态做动作候选生成（含随机探索项）。
3. 对每个候选动作执行影子模拟，预估收益。
4. 选择最优动作，在真实浏览器环境执行。
5. 观测执行结果，更新状态缓存与奖励累计。
6. 判断是否达到终止条件（预算耗尽 / 发现异常 / 关键路径完成）。

这个闭环跑通之后，再加 MCTS 的推演深度。一上来就把搜索树做深，只会让执行时间爆炸，什么都验证不了。

4.2 状态编码、动作空间与奖励函数的最小实现

这里我直接给一段简化版的伪代码，方便对照落地：

class TestState: def __init__(self, route, elements, status_flags): self.route = route self.elements = elements # [(element_id, risk_level), ...] self.status_flags = status_flags # {"toast": False, "error": False} def encode_state(state): # 把状态压缩成向量，供评估函数使用 route_vec = hash(state.route) % 1024 elem_vec = tuple(sorted(e["risk"] for e in state.elements)) flag_vec = tuple(int(v) for v in state.status_flags.values()) return (route_vec, elem_vec, flag_vec) def candidate_actions(state): actions = [] for elem in state.elements: if elem["risk"] <= 1: # 低风险动作优先探索 actions.append(("click", elem["id"])) if elem["type"] == "input": actions.append(("input", elem["id"], "random_text")) # 加入随机探索动作 actions.append(("navigate", random_neighbor_route())) return actions[:6] def simulate_step(state, action): # 影子模拟：不真实点击，而是根据状态转移表估算下一步 if action[0] == "click" and action[1] in risky_actions: return -1.0 # 高风险操作，收益为负 new_route = predict_route(state.route, action) new_flags = predict_flags(state.route, action) reward = 0.2 if new_route not in visited_routes else 0.0 reward += 0.5 if new_flags.get("error") else 0.0 return reward + 0.1 * stable_estimate(state.route, new_route) def mcts_select(state, budget=500): for _ in range(budget): action = random_choice(candidate_actions(state)) total_reward = simulate_step(state, action) if total_reward > best_reward: best_reward, best_action = total_reward, action return best_action

这段代码很粗糙，但骨架是对的。重点在于candidate_actions要有上限、simulate_step不能调用真实浏览器、奖励函数要把“新覆盖率”和“异常发现”放在同一位面比较。真实环境里，我们可以把predict_route换成基于 DOM diff 的快速推断，或者干脆维护一个状态转移记录表，用历史频率来预测下一步。

4.3 实测效果与常见偏差

我用这个极简 Agent 跑了三组冒烟任务：一组是固定脚本路径，一组是纯随机点击，一组是 Jev 式搜索决策。结果符合预期但过程很有意思。固定脚本的覆盖率很低，纯随机点击的覆盖率高但大量动作落在无用元素上，执行时间比 Jev 式高出 80%。Jev 式 Agent 在同样预算下，访问到了两个没有脚本覆盖的隐藏路由，并且触发了那个“点击三次后加载失败”的缺陷。

但有个偏差必须提醒所有人：在最开始版本里，我给的“发现异常”奖励权重过高，Agent 学会了刻意重复点击同一个按钮，因为它发现这样最容易触发加载失败。这个行为在产出端确实发现了 bug，但它完全歪曲了测试语义——真实用户不会对同一个按钮狂点十几下。后来把“动作多样性”也纳入奖励，并给重复动作加了衰减系数，行为才回到正常探索模式。这个坑就像是 DOOM 里学会了“角落蹲杀”的 Agent，技巧很现实，但不是你训练它时想要的。

5. 把这套模型真正放进测试流水线时，我踩过的几个坑

5.1 奖励函数写得太“正确”，Agent 反而不会动了

设计奖励函数时，很多人会把所有想要的指标全部塞进去：覆盖率、缺陷发现数、执行速度、页面稳定性、数据准确性，应有尽有。出发点是让 Agent“全面发展”，实际操作中它却变成了“无头苍蝇”——每一步动作都被无数目标牵制，搜索树的评分差异被拉平，最后 Agent 只能频繁选择“看似安全但毫无价值”的动作。我的经验是，奖励函数必须分主次：一个阶段只负责一个主目标，其他目标作为硬约束。主目标是“探索未覆盖路径”，那么覆盖率权重占大头，速度与风险只做阈值控制；等到探索稳定了，再切换到“发现异常”为主目标。

另外，奖励函数里的每一项都需要做归一化。把覆盖率提升设定为 0.1，把异常发现设定为 5.0，看似明确了“发现 bug 更重要”，实际上会诱导 Agent 只为拿那 5 分而行动。比较稳妥的做法是：异常奖励只在“附带出现”时生效，不作为主要驱动力。换句话说，Agent 的主线任务是“像一个有经验的人一样走完产品”，异常是探索路上的“彩蛋”，而不是它追逐的目标。

5.2 决策时延被低估：DOOM 的 16 毫秒与测试的几秒不是一个量级

在 DOOM 里，Agent 的决策必须跑在帧间隔内，慢了就挨打。我最初想当然地以为，测试环境里页面加载都要好几秒，Agent 的决策再怎么慢也无所谓。这个认知差点毁了项目——实际上，MCTS 的每次“模拟”如果不经过优化，会频繁触发候选动作的真实执行。一次真实点击带来的页面渲染、网络请求、数据库写入，动辄就要 2 到 5 秒。如果每轮决策要评估 500 条候选路径，每条路径都要真实执行，那这一轮下来就是几十分钟。

解决思路是分层降级：真实环境只执行最后选定的那条动作，评估阶段的模拟全部走“影子路径”。影子路径不做真实渲染，只用 DOM 变更预测、接口状态表、历史行为统计来估算收益。只有影子评分最高的两三个动作，才在真实浏览器里执行确认。这样决策时延就被压到可接受范围，整个回归流水线的吞吐量保住了。

5.3 观测噪声处理：DOOM 的完整帧 vs 测试里的脏状态

DOOM 的画面数据相对干净，同一位置看到的东西基本一致。测试环境完全不一样：有加载动画、有延迟渲染的异步组件、有 A/B 实验导致的元素差异、有本地缓存造成的页面跳变。Agent 在执行一次点击后，抓到的“下一帧”可能处于中间态——按钮还没渲染出来、请求还没返回、loading 遮罩挡住了所有元素。如果直接把这种脏状态喂给决策模型，奖励函数会计算出完全错误的收益方向。

我给这套流程加了两层处理。第一层是状态对齐，任何动作执行后，先等待关键元素稳定，再做状态快照。等待不能固定时间，要看网络空闲与 DOM 稳定。第二层是状态缓存，把同一路由、同类型操作的历史状态结果存下来，当出现瞬时脏状态时，用缓存修正当前观测。这两层叠加之后，Agent 对环境的“错觉”大幅减少，决策质量才算是真正稳定下来。

6. 决策模型之外：Jev 这套思路真正值得带走的东西

6.1 可解释性：从“为什么点这个按钮”到“为什么探索这个分支”

很多人对比传统脚本和 AI Agent 时，最担心的不是覆盖率，而是“不可解释”。脚本里点的每一个按钮都有代码依据，AI Agent 的随机探索像个黑盒。Jev 式的决策模型有一个天然优势：MCTS 的搜索树本身就是一张决策记录。你可以随时查看一个动作为什么胜出——它被选了哪些后续状态、预期收益是多少、探索次数和利用得分各自是多少。这些信息足以支撑测试报告中的“行为解释”。

实际操作中我养成了一个习惯：让 Agent 每隔 50 步输出一次当前搜索树的剪枝摘要，把“被评估为高收益但最终放弃的分支”也记录下来。这些记录在定位问题时价值极大。比如有一天 Agent 报告覆盖了某个页面 80% 的功能，但从剪枝摘要里能看出某个分支被反复评估又反复放弃，原因是该分支入口按钮风险等级过高。这个信息对我们优化产品导航很有帮助，等于把 Agent 的探索经验变成了产品洞察。

6.2 离线评估：先让 Agent 在“录像”里跑，别急着上生产

大家在测试圈听过“录制回放”，但未必听过“离线评估”这个玩法。Jev 在 DOOM 中的应用有一点非常讲究：在把新策略部署到真实测试流水线前，团队会用历史录制的游戏片段重放给 Agent，让它“脑补”如果当时走了另一条路会怎样，但不实际影响环境。这个思路完全可以平移过来。我们团队把近半年的真实用户会话记录、历史接口调用日志、页面变化事件存成离线语料，然后让 Agent 在这些数据上做“虚拟决策”，评估策略调整后的收益变化。

这样做的好处是，你可以安全地试各种奖励参数和探索策略，不用怕污染测试环境。有一次我们把探索率从 0.1 调到 0.3，在离线评估里发现覆盖率确实提升了，但高风险操作触发频率也涨了 4 倍，还好没有直接上生产，否则测试环境的数据会乱成一锅粥。离线评估不能完全替代真实验证，但它是低成本试错的第一道防线。

6.3 人的位置：让 Agent 做探索，让人做仲裁

最后想聊聊人的定位。Jev 这套东西上线后，我们团队最焦虑的是“测试工程师会不会被替代”。实际跑下来发现，焦虑完全是多余的。Agent 最擅长的是做海量探索、覆盖路径、寻找异常，但它在“判断一个缺陷是否值得修复”“区分产品 bug 和测试环境配置问题”这些环节上，经常给出荒谬的结论。这个时候需要一个有经验的人来做仲裁。

所以我建议把测试流程设计成人机循环：Agent 负责产生候选问题和探索报告，工程师负责审核与仲裁，再把仲裁结果反馈给 Agent 作为奖励信号的修正。我们内部的口径是：Agent 是会快速打草稿的实习生，人是审稿的主编。DOOM 里 AI 可以直接负责击杀，因为“敌人出现就打”的语义足够明确；测试里则不是，很多语义依赖业务上下文，必须人来把住最后一关。

我个人在实际跑这套模型之后最大的体会是：不要神化 AI Agent，也别固守录脚本的老路子。Jev 真正让我服气的不是它打游戏时表现多好，而是它给了我一个可拆解、可解释、可工程化的决策框架。今天你甚至不需要复刻它的全部实现，只需要把“状态表征 + 搜索推演 + 奖惩反馈”这个闭环借鉴过来，重新套到自己的测试体系上，就能实实在在缓解维护痛点。后面我还会继续做一件事情：给这套决策模型配上更细粒度的动作防沉迷机制，让它既能保持探索锐度，又能守住风险边界。如果你们也有类似项目的坑和心得，非常欢迎交流。