dsh-superagent: DeepSeek's Proactive GitHub Agent, Reviewed

In one sentence: DeepSeek published dsh-superagent on 2026-10-31 — an MIT-licensed research prototype that turns one GitHub repository into a work queue for an agent: it listens to GitHub (optionally Feishu), opens a Ticket for each authorized request, works in its own session and directory, and answers in the original thread with a pull request. The README states plainly that it is not an official DeepSeek product, and it cannot be installed by package name.

31 Oct 2026
Repository created and published
MIT
Licence, in the README and package.json
0.1.0
Version; package.json is marked private
9 docs
Design documents 000–008, read in order
See the install commands Read the design

What the official repository actually says

Every row below can be checked against the repository or its docs; read on 31 October 2026. The README also says the code was adapted for publication, so it is not identical to the internal version or to the implementation described in the article Exploring Super-agent Design.

Item Official value Where it says so
Repositorydeepseek-ai/dsh-superagent-prototype — "Towards a More Autonomous Agent System"GitHub repo page
Created / default branch2026-10-31T09:32:46Z, mainGitHub API metadata
LicenceMITLICENSE + package.json
Version / publishability0.1.0, "private": true — not an npm-installable pluginpackage.json
Author fieldDeepSeek Harness Team <[email protected]>package.json
Package shapeDSH bundle: dsh.bundle.patch → ./cordis.patch.yml; a web client; entries ., ./client, ./github-watch, ./feishu-watchpackage.json exports
Languages in the treeTypeScript, Python, CSSGitHub language bar
Docs / prompts / skills9 numbered docs (000–008), 14 prompt files, 2 bundled skills (dsh-superagent-github, dsh-superagent-feishu)Repository tree
Runtime enginesNode ^22.19.0 || >=24.0.0; dsh ^0.2.1-alpha.2; pnpm 11.7.0package.json engines
Two runtime dependenciesproper-lockfile 4.1.2, zod 4.4.3package.json dependencies
Check commandpnpm check = typecheck + tests + buildREADME + package.json scripts
Stars at publication373 stars, 29 forks, 0 open issues (snapshot, moves daily)GitHub repo page, 2026-10-31

What it is not, in the repository's own words

"Research prototype for reference only, not an official DeepSeek product." The README adds that much of the engineering was done by coding agents, that its style and practices may be inconsistent, and that you should review and adapt it before use. It also notes that some designs discussed in the article are future directions and are not implemented in this prototype.

What happens to one request

The order comes from docs 001 (domain model), 002 (authorization) and 003 (execution). Steps 2 and 3 are the whole point: a message being written is not enough to start work — it has to pass a gate and an assessment.

  1. A Source produces a Trigger — GitHub (notifications, subscribed issues and pull requests, CI changes, merges and closes) or Feishu (live events, history recovery, polling). A Source keeps its own read position, so a restart does not replay events.
  2. The gate checks who is asking — An allowed person addressing the agent directly is an explicit request; a bot on the Source's bot list can only produce an inferred candidate, never an explicit request; other people go through the admission table.
  3. Eval decides — There are exactly four decisions: accept, stop, ignore, unavailable. Only an accept creates a Ticket, and it carries a Mandate that records the Policy version it relied on.
  4. Assignment: one Ticket, one Executor Session, one directory — Executor Sessions are named worker-<ticket id>, with a directory named after the Ticket's short name under the execution root (default <stateDir>/work), created as a worktree from a local clone.
  5. The result goes back to the original conversation — Writes go out through a Channel: Feishu topic replies, GitHub comments, review-thread replies — for example as a pull request. Until a person acts, the result waits in the panel; it does not chase people with messages.
  6. Later discussion needs no second mention — On a thread a Ticket subscribes to, new messages fan out to it as context — including bot and CI messages — but that path bypasses the gate and grants no new authority; the Ticket stays bound by its Mandate.

Nine concepts, one rule each

Doc 001 is explicit that the code, the tools the agents call, the panel and the other documents use these terms and no others. Learning this table before the architecture diagram saves time.

