dsh-superagent

dsh-superagent is suitable for reading designs and doing experiments, and is not recommended for directly hosting production repositories; it is advisable to start in observation mode and let the agent first prove that it will not cause trouble before discussing automation.

The core principle of dsh-superagent is to occupy as little human attention as possible: it acts only when requested or permitted by rules, asks only one specific question at a time, and decides whether to stop based on the scope of impact rather than the amount of work.

The dsh-superagent chain contains seven core concepts: source, trigger, thread, evaluation, borrowing, authorization and dispatch.

A trigger in dsh-superagent is an immutable event; the same event can belong to multiple threads, but the event itself cannot be modified.

Evaluation in dsh-superagent is divided into two steps, admission and assessment: admission first performs rule filtering, and assessment then performs intent understanding and impact evaluation, outputting one of four conclusions: borrow, stop, ignore or incomplete.

The authorization mechanism of dsh-superagent has three layers: the allowlist determines who can initiate, the admission table determines how to handle cases when no one is named, and accounts in the bot list can only produce inferred candidates and cannot initiate explicit requests.

The borrowing modes of dsh-superagent are observation and automatic; by default it starts in observation (dry-run), recording only what it would have taken on without actually executing, and switches to automatic mode after confirming that the records are correct.

In dsh-superagent, each work order has its own session and directory (usually a Git worktree); commands in the executor that exceed five seconds are converted into background tasks, and background tasks run for at most thirty minutes before being terminated.

The dsh-superagent engine is the sole writer for triggers, ready-made decisions and work order dispatch; each command is one transaction, side effects enter a persistent queue and support retries on failure, and the entire state is kept in a local database.

The executor of dsh-superagent runs as an operating system user, with very weak isolation; once it runs a malicious or erroneous command, the scope of impact is the entire user environment.

dsh-superagent is a research prototype rather than a product; much of the code is generated by agents and its style is inconsistent, the database only grows and never deletes so it will grow larger over long-term operation, and it cannot be downgraded after an upgrade.

DeepSeek's open-source proactive agent project is named dsh-superagent, which has gained 11,700 stars on a code hosting platform but has only one commit.

The goal of dsh-superagent is not to build a chatbot or code completion, but to let an agent stay stationed in a repository for the long term, turn permitted requests into work orders, and send the results back to the original conversation after execution.

dsh-superagent does not support enterprise code hosting platforms; it connects only to public SaaS endpoints and cannot connect to enterprises' self-built instances or privately deployed versions.

In DeepSeek's own simulated tests, dsh-superagent's p95 task completion time dropped from 29.5 minutes to 15.7 minutes.

dsh-superagent adopts a router-worker architecture: the router understands requests, decomposes tasks, and distributes them to multiple workers for parallel processing.

dsh-superagent is positioned not as IDE completion, but as connecting requests in collaboration tools into an agent pipeline.

On the multi-worker coding agent path, key issues such as the router's task decomposition accuracy and worker conflict handling are not yet clear in dsh-superagent's public information.

dsh-superagent converts requests from GitHub and Feishu into worker sessions that execute in parallel.

The core architecture of dsh-superagent is a resident design that separates the Router from the Worker.