DeepSeek Harness 架构是怎样的？DSH plugin 插件树、dsh-base 共享层与运行方式

运行中的 DeepSeek Harness 就是一棵插件树：dsh 启动器读取 profile，把一层层 DSH plugin 叠装起来，dsh-base 是 web、headless、sdk、acp 共享的第一层（来源）。 它不是把功能写死在核心里，而是让每个能力都成为树上可替换、可组合的一层——理解这棵树，是理解「装插件到底装了什么」「换个 profile 为什么像换了个软件」的前提。这篇只讲这棵树怎么搭、怎么叠、怎么读；DSH 本身是什么见《DeepSeek Harness 是什么》，单个插件内部四件套见《一个 dsh plugin 里有什么》。

DeepSeek Harness 为什么是一棵插件树

DeepSeek Harness 的插件树指的是运行中的 dsh 由一层层 DSH plugin 叠加而成——连模型适配、工具、会话、agent loop 这些主干能力，本身也是插件（来源）。 把「单体内核」和「插件树」摆在一起对比，差异立刻清楚：

1. 单体内核会越改越重：如果模型接入、工具分派、会话管理都写死在一个内核里，想换模型提供方或换一套工具，就得动内核代码，牵一发动全身；分支越拉越多，版本也难收敛。
2. 插件树把变化推到边界：设计成树之后，每项能力被切成一到多个 DSH plugin，换能力就是换掉或叠加某一层，内核本身保持稳定。
3. 启动器只做组装：dsh 自身不实现具体能力，它读取配置、把 profile 指定的各层依序挂上去、然后转发命令；真正的活儿由各层承担。
4. 树是运行时的、可变的：同一个内核在不同 profile 里会叠出不同的树，因此「同一份 dsh」既像图形软件，也能像命令行工具。

一句话：DeepSeek Harness 的「一切皆插件」不是口号，而是这棵树的真实结构——你在界面上看到的每个功能，背后都对应树上的某一层 DSH plugin。 想先建立整体印象，见《装插件前先懂的 5 个概念》。

层是怎么叠起来的：dsh-base 与四种运行方式

树的公共地基是 dsh-base——它被 web、headless、sdk、acp 共同复用，四种运行方式都从这一层起步，再往上叠各自特有的层（来源）。 理解叠装结构，抓四个要点：

1. 公共地基只有一份：无论你用图形界面（web）、无界面脚本（headless）、还是把它嵌进程序（sdk / acp），底层的公共能力都来自同一份 dsh-base。它一变，所有运行方式一起受益或一起受影响。
2. 差异只在上层：各运行方式的区别不在底层，而在 dsh-base 之上额外叠了哪些层。比如与 Web GUI 相关的层只在 web 这棵树里出现，无界面运行根本不会加载它们。
3. 层可以是一组插件：别把「一层」理解成单个包——有时一层由若干协作的 DSH plugin 共同构成，它们一起提供某项完整能力。
4. 越往上越贴近场景：底层是通用地基，越往上越贴近具体运行方式与用户场景，这也是为什么后装的插件通常叠在比较高的位置。

由此得到一条实用的排查经验：一个问题只影响某一种运行方式时，多半出在 dsh-base 之上的特有层，而不是公共地基。

谁决定装哪些层：profile 与组合包的分工

profile 管「装哪些层」，组合包管「这一层怎么配、怎么挂」：profile 是一份具名组装（存于 Harness home，内含 cordis.patch.yml），组合包是「Cordis 配置项 + 挂载代码」的分发格式，用 package.json 的 dsh.bundle 声明（来源）。 叠装过程可以拆成三步来看：

1. profile 决定清单：启动时先确定用哪份 profile，它列出要装载的条目以及各自的覆盖配置；换 profile 等于换一份清单，也就换了一棵树。
2. cordis.patch.yml 负责覆盖：它不重新定义插件，只对已声明的条目做补丁与调参——所以想改某个 profile 的行为，通常改这个文件就够，不必去动任何一个 DSH plugin 的源码。
3. 组合包提供可复用的层：声明了 dsh.bundle 的包，被安装时会追加进 profile 的 bundle 清单，以整层的身份参与启动；能力来自插件，层的组织来自组合包，两者分工不同。
4. 「装插件」本质是加一层：往某个 profile 装上一个社区插件，就是在树上加一层。在「设置 → 插件市场」即 DSH Plugin Hub 里可以浏览这些可加的层，装前先想清楚它落在哪、会不会和已有层抢同一个核心包。

profile 与组合包这两个概念各自是什么、彼此什么关系，详见《DeepSeek Harness profile 是什么》。

怎么读一棵运行中的插件树

插件树不只是一张结构图，它可以在真实运行时被观察——知道怎么看，你就能把「某个功能从哪来」「某个改动影响谁」定位到具体的一层。 几个可操作的动作：

1. 先记住当前 profile 名：你用的是 web 还是 headless，决定了这棵树的上层长什么样；跨运行方式的问题先从这里排除。
2. 用 dump 看逐层配置：dsh --profile web --dump-config 会把各层依次列出，出现 # == <包名> 那样的分节，才算对应层真的生效；这是确认「插件挂上没有」最直接的办法。
3. 把功能对应回层：界面上某个按钮、某个工具、某段提示词，都可以顺藤摸瓜找到它由哪一层提供，从而判断改动或卸载会不会波及别处。
4. 把问题对应回层：只有某种运行方式出错，看上层；所有运行方式都出错，看共享的 dsh-base 层。
5. 把新增对应回层：装新插件前先看它加的是能力层还是组合层，预判它对提示词、工具列表和启动时间的影响。

读懂插件树的注意事项

插件树是理解 DeepSeek Harness 的整体坐标，不是要你背下来的结构图。

1. 树是分层叠加的：底层是共享的 dsh-base，越往上越贴近具体运行方式与场景。
2. 一层可以是一组插件：别把「一层」理解成单个包，有时一层由若干协作的 DSH plugin 共同构成。
3. 换层比改内核安全：想换模型接入或工具分派，优先换对应层，而不是动内核。
4. 装插件 = 加层：安装新插件前先想清楚它落在哪一层、会不会和已有层抢同一个核心包。
5. 排查先定位层：问题只影响某一种运行方式时，多半在 dsh-base 之上的特有层，而非公共地基。
6. 确认插件真的挂上了用 --dump-config：看到对应分节才算配置层生效，别只看安装命令返回成功。
7. 概念之间的关系：想先建立整体印象，见《装插件前先懂的 5 个概念》。

来源：DeepSeek Harness 官方文档 - 架构总览、官方文档 - 核心子系统。