Concept What it is The rule it keeps
Source一个事件流;一种可复用的实现(GitHub、飞书)加一份实例配置自己持有读取位置和机器人身份;重启不重放
Trigger一个不可变事件,带来源自己的元数据(如发起人)同一个 Trigger 接受两次只产生一张工单
Thread按时间排序的 Trigger;由 Source 决定哪些归为一串同一线程同一时间最多一个 Eval 在跑
Channel线程的「写」这一侧:话题回复、评论、PR一个线程可以有多个 Channel,一张工单持有一组
Policy带版本的研判规则,加上每个 Source 的部分(谁能发起、机器人名单)规则变了要给进行中的工单送通知,但不撤销已发的 Mandate
Eval对一批 Trigger 的判断,两层:准入闸门 + 模型研判不持有状态;输入包含线程快照、所有工单和当前策略
Mandateaccept 授予的东西:策略版本、范围、强度、匹配规则、发起人身份不可变;范围变大=开新工单;只有人能撤销
Ticket一个被授权的工单位只有 Eval 能创建;人停止后不再接收任何输入
Assignment工单与一次执行器实例的绑定pending → running → ended,和工单状态互不跟随
Value group Possible values
Decisionaccept · stop · ignore · unavailable
Strengthexplicit · inferred
Assignmentpending · running · ended
Reportprogress · waiting · ready · blocked · failed · dropped

What you can reuse, and what you must deploy yourself

Doc 001 ends with a reusability table: the concepts and their rules are reusable, while the Source implementations, Policy contents, Executor and Channel implementations belong to a deployment. In practice that means four things to fill in before it works on your repository: Sources, Policy, execution environment and Channels.

Requirements, from the 006 deployment guide

This is not a plugin-sized install: it wants its own profile, its own GitHub account, and a local clone it can add worktrees to.

Two ways in

The official route is either to let a coding agent walk you through it (recommended) or to run the block from 006 yourself. The commands below are copied from 006 and the repository root, with nothing added.

  1. Route one: let an agent do it — The README's instruction is to ask your coding agent to read SETUP.md and set it up with you. It asks one short question at a time (Feishu or not, which repository, which account, who may ask for work), shows the full plan once, and installs only after you confirm.
  2. Route two: the manual block
    npm install -g @deepseek-ai/[email protected]
    git clone <this repository> 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"
  3. The steps only the operator can do — Create the agent account, accept the repository invitation, run auth login for each wrapper, and on the Feishu side create and publish the bot app and run config init. Afterwards, check each login with <wrapper> api user --jq .login.
  4. First test: mention it in an issue — From an account on the allowed list, comment @<agent login> <request> on an issue in the repository; a Ticket appears on the overview within about a minute.

Limits the documentation states itself

This page does not decide for you whether to run it; it only pulls out the lines in the official docs that get skipped but do matter.

The permission model is "an OS user just like you"

Nine documents, read in order

The docs require that each one builds only on the ones before it, so a reader never meets a concept that has not been introduced. Skipping around is how people get stuck.

Document The question it answers
000 Philosophy为什么它要「少占注意力」;对操作者的责任要求是什么
001 Domain model九个概念、各自守的规则、哪些概念被明确拒绝
002 Authorization谁能发起工作;follow-up、订阅、交回与释放怎么算
003 Execution一张工单从执行到交付、恢复的全过程
004 Prompts哪些提示词是团队可改的部分
005 Panel面板只显示「需要人」的东西
006 Deployment账号、启动检查、升级与排错
007 Architecture类、接口、文件与测试的索引
008 Cookbook怎么加一个新的 Source

FAQ

Is it an official DeepSeek product?

No. The first line of the README is "Research prototype for reference only, not an official DeepSeek product." It grew out of the team's day-to-day work with much of the engineering done by coding agents, and the repository asks you to treat it as research code.

Can I install it as a package name, like a plugin?

No. package.json is private: true at version 0.1.0. Doc 006 clones locally, runs pnpm install && pnpm build, then dsh plugin --profile superagent add "link:$PWD" into a dedicated profile created from the Web template.

Do I have to wire up Feishu?

No. The README says it listens to GitHub and, optionally, Feishu. With GitHub only, limit Sources to GitHub; Feishu additionally needs lark-cli (documented at 1.0.90) and a Feishu app with a bot.

Will it act when nobody asked?

Only where a rule the team wrote allows it, and that kind of work starts in a mode that only records what the agent would have done. The stated discipline is that it acts only when asked or when a written rule allows it, and a bot can only produce an inferred candidate, never an explicit request.

What does it cost to run?

The repository publishes no pricing or token budget; it says only that it uses the profile's default model unless the Eval or Execution settings name another. Cost therefore depends on your own model configuration and on how wide your Policy is — more allowed work means more spend.

How does it relate to the Exploring Super-agent Design article?

It is the public prototype of that design, but the README says explicitly that the code was adapted for publication and is not identical to the internal version or to the implementation the article describes; some designs in the article are future directions that this prototype does not implement.

Sources & Updates

Every fact on this page was read from the primary sources below on 31 October 2026: the repository page, README, package.json and the numbered documents. Versions and engine requirements change — check the official repository before you start.