关于DeepSeek Harness插件生态分层模型 Plugin Layering Model简称(PLM)

[szx-a]

author: @szx-a

关于DeepSeek Harness插件生态分层模型的一个初步探讨（简称 PLM）

Plugin Layering Model (PLM) —— 本文尝试提出一种插件分层模型，旨在为 Harness 插件生态提供一个结构化的认知架构，以促进插件之间的协作与生态的有序发展。

一、背景与动机

DeepSeek Harness 基于 Cordis 框架，采用 “一切皆插件” 的架构。产品的每一部分都是插件，包括模型适配器、工具注册表、会话日志，以及 agent loop 本身。不存在需要打补丁的特权内核——扩展 dsh 的方式就是把插件挂载到其他插件旁边。

然而，随着插件数量激增（社区插件市场已收录较多插件），当前生态面临一个结构性问题：所有插件在概念层面被平等对待，缺乏对其“角色”的区分。这导致：

1. 用户难以判断插件的定位：一个插件是提供“基础能力”还是“具体功能”？用户安装时缺乏清晰的预期。
2. 插件之间缺乏协作规范：当多个插件需要协同工作时，没有明确的“谁依赖谁”的架构指引。
3. 生态发展方向模糊：社区难以形成对“基础设施类插件”和“应用类插件”的共识。

二、核心构想：插件分层模型

本文尝试为 DeepSeek Harness 插件生态建立一个两层分类模型，作为讨论的基础：

第一层：地基插件（Foundation Plugin）可简称(FP)

初步定义(欢迎补充合理修改)：可以不直接提供面向用户的“功能”，可以有类似gui的管理协作功能，是定义规则、接口、协议、容器或挂载机制，为其他插件提供运行平台或协作框架的插件。

特征：

• 提供可被其他插件消费的 Service Definition（服务定义）可以提供相关功能的基础服务
• 定义某种“抽象概念”及其操作协议
• 本身可以被启用/停用，停用后依赖它的上层插件将无法工作或直接作用于 dsh这一超级大地基上，地基插件本身是提供一个多能力的协作 更宏观的操作定义 挂载与管理。
• 通常生命周期较长，变更影响面较大

现有案例：

• dsh-base：每个 profile 的第一层，提供模型适配器、工具、持久化、沙箱与审批策略等
• dsh-market / 插件市场插件：本身是一个插件，但提供的是“浏览、搜索、一键安装其他插件”的平台能力
• dsh-thread：提供会话记忆层的基础设施
• LMA (Layered Memory Architecture)：定义“记忆体”抽象及挂载方式协议，(目前还在完善和开发)有需要的话可为记忆类插件提供统一容器

第二层：能力性插件（Capability Plugin)简称(CP)

初步定义(欢迎补充合理修改)：在地基插件提供的框架之上，实现具体功能的插件。它们面向最终用户，直接解决特定问题。

特征：

• 消费地基插件提供的服务
• 提供用户可见的、可直接使用的功能（工具、命令、UI 组件等）
• 可以被替换、升级或停用，不影响其他能力性插件
• 多个能力性插件可以挂载在同一个地基插件之上

现有案例：

• dsh-memory-evolve：在记忆基础设施之上提供进化式记忆管理
• dsh-persona-memory：在记忆基础设施之上提供人格记忆
• EchoCore：在记忆基础设施之上提供综合记忆方案

层级关系图

┌─────────────────────────────────────────────────┐
│ 能力性插件（应用层） │
│ dsh-memory-evolve / dsh-persona-memory / │
│ EchoCore / 具体工具插件 / UI 插件 │
├─────────────────────────────────────────────────┤
│ 地基插件（基础设施层） │
│ dsh-market / LMA / dsh-thread / dsh-base │
│ （提供协议、容器、挂载机制、基础能力，可以有gui式管理） │
├─────────────────────────────────────────────────┤
│ 超级地基：DeepSeek Harness │
│ Cordis + ctx + 插件系统 + 生命周期 │
└─────────────────────────────────────────────────┘

三、案例：LMA（Layered Memory Architecture）作为地基插件

以我开发的 LMA 记忆体分层插件(部分功能还在测试完善，对于接口的实现处于构想阶段，但不影响PLM这一架构概念阐述)为例，说明这一分层模型的实际应用：

LMA 的地基插件角色

• 定义了“记忆体（Memory Body）”这一抽象概念
• 提供了记忆体的创建、挂载、卸载协议（/mount、/unmount 等命令）
• 为其他记忆类插件提供了统一的“容器”和“挂载点”
• 其他记忆插件（如 dsh-memory-evolve、EchoCore）可以挂载在 LMA 之上

LMA 的能力性插件角色（可选）

• LMA 本身也内置了一套可开关的记忆流程（提取/存储/召回）
• 当用户没有安装其他记忆插件时，LMA 可直接作为能力性插件使用
• 当用户安装了其他记忆插件时，可以关闭 LMA 的内置流程，仅保留其地基功能

设计原则

LMA 作为基础设施 = 始终提供；LMA 作为记忆方案 = 可选提供

这一设计使得 LMA 既是“地基”（为其他记忆插件提供载体），又是“能力”（自带可用的记忆服务），用户可以根据需求自由选择。

四、这一模型可能带来的好处

1. 为用户提供清晰的安装决策依据

用户在选择插件时，可以快速判断：

• “我需要一个地基插件来建立某种能力框架”
• “我需要一个能力性插件来解决具体问题”

2. 为插件开发者提供架构指引

开发者可以明确自己的插件定位：

• 如果设计的是“协议/容器/框架”，应作为地基插件，重点设计服务接口
• 如果设计的是“具体功能”，应作为能力性插件，重点消费已有服务

3. 促进插件之间的协作与组合

地基插件定义了标准接口，能力性插件可以“即插即用”：

• 多个能力性插件可以共享同一个地基
• 用户可以自由组合不同的能力性插件，而不必担心底层冲突

4. 与 Harness 现有架构自然对齐

Harness 本身就是“超级地基插件”——Cordis 是底层框架，插件向共享上下文贡献服务。这一分层模型是“一切皆插件”理念在生态层面的自然延伸。

五、讨论与建议(真挚的邀请)

1. 术语普及：是否可以在社区文档中引入“地基插件 / 能力性插件”的分类术语？例如在相关文档中增加此分类说明。

2. 插件市场标签：是否可以在插件市场（如 dsh-market）增加“Foundation Plugin”和“Capability Plugin”的筛选标签，方便用户识别？

3. 服务接口规范：是否鼓励地基插件作者明确定义其提供的服务接口，方便能力性插件消费？

4. 最佳实践积累：是否可以为开发者提供“如何设计地基插件”和“如何设计能力性插件”的指南？

以上仅为初步想法，欢迎社区讨论和补充。

六、总结

DeepSeek Harness 的“一切皆插件”理念已经提供了技术层面的无限可能性。本文提出的插件分层模型（PLM），是在此基础上为生态建立结构化的分类认知——让插件不仅“都能跑”，而且“各安其位、各司其职”。更好的发挥多插件功能。

这一模型不是对现有架构的修改，而是对现有插件生态的认知框架补充。它不改变任何代码，但可能改变我们理解和使用插件的方式。

---

提案人：@szx-a
相关项目：LMA - Layered Memory Architecture目前处于测试完善阶段。

📌 讨论与反馈

欢迎在以下渠道参与讨论：

• GitHub Discussions：deepseek-ai/deepseek-harness/discussions
• LMA 项目仓库：szx-a/ds