dsh-meta-orchestrator
一个面向 DeepSeek Harness 的原生模型元代理插件：模型基于五种代理工作流模式（提示链、并行工作器、路由器、监督器、评估循环）在运行时合成特定于任务的工作流，并协调工具和子代理
插件会安装到这里；不确定时保持 web。
npx -y @deepseek-ai/dsh plugin --profile web add dsh-meta-orchestrator@0.2.0Meta Orchestrator 以 dsh-meta-orchestrator 发布，当前版本为 0.2.0。Plugin Hub 会校验它的 manifest，并保存精确安装来源，便于复现安装结果。
A DeepSeek Harness plugin that teaches the agent to synthesize a task-specific workflow at runtime — instead of hard-coding pipelines or fixed agent topologies. For anyone running multi-step work in DSH who wants the plan the agent follows to be explicit, versioned, and durable rather than implicit.
Normally an agent just starts working on your request. With this plugin, it plans first, then works the plan — and the workflow is dynamic: written by the model itself, per request:
prompt-chaining), ⚡ fan out independent parts (parallel-workers), 🔀 classify, then dispatch (router), 🎯 delegate and review (supervisor), 🔁 draft → score → improve (evaluation-loop). Each pattern's detailed playbook is loaded only when picked.orchestrate with the stages, the roles it will delegate, and verifiable success criteria. The plugin validates the structure and saves it durably. That is all the plugin ever does: it records plans, it never executes them.adapt_workflow revises the plan (every revision is versioned); when the work is done, complete_workflow records how each success criterion turned out.Simple requests skip all of this — the agent is explicitly told not to orchestrate for orchestration's sake.
flowchart LR
A["1 · Analyze"] --> P["2 · Pick a pattern"] --> W["3 · Write the plan<br/><sub>orchestrate</sub>"] --> E["4 · Do the work<br/><sub>DSH primitives</sub>"] --> M["watch progress"]
M -- "reality diverged" --> AD["revise the plan<br/><sub>adapt_workflow</sub>"] --> E
M -- "work finished" --> D["5 · close it out<br/><sub>complete_workflow</sub>"]
All of this behavior comes from one short instruction block the plugin adds to the agent's system prompt — no extra model calls, no background processes.
| Added to your agent | What it is |
|---|---|
| An instruction block (~330 words) | Teaches the plan-first protocol above; sits in the system prompt of every session |
| Five pattern playbooks | Skills in the catalog; cost nothing until the model loads one |
orchestrate / adapt_workflow / complete_workflow | The three recording tools: save the plan, revise it, close it |
create → adapt* → complete chain, fenced per session lifecycle. No custom session event types, so orchestrated sessions always resume cleanly.flowchart TB
subgraph P["🧭 dsh-meta-orchestrator"]
direction LR
PS["policy section"]
SK["5 pattern skills"]
TL["orchestrate · adapt_workflow · complete_workflow"]
end
subgraph H["🐋 DeepSeek Harness"]
direction LR
SYS["system prompt"]
CAT["skill catalog"]
REG["tool registry"]
DOM[("storage domain")]
end
PS --> SYS
SK --> CAT
TL --> REG
TL --> DOM
H --> EX["subagent · workflow · todo · goals · plan mode"]
| dsh-meta-orchestrator | workflow-capsule engines | agent-team plugins | |
|---|---|---|---|
| Who plans | The model, per request, at runtime | A generated script in a bundled sandbox runtime | A fixed lead + specialists topology |
| Pattern choice | Selected and composed from five canonical patterns | Baked into capsule scripts | One topology for every task |
| Execution | Harness-native primitives only | Own QuickJS/WASM runtime + run store | Own mailbox/wake-up machinery |
| Re-planning | adapt_workflow re-plans the pattern itself, versioned | Pause/resume/rerun of the same script | Re-brief within the fixed topology |
| DSH coupling | Public plugin surface only | Pinned to a harness snapshot | Patches harness dependencies |
| DSH packages | peer range @deepseek-ai/*@^0.1.0-rc.5 — verified against 0.1.0-rc.6, the current npm release |
| Mainline | 47f9438 (2026-08-13) |
| Last verified | 2026-08-14 — real npm install, 46/46 tests, live web profile session |
| Node | ^22.19.0 || >=24.0.0 |
| Profile | needs the storage stack, shipped by the @deepseek-ai/dsh-web-app bundle (the standard web profile). The stock headless profile does not ship it — see Troubleshooting. |
| Platforms | Windows 11 (dev), Ubuntu (CI) |
Only public plugin surfaces are used — systemPrompt, skills, tools, storageDomain, agent/pre-step — so ordinary harness churn rarely bites. But the harness is pre-1.0, and a semver caret does not span prerelease lines: ^0.1.0-rc.5 matches 0.1.0-rc.6, not a future 0.1.1-rc.1. When a new rc line lands, the peer range here needs a bump — open an issue if you get there first.
Requires a profile with the storage stack — the standard web profile (dsh-web-app bundle) ships it (see Compatibility).
dsh plugin --profile web add dsh-meta-orchestrator # from npm
dsh plugin --profile web add github:jiruidai/dsh-meta-orchestrator#v0.2.0 # from git, pinned
dsh plugin forwards to pnpm inside the profile directory, so every pnpm verb works. Restart dsh after an add or remove — the bundle layer list is read at boot; only the cordis.patch.yml layers hot-reload.
A git install builds via the package's prepare script, so pnpm asks you to allowlist it once in the profile's pnpm-workspace.yaml (allowBuilds: { dsh-meta-orchestrator: true }).
dsh plugin --profile web update dsh-meta-orchestrator # within the installed range
dsh plugin --profile web add dsh-meta-orchestrator@latest # across ranges
dsh plugin --profile web add github:jiruidai/dsh-meta-orchestrator#v0.3.0 # git installs: re-add the new ref
The profile's own patch layer applies after every bundle layer and hot-reloads — this takes effect on the next request, no restart, no reinstall. In $DSH_HOME/profiles/web/cordis.patch.yml ($DSH_HOME defaults to ~/.dsh):
- id: meta-orchestrator
disabled: true
Delete those two lines to switch it back on. Recorded workflows are untouched either way.
dsh plugin --profile web remove dsh-meta-orchestrator # drops the dependency and the bundle layer
Restart dsh. For a complete removal, the leftovers the CLI does not touch:
| Leftover | What to do |
|---|---|
$DSH_HOME/storages/meta_orchestrator.json | Every workflow the plugin recorded. Delete the file to erase them — nothing else reads it. |
allowBuilds entry in $DSH_HOME/profiles/web/pnpm-workspace.yaml | Remove it if you added one for a git install. |
meta-orchestrator row in $DSH_HOME/profiles/web/cordis.patch.yml | Remove it if you used the dev-install route below. |
Past sessions' session.jsonl | Sessions keep the orchestrate calls that already happened — ordinary session history, not the plugin's to rewrite. |
Build with pnpm build, then add an absolute-path row to $DSH_HOME/profiles/<name>/cordis.patch.yml:
- insert:
- id: meta-orchestrator
name: file:///<path-to-checkout>/lib/index.js
config:
autoTrigger: false
The web profile hot-reloads its patch layer — the plugin is live on the next request, no restart.
No configuration needed — the defaults are the intended setup. Install into the web profile, restart dsh, and hand the agent something genuinely multi-part:
Audit this repo's error handling, then write a short report with concrete fixes ranked by risk.
What you should see, in order:
The agent names its pattern in a sentence — "this is a chain: audit → rank → write."
A skill call loading that pattern's playbook.
An orchestrate call whose result reads back:
workflow "wf-3f2a91c4" recorded (v1)
pattern: prompt-chaining
stages: 4
success criteria: 3
Execute it with the harness's native primitives and report the final result against the success criteria.
Then ordinary DSH work — todos, subagents, tools. The plugin runs none of it: it recorded the plan and got out of the way.
At the end, a complete_workflow call — workflow "wf-3f2a91c4" completed (achieved, v1).
Proof it was persisted, not just narrated (the file appears with the first recorded workflow):
cat $DSH_HOME/storages/meta_orchestrator.json # $DSH_HOME defaults to ~/.dsh
One entry per session id, holding the append-only create → adapt* → complete chain with a full spec snapshot at every step.
Ask something simple instead — "what's in this folder?" — and the agent skips orchestrate entirely. That is the protocol working, not failing.
One key, no environment variables, nothing sensitive:
| Key | Default | Meaning |
|---|---|---|
autoTrigger | false | Append a one-time protocol reminder inside the first request of a session (delivered by composing the agent/pre-step decision). Off by default: the policy section alone drives the protocol at zero extra token cost. |
| Network | none — no requests, no extra model calls |
| Filesystem | none directly — one Node builtin, crypto.randomUUID |
| Credentials / env vars | none read, none stored |
| Subprocesses | none |
| Durable storage | DSH storage domain meta_orchestrator, table workflows, keyed by session id — $DSH_HOME/storages/meta_orchestrator.json on the stock JSON backend |
Worth knowing what lands in that file: every mutation stores a full spec snapshot — the model's written analysis of your request, stage names and details, the briefs it would hand to subagents, success criteria, and the completion report. That is a paraphrase of your task, in plaintext, per session, on your machine. It never leaves the machine, and deleting the file is the entire erase story.
Scope note: this is a host-plane plugin. The ~330-word policy section and the three tools register globally, so every session in the profile carries them — that is the design (see What gets installed), not a leak. With autoTrigger: true, one reminder message is appended to the first request of each session, once.
Boot fails: meta-orchestrator: pending (waiting for services: storageDomain)
The profile has no storage stack. Only the dsh-web-app bundle ships storage / storage-json / storage-domain; the stock headless profile does not. Install into the web profile — or insert those three rows into your profile's patch layer above this plugin.
No orchestrate tool — the plugin seems absent
Check whether the row actually composed: dsh --profile web --dump-config and look for the dsh-meta-orchestrator layer. Missing → the package isn't installed (re-run dsh plugin … add, then restart dsh). Present but disabled: true → a patch layer turned it off.
First add from git fails on a blocked build script
pnpm ≥ 10 refuses a git dependency's prepare script until allowlisted. Copy the exact key pnpm prints into $DSH_HOME/profiles/web/pnpm-workspace.yaml under allowBuilds: and re-run. That allowance means running package code at install time — pin a tag or sha.
The model answers without orchestrating
Intended for simple requests. If you want a nudge at the start of every session, set autoTrigger: true.
orchestrate rejected the spec: …
A structurally invalid spec (no stages, no success criteria, unknown pattern). The error lists every problem and the model normally fixes it on the next call. Nothing is persisted from a rejected call.
… could not record the spec (storage write failed)
The backend rejected the write — check that $DSH_HOME/storages/ is writable. A failed write leaves the recorded chain exactly as it was; it never half-records.
Where to look
| Boot and plugin errors | stderr of the dsh process |
| What actually happened | $DSH_HOME/sessions/<project>/<session-id>/session.jsonl — tool calls and results are ordinary session events |
| The durable record | $DSH_HOME/storages/meta_orchestrator.json |
Rollback, fastest first: disabled: true in the profile patch layer (live on the next request), or dsh plugin --profile web remove dsh-meta-orchestrator plus a restart. Neither deletes recorded workflows.
pnpm install # normal checkout: installs the published @deepseek-ai/* packages
pnpm build # clean + tsc → lib/
pnpm typecheck # src + tests
pnpm test # vitest — 46 unit + mount-integration tests
Issues and PRs are welcome — pnpm typecheck && pnpm test must be green. CI runs install → build → typecheck → test on Node 22 and 24, --frozen-lockfile against the committed pnpm-lock.yaml (generated against registry.npmjs.org).
The maintainer's local checkout instead resolves @deepseek-ai/* from a sibling harness checkout through a hand-built junction tree (see the comments in pnpm-workspace.yaml) — in that setup pnpm install is never run.
skill.orchestrate entirely.MIT.
Reporting a vulnerability — please don't open a public issue. Use GitHub's private vulnerability reporting for this repo; see SECURITY.md. Surface-wise there is little to hold: the plugin executes nothing, opens no sockets, and reads no credentials — the realistic concerns are the policy text it injects and the task paraphrases it stores locally (see Permissions & data).