Contents

• What is this
• Features
• How it works
• Team topology
• Images with a text-only main agent
• The specialist roster
• Repository layout
• Quick start
• Roster configuration
• Usage examples
• Development
• License

What is this

Inspired by the multi-agent workbench idea of oh-my-openagent, rebuilt on DeepSeek Harness native mechanisms:

• Model providers are connected through the official Settings → Models → "Add provider" flow (this suite bundles NO model adapters — zero conflict with the official catalog);
• This suite organizes the team: specialist roster, on-demand dispatch, roundtable review, model comparison, and a multimodal vision bridge.

Features

How it works

Official Settings → Models: deepseek-official + user-added providers (OpenAI-compatible, …)
        │  registered routes
        ▼
collaboration-team roster (settings.yaml)  ←──  each identity: duty + optional model
        │  host service collaborationTeam
        ▼
Main agent (Collaboration preset)
  ├─ team_call     → hire persistent specialist instances (with clones) → report / settlement notices
  ├─ team_message  → follow up or relay to any instance (specialists ask each other via team_help, you relay)
  ├─ team_status   → live team board; team_close → dismiss an instance
  ├─ model_compare → same prompt across models, side by side
  └─ vision        → images to a vision model → text analysis back

Team topology

Every identity can be hired multiple times as separate instances (reviewer#1, reviewer#2, …). The main agent is the star hub — all traffic flows through it.

                     ┌─────────────────────┐
                     │   Main agent (you)  │
                     │     the star hub    │
                     └──────────┬──────────┘
        team_call hires  ·  team_message relays (both directions)
     ┌──────────────┬────────────┼────────────┬──────────────┐
     ▼              ▼            ▼            ▼              ▼
 planner#1      coder#1      looker#1      writer#1      reviewer#2   …
     │              │            │            │              │
     └───────────── report / settlement notices ────────────┘

Specialists never talk to each other directly. When one needs another — for example researcher asking looker to read an image — the request circles through the main agent:

researcher#1 ── team_help ──►  main agent receives [team-relay]
      ▲                             │
      │                             ▼  team_message → looker#1
      │                             │
      └──── team_message ◄────  looker#1 reports the answer

Images with a text-only main agent

The composer's image-attachment path is gated by the current model's inputModalities: DeepSeek text-only routes declare no image modality, so pasted images are rejected at admission — looker or not. tool-image-inbox solves this INSIDE the policy, with a paste-as-usual experience:

Paste an image in a collaboration session
  → an invisible client bridge intercepts the paste (no button, no UI)
  → the image is stored as a workspace file (.dsh-inbox/)
  → "[图片: <path>]" appears in the draft; press Enter
  → the main agent routes the path to the vision tool or hires looker
  → looker configured: normal image analysis; not configured: the agent hints how to set it up

Non-collaboration sessions and text-only pastes are untouched. Alternatives: drop the image into the workspace folder and name the path, or switch the session to a vision route (e.g. zai / glm-5v-turbo) and paste natively.

The specialist roster

Ten pre-defined identities, each with its own specialty. The tool surface is tiered by duty: research-type identities get read-only tools, execution identities get shell/file/skill tools, visual identities get read + vision.

Repository layout

packages/
  host/team/                     Specialist roster (settings.yaml-configurable)
  tools/tool-team/               team_call dispatch + roundtable
  tools/tool-model-compare/      Same-prompt model comparison
  tools/tool-vision/             Multimodal vision bridge
  tools/tool-image-inbox/        Invisible image-paste bridge for text-only mains
config/
  agent-presets/collaboration/   Ready-to-use agent preset
docs/                            Installation & usage guide
scripts/                         Validation scripts

Quick start

Full guide: docs/installation.md.

1. Install the five packages into the DSH profile workspace (from the profile dir, e.g. ~/.dsh/profiles/web):

   # Windows
   pnpm add -w @dsh-collaboration/team @dsh-collaboration/tool-team @dsh-collaboration/tool-model-compare @dsh-collaboration/tool-vision @dsh-collaboration/tool-image-inbox

   # Linux / WSL — same command, run in the profile directory
   pnpm add -w @dsh-collaboration/team @dsh-collaboration/tool-team @dsh-collaboration/tool-model-compare @dsh-collaboration/tool-vision @dsh-collaboration/tool-image-inbox

   Before npm publication, grab the .tgz assets from Releases.

2. Insert the host rows (cordis.patch.yml):

   - insert:
       - id: collaboration-team
         name: '@dsh-collaboration/team'
       - id: collaboration-image-inbox
         name: '@dsh-collaboration/tool-image-inbox'

3. Add model providers via the official Settings → Models → Add provider card:

   Provider	Provider ID	Endpoint	Protocol
   Zhipu GLM	zhipu	https://open.bigmodel.cn/api/paas/v4	OpenAI-compatible
   OpenAI	openai	https://api.openai.com/v1	OpenAI-compatible
   Moonshot	moonshot	https://api.moonshot.cn/v1	OpenAI-compatible
   OpenRouter	openrouter	https://openrouter.ai/api/v1	OpenAI-compatible
   SiliconFlow	siliconflow	https://api.siliconflow.cn/v1	OpenAI-compatible

4. Configure the roster + preset: collaboration-team section in settings.yaml (see below); copy config/agent-presets/collaboration into ~/.dsh/.agent-presets/ (on Windows: %USERPROFILE%\.dsh\.agent-presets\).

5. Restart DSH → start a new conversation on the Collaboration preset → done.

Roster configuration

collaboration-team:
  agents:
    - { id: main, name: 主代理, role: Coordinates and dispatches specialists }
    - { id: planner, name: 规划师, role: Breaks goals into steps, provider: deepseek-official, model: deepseek-v4-flash }
    - { id: reviewer, name: 审查员, role: Reviews code and designs, provider: deepseek-official, model: deepseek-v4-flash }
    - { id: looker, name: 观察员, role: Vision analysis, provider: zhipu, model: glm-4v-flash }

• provider = a provider ID added in the official Models page; empty = follow the session model (chat-box selector)
• Give vision identities (e.g. looker) a vision-capable model, or image tasks fail at runtime
• Changes apply live — no restart needed

Usage examples

Development

pnpm install      # install dependencies
pnpm typecheck    # typecheck all packages
pnpm build        # build

Validation

node scripts/e2e-tools.mjs     # drives each tool package's apply() in a fresh process (mirrors preset mount checks)
node scripts/e2e-team-host.mjs # drives the team host service: instance lifecycle + team_help relay
node scripts/check-roster.mjs  # validates the collaboration-team roster in settings.yaml

Isolated e2e in Docker (browser + throwaway DSH)

docker compose up --build --abort-on-container-exit e2e

Boots a throwaway DSH web instance inside a container — its whole DSH_HOME lives under /dsh-home, so no real profile, session store, or preset roster is ever touched. The same container then runs the host-side scripts plus the image-inbox paste-bridge browser verification on a Linux chromium (a single container is required because dsh web binds only 127.0.0.1; on Windows the script keeps using the system Edge — override the channel with DSH_E2E_CHANNEL). Screenshots and console dumps land in .e2e-artifacts/. The exit code is the e2e result — CI runs this job on every push.