DeepSeek Harness（DSH）刚出来时，很多人的第一反应是：“又一个 Coding Agent？”但真正折腾过一阵子会发现，它和普通 Coding Agent 的思路并不完全一样。DSH 更像一个可以自己组装的 Agent 底座：模型、工具、Agent Loop、Web UI、Workflow，甚至运行方式，都能通过插件组合。
也正因为如此，DSH 真正好玩的地方不是“裸奔”的 Harness，而是社区正在快速出现的各种插件。官方目前仍将 DSH 定位为开发者预览版，核心插件与基础 API 都会继续演进；更适合把它当成一个不断进化的实验型 Agent 平台来使用。
先把 Harness 用顺，再给它加眼睛、接上浏览器，最后让多个 Agent 分工协作。插件不是装饰，而是把 DSH 变成工作台的过程。
更新说明
下面的定位以各插件当前 README、安装说明和近期社区讨论为准。社区插件并不等于官方能力：安装前应核对维护状态、依赖、权限和目标 DSH 版本，遇到问题优先在独立 profile 中验证。
01｜dsh-anchored-standard
V4 Pro 重度用户可优先试，不是通用必装
结论先说：如果你主要用 DeepSeek V4 Pro 跑 Coding 或 Agent 任务，我推荐优先试这个 preset；如果主力不是 V4 Pro，或不准备做对照验证，就不要把它当成所有项目的默认插件。社区把“工具给多了反而把模型带到另一条推理轨迹”的现象戏称为“夯拉二象性”，但这不是官方术语，也不应被写成 V4 Pro 在所有任务上的普遍定律。
它的机制是“先收后放”：第一个模型请求严格对齐官方 Minimal 条件，只暴露 bash + str_replace_editor 两个真实工具 schema，并移除自动注入的工作区摘要与技能提醒。默认在第一次持久化的 tool/call 或第一条助手回复后，才进入常驻工具集；这不是一次性解锁全部 Standard 工具，较重工具仍通过发现工具按需解锁。
推荐判断
推荐优先试：V4 Pro 是主力模型，常跑代码和智能体任务，并愿意在空白会话中用同一批任务对照官方默认方式与这个插件。
02｜dsh-web-ui
Web 界面增强全家桶
dsh-web-ui 更准确的定位是 Web UI 插件与皮肤集合，而不是单一“界面增强包”。当前集合覆盖任务看板、Git 图、右侧面板、远程移动端 UI、实时 Token 统计和皮肤中心等能力。它适合希望逐项扩展 DSH Web UI 的用户；不必为了“完整工作台”把所有组件一次装上，按日常工作流选择需要的模块更容易排查兼容问题。
03｜DSH-better-sidebar
把侧边栏变成 IDE 工作台
这个插件解决的问题很具体：侧边栏不好用怎么办？DSH-better-sidebar 的当前能力比“多一列导航”更接近一个完整工作台：它提供右侧栏与底部面板的双工作区，标签可以拖拽拆分或合并；内置文件渲染和编辑、真实 Terminal、Git 面板、后台任务与子 Agent 信息，也允许第三方插件注册新的页签和文件查看器。
这也是它更适合长期 Coding 环境的原因。不过真实终端、Git 与后台任务都意味着更大的操作面，安装前应确认项目来源，尤其不要把来源不明的插件和高权限仓库、生产凭据混在同一个 profile。
04｜modlens
让纯文本模型拥有看图能力
这是整套插件里很有意思的一个方向。当前项目说明将 ModLens 定义为给纯文本 DeepSeek、GLM 等模型外挂视觉的原生 DSH 插件：它会自动识别已经配置好的纯文本模型，生成带 (modlens vision) 标记的可选模型，并通过 modlens_read_image 工具把图片转为结构化证据，而不是让文本模型“猜图”。
典型链路
图片 → ModLens → 视觉引擎 → OCR、版面与语义证据 → DeepSeek Harness 继续执行
它支持 Gemini、Anthropic、OpenAI 兼容接口和若干可复用的本地 Agent CLI；未固定 provider 时会按配置形成故障转移链。因此更应关注引擎授权、额度与图片数据流向，而不仅是“能不能识图”。
05｜dsh-vision-toolkit
视觉工具箱进阶版
如果说 ModLens 偏向把图片“读成证据”，那么 dsh-vision-toolkit 更偏向把视觉变成一组可组合的工程工具。它以原生 Profile Bundle 方式接入 DSH Web 与 Headless，覆盖带意图的图片问答、长截图 OCR、UI 还原、元素定位、图片裁剪、像素对比、HTML 截图与文件产物等能力。
对于前端开发者，这能形成“截图 → 视觉分析 → 发现 UI 问题 → 修改代码 → 重新截图 → 像素或语义复核”的闭环。要注意的是，它需要单独配置视觉模型；安装到 profile 后通常还需要重启 DSH 服务，单纯刷新网页并不能让宿主侧插件生效。
06｜dsh-browser
让 Harness 真正操控浏览器
前面几个插件是在强化 DSH 本身，dsh-browser 则是把它接到你正在使用的 Chrome 标签页。它通过浏览器侧边栏读取页面的结构化内容与编号交互元素，能够点击、输入、滚动与导航，并复用当前标签页的登录态、Session 和 Cookie；它不是再起一个隔离浏览器，也不只是截屏识图。
- 测试网页和登录流程
- 检查前端页面
- 操作后台系统
- 自动化重复操作
使用边界
因为它会接触当前浏览器会话，最好为 DSH 单独建一个 Chrome profile；涉及财务、生产后台、管理员账户和敏感数据时，先确认当前标签页与权限，再让 Agent 执行操作。
07｜dsh_workflow
可生成、可治理、可恢复的多 Agent 工作流
最后一个，也是最值得长期关注的方向：Workflow。一个 Agent 已经很强，那如果让多个 Agent 分工呢？例如 Agent A 负责需求分析，Agent B 负责写代码，Agent C 负责测试，Agent D 负责 Code Review。此时问题从“模型够不够聪明”转向“Agent 之间怎么协作，以及失败后如何恢复”。
dsh_workflow 的当前定位不是固定的“四角色流水线”，而是把 DSH 一次性的多 Agent 调度升级为可生成、可保存、可治理、可观察、可恢复的 Workflow 层。它适合需要把复杂任务沉淀为可重复流程的场景。若只是临时拉起一个 Agent Team 处理单次任务，社区中的 dsh-agent-teams 会是更直接的补充方向。
这 7 个插件怎么装更合理
第一次玩 DSH，不建议一口气全部安装。按需求逐步搭建，反而更容易观察每种能力带来的变化。更重要的是：社区插件与 DSH 进程共享权限，安装过程还可能执行构建脚本；优先从源码、许可证和固定版本开始验证，而不是复制一长串安装命令。
第一阶段：确定主力模型
如果你的主力是 V4 Pro 且以 Agent Coding 为主，把 dsh-anchored-standard 作为第一项 A/B 测试；其他模型或普通使用场景，先保留官方 Standard，再按需加一个 UI 插件或 DSH-better-sidebar。
第二阶段：按问题选一种视觉路线
想给纯文本模型补“读图”能力，优先试 modlens；需要 OCR、像素对比和 UI 验证工具，再选择 dsh-vision-toolkit。两者都要先配置视觉引擎与数据边界。
第三阶段：在独立浏览器 profile 中试 Browser
dsh-browser 应先用于测试站点、演示账户或低风险后台，再进入真实登录态。
第四阶段：把已验证的流程沉淀下来
用 dsh_workflow 管理可重复的复杂任务，并把 Anchored Standard 的收益与代价记录为可复核的对照结果。
我最推荐的组合
如果让我自己搭一套 DSH，我会先确定主力模型：V4 Pro 重度 Agent Coding 用户先用 Anchored Standard 与官方 Standard 做一轮对照；其他情况先把官方 Standard 用顺，再按需接 UI、视觉能力与 Browser，最后才把成熟任务交给 Workflow。这个顺序更符合实际使用过程：先确认基础行为，再扩展输入与活动范围，最后再处理多个 Agent 的协作成本。
很多人把 DSH 理解成“DeepSeek 又做了一个 Coding Agent”。但它更值得关注的地方，其实是把 Agent 拆成可以组合的能力：模型可以换、工具可以换、UI 可以换、Workflow 可以换，连 Agent Loop 本身也可以通过插件组合。
裸装只是开始，插件才是 DSH 真正有意思的地方。
参考与延伸阅读
- DeepSeek Harness 官方介绍 —— 核对开发者预览状态、插件化架构与默认工具模式。
- dsh-anchored-standard 与 dsh-web-ui —— 核对双阶段使用方法与网页界面插件集合的实际定位。
- ModLens —— 了解模型选择、视觉引擎与结构化证据输出。
- DSH-better-sidebar 与 Agent Vision Toolkit —— 核对工作台与视觉工具能力。
- dsh-browser、dsh_workflow 与 dsh-agent-teams —— 核对浏览器会话复用、可管理工作流程与临时团队协作的实现说明。
本文于 2026-08-16 按公开项目说明更新。DSH 与社区插件仍在快速迭代，安装前请结合目标版本、真实权限和项目环境验证兼容性。
