BrowserPair：让AI智能体接入你现有的Chrome浏览器

AI智能体可以写代码、回答问题、调用工具，但在我自己的工作流里，有一件事始终别扭：让AI助手在我已经打开的Chrome浏览器里干活。

常见做法是启动一个全新的自动化浏览器。这对测试和隔离自动化很有用，但对于依赖我现有标签页和已登录会话的交互式任务，并不总是合适。

我独立开发了BrowserPair，探索另一种路径：将AI智能体连接到用户现有的Chrome浏览器，同时让权限与执行边界变得可见。

问题不只是“点击”

驱动网页只是智能体自动化的一部分。在智能体点击任何东西之前，你得先回答几个问题：

• 它被允许访问哪个网站？
• 用户授权了哪些操作？
• 敏感操作是否需要批准？
• 我们如何知道某个操作成功了？
• 如果表单提交后网络连接断开，会发生什么？

最后一种情况尤其关键。假设智能体在表单上点击了提交，但在收到确认前连接中断。重复该操作可能产生重复的消息、订单或记录。系统应当区分“操作失败了”和“我们不知道它是否完成了”。

这听起来像是个工程细节，但它直接决定了智能体能否被放心地用在真实业务系统里。一个只会“重试”的智能体，在支付、下单、发消息这类场景中就是灾难。

“操作失败了”与“我们不知道它是否完成了”的区分，在分布式系统中被称为不确定执行结果（indeterminate outcome）。典型场景是：客户端发出请求后连接中断或超时，请求可能已被服务端处理，也可能根本没有到达。此时盲目重试会带来至少一次（at-least-once） 语义下的重复副作用，例如重复下单、重复发消息。

工程上常见的应对思路有三种：一是让操作具备幂等性，即同一请求重复执行与执行一次效果相同，例如使用幂等键；二是执行前先查询状态，确认操作是否已经落地；三是把“未知”作为独立状态暴露给用户或上层逻辑，由人工或更高级的策略决定后续动作。BrowserPair 把“未知”作为一等状态处理，正是把这类分布式系统的基本约束引入了浏览器智能体场景。

BrowserPair 做了什么

BrowserPair 由三部分组成：一个Chrome扩展、一个用于管理浏览器任务和权限的应用，以及面向AI客户端的集成。

它的核心设计选择包括：

使用你已有的浏览器。 扩展连接到用户现有的Chrome环境，而不是为每次交互创建独立的浏览器会话。这意味着智能体能直接利用你已经登录的账号、已打开的标签页和已有的Cookie状态。

保持AI客户端可互换。 兼容MCP的客户端可以连接到浏览器。BrowserPair还提供了自带密钥（BYOK）的聊天体验，让你使用自己选择的AI提供商。

限定访问范围。 系统围绕站点和操作权限来设计，而不是授予无边界的浏览权限。

在适当的时候请求人工批准。 敏感操作可以暂停，等待用户明确确认。

保留执行证据。 智能体应当观察实际结果，而不是假设一次已派发的点击或表单提交已经成功。当结果未知时，盲目重放同一操作是不安全的。

MCP（Model Context Protocol） 是由 Anthropic 提出并开源的协议，用于标准化 AI 模型与外部工具、数据源之间的连接方式。可以把它理解为 AI 领域的“USB 接口”：客户端（如 Claude Desktop、各类 AI IDE）通过统一的协议描述自己可调用的工具，服务端则负责暴露能力并处理调用请求。BrowserPair 兼容 MCP，意味着任何支持该协议的 AI 客户端都能把浏览器当作一个可调用的工具集来使用，而不需要为每个客户端单独开发插件。

BYOK（Bring Your Own Key） 指用户使用自己的 API 密钥调用 AI 服务，而不是由平台统一代付和转发。对用户而言，这带来了成本透明（按自己的用量计费）和提供商选择自由；对产品而言，则避免了转售模型调用带来的合规与计费复杂度。BrowserPair 同时支持 MCP 客户端和 BYOK 聊天，本质上是在降低用户被单一 AI 提供商锁定的风险。

架构与取舍

