用 Bruster 接通 Claude Code 浏览器操作

让 Claude Code 操作本地网页，难点不只是接上浏览器，还要确认它真的完成了任务。Bruster 提供了一条可复现的路径：通过 MCP 连接原生 WebView，让 Claude 检查表单、填写字段、提交，再读取结果并截图。

这份教程最有用的地方，是把「执行动作」和「验证结果」放进同一个流程。但它展示的是一个本地表单样例，不能据此推断复杂网站也能稳定跑通。

接上 MCP 之前，先分清运行环境

Bruster 是开源的 Rust 浏览器控制器，内置 Model Context Protocol（MCP）服务器。MCP 在这里承担工具接口的作用，让 Claude Code 能调用浏览器能力。

Bruster 服务端不需要 Node.js，但 AI 客户端和浏览器运行时仍有各自的依赖。「不用 Node.js」不等于整个流程没有环境要求。

教程要求 Claude Code 已安装并登录，下面的 shell 操作面向 macOS 或 Linux。安装使用 curl -fsSL https://raw.githubusercontent.com/aliilyas/bruster/main/install.sh | sh，随后执行 export PATH="$HOME/.local/bin:$PATH"，用 command -v bruster 检查路径。

Ubuntu、Debian 还需要 sudo apt install libwebkit2gtk-4.1-0。没有桌面显示环境的 Linux 机器需要 sudo apt install xvfb xauth。隐藏窗口也需要渲染显示环境；DISPLAY 未设置时，Bruster 会尝试自动启动 Xvfb。

样例页面这样启动：

git clone https://github.com/aliilyas/bruster.git
cd bruster
python3 -m http.server 8765 --bind 127.0.0.1 --directory examples/launch-demo

注意最后一行：Python 3 只负责提供本地 HTTP 服务，Bruster 本身不依赖它。保持终端运行，访问 http://127.0.0.1:8765，确认 Browser smoke test 表单能打开。提交只生成本地回执，不会发送到外部服务。

接着在第二个终端进入克隆目录，注册 MCP：

claude mcp add --transport stdio bruster -- "$HOME/.local/bin/bruster" --mcp --quiet
claude mcp get bruster
claude

注意第一行的 --：前面是 Claude 的选项，后面是 Bruster 的可执行文件和参数。绝对路径可以减少终端与 MCP 启动环境之间的 PATH 差异。默认注册范围限于当前项目，进入 Claude Code 后再用 /mcp 检查连接。

真正该交给 Claude 的，是可核对的结果

教程让 Claude 先检查表单，再填入姓名 Ada Lovelace、项目 Bruster，选择 Form submission，勾选 Include screenshots。提交前，还要读取实时 JSON 预览，确认四个字段：

name 为 Ada Lovelace，project 为 Bruster，workflow 为 forms，screenshots 为 true。

之后点击 Create smoke test，检查回执标题是否为 Smoke test created for Bruster，详情是否包含 Ada Lovelace、Form submission 和 Screenshots: on，最后返回截图并报告失败项。

点击成功，只能证明动作执行了；读取提交后的状态，才能核对目标是否达成。

教程给出的工具顺序是 navigate → snapshot → fill_form → text → click → text → screenshot，Claude 也可能选择其他组合。关键不在调用顺序完全一致，而在提交前后都有明确的核对点。

这张图来自仓库在 WebKitGTK 上运行的脚本化 MCP 演示，是真实浏览器截图，但不是 Claude 对话记录。原文说明仓库提供了演示记录、构建信息和复现步骤；它证明了样例流程可复现，没有提供 Claude 多次执行的成功率。

原生 WebView 能检查什么，也会限制什么

Bruster 在 macOS 使用 WKWebView，在 Linux 使用 WebKitGTK，在 Windows 使用 WebView2，其中 WebView2 基于 Chromium。Windows 也受支持，但需要对应的安装包和客户端配置，不能直接照搬这组 shell 操作。

想观察操作过程，可以先执行 claude mcp remove bruster，重新注册时在服务参数中加入 --visible，例如 --mcp --quiet --visible。修改注册后要重启 Claude Code，可见模式需要桌面会话。

需要跨次保留 cookies 和存储时，可以添加 --profile "$HOME/.local/share/bruster/claude-demo"。它创建独立的 Bruster 配置目录，不会接入日常浏览器已有的登录会话。

边界也很明确：跨域 iframe 交互和操作系统级控件不在支持范围内。若需要可选择多种浏览器引擎，原文建议同时评估 Playwright MCP；若要构建完整回归测试，还得单独比较测试运行器的要求，不能只看 MCP 接口。

我的判断

我认可这套任务设计：先检查控件，再执行动作，最后读取状态。它把一句模糊的「帮我测一下表单」，变成了能逐项核对的验收要求，前端开发者可以直接借鉴。

工具选型则要收着看。这是项目维护者编写、由 AI 辅助准备的教程，使用的是随仓库提供的受控样例。原文没有给出复杂应用表现，也没有与 Playwright MCP 做成功率、速度或资源占用对照。因此，不能替它得出「更轻、更快、更可靠」的结论。

原生 WebView 是明确的技术选择，但是否合适取决于目标运行环境。对已有回归测试的团队，这条流程更适合作为一次定向检查的候选方案，能否纳入持续集成还需要另外验证。

能拿来做什么

• 给本地表单写 AI 任务时，同时列出输入值、提交前预览和提交后回执，让 Claude 报告具体失败项。
• 首次接入时用 --visible 观察操作，确认它找对控件、读对结果，再考虑隐藏窗口运行。
• 验证需要登录态的页面时，使用独立 --profile 建立测试会话，提前处理登录准备工作。
• 先挑应用里的一个表单复现完整流程；涉及跨域 iframe、多引擎验证或完整回归时，再按需求评估其他工具。