toolclub/dsh-agent-team-gui

dsh-agent-team-gui

English | 简体中文

Give DeepSeek Harness a reusable team: one Agent plans, another implements, and a third reviews.

Save the team once, choose a model for each member, and reuse it across projects and conversations. Follow the plan, member outputs, retries, and provider-reported Token usage in one Run Center. This is an unofficial community plugin for the DeepSeek Harness Web profile.

Watch the 80-second UI guide · Install v1.3.0 · Run your first team · Example recipe ·

*Screenshot-based UI guide with example data and Chinese synthetic narration. Displayed task results, timings, and Tokens are not a live-run benchmark. Sources and captions.*

If this is useful for your DSH workflow, give the project a Star and help another developer discover it.

Why this plugin

A team is a reusable product object, not a one-off dispatch form. Create it once in Settings → Teams, then use it across projects and conversations.

Capability · User outcome One model and tool policy per member · Combine a planner, implementer, reviewer, or specialist without forcing one route on everyone Dynamic workflow planning by default · The active conversation's model assigns focused work and dependencies from the current request Team / Solo / Inherited modes · Choose a durable conversation override, a project default, or a one-message exception without ambiguous switches Bounded DAG, retries, quality gate, background work · Long work is observable, cancellable, finite, and restart-safe Official provider Token usage · See input, cache-read, cache-write, and output Tokens with full/partial/unavailable coverage—never invented prices Versions, recipes, and definition backup · Reproduce a team, share it without credentials, preview impact, and remap model routes before applying

Install

Plugin release · DSH target · Upgrade guidance 1.3.0 · >=0.1.5-rc.1 =0.1.5-rc.1 =0.1.5-rc.1 =0.1.5-rc.1 <0.1.6-0 · Initial 0.1.5 compatibility; upgrade the plugin to 1.3.0 1.0.1 · Verified with 0.1.1-rc.2 · Previous integration; upgrade both DSH and the plugin together

The walkthrough has English subtitles and Chinese subtitles. Load the SRT alongside the existing video in a compatible player; GitHub does not attach it automatically.

Upgrading DSH from 0.1.1? Use plugin v1.3.0 for DSH 0.1.5. This release fixes source.subscribe during plugin loading, migrates reconnect and Session APIs, and keeps the existing team definitions and run store. Restart DSH and refresh the browser after upgrading. The CLI may report 0.1.5-rc.1 while its compatible internal packages resolve to 0.1.5-rc.2.

Requirements: a working DeepSeek Harness Web profile, at least one configured provider/model, Node.js >=22.19.0 =24.0.0, and pnpm. Declared DSH compatibility is >=0.1.5-rc.1 <0.1.6-0; the v1.3.0 release was verified against DSH 0.1.5-rc.1.

Recommended: install the compiled release package. It includes the built Host and client files, so installation does not run this plugin's Git prepare build or require its allowBuilds entry.

dsh plugin --profile web add https://github.com/toolclub/dsh-agent-team-gui/releases/download/v1.3.0/dsh-agent-team-gui-1.3.0.tgz
dsh --profile web

Stop and restart an already-running DSH Web process after installing or upgrading. Then open Settings → Teams. If a plugin marketplace chooses Git installation and fails, use the direct release command above; see installation troubleshooting.

DSH 0.1.7-rc.2 is outside this release's declared host range; its installer rejects v1.3.0's peer ranges and rolls back the installation (reproduced on macOS arm64, Node 26.5.0, pnpm 12.6.0). Do not treat a change of installation source as runtime support. The Node engine range is not a claim that every newer Node/DSH combination has been tested.

For DSH Plugin Hub, use version 1.5.2 or later with a refreshed catalog. Hub 1.4.8 does not have the release-package channel. If the catalog still selects Git, use the direct command above. Hub caches the catalog for one hour and can reuse stale data when a refresh fails.

Release notes and checksum ·

[!TIP]

If dsh is not on PATH, use the launcher that starts your working Harness installation.

With npm, replace dsh with npx @deepseek-ai/dsh@0.1.5-rc.1; from a source checkout, replace

it with pnpm --dir /absolute/path/to/deepseek-harness dsh. Keep the same launcher for installation

and startup. New to Harness? Start with its official setup guide.

Verify that both the dsh-agent-team-gui bundle and the agent-team-gui configuration row are present:

dsh --profile web --dump-config

Run your first team

Use the included full-stack delivery recipe, with a planner, implementation engineer, and reviewer. You can bind all three to the same working model for the first run; multiple providers are optional.

1. Download the recipe JSON. Open Settings → Teams → Recipes & data and choose Choose recipe file.
2. Map the placeholder routes to your configured provider/model routes, review the preview, and choose

Create a copy → Import reviewed recipe. In Member library, confirm each member's exact model and tool access.

1. For this first walkthrough, set Team usage → Host dispatches first, Dispatch policy → Run assigned work, and member selection to

All members, then save. The supplied recipe otherwise uses Smart/adaptive selection.

1. Select an empty scratch project, choose the imported team beside the composer, select Select team for this conversation, and send the

ready-to-copy task: build and test a small to-do list.

1. Open Team runs to inspect the plan, outputs, review, and actual Token coverage. Check the delivered

files and test results before treating the task as complete.

Create your own team

In Settings → Teams → Member library, save each member's role, model, optional fallback, and tool policy. In Settings → Teams, add those members and choose activation, member selection, and execution options. Leave Fixed order off for dynamic planning, or enable it for a fixed serial sequence. Choose Team, Solo, or Inherited beside the composer to control the current conversation.

*UI example with demonstration data.*

How orchestration works

