Question 1

为什么在 Windows 上没有守护进程运行时,bsk 命令(browsers、status、session start)会永远挂起?

Accepted Answer

这是 bsk CLI 0.3.0 在 Windows 上的一个已知 bug:自动守护进程启动路径会启动一个中间的 `bsk daemon start`,其 stderr 被连接到管道,而分离的守护进程继承了该管道(以及调用方的管道),因此 EOF 永远不会到达,等待中的客户端会永远阻塞——尽管守护进程本身已成功启动。

**修复:**升级到 bsk CLI 0.3.1 或更高版本(修复已在 PR #282 中合并)。自动启动现在直接生成守护进程,不捕获任何管道,以单个有界截止时间等待 IPC 就绪,并在 Windows 上将守护进程的 stdio 指向 NUL,同时通过 PROC_THREAD_ATTRIBUTE_HANDLE_LIST 限制句柄继承。运行 `bsk update` 或使用官方 `install.ps1` 重新安装,然后使用 `bsk --version` 验证。

**0.3.0 上的变通方法:**在执行其他命令之前手动启动守护进程:`bsk daemon start`(约 190 毫秒内返回),之后后续命令即可正常工作。或者设置 `BSK_AUTO_START=0`,使冷命令快速失败(退出码 2,约 86 毫秒)并给出可操作的错误信息,而不是挂起。

Question 2

如何修复 Windows 上的 'detects_hermes_from_home_layout' 和 'skills_dirs_match_harness_spec' 测试失败？

Accepted Answer

更新到最新的 `main` —— 此问题已在上游的提交 `47f5765` 中修复（通过 PR #310 合并）。这两个 `skill_install::harness` 测试错误地假定了 POSIX 的 `~/.hermes` 布局，但解析器在原生 Windows 上有意使用 `%LOCALAPPDATA%\hermes`（或在设置了 `HERMES_HOME` 时使用它），以遵循上游 Hermes 的惯例。该修复更新了解析器和测试，而不是放宽断言。通过运行以下命令验证修复：`cargo test -p bsk --lib --locked skill_install::harness` —— 所有 11 个测试都应在原生 Windows 上通过。请注意，此失败仅在原生 Windows 上出现，因为代码分支的选择取决于 `LOCALAPPDATA` 环境变量是否存在，而 CI 此前只在 Ubuntu 上运行完整的工作区测试。

Question 3

如何修复 BrowserSkill 智能体会话期间 GPU/CPU 使用率过高的问题（控制覆盖层重绘以及 Accessibility domain 一直处于启用状态）？

Accepted Answer

即使 agent 处于空闲状态，仍有两个原因让浏览器持续繁忙：（1）ControlOverlay 运行着一个无限循环的 `box-shadow` 动画（`bsk-breathe`），该动画无法由合成器（compositor）执行，因此整个视口每一帧都会被重绘；（2）每次 `observe`/`snapshot` 都会发送 CDP `Accessibility.enable`，但从不发送 `Accessibility.disable`，导致渲染器的无障碍（accessibility）树在会话的剩余时间里一直保持激活状态。

临时解决办法：在扩展程序的弹窗中关闭 "Control hints"——这只会停止浮层的重绘（Accessibility 仍保持启用状态）。

完整修复（以 PR/补丁形式提供，MIT 许可）：用静态的内阴影（inset shadow）加上一个仅由合成器执行的、循环两次的 `opacity` 脉冲动画来替换无限阴影动画（在 `prefers-reduced-motion: reduce` 下跳过），并在每次捕获完成读取 AX 树之后，通过捕获 worker 池向每个已完成的目标发送 `Accessibility.disable`。在 Chromium 153/Chrome for Testing 154 上实测：会话期间 GPU 进程的占用从单核的约 20.5% 降至约 5.6%（-73%），整个浏览器的 CPU 占用从约 35.4% 降至约 12.5%（-65%）。

Question 4

如何修复 "Plugin @wxg-prc-cpg/browser-skill-dsh-plugin is incompatible with dsh 0.2.0" 错误（插件被跳过，browser_* 工具缺失）？

Accepted Answer

原因：`@wxg-prc-cpg/browser-skill-dsh-plugin@0.3.1`（当前 npm 最新版本）声明的 harness peerDependencies 仅为 `^0.1.5-rc.3`，因此 DSH 0.2 宿主会在执行 `dsh plugin add` 时拒绝它，并在启动时静默跳过它——Web UI 可以加载，但六个 `browser_*` 工具永远不会注册。临时解决方案：授予精确版本豁免以强制加载（已确认有效）：

```
dsh plugin --profile web allow-version @wxg-prc-cpg/browser-skill-dsh-plugin@0.3.1 --dsh-version 0.2.0-rc.2 --accept-risk
```

将 `--dsh-version` 调整为你的宿主版本（例如 `0.2.0-rc.1`）。永久修复：peer 版本范围 `|| ^0.2.0-rc.1` 已合并到 `main` 分支（提交 `bf5a8d96`），但尚未发布——等待高于 0.3.1 的插件版本发布，发布后使用 `dsh plugin add @wxg-prc-cpg/browser-skill-dsh-plugin@latest` 升级。

Question 5

为什么在 DSH 0.2.0+ 中右侧边栏的观察标签页不再自动打开？

Accepted Answer

根本原因:上游 `@deepseek-ai/dsh-api-session-controller` 在 0.2.0-rc.2 中从 `sessions.list` 移除了 `current` 字段(0.1.5-rc.3 中仍有 `createSnapshotStore({... current ...})`)。插件在 `lib/client.cjs` 中的自动打开逻辑读取 `sessions.list.getSnapshot().current`,该值现在始终为 `undefined`,因此 `current !== sessionId` 始终为真,自动打开路径被静默取消。手动打开仍然有效,因为标签页注册不依赖于 `current`。修复方案:修补客户端,改为从观测数据中推导自动打开目标——每个观测都携带 `dshSessionIds`,因此使用 `visibleToScope(obs, id) = obs.dshSessionIds.includes(id)`,并且仅在 `current` 可用时才保留 `attempt()` 的严格 `current` 检查。变通方案:将 DSH 降级到 0.1.5-rc.3,或从右侧边栏的页面列表中手动打开观测标签页。

BrowserSkill

核心功能

避坑指南

适用场景

标签

快速上手

相似推荐