DSH插件市场现状:四个值得细看的插件案例(下)

上一篇聊了DSH插件化Harness本身的技术逻辑。这一篇往外走一步，看看这套架构催生出的插件市场目前是什么状态，再挑几个和Workspace、路由都相关的项目细看一下。

DSH是8月13日开源的，增长速度很快。开源12小时内Star数冲到5万左右，28小时后到了9万多，四天后主仓库Star数到了14.4万，Fork数1.4万多。社区自发聚合的插件商店项目里，收录的插件已经超过1080个，累计Star超过4.2万，分成13个大类，从Agent、可视化理解，到搜索数据工具、桌面启动器、主题皮肤都有。

在这个基础上，几个方向的插件密度明显更高。

记忆和上下文管理是最密集的方向之一。DSH原生有会话持久化，但跨会话记住什么、按项目怎么召回、注入预算怎么控制、什么时候自动提炼，这些还是开放问题，于是出现了大量做记忆层的插件，本地文件型的、SQLite的、自动摘要的、记忆进化的都有。它们解决的是长程任务里上下文连续的问题，落点比单纯保存聊天记录要深一层。

成熟产品开始主动兼容DSH，路径大致有三种：把已有能力包装成DSH Skill；通过MCP、CLI或HTTP API让DSH调用；把DSH本身作为产品内部可以直接启动的Agent Runtime。还有一类是跨生态兼容层，比如pi2dsh这个项目，把另一套Agent框架Pi的插件通过DSH原生的Cordis服务和Provider机制接进来，靠的是一层通用的Host ABI，每个包不用重写，也不需要额外的转换步骤。

本地优先和数据主权仍然是重要卖点。不少插件强调状态只存本地Workspace，不上传Provider凭据，不增加遥测，不经过额外云端代理，用本地SQLite或文件系统，模型Provider由用户自己选，Artifact直接落在真实项目目录里。这类插件比较适合企业内部代码、未发布产品、NDA项目和需要完整审计的研发任务。多进程并发、状态目录保护、跨设备同步这些问题，则要靠后续插件继续补上。

版本兼容和插件治理是当前最大的风险点。DSH自己在README里用大写字母写明会有兼容性破坏性变更，这个警告分量不轻。官方兼容列表显示，41个第三方集成标记为兼容，219个被标记为需要注意；有开发者做过实测，尝试的几个第三方工具全部失败。社区分析指出，受影响最大的几类插件包括依赖已经废弃的APIProxy的插件、依赖前端DOM结构的Web插件、写自定义SessionEvent类型的插件，以及直接引用内部实现细节的插件。有插件因为引用了一个内部符号，框架变更后加载直接崩溃；还有插件因为写入了自定义会话事件，升级后被更严格的读取校验拒绝，导致历史会话没法正常恢复。开源社区里也有资深开发者公开表示，这套插件设计让他们想重新审视自己过去在类似产品上的一些技术选择，评价整体偏正面，但同样提醒这还是预览阶段。较成熟的插件已经开始主动固定Tag或Commit、声明兼容版本、加安装前检查和数据迁移、支持失败回滚。DSH插件市场接下来要解决的，可能不只是功能数量，还有插件发现、审核、版本兼容和安全治理这一整套机制。

专门做路由的独立插件目前还比较少，路由更多是作为一种横向能力，被包含在Agent Team、Workflow、模型管理这类更大的插件里面。这一点正好是下面几个案例要展开的地方。

dsh-agent-team-gui：把团队做成可复用的产品对象

项目地址：toolclub/dsh-agent-team-gui

这个项目的思路，是把规划、开发、测试、安全评审这类角色，提前定义成可以保存、复用、版本管理的团队产品，每个成员单独配置主模型、Fallback模型、最大输出Token和工具的允许拒绝策略。团队执行时，一个不带工具、Token受限的Planner先生成结构化任务分配和依赖图，校验完成、确认无环之后，Ready节点按最大并发数分批执行，下游拿到有长度上限的结构化Handoff，可选的Reviewer检查质量，不通过就转给指定的Repair Owner返修，最多两轮后由Lead汇总。每次执行在规划开始前就会持久化，Run Center提供前台后台状态、当前阶段、完整输出、停止重试和Token使用情况。

