同一个页面，两个操作者：一个是屏幕前的你，一个是 DSH 会话里的 agent。这是共享浏览器插件 dsh-builtin-browser 的立意——它不做无头截屏，而是让 agent 驱动一个真实、可见、随时能接手的浏览器。装好后 agent 直接获得 34 个 browser_* 工具。
这篇只谈两件事：页面由谁承载，以及承载方式一变，安全边界跟着变成什么样。
一个插件，四种载体
1. 桌面端侧栏：驱动官方侧栏里那个浏览器，agent 操作的就是你眼前那个页面。
2. 本机 Chrome / Edge：以 --remote-debugging-port=0 启动，读它写下的 DevToolsActivePort 拿端口，之后全程走 CDP（用 Node 22 内置 WebSocket，不新增依赖）。
3. 带 electronViewHost 的旧版外壳：直接使用外壳提供的视图。
4. 纯 dsh web：自托管——插件拉起 Electron 子进程 host-main.js，经本机 TCP JSON-RPC 驱动，RPC 带随机 token 认证。
四种形态差别很大，但插件写得清楚：它不提供任何浏览器界面——地址栏、标签条、侧栏面板都不是它画的，侧栏属于外壳。把「侧栏」当成插件能力，是这里最常见的误会。
三层结构：工具层不认识载体是谁
agent (browser_* 工具)
→ ctx.browser (seam, dsh-builtin-browser/browser)
→ dsh-builtin-browser/browser-electron (provider)
→ ElectronBrowserViewHostseam 层只定义接缝
browser 行提供 ctx.browser 服务，管 provider 注册、会话生命周期与错误码，不关心能力由谁实现。
provider 层只认一个接缝
browser-electron 行只依赖 ElectronBrowserViewHost 这一个抽象（创建 / 销毁 / 显示 / sendCommand），四种载体各实现一份。这是整套设计的支点：换载体不需要动工具、历史、光标与收尾逻辑。
工具层按任务开会话
tool-browser 行提供模型侧 34 个工具，并按调用方任务维护独立会话——并发任务互不抢页面，同一任务内共享 cookie、历史与登录态。README 还留了一句：靠这个接缝解耦，工具层未来可对接无头转播 provider，模型侧不用改。
桌面端 bridge：一次明说的边界变更
DSH Desktop 是两层结构：Electron 外壳 + 一个 --expose-internals 的 Node 模式宿主，插件跑在宿主里，没有 Electron API；0.2 已移除 electronViewHost，宿主与外壳之间也没有承载视图的通道。
于是插件借道一条小桥：外壳主进程里跑一个 loopback + token 的 bridge，把侧栏浏览器 guest 的 CDP 交给插件。结果就是「人机同页」——agent 操作的页面就是你界面上看到的页面，不再多出第二个窗口。
node desktop-bridge/install.mjs
node desktop-bridge/install.mjs --revert脚本幂等、可回滚，但它改的是已安装的桌面端：升级替换 resources/app/ 后 bridge 消失，需要重跑。bridge 不在时插件退回自托管，只多一个独立窗口——是能力降级，不是故障。
边界到底变了什么
README 用一整个加粗段落讲明，因为它是有意的：官方侧栏的前提是「侧栏里的页面不被外部读取」——独立 partition，宿主拒绝跨站内容访问；让 agent 驱动那个 guest，等于有意打破这个前提。后果三条：能读到侧栏里任何页面的内容；能读到该 partition 的 Cookie 与登录态并可用 browser_auth 导出；人的操作与 agent 的操作作用于同一页面。
开关也是有的：「凭据访问」关闭后导出被拒并报 BROWSER_AUTH_DISABLED，写入登录态另有独立开关报 BROWSER_AUTH_WRITE_DISABLED。不接受这个边界，就从 desktop profile 移除插件，回到「独立窗口」的旧形态——取舍是显式的、可逆的。
载体优先级：三档，以及「缺了怎么办」
设置里显式选择的本机浏览器 > 桌面端侧栏 > 自托管，没有特例。
细节在「缺了怎么办」：选 自动 就是「哪个都行」，找不到 Chrome / Edge 时记一条警告并继续用内置；明确选了某个浏览器而它没装时，插件改挂一个只会解释原因的载体，每次命令都报出找不到的是哪个浏览器、查过哪些名字与位置，以及三条出路（装上它 / 用 DSH_BROWSER_CHROME_PATH、DSH_BROWSER_EDGE_PATH 指定路径 / 改回 内置 或 自动）。
软护栏不是安全边界
browser_restrict 是防误操作的软护栏，模型可自行解除白名单，不是安全边界。要模型拿工具改不掉的限制，得用设置页那三个动作开关（执行页面脚本 / 下载文件到磁盘 / 写入登录状态）——它们写在设置文档里，没有任何 browser_* 工具能写它；或部署级的 allowedActions。
只读工具无论白名单怎么写都不拦：snapshot / a11y / content / scrape / screenshot / get_value / wait / challenge / list_tabs / session / history / visited，外加 restrict、reset_session、reset；而 browser_close_tab 与 browser_auth 都不在豁免集合里。
两个如实口径
站内的静态扫描把本插件标记为「含敏感能力」（可执行外部命令、读写删除本地文件、读取剪贴板或密钥类环境变量、发起外部网络请求），尚无人工评估；信任档位为「已验证」——站内已于 0 天前在 dsh 0.2.0-rc.2 下真实安装成功，属于真实安装而非静态推断。
总结
载体设计回答的是「页面由谁承载」，沙箱边界回答的是「承载方式变了、代价是什么」，两者本就是同一件事的两面；想对照同类插件的中文清单与安装形态见 DeepSeek Harness Hub 插件清单。
适合与不适合
适合：真实站点上登录后操作的自动化；希望看得见 agent 每一步、随时接管的协作场景；想沿用本机已装 Chrome / Edge 的环境；各任务互不抢页面的批量作业。
不适合：核心链路只在 Windows 完整实测，Linux 与 macOS 虽已适配系统浏览器查找，但端到端链路尚未实测、暂不承诺；不接受「侧栏页面与其中 Cookie 可被 agent 读取」这一边界变更的部署，应从 desktop profile 移除插件，别指望 browser_restrict 兜住；不打算在桌面端每次升级后重跑 bridge 的场景，不要选侧栏载体。
标签：共享浏览器、DeepSeek Harness、载体设计、沙箱边界、Cordis 插件
本文由 DeepSeek Harness Hub 自动整理，数据来源于插件详情页。