Preface¶

DeepSeek Harness (hereinafter referred to as DSH) has made model routing, sub-Agents, tool permissions, approval, Session logs, and background jobs into replaceable plugin capabilities. The slogan of the official repository deepseek-ai/deepseek-harness is “Everything is a plugin”: you can attach new capabilities at the configuration layer without modifying the kernel.

When actually running complex tasks, the gap often lies not in “whether we can start a few more Agents”, but in the process itself. For tasks like parallel investigation, partitioned review, and adversarial verification, if you have to re-describe how to split, concurrency, and aggregate them in the current session every time, the strategy is difficult to reuse; after an interruption mid-run, the results are scattered across the conversation, and you usually have to start over from scratch. The built-in front-end workflow tool of DSH is suitable for “running several tasks in parallel this time”, but it is not an engineering asset that can be named, saved, audited, and resumed.

The community plugin dsh_workflow addresses this layer. This article is organized after cross-checking the community directory page, GitHub README, package.json, and license: what it is, what it can do after installation, how to write commands, and the permission boundaries you must understand before installing. The community plugin directory is an independent site and has no official affiliation with DeepSeek / Fang Tian. Do not treat it as an official app store.

What it is¶

dsh_workflow is a workflow and automation plugin for DSH. The community directory lists the maintainer as icetomoyo, the license is MIT, and the main language is TypeScript. The npm package name is @dsh-external/workflow, and the plugin ID after mounting to the profile is dsh-external-workflow. The current released version is 0.1.2 (2026-08-13). As of August 17, 2026, GitHub shows 63 stars.

The repository description and directory page use the same sentence to summarize its goal: bring Claude Code’s UltraCode mode to DSH, and upgrade one-off multi-Agent scheduling into a Workflow layer that can be generated, saved, governed, observed, and recovered. In Claude Code’s documentation, UltraCode automatically writes orchestration scripts and fans out sub-Agents for substantive tasks; what dsh_workflow adds to DSH is a higher-level product capability, rather than porting Claude Code as-is. The README clearly states: implement the complete workflow behavior of the reference KodaX, and independently implement it for DSH’s Cordis, ctx.subagents, Session, background jobs, approval, command, and tool mechanisms, without copying KodaX’s restricted licensed source code.

It explicitly does not replace DSH’s existing front-end workflow tool. The native tool continues to handle single parallel runs; this plugin handles a higher layer: discovering and running by name, on-site generation, pause/resume, re-running from snapshots or resuming with cache, and permanently persisting run graphs, events, artifacts, and costs. The “official bundle form, zero core patches” mentioned in the README refers to mounting via the DSH plugin bundle method without modifying Harness source code, not that it is an official DeepSeek product.

Currently, icetomoyo/dsh_workflow and dsh-external/dsh_workflow on GitHub resolve to the same repository (under the organization omdsh-dev: dsh_workflow). Always use the command given on the directory page when installing.

Core Features¶

Differences between one-off scheduling and reusable workflows¶

DSH already has execution primitives, but what it lacks is the ability to aggregate these primitives into maintainable processes. The repository README uses a comparison table to illustrate the changes before and after installation, and the core differences can be summarized as follows:
- Task splitting strategies no longer need to be rewritten every round, but can be saved as project or personal workflows and run by name.
- Parallel results are no longer only retained in conversation bubbles, but written to run graphs, event streams, artifacts, result summaries, and cost records.
- After an interruption, you can re-run from a run snapshot or resume unfinished tasks using the effect cache, without having to start over from scratch.
- Provider, model tier, concurrency, and budget are no longer only constrained by prompts, but enforced via manifest, preflight, and runtime hard limits.
- Generated scripts run by default in a capability-only QuickJS WebAssembly isolated heap, with permissions restricted via JSON boundaries and approval levels.

For DSH projects, the effect is that multi-Agent setups change from “a one-time trick” to engineering assets that can be audited, shared, and evolved.

Capsules, built-in workflows, and six modes¶

The execution unit is a versioned dsh.workflow v1 capsule, which contains manifest, source, intent, inputs, requires, and provenance. The runtime model is unified as async function run(wf, args). The host provides phase, spawnAgent, runAgent, wait, snapshot/output, send/stop, parallel, pipeline, synthesize, single-layer nested workflows, as well as artifact, log, and budget capabilities via the WorkflowApi.

