最佳 DeepSeek Harness 工作流与自动化插件（2026）

DeepSeek Harness（dsh）官方自带一个工作流引擎（ctx.workflowEngine）和一套用于持久化、多轮次目标的"goal"子系统，但多智能体团队编排、类似 cron 的定时任务、特定领域的研究循环，全都是社区插件的地盘。以下是 FindHarness curated 索引里的八款工作流与自动化插件，按截至 2026 年 8 月的 GitHub star 数排序。

一览表

插件	Star 数	做什么	链接
dsh-agent-teams	253	多智能体团队编排	插件详情
dsh_workflow	54	可生成、可治理、可续跑的工作流层	插件详情
mstar-harness	43	Skill 驱动的 harness/loop 工程工作流 agent	插件详情
dsh-automation	32	带审计历史的定时编码任务	插件详情
dsh-suite (plugin-team-board)	16	共享的多智能体任务看板	插件详情
dsh-deep-research	10	基于官方工作流引擎的深度研究编排器	插件详情
dsh-science	9	ReAct 研究循环 + 10 个基因组学/生物信息学 skill	插件详情
dsh-sentinel	6	条件驱动唤醒：文件/命令/http/webhook 监听	插件详情

这八款插件全部来自 FindHarness curated（source: awesome）索引下的 workflow-automation 分类。以上没有一款经过 FindHarness 的安全评估——安装前请先读插件安全检查清单，尤其是在给这些插件放开较大范围的多智能体或定时任务权限之前。

这个分类里哪些是官方的、哪些是插件

这个分类里有两块内容确实是 dsh 一等公民的官方概念，值得和下面的插件分开看：

工作流引擎（workflow/workflow、workflow/tool-ralph）：一个通用工作流引擎，暴露为 ctx.workflowEngine，再加一个"Ralph loop"工具——一种特定模式：每一轮都跑在一个全新的、不带历史记录的子 session 里，状态只通过共享工作区和一份结构化的交接报告（status/summary/evidence/next steps/blocker）向前传递。
Goal（goal/goal、goal/command-goal）：挂在已有 session 上的一个持久化目标，有 active/paused/blocked/complete 四种状态，以及一个 /goal 人类命令。

**子代理（Subagent）**也是官方的——dsh 的 ctx.subagents 注册表支持委派给进程内子代理、Claude Code、Codex，或一个外部 ACP 进程。下面的 dsh-agent-teams 是在这个底层能力之上构建出的一种特定多智能体团队模式，而不是取而代之。

八款插件详解

1. dsh-agent-teams —— 多智能体团队编排

github.com/nanmicoder/dsh-agent-teams · 253 star · MIT · npm：@nanmicoder/dsh-agent-teams

star 数遥遥领先的工作流插件。"AgentTeams multi-agent teams" 是 FindHarness 索引里的完整描述——团队具体如何定义和协调，需要查看仓库自己的 README，但仅凭 star 数就能看出，这是社区对"如何让多个 agent 一起协作"这个问题、超出 dsh 原生子代理委派原语之外的默认答案。

dsh plugin --profile web add @nanmicoder/dsh-agent-teams

2. dsh_workflow —— 可治理的工作流层

github.com/icetomoyo/dsh_workflow · 54 star · MIT

描述为"UltraCode 风格的多智能体编排"：一个可生成、可保存、可治理、可观测、可续跑的工作流层。对治理和可观测性的强调，把它和一个简单的任务执行器区分开来——它面向的是那些你想在运行过程中检查和控制的工作流，而不是发射后不管。

dsh plugin --profile web add github:icetomoyo/dsh_workflow

3. mstar-harness —— skill 驱动的循环工程

github.com/btspoony/mstar-harness · 43 star · MIT · npm：@mstar-harness/dsh

一个"skill 驱动的 harness/loop 工程工作流 agent 插件"。围绕循环工程的表述暗示它和 dsh 自己的 Ralph loop 概念有重叠，但作为一个专门围绕 skill 构建的插件——在假定它们等价之前，先去 README 里看看它和官方的 workflow/tool-ralph package 是如何组合或有何不同的。

