为 AI 测试构建可接管的独立浏览器

让 AI 代替人打开网站、点击按钮，已经不算难事。难的是：它卡在登录页却说完成了，断线后测试现场消失了，或者为了方便接入，直接拿到了开发者日常浏览器里的账号。

Hronaut 的作者因此做了一个独立浏览器：AI 负责操作，人能随时接管，登录状态和标签页不随 agent 会话消失。这篇文章值得看的，是它把 AI 浏览器测试的问题，从「能不能点」推进到了「谁掌控现场、状态怎么保存、权限怎么隔离」。

AI 能操作浏览器，为什么还不够

作者团队需要的是接近真实用户的手动测试，包括慢网络、不同屏幕尺寸，以及登录后的操作流程。他们希望把执行交给 AI，同时保留人的观察和干预能力。

这让工具选择多了几项约束：浏览器必须可见，agent 重启后页面还在；每个任务使用独立身份；人负责登录；能够访问 localhost 和内部 staging；还要兼容 Claude Code、Codex、Cursor 等支持 MCP 的客户端。

作者遇到的问题很具体。他们使用 Playwright MCP 时，浏览器会随 agent 会话一起关闭，重启后需要重新登录、打开页面。无人观察执行过程时，只能事后读日志，而且 agent 有时停在登录页或空页面，仍然报告「完成」。

Chrome 扩展方案让作者担心工作浏览器里的邮箱和个人账号暴露给 agent；他们尝试的云浏览器则无法访问本地开发服务和内部环境。

这些都是作者所用方案下的体验，不能据此推断所有 Playwright MCP 配置、Chrome 扩展和云浏览器都有同样限制。

作者真正要解决的是让人和 agent 共用一个可控的测试现场。

把浏览器独立出来，才能保住测试现场

Hronaut 是支持 Windows、macOS、Linux 的 Electron 桌面应用。agent 在普通 Chromium 窗口中操作，人可以实时观察，一键暂停、接管，再把控制权交回去。需要人工登录、通过检查或确认动作时，应用会通知用户，并标记对应标签页。

浏览器进程独立于 agent 会话。agent 断开，浏览器继续运行；重新连接后，可以回到原来的标签页。

这里的组织单位是工作区（workspace）。每个任务拥有独立的 cookies、存储和登录状态，工作区有稳定 ID，agent 创建后会拿到私有恢复密钥（resume key）。作者称，重连时 agent 只能回到自己的工作区，看不到其他工作区。

为避免多个 agent 同时操作同一页面，Hronaut 采用独占写入：一个工作区同一时间只有一个客户端可以执行写操作，读取则可以共享。它还提供观察者工作区：使用干净、未登录的身份，绑定一个站点，只允许查看，适合检查访客视角。

登录状态也采用复制机制。人先登录，agent 再使用包含 cookies 和 localStorage 的副本，原始环境保持独立。这样可以减少对原始会话的干扰，但副本依然带有登录权限，不能把「拿不到密码」理解成「没有账号权限」。

MCP 负责接入，页面检查负责减少误报

Hronaut 内置 MCP server，使用 Streamable HTTP transport，只监听 127.0.0.1，默认端口为 47812。agent 连接后，可以打开标签页、导航、点击、输入、读取页面和截图。

MCP 在这里承担的是工具接口，模型和 agent 仍由用户自己提供。Hronaut 本身不会自动编写测试。

Claude Code 可以通过以下命令安装接入插件：

/plugin marketplace add hronaut/hronaut
/plugin install hronaut@hronaut

要注意第二行的 hronaut@hronaut 是完整插件标识。作者称，插件每次连接时都会从 Hronaut 的 token 文件读取凭据。

MCP endpoint 默认启用 token 鉴权，token 存放在仅文件所有者可读的文件中。作者强调，接入说明通过读取文件获取 token，避免把它直接写进 agent 配置或聊天。Codex 和其他客户端则从 Hronaut Home 页面复制配置；原文没有展开具体字段。

连接后，可以用 /mcp 检查状态，再让 agent 创建名为 first-check 的工作区，打开 https://example.com 并返回页面标题。

针对「没检查到内容却说完成」，Hronaut 还提供页面质量检查：判断当前页面是否有真实内容，还是空壳、登录墙、软 404，或者已经跳到其他域名。软 404 指页面实际没有目标内容，却未正常返回 404 状态的情况。

这类检查能补上操作成功与任务完成之间的缺口。不过，原文没有提供误报率或漏报率，尚不能判断它的可靠程度。

我的判断

我认同把人工接管、会话持久化和任务隔离放到优先级前面。对于登录后才能测试的前端页面，反复恢复现场会打断工作；可见窗口也让人更容易发现 agent 正在错误页面上继续操作。

但这篇文章同时是一篇产品自述。作者就是 Hronaut 开发者，披露了使用 AI 辅助写作，也没有给出与其他方案的对照测试。它说明了设计动机，尚未证明效率或安全性更好。

安全承诺尤其需要分层理解。作者称，agent 从页面读取的信息会经过过滤，隐藏密码、API keys、会话标识和签名 URL，但没有说明过滤覆盖哪些读取路径，也没有交代截图中的敏感信息如何处理。现有描述不足以证明所有输出都经过脱敏。

登录状态复制解决了环境干扰问题，却不会自动消除误操作风险。

选择上也有明确边界：首次 agent 调用起算，免费试用 10 天，无需绑卡，之后需要订阅。代码在 GitHub 可读，但使用自有许可证，并非开源。构建尚未代码签名，安装时可能触发 Windows SmartScreen 或 macOS Gatekeeper 提示；作者提供了哈希和 GitHub 构建证明供核验。

它还要求 agent 与浏览器运行在同一台机器上，不适合服务器端数百个浏览器的规模。对于无需登录的自动化测试，作者自己也承认，免费 Playwright MCP 如果已经够用，就没有必要换。

能拿来做什么

• 如果你正在让 AI 检查前端页面，可以先把验收条件写清楚：确认登录身份、目标域名和关键内容确实出现，再接受「完成」报告。
• 如果登录和恢复页面经常打断调试，可以优先评估浏览器会话能否独立保存，以及 agent 重连后能否回到同一现场。
• 如果多个 agent 并行检查网站，可以借鉴任务独立工作区和单客户端写入的设计，减少共享账号状态与同时点击造成的干扰。
• 如果现有 Playwright MCP 已能完成测试，先确认自己是否确实需要人工接管、登录状态复制和本地可见窗口，再决定是否增加一个付费工具。