企业官网建设流程全解析

1. 从一局游戏录像说起：为什么"会玩"和"会测"是同一件事

第一次看到"Jev"这个代号，是在一个自动化测试交流群里。有人丢出一段录屏：一个智能体在模拟环境里反复尝试打开某个界面、点击按钮、读取状态，失败之后自己换了一条路径重来，最后把整个流程跑通了。群里有人开玩笑说，这玩意儿打游戏肯定也不差。我当时的第一反应是——这话其实说到了点子上。

DOOM 这类第一人称射击游戏，本质上是一个部分可观测、状态连续变化、动作有代价的决策环境。你看到的画面只是当前视角，敌人可能从背后出现，弹药有限，走错一步就要重来。而自动化测试面对的是什么？一个界面元素可能因为加载慢而暂时不可见，一个弹窗可能随机出现打断流程，一次点击可能触发异步请求导致后续状态不确定。这两件事在决策模型层面，几乎是同构的。

所以"Jev：从 DOOM 到自动化测试的 AI Agent 决策模型"这个标题，真正想聊的不是"用 AI 打游戏"这种猎奇话题，而是一个更硬核的问题：如何把游戏 AI 里那套"感知—决策—行动—反馈"的闭环，迁移到自动化测试这种工程场景里，让测试脚本从"死板的录制回放"进化成"会自己找路的智能体"。

这篇文章适合三类人看。第一类是做自动化测试、被脆弱脚本折磨过的工程师，你会看到为什么传统方案在复杂界面下必然失效。第二类是对 AI Agent 决策模型感兴趣、想找个具体落地场景的开发者，自动化测试是一个比打游戏更有商业价值的试验场。第三类是刚入门、想理解"智能体到底怎么决策"的读者，我会尽量用生活化的类比把原理讲透。

需要先说明一点：Jev 在这里我把它当作一个决策模型的设计思路代号来讨论，而不是某个具体开源项目的名字。下面的内容是基于"游戏 AI 决策 + 自动化测试"这个交叉场景，结合常见工程实践做的合理推演和方案设计。你完全可以把这套思路套到自己手头的测试框架上。

2. 拆解标题里的三个关键词：DOOM、自动化测试、决策模型

2.1 DOOM 场景到底特殊在哪

很多人以为游戏 AI 难在"反应快"，其实不是。DOOM 这类环境真正难的地方有三个。

第一是部分可观测。你的智能体只能看到当前视角的画面，地图的其余部分、敌人的位置、道具的分布，全都是未知的。它必须一边行动一边更新自己对世界的认知。这跟自动化测试里"页面只渲染了可视区域、DOM 树里还有大量懒加载节点"的情况一模一样。

第二是动作空间连续且带代价。移动、转向、射击，每个动作都会改变状态，而且有些动作是不可逆的（比如开枪消耗弹药、走进死胡同）。测试里也一样，一次提交表单可能就真的写入了数据，点错了删除按钮可能就回不去了。

第三是奖励稀疏。一局游戏打几分钟，可能只有最后通关才给一个正反馈。中间大部分时间智能体都在"瞎逛"。测试场景里，一个端到端流程可能十几步，只有最后断言通过才算成功，中间任何一步失败都拿不到有效信号。

理解了这三点，你就明白为什么简单的"如果 A 就 B"规则引擎在复杂场景下会崩——它没法处理不确定性，也没法从稀疏反馈里学习。

2.2 自动化测试的痛点，和游戏惊人地相似

我做过几年自动化测试，踩过的坑基本可以归成几类，你会发现它们和 DOOM 的难点一一对应。

传统方案怎么应对？加显式等待、加 try-catch、加各种兜底重试。这些手段本质上是用工程补丁去对抗不确定性，能缓解但治不了根。因为它们的决策逻辑是写死的，环境一变就得人来改。

而 AI Agent 决策模型的思路是：不写死路径，让智能体自己根据当前观测去选动作，失败了就调整策略。这正好是游戏 AI 几十年积累下来的东西。

2.3 "决策模型"不是"大模型"，别搞混

这里要澄清一个常见误解。一说到 AI Agent，很多人立刻想到大语言模型。但决策模型和语言模型是两回事。

