BUA 的取舍：把浏览器能力交回 Desktop

BUA 是一个很有诱惑力的方向。

当 Agent 能进入浏览器，它就不再只是回答问题，而是开始接触真实工作的现场：SaaS 后台、公司内部系统、已经登录的 Notion、CRM、财务平台、招聘后台、客服工具。很多业务动作没有稳定 API，或者 API 能做的事远少于页面里能做的事。用户真正拥有权限和上下文的地方，往往就是自己每天打开的那个浏览器。

所以我们做过 BUA 组件。这不是一个偶然决定，而是很自然的一步。

但真正做过之后，也会更清楚地看到另一面：这条路在 Web 端维护起来很重。它不是“加一个浏览器工具”这么简单，而是要长期维护 Web app、后端、Chrome 扩展、浏览器权限、连接状态、审计、急停和用户感知之间的一整条链路。只要其中一环不稳定，用户看到的就是“Agent 又失败了”。

这让问题从“BUA 有没有价值”变成了更关键的产品判断：

浏览器能力应该成为哪个产品形态的主路径？

我们的答案越来越明确：BUA 仍然重要，但主流体验应该回到 Desktop。对 aibuddy 来说，更合理的路径不是继续把 Web 端自研 BUA 扩展当作主战场，而是在 Desktop 里复用 Chrome DevTools MCP 这类本地浏览器控制能力。

这不是放弃浏览器能力，而是把工程重心放回产品本身。

BUA 解决的是登录后的真实工作流

BUA 可以理解成 Browser Use Agent：让 Agent 使用浏览器完成任务。

它的重点不是抓取公开网页。公开网页可以搜索、fetch、调用 API，必要时也可以用普通浏览器自动化处理。BUA 真正有价值的地方，是那些必须发生在用户登录态里的任务。

比如，从招聘后台打开候选人详情，整理前 10 个候选人的联系方式；进入财务系统，导出某个时间段的发票；打开内部运营后台，对照表格逐项修改状态；在 Notion、Linear、CRM 和客服后台之间复制、检查、补全信息；或者让 coding agent 直接观察一个 Web app 的实际 UI 状态，再继续定位问题。

这些任务有一个共同点：关键上下文不在模型里，也不在公开互联网上，而在用户当前的浏览器会话里。账号、cookie、MFA 后的 session、组织权限、页面状态、临时筛选条件，都是任务的一部分。

因此，BUA 的价值不是“自动点击”。它更像 Agent 的一个执行面。它让 Agent 从文本和 API 世界进入业务系统，处理那些没有 API、API 不完整，或者临时用页面操作更划算的工作。

这个方向本身是成立的。问题只在于：应该用什么方式把它产品化。

浏览器自动化不是同一种产品

讨论 BUA 时，最容易出错的地方，是把所有浏览器自动化都当成一类能力。其实不同路线背后的产品假设完全不同。

云端 headless 浏览器适合公开 Web 自动化、批量抓取、测试、监控和规模化执行。它的优势是环境可控、并发容易、服务端调度自然。缺点也很清楚：它默认拿不到用户本机浏览器里的登录态。只要任务依赖用户自己的 cookie、MFA、企业 SSO、设备信任或浏览器 profile，云端干净浏览器就会遇到边界。

浏览器扩展解决的是另一类问题。它可以进入用户已经登录的 Chrome，把 Agent 的动作转成真实浏览器输入，并把页面状态、可交互元素和内容摘要返回给 Agent。我们之前的 BUA 组件就是这条路线：Chrome MV3 扩展通过 Chrome DevTools Protocol 执行动作，后端通过 BrowserBridge 派发请求，主 Agent 再把浏览器循环委派给内建 browser subagent。

这条路线的优点很直接：用户不用交出密码，也不用把 cookie 复制到远端。Agent 操作的就是用户真实的浏览器环境。

但扩展不是一个普通前端模块。它有自己的运行时、权限、生命周期和分发问题。MV3 Service Worker 会休眠，content script 有注入时机，debugger 权限会触发用户可见提示，扩展更新和内部发布有自己的节奏。再加上 Web app、后端、扩展之间的配对、鉴权、保活和重连，系统自然会变长。

