DeepSeek Harness 插件生态全景：DSH plugin 架构、扩展点索引与社区分布

DeepSeek Harness 的插件生态可以看成一张三层地图：内核之上是官方内置组合包，再往上是数量最多的社区 DSH plugin。 内核只提供插件运行时与最基础的接缝，官方用组合包把「网页版」与「无界面版」两种骨架搭好，其余能力扩展几乎全交给社区。本文不逐个解剖插件、也不重复讲基础概念，只回答三个问题：生态由什么构成、扩展点落在哪些位置、社区插件覆盖哪些领域与来源构成。（来源）

DeepSeek Harness 插件生态由什么构成：内核、官方插件与社区插件三层

DeepSeek Harness 插件生态自下而上分三层，内核与插件运行时在最底、官方内置组合包居中、官方与社区发布的各类 DSH plugin 在最上（来源）。 三层的构成与角色，本节接下来逐一展开；其中官方内置组合包的清单与各 profile 模板的分工，详见《DeepSeek Harness profile 与组合包》。讲完三层之后，本文重点补两处增量：扩展点究竟落在运行时的哪些位置、社区插件覆盖哪些领域并如何分布。

先看最底层。内核与插件运行时是整棵树的根，它本身不提供业务能力，只暴露一组「接缝」（seam）供插件接入——工具、命令、钩子、UI 卡片、服务与提供方五类。接缝的注册走 Cordis 的 effect 作用域：插件加载时注册的东西，会在它被卸载时被一并撤销，所以「装或卸」不是往配置里加一行字，而是实打实地挂上与摘掉一棵子树。这也解释了为什么同一个内核装不同插件会像换了个软件：换的是接缝上挂着的那批实现。

再看中间层。官方内置组合包把「网页版」与「无界面版」两种骨架打包分发，它们不是普通插件，而是 bundle——「Cordis 配置项 + 挂载代码」的分发格式，靠 package.json 里的 dsh.bundle 字段声明身份，装进 profile 后以整层方式参与启动。随发行版常见的 profile 模板有 web、headless、sdk、sdk-minimal，另有 acp：web 带图形界面，headless 去界面适合脚本，sdk 与 sdk-minimal 供程序嵌入，acp 面向协议接入。它们决定了「一棵树长什么形状」，但不决定「树上挂多少果子」。

最上层才是社区插件层。绝大多数功能扩展都是社区作品，托管在 npm 与 GitHub，用 dsh-plugin topic 统一标记。社区插件既可能是只注册一个工具的小包，也可能是同时注册工具、命令、UI 卡片与服务提供方的整套增强；数量、覆盖面与迭代速度都远超官方自带的那几层。把三层摆到一张表里对照，边界一眼就清楚：

要提醒一句边界：三层是「角色的划分」，不是「三份互不相干的名单」。同一个插件，从「谁维护」看是社区作品，从「以什么格式分发」看可能是 bundle，从「挂在哪里」看又落在某个 profile 的接缝上。所以判断一个插件在生态里的位置，要分别问清这三件事，而不是拿一个标签套全部。

DSH plugin 的扩展点索引：工具、命令、钩子与 UI 卡片各落在哪

DSH plugin 的扩展点主要有五类：工具、命令、钩子、UI 卡片，以及服务与提供方接缝，每一类都对应一个固定的注册位置（来源）。 把它们排成一张落点索引表：

一个插件很少只占一类：多数插件会同时注册若干类扩展点，能力面越宽、注册的落点越多。 比如一个上下文可视化插件，可能同时注册工具（拉取上下文）、UI 卡片（设置页开关）与服务提供方（替换上下文来源）三类，各管一段。

把五类拆开看，各自的作用与代价并不一样：

1. 工具（tool）：通过 ctx.tools.register(defineTool(...)) 注册，注册后出现在对话里模型可调用的工具清单，是五类里影响面最大的一类——它直接决定模型能读写什么。工具给得越宽，能力越强，出错面也越大。
2. 命令（command）：注册成终端或对话里的 /命令，是给用户用的快捷入口。命令是「人来触发」，工具是「模型来触发」，两者面向的发起方不同。
3. 钩子（hook）：挂在事件与守卫接缝上，决定插件能在什么时机介入——执行前拦截、追加一次审批、或改写行为，都属于钩子。
4. UI 卡片（settings card）：落在设置页「Plugins」区的槽位与命名空间里，决定插件在界面上有没有开关、表单或面板，让能力可被看见、可被配置。
5. 服务与提供方：走按名注册表与 ctx.get，用于替换模型路由、子代理、技能这类子系统实现，是五类里最「深」的一类，改的是整棵树的某个内部件。

用起来要记一条：扩展点不是随便挂的——每个落点都得先在 inject 里声明依赖，运行时才保证对应服务已经就绪。 所以一个插件的能力面，等于它在这五类里各注册了什么。按下面的顺序看，最容易看清一个 DeepSeek插件 的分量：

1. 先看工具：工具决定模型能做什么、会读写哪些资源，是五类里影响面最大的一类。
2. 再看命令与钩子：命令是给用户用的快捷入口，钩子决定它能在什么时机介入、能不能拦下操作或追加一次审批。
3. 最后看 UI 卡片与服务：UI 卡片决定它在设置页有没有开关，服务提供方决定它能不能替换模型、子代理这类子系统实现。

想在本地把「这个插件到底挂了哪些落点」核出来，可以按下面几步走，每一步都有明确的预期结果：

