挑插件最容易被"支持浏览器自动化"这种大词带走。真正能落到选型上的，是那些你能打开仓库或详情页逐条核对 的事实：装了哪些工具、出错时你有没有观察窗、换到你的机器上它还站不站得住。ego-browser 的 README 给了一张与同类插件的对照表，点名 Da1dr1em/dsh-ego-browser 只做了 3 个工具 （run / help / status）。本文不评谁好谁坏，只把可核对的事实摊成三个维度；入口先放这里：完整插件清单与汉化避坑指南。
为什么用"可核对"当筛子
宣传语不可核对，代码与详情页字段可以。ego-browser 的坐标：星标 195、综合分 64.4、周下载量 880（npm 全网窗口，含 CI、镜像与爬虫，不代表本站安装数）；信任档位已验证 （dsh 0.2.0-rc.2 下真实安装，L4 · 真实安装）；npm 包 dsh-ego-browser，latest 0.8.6；分类是 dsh 原生插件 · browser。
维度一：工具是一条命令，还是一套可组合的动作
README 对照表第一行是"结构化工具数"：ego-browser 一侧 32 个 、"职责单一、可确定性调用"，同类插件一侧 3 个 （run / help / status）。注意这个数字在 README 里内部不一致 ------正文另一处写"33 个"，与清单标题的"32 个"对不上，别当硬指标，以 ego_help 给出的完整索引为准。
真正影响使用的不是"多几个"，而是粒度 ：单入口意味着一次调用写一段完整脚本；拆成 ego_snapshot / ego_click / ego_wait_for_response 这种粒度后，每一步都可单独观察、单独重试、单独接管------中间某一步失败时，你希望它"整段重跑"还是"从失败那一步接着来"，答案基本决定了你需要什么粒度。
维度二：出问题的那一刻，你看得见、插得上手吗
README 对照表里连续四行都指向同一件事------实时观察窗（有 / 无）、监控窗鼠标直接操作 真实浏览器（有 / 无）、worker 单实例守卫 + 崩溃 / 重复自愈（有 / 无）、下载捕获 ego_download 与人机验证检测 ego_captcha / ego_page_info（有 / 无）。
四行可逐条验证：观察窗 有 CDP JPEG 与 FFmpeg H.264 两条画面后端、标签条与历史抽屉；鼠标直操 的点击 / 拖拽 / 滚动回传 CDP，作用在同一个 Agent 浏览器上；worker 守卫 表现为崩溃自动重启、不会起两个 worker 抢同一个 target；下载与验证码 各有专门工具。它们回答同一个问题：流程卡住时，你是拿到一句"失败了"，还是能看到现场并亲手把这一步做过去。
维度三：换到你自己的机器上，它还能不能自己站住
README 对照表最后两行：平台自适应 （一侧"全平台"，另一侧"仅 Windows 预览宿主，需手动配"）、登录态落盘持久化 ego_auth_flush （一侧"有"，另一侧"仅文档级说明"）。但"全平台"不等于每个平台一样强：Linux 上语义树用 CDP DOMSnapshot 重建，非 macOS 内核级 ，复杂 iframe / 画布可能降级；Linux 上跨 CLI 调用可能丢 tab / 空间状态 ；Windows 上插件层已做适配，但底层 ego-lite 宿主仍是非 Windows 官方支持的社区移植 。登录态同理：多个任务空间 cookie 相互隔离 ，且重启 DSH 后运行期登录态会被清空 （Chrome 运行期 cookie 仅优雅关闭时落盘），跨重启保留得走 ego_login_import。
形态差异：装不装 better-sidebar、用哪种宿主
装了 dsh-better-sidebar，观察窗注册为侧边栏原生 Tab ，Agent 首次调用 ego_* 时自动打开；没装则回退成右下角浮动观察球 （#dsh-ego-fab）。两种形态共用同一套 SSE 实时推流 / 点击 / 输入 / 下载捕获能力 ，变的只是入口位置。它不是 peer 依赖，靠 ctx.betterSidebar 机会性消费。版本细节：外部链接拦截需要 TabDescriptor.urlTarget，要求 better-sidebar v0.12.2+ ，低于此版本会静默失效。
宿主类型同理：带图形界面的 DSH Web 才有观察窗 ，headless 会话仍可用 ego_*、只是没有观察窗。
一张可核对的对照表
|------|---------------------|-----------------|--------------------------------|
| 维度 | 可核对项 | ego-browser | 同类插件（Da1dr1em/dsh-ego-browser） |
| 工具粒度 | 结构化工具数 | 32 个（另一处写 33 个） | 3 个（run / help / status） |
| 出错可见 | 实时观察窗 / 鼠标直操 | 有 / 有 | 无 / 无 |
| 出错守卫 | worker 单实例守卫 + 崩溃自愈 | 有 | 无 |
| 出错信号 | 下载捕获 / 人机验证检测 | 有 / 有 | 无 / 无 |
| 平台归属 | 平台自适应 | 全平台 | 仅 Windows 预览宿主，需手动配 |
| 会话延续 | 登录态落盘持久化 | 有 | 仅文档级说明 |
（此表只照抄 README 声明的对照项；README 同时声明"此文档不含对任何他人的贬低"。）
总结
选浏览器自动化插件，先问工具粒度够不够细分、出错时你有没有现场和接管能力、以及换到你的平台与宿主上它还能不能站住，三个维度都能逐条核对；想对照同类插件的中文清单与安装形态见 完整插件清单与汉化避坑指南。
适合与不适合
适合 ：需要登录态、验证码这类"真人会在场"环节的自动化任务；把流程做成多步、希望每步都可观察可重试的工作流；以文件为产物、需要下载捕获兜底的任务；愿意为了"看得见"而使用带图形界面 Web 宿主的用户。 不适合 ：要求在 Linux 上做内核级无头快照、或需要大规模并发抓取的场景------语义树来自 CDP DOMSnapshot，且 ego_* 调用串行化；Windows 上的复杂多步流程------底层 ego-lite 宿主仍是非 Windows 官方支持的社区移植；在公共 npm registry 直接 pnpm install 的环境------本仓库的 DSH peer 包不全在公共 registry，可能解析 @deepseek-ai/* peer 失败。
标签：ego-browser、DeepSeek Harness、选型对比、浏览器自动化、DSH 插件
本文由 DeepSeek Harness Hub 自动整理，数据来源于插件详情页。