语言模型擅长的是理解和生成文本，它能读懂"点击登录按钮"这句话是什么意思。但"在当前页面状态下，我应该先点登录还是先关弹窗"这种序贯决策问题，语言模型并不天然擅长，因为它没有内置的"试错—反馈—更新"机制。

Jev 这类决策模型的核心，通常是一个策略网络或者价值评估模块，它输入当前状态（页面截图、DOM 特征、历史动作序列），输出下一步动作的概率分布或者每个动作的预期收益。语言模型可以作为它的"感知前端"和"动作翻译器"，但决策本身靠的是强化学习或者搜索算法。

打个比方：语言模型像一个懂很多知识的顾问，能告诉你"登录一般要点哪个按钮"；决策模型像一个老练的操作员，能在具体局面下判断"现在这个弹窗挡着，得先关它"。两者配合，才是完整的智能体。

3. 决策模型的核心骨架：感知、策略、记忆、反馈四件套

3.1 感知层：把界面变成智能体能"看懂"的状态

智能体要决策，首先得知道"现在是什么情况"。这一步叫状态表征。

在 DOOM 里，状态可以是原始像素，也可以是提取后的特征（敌人距离、血量、朝向）。在自动化测试里，状态来源更丰富：

• 视觉信息：页面截图，用卷积网络或者视觉编码器提取特征
• 结构信息：DOM 树、可访问性树，转成图结构或者序列
• 语义信息：把界面元素用文本描述出来，交给语言模型编码
• 历史信息：过去几步做了什么、结果如何

我实测下来，纯视觉方案在界面变化大的场景下泛化更好，但精度不够；纯 DOM 方案精度高但一改结构就失效。比较稳的做法是融合：视觉给粗粒度定位，DOM 给精确坐标，语义给动作意图。三者拼成一个状态向量，喂给策略网络。

这里有个容易忽略的细节：状态要做归一化。不同分辨率、不同缩放比例下，同一个按钮的像素坐标完全不同。如果不归一化，模型学到的策略换个屏幕就废了。常见做法是把坐标转成相对页面的百分比，把尺寸转成相对视口的比例。

3.2 策略层：从"写死的 if-else"到"学出来的概率分布"

策略是决策模型的心脏。它要回答一个问题：给定当前状态，选哪个动作最好？

传统脚本是确定性的：if 元素存在 then 点击。策略网络是概率性的：输出"点击登录 0.7、关闭弹窗 0.2、等待 0.1"这样的分布，然后按概率采样或者取最大值。

为什么用概率而不是直接取最大？因为探索。如果每次都选当前认为最好的动作，智能体可能永远发现不了更优路径。就像测试时你总点同一个按钮，永远不知道另一条路是不是更快。概率采样让智能体有机会尝试"看起来没那么好"的动作，从而积累更全面的经验。

策略的学习方式主要有两种。一种是模仿学习：拿人工操作的录屏当示范，让模型学着模仿。上手快，但天花板受限于示范数据的质量。另一种是强化学习：让智能体自己在环境里试，根据结果好坏调整策略。上限高，但训练慢、样本效率低。

我的经验是先用模仿学习冷启动，再用强化学习微调。纯强化学习从零开始，在测试这种奖励稀疏的场景里，可能跑几万步都学不到东西。先用人工示范把基础策略带起来，再让它自己探索边界情况，效率高得多。

3.3 记忆层：为什么智能体需要"记住刚才发生了什么"

DOOM 里有个经典问题：智能体走进一个房间，转了一圈没找到出口，出来之后又走进同一个房间。因为它没有记忆，每次看到的都是"新"房间。

测试场景里同样的问题：智能体点了一个按钮没反应，等两秒又点一次，还是没反应，再点一次……它不知道自己已经点过了。或者它关了一个弹窗，刷新页面后弹窗又出现，它又去关，陷入循环。

解决办法是给智能体加记忆模块。最简单的是一张"已访问状态"表，记录去过哪些状态、做过哪些动作。复杂一点的是用循环神经网络或者 Transformer 维护一个隐状态，把历史信息压缩进去。

