xiaohack's Blog - Playwright
type: channel
link: https://blog.xiaohack.org/tag/playwright/
items: 进阶指南：BrowserUse + AgentRun Sandbox 最佳实践
items: 二开 gemini 自动验证程序
items: Skills 与延迟加载工具定义的 MCP，目前哪个更高效、稳定和可控？
items: 快速上手：LangChain + AgentRun 浏览器沙箱极简集成指南
items: Tiktok 用户主页 视频 和 评论 爬虫，基于Python selenium 库 和 playwright库两种方式。
items: Linky：基于 AI 的自动化外链发布工具
items: [分享] from windows to wsl2 我的 cc,codex,opencode 迁移记录
items: 【分享】AI 自动化测试方案
items: 为什么不一定需要 debugger 做浏览器控制?

进阶指南：BrowserUse + AgentRun Sandbox 最佳实践
type: item
date: 2026-01-26T15:07:57+08:00
description: 作者：辰泉提示：本文是 AgentRun Browser Sandbox 快速上手实践指南的姊妹篇，专注于高级集成方案、生产环境的最佳实践、性能优化和部署策略。如果您还没有完成基础学习，请先阅读《快速上手：LangChain + AgentRun 浏览器沙箱极简集成指南》。前言在完成了 Browser Sandbox 的基础集成之后，本文将介绍高级集成方案（如 BrowserUse 框架）以及生产环境部署需要考虑的因素：如何管理 Sandbox 生命周期？如何优化性能和成本？如何保证系统的安全性和可观测性？本文将为您提供全面的高级应用和生产环境最佳实践指南。基于 BrowserUse 集成 Browser Sandbox效果截图BrowserUse 是一个专门为 AI Agent 设计的浏览器自动化框架，支持视觉理解和智能决策。通过 AgentRun Browser Sandbox，您可以让 BrowserUse 在云端运行，享受 Serverless 架构的优势。BrowserUse 架构概览下图展示了 BrowserUse 与 Browser Sandbox 的集成架构：架构特点：智能决策循环： Agent 通过 LLM 分析页面截图，基于视觉理解生成操作指令，执行操作后继续循环，直到任务完成无头浏览器控制： 通过 CDP 协议远程控制云端浏览器，Playwright 作为底层驱动，所有操作在云端执行实时可视化： VNC 提供实时画面监控，方便调试和验证 Agent 行为快速开始安装依赖pip install browser-use python-dotenv agentrun-sdk[playwright,server]主要依赖说明：browser-use：BrowserUse 核心库，支持多模态 LLMagentrun-sdk[playwright,server]：AgentRun SDK，用于创建 Sandboxpython-dotenv：环境变量管理配置环境变量创建 .env 文件：# DashScope API Key（用于 Qwen 模型） DASHSCOPE_API_KEY=sk-your-dashscope-api-key # AgentRun 认证信息 AGENTRUN_ACCOUNT_ID=your-account-id ALIBABA_CLOUD_ACCESS_KEY_ID=your-access-key-id ALIBABA_CLOUD_ACCESS_KEY_SECRET=your-access-key-secret # Browser Sandbox 模板名称 BROWSER_TEMPLATE_NAME=sandbox-browser-demo创建 Sandbox 并使用 BrowserUseimport asyncio import os from agentrun.sandbox import Sandbox, TemplateType from browser_use import Agent, BrowserSession, ChatOpenAI from browser_use.browser import BrowserProfile from dotenv import load_dotenv load_dotenv() async def main(): # 创建 Browser Sandbox sandbox = Sandbox.create( template_type=TemplateType.BROWSER, template_name=os.getenv("BROWSER_TEMPLATE_NAME"), sandbox_idle_timeout_seconds=3000 ) # 配置 Qwen 多模态模型 llm = ChatOpenAI( model='qwen-vl-max', api_key=os.getenv("DASHSCOPE_API_KEY"), base_url="https://dashscope.aliyuncs.com/compatible-mode/v1" ) # 创建浏览器会话 browser_session = BrowserSession( cdp_url=sandbox.get_cdp_url(), browser_profile=BrowserProfile( headless=False, timeout=3000000, keep_alive=True ) ) # 创建 Agent 并执行任务 agent = Agent( task="访问阿里云官网并总结主要产品分类", llm=llm, browser_session=brows…

