您的代理驱动一个真实的浏览器。
不是假的。

AgentsRoom 中的 Browser Automation 把两件事合二为一。第一，每个项目 room 中嵌入的真实 Chromium 浏览器，包含 URL 栏、back/forward、reload、history、截图到剪贴板、用默认浏览器打开、按项目持久化的 cookies 和 localStorage。第二，通过 Model Context Protocol 把该浏览器暴露给您的 AI 代理的 AgentsRoom Browser MCP 服务器（agentsroom-browser）。代理获得一个干净、可脚本化的接口：navigate、click、type、screenshot、求值 JavaScript、等待元素、获取页面状态、获取 console 日志、后退、前进、重新加载。

为什么这件事重要？因为当代理说 '功能已交付' 但从不打开页面检查时，AI 编码代理的整个承诺就崩塌了。今天大多数代理依赖运行单元测试，然后祈祷。有了真实的 browser MCP，代理加载 localhost 服务器，跑一遍用户流，看到人类用户会看到的东西，之后才签收。QA Engineer 代理角色终于有了它需要的工具来做真正的 QA，而不只是静态分析。

技术设置对您来说是不可见的。当您在代理上勾选 'Browser access' 时，AgentsRoom 把 agentsroom-browser 条目合并进项目的 .mcp.json，代理启动时就带有可用的浏览器工具。一个运行在 loopback 端口（127.0.0.1，OS 分配，每次启动重新生成，用 32 字节 hex token 认证）上的 WebSocket 桥连接 MCP 子进程到 Electron 应用中的 Chromium WebContentsView。每次点击、每次输入、每次截图都是一次 JSON-RPC 调用。代理看到的是真实浏览器，不是桩。

一个真实的浏览器，不是 Playwright 桩

大多数谈到浏览器自动化的 AI 代理 demo 在每次工具调用时 spawn 一个 headless Playwright 实例。这对 benchmark 有效，但在现实生活中很痛苦：您看不到代理在做什么，每次 navigation 都重新 spawn Chromium，cookies 丢失，localStorage 为空，您的 dev 服务器以为每次访问都是全新会话。AgentsRoom 取另一个角度。浏览器已经在您的项目 room 中打开（您自己像普通浏览器一样使用它），代理驱动那个浏览器。会话、cookies、localStorage、登录状态，全部保留。

代理的每次点击和输入触发通过 Electron WebContentsView 的真实原生分发，带有正确的键事件、鼠标事件和 DOM 变更。截图是从实际渲染页面捕获的真实 PNG（不是 DOM-to-image 的 hack）。console 日志被缓冲并可查询，包括警告和错误。代理看到的和您打开 DevTools 时看到的是同一种东西：真实的性能、真实的网络行为、真实的 CORS、真实的 auth。

Room 间隔离被强制执行。AgentsRoom 为每个项目创建一个 Chromium WebContentsView，带有自己的会话分区（persist:agentsroom-browser-<projectId>）。项目 A 的 cookies 永远不会泄漏到项目 B。当您切换项目时，前一个浏览器被隐藏，新的浏览器以自己的状态上线。代理总是落地在正确的项目，带着正确的凭据。

MCP 层有意保持小巧且零依赖。browser-mcp-server.cjs 子进程通过 stdio 说 MCP 2024-11-05 协议（initialize、tools/list、tools/call），并把它翻译成通过 loopback WebSocket 桥的 JSON-RPC 调用。与重型 SDK 服务器相比，这保持了快速（首次工具调用低于 100ms）和易于调试。在每次改变页面的动作（点击、输入、navigate、reload、back、forward）之后，响应包含一张上限 1.6 MB 的 base64 PNG 截图，这样代理总能看到它刚才做的事的结果。这件事原来是最大的可靠性提升之一：看到屏幕的代理远比抱有希望的代理更频繁地做对事。