推荐使用 BrowserSkill

【科普】灵犀专业版官方内置Browser技能、浏览器连接器与灵犀浏览器助手

灵犀专业版内置的 Browser 技能选择了一条"深度绑定"的路线：它的 Python 层通过 SKILL_PATH 环境变量（由灵犀桌面端注入）定位技能目录，加载 CDP 客户端，通过 HTTPCDPClient 将命令转发给本地 native-host 服务，再通过浏览器插件在目标标签页上执行。用户通过元素索引（整数）与页面交互，无需关心 CSS 选择器或 DOM 结构。当插件不可用时，自动降级到内置的 ungoogled-chromium 无头浏览器。

这套方案与灵犀生态紧密结合，但局限性也很明显：

1. 与灵犀运行时深度绑定，无法独立使用

整条链路依赖灵犀桌面端注入的 SKILL_PATH 环境变量。脱离灵犀环境，Browser 技能无法加载。这意味着换一个 Agent 平台，这套能力就废了。

2. 闭源，生态封闭

技能代码随灵犀专业版分发，不对外开放。无法审计它的实现、无法定制它的行为，更无法把它集成到自己的工具链中。

3. 无 Agent 隔离机制

操作直接在用户浏览器标签页中执行。如果多个 Agent 同时运行，或者 Agent 和用户同时操作同一个浏览器实例，互相干扰是大概率事件。

4. 权限模型单一

只有"操作/不操作"的二元选择，缺少 Borrow 这样的精细授权机制。用户无法控制 Agent 能访问哪些页面、不能访问哪些页面。

相比之下，我更推荐大家使用腾讯开源的 BrowserSkill（GitHub：Tencent/BrowserSkill: Let AI agents use your real, logged-in browser without interrupting your work. CLI + extension for browser automation across any shell-capable AI agent.），这个插件和技能走的是另一条路——开放、通用、可组合。

1. 开源，MIT 协议

代码完全公开，可审计、可 fork、可定制。这对涉及企业内部系统或私人账号的场景至关重要。

2. 通用接口，不绑定任何 Agent

bsk CLI 提供标准接口，同时支持 MCP 协议。无论用 WorkBuddy、Cursor、Claude Code、Codex 还是自己写的 Agent，一套 BrowserSkill 通吃。真正做到"一次安装，所有 Agent 通用"。

3. Agent Window 隔离

Agent 的操作在独立的 Agent Window 中执行，与日常浏览的标签页完全隔离。多 Agent 同时运行也不会互相干扰。

4. Borrow 机制（精细权限控制）

这是 BrowserSkill 最亮眼的设计——Agent 需要访问某个页面时，向用户发起 Borrow 请求，用户可以选择"允许一次"、"始终允许"或"拒绝"。敏感页面必须显式授权，用户始终握有最终控制权。

5. Human-in-loop 内建

遇到验证码、OTP、登录确认时，Agent 主动暂停，把页面交还给用户处理，完成后继续。整个过程是协议的一部分，不是事后补丁。

6. 数据隐私不离开本机

所有操作在本机执行，Agent 通过本地通信通道获取页面快照，远程模型不直接接触浏览器会话。

对比

总结

灵犀的 Browser 技能在"深度集成"这条路上走得不错——元素索引交互、双模式降级、人机协作兜底，都是实用设计。但它的封闭性决定了它只能是灵犀生态的一个组件。

BrowserSkill 的可贵之处在于它不制造新生态，而是做通用能力层。它不绑定任何 Agent、不绑定任何模型、不绑定任何云服务。装好 CLI 和扩展，它就安静地等待任何 Agent 通过标准接口调用。这种"即插即用"的设计哲学，才是浏览器自动化走向广泛落地应该走的路。

如果只在灵犀专业版内使用，内置的 Browser 技能够用。但如果需要在多个 Agent 平台之间复用一套浏览器自动化能力，或者关心代码是否可审计、权限是否可控——BrowserSkill 是更值得关注的选择。