DSH 最好用的 10 个外部插件：往空壳内核里塞战斗力

我前两天把 DeepSeek Harness（大家叫它 DSH）的官方核心插件拆了一遍，写完才意识到一个问题：官方那套东西太少了。DSH 的设计哲学是「Everything is a Plugin」，开箱几乎是个空壳，连读文件、识图这种基础能力都得自己装。官方核心那十来个包只是把「引擎能转起来」这件事补齐，真正的战斗力都在 GitHub 上那 1000 多个社区仓库里。

所以这篇我不聊官方核心了。我只聊从外面装进来的东西，也就是社区开发者打上 dsh-plugin 标签的那些第三方插件。我花了几个晚上真去装、真去读它们的实现，挑出 10 个我觉得程序员日常最用得上的。每个我都讲清楚它到底干什么、你为什么需要、它又是怎么挂进 DSH 那个 Cordis 内核的。

GitHub 上打着 dsh-plugin 标签的公开仓库现在已经破千。想自己逛的话，去 GitHub topic 页 或者深求社区的 PluginHub 翻就行。下面这张图是 PluginHub 的界面，你能看到它已经按 UI 增强、工作流、模型接入这些类目分好了。

外部插件是怎么「装进来」的

在聊具体插件前，得先讲清楚它们是怎么进到系统里的。这是 DSH 跟很多「装个扩展要重启」的平台不一样的地方，也是它底层那篇 Cordis 论文说的「可逆副作用」在真实使用里的样子。

官方文档给的安装命令长这样：

# 装一个外部插件包（指向 GitHub 仓库，可带 #ref 指定版本）
dsh plugin --profile web add "github:owner/repo#ref"

# 装完要重启对应的 profile
dsh --profile web

关键在于 package.json 里要声明 dsh.bundle.patch。只有声明了这个字段的包，才会变成真正生效的 profile 层（profile layer）。普通的 npm 依赖装进去是「装了但不激活」。这设计很讲理：你把十几个插件塞进一个 profile，它们像叠加补丁一样一层层盖在内核上，互不污染。

我第一次看到这个机制时有点懵，后来想通了：它本质是 Cordis 的插件树。每个插件是一个 apply(ctx, options) 函数，挂载时往 ctx 上注册服务、事件、命令；卸载时，所有通过 ctx.effect 登记的副作用自动回滚。装插件、卸插件、换整套 UI，都不用重启进程，系统跑着跑着就把自己的一部分换掉了。把论文里那句「时空可组合性」翻译成人话，就是：时间上能干净地撤销，空间上能声明我依赖谁、又提供给了谁。

下面这张图是外部插件的装载与生效路径：

1. dsh-at-file：在输入框里 @ 文件

原生 DSH 的输入框很素，你想让模型参考某个文件，得自己把路径或者内容塞进去。dsh-at-file 干的事很简单也很刚需：你在输入框打一个 @，它弹出一个搜索框，让你挑工作区里的文件，选中后把文件内容一起带进 prompt。

它挂的内核点是消息编辑器。实现上它会监听 composer 的输入事件，拦截 @ 触发一个文件选择器，再把选中的文件以附件形式喂给下一次请求。我装完之后的第一感觉是：终于不用满屏复制粘贴了。想让 Agent 照着 login.ts 的逻辑改支付页，直接 @login.ts 改，完事。

安装之后的效果如下：

2. dsh-genui：让模型的回复长出交互界面

这是我个人最欣赏的一个外部插件，仓库在 omdsh-dev/dsh-genui。原生 DSH 的模型输出全是 Markdown 纯文本，要看代码 diff、流程图、统计图表，靠文字排版效率很低。dsh-genui 让模型输出一种特殊的 dsh-ui 代码围栏，里面是 JSON 格式的界面描述，前端识别后渲染成可交互组件。

它支持三十多种组件：卡片、数据表格、各种图表、表单、标签页、文件树、时间线、代码 diff、mermaid 流程图，甚至 3D 场景和带滑块的函数动态绘图。更关键的是它实现了完整事件闭环：渲染出来的按钮、表单提交之后，会把 action 事件回传给 Agent，模型根据交互继续生成后续内容。这不是静态展示，是双向交互。

它的机制其实就一层 fence 解析加事件桥，我读了源码思路，核心是下面这个约定：