二开 gemini 自动验证程序
type: item
date: 2026-01-23T09:08:20+08:00
description: 最近接触到一款支持自动学生认证的程序，便萌生了为其补充完善功能的想法。开发过程中，我发现某平台可购得单价 3.5 元的邮箱账号，这类账号仅支持手机端登录，且未开启双因素认证（2FA）。针对这一情况，我为程序新增了三项核心功能：2FA 自动设置、年龄验证校验（毕竟没有学生资格的账号，大概率是因为未完成 2FA 验证）、2FA 自动修改，以及虚拟卡自动绑定。整个项目全程基于 Claude 和 Codex 工具开发，目前已实现根据输入的虚拟卡信息，自动完成年龄验证与卡片绑定的功能。需要说明的是，我并非账号经销商，项目也未植入任何广告。此外，程序尚存不少待修复的 bug，且我后续不会对其进行维护迭代 —— 开发这个工具只是出于个人兴趣，我仅注册了二十个账号用于自身日常开发，完全不涉及任何盈利行为。需要配置比特浏览器使用，会自动创建窗口，以及你的浏览器配置过密码删除窗口，也会自动删除窗口。 github.com GitHub - 16627517673/bitbrowser-automation: BitBrowser Automation System - Batch Google...BitBrowser Automation System - Batch Google account processing tool (FastAPI + Vue 3 + Playwright) 很多账号没有学生资格，以及你被拉入家庭组之后，反重力还是无法用，很大概率就是没有年龄验证，这个很重要。📌 转载信息来源： https://linux.do/t/topic/1502327原作者： 16627517673转载时间： 2026/1/23 09:08:18

Skills 与延迟加载工具定义的 MCP，目前哪个更高效、稳定和可控？
type: item
date: 2026-01-23T08:29:15+08:00
description: 编者按： 我们今天为大家带来的这篇文章，作者的核心观点是：相较于依赖复杂且高成本的动态 MCP 工具加载机制，以 Skills 为核心的能力摘要与自维护模式，在当前阶段反而更加高效、稳定且可控。文章系统梳理了延迟工具加载（deferred tool loading）的工程现实与限制，指出即便工具可以延后注入，对话级别的工具集合仍然是静态的，且发现机制高度依赖正则匹配，收益并不如预期。作者进一步深入分析了 MCP 在上下文占用、API 稳定性、缓存失效与推理轨迹丢失等方面带来的隐性成本，并结合 Sentry MCP、Playwright 等实践案例，说明为何将 MCP 转换为 Skills，反而能让 Agent 更好地发挥既有工具的能力。文章最后还探讨了 MCP 是否可能完全转化为 Skills 的可行性，并坦率指出当前协议与生态在稳定性与摘要机制上的不足。作者 | Armin Ronacher(作者为 Flask、Jinja2 等开源项目的创建者)编译 | 岳扬我正把所有的 MCP 都迁移到 Skills 上，包括之前还在使用的最后一个：Sentry MCP（译者注：Sentry 是流行的应用监控与错误追踪平台）。早前我就已经完全弃用 Playwright（译者注：由 Microsoft 开发的现代 Web 自动化测试和浏览器自动化框架），转向使用 Playwright Skill。过去一个月左右，关于使用“动态工具配置（dynamic tool loadouts）[1]”来推迟工具定义的加载的讨论一直不少。Anthropic 也在探索通过代码来串联 MCP 调用的思路，这一点我也尝试过[2]。我想分享一下自己在这方面的最新心得，以及为什么 Anthropic 提出的“延迟工具加载方案（deferred tool loading）”并未改变我对 MCP 的看法。或许这些内容对他人会有所帮助。01 什么是工具（Tool）？当 Agent 通过强化学习或其他方式接触到工具定义时，它会被鼓励在遇到适合使用该工具的场景时，通过特殊的 token 输出工具调用。实际上，工具定义只能出现在系统提示词（system prompt）中特定的工具定义 token 之间。从历史经验来看，这意味着我们无法在对话状态的中途动态发出新的工具定义。因此，唯一的现实选择是在对话开始时就将工具加载好。在智能体应用场景中，我们当然可以随时压缩对话状态，或更改系统消息中的工具定义。但这样做的后果是，我们会丢失推理轨迹（reasoning traces）以及缓存（cache）。以 Anthropic 为例，这将大幅增加对话成本：基本上就是从头开始，相比于缓存读取，需要支付完整的 token 费用，外加缓存写入成本。Anthropic 最近的一项创新是“延迟工具加载”（deferred tool loading）。我们仍然需要提前在系统提示词（system message）中声明工具，但这些工具不会在系统提示词发出时就注入到对话中，而是会稍后才出现。不过据我所知，这些工具定义在整个对话过程中仍必须是静态的 —— 也就是说，哪些工具可能存在，是在对话开始时就确定好的。 Anthropic 发现这些工具的方式，纯粹是通过正则表达式（regex）搜索实现的。02 与 Skills 的对比尽管带延迟加载的 MCP 感觉上应该表现更优，实际上却需要在 LLM API 端做不少工程化工作。而 Skills 系统完全不需要这些，至少从我的经验来看，其表现依然更胜一筹。Skills 实质上只是对现有能力及其说明文件位置的简短摘要。这些信息会被主动加载到上下文中。 因此，智能体能在系统上下文里（或上下文的其他位置）知晓自己具备哪些能力，并获知如何使用这些能力的“手册链接”。关键在于，Skills 并不会真正把工具定义加载到上下文中。 可用工具保持不变：bash 以及智能体已有的其他工具。Skills 所能提供的，只是如何更高效使用这些工具的技巧和方法。由于 Skills 主要教的是如何使用其他命令行工具和类似实用程序，因此组合与协调这些工具的基本方式其实并未改变。让 Claude 系列模型成为优秀工具调用者的强化学习机制，恰好能帮助处理这些新发现的工具。03 MCP 能否转换为 Skills？这自然引出了一个问题：既然 Skills 效果这么好，我能不能把 MCP 完全移出上下文，转而像 Anthropic 提议的那样，通过 CLI 来调用它？答案是：可以，但效果并不好。Peter Steinberger 的 mcporter[3] 就是其中一种方案。简单来说，它会读取 .mcp.json 文件，并将背后的 MCP 暴露为可调用的工具：npx mcporter call 'linea…

