What Is DeepSeek DSH Super-agent? Router + Worker Architecture Explained (2026) | HackAIGC
What Is DeepSeek DSH Super-agent? Router + Worker Architecture Explained (2026)
DeepSeek DSH Super-agent (repo: dsh-superagent-prototype) is a research prototype from the DeepSeek Harness team for a more autonomous coding agent. It uses a Router + Worker dual-layer design: one main session routes and talks to people, while isolated worker sessions execute tickets in parallel. The team published the design notes and an open MIT prototype around October 31, 2026. It is not an official DeepSeek consumer product.
If you landed here looking for uncensored chat or jailbreaks, that is a different topic — see our DeepSeek V4.1 Flash abliterated GGUF explainer and How to jailbreak DeepSeek 4.1. This piece is about the agent architecture.
TL;DR
- What it is: a proactive coding agent bundle for DeepSeek Harness, scoped to one GitHub repository (optional Feishu), with a web panel for items that need a human.
- Architecture: Router (main session) handles interaction, policy, and dispatch; Workers run isolated sessions/directories per Ticket.
- Design goals: continuous, efficient, proactive, and persistent — summarized as “Super-agent” traits in DeepSeek’s design exploration.
- Status: MIT research prototype; the README states it is for reference only, may differ from the internal system and the design article, and is not production-ready.
- Soft next step if you want open-ended creative chat instead of agent ops: HackAIGC chat.
What “DSH Super-agent” means
| Term | Meaning |
|---|---|
| DSH | DeepSeek Harness — DeepSeek’s agent/runtime tooling surface |
| dsh-superagent | The Super-agent bundle / research prototype |
| Router (main Session) | Evaluates triggers, accepts/dispatches tickets, replies to people |
| Worker (Executor Session) | Runs one Ticket in its own session and work directory |
| Ticket | A unit of authorized work created after Eval accepts a trigger |
| Trigger / Thread | Events from Sources (e.g. GitHub, Feishu) grouped into threads |
The official framing in the GitHub README is blunt: treat it as research code, not a shipped DeepSeek product. Some ideas in the design article are future directions and are not implemented in the published prototype.
Why DeepSeek framed a “Super-agent”
Coverage of the DeepSeek Harness team’s design exploration (Exploring Super-agent Design: Towards a More Autonomous Agent System) and secondary reporting (e.g. IT Home via AIHOT, Oct 31, 2026 Asia/Shanghai) emphasize a shift in the bottleneck: as single-task agents need less babysitting, human attention becomes the scarce resource.
They contrast typical single-session agents — independent sessions you juggle by hand — with a system that stays online, fans work out, and speaks only when a person must act or can use a result. The prototype’s philosophy doc puts it as: take as little human attention as possible, and give as much value as possible.
Four traits they highlight
- Continuous — one agent across channels (e.g. IM and GitHub comments) on the same work.
- Efficient — multiple complex tasks in parallel via workers.
- Proactive — observe environment events and advance work the team’s rules allow.
- Persistent — stay online and recover from failures over long runs.
Router + Worker: how the dual layer works
Router layer (main session)
The Router is the orchestrator. In the published docs it:
- Ingests Triggers from Sources (GitHub notifications/issues/PRs/CI; optionally Feishu).
- Runs Eval (gate + assessment) under a versioned Policy (who may request work, what rules apply).
- Creates Tickets with a Mandate when work is accepted.
- Replies on the original conversation / channel (comments, PRs, etc.).
- Uses a smaller routing tool set (
dsh-superagent-routerpreset) so it does not block forever on long shells.
Worker layer (executor sessions)
Each Ticket gets:
- An Executor Session (worker) and its own directory under an execution root.
- The
dsh-superagent-workerpreset with work tools (file, search, shell, jobs, web, skills, todos, subagents). - Isolation from other tickets so concurrent work does not smash one shared context.
Workers report progress/outcomes to the Router; they are not the primary voice to humans. Background jobs and subagents can keep a ticket “working” after a turn; docs describe wait limits (e.g. background work capped on the order of 30 minutes per turn before jobs are killed and the ticket is reported waiting — verify against current docs/003-execution.md if you operate it).
Event-driven flow (simplified)
| Stage | What happens |
|---|---|
| Source | Emits Triggers (messages, PR comments, CI results, …) |
| Thread | Orders related Triggers; serializes Eval on that thread |
| Eval | Gate + model assessment → accept / ignore / stop |
| Ticket + Mandate | Authorized unit of work |
| Assignment → Worker | Isolated execution |
| Channel | Writes results back (comment, PR, …) |
Related events for a subscribed Thread can fan out directly to a Worker, so not every follow-up must re-enter the Router — a load-reduction detail called out in both the architecture docs and secondary coverage.
What the open prototype actually does
Per the README:
- Listens to GitHub and optionally Feishu.
- When an allowed person asks for work, opens a work item, runs it in its own session/directory, and answers in the original conversation (for example with a pull request).
- Shows a web panel for items that need a person.
- Acts only when asked or when a written team rule allows proactive work; speaks when someone must act or can use a result.
Setup is intentionally agent-assisted (SETUP.md). Development check: pnpm check (typecheck, tests, build). License: MIT.
As of early November 2026 the public repo was actively watched (star counts move fast; check GitHub live rather than quoting a single snapshot as capacity or “API quota”).
What DeepSeek’s early experiments claimed (with caveats)
Secondary reporting of the design article describes synthetic-load experiments (~300 messages, ~20 work requests, 5 runs) comparing Super-agent variants vs single-session + subagent setups. Reported Super-agent completion-time p50 / p95 figures around 12.4 / 15.7 minutes vs higher p95 for a neutral single-session baseline were cited in that coverage.
Caveats we keep:
- Those runs are synthetic / simplified and measure scheduling & collaboration, not quality of a single coding task.
- The prototype ≠ the internal Harness Super-agent instance DeepSeek says already runs on their own Harness work.
- We do not invent API quota numbers, production SLAs, or NSFW/jailbreak angles for this topic.
Who should care
Team leads trying multi-ticket coding agents
If your pain is “too many sessions / too much attention tax,” Router+Worker is the interesting pattern: one conversational front door, many isolated executors.
Builders on DeepSeek Harness
The prototype is a bundle meant to be read, adapted, and operated carefully — allowed lists, policy, and operator responsibility are first-class.
People searching “DeepSeek uncensored”
Wrong shelf. This project is about autonomous software agents, not content filters. For hosted adult/creative chat, use a purpose-built tool like HackAIGC. For local abliterated weights context, see the V4.1 Flash abliterated GGUF explainer.
Open questions DeepSeek itself flags
Design write-ups call out unfinished work: Router scaling with task load, long-horizon memory across months, collaboration UX outside a session, agent-to-agent (A2A) communication, and security/privacy when a cloud agent reaches a local machine (prompt injection, endpoint credentials, cross-device permissions).
FAQ
What is DeepSeek DSH Super-agent?
It is a DeepSeek Harness research prototype for a proactive coding agent that uses a Router session plus isolated Worker sessions per ticket. The public repo is deepseek-ai/dsh-superagent-prototype.
Is DSH Super-agent an official DeepSeek product?
No. The README states it is a research prototype for reference only, not an official DeepSeek product, and not production-ready.
What is the Router + Worker architecture?
The Router (main session) handles human interaction, policy evaluation, and dispatch. Workers (executor sessions) run accepted tickets in isolated directories and report back; the Router speaks to people.
Does it replace Claude Code / Cursor / other coding agents?
It is a Harness-oriented architecture and open prototype for team-scoped, event-driven GitHub (and Feishu) work — not a drop-in consumer chat app. Compare on workflow fit, not marketing names.
Is this related to DeepSeek jailbreaks or NSFW chat?
No. Collision-wise this post is separate from DeepSeek jailbreak and abliterated-weight explainers. Super-agent is about autonomy and orchestration.
Bottom line
DeepSeek DSH Super-agent is the Harness team’s open look at a Router + Worker Super-agent: continuous multi-channel interaction, parallel isolated execution, proactive rules, and long-running persistence — published as research, not as a polished DeepSeek SKU. Read the docs in order on GitHub, treat quotas and internal metrics from secondary posts with care, and keep creative/uncensored chat on tools built for that job, such as HackAIGC.
Sources: deepseek-ai/dsh-superagent-prototype, DeepSeek Harness, AIHOT item (IT Home summary), prototype docs 000–007 (philosophy, domain, authorization, execution, architecture).