\`\`\`dsh-ui
{
  "type": "bar-chart",
  "data": [{ "label": "A", "value": 10 }, { "label": "B", "value": 20 }],
  "onAction": "chart_clicked"
}
\`\`\`

模型吐出这段围栏，前端渲染出柱状图；用户点了一下，前端发回 chart_clicked 事件，Agent 收到后接着往下推理。一个插件就把「纯文本对话」升级成了「带操作面板的对话」，安装之后的效果如下：

3. ModLens：给纯文本模型外挂一双眼睛

DeepSeek 的模型本身是纯文本的，看不了图。ModLens 是社区里最早的视觉插件之一，做法是：你往对话框粘一张图，它先调外部的视觉引擎，把图里的文字、布局、实体、语义信息整理成结构化证据，再交给 DeepSeek 继续推理。OCR 文本、页面布局、语义内容它都能抽出来。

它挂的是消息管线。注意它不是简单桥接一个视觉 API 就完事，而是把图像变成「模型能读的证据」，再拼回上下文。这补上了纯文本模型的硬短板。代价是它自己不带视觉能力，你还得给它配一个能看图的接口。已经在 GitHub 上面斩获了 2.6k 的 star。

4. dsh-agent-teams：在对话里拉起一支 Agent 团队

你说一句「用 AgentTeams 调研一下 XX」，当前会话里的 Agent 原地升职当队长，再拉几个子 Agent 进组，拆任务、设依赖、互相发消息。Web 界面右上角能实时看整个团队：谁在干活、谁空闲、谁摸鱼。

它挂的是 subagent 这个能力缝。DSH 内核本身提供 subagent 调度能力，这个插件是在上面做了编排层：任务拆分、依赖图、进度看板。对那种「一个 Agent 干不完、要分头调研再汇总」的活，这个插件把多 Agent 协作从「你自己手动开多个会话」变成了「一句话的事」。
安装后效果如下：

5. dsh-memory-evolve：让 Agent 跨会话记得住事

原生 DSH 每次开聊基本是失忆的。dsh-memory-evolve 给 Harness 补了一套跨会话长期记忆：项目约定、架构决策、踩过的坑、当前进度，它持续记下来，还能感知 Git 分支，后台做 Skill 演化。

举个例子，你今天跟它说「这个项目部署端口是 8080」，它写进项目记忆；过几天你新开一个会话，问部署配置，它还能接上，不用你从项目背景重新讲一遍。记忆太多也能归档，需要时再调出来。对于要长期跟的项目，这个插件把 AI 从「每次开聊都失忆」变成了「能长期跟项目的助手」。它挂的是会话生命周期缝，在 turn 之间读写一个持久化的记忆存储。

6. dsh-turn-rewind：把对话和文件退回某条消息之前

Agent 改崩了怎么办？dsh-turn-rewind 能让你把对话和文件恢复到某条消息之前的状态。它跟内核的会话事件流挂钩：因为 DSH 的会话日志是唯一事实源（这一点我在架构拆解里写过，所有「模型看到的」都能从 SessionEvent 流重建），所以这个插件能精确回放。

它比你自己手动回滚靠谱的地方在于：恢复前先预览有哪些文件要变，要你确认，还给你留一个救援点。也就是说它不是无脑覆盖，而是「先告诉你我要动哪些东西，你点头我再动」。对那种改完发现全错的时刻，这个插件能救命。
安装之后你就可以：

7. DSH-better-sidebar：把侧边栏改成迷你 IDE

这个插件把侧边栏疯狂增肥：文件管理、代码编辑、真实终端、Git 面板、后台任务、子 Agent，全塞进同一块侧边栏。装完之后侧边栏长成了一个迷你 IDE 工作台。

它最直接的价值是让你少切窗口。以前你可能在 Harness、VS Code、终端、Git 之间来回横跳，现在不少操作在侧边栏里就能完成：文件能看能改，终端是真 Shell，Git 能看 diff、暂存、提交。它还支持第三方注册新的 Tab 页，等于把侧边栏做成了一个可扩展的工作台框架，并且还可以支持多开，效果如下所示：

8. dsh-plan-execute：双模型规划与执行分离

这是一个工作流引擎类的插件，挂在 agent-loop 这个缝上。思路是：一个 planner 模型负责想（把任务拆成计划），一个 executor 模型负责干（按计划执行）。两个模型可以是不同的，比如让一个强的模型做规划，让一个便宜的模型做执行，成本和质量能分开优化。

我在读它实现时注意到，它本质上是在 DSH 的 agent loop 外面又包了一层路由：把一轮对话切成「规划阶段」和「执行阶段」，分别发给不同的 llm 提供者。这正好印证了 DSH 架构里那句话：模型没有特殊地位，它只是又一个插件。换模型跟换皮肤是同一层级的抽象。

9. dsh-llm-fallbacks：模型挂了自动切备用

这个插件直接坐在 llm 这个能力缝上，是理解 DSH「可替换内核」最好的例子。它做的事是：你给主模型配一串备用模型，主模型超时或者报错，它自动把请求转给下一个，直到有人能答。

它和官方 llm-deepseek 是同一层的东西，区别是它不提供某个具体模型，而是提供一个「路由层」。我读它思路时，把它简化成一个最小插件骨架，核心就是用 ctx.inject 把自己的 provider 挂到 ctx.llm 上：

import { Context } from 'cordis'

// 一个最简的 fallback 路由插件，呼应 Cordis 论文的「声明我提供什么」
export const name = 'dsh-llm-fallbacks'
export function apply(ctx: Context, options: { models: string[] }) {
  // ctx.inject 声明：我向 llm 这个缝提供了一个 provider
  ctx.inject('llm', {
    id: 'fallback-router',
    async chat(messages) {
      for (const model of options.models) {
        try {
          return await ctx.llm.call(model, messages) // 逐个试，失败就下一个
        } catch (e) {
          ctx.logger.warn(`model ${model} failed, try next`)
        }
      }
      throw new Error('all models failed')
    },
  })
  // ctx.effect 登记一个可逆副作用：启用时打个日志，卸载时自动清理
  ctx.effect(() => {
    ctx.logger.info('fallback router active')
    return () => ctx.logger.info('fallback router removed')
  })
}

这段代码是我自己写的缩略版，不是插件原文件，但结构跟社区实现一致：ctx.inject 是「空间上声明我提供给了谁」，ctx.effect 是「时间上登记一个能自动撤销的动作」。论文里那套时空可组合性，落到插件里就是这两个调用。

10. dsh-market：先把插件市场装上

最后一个我建议第一个装。dsh-market 是插件市场本体：搜索、安装、升级、卸载都能在设置里点完。装完它，很多其他插件在界面上点两下就装好了，不用再回去敲命令行。

它更像元插件（meta plugin），管的是插件生态本身。我在想 DSH 这个设计挺妙：连「管理插件的东西」都是个插件，不是内核写死的功能。你不喜欢这个市场，可以装另一个；市场本身也能被换掉。这又回到了那句 slogan：Everything is a Plugin，连管理插件的也是插件。

我自己写的最小外部插件

讲了这么些，我想确认一件事：社区插件跟官方插件，用的是不是同一套内核契约？答案是是的。为了验证，我照着 Cordis 的插件形状写了一个最小外部插件，它做的事是「计数这一轮对话调了几次工具」，纯用来印证机制：

import { Context, Service } from 'cordis'

// 声明一个服务，其他插件可以通过 ctx.toolCounter 拿到它
class ToolCounter extends Service {
  count = 0
  constructor(ctx: Context) {
    super(ctx, 'toolCounter', true)
  }
}

export const name = 'my-tool-counter'
export function apply(ctx: Context) {
  const svc = new ToolCounter(ctx)
  ctx.service('toolCounter', svc) // 注册服务

  // 监听内核的会话事件流：每次有工具调用，计数加一
  ctx.on('session/event', (ev) => {
    if (ev.type === 'tool/call') svc.count++
  })

  // 在系统提示里加一句，让模型知道当前工具调用数
  ctx.inject('systemPrompt', () => `已调用工具 ${svc.count} 次。`)
}

这个插件没干啥正事，但它证明了外部插件能做的三件核心事：往 ctx 上注册一个服务、监听内核事件流、往系统提示注入内容。官方包干的也是这三件。社区插件不是「二等公民」，它们跟官方核心站在同一个 ctx 上，只是挂的方向不同。

几点实在的提醒

我装了一圈外部插件，有些话得说在前面，免得你踩坑。

第一，生态虽大，质量参差。1000 多个仓库里，有认真做的，也有图一乐的（比如那个每次回复完自动补一句「谢谢你，鲸鱼大人」的 deepseek-manners，还有那个往界面塞 2005 年中文网站风格广告的 dsh-ads）。我上面列的 10 个是我读过实现、觉得靠谱的，但装任何社区插件前，自己点开仓库看一眼源码，比看 README 的宣传语有用。

第二，DSH 现在还是开发者预览版，会破坏性变更。插件今天能装，下个版本内核一改，它可能就挂了。挑插件时看它的更新时间，越新越可能适配当前版本。

第三，安全得自己负责。插件能注册命令、能读文件、能发网络请求。那种要你开一大堆权限的插件，装之前想清楚你信不信作者。

所以 DSH 本体就是个乐高底板，官方核心只是几块基础砖。真正的花样全在 GitHub 那 1000 多个社区仓库里：有人给它装浏览器、长期记忆、数据库，有人嫌它不会看图就接个视觉模型，还有人往里塞电子宠物和 18 款小游戏。这篇挑的 10 个，是我觉得程序员日常最能直接提效的那批。空壳不可怕，可怕的是你不知道往里塞什么。现在你知道了。