如果说过去两年我们在选择 AI 编程工具时，纠结的是 Claude Code、Codex、Cursor 之间该站哪一队，那么 DeepSeek Harness（下文简称 dsh）带来的思路变化是根本性的：底层 Runtime 可以固定不变，能力却完全由你自己组合。dsh 的核心设计信条只有一句话——Everything is a Plugin（一切皆插件）。模型适配器、工具注册表、会话日志、Agent Loop、沙箱、存储、任务调度、UI，甚至权限策略，全部以 Cordis 插件的形式存在；宿主只负责组织能力，能力本身一律由插件提供。本文是《DeepSeek Harness 内置插件全景》的上半部分，面向已经跑通 dsh 基础流程、准备深入理解插件机制与选型逻辑的进阶读者。我们会从 Cordis 的注册与生命周期讲起，逐层拆解传统串联式 Agent 与 dsh 运行时的结构差异，给出「需求到插件」的映射表，讲清 web、tui、headless 三档 Profile 各自把插件装进哪套环境，最后落到安装命令的字段拆解与 UI 增强四件套的能力边界。读完这一段，你应该能独立判断：我这套工作流，到底该装哪几个插件、装到哪个 Profile、以及怎么验证它真的加载上了。
Everything is a Plugin：dsh 把权限策略也做成 Cordis 插件意味着什么
要理解 dsh 的插件化到底彻底到什么程度，得先理解承载它的那层框架——Cordis。Cordis 是一个轻量级的插件化应用框架，它的职责边界非常清晰：统一负责插件的注册、依赖解析与生命周期管理。这三件事看起来朴素，但正是它们决定了 dsh 能长出什么样的生态。
先说注册。在 dsh 里，插件不是一个「往主程序上挂功能」的外挂概念，而是一等公民。模型适配器、工具注册表、会话日志、Agent Loop、沙箱、存储、调度、UI，甚至权限策略，全部以 Cordis 插件形式存在。你换一个模型适配器插件，dsh 就有了新的模型后端；你换一个沙箱插件，dsh 的代码执行隔离策略就整体换了一套。这种「能力即插件」的注册模型，意味着宿主代码里几乎不存在硬编码的能力分支。
再说依赖解析。这是插件化系统最容易翻车的地方。当你的插件清单长到十几个、彼此还有先后顺序要求时（比如权限策略插件必须在工具注册表之前就位，UI 插件依赖会话日志插件的输出结构），靠人工排顺序几乎必然出错。Cordis 把依赖解析收拢到框架层，插件声明自己依赖什么、提供什么，由框架决定加载次序与装配关系。这也是为什么 dsh 的插件组合可以「叠加」——插件之间可以互相叠加，形成完全不同的工作环境，而不是互相踩脚。
最后是生命周期管理。插件的加载、启用、停用、卸载，都需要有明确的钩子与状态边界。这一点对 dsh 尤其关键：因为 dsh 可以在同一个安装里同时服务多个 Profile，如果生命周期管理不到位，一个 Profile 里停用的插件很可能污染另一个 Profile 的运行时状态。
那么，「连权限策略都是插件」这件事到底意味着什么？我认为有三层含义，值得进阶读者认真对待：
- 第一层：安全边界是可替换的，而不是写死的。在传统 Agent 框架里，权限模型通常是框架内核的一部分——什么工具能碰文件系统、能不能执行 Shell、网络访问要不要审批，往往是改代码才能改的配置。dsh 把权限策略做成插件后，你可以整体换一套策略实现来适配团队规范，也可以针对 CI 环境换一套更严格或更宽松的策略。安全不再是一个「框架给不给」的问题，而是一个「你装哪个插件」的问题。
- 第二层：权限策略可以和别的能力插件形成组合约束。比如一个浏览器自动化插件（保留本机 Chrome 的登录态与 Cookie）和一个纯 UI 皮肤插件，它们对系统的侵入程度完全不是一个量级。当权限策略本身是插件时，你就有机会把「装了什么高权限插件」和「用什么策略约束它」绑定起来看，而不是靠事后审计。
- 第三层：生态的竞争焦点会下移。当权限、沙箱、存储、调度、Agent Loop 全都可以插件化，社区真正比拼的就不再是谁的聊天窗口更好看，而是谁能提供更扎实的底层能力插件。这对开发者的含义是：你写一个插件时，要想清楚自己占的是哪一层的位置。
换个角度总结这段：dsh 不是一个自带很多功能的 Agent，而是一个能够通过插件不断组装 Agent 能力的运行时。宿主只做一件事——组织能力；能力本身全部来自插件。理解了这一点，后面所有关于 Profile、安装命令、分类选型的讨论，本质上都是在讨论「怎么编排这套组织关系」。
传统串联式 Agent 与 dsh 运行时：Prompt→模型→Agent→工具 的结构差异
要看清 dsh 的特别之处，最好的办法是把它和传统 LLM Agent 的结构放在一起对照。
传统 LLM Agent 的结构通常比较固定：Prompt、模型、Agent、工具依次串联，形成一条单向的处理链。请求进来，先经过 Prompt 组装，再交给模型推理，模型决定调用哪个工具，Agent 执行工具并把结果回灌，循环往复。这条链路清晰、好理解，但有一个隐含代价：能力大多封装在框架核心里。你想换一套界面？改核心。你想加视觉能力？改核心。你想让多个 Agent 协作？还是改核心。核心越来越臃肿，而每个团队的改法都不一样，最终导致分叉。
dsh 的结构是另一种组织方式。它把模型适配器、工具注册表、会话日志、Agent Loop、沙箱、存储、调度、UI、权限策略全部拆成 Cordis 插件，宿主只负责把这些能力组织起来。结果是：我们不需要修改 dsh 的核心源码，就可以改变它的行为。这句话不是营销话术，而是可以直接验证的工程事实——你的所有定制动作，都发生在插件层，而不是核心层的 diff 里。
用一个更工程化的视角来对比两者的差异：
| 对比维度 | 传统串联式 Agent | DeepSeek Harness |
|---|---|---|
| 结构形态 | Prompt→模型→Agent→工具依次串联，链路固定 | 宿主 + 插件集合，能力由 Cordis 动态装配 |
| 能力位置 | 大多封装在框架核心里 | 模型适配器、工具注册表、会话日志、Agent Loop、沙箱、存储、调度、UI、权限策略全部插件化 |
| 变更方式 | 修改核心源码，产生分叉 | 不改核心源码，通过安装/停用插件改变行为 |
| 组合能力 | 能力之间耦合在核心，难以自由叠加 | 插件之间可以互相叠加，形成完全不同的工作环境 |
| 环境隔离 | 一份代码一套行为 | 同一份 dsh 可按 Profile 加载不同插件组合，互不干扰 |
| 扩展单位 | 功能模块 | Cordis 插件（含权限策略这类系统级能力） |
这张表里最值得琢磨的是最后两行。传统方案的扩展单位是「功能模块」，而 dsh 的扩展单位是「插件」——这两者的差别在于，插件是有生命周期、有依赖声明、可以被 Profile 隔离的实体。这意味着同一份 dsh 安装，在 Web 场景下可以是一套带任务看板和视觉能力的完整工作台，在终端场景下可以只是一个全屏 TUI，在 CI 里可以是一个无界面的后台执行器。你面对的从来不是「一个 Agent 应用」，而是一套可以不断拼装的 Agent 基础设施。
这里有一个进阶读者容易忽略的点：把 Agent Loop 也插件化，意味着会话循环与执行策略本身是可替换的。传统框架里，Agent 的「思考—行动—观察」循环深度写死在核心，你顶多调调参数；而在 dsh 里，谁来驱动这个循环、以什么策略决定何时停止、如何在循环中插入沙箱校验，都是插件层的决策。这也解释了为什么后面我们会看到 dsh_workflow 这类「流程固化」插件能与 Agent Teams 组合——它们本质上是在 Agent Loop 之上再叠一层编排能力。
理解了这个结构差异，再回头看「需求→插件」的映射关系，就会顺畅很多：你其实不是在「给工具加功能」，而是在「给运行时换零件」。
需求到插件的映射表：换界面、加视觉、多 Agent、浏览器、上下文各该装谁
对于刚接手 dsh 的团队，最实用的切入点不是先看插件目录，而是先把自己的需求翻译成插件语言。下面这五组对应关系覆盖了绝大多数场景：
| 需求 | 做法 | 对应插件示例 |
|---|---|---|
| 换一套界面 | 安装 UI 插件 | dsh-web-ui、dsh-TUI |
| 增加视觉能力 | 安装视觉插件 | modlens、dsh-vision-toolkit |
| 多 Agent 协作 | 安装 Agent Teams 插件 | dsh-agent-teams |
| 浏览器自动化 | 安装 Browser 插件 | dsh-browser、BrowserSkill |
| 上下文管理 | 安装 Context 插件 | dsh-context |
这张映射表的价值在于，它把「我该装什么」这个模糊问题，降解成了「我在哪个维度上缺能力」这个可回答的问题。下面逐条说明每个维度的判断依据：
- 换界面（UI 插件）：如果你需要浏览器访问的工作台、任务看板、远程移动端能力，选 Web 侧的 UI 插件；如果你习惯 SSH 远程开发、日常泡在终端里，选终端 TUI 插件。这一层决定的是「你怎么使用 dsh」，而不改变 Agent 的核心能力。
- 加视觉（视觉插件）：当你的工作涉及 OCR、网页截图分析、文档理解、图片内容提取时，就需要视觉插件把图片能力「外挂」给原本以文本为中心的 Agent。注意不同视觉插件的能力深度不同，后面会详细区分。
- 多 Agent（Agent Teams 插件）：当你发现单个 Agent 处理复杂任务时上下文越来越乱、职责越来越混杂，就该考虑让多个 Agent 分工协作了。这类插件解决的是「怎么让多个 Agent 一起干活」。
- 浏览器（Browser 插件）：Agent 真正进入生产环境后，仅能读写代码往往不够，还需要打开网页、读取页面、点击输入、带着登录态执行任务。这类插件通常涉及浏览器扩展等额外组件，安装方式与普通插件不同。
- 上下文（Context 插件）：Agent 用得越久，真正的问题往往不是模型不够聪明，而是上下文越来越乱。这类插件围绕上下文的构成可视化与管理展开。
关键在于，插件之间还可以互相叠加，形成完全不同的工作环境。界面插件 + 视觉插件 + 上下文插件，得到的是一个面向日常交互开发的完整工作台；界面插件 + 多 Agent 插件 + 工作流插件，得到的是一个任务编排环境。这也正是「插件化」相比「功能开关」的本质优势：开关只能选开或关，插件可以自由组合。
需要提醒的是，dsh 的优势不是「插件越多越强」，而是根据自己的工作流自由组合。不要一上来就安装十几个插件，先把核心工作流跑通，再逐步添加能力。
Profile 三档形态：web、tui、headless 分别把插件装进哪套环境
dsh 的插件安装和普通 npm 包、Python 包有一个明显区别，这个区别是进阶用户必须建立直觉的地方：插件装好之后，运行在哪一套环境中由 Profile 决定。
换句话说，npm install 或 pip install 解决的是「包在不在本机」，而 dsh 的 Profile 解决的是「这个包在哪个运行时里生效」。同一个 dsh 可以根据使用场景加载不同的插件组合，不同 Profile 之间互不干扰。这是 dsh 能做到「一份安装、多套形态」的关键机制。
dsh 常用的三种 Profile 如下：
| Profile | 形态 | 适用场景 |
|---|---|---|
| web | 浏览器访问的 Web 工作台 | 日常交互开发、任务看板、远程访问 |
| tui | 终端全屏界面 | SSH 远程开发、习惯命令行的用户 |
| headless | 无界面后台运行 | 自动化脚本、CI 集成、定时任务 |
这三档形态的设计逻辑非常清晰，值得展开讲透：
- web 面向「有人盯着屏幕交互」的场景。它的插件组合通常最重：UI 全家桶、侧边栏工作台、视觉能力、插件市场都会装在这一档。因为 Web 工作台天然适合承载任务看板、Git 图谱这类需要可视化面积的能力。
- tui 面向「SSH 远程开发、习惯命令行」的用户。它的插件组合通常最轻——一个终端用户可能只保留一个全屏终端界面插件就够了。这不是能力缺失，而是有意的减法：终端场景下复杂的可视化面板反而增加干扰。
- headless 面向「没有人类在场」的场景——自动化脚本、CI 集成、定时任务。这一档通常不装任何 UI 插件，专注执行与产出。
这里要特别强调一个工程直觉：Profile 之间的隔离是有实际价值的，不是概念游戏。设想你在 CI 流水线里跑 headless Profile，如果插件组合和本地 Web Profile 共享一套状态，那么本地随手装的一个浏览器自动化插件，可能会让 CI 里出现意料之外的网络行为。正因为不同 Profile 之间互不干扰，你才能放心地在本机 Web 环境里大胆试装插件，而不担心污染生产链路的执行环境。
另一个常见误区是把 Profile 理解成「主题」或「皮肤」。不是的——Profile 决定的是哪些插件参与运行，是运行时的装配清单，而皮肤是清单里的某一类插件。这个区别在后面讲到 dsh-deep-whale 这类皮肤插件时会再次体现。
Web Profile 与 TUI Profile 的插件组合清单：dsh-web-ui、dsh-better-sidebar、modlens、dsh-market 与 dsh-TUI
概念讲完，直接看两套真实可用的 Profile 插件组合，感受会更直观。
一个典型的 Web Profile 插件组合长这样：
Web Profile
├── dsh-web-ui # Web 工作台
├── dsh-better-sidebar # 侧边栏工作区
├── modlens # 视觉能力
└── dsh-market # 插件市场
而终端用户可能只保留：
TUI Profile
└── dsh-TUI # 全屏终端界面
把这两棵树并排看，会发现一件很有意思的事：同一份 dsh，可以加载完全不同的插件集合。Web Profile 里有四个插件，TUI Profile 里只有一个；但它们共享同一个 dsh 安装、同一套插件管理机制。这就是 Profile 机制「组织能力」的直观体现。
逐个拆解 Web Profile 这四件套各自负责什么：
- dsh-web-ui：Web 侧的核心工作台插件。它并不只是简单换一个界面，而是围绕 Agent 工作流补齐任务看板、Git 图谱等工作台能力。换句话说，它解决的是「dsh 在浏览器里应该长成什么样」。
- dsh-better-sidebar：解决的是「工作区组织能力」的问题。它提供完整侧边栏工作台——文件树 / 编辑器、终端、Git、子代理，并且支持第三方插件注册新 Tab。适合想把 dsh 做成「AI IDE」的用户。
- modlens：视觉能力插件，让纯文本模型具备处理图片的能力（下一段会详细展开它的工作原理）。
- dsh-market：把插件市场内置在设置页里，提供搜索、分类与一键安装更新。这是起步阶段最推荐优先安装的插件——理由很简单：与其手动去搜几十个 GitHub 仓库，不如先让市场帮你发现和安装。
而 TUI Profile 里的 dsh-TUI 则是另一条路线：Claude Code 风格的全屏终端 TUI，提供流式思考、双击 Esc 回溯、状态栏、模型切换。它在终端里提供流式输出与消息回溯，体验接近 Claude Code。终端用户则更推荐 dsh-TUI，原因不在于它「弱」，而在于它精准匹配终端场景的交互习惯——流式思考与消息回溯这两点，在长会话调试时的价值尤其高。
这里给一条实战建议：起步建议先安装 dsh-market，再通过市场按需安装其余插件，后续的更新管理也一并交给它。先把核心工作流跑通，再逐步添加其他能力。这条路径之所以有效，是因为市场插件本身解决了「插件在哪里找」这个二阶问题——插件发现本身也是插件化设计的一部分。
dsh plugin --profile add 命令拆解：从选 Profile 到验证加载的完整安装链路
dsh 为插件提供了统一的安装入口，一条命令即可完成。命令的基本形式如下：
# 安装插件到 web profile（--profile 指定目标环境，必填）
dsh plugin --profile web add <源>
# 安装插件到 tui 终端环境
dsh plugin --profile tui add <源>
这个命令有三个字段必须理解到位：
- dsh plugin：插件管理的统一入口，安装、管理等动作都从这里进。
- --profile web / --profile tui：必填参数，指定插件要装进哪一套运行环境。这是 dsh 与 npm/Python 安装最本质的区别——你装的不是「到本机」，而是「到某个 Profile」。
- add <源>：指定插件来源。源可以是 npm 包名（如 @linxin666/dsh-web-ui-all@latest），也可以是 GitHub 仓库地址（如 github:zhu1090093659/dsh-web-ui）。
以安装 dsh-web-ui 为例，官方开源地址是 https://github.com/zhu1090093659/dsh-web-ui，对应命令为：
dsh plugin --profile web add @linxin666/dsh-web-ui-all@latest
注意这个命令里的 @latest 后缀。在开发阶段追最新版很方便，但生产环境的插件版本策略需要另外考虑，后面讲版本固定时会展开。
一套完整的安装流程通常是这样的：
选择 Profile
↓
安装插件
↓
检查依赖 / README
↓
重启对应服务
↓
验证插件是否加载
这条链路里，「重启对应服务」是最容易被新手漏掉的一步，也是很多「我明明装了但没生效」问题的根源。注意这里的措辞是「重启对应服务」——因为你只影响了你指定 Profile 的那套环境，不需要把整个 dsh 生态推倒重来。
另外，「检查依赖 / README」这一步不是形式主义。有些插件（尤其是浏览器类）需要额外的浏览器扩展或外部服务，官方会提供一键安装脚本。这类插件建议严格按官方脚本或 README 安装，而不是手动拼命令——因为手动拼很容易漏掉扩展注册这类隐性步骤，导致插件加载成功但功能不工作，排查成本极高。
安装之后，重启后我们就可以在设置的插件列表中查看已安装的插件。这一步就是「验证插件是否加载」的落地动作。我们还可以在左侧列表查看插件的功能，试装皮肤——这既是功能确认，也是体验插件效果的最快方式。
插件列表、功能预览与卸载入口：设置页里的三个操作位
插件装完之后，日常操作其实集中在设置页的三个位置上。理解这三个位置的分工，能省下大量摸索时间。
第一个操作位是插件列表。安装并重启后，我们可以在设置的插件列表中查看已安装的插件。这是确认「装没装上」的第一现场——如果你的插件没出现在这里，那么问题出在安装链路或 Profile 指定上，而不是插件功能本身。
第二个操作位是功能预览与皮肤试装。我们可以在左侧列表查看插件的功能，试装皮肤。这个位置的价值在于「零成本体验」：尤其是对皮肤、主题、桌宠这类不影响核心能力的插件，先在列表里看看效果再决定是否保留，比装完再卸载要省事得多。
第三个操作位是卸载入口。如果要卸载插件，只要在设置菜单的插件列表中点击卸载按钮即可；点击确认卸载即可完成卸载。整个流程没有命令行参与，对不熟悉终端操作的团队成员尤其友好。
把这三个操作位串起来看，你会发现 dsh 的插件管理 UI 设计遵循了一个清晰的原则：发现、预览、清理，全部收敛在同一个列表里。这对插件数量增长后的维护至关重要——当你的 Profile 里堆了十几个插件，一个统一的列表视图几乎是你唯一的可控抓手。
这里补一条实战经验：试装新插件时，建议一次只加一个，装完立刻验证并观察是否有副作用。原因是插件可以叠加，能力越强的插件对运行时状态的改动越大。如果你一次装了五个，出问题时你无法判断是哪个引入的；而一次一个，问题定位成本几乎为零。这条原则在安装浏览器类、订阅类等高权限插件时尤其重要。
UI 增强四件套：dsh-web-ui、DSH-better-sidebar、dsh-TUI、dsh-at-file 的能力边界
UI 增强与工作台这一类插件，解决的是「界面不够好用」的问题，目标是把 dsh 从一个命令行工具升级成接近 IDE 的完整工作台。这一类里有四个插件最值得讲清楚边界，因为它们名字相近、定位却完全不同，选错了就是白装。
先用一张表把四者的定位钉死：
| 插件 | 解决的问题 | 安装命令 |
|---|---|---|
| dsh-web-ui | Web UI 全家桶：任务看板、Git 图谱、右侧面板、远程移动端、桌宠、实时 Token 统计、皮肤中心 | dsh plugin --profile web add github:zhu1090093659/dsh-web-ui |
| DSH-better-sidebar | 完整侧边栏工作台：文件树 / 编辑器、终端、Git、子代理，支持第三方插件注册新 Tab | dsh plugin --profile web add dsh-better-sidebar |
| dsh-TUI | Claude Code 风格全屏终端 TUI：流式思考、双击 Esc 回溯、状态栏、模型切换 | dsh plugin --profile tui add @deepseek-harness-tui/dsh-tui |
| dsh-at-file | 输入框 @ 快速搜索并引用工作区文件 / 目录 | dsh plugin --profile web add github:omdsh-dev/dsh-at-file |
逐个说明它们的能力边界：
- dsh-web-ui 是「面」的补齐。它并不只是简单换一个界面，而是围绕 Agent 工作流补齐任务看板、Git 图谱等工作台能力。注意它的功能清单里有实时 Token 统计和皮肤中心——这意味着它不只是 UI 壳，还承载了运行时可观测性的一部分。适合需要「一个完整 Web 工作台」的用户。
- DSH-better-sidebar 是「结构」的补齐。它解决的则是「工作区组织能力」的问题，提供常驻侧边栏。文件树 / 编辑器、终端、Git、子代理这些能力被组织进侧边栏，而且支持第三方插件注册新 Tab——这意味着它本身是一个可扩展的容器。适合想把 dsh 做成「AI IDE」的用户。
- dsh-TUI 是「终端体验」的补齐。它在终端里提供流式输出与消息回溯，体验接近 Claude Code。注意它装的是 tui Profile，不是 web Profile——这是四件套里唯一跨 Profile 的一个，也再次印证了 Profile 机制的必要性。
- dsh-at-file 是「输入交互」的补齐。它的用法非常直观，在输入框输入 @ 即可搜索并引用工作区文件。示例用法：
请分析 @runoob-demo/src/main.py
比较 @runoob-demo/src/api 和 @runoob-demo/src/service
对代码 Agent 来说，这种交互方式比手动复制文件内容自然得多。它不改变 Agent 的能力上限，但显著降低了「把正确上下文喂给 Agent」的操作成本——从工程角度看，这恰恰是上下文质量问题里最被低估的一环。
把这四个插件放在一起，可以看出一个清晰的分工逻辑：dsh-web-ui 管「工作台长什么样」，DSH-better-sidebar 管「工作区怎么组织」，dsh-TUI 管「终端用户怎么用」，dsh-at-file 管「上下文怎么快速引用」。它们可以叠加，也可以按需取舍。其中 dsh-web-ui 与 DSH-better-sidebar 是社区人气最高的组合，前者补齐 Web 界面的功能面，后者提供常驻侧边栏——如果你准备把 dsh 作为主力开发环境，这两个几乎是最优先考虑的起点。
最后提醒一句安装层面的细节：这四个插件里有三个装了 web Profile、一个装了 tui Profile，而它们的源格式也各不相同——有 npm 包名（dsh-better-sidebar）、有带 @scope 的包（@deepseek-harness-tui/dsh-tui）、有 github: 前缀的仓库地址。这意味着你在抄安装命令时，务必连源格式一起抄，不要只抄插件名，否则很可能安装失败。至于具体的源格式规范，以及安装第三方插件时必须做的四项安全检查（源码、许可证、依赖、版本固定），我们会在下半部分继续展开。接下来，我们将进入视觉与多模态、多 Agent 与工作流、浏览器自动化、记忆与上下文迁移、插件发现与管理等核心插件类别的深度解析，并给出完整的场景化推荐与安全清单。
上一段我们把 dsh 的插件分类、Profile 隔离机制、`dsh plugin` 的统一安装入口，以及一批 UI/工作台插件拆开讲透了。这一段的重点落在「能力型插件」上：从把纯文本模型补成多模态的视觉外挂，到多 Agent 协作、浏览器自动化，再到上下文治理与长期管理姿势，最后给出一份可以直接照做的落地清单。
视觉能力外挂：modlens 的结构化视觉证据与 dsh-vision-toolkit、dsh-vision-router 的分工
dsh 本身并不是天生多模态的运行时，它的策略是把视觉能力以插件形式「外挂」给原本以文本为中心的 Agent。这里最容易被误解的一点是：社区里所谓「让纯文本模型秒变多模态」，并不是把图片塞进模型上下文让它自己去猜，而是先用一层插件把图像转化成结构化视觉证据，再交给文本模型处理。
以 modlens 为例，它的核心思路是：当你往会话里粘贴一张网页截图，模型拿到的不是一句笼统的「这是一张网页截图」，而是一组可被文本模型精读的证据——包括 OCR 文本（页面上有哪些文字、各自内容是什么）、布局信息（区块的层级与摆放关系）、坐标（每个元素在画面中的位置边界）以及语义标签（这块区域是导航、是按钮、还是正文）。这套输出对下游文本模型非常友好：模型不需要理解像素，只需要阅读一份带位置和语义的「页面说明书」，就能回答用户的问题，比如「截图里那个提交按钮在页面哪个位置」「正文里的价格是多少」。
这种方式的工程价值在于它把不确定性从模型层挪到了插件层。OCR 的准确率、版面还原的保真度、坐标的精度，都由视觉插件负责并可单独调优；文本模型只负责语义推理。出了问题也更容易定位：如果 OCR 把字符认错，那是视觉链的问题；如果 OCR 对了但模型答错，那是推理链的问题。相比之下，把图片直接丢给一个纯文本模型，你既拿不到中间证据，也无法判断错误到底出在哪一环。
社区里另外两款视觉插件做了不同的取舍。dsh-vision-toolkit 是一个更完整的视觉工具箱，覆盖意图问答、长截图 OCR、UI 还原、grounding（把自然语言指代定位到画面中的具体元素）以及像素 diff（对比两次截图的差异）。如果你的日常工作集中在前端开发、UI 复刻、截图比对这类场景，它比只做 OCR 的方案实用得多——因为 UI 还原要的不只是文字，还需要知道「这个按钮长什么样、在哪个位置、和上一版差了几个像素」。而 dsh-vision-router 的定位是免费视觉链与像素级工具，支持把视觉推理路由到本地的 Ollama 或 LM Studio。对数据敏感、希望视觉能力完全本地化部署的团队，这一条尤其关键：图片不出本机，模型调用走本地推理服务，既省成本也满足合规要求。
三者的分工可以这样理解：modlens 解决「把图片变成文本模型能读的证据」，dsh-vision-toolkit 解决「在前端与 UI 场景下做更精细的视觉操作」，dsh-vision-router 解决「视觉推理跑在哪里、要不要联网」。它们可以叠加使用，但起步阶段不建议全装，先明确你的主要场景：通用 OCR 与文档理解优先 modlens，前端复刻优先 dsh-vision-toolkit，本地化与成本敏感优先 dsh-vision-router。
下面的表格把三款插件的定位与适用边界放在一起对比，方便选型：
| 插件 | 核心产出 | 典型场景 | 部署与成本倾向 |
|---|---|---|---|
| modlens | 结构化 OCR、版面、坐标、语义标签 | 网页截图分析、文档理解、图片内容提取 | 通用，依赖外部或本地视觉模型 |
| dsh-vision-toolkit | 意图问答、长截图 OCR、UI 还原、grounding、像素 diff | 前端开发、UI 复刻、截图回归比对 | 功能覆盖面大，适合深度视觉工作流 |
| dsh-vision-router | 免费视觉链与像素级工具，可路由本地推理 | 本地化部署、成本与合规敏感场景 | 支持 Ollama / LM Studio 本地运行 |
安装命令统一走 dsh plugin --profile web add 入口，例如把 modlens 装进 Web Profile：
# 安装视觉插件到 web profile
dsh plugin --profile web add @liustack/modlens
# 前端与 UI 复刻场景可叠加视觉工具箱
dsh plugin --profile web add @anionex/dsh-vision-toolkit
# 本地化视觉链：先确认本机 Ollama 或 LM Studio 已就绪
dsh plugin --profile web add dsh-vision-router
# 装完后重启对应服务，再到设置的插件列表确认加载状态一个常见的工程坑是：把视觉插件装到错误的 Profile 上。如果你日常在终端 TUI 里工作，却把视觉插件装进了 web Profile，那么终端会话里并不会出现视觉能力——Profile 之间是隔离的，插件装在哪套环境，就在哪套环境生效。另一个坑是本地视觉链没启动就先装路由插件，结果调用时找不到推理服务。建议的操作顺序是：先确认本地模型服务可用，再装 dsh-vision-router，最后在会话里用一张截图做端到端验证。
皮肤与桌宠也是插件：dsh-deep-whale 与 whale-girl/dsh-pet 系列的安装差异
如果要找最能说明「一切皆插件」彻底程度的证据，皮肤和桌宠是最好的例子。在传统 Agent 里，主题、外观、彩蛋通常被写死在核心里，改起来要么等官方更新，要么自己维护一份分叉。而在 dsh 里，连「界面长什么样」「桌面多不多一只宠物」都是插件，随时可加可删，且互不影响核心逻辑。
第一个例子是 dsh-deep-whale。这是一套鲸鱼娘皮肤系列，包含深海女仆工坊等主题，并且支持亮色与暗色两套模式。它的意义不只是好看：对长时间盯着屏幕的开发者来说，亮暗模式切换是实打实的体验需求。以前这类需求得靠改主题配置文件、覆盖样式，现在一条安装命令就能挂上去，不满意就在设置里卸载，干净利落。
第二个例子是 whale-girl 与 dsh-pet 系列桌宠。它把一只小鲸鱼放到工作台上，可以拖拽、可以喂食、可以互动。这听起来像是纯粹的娱乐，但它恰好证明了插件系统的边界：插件的权限和能力足够大，足以渲染出一个可交互的、带状态的 UI 组件，并且和 Agent 的工作台共存。能让桌宠跑起来，说明插件加载、生命周期管理、UI 挂载点这几条链路都是通的。
安装差异需要特别注意。dsh-deep-whale 走的是标准 GitHub 源安装路径：
# 安装鲸鱼娘皮肤系列（支持亮 / 暗色模式）
dsh plugin --profile web add github:Small-tailqwq/dsh-deep-whale而 whale-girl 与 dsh-pet 系列在社区里有多个仓库，彼此实现、依赖、配置项可能不一致，没有一条通用的安装命令能覆盖全部。正确的做法是按各仓库自己的 README 安装，不要凭经验套用别人的命令。这类插件通常还会带一些额外配置，比如宠物资源包路径、交互开关、初始位置等，装完要回到设置的插件列表里核对是否加载成功，再重启对应服务。
工程上的建议是：皮肤和桌宠属于「纯表现层插件」，风险相对可控，但仍然要看清依赖。一个看起来只是换皮的插件，如果引入了一堆无关依赖，或者需要额外的网络权限，就值得警惕。另外，皮肤类插件往往和 UI 插件存在样式耦合——如果你同时装了 dsh-web-ui 和某款皮肤，出现样式冲突时，优先确认两者的加载顺序与作用域，必要时先禁用皮肤定位问题。
多 Agent 与工作流的分工：dsh-agent-teams 拆任务、dsh_workflow 固化流程
UI 插件解决的是「怎么使用 dsh」，而多 Agent 插件解决的是「怎么让多个 Agent 一起干活」。这两类插件的抽象层级完全不同，也正因如此，它们可以叠加出很强的工作流。
dsh-agent-teams 的思路非常直观：把当前会话变成「队长」，由队长把任务拆解给多个可以继续对话的子 Agent。注意这里的关键词是「可续聊」——子 Agent 不是一次性的函数调用，而是有独立对话上下文的执行单元，你可以继续和某个子 Agent 追问、修正、追加需求。除此之外，它还支持带依赖的任务编排和自动调度，以及一个实时面板用来观察各个子 Agent 的进展。
「带依赖的任务」这一点值得展开。真实开发任务很少是平铺的，前端页面依赖后端接口定义，测试依赖前后端都完成，Review 依赖测试通过。agent-teams 允许你表达这些依赖关系，由调度器按拓扑顺序推进，而不是所有子 Agent 一拥而上。这在实际工程里能省掉大量人工等待和手动协调。实时面板则解决了「黑盒焦虑」——你能看到每个子 Agent 当前在做什么、卡在哪里，而不是等一个最终结果。
而 dsh_workflow 解决的是另一个维度的问题：把 Agent 的工作流程固定下来并反复执行。官方描述里它是一层可生成、可保存、可恢复、可观察、可治理的 Workflow 层。翻译成工程语言就是：把一次成功的执行路径沉淀为可复用的流程定义，下次遇到同类任务直接恢复执行，而不是让 Agent 每次即兴发挥。
两者的分工可以一句话概括：agent-teams 解决「多个 Agent 一起工作」，workflow 解决「把 Agent 工作流程固定下来并反复执行」。前者负责并行与协作，后者负责确定性与可复用性。它们并不冲突，反而是互补的。
安装命令如下，注意 agent-teams 走 npm 风格源，而 dsh_workflow 目前是 GitHub 源：
# 多 Agent 协作：当前会话变队长
dsh plugin --profile web add @nanmicoder/dsh-agent-teams
# 工作流层：可生成、保存、恢复、观察、治理
dsh plugin --profile web add "github:dsh-external/dsh_workflow#main"
# 注意：生产环境不建议长期追踪 main 分支，建议固定到具体 commit一个常见的坑是：把 agent-teams 的「队长」理解成万能调度器，把特别重的任务无限拆下去，结果子 Agent 数量爆炸、Token 成本失控、依赖关系复杂到没人看得懂。建议给拆解设上限，比如子 Agent 数量控制在个位数，依赖层级不要超过三层。另一个坑是 workflow 追 main 分支——这在开发阶段没问题，但如果这套流程已经进入日常生产，main 一更新就可能出现「昨天能跑，今天崩了」。这一点在后面的小节还会展开。
Leader/Frontend/Backend/Test/Review 执行链：从需求拆解到 Workflow 反复执行的完整流转
把 agent-teams 和 workflow 组合起来，就能形成一条完整的执行链。这条链路是理解 dsh「从工具走向运行时」的最好样本。
起点是一个需求。这个需求进入会话后，当前会话作为 Leader Agent 首先做任务拆解：把一个模糊的需求翻译成若干个可独立执行、有明确交付物的子任务。接着，各个子 Agent 依次登场——Frontend Agent 负责界面实现，Backend Agent 负责接口与数据层，Test Agent 负责验证，Review Agent 负责把关。这些子 Agent 不是孤立的：它们之间带着依赖关系，由自动调度器按顺序推进。前端要等后端把接口定义确定下来，测试要等前后端都完成，Review 在测试通过后启动。
当这条链路走通一次之后，它的价值不只是「这一次任务完成了」，而是这个执行模式本身可以被 Workflow 层固化下来：保存为流程定义，下次遇到同类需求时恢复执行。于是流程从「每次重新编排」变成「复用已验证的路径」，可观察性也有了落点——你能看到每一步的输入输出，出了问题也能定位到具体环节。
把这条链路写出来是这样的：
需求
↓
Leader Agent（任务拆分：界定交付物与依赖）
├── Frontend Agent
├── Backend Agent
├── Test Agent
└── Review Agent
↓
Workflow（流程固化：生成 / 保存 / 恢复 / 观察 / 治理）
↓
最终结果这时候 dsh 的角色发生了质变：它不再只是「AI 帮我写代码」，而是「AI Agent 自己组织多个执行单元完成任务」。开发者从「逐行指挥」变成「定义目标与约束」，具体怎么拆、怎么调度、怎么验证，交给运行时和插件去完成。这也是为什么说 dsh 的价值不在于自带多少功能，而在于它提供了一层可组合的运行时。
工程上要提醒的是：这条链路对上下文质量的要求非常高。Leader 拆得清楚，子 Agent 才不会跑偏；子 Agent 之间的接口约定如果不明确，Frontend 和 Backend 很容易各写各的，最后对不上。实践建议是在 Leader 拆解阶段就把「接口契约」和「验收标准」写清楚，作为子任务的显式输入，而不是指望子 Agent 自己猜。
dsh-browser 与 BrowserSkill：直接驱动本机 Chrome 保留登录态与 Cookie
Agent 真正进入生产环境后，仅仅能读写代码往往不够，还需要打开网页、读取页面内容、点击输入、带着登录态执行任务。这就是浏览器类插件的用武之地。
这里最关键的差异是：dsh-browser 直接驱动本机 Chrome，而不是启一个干净的无头浏览器。这个区别在工程上是决定性的。无头浏览器方案每次启动通常都是一张白纸——没有登录状态、没有 Cookie、没有你本机浏览器里积累的会话。于是 Agent 要完成任务，就得先走一遍登录流程，遇到验证码、双因素认证、风控策略，很容易卡死。
而 dsh-browser 复用本机 Chrome 的原有登录状态与 Cookie，Agent 不必每次从零登录。对网站自动化、后台操作、数据采集、Web 测试这类需要登录态的任务，这是实打实的效率差异。你平时在 Chrome 里登录好的账号，Agent 可以直接用，任务从「先解决登录」变成「直接干活」。
腾讯开源的 BrowserSkill 走的是同类思路，提供真实已登录浏览器的自动化方案，形态是 CLI 加浏览器扩展。这类方案共同的特点是：它们不只是装一个 npm 包那么简单，往往还需要配套的浏览器扩展或其他外部组件。
正因如此，安装方式必须谨慎。社区里 dsh-browser 是由仓库提供一键安装脚本（包含浏览器扩展），BrowserSkill 是按仓库说明安装。正确的做法是按官方脚本或 README 安装，而不是手动拼命令。原因有三：第一，浏览器扩展需要以特定方式加载到浏览器里，手动拼命令很容易漏掉这一步；第二，这类插件可能涉及与浏览器通信的本地端口或桥接进程，参数不对就会连不上；第三，扩展的权限范围较大，官方脚本通常会明确提示你授予了哪些权限，手动安装则可能在不清楚权限的情况下就把扩展装上去了。
安全层面要特别强调：浏览器自动化插件的权限等级明显高于 UI 皮肤类插件。它能读你已登录页面里的内容、能代替你点击和输入，这意味着一旦插件代码有问题，影响面可能是你的账号和数据。所以安装前务必先看源码，重点审查涉及浏览器控制、文件系统、网络请求的部分；固定版本或 commit；不要把来源不明的浏览器扩展随手装进主力浏览器。
上下文治理与迁移：dsh-chat-import 无损导入、dsh-context 看 Token 趋势
Agent 用得越久，真正的问题往往不是模型不够聪明，而是上下文越来越乱——这是长时间使用 Coding Agent 的开发者都会遇到的现实。围绕这个问题，dsh 有一组专门的插件。
dsh-chat-import 解决的是「迁移」问题：它可以从 Claude Code、Codex、ChatGPT、Cursor、Gemini 等工具无损导入历史会话。对已经大量使用其他 Coding Agent 的用户来说，这类迁移插件的价值非常高——你过去积累的对话、决策记录、上下文线索不必丢掉，可以带进 dsh 继续用。这降低的其实是切换成本：以前换工具意味着从零开始，现在可以带着历史进来。
dsh-context 解决的是「看清」问题：它提供上下文组成、Token 趋势、压缩与裁剪的可视化面板。你可以看到当前上下文是由哪些部分构成的——系统提示、历史消息、工具调用结果、文件内容各占多少；可以看到 Token 消耗的趋势，判断是不是在往失控的方向走；可以在需要时做压缩或裁剪，并观察效果。对长时间运行的 Coding Agent，这种可视化不是锦上添花，而是必需品：你看不见上下文，就没法治理上下文。
这里要引出一个更根本的判断：Agent 的效果很大程度上取决于「模型能力 + 上下文质量 + 工具能力 + 任务状态」，而不是单纯看模型 benchmark。很多人选工具时盯着模型跑分，但实际体验的差距往往来自另外三项。上下文质量差，再强的模型也会答偏；工具能力弱，Agent 就只能空谈；任务状态管理混乱，多轮之后就会丢失目标。dsh 的插件体系恰好把这几项都变成了可插拔、可观测、可替换的部分，这也是它相比「一个功能写死的 Agent」的长期价值所在。
工程建议是：如果你是从其他工具迁移过来的，先装 dsh-chat-import 把历史带进来，再装 dsh-context 建立上下文可观测性。这两个插件配合 dsh-at-file（输入框 @ 引用工作区文件）可以组成一套很顺手的迁移组合——历史会话有了，上下文看得见了，引用文件也更自然了。
# 从其他 Coding Agent 导入历史会话
dsh plugin --profile web add dsh-chat-import
# 上下文组成、Token 趋势、压缩 / 裁剪可视化面板
dsh plugin --profile web add dsh-context
# 配合 @ 引用工作区文件，比如：
# 请分析 @runoob-demo/src/main.py
# 比较 @runoob-demo/src/api 和 @runoob-demo/src/service需要提醒的坑是：导入历史会话后，上下文体积可能迅速膨胀，反而拖慢响应、拉高成本。正确姿势是导入之后立刻用 dsh-context 看一次 Token 趋势，对不再需要的历史做压缩或裁剪，而不是一股脑全塞进上下文。迁移的目的是保留有价值的决策线索，不是把旧包袱原样搬过来。
2026 年 9 月的最新进展：dsh-find-plugin 自然语言找插件与 dsh-market 的长期管理姿势
当插件数量越来越多，新的问题自然出现：插件在哪里找。dsh 对这个问题的回答很符合它的一贯风格——「寻找插件」本身也是插件。
dsh-market 在设置页内置了一个插件市场，支持搜索、分类与一键安装更新。这意味着你不需要再去 GitHub 上逐个翻仓库、手动抄安装命令，常用插件在设置里就能找到并装好，后续的更新也可以交给它。对准备长期使用 dsh 的人来说，这几乎是第一优先级的插件。
dsh-find-plugin 更进一步：直接在会话里用自然语言找插件，返回描述与安装命令。比如你直接问「有没有可以分析网页截图的插件」，它会返回插件名称、功能描述和对应的安装命令。这把「发现插件」这件事从「知道关键词再去搜」变成了「描述需求就能找到」。对刚接触 dsh、还不熟悉插件命名体系的新用户，这个入口非常友好。
安装命令如下：
# 设置页内置插件市场：搜索、分类、一键安装 / 更新
dsh plugin --profile web add dshmarket
# 会话内自然语言搜索插件，返回描述与安装命令
dsh plugin --profile web add dsh-find-plugin如果准备长期使用 dsh，建议的姿势是：先安装 dsh-market，再通过市场按需安装其余插件，后续的更新管理也一并交给它。不要一开始就手动去搜几十个 GitHub 仓库，那样既低效，也容易装进来源不明或不兼容的东西。先把核心工作流跑通，再逐步添加其他能力——这是 dsh 最合适的使用方式，不是「安装、打开、结束」，而是渐进式搭建。
接下来是生产实践里最重要的一条纪律：固定版本或 commit，不要追 latest 或 main。dsh 仍处于快速迭代阶段，社区插件的 API 也可能发生变化。始终追踪 main 分支，就会有「今天能运行，插件作者一更新，明天突然崩掉」的风险。生产环境里这种不确定性代价很高，因为你很难在第一时间判断是插件更新导致的，还是自己的配置出了问题。
| 做法 | 示例写法 | 适用阶段 | 风险 |
|---|---|---|---|
| 追踪分支 | github:dsh-external/dsh_workflow#main | 个人尝鲜、跟进新特性 | 上游一改就可能不可用 |
| 固定 commit | github:xxx/xxx@a1b2c3d | 生产环境、团队协作 | 需主动跟进安全与功能更新 |
具体语法以插件管理器当前版本为准，但原则是明确的：在生产环境把依赖钉到具体 commit，把「升级」变成一个有意识、可回滚的动作，而不是被动接受。可以这样理解两者的取舍：追 main 换来的是最新特性，付出的是稳定性；固定 commit 换来的是可复现，付出的是要自己安排升级节奏。团队协作场景下，后者几乎总是更划算。
安装第三方插件还有四项检查值得形成习惯：先看源码，尤其是涉及 Shell、浏览器、OAuth、API Key、文件系统、网络权限的插件，不要只看 README 的宣传；看许可证，准备商业使用、二次开发或企业内部部署时，提前确认 License 限制；看依赖，一个看起来只是 UI 插件的项目，如果引入大量不必要的依赖，就值得警惕；固定版本或 commit，理由如上。想继续探索更多插件，可以从 GitHub topic「dsh-plugin」、社区维护的精选清单，以及社区插件目录站入手。订阅类插件尤其要小心——它们往往涉及账号授权与第三方服务，安全风险明显高于普通 UI 插件，不要仅凭「免费模型」「免费订阅」这类关键词就安装，务必先看清源码、权限范围与实际授权流程。
总结与最佳实践
到这里，dsh 的内置与社区插件全景就基本铺开了。把全文要点压缩成一份可执行清单：
- 先理解 Profile 隔离：插件装在哪套环境（web / tui / headless）就在哪套环境生效，装错 Profile 是最常见的「插件没反应」原因。
- 统一安装入口：所有插件都走
dsh plugin --profile <目标> add <源>，装完重启对应服务，再到设置的插件列表验证加载状态。 - 视觉能力按场景选：通用 OCR 与文档理解选 modlens；前端复刻、UI 还原、像素 diff 选 dsh-vision-toolkit；本地化与成本敏感选 dsh-vision-router（配合 Ollama / LM Studio）。记住原理是「先把图片转成结构化证据，再交给文本模型」。
- 皮肤与桌宠也是插件：dsh-deep-whale 走标准 GitHub 源安装，whale-girl / dsh-pet 系列按各仓库 README 安装，不要套用别人的命令。
- 多 Agent 与工作流配合用：agent-teams 负责并行协作与依赖调度，workflow 负责把流程固化、反复执行。给子 Agent 数量和依赖层级设上限，避免成本失控。
- 执行链要点是契约：Leader 拆解阶段就把接口契约和验收标准写进子任务，别指望子 Agent 自己对齐。
- 浏览器插件要认清权限：dsh-browser 直接驱动本机 Chrome 保留登录态与 Cookie，与无头方案差异巨大；涉及浏览器扩展时按官方脚本或 README 安装，优先审查源码与权限。
- 上下文要治理，不要囤积：dsh-chat-import 负责迁移，dsh-context 负责可视化与压缩裁剪；导入历史后立刻看一次 Token 趋势，及时清理。
- 效果的四要素：模型能力 + 上下文质量 + 工具能力 + 任务状态，缺一项都会拖后腿，不要只盯模型跑分。
- 长期管理姿势：先装 dsh-market，再按需扩展并交给它管理更新；用 dsh-find-plugin 在会话里用自然语言找插件。
- 生产纪律：固定 commit 而非追 latest / main；升级要可回滚，不要被动接受上游变动。
- 安装四查：查源码（重点看 Shell、浏览器、OAuth、API Key、文件系统、网络权限）、查许可证、查依赖、固定版本或 commit。
- 渐进式搭建：从安装 Harness、选择 Profile、装基础插件开始，依次增加工具、Agent、Workflow、Memory / Context，最终形成自己的 Agent Runtime。
一句话收尾：dsh 的核心运行时负责连接能力，插件负责提供能力，Profile 负责组织能力，而你负责定义自己的 Agent。如果这个生态继续发展下去，它可能不只是一个「AI 编程工具」，而更像一个可组合的 Agent 运行环境——而这，才是 Everything is a Plugin 最值得研究的地方。