DeepSeek Harness’s team extracted part of the “more autonomous coding agent” they use internally into a public prototype: dsh-superagent (repo dsh-superagent-prototype). It runs on DeepSeek Harness, scoped to one GitHub repository: it listens on GitHub (optional Feishu/Lark), opens a ticket when someone asks per the rules, works in an isolated Session / directory, then returns to the original thread — for example a comment reply or a PR. A web panel surfaces items that need a human.
The docs are blunt: this is a research prototype for reference only, not a product. Code style and engineering quality may be uneven, and the release is not the full internal system or everything in the essay Exploring Super-agent Design: Towards a More Autonomous Agent System. License: MIT. Repo: deepseek-ai/dsh-superagent-prototype. Researched November 3, 2026 (about 13.1k★ at check time).
At a glance
| Item | Details |
|---|---|
| Type | Coding Super-agent research prototype on DeepSeek Harness (single repo) |
| Version | Package dsh-superagent 0.1.0; needs a DSH that satisfies engines.dsh (docs pinned @deepseek-ai/[email protected] when checked) |
| License | MIT |
| Stars | About 13.1k when checked |
| Runtime | Node.js 22.19+ / 24+, pnpm, git 2.32+, tmux, Python 3.8+, GitHub CLI 2.48+; optional Feishu lark-cli |
| Sources | GitHub (required direction); optional Feishu/Lark chat |
| Shape | Dedicated DSH profile (docs call it superagent) + admin panel; Router / Worker Session presets |
| Repo | github.com/deepseek-ai/dsh-superagent-prototype |
What problem it targets
README in one line: take as little human attention as possible, deliver as much result as possible. An agent that can act for a whole team can also burn a whole team’s attention — so by default it only moves when named, or when team rules allow; it speaks again when a human decision or a usable result is needed. Philosophy: docs/000-philosophy.md.
Unlike “you open Claude Code / Codex and babysit a terminal round”, this is closer to a repo-level on-call: requests arrive from Issues / comments / (optional) Feishu, the main Session (Router) decides whether to take the job, Workers execute in isolated sessions, and results write back to the same channel.
How to read the architecture (skip the class names)
The domain flow in the docs:
Source → Trigger → Thread → Eval → (if accepted) Ticket + Mandate → Assignment → Executor → write back to Source via Channel
For day-to-day reading, four blocks are enough:
- Source: shipped as GitHub (notifications, watched Issues/PRs, CI changes, …) plus optional Feishu. External events become immutable Triggers hung on a Thread.
- Eval: the main Session does two layers — first a Gate (who may initiate; explicit request vs inferred candidate), then a policy judgment that yields a Decision (accept / stop / ignore / incomplete). Accept creates a Ticket with a Mandate.
- Executor: each Ticket gets its own Executor Session and workdir (
DshExecutor); multiple Workers can run in parallel (capped bymaxWorkersetc.). Progress, blockers, and questions come back as structured Reports; human decisions land in the panel’s “needs human” queue. - Policy + Panel: allowlists, bot lists, admission tables, accept mode (docs suggest starting from
observe— “would accept but do not really”) live in versioned policy; the panel shows tickets, source health, settings, and prompts.
Under the hood there is also an Engine, SQLite Store, Effects queue, and more — see docs/007-architecture.md. What matters more for operators: authorization lives in host policy, not in chat text — comments or quotes cannot rewrite who may open tickets.
Install (official path)
Setup is deliberately “have your existing coding agent walk you through it”. After cloning, tell it:
Read SETUP.md in this repository and set up dsh-superagent with me.
SETUP.md asks the agent to ask one short question at a time, collect answers, then propose a full plan and only execute after you confirm. Secrets are not requested in chat; steps that need a local terminal login are listed separately.
The manual main path in the docs (prefer the repo’s then-current docs/006-deployment.md) looks like:
- Prep deps: Node / pnpm / git / tmux / Python /
gh; configure DSH model providers. - Create a separate GitHub account for the agent (do not use your daily personal account as the agent identity); log in with a wrapped
ghthat uses its ownGH_CONFIG_DIR. Optionally wire a Feishu bot andlark-cli. - Install (pinned versions from the deployment doc when checked):
npm install -g @deepseek-ai/[email protected]
git clone https://github.com/deepseek-ai/dsh-superagent-prototype.git dsh-superagent && cd dsh-superagent
pnpm install && pnpm build
dsh superagent --from-default-profile web --dump-config > /dev/null
dsh plugin --profile superagent add "link:$PWD"
4. Write a cordis.patch.yml from the examples (stateDir, ports, …), then:
scripts/dsh-superagent start
scripts/dsh-superagent status
Open the panel sidebar → Superagent. Fill in who may call it; with an empty allowlist, requests never become Tickets. Smoke test: from an allowlisted account, comment @agent-account on a repo Issue — within about a minute the Overview should show a ticket.
Before upgrades, back up orchestrator.sqlite under stateDir; a DB migrated to a newer schema cannot be opened by older versions.
How it sits next to Claude Code / Codex
| Dimension | Claude Code / Codex (day-to-day) | dsh-superagent |
|---|---|---|
| Typical use | You drive a terminal / IDE: edit, run, iterate now | Repo on-call: Issue/comment/Feishu → eval → isolated work → reply/PR |
| Shape | Vendor CLI / subscription product | DSH plugin-style research prototype (MIT); you bring models + Harness |
| Multi-task | You open and babysit sessions | Router assigns; many Workers in parallel; panel queues human needs |
| Auth model | You watch the session and permission prompts | Policy: allowlist, admission, accept mode, Mandate; chat cannot change rights |
| Maturity | Finished daily coding experience | Officially a research prototype, not production-ready |
One line: Claude Code / Codex is “you drive”; dsh-superagent is “an auditable on-call orchestrator hung on the repo”. For local model switching and quota views for Claude Code / Codex, see Magpie and QuotaPanel; the wider map is AI coding agent ecosystem (EN pending). For a “pick a folder + plain language” desktop shell also on DSH, compare PawWork (EN pending).
Safety and boundaries (read first)
- Research prototype: expect bugs; review and rewrite before anything production-shaped.
- Privilege tier: Worker / Router presets run as the operator OS user per the docs, with a
danger-full-access-style high-privilege stance; process isolation is not account isolation. Docs suggest a dedicated OS account that only holds agent credentials for sensitive setups. - What it can reach: Workers can run programs by path and read the operator home directory, etc. — the boundary is how you deploy, not a “please be careful” chat line.
- Who may open tickets: only Source policy allowlists and admission; start narrow +
observeto learn behavior before consideringauto. - Agent identity: every comment / branch push / PR on GitHub is under the agent-only account; do not bind your personal primary account.
- Secrets: SETUP forbids asking for secrets in chat; CLI login, Feishu app secrets, etc. stay in the local terminal.
- Enterprise GitHub: docs target github.com; GitHub Enterprise Server is not supported.
Who it is for (and not)
Good fit: already on (or willing to install) DeepSeek Harness; want Issue/comment-driven, PR-capable repo agents; fine managing your own model bill, machine, and policy; want to read an open implementation against Super-agent design write-ups.
Poor fit: just want an app that codes out of the box (prefer Claude Code / Codex / a desktop shell); cannot accept a high-privilege local agent; need GitHub Enterprise Server or turnkey SaaS ops.
Entry: repo · have an agent read SETUP.md first · numbered docs from docs/000-philosophy.md in order. Versions and install pins follow the November 3, 2026 README / SETUP / 006-deployment.