实操中我建议至少记录三样东西：动作历史（做过什么）、结果历史（每次动作后状态怎么变）、失败历史（哪些动作在哪些状态下失败过）。第三样尤其重要，它能帮智能体避开已知的死路，而不是反复撞墙。

3.4 反馈层：奖励怎么设计，决定了智能体学成什么样

奖励设计是决策模型里最考验功力的部分。设计得好，智能体自己就能找到正确路径；设计得差，它会学会一堆你意想不到的"歪招"。

测试场景的奖励可以分几层：

• 终局奖励：整个流程跑通，给 +100；中途崩溃，给 -100
• 过程奖励：每正确识别一个元素 +1，每触发一次有效状态变化 +2
• 惩罚项：重复动作 -1，超时 -5，非法操作 -10

这里有个坑我踩过：过程奖励给太多，智能体会刷分。比如它发现反复识别同一个元素就能一直拿 +1，于是原地打转。解决办法是给过程奖励加衰减，或者只在"首次达成某个子目标"时给奖励。

另一个坑是奖励和真实目标不一致。你希望它跑通业务流程，结果它学会了"只要不报错就行"，于是遇到问题就跳过。这时候要在终局奖励里加重惩罚，让它明白"跳过不等于通过"。

4. 把 DOOM 的打法搬到测试里：一次完整的决策流程推演

4.1 场景设定：一个带弹窗和异步加载的登录流程

假设我们要测一个登录流程，理想路径是：打开页面 → 输入账号 → 输入密码 → 点击登录 → 等待跳转 → 验证首页元素。但实际环境里有一堆干扰：

• 打开页面后可能弹出"隐私政策"弹窗，需要先关闭
• 账号输入框可能是懒加载的，需要等它出现
• 点击登录后可能弹出图形验证码
• 跳转后首页可能还在加载，需要等关键元素出现

传统脚本会写成一条直线，任何一步不符合预期就挂。智能体则要在这个环境里自己找路。

4.2 状态表征的具体设计

我设计的状态向量包含四部分：

1. 视觉特征：页面截图缩放到 224x224，过一遍轻量卷积网络，得到 128 维向量
2. 元素特征：当前可交互元素列表，每个元素用（类型、文本、位置、是否可见）四元组表示，最多取 20 个，不足补零
3. 历史特征：最近 5 步的动作和结果，编码成 64 维向量
4. 全局特征：当前 URL、页面标题、已耗时，编码成 32 维向量

四部分拼接成一个约 300 维的状态向量。这个维度不算大，普通全连接网络就能处理，推理延迟可以控制在几十毫秒，满足实时决策需求。

4.3 动作空间的定义

动作空间要设计得既够用又不冗余。太少了智能体没法完成任务，太多了学习难度爆炸。

我定义的动作集是这样的：

• click(element_id)：点击某个可交互元素
• input(element_id, text)：向输入框填入文本
• wait(ms)：等待一段时间
• scroll(direction)：滚动页面
• back()：返回上一页
• assert(condition)：断言某个条件成立

其中element_id是从当前元素列表里选的，text是从预置的测试数据里选的。这样动作空间是离散且有限的，策略网络输出一个固定长度的概率分布就行。

4.4 一次决策的完整链路

假设当前状态是：页面刚加载完，检测到一个"隐私政策"弹窗，登录表单被遮挡。

感知层输出状态向量，其中视觉特征显示有个半透明遮罩，元素特征里"关闭弹窗"按钮可见度最高。

策略层根据状态输出动作概率：click(关闭弹窗) 0.65、click(登录按钮) 0.15、wait 0.1、其他 0.1。

记忆层检查历史，发现"关闭弹窗"这个动作在当前状态下没做过，允许执行。

执行点击关闭弹窗，页面状态变化，弹窗消失，登录表单完全可见。

反馈层给这次动作 +2 分，因为触发了一次有效的状态变化（遮挡解除）。

然后进入下一轮决策，这次状态里登录表单可见，策略层大概率会输出input(账号框)。

整个流程就是这样一轮一轮推进的。每一步都不需要人写死"先关弹窗再登录"，智能体自己从状态里读出了这个顺序。

4.5 失败之后怎么恢复

真正体现决策模型价值的，是失败恢复能力。