快速上手：LangChain + AgentRun 浏览器沙箱极简集成指南
type: item
date: 2026-01-22T17:35:21+08:00
description: 作者：辰泉前言在 Agentic AI 时代，智能体需要与真实世界交互，而浏览器是连接虚拟世界与现实世界的重要桥梁。AgentRun Browser Sandbox 为智能体提供了安全、高性能、免运维的浏览器执行环境，让 AI Agent 真正具备“上网”的能力——从网页抓取、信息提取到表单填写、自动化操作，一切皆可实现。AgentRun Browser Sandbox 介绍什么是 Browser Sandbox?Browser Sandbox 是 AgentRun 平台提供的云原生无头浏览器沙箱服务，基于阿里云函数计算（FC）构建。它为智能体提供了一个安全隔离的浏览器执行环境，支持通过标准的 Chrome DevTools Protocol (CDP) 远程控制浏览器实例。核心特性无头浏览器能力内置 Chromium/Chrome 浏览器，支持完整的 Web 标准原生兼容 Puppeteer、Playwright 等主流自动化框架支持通过 CDP 协议进行精细化控制实时可视化内置 VNC 服务，支持实时查看浏览器界面提供操作录制功能，方便调试和回放支持通过 noVNC 客户端在网页中直接交互安全与隔离每个沙箱实例运行在独立的容器环境中文件系统和进程空间完全隔离支持 WSS 加密传输，确保数据安全Serverless 架构按需创建，按量付费，无需提前预置资源快速弹性伸缩，支持高并发场景零运维，无需管理服务器和浏览器依赖主要应用场景AI Agent 赋能： 为大模型提供“眼睛”和“手”，执行网页浏览、信息提取、在线操作等任务自动化测试： 在云端运行端到端（E2E）测试和视觉回归测试数据采集： 稳定、高效地进行网页抓取，应对动态加载和反爬虫挑战内容生成： 自动化生成网页截图或 PDF 文档上手使用 AgentRun Browser SandboxAgentRun SDK 快速介绍后续的内容将基于 AgentRun SDK 进行，因此我们先对 SDK 进行简要介绍。Agentrun SDK 是一个开源的开发者工具包，本期介绍 Python 版本。其旨在简化智能体与 AgentRun 平台各种服务（包括 Browser Sandbox）的集成。它提供了统一的接口，让您可以用几行代码就将沙箱能力集成到现有的 Agent 框架中。SDK 的核心功能如下：统一集成接口提供对 LangChain、AgentScope 等主流框架的开箱即用支持统一的模型代理接口，简化多模型管理标准化的工具注册机制Sandbox 生命周期管理自动创建和销毁沙箱实例支持会话级别的状态保持灵活的资源配置和超时控制安装 AgentRun SDKpip install agentrun-sdk[playwright,server]注意： 确保您的 Python 环境版本在 3.10 及以上。基本使用示例以下是使用 AgentRun SDK 创建和管理 Browser Sandbox 的核心代码：from agentrun.sandbox import Sandbox, TemplateType from playwright.sync_api import sync_playwright # 创建 Browser Sandbox sandbox = Sandbox.create( template_type=TemplateType.BROWSER, template_name="your-template-name", sandbox_idle_timeout_seconds=300 ) # 获取 CDP URL（用于 Playwright 连接） cdp_url = sandbox.get_cdp_url() # 使用 Playwright 连接并操作 with sync_playwright() as p: browser = p.chromium.connect_over_cdp(cdp_url) page = browser.contexts[0].pages[0] page.goto("https://www.example.com") page.screenshot(path="screenshot.png") browser.close() # 销毁 Sandbox sandbox.delete()关键概念：template_name： 控制台创建的浏览器环境模板cdp_url： 用于 Playwright/Puppeteer 连接vnc_url： 用于实时查看浏览器画面（可通过 sandbox.get_cdp_url() 获取）注意： 由于所有浏览器操作都在云端进行，您无需在本地安装浏览器。Playwright 仅用于通过 CDP 协议连接到云端的浏览…