这个项目对Workspace最直接的一条借鉴，是路由的范围应该覆盖是否启用团队、选哪些成员、失败之后转向哪里，而不只是选模型这一个动作。它相当于把"路由"从单点决策，扩展成了团队执行链路里的一整套决策点。

DSH Workflow：把一次性多Agent调度做成长期流程资产

项目地址：omdsh-dev/dsh_workflow

DSH原生的workflow工具适合一次性并行执行，这个项目在上面加了一层更完整的流程产品能力：命名和发现、自动生成、保存复用、暂停恢复、重跑续跑、持久证据、成本和Token记录、权限审批。项目采用官方Bundle形态，复用Cordis、子Agent、Session、Jobs、审批这些既有机制，不改DSH核心。它用版本化的Capsule表达一个流程，里面带着Manifest、Source、Intent、Inputs这些说明，让流程携带"它解决什么问题、需要什么能力、从哪里生成"这层信息，而不只是一段脚本。每次运行有稳定的Run ID和明确状态机，running可以转paused、completed、failed、denied或stopped，用户可以按原运行快照重跑，也可以按当前保存版本重跑，还可以只续跑未完成的部分。模型生成的流程运行在受限的QuickJS/WASM环境里，能接触到的只有经过校验的Workflow API，这层API再代为调用Agent和宿主能力，文件系统、进程和网络都不会直接暴露给它。

这套设计对做"AI for Process"方向的团队会比较有参考价值：流程被当成资产来管理，有版本、有运行记录、也有恢复机制。

dragonbaba/dsh-routing-suite：轻量的工作风格路由

项目地址：dragonbaba/dsh-routing-suite

当前版本0.1.2，是一个很克制的实现。它保留官方Standard预设的Persona、上下文和完整工具集，只根据会话里第一条正式任务，在Automatic、Inspect First、Direct Execution三种工作风格里选一种，选定之后整个会话保持稳定，不会每一轮重新判断。它的实现方式很轻：所有效果都通过系统提示词里的一段工作方式指导来实现，不牵扯模型调用、文件系统或网络层面的改动。路由粒度停留在工作方式这一层，模型选择和成员分工都还没纳入，首任务定完风格之后，如果任务性质中途变化，适应能力有限。

yjh051108/dsh-routing-suite：更工程化的推理模式路由

项目地址：yjh051108/dsh-routing-suite

这个项目由运行时注入器和路由预设两部分组成。注入器提供热重载、卸载、路由自愈这些开发工具；预设部分把任务行为分成偏规划分析的spec、偏直接执行的react、容易冲突的mixed和证据不足交给模型自判的weak，还针对不同DeepSeek模型给不同的引导方式。它重点处理了两个问题：一是首轮路由如何保证真的生效，做法是在提示词装配前，通过生命周期事件抓取第一条正式用户任务，避免因为没拿到任务内容而默认落入弱路由；二是路由提示在长上下文里容易被稀释，做法是让简短引导跟着每一轮用户消息重复出现，覆盖整个会话周期。项目还做了一批P1到P23的实验，测分类区分度、路由准确率、任务完成率、指令稀释和不同模型的Persona差异，这套实验方法已经具备路由工程的样子了。

把这两个路由插件放在一起看，能看出路由决策在DSH里目前主要落在哪几层：决策时机上，一个是首任务定一次就不再变，一个是每轮都补一次引导；路由对象上，一个选的是工作风格，一个选的是推理姿态加模型引导方式；实现方式上，一个只改系统提示词的一段内容，一个动用了运行时注入这类更深的机制。两者都还没覆盖到Provider级别的模型路由，也没有做成员或子Agent路由。这说明目前这块能力主要停留在提示词层面的软约束，真正硬性的执行路由，还是被并进了Agent Team和Workflow这类更大的项目里。

这两篇一起大概说清楚了DSH插件化Harness的技术逻辑，以及围绕它长出来的插件市场目前的样子：记忆管理最密集，成熟产品在主动接入，本地优先仍是卖点，版本兼容是最大风险，路由目前更多是嵌在大项目里的一种能力，还没长成独立的一类插件。