dsh plugin --profile web add @mstar-harness/dsh

4. dsh-automation —— 定时编码任务

github.com/titanwings/dsh-automation · 32 star · MIT

在全新 agent session 里跑定时编码任务，带可审计的历史记录。这是列表里最接近"dsh 版 cron"的插件——每次定时运行都会启动一个新 session 而不是复用已有的，历史记录保持可审计，如果你在跑无人值守的任务、想要一份每次运行实际做了什么的记录，这一点很重要。

dsh plugin --profile web add github:titanwings/dsh-automation

5. dsh-suite (plugin-team-board) —— 共享任务看板

github.com/whyihaveyou/dsh-suite（packages/plugins/plugin-team-board）· 16 star · MIT

一个共享的多智能体任务看板——创建、认领、流转、查询任务——基于一个 Cordis 服务 key 实现，让多个 agent/插件能通过它协调工作。它解决的问题比 dsh-agent-teams 更窄：这是一个协调原语（一块共享看板），而不是一个完整的团队编排框架，很可能可以被用在一个自定义多智能体方案的底层。注意这个插件位于一个 monorepo 的 packages/plugins/plugin-team-board 子目录下——请先查看该仓库自己的 README 确认准确的安装路径。

dsh plugin --profile web add github:whyihaveyou/dsh-suite

6. dsh-deep-research —— 基于官方引擎的研究编排

github.com/omdsh-dev/dsh-deep-research · 10 star · MIT

一个自适应深度研究编排器，明确说明是构建在官方工作流引擎之上，而不是自己重新实现一套循环逻辑。正因为这一点值得单独指出：如果你想找一个建立在 ctx.workflowEngine 之上、而不是绕开它自建一套的插件长什么样的实际例子，这是 curated 索引里少数明确说明这一点的插件之一。

dsh plugin --profile web add github:omdsh-dev/dsh-deep-research

7. dsh-science —— 特定领域的研究工作台

github.com/biociao/dsh-science · 9 star · MIT

一个"Claude Science 风格的研究工作台"：一个暴露 research_* 工具的 ReAct 研究循环引擎、通过 artifact_* 工具实现带溯源的版本化产物，以及十个打包好的、覆盖基因组学、病原体、生物信息学的科学 skill。这是本文里领域针对性最强的插件——如果你的工作确实涉及这些领域会最有用，但即便不涉及，它也是一个很好的参考,展示了一个功能齐全的研究工作流插件（循环 + 产物 + skill）该长什么样。

dsh plugin --profile web add github:biociao/dsh-science

8. dsh-sentinel —— 条件驱动唤醒

github.com/fuhefei/dsh-sentinel · 6 star · BSD-3-Clause

对文件、命令、HTTP 端点、进程或 webhook 进行持久监听，条件触发时唤醒 agent。这是和 dsh-automation 的定时运行不同的一种自动化形态——不是"每 N 小时跑一次"，而是"X 发生时才跑"，对于真正由事件驱动（文件变化、webhook 触发）而不是由时间驱动的任务，这一点很重要。

dsh plugin --profile web add github:fuhefei/dsh-sentinel

多智能体方案怎么选

这里有三款插件从不同角度涉及多智能体协调：

dsh-agent-teams —— 采用最广的通用"跑一个 agent 团队"插件。
dsh_workflow —— 一个可治理的工作流层，更偏重结构和可观测性,而不是团队组成本身。
dsh-suite (plugin-team-board) —— 一个更窄的协调原语（一块共享任务看板），而不是完整框架——如果你在搭建一套自定义方案、只需要这块看板，这个更合适。

哪一个适合你取决于：你想要一个现成的团队模式（dsh-agent-teams）、一套受治理的工作流结构（dsh_workflow），还是一个自己拼装用的协调构建块（plugin-team-board）。