DeepSeek开源Router-Worker架构编程Agent

The DeepSeek Harness team just released dsh-superagent, an MIT-licensed research prototype. DeepSeek dsh-superagent is a proactive coding agent for one GitHub repository. It is packaged as a bundle for DeepSeek Harness. It listens to GitHub and, optionally, Feishu. It turns allowed requests into parallel work items, each in its own agent session. The release shipped alongside a design post, Exploring Super-agent Design: Towards a More Autonomous Agent System.

• What is it?: A TypeScript bundle, v0.1.0, released as 1 commit under MIT. It uses whatever model the Harness profile is set to.
• Runs on: Your own machine, as a dedicated DeepSeek Harness profile. Needs Node.js 22.19+ or 24+, git 2.32+, Python 3.8+, tmux and GitHub CLI 2.48+.
• Performance: In DeepSeek’s simulation, it finished tasks far faster under a noisy message stream than a single-session agent.
• Best: p95 task completion of 15.7 minutes vs 29.5 minutes for the single-session baseline (about 1.9x faster).
• Worst: Tested only on synthetic messages and simulated tools. Real coding quality was not measured.

What is DeepSeek dsh-superagent?

It is a GitHub agent that waits to be asked. When an allowed person addresses it, it opens a work item, called a Ticket. Each Ticket runs in its own session and directory. Results return to the original conversation, often as a pull request. A local web panel lists only what needs a person.

The README page states the core rule plainly: take as little human attention as possible, and give as much value as possible. The philosophy doc applies it to behavior. The agent confirms once, stays quiet while working, and writes again only with a result, a question or a failure.

Why did DeepSeek build a Super-agent?

DeepSeek team argues that mainstream agents treat 1 session as the basic unit. According to the report, as reported by ifeng, a person can actively follow only 3 to 5 sessions at once. Human attention, not model capability, becomes the bottleneck for multitasking.

How does the Router-Worker architecture work?

The research team describes 2 layers. A long-running Router handles interaction and dispatch. Isolated Worker sessions do the actual work.

In the prototype, that flow is concrete, per the domain model:

• Source → Trigger: GitHub or Feishu produces events.
• Eval: decides whether a batch of Triggers asks for new work.
• Ticket: a unit of authorized work, with an immutable Mandate stating why it may proceed.
• Subscription: later comments on a pull request reach the right Worker without a fresh mention.

The main session runs the dsh-superagent-router preset with a smaller tool set. Each Worker runs dsh-superagent-worker. Shell commands move to the background after 5 seconds, so Workers keep receiving messages, per the execution doc.

Proactive work is gated. The authorization doc defines 3 accept modes: off, observe (default) and auto. In observe, the agent only records what it would have accepted.

The research team also lists ideas beyond the prototype: an external Watchdog, storage and compute separation, and an asynchronous ReAct loop.

How does it perform?

DeepSeek tested with simulated group chat and GitHub CI streams. Each run had about 300 messages, of which about 20 were real work requests. Each scheme ran 5 times, per ifeng’s account of the report.

• Super-agent: p50 of 12.4 minutes, p95 of 15.7 minutes.
• Single session plus subagents, neutral prompt: p95 of 29.5 minutes. No p50 was given.
• Why: under the neutral prompt, the baseline called a subagent 0 times in 5 runs.
• Router load: as arrivals rose from about 1 to 40 per minute, batch size grew from 1.0 to 2.8. Per-request latency rose from 2.5 to 3.9 seconds.

An ablation removed direct event pass-through. Router decisions rose about 30%, and cache-read tokens rose about 37%, from 23.23M to 31.77M. All figures are self-reported and come from secondary reports of the report.

How does dsh-superagent compare with other GitHub coding agents?

Key Takeaways

• DeepSeek released dsh-superagent, an MIT-licensed proactive coding agent prototype.
• A Router dispatches work; isolated Worker sessions execute each Ticket.
• Simulated p95 task time: 15.7 minutes vs 29.5 minutes for a single session.
• Proactive work stays in observe mode until a team switches it on.
• It runs with full OS-user access, so isolate it before use.

Check out the GitHub repo, the setup guide and the design docs. Also, feel free to follow us on Twitter and don’t forget to join our 150k+ML SubReddit and Subscribe to our Newsletter. Wait! are you on telegram? now you can join us on telegram as well.