AI 控制浏览器的四种方案:插件 / Playwright / CDP / Browser Use
"AI 控制浏览器"目前有四类方案,权限差异非常大。做爬虫 / 自动化 / Agent 时选错方案会撞墙——比如插件方案下想调试 JS 是不可能的。 权限矩阵方案 操作 DOM 读 DOM 执行 JS 调试 JS Chrome DevTools 全权限 保留登录态Chrome 扩展 ✅ ✅ ✅ ❌ ❌ ✅Playwright / Puppeteer ✅ ✅ ✅ 部分 ❌ 需配置Chrome DevTools Protocol (CDP) ✅ ✅ ✅ ✅ ✅ ✅Browser Use / Open Operator ✅ ✅ ✅ 部分 部分 ✅方案一:Chrome 扩展 适合:日常使用中的 AI 助手(Sider、Harpa、Monica 等)、需要长期挂在浏览器里的工具。 做法:写一个 Chrome/Edge 扩展,通过 content script 读写 DOM: // content.js document.querySelector("input.search").value = "hello"; document.querySelector("button.submit").click();或者用扩展 API 拿到当前 tab 的 DOM 快照喂给 LLM: chrome.tabs.sendMessage(tabId, { type: "getDOM" }, response => { callLLM(response.html); });局限:无法调试 JS(没 DevTools 权限) 无法访问 Network / Sources / Performance 某些反爬网站可能识别扩展环境方案二:Playwright / Puppeteer 适合:爬虫、自动化测试、CI 里跑的一次性任务。 from playwright.sync_api import sync_playwrightwith sync_playwright() as p: browser = p.chromium.launch(headless=False) page = browser.new_page() page.goto("https://example.com") # 读 DOM html = page.content() # 执行 JS result = page.evaluate("() => document.title") # 点击 page.click("button.submit")配合 LLM:Playwright 抓页面 → 传 DOM 给模型 → 模型返回下一步操作 → Playwright 执行。 局限:每次启动是全新 profile,没登录态(除非 launch_persistent_context) 反自动化检测(Cloudflare、Datadome 之类)会挂 网站升级 selector 就崩有个绕检测的插件叫 playwright-stealth,能过大多数入门反爬。 方案三:Chrome DevTools Protocol(权限最高) 适合:需要完整 DevTools 能力的场景——JS 调试、Network 拦截、Performance profiling、逆向分析。 先以 debug 模式启动 Chrome: chrome.exe --remote-debugging-port=9222 --user-data-dir="D:\chrome-cdp"然后 Playwright 连过去(这里 Playwright 是 CDP 的高层封装): browser = p.chromium.connect_over_cdp("http://127.0.0.1:9222")或者直接用底层 CDP: from pychrome import Browser b = Browser(url="http://127.0.0.1:9222") tab = b.list_tab()[0] tab.start() tab.Runtime.evaluate(expression="document.title")# 拦截 Network tab.Network.enable() tab.call_method("Fetch.enable")# 设置断点 tab.Debugger.enable() tab.Debugger.setBreakpointByUrl(url=".../app.js", lineNumber=100)能力和你按 F12 一样。 方案四:Browser Use / Open Operator 类项目 近一两年新出的一批"给 LLM 用的浏览器 SDK"——比如 browser-use、Anthropic 的 Computer Use、OpenAI Operator: from browser_use import Agent from langchain_openai import ChatOpenAIagent = Agent( task="打开 GitHub 搜索 langchain 项目的最新 star 数", llm=ChatOpenAI(model="gpt-4o"), ) result = agent.run()这类 SDK 帮你封装好:页面截图 + 元素编号 Vision 模型选元素 Playwright 执行操作 失败自动重试写业务代码不用管 selector,直接说自然语言。代价:慢(每步 LLM 调用)、贵(大量 vision token)、有时候错。 怎么选场景 推荐用户浏览时给 AI 助手能力 Chrome 扩展定时任务 / CI 里跑 Playwright需要 JS 断点、Network 拦截、逆向 CDP想让 LLM 自主完成复杂多步任务 Browser Use 类反爬严的网站 CDP + stealth + 真实 profile一句话总结 日常插件、爬虫 Playwright、逆向调试 CDP、Agent 用 Browser Use——四种方案权限从低到高,按需要选。CDP 是"能上 F12 就能做的一切"的上限。
6000 张图做 YOLO 辅助标注:一个大模型还是拆多个
数据集里 6000 张图,想训一个 YOLO 做预标注(不是最终部署)——是把所有类别塞一个模型,还是按大类拆多个?答案要看你的类别怎么分。 场景 1:类别相近 → 一个大模型 比如都是路面场景:person、car、bus、truck、traffic_light——目标形态接近、上下文相似,塞一个模型没问题: # data.yaml nc: 20 names: - person - car - bus - truck - traffic_light - ...优点:只维护一个模型 推理一次拿全部结果 6000 张图对 YOLOv8s / YOLO11s 一点都不多,一晚上跑完 类别之间可能有互相约束(比如"斑马线附近容易有 person"),单模型能学到场景 2:类别跨度大 → 拆多个模型 要标的东西差别巨大: 交通标志:限速 / 禁停 / 左转 / 右转 车辆:car / bus / truck 家具:chair / table / sofa三个域完全不同的时候,一个模型很容易顾此失彼——训到最后 mAP 只是 balance 出的中间值。每个域一个小模型:交通标志检测模型 车辆检测模型 家具检测模型优点:新加一个大类不用重训全部 小模型训练快、精度高 误检更少(不会拿"椅子"当"汽车")缺点:推理跑多个模型 管理麻烦(模型 → 类别 → 版本)场景 3:类别很多且分层 → 分级流水线 CVAT / LabelStudio 等专业标注平台常用的做法——粗定位 + 细分类: 一级:粗定位(找目标) │ ├─ person ├─ vehicle ├─ animal ├─ traffic_sign └─ building二级:细分类(每个粗类一个小模型) ├─ traffic_sign │ ├─ speed_limit │ ├─ stop │ ├─ turn_left │ └─ turn_right ├─ vehicle │ ├─ car / bus / truck / bike └─ ...粗模型只负责"找到候选框",细分类器(可以是分类模型不是检测)判定具体类别。这套结构对增加新细类特别友好——只改对应二级分类器就行。 配合 SAM 类分割模型:SAM 出 mask → YOLO 分类头判定 → 输出精细标注。这是当前自动标注前沿方案。 6000 张的容量参考YOLOv8n / YOLO11n:几百到几千张就能有效果,训练几十分钟 YOLOv8s / YOLO11s:6000 张的甜蜜点,训练 1-3 小时 YOLOv8m / YOLO11m:需要至少 1 万张才发挥优势 YOLOv8l / YOLOv8x:几万张起步6000 张选 s / m,别上 l 或 x——过拟合概率大。 类别不平衡怎么办 6000 张里可能某些类别几百张、某些类别几十张。方法:加数据增强:mixup、mosaic、hsv、rotation——Ultralytics 默认就开 加权采样:class_weights 让少数类被多次采样 合并罕见类:训不动的类临时合并成"其它",先跑通再迭代 cascade:稀有类先由粗模型定位,再单独训一个二分类判定辅助标注 vs 最终部署 辅助标注模型要求:Recall 优先(宁多勿少,人工再删) Precision 差点没事 速度不用极致最终部署模型要求:Precision + Recall 都要 速度 / 显存有约束 需要严格评测两者训练策略也不一样。辅助标注可以 confidence 阈值调低(比如 0.15),把所有可疑目标都框出来,让人复核。 推荐做法 如果类别 <= 30、都是相似的场景:一个 YOLOv8s / YOLO11s 模型,配合置信度 0.15-0.25 做辅助标注,人工审核补漏。 类别 >= 50 或者跨大类:每个大类一个模型,或者上"检测 + 分类"分级流水线。 一句话总结 类别相近 → 一个大模型;跨度大 → 拆多个;类别多且分层 → 检测 + 分类分级。辅助标注就调低 confidence 让人复核,比追求高 precision 更实用。
OpenCode Browser 扩展能做什么:与 Chrome DevTools MCP 的差异
两种方案的架构对比 OpenCode Browser(扩展方式) Chrome DevTools MCP(CDP 方式)OpenCode OpenCode ↓ ↓ Native Messaging MCP Server ↓ ↓ Chrome Extension Chrome DevTools Protocol (CDP) ↓ ↓ DOM / Tab 操作 完整 DevTools 能力OpenCode Browser 扩展连接方式更轻量,不需要打开 --remote-debugging-port,官方说明"No DevTools Protocol, no security prompts"。 OpenCode Browser 能做什么能力 支持导航(跳转 URL) ✅点击元素 ✅输入文本 ✅获取页面 DOM / 文本 ✅截图 ✅读取 <script> 标签内容 ✅读取 window.localStorage / sessionStorage 取决于扩展实现监听 Network 请求(XHR/fetch/WebSocket) ❌设置 JS 断点 ❌查看 Webpack/闭包内变量 ❌Memory Snapshot / Performance Profile ❌拦截/修改请求 ❌Chrome 扩展标准 API(chrome.scripting.executeScript)可以在页面上下文执行脚本,所以凡是挂在 window 上的对象(window.__NEXT_DATA__、window.__INITIAL_STATE__ 等)都可以读取。 但 webpack 闭包内的局部变量: ;(() => { const token = "abc123"; // ← 扩展拿不到这个 })();无论是 OpenCode Browser 还是普通扩展都无法直接访问,必须通过 DevTools Protocol 的 Runtime.evaluate 或断点能力才能拿到。 什么时候用 Chrome DevTools MCP 如果目标是:分析混淆 JS、逆向加密参数 Hook XHR / fetch / WebSocket 请求 查看 React/Vue 组件状态树 抓取动态签名、Token 设置断点、单步执行应该改用支持 CDP 的 MCP 方案,例如通过 --remote-debugging-port=9222 启动 Chrome,再连接 CDP: google-chrome --remote-debugging-port=9222 --user-data-dir=/tmp/debug-profile然后 MCP Server 通过 WebSocket 连接 ws://localhost:9222 调用 CDP 接口。 CDP 可以做到: Sources → 设置断点 Network → 查看所有请求/响应 Console → 执行任意 JS Memory → Heap Snapshot如果目标是指纹浏览器(Adspower 等) OpenCode Browser 扩展控制 Chrome 不能隐藏浏览器指纹(Canvas、WebGL、TLS、WebRTC 等),这些由浏览器本身决定。 需要多账号防关联的场景通常走另一条路: OpenCode / Playwright ↓ Adspower / MultiLogin 本地 API ↓ 指纹浏览器实例通过 Adspower 提供的 REST API 创建/启动指纹浏览器,再用 Playwright 连接其 CDP 端口操作页面。 小结 OpenCode Browser 扩展的定位是自动化操作真实浏览器(点击、填表、截图、爬内容),适合不需要深层 JS 调试的 RPA 和 AI Agent 场景。需要分析 JS 执行过程或拦截网络请求时,应切换到 CDP 方案。
TrickyStore 替代方案:2026 年 Android Root 通过 Play Integrity 的主流组合
背景 TrickyStore 的核心功能是:劫持 Android KeyStore,注入 Keybox,伪造 TEE 硬件证明(Hardware Attestation),让 Play Integrity 拿到 MEETS_STRONG_INTEGRITY。 2026 年 Google 大规模推进 RKP(Remote Key Provisioning),设备 Keybox 越来越多通过远程下发,公开泄露的 Keybox 被大量封禁,TrickyStore 的有效性明显下降。 主流替代方案对比方案 用途 推荐度Play Integrity Fork Device / Basic Integrity 修复 ⭐⭐⭐⭐⭐ReZygisk 替代原生 Zygisk ⭐⭐⭐⭐Shamiko Root 痕迹隐藏 ⭐⭐⭐⭐HMA-OSS(Hide My Applist) 隐藏 Root、LSPosed、模块列表 ⭐⭐⭐⭐KernelSU Next + SUSFS Kernel 级隐藏,最难检测 ⭐⭐⭐⭐⭐TrickyStore Strong Integrity / TEE 硬件证明 ⭐⭐⭐(RKP 影响下效果变弱)各场景推荐组合 银行 App(不要求 Strong Integrity) Play Integrity Fork + HMA-OSS + ReZygisk很多银行只要求 DEVICE_INTEGRITY,更多是检测:Root 文件、Bootloader 状态、Magisk/LSPosed 痕迹、可疑 App 列表。HMA-OSS 可以对指定 App 隐藏已安装列表,避免被扫描到 Root 工具。 Google Wallet Google Wallet 目前仍需要 STRONG_INTEGRITY,TrickyStore 仍然是成功率最高的方案,没有更好的替代: TrickyStore + Play Integrity ForkKeybox 失效后需要更换有效的私有 Keybox,公开 Keybox 已不可靠。 游戏(Pokemon GO、吃鸡等) 游戏越来越少单纯依赖 Play Integrity,更多依赖自己的反作弊检测: KernelSU Next + SUSFS + HMA-OSSSUSFS 在内核层隐藏 /proc、/sys 特征,比用户空间隐藏更彻底,是目前社区反作弊对抗的主流选择。 完全放弃 TrickyStore 的通用方案 KernelSU Next + SUSFS + ReZygisk + Play Integrity Fork对绝大部分银行 App 和普通应用可以通过 BASIC + DEVICE Integrity,已经够用。 Magisk 体系 vs KernelSU 体系维度 Magisk 体系 KernelSU 体系方式 修改 boot.img 内核模块隐藏难度 中(用户空间检测较容易发现) 高(内核层操作更底层)兼容性 广(绝大多数设备) 需要设备支持 KMI 或自编译内核Zygisk 原生支持 需 ReZygiskSUSFS 支持 有 susfs4magisk,但效果弱于 KernelSU 原生支持,效果最好重要说明 银行 App 实际检测逻辑通常不只看 Play Integrity,还包括:/proc/mounts 是否有可疑挂载 系统分区是否有异常文件 可疑进程名(magiskd、zygote64d 等) 已安装 App 列表(通过 PackageManager)即使 Play Integrity 全部通过,Root 痕迹未隐藏干净仍可能被识别。HMA-OSS 对目标 App 可以精确控制可见的应用列表,是隐藏 Root 工具的关键一步。
NVM 安装与配置:macOS/Linux 和 Windows 环境变量设置,npm 找不到的排查
macOS / Linux 配置 安装 nvm 后,需要在 Shell 配置文件中初始化脚本,否则每次新开终端都找不到 nvm 命令。 在 ~/.zshrc(zsh)或 ~/.bashrc(bash)末尾添加: export NVM_DIR="$HOME/.nvm" [ -s "$NVM_DIR/nvm.sh" ] && \. "$NVM_DIR/nvm.sh" [ -s "$NVM_DIR/bash_completion" ] && \. "$NVM_DIR/bash_completion"重新加载: source ~/.zshrc # 或 source ~/.bashrc验证: nvm -vWindows(nvm-windows)配置 nvm-windows 安装后需要两个系统环境变量: NVM_HOME=C:\Users\<用户名>\AppData\Roaming\nvm NVM_SYMLINK=C:\Program Files\nodejs并在 Path 中加入: %NVM_HOME% %NVM_SYMLINK%验证(重开终端后): nvm version node -v npm -v查看当前配置: nvm root # nvm 安装目录 where nvm # 命令位置常用命令 # 安装指定版本 nvm install 22 nvm install 20.11.0# 查看已安装版本 nvm list# 切换版本 nvm use 22# 设置默认版本(新终端自动激活) nvm alias default 22# 查看当前使用的版本 nvm current node -vnpm 找不到的排查 原因一:还没安装 Node nvm list # 如果为空,先 install nvm install 22 nvm use 22原因二:版本未激活 nvm current # 输出 none 或系统版本 nvm use 22原因三:没有设置 default alias 新开终端后 nvm 不会自动激活任何版本: nvm alias default 22设置后新终端自动使用该版本。 原因四:Windows PATH 配置错误 where node where npm echo %NVM_SYMLINK%如果 where node 返回空或旧路径,检查 NVM_SYMLINK 是否指向 nvm 创建的 nodejs 符号链接目录,并确认 %NVM_SYMLINK% 在 PATH 中。 项目级 Node 版本锁定 在项目根目录创建 .nvmrc: 22进入目录后执行: nvm use # 自动读取 .nvmrc 切换版本配合 .nvmrc 可以保证团队成员使用相同的 Node 版本。