Tiktok 用户主页 视频 和 评论 爬虫，基于Python selenium 库 和 playwright库两种方式。
type: item
date: 2026-01-20T16:52:37+08:00
description: 背景一开始是通过Api获取数据，但是最近他们增加X-Gnarly参数，而且在github上没有找有效的方案后，放弃api请求，改用页面爬取的方式。彻底避免参数加密校验。我的环境 python 3.11 selenium 4.39.0 playwright 1.57.0评论页面实现啦抓取第一页和第二页的评论，你们要是抓更多页可以吧第二页改成循环。执行脚本后会在当前目录生成一份json文件，里面是/api/comment/list/接口返回的数据。 python3.11 comment_scraper.py "@mahi.islam.oliva/video/7565942090039954706" 代码如下：import json import time import sys import base64 import re,os from selenium import webdriver from selenium.webdriver.chrome.options import Options from selenium.webdriver.common.by import By from selenium.webdriver.support.ui import WebDriverWait from selenium.webdriver.support import expected_conditions as EC import argparse def merge_comments(first_page, second_page): """合并两页的评论数据""" merged_data = first_page.copy() if 'comments' in second_page: if 'comments' not in merged_data: merged_data['comments'] = [] merged_data['comments'].extend(second_page['comments']) return merged_data def extract_tiktok_filename(path: str) -> str: """ 从 TikTok 路径（如 '@username/video/123456'）中提取 'username_123456' 支持带或不带 @、带 URL 等情况 """ # 匹配模式：可选的 @ + 用户名（字母数字下划线.）+ /video/ + 数字ID match = re.search(r'@?([\w.]+)/video/(\d{16,})', path) if match: username = match.group(1) video_id = match.group(2) return f"{username}_{video_id}" else: # 如果格式不符，回退到清理后的通用方式 safe = re.sub(r'[\\/:*?"<>|\s]+', '_', path.strip('@/')) return safe[:100] class TiktokScraper: def __init__(self): self.comments_data = [] self.setup_driver() def setup_driver(self): chrome_options = Options() chrome_options.set_capability("goog:loggingPrefs", {"performance": "ALL"}) chrome_options.add_argument("--start-maximized") chrome_options.add_argument("--no-sandbox") chrome_options.add_argument("--headless=new") chrome_options.add_argument("--disable-dev-shm-usage") chrome_options.add_argument("--disable-blink-features=AutomationControlled") chrome_options.add_argument("--disable-infobars") chrome_options.add_argument("--disable-extensions") chrome_options.add_argument("--disable-gpu") # 减少 WebGL 差异（可选） chrome_options.add_experime…

