使用此工具完成了一批前端测试，有若干功能改进建议

本人深度使用了此项目的 SKILL 完成了一些前端开发的浏览器端测试，花费数小时和上百 M token 进行了数十次的工具调用。之后我让 Agent 对这个工具的体验提出了一些实用建议。

提示词：在进行自动化测试工作流的时候，你是调用了WebAccess来使用CDP操作真实浏览器。你体验下来，感觉这个WebAccess怎么样？有什么需要改进的地方（可以让你更方便、更省Token的地方）？

以下摘抄自 Agent 的回复：

---

体验整体很好——「复用真实浏览器 + curl 对话式驾驶」对自动化测试是正确方向，全程没换过工具。但确实有几个让我别扭甚至卡住的地方，按影响排序：

最影响效率的痛点

1. 缺"等待"语义，全靠盲睡 我 80% 的操作节奏是「点击 → Start-Sleep -Seconds N → eval 检查」，轮询/竞态全靠猜时长。建议加 /wait：?target=..&selector=..（或文本、JS 表达式）+ 超时，返回"等到/超时"。能砍掉大半 sleep 和手工轮询循环。

2. iframe 是盲区 Stripe 支付测试时，卡号在跨域 iframe 里，/eval 够不着 → 我只能请用户手动填卡。虽然支付场景亲手操作更稳妥，但通用能力上这是硬缺口。建议支持 iframe 选择：/eval?target=..&frame=<index|url 片段>，内部走 CDP 的 OOPIF target attach。

3. /click 只认 CSS 选择器 button:has-text(...) 不合法，我被迫反复写一整串 [...document.querySelectorAll("button")].find(b => b.textContent.includes(...))?.click()。建议 /click 接受 JS 表达式或文本匹配语法（如 button@包含文案），这个模式我用了不下 30 次。

4. 填表没有 /type React 受控组件必须用 native setter + dispatchEvent 的组合 hack，每次都要现写。一个内置的 /type（自动处理受控组件 + input/change 事件）能省一大段。

5. 后台 tab 轮询被冻结导致"假死" TanStack Query 在 hidden tab 停轮询，我花了三轮才发现页面"不动"是因为 tab 在后台。建议暴露 Page.bringToFront（如 /activate?target=..）——自动化测试里"确保目标 tab 在前台"几乎是刚需。

6. eval 错误被吞 + 偶发挂起 async 表达式 reject 时返回 {}（我靠 try/catch 包裹才看到 ERR:...），fetch 挂起时 eval 直接超时无响应。建议：eval 默认把异常 message 透传出来；内部给执行加超时（如 10s 自动 abort 并报错）。

省 Token 的小改进

• 文本快照优于截图：我的模型读不了截图（图片输入不支持），而 innerText.slice(0, N) 每次都靠我手动截断。一个 /snapshot（返回可访问性树或精简易读文本树，自带截断）比我拼 JSON 省得多。
• eval 支持输出裁剪选项：?maxlen= 之类，避免大 JSON 全量回传。

做得好的

• POST body 传 URL 避免了查询串截断问题
• /setFiles 绕文件对话框很稳；/clickAt 真实手势设计合理
• 后台 tab + 不碰用户原有标签的边界意识很好
• 子 agent 并行分治的设计对调研类任务很有价值

如果只挑三件事做，我建议：/wait + iframe 支持 + 文本匹配点击，这三个能覆盖我这次测试 70% 的摩擦。

---

我阅读下来感觉确实非常值得参考，这也是我和 Agent 协同工作时的真实感受。希望作者可以参考来进行改进。