BrowserMan vs Browser MCP
Browser MCP 和 BrowserMan 表面上很像：都通过 Chrome 扩展和 MCP，让 AI Agent 操作你真实、已登录的浏览器。区别在于中间链路。Browser MCP 完全运行在你的电脑上，Agent、MCP Server 和浏览器必须在同一台设备上；BrowserMan 增加托管中继，让任意位置的 Agent —— 云端、容器、定时任务、远程服务器 —— 都能访问你的浏览器，同时保留你真实的已登录会话。
简要结论
| 能力 | Browser MCP | BrowserMan |
|---|---|---|
| 使用你真实、已登录的 Chrome | ✓ | ✓ |
| 支持运行在其他机器或云端的 Agent | ✗ | ✓ |
| 可接入 ChatGPT、n8n、Slack Bot、定时任务 | ✗ | ✓ |
| 支持 X、LinkedIn、Reddit、微博、小红书、B 站、知乎等站点的内置动作 | ✗ | ✓ |
| 一个账户管理多个浏览器 / 多个配置文件 | ✗ | ✓ |
| 网页授权式配置（无需复制粘贴 API Key） | ✗ | ✓ |
| 纯本地链路，没有第三方中继 | ✓ | ⚠ |
| 开源 | ✓ | ⚠ |
架构一图看懂
Browser MCP 的架构对单台电脑很优雅：没有网络中转、没有账户系统，也不需要信任额外服务器。但它要求每个组件 —— 包括 Agent —— 都和浏览器在同一台设备上。如果你的 Agent 运行在容器、定时任务，或 n8n、ChatGPT 这类云端服务里，Browser MCP 就够不到你的浏览器。
BrowserMan 多加了一层很薄的托管中继：browserman.run。它只在 Agent 和扩展之间转发命令，不执行操作，也不保存页面内容、Cookie 或密码。敏感内容仍留在你真实的 Chrome 里；你得到的是访问范围 —— Agent 可以在任何地方运行。
适合选择哪一个？
适合选择 Browser MCP 的情况
- 你的 Agent 始终和浏览器运行在同一台电脑上（Claude Desktop、macOS 上的 Cursor、本地脚本）。
- 你更看重严格的纯本地链路，不希望中间有第三方服务。
- 你不需要内置动作，可以接受让 LLM 自己理解 DOM 结构。
- 你需要一个没有账户系统的纯开源依赖。
适合选择 BrowserMan 的情况
- 你的 Agent 运行在云端（ChatGPT、Claude.ai、n8n、Zapier、服务端定时任务），但需要访问你已登录的浏览器。
- 你运营社交媒体，希望用
xiaohongshu.com/post这类一次调用的动作，而不是让 LLM 每次重新学习平台 DOM。 - 你需要从一个账户管理多个浏览器或多个配置文件。
- 你希望非开发者也能完成配置：在网页上批准访问，而不是把 API Key 复制进配置文件。
- 你需要可审计性：活动日志、限定范围的令牌、控制台一键吊销。
Browser MCP 真正更强的地方
Browser MCP 的信任模型更简单。Agent 和扩展之间没有中继服务器、没有用户账户，也没有需要持续维护的托管服务。对只想让本地 Claude Desktop 使用浏览器的开发者来说，这是最轻量的答案。BrowserMan 增加了托管中继、账户控制和内置动作，也意味着你需要信任这项服务来转发流量（即便它不保存敏感数据）。
Browser MCP 是纯本地方案，也有成熟的开源生态。如果「必须没有第三方中继」或「必须完全开源」是硬性要求，这一点很重要。
BrowserMan 真正更强的地方
只要 Agent 不在你的电脑上运行，Browser MCP 就够不到你的浏览器，而 BrowserMan 的架构优势就开始显现。这不是小众边界情况，而是几乎所有生产场景都会遇到的问题：
- 定时或无人值守任务。运行在服务器上的 cron 任务，无法通过 Browser MCP 操作你 MacBook 上的浏览器。通过 BrowserMan 的中继可以做到：你这端的浏览器保持连接，服务端 Agent 只需调用 API。
- 云端 Agent。ChatGPT、Claude.ai 和多数 SaaS Agent 平台运行在别人的基础设施里，不能直接打开到你电脑的 stdio 管道，但可以调用 HTTPS 中继。
- 团队 / 公司部署。IT 团队可以把 BrowserMan 扩展部署到员工电脑上，再构建内部 Agent 操作这些浏览器；同时保留活动日志、限定范围的访问和按员工一键吊销。Browser MCP 没有账户模型来承载这类流程。
- 特定平台自动化。BrowserMan 提供 13+ 个平台的内置动作，包括微博、小红书、B 站、知乎等中文社交平台。差别在于：你可以直接调用小红书发帖动作，而不是让 LLM 用十几轮对话重新理解平台 DOM。
- 非开发者配置。BrowserMan 的流程是：打开链接、登录、批准访问。Browser MCP 的流程是：安装扩展、安装 MCP Server、编写引用本地命令的配置文件。
Token 成本和可靠性呢？
两者都会向 Agent 暴露类似可访问性树的页面接口，所以基础读页的 Token 成本接近。BrowserMan 进一步拉开差距的地方在内置动作：已覆盖平台上的操作可以收敛成一次带类型参数的工具调用，而不是 10 到 20 轮「读取页面 → 点击 → 再读取页面」。这会直接降低延迟、Token 开销和失败面。
常见问题
Browser MCP 能不能改造成远程可访问？
可以，但你需要自己搭隧道、暴露端口，或维护额外基础设施。本质上等于重新实现 BrowserMan 中继提供的能力，再加上账户、会话和审计层。
BrowserMan 的中继会看到我的 Cookie 或页面内容吗？
不会。中继只在 MCP 桥接层和扩展之间转发命令信封。真正执行操作、访问 DOM、处理 Cookie 都发生在你真实的 Chrome 扩展里。Cookie 和密码不会经过 BrowserMan 服务器。
我已经配置了 Browser MCP，还能继续用吗？
可以，它们不冲突。如果你只需要同一台电脑上的 Agent，Browser MCP 就足够。很多用户会同时使用两者：本地开发用 Browser MCP，需要云端触发或定时执行时用 BrowserMan。
BrowserMan 是开源的吗？
扩展和 CLI 组件是公开的；托管中继作为服务运行。如果你硬性要求纯本地、全开源，Browser MCP 更符合这个条件。