Desktop 本地浏览器控制则是第三条路线。Desktop 应用本来就在用户机器上运行，天然更接近本机 Chrome、文件系统、凭证存储、进程生命周期和本地权限。Chrome DevTools MCP 属于这个方向：它把 Chrome DevTools 能力作为 MCP server 暴露给 Agent，让 Agent 可以控制和检查真实 Chrome，完成自动化、截图、网络观察、调试和性能分析。

还有一条路线是 API 和 connector。只要目标系统有稳定 API，或者用户愿意通过 OAuth 授权连接 Gmail、Calendar、Notion、Slack、Linear 这类服务，API 往往比浏览器操作更可靠。它有结构化 schema、错误码、权限边界和可测试性。浏览器能力应该补齐长尾工作流，而不是替代所有集成。

所以 BUA 不是浏览器自动化的唯一答案。它是“用户登录后的浏览器工作现场”这一类问题的答案之一。

Web 端的问题是失败面太宽

我们已经证明过 Web 端 BUA 可以做出来。

项目里的设计并不粗糙：BUA 是 Chrome MV3 扩展；Agent 通过 BrowserBridge 把动作派发给扩展；主 Agent 不直接使用 browser 工具，而是委派给内建 browser subagent；子 Agent 在独立上下文里执行 extract → click → wait → extract 这样的循环，最后只把 summary 交回主线程。

这个架构判断是对的。浏览器任务的最小单位通常不是一次 click，而是一段持续观察和行动的循环。如果主 Agent 直接跑 10 到 20 次 browser action，主对话会被大量页面细节污染，成本也会随主对话长度增长。把浏览器循环放进子 Agent，能隔离上下文，也能让主线程保持干净。

但架构合理，不等于它应该成为 Web 产品的主路径。

Web 端 BUA 的失败面太宽。用户看到的只是一个简单期待：“帮我打开这个页面，把里面的信息整理出来。”系统背后却要同时保证几件事：Web app 要知道扩展是否在线，后端要能把请求路由到正确的用户实例，扩展要能在正确 tab 上挂载 debugger，浏览器状态不能漂移，session 要能审计和清理，用户随时要能停止。

任何一段不稳，体验都会塌成同一种结果：Agent 没完成任务。

更麻烦的是，这些问题很多并不服务于我们的核心产品判断。我们真正想打磨的是 Agent runtime、上下文管理、长任务体验、工具协作、结果交付和用户工作流，而不是长期处理扩展休眠、配对状态、权限提示和跨运行时连接这些边缘复杂度。

还有一层产品心智的问题。Web 产品天然适合多人、多设备、云端协作；但 BUA 操作的是某一台机器上的某一个浏览器 session。它的状态是本地的、瞬时的、强环境依赖的。把这种能力放在 Web 端当主路径，产品边界会变得不清楚：用户以为自己在使用云端 Web 产品，实际上关键动作依赖本机浏览器、扩展、tab 状态和本地权限。

这不是不能解释，但解释成本本身就是一个信号。

Desktop 更像浏览器能力应该待的位置

BUA 的核心资源本来就在本地：浏览器、登录态、文件、开发环境、桌面应用、本机权限，以及用户当前机器上的工作上下文。

这和 Desktop 的产品定位天然贴合。

Desktop 不是 Web app 的外壳。它更适合成为一个本地 AI 工作台：能读取项目文件，能调用本机工具，能管理 MCP server，能连接本机浏览器，也能处理长任务里的中间状态。用户打开 Desktop，本来就在授权一个更贴近自己工作环境的 Agent。

在这个产品契约下，Chrome DevTools MCP 就更自然。

它把浏览器控制放在 MCP 这层工具协议里，而不是让我们维护一套 Web app、后端和扩展之间的私有桥。Agent 通过 MCP 调用 DevTools 能力，连接真实 Chrome，获得页面检查、截图、网络和自动化能力。对 coding agent 来说，这也符合它已经在使用 MCP 连接文件、命令、服务和外部工具的方式。

