Midscene.js 脚本卡顿排查指南：四步定位慢操作并提速-开发者社区

Midscene.js 脚本卡顿排查指南：四步定位慢操作并提速

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

Midscene.js 性能优化的起点，是先把"慢"拆开看。这篇诊断笔记按"症状—定位—对策—验证"四步展开，带你完成一次完整的脚本卡顿排查：判断卡顿发生在哪一步、耗时集中在截图与图像分析还是模型响应、如何用缓存复用避免重复劳动，最后确认提速确实发生。

🩺 看症状：先判断你的脚本卡在哪一步

动手改代码之前，先对号入座。常见的卡顿表现有四种：脚本执行到某一步"挂住"，界面上没反应，几秒后才继续走下一步；同一条流程里，有的步骤一两秒就完成，有的却要六七秒，耗时差异很大；同一条脚本反复跑，总时长几乎不下降；跑着跑着进程内存持续上涨，后面的步骤越来越拖。如果中了前两条，问题多半在截图与模型环节；中了后两条，则要怀疑缓存和内存管理。

🔍 定位：一次自动化操作的耗时花在哪

一次自动化的时间基本被三块吃掉：

截图与图像分析。每执行一步，Midscene.js 都要截屏、压缩、把图像交给视觉模型解析，这是最大的消耗点。压缩链路在 packages/shared/src/img/transform.ts 里，截图越大，上传和解析越慢，截图性能直接决定单步耗时。
模型响应。同样的任务，轻量模型和重推理模型的返回时间可能差出数倍。
重复执行已知结果。同一个查询、同一个元素定位反复跑，如果结果没有落盘复用，每次都白付一次模型调用。

判断方法很简单：打开执行报告，按步骤看各自耗时。

上面这份报告里，每一步 Locate、Query、Action 的耗时都标在旁边，总时长 7.36s，时间主要花在模型调用密集的查询和定位步骤上——这就是典型的"第二块"耗时。

🔧 对策：按原因逐条处理

压缩截图并收窄分析区域

场景：整页截图尺寸大，上传和解析耗时都高。做法：截屏时降低质量（比如 80%）并限制最大宽度（比如 1200px），图像模块会按参数重压缩后再送模型；如果目标固定出现在页面某个区域，先做一次定位，只对关键区域做精细分析，避免整张图都过一遍。

合并单点查询为批量查询，按复杂度切换模型

场景：脚本里连续发出几十次单点aiQuery、aiLocate，每次都付一次完整调用成本。做法：让模型一次返回结构化数组，例如一次问"所有商品项"而不是逐个点名取数：

const items = await agent.aiQuery('页面上所有商品项[{name, price}]');

同时按任务分级选模型：简单点击、取数用轻量模型，复杂推理和长流程规划再切到能力更强的模型，成本和时间都能降下来。

给重复的表单填写开缓存

场景：同一套登录、填写、搜索流程被批量重复执行（回归测试、批量下单）。做法：给 Agent 配一个带显式 id 的缓存，策略可选read-only、read-write、write-only，配置校验逻辑见 packages/core/src/utils.ts：

const agent = new Agent(page, { cache: { id: 'login-form-fill', strategy: 'read-write' }, });

命中缓存的步骤直接复用结果，不再触发模型调用，这是缓存复用收益最大的一块。

分批处理大结果集并定时清理内存

场景：一次查询返回上千条数据，整体塞进内存处理，跑长任务时进程越跑越重。做法：把结果切成每批 100 条循环处理；对长时间运行的脚本，定期清理临时文件和缓存目录，防止内存和磁盘被慢慢吃满。

限制并发并开启性能监控

场景：多脚本并行、多模型调用同时打出去，出现排队和资源争抢。做法：给并发的模型调用设上限（比如 3），避免堆积；开启性能监控后，运行结束读取性能报告，逐步骤核对耗时与 token 消耗——Agent 层的用量汇总逻辑在 packages/core/src/agent/metrics.ts，报告里能看到每个意图和模型的调用次数。