企业官网建设流程全解析

Midscene.js 性能优化指南：先定位、再分层修复自动化脚本卡顿

【免费下载链接】midsceneGUI Agent for E2E Testing项目地址: https://gitcode.com/GitHub_Trending/mid/midscene

运行 Midscene.js 这类 AI 驱动的 GUI Agent 做 E2E 自动化测试时，脚本卡顿往往不是单点问题：截图传得多、模型响应慢、重复步骤不缓存，时间会叠加成分钟级的等待。本文带你先定位脚本运行提速的空间在哪，再按瓶颈逐层调整。

📍 先找问题：三步定位脚本卡顿点

Midscene.js 每一步 AI 操作大致经过四个环节，耗时基本都藏在这里：

1. 截图与图像预处理：每次动作前要截取屏幕，压缩后转 Base64 再传给模型，页面越大这一步越重；
2. 模型调用延迟：截图 + Prompt 上传视觉语言模型，网络往返和模型推理时间通常占单步耗时的最大头；
3. 重复计算：同一脚本重跑时，未变化的定位（aiLocate）、查询（aiQuery）步骤会重新请求模型；
4. 动作后固定等待：每步执行完有默认的waitAfterAction等待时间，步数一多就被放大。

定位方法很简单：

• 查看运行报告：报告目录由MIDSCENE_RUN_DIR控制（默认midscene_run），报告里可以逐步查看每个 step 的耗时分布；
• 打开调试日志：设置MIDSCENE_DEBUG_MODE环境变量，核心工具模块输出的日志会打印各阶段耗时；
• 经验判断：如果单步耗时基本恒定在秒级，问题多在模型响应；如果耗时随页面尺寸增长，问题在截图链路。

🔧 按瓶颈分层修复

1. 先调调用参数：压缩截图、合并查询、缩短等待

症状：总耗时随页面大小和步数线性上涨，但每步操作本身并不复杂。原因：大图 Base64 体积大，上传慢、视觉 token 多；加上每步固定的动作后等待，慢点被逐步累积。处理：Agent 初始化支持screenshotShrinkFactor（截图送模型前的缩放因子，默认 1）和waitAfterAction（动作后等待毫秒数），参数定义见 行为参数模块：

const agent = new MidsceneAgent(page, { screenshotShrinkFactor: 2, // 截图缩到 1/2 再送模型，降低传输与 token 开销 waitAfterAction: 0, // 页面稳定时可去掉固定等待 });

另外，把多次零散的aiQuery合并为一次批量查询，能直接减少模型调用轮次。图像压缩底层由 截图处理模块 的constrainBase64ImageToMaxSize等函数完成，缩放过大可能影响小元素识别，移动端建议从 1.5～2 开始试。预期效果：单步耗时随页面尺寸变化的斜率明显变平。

2. 按任务复杂度选择模型

症状：简单定位也动辄几秒，日志里模型响应时间远长于本地处理。原因：模型调用延迟取决于所选模型家族与推理速度，复杂模型并非所有步骤都需要。处理：Midscene.js 通过环境变量配置模型，见 模型配置定义：

# 按需指定模型与调用超时，减少单次响应等待 export MIDSCENE_MODEL_NAME=<模型名> export MIDSCENE_MODEL_FAMILY=<模型家族> export MIDSCENE_MODEL_TIMEOUT=30000

思路是：整条流水线用同一个快模型跑定位类步骤；只有个别长文本理解步骤（如复杂断言）在代码里为该步临时切回强模型。预期效果：定位类步骤的模型延迟下降，总时长接近"必要精度"对应的下限。

3. 开启任务缓存与结果复用

症状：同一脚本每次重跑，未变化的定位、断言步骤照样消耗模型调用。原因：默认情况下每步都重新请求模型，缺少结果复用。处理：给 Agent 传cache: { id: '...' }，或在 YAML 场景启用MIDSCENE_CACHE，缓存处理逻辑在 缓存处理函数 的processCacheConfig中。命中缓存的步骤直接复用上次结果，不再请求模型：

const agent = new MidsceneAgent(page, { cache: { id: 'shop-flow' }, // 相同步骤签名命中后跳过模型调用 });

注意：页面结构变化会使缓存失效重算，这属于正常行为。预期效果：回归场景重跑时，稳定步骤的耗时从秒级降到接近 0。

4. 控制并发与内存

症状：并行跑多个脚本或跑大批量数据时，进程内存持续增长、偶发卡顿。原因：每步截图都是留在内存里的 Base64 字符串，报告和运行目录也会累积大文件，并发放大了一切开销。处理：把大任务分批串行提交（如一次 3 个脚本以内）；定期清理MIDSCENE_RUN_DIR下的历史运行报告；大批量查询结果分批处理而不是一次性保留。预期效果：内存曲线平稳，批量任务的尾延迟不再拖垮前面的任务。

✅ 优化之后要验证

拿一条固定脚本重跑对比，别凭感觉下结论。以下为一组示例数据（20 步的 Web 回归脚本）：

方法：先记录一次基线耗时，每次只改一层，改完重跑同一任务，确认下降来自哪一步，避免多个变量混在一起无法归因。

收尾

整体思路就是"先看报告定位耗时环节，再按参数、模型、缓存、并发四层由浅入深地修"，每层只解决一类瓶颈。建议把基线耗时和关键步骤的耗时快照存档，每次升级模型或改动脚本后重测一次，把性能监控变成例行动作，卡顿问题就能在放大之前被拦住。

【免费下载链接】midsceneGUI Agent for E2E Testing项目地址: https://gitcode.com/GitHub_Trending/mid/midscene