DeepSeek's dsh-superagent Is a Harness Prototype, Not a Product

The repo name ends in prototype, and the README's first line nails the boundary: "Research prototype for reference only, not an official DeepSeek product." That is not humility—it is product law. deepseek-ai/dsh-superagent-prototype landed on GitHub on October 31 under MIT from the DeepSeek Harness Team; by about 23:50 Hong Kong time that night it sat near 1095 stars / 88 forks. What shipped is a reference implementation, not a DeepSeek SuperAgent you can buy on a pricing page.

Three misreads travel with every screenshot. First: treating it as a shipped agent product—the org says it is not. Second: assuming it mirrors the essay Exploring Super-agent Design: Towards a More Autonomous Agent System—the README says the public tree was adapted, differs from the internal build and from the article, and some designs in that piece are future work not implemented here. Third: hearing "company-wide automated teammate"—it binds to one GitHub repository, with optional Feishu. Not a multi-repo orchestrator. Not a general desktop controller.

What it actually does, without the marketing fog: a proactive coding agent packaged as a DeepSeek Harness (DSH) bundle. When someone on the allowlist asks for work—or a team-written rule permits it—it opens a Ticket, works in its own agent session and directory, and answers in the original thread, typically with a PR. A web panel surfaces only what still needs a human; healthy state takes no space. docs/000 states the bar in one line: take as little human attention as possible, and give as much value as possible. An agent that can act for a whole team can also waste a whole team's attention, so it moves only when addressed or a written rule allows it, and speaks only when someone must act or can use a result.

Stop calling the guts "multi-agent soup." The host path is Router + Worker: the main Session preset is dsh-superagent-router (Eval, accept, dispatch); the execution side is dsh-superagent-worker—one Session and one directory per Ticket, commands as the operator's OS user, no approval prompts by default. The docs warn you themselves: do not hang this on a daily laptop full of SSH keys and cloud credentials. Events hit Source filtering first (the bot's own messages and out-of-scope noise drop), then Thread / Eval / Mandate / Ticket / Assignment. Side effects ride a durable Effects queue: enqueue inside the transaction, send / launch / deliver after commit. The Engine writes domain state synchronously; the Store is a separate SQLite—compute and storage split, async work on the queue, not one chat loop doing everything.

Developers only need a short checklist today: under deepseek-ai, MIT, labeled a Harness research prototype; do not build production mental models as if it were SaaS; to try it, have your own coding agent walk SETUP.md one short question at a time, start with a tight allowlist, and keep proactive work record-only until the would-have-done trail looks sane. Anyone still posting "DeepSeek launched SuperAgent" mostly skipped the first paragraph of the README.