技能介绍

要解决的具体问题

在本地把浏览器自动化跑起来，看起来只是安装 Playwright，实际上要同时维护 Chromium 版本、系统依赖、代理出口和并发隔离。当多个 Agent 同时工作时，还要处理抢端口、抢临时 profile、清理残留进程等问题，任何一处失控都可能导致任务相互干扰。更棘手的是机器人检测：现代站点会将“常驻浏览器”视为风险信号，本地环境经常在执行到一半时突然要求验证。

技能如何工作

Browserbase MCP Server 把浏览器执行层交给 Browserbase，把浏览器动作语义交给 Stagehand，再通过 MCP Server 暴露给 Agent。核心能力包括：

接入 MCP：Agent 使用 MCP 工具调用云浏览器能力，无需在本地维护浏览器运行时。
托管 HTTP 或自托管 stdio：前者适合快速接入云端服务，后者适合需要自行控制进程生命周期的部署。
Browserbase 会话：浏览器运行在云会话中，Agent 只需描述目标，不直接管理 Chromium。
Stagehand 动作模型：通过动作抽象驱动浏览任务，减少直接拼接底层 API 的维护成本。

典型工作路径是：Agent 发起浏览目标 → 通过 MCP 调用云浏览器 → Stagehand 拆解并执行动作 → 页面状态与结果返回 Agent。这种方式将执行环境从本地机器转移到云端，适合需要稳定浏览器出口，但不希望长期维护浏览器基础设施的团队。

适用边界与注意点

适合已经在使用 MCP 兼容 Agent 框架，并接受云会话执行方式的团队。如果任务要求离线运行、强数据本地化，或需要精细控制 Chromium 启动参数，应改用自托管方案。云浏览器会带来网络往返延迟，并依赖托管服务的可用性；动作语义以 Stagehand 文档为准，复杂的多步编排仍需在 Agent 层完成。