@qqbrowser/qbot-dsh

English | 中文

qbot-dsh 是基于仓库内 pristine @deepseek-ai/dsh 基线的 QQ 浏览器产品启动器。它负责可执行入口、产品 profile 层、QQ 浏览器鉴权与模型网关、内容审核、产品网页搜索、模型设置快捷入口、产品政策界面、浏览器生命周期埋点和原生宿主启动协议。上游 dsh 包不引用产品代码，保持独立复用。

运行方式

launcher 会在加载 dsh 模块前将 DSH_HOME 默认设为 ~/.qbot-dsh；显式设置的 DSH_HOME 优先。profile 位于 $DSH_HOME/profiles。随包提供的 Web profile 依次组合 @deepseek-ai/dsh-base、@deepseek-ai/dsh-web-app 和本包的 cordis.patch.yml。launcher bundle 内置 @tencent/[email protected]，产品默认配置为 target: openclaw.QBotDSH、endpoint: https://galileotelemetry.tencent.com、namespace: Production 和 envName: formal；可发布和当前目标的完整归档都会携带它，无需单独安装 Profile 插件，也不依赖检出目录的 fallback。

profile 准备过程通过上游包级 fallback healer 持有 $DSH_HOME/profiles/node_modules。如果托管安装提供了旧的整目录链接，首次准备 profile 时仅在该链接指向当前 launcher 依赖目录的情况下迁移；任何其他链接目标都会失败且不会被删除。

随包提供的 Web 名册包含标准、Code、极简和创造模式。创造模式保留标准 agent 能力、浏览器工具和产品随包技能，再增加实时 Cordis 检查、临时插件挂载以及内嵌的组合创作技能。只应在受信任的任务中选择它：实时运行时工具具有与 shell 访问相同的权限。

嵌入宿主持有 npm 和 Python 环境变量，并将包管理器状态放入 ~/.qbot-dsh 下的专用目录。在 workspace-write 模式下，launcher sandbox provider 仅允许受限 shell 和 terminal 进程写入该根目录下的 npm-cache、npm-logs、node-user、pip-cache、python-user、pycache 和 tmp、QQ 浏览器 skill 根目录、wecom-cli 凭据目录（~/.config/wecom）、dws 凭据目录（~/.dws，以及 macOS 上的 ~/Library/Application Support/dws-cli、Linux 上的 ~/.local/share/dws-cli、Windows 上的 %LOCALAPPDATA%/dws-cli），以及按需安装的钉钉 CLI 前缀（$DSH_HOME/connectors/dingtalk）。skill 根不存在时由 launcher 创建：Windows 使用 %LOCALAPPDATA%/qqbrowser-skill，其他平台使用 ~/.qqbrowser-skill。企业微信与钉钉凭据目录以及钉钉 CLI 前缀不存在时同样会创建。read-only 行为不变，进程内文件系统工具不会获得额外权限，也不会放行任何父目录或其他 Qbot 目录。产品 system prompt 要求 npm 全局安装、pip --user 安装、pipx 工具和因其他位置受限而改放的临时文件使用宿主已配置的 DSH 目录，使浏览器在卸载时能随 DSH 根目录一并删除。

qbot-dsh web
qbot-dsh --profile headless "task"
qbot-dsh --profile web --dump-config
qbot-dsh --version

--version 以无前缀的单行文本显示 launcher 包版本。

Web profile 还会把本包挂载为 client plugin。该插件添加「政策说明」设置页，渲染底部 AI 风险声明，在 compact 模式的「设置」下方渲染全屏和关闭控件，并通过 postMessage 在 dsh-web-bridge 通道转发 new_session、send、ai_first_token、ai_reply_complete、open_fullscreen 和 close 信封；事件只携带标识符和耗时，不包含消息正文。

评测专用的自动审批默认关闭；显式用户 patch、持久化权限默认值、验证方法和安全限制参见为评测配置自动审批。

插件

profile 的插件是声明了 dsh.bundle 的 npm 包；安装一个插件即把它的 patch 层加入 dsh.profile.bundles。两个入口都能管理插件，它们都用当前进程的 Node 可执行文件运行本包内置的 pnpm，因此 PATH 上不需要 pnpm、Node 或 git。

在对话中管理。 直接粘贴社区 README 里的安装命令，或用自然语言提出请求。agent 会调用 plugin_manage：它先展示将要执行的完整 pnpm 命令供用户确认，确认后安装进当前 DSH 正在运行的 profile。服务端部分立即生效；带浏览器界面的插件需要刷新一次页面，侧边栏会给出「刷新」提示条。更新会替换已经加载的代码，因此结果会说明需要重启——agent 会提示 harness_restart，仅在用户要求时调用，进程随后在本轮结束后退出，侧边栏察觉后自动拉起新进程并重新加载到它上面。拒绝确认则不改变任何内容。插件市场那种复制粘贴式的安装提示词走的是同一条路：无论提示词把步骤写成什么样，agent 都把它路由到 plugin_manage，并在答复里说明哪一条流水线性质替代了哪一步。本产品不内置任何插件市场，因此这类提示词能装的只有它自己已经写死的 pinned 来源；写得再含糊一点，agent 就会停下来，请用户给出安装命令。它不会为安装去跑包管理器，也不会为安装申请沙箱提权——提示词诱导其中任何一项，恰恰是应当改走这两个工具的信号。

在终端中管理。 产品不安装 PATH shim，请用运行时自带的 Node 以绝对路径调用入口：