The repository currently includes two built-in workflows:
- parallel-investigation: Parallel investigation that can be parameterized by rubric, agent, and concurrency.
- scoped-review: Partitioned review with packet / schema / read-contract, dual primaries, per-finding verifier, and audit artifacts. The /workflow review command can directly capture the current Git scope and start it without patching the DSH core with a /review command.

There are also six standard patterns: classify-and-act, fan-out-and-synthesize, adversarial-verification, generate-and-filter, tournament, and loop-until-done. Agents can specify phase, scope, read-only, provider / sub-Agent type, and three routing tiers: fast | balanced | deep.

The discovery order is deterministic and will not “accidentally read another file with the same name”:
1. Plugin-built-in workflows and patterns (cannot be shadowed by disk files)
2. Project directory .dsh/workflows
3. Personal directory $DSH_HOME/workflows

Project entries override personal entries; within the same directory, .workflow.json takes precedence over .ts/.mjs/.js. Symbolic links, path escaping, oversized files, unknown capsule fields, version incompatibility, and mismatched manifest and filename will all cause a failure before execution.

Lifecycle, persistence, and resumption¶

Each run has a stable ID, and the status switches between running → paused/completed/failed/denied/stopped. By default, data is written to the project directory:

.dsh/workflow-runs/<run-id>/
├── run.json                    # Status, result summary, cost
├── events.jsonl                # Append-only event graph
├── workflow.workflow.json      # Immutable execution snapshot of generated workflows
├── results/                    # Completed and verified effect cache
└── artifacts/                  # Workflow-named evidence

Re-running by run ID uses the immutable snapshot from that run; re-running by a saved name uses the current saved version. resume-run hits the cache for the same call sequence and same task input, and continues executing the remaining tasks. Final-state runs are automatically cleaned up according to maxRetainedRuns, and you can also use prune to preview or perform cleanup.

Slash commands, model tools, and background jobs use the same engine, run store, and security policy. Workflow startup and run_workflow return { runId, status, jobId? } immediately by default, and long-running processes will not occupy the current turn; when you need to wait synchronously for the final state, explicitly add --wait or wait: true.

Installation and Enablement¶

The installation command given on the community directory page can be run in the DeepSeek Harness terminal:

dsh plugin add github:icetomoyo/dsh_workflow

The directory page also reminds you: for reproducible installations, pin the commit hash. The latest commit on the current main branch is 44b83c182aa02d1be8a0803e8446cb495f93cd8f (author icetomoyo, 2026-08-13), which can be written as:

dsh plugin add github:icetomoyo/dsh_workflow#44b83c182aa02d1be8a0803e8446cb495f93cd8f

The GitHub README additionally provides the syntax for mounting to the web profile, and notes that the build artifacts have been committed, so no compilation is required on the user side when installing from the git source:

dsh plugin --profile web add "github:dsh-external/dsh_workflow#main"
dsh --profile web --dump-config

When verifying, the configuration should include:

- id: dsh-external-workflow
  name: '@dsh-external/workflow'

You need to restart the corresponding DSH process after modifying the profile. The runtime requirements come from the README and package.json: Node.js >=22.19 (package.json specifies ^22.19.0 || >=24.0.0), and a DSH snapshot consistent with the repository’s compatibility.json. The current compatibility baseline recorded in this file is DSH 0.0.1-rc.2, tested on 2026-08-13.

The plugin runs with the permissions of the current dsh process, and may execute code during installation. Please check the source code repository and license before installing.

Typical Usage¶

After restarting the corresponding profile, the README recommends running this set of commands in the session first:

/workflow list
/workflow parallel-investigation {"question":"为什么这个测试会间歇失败？"}
/workflow create 为这个仓库设计一个并行安全评审流程
/workflow review --risk high --requirement "不得破坏公开 API" --test-evidence "pnpm test 通过" --wait
/workflow runs

/workflow list will list built-in, pattern, project, and personal workflows; invalid entries will be reported but not executed. /workflow <name> [JSON args] starts a saved workflow by name. /workflow show defaults to the latest run, and /workflow stop defaults to stopping the current active run.

/workflow create <request> and /workflow <natural language request> for unknown names will not get stuck on command/run as a slash command. They will immediately end command processing and pass the original user question as a real user message to the current main Agent; the internal writing convention is passed to the model as a collapsed plugin context to avoid polluting the session title. The main Agent first investigates the workspace using its own tools, then calls run_workflow with source + manifest to generate and start the workflow. This path does not accept --wait; to wait synchronously, use --wait on a named workflow, rerun, or review.

