前言¶
开发 DSH 插件时，一个常见的调试困境是：某个功能只能在前台会话里验证，而插件自己跑在工具调用里，拿不到前台会话的能力。模型想确认”这个流程在真人操作下到底能不能跑通”，往往只能绕道——去翻浏览器 cookie、猜 RPC 参数、改 DOM。elfgzp/dsh-session-bridge 把这几条弯路合成了一组标准工具调用。
这篇介绍基于仓库 README 与 package.json，说明它能做什么、怎么装、以及使用时要注意什么。
这是什么¶
dsh-session-bridge 是 elfgzp 维护的 DSH 插件，分类属于工作流。它把 Host 已有、但对模型工具不可见的两套能力暴露成工具：ctx.sessionController（创建、提示、检查、取消会话）和 ctx.connection.authenticatedUrl()（带启动令牌的本地 Web App 地址）。README 对它的一句话定位是：让 DeepSeek Harness agent 打开前台会话、驱动它们、把结果读回来，并交出本地 Web App 的已认证 URL。
核心功能¶
插件提供五个工具：
| 工具 | 作用 |
|---|---|
dsh_web_url |
返回本地 Web GUI 地址，默认遮蔽启动令牌；传 includeToken: true 可获得可直接打开浏览器的 URL（需要 danger-full-access 预设）。 |
dsh_session_create |
创建前台会话，返回其 id。 |
dsh_session_prompt |
向会话发送提示，可选 queue 或 steer 两种模式。 |
dsh_session_read |
读取会话记录；waitMs 可以等待当前轮次结束。 |
dsh_session_cancel |
取消会话中正在运行的轮次。 |
前台会话和委派任务的区别¶
这是整个插件存在的理由。README 讲得比较直接：
- 前台会话是根智能体，拥有
userQuestions服务，需要人工同意时可以真的开口问。 - 委派任务（子智能体、工作流智能体）没有这项服务，调用时会得到
APP_APPROVAL_UNAVAILABLE: Application approval is unavailable in delegated tasks; ask the main task to perform this operation。
所以那些需要人工确认的插件（README 举了 elfgzp/dsh-cua-macos 的例子）只能通过前台会话端到端跑通，而这五个工具负责创建这种会话。
令牌处理¶
connection.authenticatedUrl() 生成的启动令牌是一份有效凭证：任何浏览器打开这个 URL 都会拿到一个已认证的会话，而且工具返回值会进入对话记录，进而进入日志、导出和聊天副本。
因此默认行为是 maskToken：返回 origin 以及把令牌截成首尾各四字符的 URL。只有在确实需要打开浏览器时才传 includeToken: true，并且不要把结果持久化或粘贴出去。
includeToken: true 受调用方权限预设限制。工具向 permissionPresets 服务查询当前会话的预设（current(session)）并解析为 { sandbox, approval }，只有 sandbox === "danger-full-access" 才交出明文令牌，其他预设一律返回 insufficient-permission 和遮蔽后的 URL。
README 明确说明这个闸门是失败关闭的：permissionPresets 缺失、resolve() 处理不了 custom、任一调用抛错、execution.agent.session 不可用，结果都是”不给令牌”，而不是”放行”。
安装与启用¶
dsh plugin --profile <profile> add github:elfgzp/dsh-session-bridge
装完重启 DSH。插件没有依赖。仓库要求 engines.dsh 为 >=0.2.0，许可证是 MIT。
典型用法¶
README 给的示例是让智能体验证只在前台会话里能做的事情：
你手上有一个只能在前台会话里验证的功能。请：
1. 用 dsh_session_create 建一个会话
2. 用 dsh_session_prompt 让它做那件事
3. 用 dsh_session_read（waitMs=120000）把结果读回来
三个步骤对应工具清单里的创建、提示、读取，中间没有涉及 cookie 或 DOM 操作。
仓库自带测试：
npm test # node --test test/*.test.mjs
lib/format.js 里是纯函数（maskToken、clip、reasonLabel、transcribe、waitForTurn），不依赖 Host，测试在普通 Node 20 上就能跑。test/web-url.test.mjs 通过 apply() 接一个假的 ctx，覆盖了权限闸门和所有失败关闭路径。
适用场景与注意¶
适合需要在真实前台会话里验证功能、或者需要把本地 Web App 地址交给外部流程的 DSH 插件开发者。
几点使用上的注意：
dsh_session_read会截断长文本，且最多返回maxMessages条消息（默认 40）。长会话要分段读取。- 会话记录包含工具调用及其结果，所以即使那个会话用了别的工具，从这里也能审计。
dsh_web_url依赖webApp服务，无头部署没有这个服务，工具会说明这一点而不是直接报错。- 这个插件是社区目录里的第三方项目，按当前 dsh 进程的权限运行。安装前应通读源码并确认许可证（MIT）符合你们的使用要求。
小结¶
dsh-session-bridge 的价值不在于新功能，而在于把原先藏在浏览器和 RPC 层里的操作收进标准工具调用，让智能体能够真正走进前台会话做验证。
- 社区目录页：https://www.skillhub.cn/plugins/elfgzp/dsh-session-bridge
- GitHub：https://github.com/elfgzp/dsh-session-bridge