平台的云端组件使用Cloudflare Workers、Durable Objects和D1。Chrome扩展是通往浏览器环境的桥梁，Web应用则给用户一个管理连接和任务的地方。

这并不是在宣称浏览器扩展能提供完美的执行沙箱。权限、审批和证据各自解决不同的问题。授权并不能消除与已认证网站交互的风险，审批提示也不会神奇地让工作流变得安全。

BrowserPair 也不打算取代Playwright或云端浏览器基础设施。那些工具非常适合自动化测试、可重复的无头任务和隔离环境。这个项目聚焦的是另一种用例：让现有的AI助手协助真实的交互式浏览器工作，同时让用户保留有意义的控制权。

换句话说，BrowserPair 的定位不是“更强的自动化”，而是“更可控的协作”。这两者的设计目标不同，评价标准也不同。

Cloudflare Workers 是运行在边缘网络上的无服务器运行时，适合处理低延迟的请求路由与轻量逻辑；Durable Objects 提供带有强一致性的有状态对象，适合用来协调同一浏览器会话或同一任务的状态，避免并发操作互相干扰；D1 则是 Cloudflare 提供的基于 SQLite 的托管关系型数据库，用于存储任务记录、权限配置等结构化数据。三者组合的典型模式是：Workers 处理入口请求，Durable Objects 维护每个会话的串行化状态与锁，D1 负责持久化。

需要说明的是，浏览器扩展本身并不构成安全沙箱。扩展运行在用户已登录的浏览器环境中，拥有页面访问权限，因此权限模型、审批流程和执行证据是互补的三道防线，而不能指望其中任何一道单独消除风险。这也是原文强调“授权并不能消除与已认证网站交互的风险”的原因。

我还在学习什么

有意思的工程问题都出在边缘情况，而不是顺利路径的演示。例如：

1. 权限粒度做到多细才合适，而不至于让界面变得令人疲惫？
2. 哪些操作应当始终要求人工确认？
3. 智能体应如何从未知结果中恢复，而不让事情变得更糟？
4. 执行证据如何对用户有用，而不至于淹没他们？

我独立构建了BrowserPair，并正在通过真实的浏览器工作流持续改进体验。

如果你构建过MCP工具、浏览器扩展或智能体自动化系统，我很想听听你是如何处理授权和不确定执行结果的。

试用 BrowserPair： https://browserpair.com

问题： 你更愿意把现有的AI助手连接到当前浏览器，还是使用一个独立的AI控制浏览器会话？

深度分析：现有浏览器接入的隐含价值

从产品角度看，BrowserPair 切中的是一个被忽视的缝隙。大多数AI浏览器自动化工具默认“干净环境”才是正确的抽象，但对普通用户而言，真正有价值的场景往往发生在他们已经登录、已经配置好、已经打开了一堆标签页的浏览器里。重新登录、重新配置、重新建立上下文，本身就是巨大的摩擦。

从安全角度看，这种设计也提出了更尖锐的问题。连接现有浏览器意味着智能体可能触达用户的真实账号和真实数据，权限模型不能只是“允许/拒绝”的二元开关。BrowserPair 对站点和操作进行范围限定，并要求对敏感操作进行人工批准，这是务实的方向，但粒度如何平衡仍需实践检验。

从生态角度看，MCP兼容和BYOK的设计降低了锁定风险。用户不必为了使用这个工具而更换AI提供商，这有助于它在已有的AI工作流中被采用，而不是要求用户重建习惯。

一个值得关注的细节是“未知结果”的处理。传统自动化脚本通常假设操作要么成功要么失败，但在真实网络中，超时和断连是常态。BrowserPair 明确将“不确定”作为独立状态来对待，这比简单的重试逻辑更接近真实世界的工程需求。

小结

BrowserPair 代表的是一种务实的AI智能体落地思路：不追求完全自主，不假装浏览器扩展是完美沙箱，而是把权限、审批和执行证据作为一等公民。对于需要在真实浏览器环境中使用AI助手的用户来说，这种“可控协作”可能比“全自动黑盒”更有长期价值。