1. 看它是不是一层：执行 grep -A3 '"dsh"' "$DSH_HOME/profiles/web/package.json"。预期：声明了 dsh.bundle 的包说明它把自己当成整层挂载，否则只是普通依赖。
2. 看它是否进了加载清单：执行 dsh plugin --profile web list | grep -n "<包名>"。预期：有输出说明这个包已经装进该 profile，没输出就是没装到这里。
3. 看它在树里有没有那一层：执行 dsh --profile web --dump-config | grep -n "# =="。预期：出现 # == <包名> 那一行，才说明它在这个 profile 里真的会被加载；只在 list 里出现、dump-config 却没这一层，说明装的是没声明 dsh.bundle 的普通依赖。
4. 看 UI 落点：打开设置页的「Plugins」区。预期：注册了 UI 卡片的插件在这里能看到开关或面板；只注册工具/命令的插件在这里没有卡片。

一句话：读扩展点就是读「它从哪几个口子接进运行时」——口子越深，装之前越要看清来源。想按通用信号评估一个插件值不值得装，见《dsh plugin 值不值得装的信号》。

社区插件的分布与规模：覆盖哪些功能领域、来源构成如何

社区插件层是整棵树上数量最多、迭代最快的一层，它的「分布」可以从两个维度看：覆盖哪些功能领域，以及来源由谁构成（来源）。 本章只谈生态地图上的覆盖面与来源构成，不重复讲具体的上架流程。

先看功能覆盖面。社区插件几乎铺满了内核暴露的每一类接缝：

1. 界面与交互类：注册 UI 卡片与设置面板，改的是设置页长什么样、有哪些可点的开关。
2. 会话与上下文类：注册工具与钩子，介入模型看到什么、能调用什么，例如上下文可视化、压缩与检索。
3. 记忆与知识类：注册服务与提供方，替换或补充记忆、检索这类子系统实现。
4. 工具与集成类：注册工具，把外部命令、API、MCP 服务器接进对话。
5. 智能体与编排类：注册服务提供方与钩子，替换子代理、拆解团队协作。

再看来源构成。从「谁维护」看，社区插件由个人与组织发布；从「以什么格式分发」看，有的是普通 npm 包、有的声明 dsh.bundle 以整层挂载；从「发布在哪」看，主要是 npm 与 GitHub 两条路。 同一个插件在这三个维度上的归属可能互不相同，这正对应了「三层是角色划分、而非三份名单」那个判断。把覆盖面与来源摆成一张表：

要判断某个领域现在有多热闹、有多少现成实现，可以按分类在 DSH Plugin Hub 里数条目；至于「怎么参与、怎么把一个插件提交上去」，属于社区插件本身的话题，本篇只用一句内链带过：见《DeepSeek Harness 社区插件怎么找》。

一句话：读生态地图的「分布」，读的是「哪些领域被覆盖、由谁在维护」，而不是某一条具体的上架流程。

DSH plugin 生态全景的常见误区

把这张地图当说明书，最容易踩下面几个坑。 逐条纠正：

1. 「装插件 = 装到整台机器」——不是装到整台机器，而是装在 profile 上：$DSH_HOME/profiles/<名字>/ 各有自己的 package.json 与 node_modules，装到 web 不会自动出现在 desktop，要逐个 profile 各装一遍。
2. 「装上就自动生效」——不是装上就生效，而是装完要重启该 profile 的进程并刷新页面；只在 list 里出现、dump-config 里没有那一层，说明它还是普通依赖、未作为层加载。
3. 「扩展点多 = 更强大更安全」——不是更强大更安全，而是多注册一个工具或钩子就多一条模型可能走错、插件可能介入的路径，能力面与风险面一起变宽。
4. 「在市场上 = 官方背书」——不是在市场上就等于官方背书，而是绝大多数插件由社区维护，市场只做归类与兼容性核实。
5. 「dsh-plugin topic 只是随手打的标签」——不是随手打的标签，而是市场抓取的依据：认准这个 topic，等于确认它是按 DSH plugin 规范发布、会被市场自动收进的仓库。
6. 「组合包和插件是一回事」——不是一回事，而是不同层次：组合包是分发格式（dsh.bundle），插件是能力实现，一个组合包里可以组织多个插件。

注意事项与局限

生态全景是一张坐标系，不是一份承诺——记住下面几条边界，才不会把地图当成说明书。 逐条说明：

1. DeepSeek Harness 仍在开发者预览期：破坏性变更比较频繁，本文的索引是当前版本的快照，地图上的分类与扩展点都可能随版本调整，装之前以插件页标注的兼容版本为准。
2. 来源与权限要单独核：插件与宿主同进程运行、拥有本机权限，扩展点的落点清楚，不代表来源可信，装前仍要审来源与权限。
3. 核对落点要能读本地 profile：本篇的核对步骤依赖读取 $DSH_HOME/profiles/... 并执行 dsh --dump-config，换了机器或 profile 名字，结果要重新核。
4. 市场收录有滞后：市场是整理层，新发布的仓库未必第一时间被收录，找不到时可以直接用 GitHub 或 npm 地址安装。
5. 地图不能替代解剖：本篇给的是位置索引，想判断一个插件到底动你的什么，仍要回到它的能力、设置、权限与依赖四件去看。

与其在 GitHub 的 topic 列表和一串仓库之间来回翻找，不如先用社区官方的 DSH Plugin Hub（dsh-plugin.org/zh）把整个生态在应用内一眼看全，再按分类一键装上想试的插件。

来源：DeepSeek Harness 官方文档 - 架构总览、dsh CLI README、dshplugin/dsh-plugin-hub。