前言¶
做 Agent 相关工作时，浏览器这一层常被拆得很碎：有的脚本只跑无头请求，有的流程要靠人工登录，有的截图和扩展捕获又散落在各自的工具里。结果是同一条任务链上要维护多套浏览器方案，登录态、页面导航、截图来源都不一致。下面介绍的浏览器助手（Browser Orchestrator）就是针对这个切口的 Skill，定位是作为 MCP Relay 侧的有界面 Browser Node，把配对、登录态工作、页面操作和捕获尽量收拢到一处。
这是什么¶
浏览器助手由深圳亚汇讯发布并维护，在 SkillHub 上的坐标为 @yahuixun/browser-orchestrator，来源标记为 enterprise，分类为 ai-agent。它解决的问题很具体：当上层通过 MCP Relay 驱动浏览器时，需要一个能保持有界面、能承载登录态、并按配置做页面导航与捕获的节点，而不是每次从零搭一套浏览器环境。
从 SkillHub 页面可核对的元数据如下：
名称: 浏览器助手
坐标: @yahuixun/browser-orchestrator
版本: 0.1.5
来源: enterprise
分类: ai-agent
发布者: 深圳亚汇讯
标签: requires_api_key=true
可核对的能力清单¶
官方简介列出的能力范围，按用途分成四组说明，便于判断它覆盖到哪一层。
- Relay 配对。负责与 MCP Relay 建立配对关系，让上层能把这个浏览器节点当作一个可用的浏览器端。
- 已认证的 worker 连接。在配对之后维持经过认证的连接，而不是裸露地共享一个浏览器实例。
- 手动登录安全的浏览器工作。面向需要人工登录的场景，让浏览器在有界面状态下承接登录态相关的操作，降低把凭据交给自动化流程的风险。
- 本地 MCP 回退。当 relay 链路不可用时，退回到本地 MCP 路径继续工作，保证浏览器能力不整条断掉。
页面操作与捕获方面，简介明确了三类动作：页面导航、截图，以及按配置捕获已启用的扩展内容。也就是说，它不是只负责“打开页面”，还把结果留存和扩展侧输出纳入了同一口径。
启用前提与限制¶
使用前提里最需要先确认的一点，是标签 requires_api_key=true。这意味着它不是开箱即用、无需任何密钥的通用工具，启用前要先准备好对应的 API Key，并确认密钥所属环境与 MCP Relay 的运行环境一致。
其次是环境匹配。它面向的是 MCP Relay 体系中的 headed Browser Node，也就是需要有界面的浏览器节点。如果你的运行环境只打算跑无头浏览器、或者不接入 MCP Relay，这套定位就不直接适用，本地 MCP 回退只是链路层兜底，不代表它变成无头浏览器方案。
第三是扩展捕获的范围。简介写的是“configured extension capture”，属于按配置触发的捕获，而不是无条件抓取所有扩展输出。哪些扩展参与捕获、捕获到什么粒度，取决于实际配置；公开资料里没有给出可直接核实的扩展清单与配置字段，这部分需要在启用时按你自己的环境确认。
第四是数据口径。SkillHub 页面显示的评分与下载量会随时间变化，本文以抓取到的页面资料为准，不把页面数据当作稳定结论，也不据此推断服务质量。
适用场景¶
适合的场景是：已经在用或准备用 MCP Relay 驱动浏览器，任务里包含需要登录态的页面操作，希望截图、导航和扩展捕获有统一来源，并且愿意先配置 API Key。
不适合直接照搬的场景是：只做静态页面抓取且无需登录、只跑无头渲染、或者不打算接入 MCP Relay 的项目。这类需求更适合各自的专用工具，不必为此引入一个面向 relay 体系的浏览器节点。
结尾¶
浏览器助手的价值不在于多一套浏览器脚本，而在于把有界面浏览器节点的配对、登录态工作、页面导航、截图和扩展捕获放到同一个 MCP Relay 入口后面，减少多套方案并存带来的不一致。需要先确认的是 API Key 与运行环境是否匹配。官方地址：https://api.skillhub.cn/yahuixun/browser-orchestrator