这条路线当然也有安全边界。Chrome DevTools MCP 的官方说明明确提醒，它会把浏览器实例内容暴露给 MCP client，用户不应该在其中打开不想分享给 Agent 的敏感信息。也就是说，它不是“没有风险”的路线。

但从产品和工程取舍看，它更诚实：本地能力由 Desktop 承载，本地浏览器通过本地工具接入，用户在同一个本地工作台里理解权限边界。复杂度没有消失，但它回到了更合适的位置。

这次取舍换回的是产品专注

把主路径转向 Desktop + Chrome DevTools MCP，会失去一些东西。

最明显的是 Web 端的一体化叙事。用户不能只打开 Web app，就期待 Agent 无缝控制本机浏览器。对于纯 Web 产品来说，这少了一点“所有能力都在网页里完成”的想象。

我们也会少一些底层控制。自研 BUA 扩展可以完全定义 action schema、session 模型、审计 UI、blocklist、subagent prompt 和错误恢复。使用 Chrome DevTools MCP，就要接受 MCP server 的能力边界、版本节奏和安全模型。

但换回来的东西更重要。

首先是维护面变小。浏览器控制、DevTools 接入、部分自动化稳定性和调试能力，可以交给更贴近 Chrome 生态的工具。我们不需要把大量精力放在扩展桥的边缘状态上。

其次是产品边界更清楚。Web 端继续适合展示、协作、轻量任务和云端能力；Desktop 端承担本地工作环境里的深度 Agent 能力。浏览器控制属于后者，不必在两个 surface 上平均用力。

第三是用户信任边界更清楚。Desktop 是一个本地授权的工作台。用户更容易理解：这个应用可以接触本机文件、浏览器、MCP server 和开发环境。相比之下，在 Web 页面里发起对本机浏览器的远程控制，心智上更容易产生不确定感。

最后，我们也保留了未来弹性。如果有一天确实要面向外部用户提供 Web BUA，那应该把它当作一个独立产品来设计：有明确 consent UI、分发策略、权限模型、合规说明和更严格的用户控制。而不是让一个内部能力长期背负公共产品的复杂度。

这就是这次 tradeoff 的核心：不是浏览器能力不重要，而是它不该消耗掉产品最稀缺的注意力。

回到我们真正要做的事

早期自研 BUA 是值得的。它让我们真正理解了浏览器任务的形态：不是一次 click，而是观察、等待、行动、再观察的循环；不是让主 Agent 直接处理所有页面细节，而是要用独立上下文隔离复杂度；不是只要能自动化就行，还要有审计、急停、错误契约和生命周期管理。

这些理解会留下来。

但理解机制之后，产品必须回到更朴素的问题：这是不是我们最应该长期维护的部分？

对 aibuddy 来说，答案是否定的。

我们的重心应该是一个可靠的 AI 工作台：理解任务，管理上下文，调用工具，组织长任务，交付结果，并且让用户知道系统正在做什么、做到了哪里、为什么失败、下一步该怎么恢复。浏览器能力是其中一个重要工具，但不是我们要证明自己的地方。

所以这次取舍可以概括成一句话：

BUA 是能力方向；Desktop 是产品主路径；Chrome DevTools MCP 是更合适的实现杠杆。

把重心放回产品本身，不是退一步，而是停止在错误的层面消耗创造力。

参考来源

• Chrome DevTools MCP —— 官方 Chrome DevTools MCP 项目，说明其 MCP server 让 coding agent 控制和检查真实 Chrome 浏览器。
• Browser Use Open Source —— Browser Use 对 AI 浏览器自动化路线的开源说明。

相关阅读

• 智能体需要 Harness，不只是更强的模型 —— 浏览器能力只是工具，真正决定可用性的仍然是 Harness。
• Agent 长任务的瓶颈，是上下文工程 —— 浏览器任务中的多轮观察和操作，最终也会回到上下文质量。
• AI Builders：从会用 AI 到交付系统 —— 真正的 AI builder 关心的是可交付系统，而不是单点能力展示。