Linky：基于 AI 的自动化外链发布工具
type: item
date: 2026-01-20T10:18:53+08:00
description: 佬们，我开发了 Linky，一个能自动在各类网站提交链接（发外链）的 AI 工具。传统工具的痛点：名单固定： 往往只能在预设的 500-2000 个站点里打转。极其脆弱： 只要目标网站改个 UI，脚本就报错。特征明显： 机械化的操作路径很容易被反爬虫系统识别。我的解决方案：Linky 结合了 AI（Claude/OpenAI） 和 Playwright。它不再是死记硬背脚本，而是通过理解网页结构来智能操作。核心亮点：全网通用： 你给它任何网址，它都能尝试去理解并完成提交，不局限于固定列表。自适应 UI： 即使网站改版，AI 也能通过语义理解找到正确的输入框和按钮。“动作回放” (Action Replay)： AI 第一次成功探索后会记录路径，后续执行零成本，无需重复消耗 Token。拟人化操作： 模拟真实的点击和录入行为，规避自动化检测。自带 Key (BYOK)： 用户自带 API Key，成本完全透明，不收中间费。技术栈：桌面端： Electron + React 19后端： Python + FastAPI + browser-use (AI 浏览器框架)自动化： Playwright目前仅支持 macOS，Windows 版本正在路上。这还是个正在开发中的早期项目，我不知道大家是否认为它有用。如果你对这个工具感兴趣的话，欢迎去 GitHub 点个 Star 以给我反馈！GitHub 传送门： https://github.com/jiweiyeah/linky-ai（补充：这工具是用 Claude 写的，用 AI 来写一个 AI 工具，这种感觉挺奇妙的 ）📌 转载信息来源： https://linux.do/t/topic/1487370原作者： yeheboo转载时间： 2026/1/20 10:18:52

Linky：基于 AI 的自动化外链发布工具
type: item
date: 2026-01-20T10:01:36+08:00
description: 佬们，我开发了 Linky，一个能自动在各类网站提交链接（发外链）的 AI 工具。传统工具的痛点： 名单固定： 往往只能在预设的 500-2000 个站点里打转。 极其脆弱： 只要目标网站改个 UI ，脚本就报错。 特征明显： 机械化的操作路径很容易被反爬虫系统识别。 我的解决方案：Linky 结合了 AI （ Claude/OpenAI ） 和 Playwright。它不再是死记硬背脚本，而是通过理解网页结构来智能操作。核心亮点： 全网通用： 你给它任何网址，它都能尝试去理解并完成提交，不局限于固定列表。 自适应 UI： 即使网站改版，AI 也能通过语义理解找到正确的输入框和按钮。 “动作回放” (Action Replay)： AI 第一次成功探索后会记录路径，后续执行零成本，无需重复消耗 Token 。 拟人化操作： 模拟真实的点击和录入行为，规避自动化检测。 自带 Key (BYOK)： 用户自带 API Key ，成本完全透明，不收中间费。 技术栈： 桌面端： Electron + React 19 后端： Python + FastAPI + browser-use (AI 浏览器框架) 自动化： Playwright 目前仅支持 macOS ，Windows 版本正在路上。这还是个正在开发中的早期项目，我不知道大家是否认为它有用。如果你对这个工具感兴趣的话，欢迎去 GitHub 点个 Star 以给我反馈！GitHub 传送门： https://github.com/jiweiyeah/linky-ai（补充：这工具是用 Claude 写的，用 AI 来写一个 AI 工具，这种感觉挺奇妙的 😄）