假设智能体点击登录后，页面弹出了图形验证码。传统脚本到这里就挂了，因为它没预料到这一步。智能体则会：

1. 感知到状态变化（出现了新的图像元素）
2. 在记忆里搜索"类似状态出现过吗"，发现没有
3. 策略网络输出几个候选动作：wait、click(刷新验证码)、back
4. 尝试wait，发现验证码还在
5. 尝试click(刷新验证码)，验证码变了但还是需要输入
6. 最终识别出这是需要人工介入的环节，触发告警并保存现场

注意最后一步——智能体不是万能的，它要知道自己什么时候该求助。这比"硬着头皮乱点"有价值得多。我在设计时会给"触发告警"也设一个正奖励，鼓励它在确实无法处理时及时上报，而不是把环境搞乱。

5. 训练这套模型时，我踩过的五个坑

5.1 坑一：奖励稀疏导致智能体"摆烂"

最开始我用纯终局奖励，跑通 +100，失败 -100。结果训练了几万步，智能体学会了一个"最优策略"：什么都不做，等超时。因为随机乱点的期望收益是负的，而不动至少不会扣分。

解决办法是引入课程学习。先让它在一个简化环境里学（没有弹窗、没有异步加载），跑通率上来了再逐步加干扰。同时加过程奖励，让它每完成一个子目标都有正反馈。这样它才有动力往前走。

5.2 坑二：状态表征里混入了噪声

有段时间模型表现很不稳定，同样的页面有时能跑通有时不能。排查后发现是状态表征里包含了时间戳这个特征。不同时间跑，时间戳不同，状态就不同，模型学到的策略被这个无关变量干扰了。

教训是：状态表征里只放和决策相关的信息。时间戳、随机 ID、会话 token 这类每次都变的东西，要么去掉，要么做归一化处理。

5.3 坑三：动作空间里的"隐形陷阱"

我定义了一个scroll动作，本意是让智能体滚动页面找元素。结果它学会了无限滚动——因为滚动这个动作本身不扣分，而滚动之后状态会变，偶尔还能刷到过程奖励。

后来我给滚动加了限制：同一方向连续滚动超过 3 次就扣分。同时规定只有"滚动后发现了新的可交互元素"才给奖励。这样它就不会为了滚动而滚动了。

5.4 坑四：模仿学习的示范数据质量参差不齐

冷启动阶段我收集了一批人工操作录屏。问题是不同人操作习惯不一样，有人喜欢先关弹窗，有人喜欢直接点登录（弹窗会自动消失）。模型学的时候被这两种策略拉扯，学出来的东西四不像。

解决办法是对示范数据做筛选和标注。只保留"高效且成功"的轨迹，把那些绕远路、试错多的剔除掉。同时给不同轨迹打上质量分，训练时按质量加权。数据干净了，模型收敛快很多。

5.5 坑五：训练环境和真实环境不一致

训练时用的模拟页面是我自己搭的，元素 ID、加载速度都可控。部署到真实环境后，模型表现断崖式下跌。原因是真实环境的页面结构、网络延迟、渲染时序都和模拟环境有差异。

这是仿真到现实的鸿沟问题，游戏 AI 里也很常见。缓解办法有两个：一是域随机化，训练时故意随机化加载延迟、元素位置、页面尺寸，让模型见过足够多的变化；二是在线微调，部署后允许模型在真实环境里继续学习，慢慢适应。

6. 这套思路适合什么场景，不适合什么场景

6.1 适合的场景

不是所有测试都值得上决策模型。我总结了几条判断标准：

• 流程分支多、路径不唯一：比如注册流程有邮箱注册、手机注册、第三方登录多条路
• 环境动态性强：弹窗、引导、AB 实验频繁打断主流程
• 维护成本已经很高：脚本三天两头挂，人力都花在修脚本上了
• 有足够的试错空间：测试环境可以随便折腾，不会造成真实损失

满足这些条件的场景，决策模型的收益最明显。因为它擅长的就是"在不确定环境里自己找路"。

6.2 不适合的场景

反过来，这些场景用传统脚本更划算：

