一、引言
当 AI Agent 试图操作 Web 应用时，最常见的瓶颈并非能力不足，而是身份与环境的缺失------Agent 没有用户的登录态，也无法绕过复杂的前端交互。Tencent 开源的 BrowserSkill 试图从架构层面解决这个问题：通过一个轻量级的本地栈（CLI + Daemon + 浏览器扩展），将任何具备 Shell 调用能力的 AI Agent 与用户已登录的真实浏览器会话连接起来，同时确保用户的工作流不受干扰。
本文将从技术架构、核心机制、人机协作模式三个维度拆解 BrowserSkill 的设计思路，并对若干待解问题进行分析。
二、架构：CLI · Daemon · Extension 三层协同
BrowserSkill 的本地部署由三部分组成：
sql
┌──────────────┐ ┌──────────────┐ ┌──────────────┐
│ bsk CLI │────▶│ Local │────▶│ Browser │
│ (Agent入口) │ │ Daemon │ │ Extension │
└──────────────┘ └──────────────┘ └──────────────┘
│ │
WebSocket Agent Window
│ │
浏览器标签页（只借不还）bsk CLI 是 Agent 的直接操作接口。所有 browser_* 命令（如打开 URL、点击元素、截图等）均通过它发出。CLI 本身不持有浏览器状态，仅负责将请求序列化并转发。
Local Daemon 是架构的核心中转层。它以常驻进程的形式运行，监听来自 CLI 的请求，并通过 WebSocket 将指令路由到目标浏览器扩展。Daemon 还负责维持与扩展的长连接，处理断线重连与心跳。
浏览器扩展 运行在独立的 Agent Window 中。这是设计上的关键决策：Agent 的浏览器会话与用户的日常浏览完全隔离，避免 Cookie、History 等内容泄露。
三、核心能力解析
3.1 复用真实登录态
传统测试框架（如 Playwright、Puppeteer）通常需要为每个 Agent 准备独立的测试账号，或通过注入 Cookie 的方式模拟登录。BrowserSkill 的做法更直接：Agent 直接借用用户在真实浏览器中的登录会话。这意味着 OAuth 回调、SAML 单点登录、企业内网认证等复杂场景都可以透明复用。
不过这也带来一个需要谨慎处理的设计点：扩展仅"借用"指定的标签页，任务完成后必须归还，不得修改或关闭其他标签页。
3.2 多标签页的状态同步与风险
待深挖问题：在多标签页场景下，状态如何同步？是否存在标签页被意外关闭的风险？
从架构上看，Daemon 通过 tabId 标识目标标签页。当 Agent 发起跨标签操作时，协议层需要保证 tabId 的有效性------若标签页在操作中途被关闭，扩展应返回明确的错误码而非静默失败。合理的实现策略是：
- 扩展在每次操作前校验
tabId对应的标签页是否存活 - 若标签页已关闭，Daemon 向 CLI 返回
TAB_CLOSED事件，CLI 触发 Agent 的异常处理逻辑 - Agent 可选择重新导航到目标 URL，或在上下文中记录中断原因
潜在风险在于：如果 Agent 执行的是破坏性操作（如关闭当前标签页后再尝试读取），协议 1.3 需要明确定义操作序列的原子性边界。
3.3 人机协作中断与恢复
当 Agent 遇到验证码、二次确认弹窗、SMS 验证等需要人类介入的步骤时，BrowserSkill 的设计是主动请求用户接管，而非尝试绕过或失败重试。
待深挖问题：中断后 Agent 从哪一步恢复？是否有断点续传机制？
一个完整的恢复方案应包含：
- 检查点序列化：在每次操作执行前，Daemon 将当前上下文（URL、DOM 快照、已填字段、操作步骤序列）序列化写入本地文件
- 中断事件通知 ：扩展检测到需人工介入的场景时，向 Daemon 发送
HUMAN_HELP_REQUIRED事件，Daemon 同时暂停后续操作调度 - 用户介入窗口：扩展在 Agent Window 中高亮提示，用户可在真实浏览器中完成验证或确认
- 恢复执行 ：用户完成后，扩展发送
HUMAN_JOINED事件，Daemon 从最近检查点恢复，继续执行后续步骤
断点续传的关键在于检查点的粒度：过于粗粒度会导致用户完成后 Agent 仍需重复大量操作；过于细粒度则检查点文件膨胀。建议以"交互事件"为边界进行保存。
四、Daemon 的持久化与沙箱部署
待深挖问题：bsk CLI 的 daemon 在沙箱环境中如何保持持久运行？BSK_AUTO_START=0 的具体适用场景是什么？
Daemon 的进程管理通常由以下机制保障：
- systemd / launchd 单元 ：生产环境推荐通过系统服务管理 Daemon，配置
Restart=always确保崩溃自恢复 - BSK_AUTO_START=0 ：该环境变量用于禁用 Daemon 的自动启动。适用场景包括：
- 开发调试：手动控制 Daemon 生命周期，便于观察日志
- CI/CD 管道：每条流水线独立启停 Daemon，避免并发冲突
- 资源受限环境：按需启动 Daemon，任务结束后释放内存
在沙箱或容器环境中，由于缺乏持久化存储，建议配合卷挂载将 Daemon 的会话状态（Cookie 映射、操作历史）持久化到宿主机，避免重启后状态丢失。
五、协议演进：Protocol 1.3 的改进方向
待深挖问题：Protocol 1.3 相比旧版本有哪些协议层面的改进？向后兼容性如何保证？
从架构设计推断，Protocol 1.3 可能的改进点包括：
| 维度 | 改进方向 |
|---|---|
| 事件模型 | 引入异步事件流（如 TAB_CLOSED、HUMAN_HELP_REQUIRED），替代旧版轮询机制 |
| 错误处理 | 细化错误码，区分 NETWORK_ERROR、ELEMENT_NOT_FOUND、TAB_MISMATCH 等 |
| 检查点协议 | 新增 CHECKPOINT_SAVE / CHECKPOINT_RESTORE 消息类型，支持断点续传 |
| 多 Agent 支持 | 增加 agentId 字段，允许多个 Agent 共享同一 Daemon 实例 |
向后兼容性通常通过版本协商机制实现：客户端在 WebSocket 握手时发送支持的协议版本列表，服务端选择最高共同版本响应。对于不兼容的字段变更，采用"可选字段默认值"策略，旧客户端忽略新字段而非报错。
六、验证码场景的能力边界
待深挖问题：图像理解模型能否独立完成简单 CAPTCHA？对 SMS/二维码/人脸验证的处理边界在哪里？
BrowserSkill 的当前设计将验证码视为必须人工介入的场景。原因如下：
- CAPTCHA 类型多样性：文本识别、滑块验证、点选验证、旋转验证等类型各异，通用解决方案极难覆盖
- 反作弊机制：现代验证码服务（如 reCAPTCHA v3、hCaptcha）会检测自动化行为模式
- 合规风险：绕过验证码可能违反目标网站的服务条款
对于简单图像验证码，理论上未来可集成视觉模型作为可选能力，但需满足以下条件：
- 明确告知用户并获授权
- 仅处理低风险场景（非金融、非隐私类站点）
- 保留人工兜底通道
SMS/二维码/人脸验证属于硬性人工依赖，Agent 无法绕过，必须通过人机协作机制由用户完成。
七、配置与扩展生态
7.1 扩展设置项
BrowserSkill 提供两项独立开关：
- 借标签页确认：开启时，Agent 借用标签页前需用户确认；关闭则自动借用
- 请求人工帮助：开启时，遇到需要人类操作的步骤会中断并请求协助；关闭则遇到此类步骤直接失败
这两个设置允许用户根据场景灵活权衡自动化效率与安全性。
7.2 DeepSeek Harness 原生插件
BrowserSkill 为 DeepSeek Harness 提供了 dsh 插件，Agent 可直接调用 browser_* 工具集，并在 Web UI 中实时查看浏览器会话状态（当前 URL、已执行操作列表、截图缩略图）。这一集成降低了 DeepSeek 用户的接入成本。
7.3 全页截图能力
通过 Quick Actions 或 CLI 命令，Agent 可捕获完整页面的长截图。这一能力适用于：
- 记录 Agent 操作结果供审计
- 调试时定位页面状态异常
- 生成操作报告
八、小结
BrowserSkill 的核心价值在于解耦了 Agent 的身份与环境：Agent 不再需要独立的测试账号或模拟浏览器实例，而是直接接入用户真实的登录态会话。其三层架构（CLI + Daemon + Extension）保证了操作的可靠性与用户工作流的独立性。
未来值得关注的发展方向包括：断点续传机制的完善、多 Agent 并发安全性的保障、以及验证码处理能力的渐进式增强。对于企业级用户，Daemon 的持久化策略和 Protocol 版本的兼容性管理也将是部署时的关键考量。