The repository also provides a restricted capsule example examples/review.workflow.json. It declares readOnly: true, fans out according to independent scopes like implementation / tests / docs, then proceeds through verifier and synthesize steps. It is suitable for reviewing against the capsule fields rather than copying directly as a production workflow.

There are three corresponding tools on the model side:
- workflow_list: Discover available workflows
- run_workflow: Run named workflows, scout-then-author from natural language, or execute restricted inline workflows
- workflow_manage: View, pause, resume, stop, rerun, resume, save, rename, revise, delete, and clean up

Common governance commands also include:

/workflow help
/workflow pause|resume|stop [runId]
/workflow rerun|resume-run <runId|savedName> [JSON args] [--wait]
/workflow save <runId> <name> [project|personal]
/workflow prune [--dry-run] [--keep N] [--older-than 7d|24h]

Slash commands use ctx.userQuestions for one-time human confirmation; model tools use the current turn’s ctx.approval. Background runs will try to register to ctx.jobs, while always retaining the plugin’s own durable run ID.

If you are using DSH Web, the left workspace will collapse other sessions when “manual sorting” is enabled and there are more than 5 sessions. New workflow sessions already belong to the corresponding workspace; if necessary, click “Expand N other sessions” or switch the view to “Recently Updated”.

Applicable Scenarios and Notes¶

It is suitable for these situations:
- You need to make parallel investigation, partitioned review, and adversarial verification into reusable workflows, rather than rewriting the splitting method in the conversation every time
- You want runs to have stable IDs, event graphs, and cost records, and be able to re-run or resume after interruptions
- Your team wants to treat multi-Agent strategies as project assets and store them in .dsh/workflows, rather than only keeping them in someone’s individual session

It is not suitable as a replacement for DSH’s native workflow tool. For one-off parallel runs of several tasks, continue to use the front-end tool. Also do not expect it to automatically fill in capabilities that are not yet available in the current DSH sub-Agent interface: the README clearly states that the generic subagent seam does not currently directly support existing-agent target, per-agent effort, and worktree; these requests require the deployment side to register an adapter, and will fail explicitly instead of silently degrading when not registered.

You also need to remember these boundaries:
- Generated scripts can only produce side effects via the frozen WorkflowApi, running in an independent QuickJS WebAssembly heap; import/require, process, files, shell, network, timer, and non-deterministic APIs will be statically rejected. It is still an in-process component, not an OS-level container.
- Trusted local modules (.ts/.mjs/.js) in the project or personal directory run with Node host permissions and require explicit confirmation each time. Do not mark unvetted third-party source code as trusted-local.
- Only generated capsule runs save immutable script snapshots; pure-function trusted-package / local runs cannot be saved again from the run ID.
- dsh.workflow v1 is not protocol-compatible with KodaX capsules, and external capsules will not be accidentally executed.
- Built-in verification covers actual read/mutation tool evidence, Git workspace changes, required path前后 fingerprints and text post-conditions; for non-Git workspaces or when external authoritative evidence is required, you need to register a verification adapter yourself.

Common configuration items (see the repository’s docs/CONFIGURATION.md for full fields) include approvalMode (never | generated-and-local | always, the README example defaults to generated-and-local), maxAgents, maxConcurrency, maxRetainedRuns, and provider and token limits for the fast / balanced / deep tiers. When a workflow’s declared requirement is not in the deployment capability list, it will fail directly instead of silently degrading.

Again: The plugin runs with the permissions of the current dsh process, and may execute code during installation. Check the source code and MIT license before installing; for a reproducible environment, pin the commit and verify the DSH snapshot in compatibility.json.

Summary¶

dsh_workflow does not build a separate orchestration kernel parallel to DSH, but aggregates existing providers, sub-Agents, approval, Sessions, and jobs into a workflow layer that can be named, persisted, and resumed. For people who often need to沉淀 multi-Agent workflows, it adds “workflow product capabilities” rather than “just another parallel switch”.

Community Directory: https://deepseek-harness-plugin.com/zh-CN/plugins/dsh_workflow/

GitHub: https://github.com/icetomoyo/dsh_workflow

Using dsh_workflow to make DSH's one-time multi-Agent scheduling into a recoverable workflow