• 流程固定、环境稳定：比如纯接口测试，输入输出确定，没必要上智能体
• 对确定性要求极高：比如金融交易的核心链路，不允许任何"探索性"操作
• 样本极少：整个流程就跑几次，训练数据都不够，模型学不出东西
• 实时性要求苛刻：决策模型推理有延迟，毫秒级响应的场景扛不住

我的建议是混合使用：核心稳定流程用传统脚本保证确定性，边缘易变流程用决策模型兜底。两者不是替代关系，是互补关系。

6.3 成本收益的粗略估算

上一套决策模型，前期投入不小：环境搭建、数据收集、模型训练、调参，少说也要几周。但一旦跑起来，维护成本会显著下降。

我做过一个粗略对比：某业务流程有 30 个测试用例，传统脚本每月因为界面变动平均挂 8 次，每次修复平均 0.5 小时，一个月 4 小时。上决策模型后，模型自己适应了大部分变动，每月只需人工介入 1-2 次，约 1 小时。省下的时间一年就是几十小时，还不算因为脚本挂了导致漏测的风险成本。

当然这个账因团队而异。用例越多、变动越频繁，决策模型的性价比越高。

7. 从决策模型到真正的智能体，还差什么

7.1 自我反思能力

现在的决策模型大多是"反应式"的：看到状态，选动作，执行。它不会在失败后停下来想"我为什么失败"。

更高级的智能体应该有反思模块：一次流程失败后，回放整个动作序列，定位是哪一步导致了失败，然后把这条经验存进记忆，下次遇到类似状态时避开。这其实就是把强化学习里的"经验回放"和语言模型里的"思维链"结合起来。

7.2 工具调用能力

测试场景里，智能体不只需要点击和输入，还可能需要调用外部工具：查数据库验证数据、调接口准备测试数据、发消息通知相关人员。这些能力靠纯策略网络实现不了，需要给它接一个工具调用接口。

这也是当前 AI Agent 研究的热点方向：让决策模型不仅能选"点击哪个按钮"，还能选"调用哪个工具、传什么参数"。

7.3 多智能体协作

复杂测试场景可能需要多个智能体分工：一个负责准备数据，一个负责执行主流程，一个负责验证结果。它们之间需要通信和协调。

这块目前还比较前沿，工程落地案例不多。但思路是清晰的：每个智能体有自己的专长策略，通过一个协调器分配任务、汇总结果。

7.4 可解释性

这是工程落地最大的障碍之一。传统脚本挂了，你看代码就知道哪一步错了。决策模型挂了，你面对的是一堆权重和概率，很难说清它为什么选了那个动作。

解决办法是加决策日志：每次决策时记录状态摘要、候选动作、各动作的概率、最终选择、执行结果。出问题时回放日志，虽然不能完全解释，但至少能定位到是哪一步决策出了问题。再配合可视化，把状态和动作画出来，排查效率会高很多。

8. 给想上手的人的几条实操建议

如果你看完想自己试试，我给几条实在的建议。

第一，别一上来就搞强化学习。先用模仿学习跑通闭环，验证整个链路是通的。强化学习调参能调到你怀疑人生，没有闭环验证之前不要碰。

第二，状态表征宁简勿繁。我见过有人把整个 DOM 树序列化塞进状态里，维度几万，训练慢得离谱。先用手工特征，够用就行，不够再加。

第三，奖励设计要反复迭代。第一版奖励几乎不可能设计对，做好改十版的准备。每次改完观察智能体的行为，看它有没有学会奇怪的策略。

第四，一定要有兜底机制。智能体再聪明也会遇到处理不了的情况。设计好"什么时候放弃、什么时候告警、怎么保存现场"，比追求 100% 成功率更重要。

第五，从简单场景开始。别一上来就挑战最复杂的业务流程。找一个分支适中、干扰可控的场景先跑通，积累经验再扩展。

第六，记录一切。状态、动作、奖励、结果，全都记下来。训练不收敛的时候，这些日志是你唯一的线索。

最后分享一个我自己的体会：决策模型不是要取代测试工程师，而是把工程师从"修脚本"这种重复劳动里解放出来，去做更有价值的事——设计测试策略、分析测试结果、探索新的测试场景。工具越智能，人的判断力越值钱。这个方向值得投入，但别指望它一夜之间解决所有问题。