[分享] from windows to wsl2 我的 cc,codex,opencode 迁移记录
type: item
date: 2026-01-18T19:07:55+08:00
description: 第一稿，出去吃火锅了…断断续续研究了将近一天，终于把 cc codex 和 opencode 都迁移到了 wsl 里 了；在这里开个记录帖子，记录下自己遇到的问题以及解决方案，欢迎各位佬友友好交流，分享自己的经验。1. 迁移动机（废话略多）最重要的一点，codex 在 windows 上的表现不佳且速度慢；在 windows 上使用 codex 的佬友一定经常见到过 codex 的 PowerShell 语法错误… 大量的时间和 token 被浪费于此，尽管在提示词里针对 codex 经常犯错的部分进行了提示，但仍无法有效地解决，根本原因还是 pwsh 的训练数据太少，而 unix 类天生就是大家默认的开发环境，数据多，支持地更好。且在 Linux 上 codex、cc 运行起来也更加丝滑opencode 的 windows 兼容过于垃圾；opencode 在爆火之前我就早早的接触过了，然而… 其对 windows 的支持可谓十分之差，经常出现上一个版本还是可以启动，下一个版本就不能启动了，打开 opencode 的 github 你会发现类似的 issue 层出不穷，最经典的就是渲染出错，启动 opencode，出现 opencode [object] [Object]；在经历数次 codex 手动修复让其能够启动后，我受够了。常用的工具包或插件如 codeagent 和 claude mem 等对于 windows 的支持也很差；前者是我使用频率最高的 workflow+skill；而后者我更是从来没有在 windows 上成功启动过，考虑到众多插件都会优先支持 Linux 和 MacOS，我还是迁移的好。2. windows 已有配置cc switch我是 cc switch 的忠实用户，ccs 的伟大无需多言；我用到的核心功能主要是多配置切换，供应商 + 全局提示词；我有各家的 coding plan 以及自己手写的多套全局提示词，十分需要 ccs 统一管理；ccs 在当前版本可以指定 wsl 目录，这使得迁移起来没有什么难度，但是我并没有选择使用。ccs 的代理和统计功能，开启后可以直观地观测自己每天的 token 用量；ccs 的本地代理功能也是此次迁移较为顺利的根本原因3. 迁移记录3.1 基础部分安装 codex claude code opencode；过于简单，为了方便，我统一用 npm 了；添加供应商配置，这个时候，刚才说过的 ccs 的本地代理功能就派上用场了；只需要把 url 指向 ccs 的代理端口即可，这里以 codex 为例我出于一些考量，并没有选择用 ccs 直接配置，你也可以在这里更改配置目录后用 ccs 进行配置，更加自动3.2 问题来了mcp 迁移，对于一些 npx nvx 或者 remote 类型的 mcp 很简单，都不需要改；都知道 wsl 好，为什么我迟迟没有迁移打算呢，问题就在于这里，因为个人手搓的小玩意对于 playwright 的依赖程度较高，而 wsl… 配置图形化… 比较麻烦吧，支持地也不好，当然 这些都不是问题。在调研站里的方案，以及询问 gpt52pro 后，我有了方案 1:方案 1: WSL2 里跑 Linux Playwright（WSLg）在 WSL2 里跑 Linux 浏览器（WSLg 出窗口），这个… 需要做不少的前置准备，且最后的效果也不尽人意，我在跑通后遂放弃。1 首先必须有显示环境（WSLg） echo "$DISPLAY" echo "$WAYLAND_DISPLAY" echo "$XDG_RUNTIME_DIR" 2 得有浏览器二进制（Playwright 下载的 Chromium/Firefox/WebKit） npx playwright install 3 必须有系统依赖（Ubuntu 的一堆 .so） # 安装系统依赖 sudo env "PATH=$PATH" npx playwright install-deps 这一套跑完，可以按照站里佬的方案持久化安装 playwright 或者 npx 启动；它的问题是什么呢？WSLg 的浏览器实在太丑了！包括且不限于字体的缺失导致渲染出来的网页相当地丑，你根本无法判断是自己 UI 设计问题还是渲染问题启动时候默认一个半截窗口，全屏后不会响应式调整页面大小！这个过于逆天尤其是 2 是我放弃方案 1 的最直接原因；而方案 2 是我现在使用的方案，我似乎没有看到有佬提及这个方案来着？有一个佬友给出了类似的 chrome dev mcp 的安装方式，所以我就放上来供佬友参考；方案 2： Windows 侧 Playwright MCP基本的原理：WSL2 (Ubuntu): claude / code…

