Midscene.js 性能优化指南先定位、再分层修复自动化脚本卡顿【免费下载链接】midsceneGUI Agent for E2E Testing项目地址: https://gitcode.com/GitHub_Trending/mid/midscene运行 Midscene.js 这类 AI 驱动的 GUI Agent 做 E2E 自动化测试时脚本卡顿往往不是单点问题截图传得多、模型响应慢、重复步骤不缓存时间会叠加成分钟级的等待。本文带你先定位脚本运行提速的空间在哪再按瓶颈逐层调整。 先找问题三步定位脚本卡顿点Midscene.js 每一步 AI 操作大致经过四个环节耗时基本都藏在这里截图与图像预处理每次动作前要截取屏幕压缩后转 Base64 再传给模型页面越大这一步越重模型调用延迟截图 Prompt 上传视觉语言模型网络往返和模型推理时间通常占单步耗时的最大头重复计算同一脚本重跑时未变化的定位aiLocate、查询aiQuery步骤会重新请求模型动作后固定等待每步执行完有默认的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.52 开始试。预期效果单步耗时随页面尺寸变化的斜率明显变平。2. 按任务复杂度选择模型症状简单定位也动辄几秒日志里模型响应时间远长于本地处理。原因模型调用延迟取决于所选模型家族与推理速度复杂模型并非所有步骤都需要。处理Midscene.js 通过环境变量配置模型见 模型配置定义# 按需指定模型与调用超时减少单次响应等待 export MIDSCENE_MODEL_NAME模型名 export MIDSCENE_MODEL_FAMILY模型家族 export MIDSCENE_MODEL_TIMEOUT30000思路是整条流水线用同一个快模型跑定位类步骤只有个别长文本理解步骤如复杂断言在代码里为该步临时切回强模型。预期效果定位类步骤的模型延迟下降总时长接近必要精度对应的下限。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 回归脚本场景优化前优化后主要手段单脚本完整跑 1 遍96 s68 s截图缩放 缩短等待连续重跑 5 遍合计480 s310 s任务缓存复用50 条数据的列表查询3 轮模型调用1 轮合并批量查询方法先记录一次基线耗时每次只改一层改完重跑同一任务确认下降来自哪一步避免多个变量混在一起无法归因。收尾整体思路就是先看报告定位耗时环节再按参数、模型、缓存、并发四层由浅入深地修每层只解决一类瓶颈。建议把基线耗时和关键步骤的耗时快照存档每次升级模型或改动脚本后重测一次把性能监控变成例行动作卡顿问题就能在放大之前被拦住。【免费下载链接】midsceneGUI Agent for E2E Testing项目地址: https://gitcode.com/GitHub_Trending/mid/midscene创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考
Midscene.js 性能优化指南：先定位、再分层修复自动化脚本卡顿
Midscene.js 性能优化指南先定位、再分层修复自动化脚本卡顿【免费下载链接】midsceneGUI Agent for E2E Testing项目地址: https://gitcode.com/GitHub_Trending/mid/midscene运行 Midscene.js 这类 AI 驱动的 GUI Agent 做 E2E 自动化测试时脚本卡顿往往不是单点问题截图传得多、模型响应慢、重复步骤不缓存时间会叠加成分钟级的等待。本文带你先定位脚本运行提速的空间在哪再按瓶颈逐层调整。 先找问题三步定位脚本卡顿点Midscene.js 每一步 AI 操作大致经过四个环节耗时基本都藏在这里截图与图像预处理每次动作前要截取屏幕压缩后转 Base64 再传给模型页面越大这一步越重模型调用延迟截图 Prompt 上传视觉语言模型网络往返和模型推理时间通常占单步耗时的最大头重复计算同一脚本重跑时未变化的定位aiLocate、查询aiQuery步骤会重新请求模型动作后固定等待每步执行完有默认的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.52 开始试。预期效果单步耗时随页面尺寸变化的斜率明显变平。2. 按任务复杂度选择模型症状简单定位也动辄几秒日志里模型响应时间远长于本地处理。原因模型调用延迟取决于所选模型家族与推理速度复杂模型并非所有步骤都需要。处理Midscene.js 通过环境变量配置模型见 模型配置定义# 按需指定模型与调用超时减少单次响应等待 export MIDSCENE_MODEL_NAME模型名 export MIDSCENE_MODEL_FAMILY模型家族 export MIDSCENE_MODEL_TIMEOUT30000思路是整条流水线用同一个快模型跑定位类步骤只有个别长文本理解步骤如复杂断言在代码里为该步临时切回强模型。预期效果定位类步骤的模型延迟下降总时长接近必要精度对应的下限。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 回归脚本场景优化前优化后主要手段单脚本完整跑 1 遍96 s68 s截图缩放 缩短等待连续重跑 5 遍合计480 s310 s任务缓存复用50 条数据的列表查询3 轮模型调用1 轮合并批量查询方法先记录一次基线耗时每次只改一层改完重跑同一任务确认下降来自哪一步避免多个变量混在一起无法归因。收尾整体思路就是先看报告定位耗时环节再按参数、模型、缓存、并发四层由浅入深地修每层只解决一类瓶颈。建议把基线耗时和关键步骤的耗时快照存档每次升级模型或改动脚本后重测一次把性能监控变成例行动作卡顿问题就能在放大之前被拦住。【免费下载链接】midsceneGUI Agent for E2E Testing项目地址: https://gitcode.com/GitHub_Trending/mid/midscene创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考
