DeepSeek Harness 插件生态的 6 个方向：从 Tools 到 Workflow

最近整理了一批 DeepSeek Harness 插件。

真正把插件集中起来以后，我发现 DSH 的插件并不只是“多几个 Tool”，而是在逐渐覆盖一个 Agent 系统的不同层次。

目前我整理到的相关插件已经超过 2500 个。

如果按照实际解决的问题来看，我觉得其中最值得关注的可以先分成 6 个方向。

1. Tools：扩展 Agent 能做什么

Tools 是最基础的一层。

它解决的是：

Agent 能不能调用某种外部能力？

例如：

• 文件处理

• 搜索

• Shell

• 浏览器操作

• API 请求

• Git

• 数据处理

这是最容易理解的一类插件。

当 Harness 缺少某个具体能力时，通常先找 Tool 就够了。

但这类插件同时也是权限问题比较集中的地方。

比如插件拥有 Shell 和 Filesystem 能力以后，它能够完成更多任务，也意味着安装之前更应该确认源码、依赖和权限范围。

2. UI：改变人和 Agent 怎么交互

第二类是 UI。

这类插件不会直接提高模型能力，却可能大幅改变日常体验。

比较常见的是：

• Terminal UI

• Sidebar

• 文件树

• Git 面板

• Task 状态

• Subagent 管理

• Streaming 状态展示

一些插件加入这些能力之后，Harness 的形态会逐渐从：

CLI 聊天工具

变成：

一个带 Agent 的轻量开发环境。

对于长期使用 Coding Agent 的人来说，这种体验层的改变其实很明显。

3. Memory：解决跨 Session 上下文

一次性的代码任务对 Memory 要求不高。

但如果 Agent 长期参与同一个项目，很快就会出现：

为什么每次都要重新解释项目？

需要重复告诉它：

• 项目架构

• 编码规范

• 历史决策

• 常用命令

• 已知问题

• 用户偏好

Memory 插件主要解决的就是这些内容如何保存和重新召回。

常见思路包括：

会话内容
↓
提取值得长期保存的信息
↓
持久化
↓
后续任务检索
↓
重新注入上下文

这已经不仅是模型上下文窗口的问题，而是 Agent 状态管理的问题。

4. Vision：补充文本 Agent 的输入能力

开发过程中经常会遇到：

• UI 截图

• 报错截图

• 设计稿

• 图表

• OCR

如果 Harness 当前的工作流主要围绕文本，一类常见插件思路就是：

图片
↓
OCR / Layout / Vision Analysis
↓
结构化信息
↓
Agent

这样不一定需要改变整个 Agent 架构，也能给已有工作流增加图片输入能力。

从插件设计角度看，这类项目很能体现 Harness 的扩展方式：

模型本身不一定改变，但 Agent 的能力边界可以通过外部组件继续扩展。

5. Skills：把工具组织成方法

Tools 解决：

能不能做。

Skills 更接近：

应该怎么做。

例如 Code Review，不是简单提供一个“读取代码”的 Tool。

一个 Skill 可能会定义：

1. 读取改动；

2. 判断影响范围；

3. 检查潜在错误；

4. 检查测试；

5. 输出结构化 Review。

Debug、测试、项目初始化、文档生成也类似。

所以我觉得 Skills 是 Agent 插件体系里一个很关键的层次。

随着基础 Tool 越来越丰富，真正决定 Agent 工作稳定性的会逐渐变成：

能不能把这些 Tool 组织成可靠流程。

6. Workflow：从辅助工具走向自动执行

再往上一层就是 Workflow。

这里解决的是：

如何让 Agent 自己连续完成多个步骤？

例如：

• Hook

• 多步骤任务

• 自动化执行

• Agent 编排

• 多 Agent 协作

• 状态管理

这时候用户不再需要一步一步告诉 Agent：

先做 A，再做 B，再检查 C。

而是把整个目标交出去，由 Workflow 管理执行过程。

从这个角度看，可以把插件生态粗略理解成：

Tools
↓
UI / Memory / Vision
↓
Skills
↓
Workflow

底层扩展能力，上层逐渐组织成完整工作方式。

插件越来越多之后，检索也开始成为问题

整理过程中另外一个很明显的问题是：

插件分散在 GitHub topic、registry 和不同 repo 中。

所以我后来把目前的数据做成了一个可搜索索引：

DSH Marketplace

目前索引了 2500+ 个插件，可以按分类、名称、作者、Star、更新时间等信息进行筛选。

同时也在逐步补：

• Source

• License

• 安装方式

• 权限信息

• 部分插件实际安装验证

我现在更关心的其实不是最终能收录多少插件，而是如何把插件从“一个 GitHub URL”变成真正能够判断是否值得使用的信息。

总结

从目前的插件分布来看，DeepSeek Harness 的扩展生态已经开始覆盖一个 Agent 系统的多个层次：

能力、界面、状态、输入、方法和工作流。

这也是我觉得 Harness 插件生态比较值得继续观察的原因。

后面插件数量继续增加几乎是必然的。

真正值得看的会是：

哪些插件组合最终能形成稳定、可复用的 Agent 工作流。