【分享】AI 自动化测试方案
type: item
date: 2026-01-15T18:35:32+08:00
description: 用 Claude Code 跑自动化测试时遇到过这种情况吗？生成了一堆测试用例，跑完发现 Token 烧了不少，结果一半是废的 —— 要么断言写错，要么压根定位不到元素。所以我花了点时间把市面上的 AI 测试方案摸了一遍。就两条路，DOM 解析或者视觉识别，先选一个深耕就行。DOM原理没什么花活。DOM 就是浏览器把 HTML 页面变成一棵可以被 JavaScript 随意增删改查的树状对象结构。简单说，你写的 HTML 被浏览器变成了一堆 "会动的积木"，这些积木可以用 JavaScript 随便抓、改、删、加。AI 通过选择器找到这些积木，Playwright 负责点点点。就这样。推荐工具：agent-browser这是 Vercel 出的一个专门用于 AI Agent 的浏览器自动化 CLI，支持无头模式，可以不打开浏览器进行测试。# 安装 CLI npm install -g agent-browser # 安装驱动 agent-browser install # 验证安装 agent-browser open baidu.com # 返回以下内容表示成功 # ✓ 百度一下，你就知道 # https://www.baidu.com/ 这条路的好处很直接 ——Token 消耗低，跑得快，CI/CD 接进去顺滑。但有个前提：你的 DOM 结构得稳定。纯视觉这个思路更直观：将页面截图发送给视觉大模型识别，模型返回下一步操作指令，循环执行直到完成全部任务。推荐工具：Midscene这是字节开源的纯视觉测试方案，支持 Web、Android、iOS，兼容多种视觉模型：Gemini、Qwen-VL、Doubao-VL。自然语言写测试目标，AI 自己生成脚本。但 Token 消耗高。跑一轮测试下来成本不低。而且视觉模型偶尔会出问题。所以视觉方案更像是补充：DOM 搞不定的场景，比如验证 UI 有没有错位、样式有没有问题，再让视觉上。ChatGPT AgentMode这是 ChatGPT 的 AgentMode 功能需要订阅企业版或者 Pro 版本 (team 也可以) 它会启动一个虚拟浏览器访问你要求的网址像真人一样在你的平台浏览、点击按钮、账号登录 ，要求最后给我详细的测试报告，如果你的网站已经部署到公网上那么就可以使用 Agent Mode 进行测试。缺点是最少需要购买 Team 或者 Pro。怎么选？ 场景建议 页面结构稳定，预算有限DOM + Playwright页面动效多、结构不稳定视觉方案想检测布局错位、样式问题必须视觉，DOM 看不出来成本敏感DOM 为主 几个坑提前说成本控制：先让 AI 生成用例，人审完再跑。不然跑完发现一半用例有问题，Token 白烧了。CI/CD 集成：配置的时候注意超时设置。视觉方案跑得慢，默认超时可能不够。自愈能力：市面上很多工具都说支持 "自愈"，意思是 UI 改了之后测试脚本能自动调整选择器。实际效果看情况，改个按钮文案能自愈，重构了页面结构还是得手动改。核心就一句：DOM 打底，视觉补充，别一开始就 all in 最贵的方案。有实践经验的欢迎评论区交流。相关链接：Midscene：https://midscenejs.comagent-browser：GitHub - vercel-labs/agent-browser: Browser automation CLI for AI agentsPlaywright：https://playwright.devtest-cases Skill：myclaude/skills/test-cases/SKILL.md at master · cexll/myclaude · GitHub📌 转载信息来源： https://linux.do/t/topic/1462003原作者： benchen转载时间： 2026/1/15 18:35:29

