DeepSeek open-sourced an Agent that will work through GitHub Issues, and by default gives you only 3 workers
It watches a repo, picks up work from Issues and PRs, and a Router distributes it to parallel Workers. By default there are 3 worker slots, up to 16, plus 1 reserved for humans. The comments first worry about the review queue.
DeepSeek open-sourced an Agent that will work through GitHub Issues by itself. By default it opens only 3 worker slots, up to 16, and reserves 1 more for human messages. That number is more interesting than the slogan.
The project is called dsh-superagent-prototype, is MIT-licensed, and DeepSeek says it is a research prototype, not a product. It comes from the DeepSeek Harness team. Usage is very specific: watch a GitHub repo, with optional Feishu group integration. People on the allowlist submit requests, it opens a work item, does a first version, drafts a fix, and then hands the result back to humans for Review. The repo is at deepseek-ai/dsh-superagent-prototype. Leandro von Werra posted about it on X, and AGTP then gave a more complete breakdown.
The documentation screenshot says it plainly: GitHub and Feishu trigger events, a deterministic gate first checks whether the sender is on the allowlist, the main session Router decides to accept, stop, ignore, or unavailable, and then creates a ticket with immutable instructions. Each ticket has its own worker session and directory, and results return to the same thread.
AGTP's tweet describes the architecture more fully: a persistent Router plus multiple parallel Workers, with triggers including group chats, email, calendar reminders, GitHub comments, and CI test results. It is online 24/7 and takes on work by itself. DeepSeek Harness engineer Yujia Qiao wrote the design article “Super Agent: Proactive Is All You Need?” The article first circulated domestically, a community English translation appeared a few hours later, and the official English version was said to be coming soon.
Key limits are in the documentation:
| Item | Limit |
|---|---|
| Worker slots | Default 3, max 16, plus 1 extra reserved for human messages |
| Evaluation timeout | Default 120 seconds, adjustable from 30 to 600 seconds |
| Ticket preparation command | Max 10 minutes |
| Background work | Max 30 minutes after each poll |
| Worker shell moves to background | After 5 seconds |
| Idle subscription thread query range | 14 days |
| Input retry delay | 2 seconds, doubling up to 60 seconds |
These numbers are more useful than slogans. It treats human attention as the ceiling and then adds guardrails to that ceiling: one ticket, one worker; timeouts; rules for pulling people in. However strong the model is can be set aside; making the boundaries clear is more important.
Community reaction is split into two camps. Supporters see a software factory and feel the repo is one step closer to self-maintenance. Opponents first do the math: more workers just means more prs to read. Some worry that if two agents touch the same file, the second PR will need to be rebased. Some ask whether the prototype will route overlapping PRs through a coordinator, or let them collide first and then resolve. Others say many agents handling Issues and PRs in parallel sounds great—until one tired person has to review them all.
Someone directly posted a Simpsons video of someone shouting “Stop,” captioned “job market.”
The more parallelism there is, the more conflicts and the Review queue look like the new bottleneck. DeepSeek wrote the default 3 worker slots into the docs—at least it isn’t pretending humans don’t exist. If you want to try it, start with a small repo. Don’t hand all the repo’s Issues to 16 workers right away.
发布时间: 2026-11-01 17:38