远程浏览器自动化与可视化控制工具

传统无头自动化的痛点

当 AI Agent 需要自动化操作网页（如发布内容、管理后台）时，传统方案常采用无头浏览器（Headless Browser）。这种方式在处理纯 API 交互或简单页面时有效，但一旦遇到登录验证码、滑块验证、扫码登录或风控拦截，AI 便会卡住——因为它无法“看到”更无法“操作”这些需要人工判断的界面。主流平台（如社交媒体、创作者后台）的反自动化机制越来越强，纯无头模式已难以应对真实世界中的复杂交互。

技能如何解决问题：远程可视化与人机协作

本技能通过部署一个全程可视、可交互的浏览器环境，将控制权灵活地在 AI 与人之间切换，核心思路如下：

1. 可视化部署：在 Linux 服务器上，它会在虚拟显示器（如 DISPLAY=:99）中启动一个 Chromium 浏览器，并通过 noVNC（基于 websockify）将画面实时转发到 6080 端口的 Web 页面。用户可以像访问网页一样，直接在浏览器中查看和操作这个远程桌面。
2. AI 可控接口：浏览器以远程调试模式（--remote-debugging-port=9223）启动，AI Agent 通过标准的 Chrome DevTools Protocol 连接到 127.0.0.1:9223，从而能执行打开页面、点击、输入、读取 DOM 和截图等一系列操作。
3. 人机协作流程：当 AI 遇到无法处理的验证环节时，可以暂停自动化任务。此时，用户直接在 noVNC 网页界面上完成登录、拖动滑块或输入验证码。完成后，通知 AI 任务可以继续，AI 随即通过 CDP 接管，完成剩余自动化操作。

关键步骤与原则：

• 部署后，所有浏览器操作必须通过本技能部署的 CDP 端口（9223）进行，禁止使用 Agent 自带的内置无头浏览器或启动新实例，以确保用户与 AI 看到的是同一画面。
• 为保证安全，noVNC 默认生成随机访问密码，且不建议将 CDP 调试端口（9223）暴露于公网。
• 服务被配置为系统服务（systemd），确保服务器重启后环境自动恢复，无需手动干预。

适用场景与明确边界

适合的场景：

• 需人工验证的网页自动化：例如，自动发布短视频到某音/某手、管理某博账号、登录各类 CMS 后台等。
• AI 与人共视共控：适用于需要实时看到 AI 操作过程并能随时介入的调试或协作场景。

不适合的场景：

• 纯 API 交互任务：如果目标网站提供完善的 API，无需浏览器画面，则应优先使用 API。
• 高安全敏感环境：不建议在对远程桌面暴露零容忍的生产环境中使用。
• 无 root/sudo 权限的 Linux 服务器：Linux 模式需要足够权限安装系统组件。Windows 模式则无此限制，它直接接管本机已安装的 Edge/Chrome。