flowchart TD
    U[User message] --> M{Effective mode and one-shot choice}
    M -->|Solo or Manual| L[Lead handles request directly]
    M -->|On demand| J{Lead decides whether delegation helps}
    J -->|No| L
    J -->|Missing information| A[Ask user]
    J -->|Yes: dispatch_to_squad| D[Validate and admit one initial dispatch]
    M -->|Host dispatch or Force Team next| D
    D --> P[Use explicit plan or invoke bounded planner]
    P -->|Smart skip| L
    P --> W[Dependency-ready members, failure policy, optional quality gate]
    W --> R[Persist results, diagnosis and reported usage]
    R --> L
    R -->|Lead reviews unfinished work| C[Bounded continue_squad_run]
    C -->|Reuse successes, shared budget, one continuation| W

New editor drafts and built-in templates default to Lead decides when to delegate. Selecting a team makes it available; simple answers create no planning child or team run. Saved/imported choices and legacy missing-field defaults remain unchanged. Full flow and edge-case contract. Host background runs finish in Run Center; model-initiated tool dispatch waits for its result.

After dispatch, when no explicit assignments/order are supplied and no fixed order exists, the plugin uses the active conversation's provider/model route in a bounded, tool-free planner child. It receives the member roles and returns structured assignments plus an acyclic dependency graph. It does not turn one member into a replacement for the whole team. A bad, cyclic, or unavailable plan falls back to deterministic role-scoped assignments.

Ready DAG nodes run up to maxConcurrency. Dependants receive only bounded structured handoffs; full member output remains in durable run history. A fixed member order is an explicit serial override and bypasses DAG planning.

Activation and selection

• Run assigned work requires execution once dispatch has been chosen; it does not force on-demand delegation.
• Smart lets the bounded planner skip unsuitable/trivial work.
• Manual blocks ordinary automatic/model dispatch; explicitly choose Force Team next or a manual Run Center action.
• All members assigns each configured member exactly once.
• Adaptive lets Smart planning select the smallest useful non-empty subset.

Conversation modes

• Team is an explicit durable team selection for this conversation.
• Solo is an explicit durable opt-out, even when the project has a default team.
• Inherited removes the conversation override and follows the project default when one exists.
• Next message is a separate crash-safe one-shot Team or Solo choice, consumed exactly once.

These states remain interactive after page refresh, cold Host startup, and live reconnect. An empty or temporarily unavailable catalog never silently deletes a saved selection.

Safety bounds

• Planner, member, reviewer, and repair prompts put the exclusive role and no-delegation contract

before a bounded excerpt of user content.

• Delegated sessions cannot dispatch another team. Detected DSH subagent tools—including renamed

registrations—are denied inside team children.

• One durable claim binds automatic and model-tool dispatch to the latest human message, so repeated

tool calls cannot create hundreds of duplicate teams.

• Member timeout, concurrency, retry-once, soft team Token budget, and quality rounds are finite.
• A retry creates a linked immutable run and replays the original normalized assignments, order,

and DAG; it does not silently ask the model to invent a different workflow.

Run Center and Token usage

Every execution is written before planning starts. The Run Center exposes foreground/background state, live phase, elapsed time, child IDs, complete outputs, bounded handoffs, stop, linked whole or member retry, export, filters, and retention-safe clear.

If a DSH child settles with stopReason: "error" after delivering non-empty plain text, the member counts as Completed instead of losing a valid long-form deliverable. The stop reason remains recorded and Run Center shows a protocol-delivery warning. Empty output, rejected runs, cleanup failures, timeouts, and other non-completed reasons such as max-tokens remain failures.

Each member handoff summary keeps up to 16,000 characters by default. A team may set handoffSummaryMaxChars from 1,000 to 32,000. Complete raw output remains durable in Run Center; dependency and lead prompts retain separate aggregate bounds so one long artifact cannot make model context unbounded.

The plugin reuses DSH's official tokenUsage projection and keeps four buckets:

• uncached input;
• cache read;
• cache write;
• output.

Planner, member, review, and repair usage remain separately attributable. Coverage is explicitly full, partial, or unavailable at run and retry-attempt level. Before a provider reports a sample, the UI says Metering… instead of showing a false zero. Tokens are not money; the plugin does not guess prices that Harness providers do not publish through a stable pricing contract.

Quality gate and background runs

An optional quality gate names one reviewer, one repair owner, explicit criteria, and 0..2 repair rounds. A rejection can rerun only that repair owner, followed by the named reviewer. It cannot create arbitrary agents or recurse.

Foreground runs finish before the lead Agent synthesizes bounded handoffs. Background runs return a short acknowledgement and stay visible in the plugin Run Center; when the official DSH Jobs service is present, the same run is also registered there with a shared cancel hook. Without that optional service, the plugin falls back to process-local background execution; a Host restart then reconciles unfinished durable state as Interrupted rather than pretending it completed.

Versions, recipes, and definition backup

• Each saved team version includes immutable snapshots of all referenced member definitions.
• Restore is preview-first and warns when a shared member would change another team.
• Recipes contain one team and its members, never provider credentials. Import supports Copy or

Merge, conflict preview, and separate primary/fallback route remapping.

• Definition backup exports agents and teams. Import is preview-first with Merge or Replace;

replace reports deletions, dangling mode/default cleanup, and affected teams before confirmation.

• Multi-table writes are serialized and use compensating rollback on validation, cancellation, or

storage failure. Readers see either the previous or committed definition graph, not a half-import.

• Remote recipe URLs are disabled in v0.5. Import a reviewed local JSON file; this intentionally

avoids exposing an unprotected server-side fetch/SSRF surface.

Start with the credential-free full-stack delivery recipe, preview it, and remap its your-provider / your-model placeholders to routes configured in your own DSH profile.