~/.qbot-dsh/runtime/node/bin/node ~/.qbot-dsh/app/node_modules/@qqbrowser/qbot-dsh/lib/bin.js \
  plugin --profile web add github:owner/repo#<sha>

所有 pnpm 动词原样转发，因此 add、remove、update、list 和 why 均可使用；pnpm 能解析的任何 spec 也都可用：registry 包名、github:owner/repo#<sha>、git+https://…、.tgz URL 或本地路径。运行中的 DSH 监视 profile manifest，因此终端安装同样会在其中生效。在同一台机器上工作的外部编码 agent 应当使用这条命令，而不是自己去调包管理器；命令行没有批准关卡，它装坏的层也只能经由启动时那条路径进入搁置。

状态隔离。 pnpm 的 store、cache 和 state 目录位于 $DSH_HOME/pnpm，通过命令行设置传入，优先级高于命令行中位于其前的任何写法。pnpm 准备 git 来源的包时，会以 shell 命令运行那个 checkout 自己的包管理器——checkout 带 pnpm-lock.yaml 时就是 pnpm install——所以每次操作还会在子进程 PATH 的最前面放一个 pnpm 命令，用同一份内置 pnpm、同一组设置运行；这个命令放在只属于这次运行的私有目录里，运行结束即删除，管线之外的任何 PATH 上仍然没有 pnpm。不会写入 ~/Library/pnpm、~/.npmrc 或 Harness home 之外的任何位置；卸载浏览器的 DSH 时插件随之删除。

镜像源。 取包时先尝试浏览器注入的 registry，然后依次尝试腾讯云、华为云和 npmjs 镜像；@tencent scope 始终从公司镜像解析。只有取包失败才会切换到下一个镜像，其他失败按原样上报。镜像链和十分钟的操作超时是 plugin-manager 行的 registries 与 timeoutMs，可在 $DSH_HOME/cordis.patch.yml 中修改。

插件加载不了时。 启动时无法解析的第三方层会被搁置并记录在 profile manifest 旁的 dsh-quarantine.json 中，DSH 照常启动；该记录会在该层重新加载成功时自行清除。被运行中的 DSH 在激活时拒绝的层，以及连续两次启动都没有到达就绪状态之后的全部层，则一直搁置到该包更新或重装成功为止。两种情况都会在会话开始时告知 agent。更新或重新安装即可恢复，无需手工清理任何状态。

不内置插件市场。 本次发布不带任何插件市场，上面两个入口就是全部入口，侧边栏和模型都够不到任何目录。SkillHub 广场的定点副本仍然留在仓库里，由 src/embedded-skillhub.ts 中的 SKILLHUB_EMBEDDED 把守：关着的时候它一行组合都不出、一个字节都不发布，提示词里也不提它。怎么开、怎么关：四处改动，外加两套用例替你核对。

上报。 插件操作会作为一条 plugin_action 埋点事件转发给浏览器，携带操作类型、包名、版本、结果、失败分类和耗时——不包含 spec，因为 spec 可能指向私有仓库。浏览器扩展按事件名白名单接收，因此在白名单条目合入前该事件会被丢弃。

原生宿主协议

qbot-dsh --profile web --port 0 --native-protocol=jsonl-v1 会将 stdout 保留给一条启动记录。绑定成功后输出包含 loopback URL、端口和进程 ID 的 ready JSON 对象。嵌入宿主负责加载该 URL；launcher Web profile 不会把它交给外部默认浏览器。启动失败时输出错误码为 WEB_LISTEN_FAILED 或 WEB_STARTUP_FAILED 的 error 对象。其他进程输出会重定向到 stderr。

宿主 lifeline

嵌入宿主可以传入一条继承的可读 pipe，并把其描述符编号写入 DSH_HOST_LIFELINE_FD。pipe 关闭后产生的 EOF 会请求与中断信号相同的有界有序关闭。POSIX 宿主通常使用描述符 3；Windows Web 宿主可在组合没有 stdin 所有者时使用描述符 0。无效描述符只会告警并关闭 lifeline，不会让启动失败。

开发

先在仓库根目录运行 pnpm run build，再通过 pnpm --dir apps/launcher run qbot-dsh -- <args...> 执行源码入口。pnpm --dir apps/launcher run release:pack 会在 apps/launcher/dist/npm 下构建可发布 tarball，产物包含固定版本的 pristine dsh 运行时和全部受支持目标的原生依赖。

apps/launcher/scripts/qbot-dsh-publish.sh --local 会保留增量构建产物，只组装托管 Node 运行时报告的目标，把不可发布 tarball 写入 apps/launcher/dist/local，并替换 ~/.qbot-dsh 下的包，即使产物版本没有变化。该模式保留 payload 审计，但不执行最高等级重压缩。添加 --release-equivalent 后会执行发布构建使用的 clean、三目标打包和压缩；添加 --skip-pack 后会复用当前模式选定的产物目录。

pack 命令默认会从已组装 payload 中剪除 source map、类型声明和测试、示例类开发目录，保留其中的文档、注释和可读 JavaScript，且不生成 mapping 归档。传入 --minimize-public-payload 后，命令会剪除其余开发材料并压缩 JavaScript；发布 mapping 写入 apps/launcher/dist/mapping，当前目标的本地 mapping 则写入 apps/launcher/dist/local-mapping。

launcher 自有细节见架构与 DSH 边界、浏览器产品界面设计、完整包指南、QB 网关参考和模型路由搜索设计。