为什么不一定需要 debugger 做浏览器控制?
type: item
date: 2026-01-14T09:21:38+08:00
description: AIPex 最新发布了新版本，其中最重要的能力之一，是浏览器任务可以在后台运行，而不打断用户的正常工作流。这一能力并非来自某个“技巧”，而是源于一个明确的工程选择： 我们有意识地避免将浏览器控制建立在 debugger （ Chrome DevTools Protocol ）之上。本文将解释为什么主流方案普遍选择 debugger ，以及 AIPex 为什么在多数智能代理与日常自动化场景中，选择了一条不同的路线。为什么大多数浏览器控制方案选择 debugger （ CDP ）在当前无需迁移的浏览器自动化插件或 Agent 中，常见方案包括： Manus 的 Manus Browser Operator Claude 推出的 Claude in Chrome 开源社区的 nano browser 以及 Puppeteer / Playwright 等自动化工具的扩展形态 这些方案通常基于 Chrome DevTools Protocol （ CDP ），尤其是其 debugger 能力来实现浏览器控制，原因并不复杂：1. 能力覆盖完整CDP 提供了浏览器内部几乎所有关键能力，包括： 页面导航与生命周期控制 DOM 与 AXTree （ Accessibility Tree ）访问 事件注入（鼠标、键盘、滚轮） 网络拦截与修改 截图、录屏、性能采样 对于复杂自动化而言，CDP 是一个“开箱即用”的全能力接口。2. 可访问性树（ AXTree ）高度语义化通过 CDP ，可以直接获取浏览器构建的 Accessibility Tree： 每个节点都具备 role / name / state 天然适合语音辅助与 AI 理解 在理想 ARIA 实现下，语义质量很高 因此，AXTree 成为了许多 AI Agent 的主要页面表达形式。3. 工程生态成熟围绕 CDP 已经形成成熟工具链： Puppeteer 、Playwright 等底层实现 完整的文档、示例与社区经验 对自动化工程师而言，学习与接入成本明确 debugger （ CDP ）在桌面场景中的现实代价尽管 CDP 能力强大，但在“与用户并行工作的桌面场景”中，它也带来了一些难以忽视的问题。1. 前台焦点与用户体验问题CDP 并非以“后台无打扰”为设计目标。在真实桌面环境中： debugger attach 往往会触发 Tab 激活或窗口前置 输入与视觉焦点可能被强制抢占 即使通过 headless 或参数规避，也难以在不同平台与浏览器上保证一致行为 结果是： 当用户正在使用其他应用或标签页时，自动化任务可能打断其当前操作，严重影响体验。2. 浏览器与运行环境耦合使用 CDP 通常意味着： 需要启用调试端口 强绑定 Chrome / Chromium 对部分嵌入式 WebView 、受限环境或非 Chromium 浏览器支持不佳 在企业环境或多浏览器生态中，这种耦合会显著增加部署与维护成本。3. 安全与权限摩擦调试端口、进程权限、证书配置等问题，在企业与受管环境中常常触发： 安全策略拦截 合规审查 IT 运维阻力 这类问题并非技术不可解，而是部署摩擦成本过高。为什么浏览器控制不一定需要 debuggerAIPex 的核心设计目标是：让浏览器任务像“背景思考”一样运行，而不是像“远程操控”一样打断用户。为此，我们选择了一条不以 debugger 为中心的路径。AIPex 的方案：DOM 语义快照 + 轻量交互在页面侧，AIPex 采用纯 JavaScript / TypeScript 能力，实现： 语义化页面快照 稳定节点映射 轻量级事件交互 而不是依赖 CDP 的 AXTree 与调试通道。1. 语义快照，而非调试树AIPex 基于 @aipexstudio/dom-snapshot： 直接遍历 DOM Tree 提取可访问性相关语义（ role / name / state ） 不依赖 CDP 的 Accessibility Tree （ AXTree ） 该库在 README 中明确说明： 它是一个纯 DOM 方案，而非 CDP 的替代封装。2. 稳定、可复用的节点 ID自动为页面元素生成稳定的：data-aipex-nodeid这使得： “语义快照中的节点”与“真实 DOM 元素”之间的映射可长期复用 避免调试态下常见的选择器漂移问题 支持从文本命中直接反查到可操作元素 3. 面向可交互对象的快照策略语义快照优先关注： 按钮、链接、输入框等可操作元素 对话与任务相关的界面子集 并过滤： display: none visibility: hidden aria-hidden inert 从而避免将无意义或不可见节点暴露给 Agent 。4. 文本化表达与语义搜索快照可被转…