DeepSeek Super Agent GitHub 部署教程：首次启动 exit 3 是正常的

GitHub 上的 DeepSeek Super Agent，指的是 DeepSeek 在 2026 年 10 月 31 日开源的 dsh-superagent-prototype 仓库。它是 DeepSeek Harness（DSH）的一个插件包：盯住一个 GitHub 仓库（可选再接飞书），只接名单里的人派的活，每张工单在独立的 Session 和目录里做完，再回到原来的 Issue 或对话里交付，比如提一个 PR。它不是能下载的 App，不是新模型，README 第一句就写明它是研究原型、不是 DeepSeek 正式产品。

能不能装，取决于四样东西：一台带 tmux 的 macOS 或 Linux（Windows 原生跑不起来服务脚本），一个专门给它用的 GitHub 用户账号，一个版本落在 engines.dsh 区间内的 DSH，以及 DSH 里配好的模型（默认 deepseek-flash）。四样都有，就按这个顺序走：git clone 仓库，装 @deepseek-ai/dsh@0.2.1-rc.3，pnpm install && pnpm build，建 superagent profile 并挂上插件，在 cordis.patch.yml 里写好 stateDir，然后 scripts/dsh-superagent start。

第一次启动返回 exit 3、提示「GitHub 来源没有设置监听的仓库」是正常的，意思是服务已经起来、在等你配置。2026 年 11 月 1 日在一台 Apple 芯片的 macOS 上（Node 24.11.0、DSH 0.2.1-rc.3）实际跑到了这一步，也试出了漏写 stateDir 和账号 CLI 配错时的报错原文；之后的步骤是补机器人账号、仓库和名单，再用一条 @ 评论派出第一张工单，这部分来自官方部署文档。

dsh-superagent 是什么：DeepSeek Harness 的插件包，不是 App

dsh-superagent 是装进 DeepSeek Harness 里运行的一组插件，DeepSeek 没有为它发布安装包，也没有手机版。新闻里的「Super-agent」「超级智能体」和仓库名 dsh-superagent 说的是同一个东西；「超级智能体」是媒体的叫法，DeepSeek 的中文设计文章标题用的是 Super-agent，下文统一叫 dsh-superagent。仓库按 MIT 协议开源，截至 2026 年 11 月 1 日只有一次提交，Issues、Discussions 和 Wiki 都没有开放，遇到问题只能查仓库 docs/ 里的文档。

能下载的是 DeepSeek Harness 本体。按 DeepSeek Harness 官方介绍页，DSH 是 DeepSeek 开源的 Agent 框架，目前是全球公开预览版，提供 macOS（Apple 芯片）和 Windows（64 位）桌面版，也可以从命令行启动网页界面。dsh-superagent 的官方部署方式用的是后者：从 git 仓库构建插件，用 dsh 命令行建一个基于 Web 模板的独立 profile，在浏览器里打开管理面板。桌面版能不能加载这个插件包，官方文档没有写。

它适合的场景很具体：一个仓库、一个团队，有人在 Issue 或评论里 @ 机器人账号说「修一下这个」，它就开工单、拉分支、干完回原帖交 PR，面板上只显示需要人处理的事。如果你要的是自己在本机同时开几个编码 Agent 分活，而不是一个常驻接单的机器人账号，小团队多代理编程工作流：Worktree、任务分工与合并验收讲的更贴近。

新闻里的「AI 指挥 AI 干活」：开源原型默认只接 @ 的活

新闻讲的 Router 加 Worker 双层架构在原型里是有的，但「没人 @ 也主动修 bug」是 DeepSeek 内部实例的做法，开源原型默认不会这样干。按 IT之家对设计文章的报道，Router 负责承接所有人的消息并分派任务，多个 Worker Session 在互相隔离的上下文里并发干活；DeepSeek 团队说内部实例已经持续运行，会盯着公共群聊，在没人 @ 的情况下发现缺陷并提交修复 PR。README 则写明，公开代码和内部版本、和文章描述的实现都不完全一样，文章里有些设计只是后续方向。

落到原型上，主动接活的开关叫接受模式，默认是 observe：它会评估那些没人点名的消息，觉得「本可以接」时只记一笔，不真的开工单；有人在名单里并且明确 @ 它，才会开工。看过记录、觉得判断靠谱之后，再改成 auto。至于设计文章里的实验，IT之家转述的结果是：在约 300 条消息、其中约 20 条工作请求的合成负载下，各方案各跑 5 次，Super-agent 完成任务的 p50 为 12.4 分钟、p95 为 15.7 分钟，中性提示下的单 Session 方案 p95 为 29.5 分钟。DeepSeek 团队自己说明这是合成负载和简化环境，衡量的是调度协作，不是单个任务的执行能力，换到你的仓库里不会看到同样的数字。

装之前的准备清单：专用 GitHub 账号最容易卡住

按官方 dsh-superagent 部署文档（006-deployment）和 SETUP.md 的环境探测，下面每一项都缺一不可。最常卡住的是机器人账号：它必须是一个真实的 GitHub 用户账号，不能拿你自己的号顶替，因为它写的每条评论、推的每个分支都署这个名字。

• 一台 macOS 或 Linux，装好 tmux；Windows 原生不行，原因和替代办法见下一节
• Node.js 22.19 以上或 24 以上、pnpm、git 2.32 以上、Python 3.8 以上、GitHub CLI（gh）2.48 以上
• 版本落在插件 engines.dsh（^0.2.1-alpha.2）区间内的 DSH，官方文档固定写的是 0.2.1-rc.3
• github.com 上的仓库（GitHub Enterprise Server 不支持），外加本机一份 clone，用来给每张工单开 worktree；仓库用了 Git LFS 就再装 git-lfs
• 一个对仓库有写权限的 GitHub 用户账号，GitHub App 不行，因为 dsh-superagent 靠读这个账号的通知来收活
• DSH 里配好的模型，Web 模板默认用 deepseek-official 提供的 deepseek-flash，面板里可以登录 DeepSeek 账号或填 API Key

接飞书的话，再加一个带机器人能力的飞书或 Lark 自建应用，以及 lark-cli（官方测试过 1.0.90）。另外，dsh-superagent 不用你本人登录的 gh，而是要一个只读机器人账号凭据的包装脚本，后面配置一节会给出写法。

Windows 能用吗：官方服务脚本只能跑在 macOS 和 Linux

Windows 原生跑不起来。负责启动、停止和查状态的 scripts/dsh-superagent 是一个 Python 脚本，开头就导入了只在类 Unix 系统上存在的 fcntl 模块，并且把 dsh 放进 tmux 会话里运行，这两样 Windows 原生都没有。DSH 本身有 Windows 桌面版，但那不等于这个插件包能在 Windows 上按官方方式部署。

Windows 用户能走的路有两条。一是在 WSL 里按 Linux 的方式部署，这是不改代码的做法。二是第三方移植：2026 年 11 月 1 日出现的 buyou-claw/dsh-superagent-win 改了 PATH、git 环境、gh 包装脚本和 PowerShell 写法，但它不是 DeepSeek 发布的，作者自己的测试仍然要在 WSL 或 Linux 上跑，用之前自己读一遍改动。

DSH 装哪个版本：npm 的 latest 可以，@alpha 不行

装 @deepseek-ai/dsh 时用官方文档里的 0.2.1-rc.3，或者直接装 latest，都在插件要求的范围内；不要装 @alpha。插件的 engines.dsh 是 ^0.2.1-alpha.2，截至 2026 年 11 月 1 日 npm 上 latest 和 next 标签都指向 0.2.1-rc.5，落在区间内；alpha 标签指向 0.2.2-alpha.2，超出了区间，装上之后日志会报插件和正在运行的 dsh 不兼容，官方给的处理就是换回区间内的版本。这个结论是拿 npm 当天的版本列表按 semver 规则逐个算出来的，实际运行过的只有 0.2.1-rc.3。npm 标签会移动，装之前用 npm view @deepseek-ai/dsh dist-tags 看一眼。

从 git clone 到首次启动：五步命令和实测输出

下面的命令来自官方部署文档，输出是 2026 年 11 月 1 日在 macOS（Darwin 25.1.0 arm64）上实际跑出来的，环境是 Node 24.11.0、git 2.50.1、tmux 3.6a、Python 3.12.1、gh 2.82.1，DSH 0.2.1-rc.3。为了不碰本机已有配置，DSH 装在单独目录里，DSH_HOME 也指向了单独的位置；你按默认装，profile 会落在 ~/.dsh/profiles/superagent。整套流程只在一台还没有 superagent profile 的机器上跑一次。

1. 装 DSH，没有 pnpm 就一起装上。实测装 @deepseek-ai/dsh@0.2.1-rc.3 和 pnpm@11.7.0 时输出「added 687 packages in 1m」，用时约 1 分钟，dsh --version 显示 0.2.1-rc.3。

   sh复制

   npm install -g @deepseek-ai/dsh@0.2.1-rc.3
   npm install -g pnpm   # 还没装 pnpm 时

2. 克隆仓库并构建插件。实测 pnpm install 5.9 秒完成。想先确认代码没问题，可以多跑一次 pnpm check，它会做类型检查、跑测试再构建，实测 59 个测试文件、1,197 个测试全部通过。Node 24 下会刷出很多行 ExperimentalWarning: SQLite is an experimental feature，这是 Node 对内置 SQLite 的提示，不影响结果。

   sh复制

   git clone https://github.com/deepseek-ai/dsh-superagent-prototype dsh-superagent
   cd dsh-superagent
   pnpm install && pnpm build

3. 建 profile 并挂上插件。第一条命令按 DSH 的 Web 模板建出 superagent profile，第二条把当前目录作为插件装进去。实测两条都 exit 0，profile 目录里生成了 cordis.patch.yml、cordis.yml、package.json 和 pnpm-workspace.yaml。第一条命令只能在新装时用：profile 已存在时再跑一次，会整个替换掉它并删除你的 cordis.patch.yml，升级时千万别用。

   sh复制

   dsh superagent --from-default-profile web --dump-config > /dev/null
   dsh plugin --profile superagent add "link:$PWD"

4. 写机器配置。把仓库自带的示例复制成 profile 的 cordis.patch.yml，把 stateDir 改成一个绝对路径。这个目录存数据库、锁、命令垫片、机器人专用的 git 配置和各工单的工作目录，之后在面板里改不了，升级前要备份。示例里还把面板端口设成了 3082。

   sh复制

   cp examples/profile.cordis.patch.yml ~/.dsh/profiles/superagent/cordis.patch.yml
   # 把 stateDir 改成绝对路径，例如 /Users/你的用户名/.dsh/state/superagent

5. 启动并查状态。start 会在名为 dsh-superagent 的 tmux 会话里运行 dsh --profile superagent，最多等 1 分钟。实测几秒内返回 exit 3，这就是装对了。

   sh复制

   scripts/dsh-superagent start
   scripts/dsh-superagent status

实测第 5 步的输出（节选）如下，status 返回的内容相同，退出码也是 3：

"health": { "runtime": "paused", "github": "paused", "assessment": "ready", "evals": "ready" },
"setup": {
  "place": "github",
  "code": "repositoryUnset",
  "detail": "The GitHub Source names no repository."
}
dsh-superagent is waiting for setup: The GitHub Source names no repository.
Open the URL DSH printed in the log, then the dsh-superagent overview.

首次启动 exit 3：「GitHub 来源没有设置监听的仓库」是在等配置

exit 3 的意思是服务已经在跑、在等配置，重启解决不了，也不需要重启。官方给 start、status、restart 定了四个退出码，看懂它们就知道下一步该干什么：

打开日志里打印的网址（.artifacts/ 下最新的那个日志，网址带 token），在左侧栏选 Superagent 就是管理面板。2026 年 11 月 1 日在简体中文浏览器里打开时，界面跟着浏览器显示中文：先弹出 DSH 0.2 的「预览版说明」，接着是「开始使用：登录 DeepSeek 账号，或添加 API Key，即可开始使用。你的项目和文件保存在本地。」，这一步就是给 DSH 配模型。Superagent 的概览页顶部有概览、来源、触发、评估、执行、设置六个标签。

「系统问题 2」下面列着两条。第一条是「部署检查未通过，dsh-superagent 暂不接单」，下面一行写着「GitHub 来源没有设置监听的仓库。」，旁边是「重新检查」按钮；第二条是「没有人能发起工作：各来源上的名单都为空，任何请求都不会成为工单」，旁边是「去添加」按钮。执行器一栏同时显示「执行器等待部署检查」。这两条系统问题就是下一节要补的东西，补完任何一项，面板都会重新做部署检查。

补齐配置的顺序：模型、机器人账号、来源、名单、执行

按官方 SETUP.md 的顺序补，每补一项面板会重新检查。README 推荐的做法是让你常用的编码 Agent 来带：对它说「Read SETUP.md in this repository and set up dsh-superagent with me.」，它会一次只问一个问题，一共 9 个（来源、仓库、机器人账号、飞书群、GitHub 名单、飞书名单、checkout、提交署名、自动合并），汇总成一份计划等你确认后再执行，并且不会在对话里向你要密钥。2026 年 11 月 1 日的实测停在机器人账号之前：没有新建 GitHub 账号、没有填模型 Key，也没有派过真实工单，所以下面的步骤来自官方部署文档，其中的面板文字和报错原文是实测时看到的。

1. 配模型。在面板的「开始使用」里登录 DeepSeek 账号，或者点「添加 API Key」。dsh-superagent 默认用 profile 的默认模型，评估和执行设置里可以另指定。

2. 建机器人账号，给它一个只用自己凭据的 gh。在 GitHub 上注册一个新的用户账号，邀请它成为仓库协作者并给写权限，用这个账号接受邀请。然后写一个包装脚本，让它的登录信息和你本人的 gh 分开存：

   sh复制

   mkdir -p ~/.local/bin
   cat > ~/.local/bin/gh-agent <<'EOF'
   #!/bin/sh
   GH_CONFIG_DIR="$HOME/.config/gh-agent" exec gh "$@"
   EOF
   chmod +x ~/.local/bin/gh-agent
   gh-agent auth login
   gh-agent api user --jq .login

   登录时用机器人账号，最后一条命令打印出的应该是机器人的用户名。

3. 设置来源。在「设置 › 来源」的 GitHub 卡片里填仓库（owner/name 格式）和机器人 CLI 的绝对路径，比如 /Users/你的用户名/.local/bin/gh-agent。保存时会先检查这个 CLI 能不能用、账号有没有推送权限，检查不过就直接拒绝保存并给出原因。

4. 加名单。点概览里「没有人能发起工作」旁边的「去添加」，在 GitHub 来源的名单里先只加你自己的 GitHub 用户名。名单为空时，任何请求都不会变成工单；官方建议一开始只放自己，熟悉它的行为后再加人。

5. 设置执行。填工单工作目录的根目录和 prepare 命令，让每张工单从你本机的 clone 里开一个 worktree。官方给的写法如下，把 /home/me/src/widgets 换成你的 clone 路径：

   sh复制

   git -C /home/me/src/widgets fetch --no-tags "https://github.com/$DSH_SUPERAGENT_GITHUB_REPOSITORY.git" "${DSH_SUPERAGENT_GITHUB_PR_HEAD:-HEAD}:refs/dsh-superagent/$DSH_SUPERAGENT_TICKET" &&
   git -C /home/me/src/widgets worktree add -b "agent/$DSH_SUPERAGENT_NAME" "$DSH_SUPERAGENT_DIR" "refs/dsh-superagent/$DSH_SUPERAGENT_TICKET"

   你本人登录过的 CLI（比如自己的 gh）加进被阻止的命令里。提示词设置里再写上提交署名和是否自动合并，官方建议先关掉自动合并，由人来合。

6. 确认状态并派第一单。scripts/dsh-superagent status 返回 exit 0、没有 setup 问题后，用名单里的账号在仓库的某个 Issue 下发一条新评论，写 @机器人用户名 你的请求。默认每 60 秒轮询一次通知，一分钟左右概览里应该出现一张工单；机器人会先回复确认，在自己的 Session 和目录里干活，最后在原 Issue 里交付，通常是一个 PR。注意编辑已有 Issue 的正文、在里面补一个 @ 是收不到的，必须发新评论。

启动和保存配置时的报错对照：超时、agentCliMissing、403

下面前五行是 2026 年 11 月 1 日在 DSH 0.2.1-rc.3 上实际碰到的，报错是英文原文，面板里会按界面语言显示；其余几行来自官方部署文档的排错表。

管理 API 的地址是 http://127.0.0.1:3082/orchestrator/api/，面板和 SETUP.md 里的编码 Agent 都通过它保存设置。保存被拒时，响应体会写明是哪一项配置出了问题，按上表对号入座即可。

怎么接飞书：自建应用机器人和只认机器人身份的 lark-cli

接飞书是可选的，不接也能只用 GitHub。要接的话，先在飞书开放平台建一个自建应用，开启机器人能力，给它接收消息事件、读取和发送群消息、读取群成员这几项权限，然后发布应用版本。飞书和 Lark 是同一套开放平台的国内版和海外版，命令行工具都是 lark-cli。下面是官方部署文档给的步骤。

接着给机器人单独准备一份 lark-cli 配置，并限定成只能以机器人身份调用。第一条命令从标准输入读应用密钥：

LARKSUITE_CLI_CONFIG_DIR="$HOME/.lark-cli-dsh-superagent" lark-cli config init --app-id <cli_…> --app-secret-stdin
LARKSUITE_CLI_CONFIG_DIR="$HOME/.lark-cli-dsh-superagent" lark-cli config strict-mode bot --global
cat > ~/.local/bin/lark-bot <<'EOF'
#!/bin/sh
export LARKSUITE_CLI_CONFIG_DIR="$HOME/.lark-cli-dsh-superagent"
exec lark-cli "$@"
EOF
chmod +x ~/.local/bin/lark-bot

配置目录一定要单独建，因为 lark-cli 一个应用 ID 只允许一份配置，你个人的配置里可能已经有这个应用的用户登录；能以用户身份调用的 CLI 会被 dsh-superagent 直接拒绝。之后在 cordis.patch.yml 里取消 dsh-superagent-feishu 那两行的注释，重启后在「设置 › 来源」的飞书卡片里填 lark-bot 的路径、要监听的群和是否接收私聊，并把机器人拉进这些群。默认机器人只读 @ 它的消息，私聊是开着的；名单可以设成跟某个群的成员同步。飞书这边配置失败只会停掉飞书来源，不影响 GitHub。

它能动你电脑上的什么：worker 以你的系统用户全权限运行

能动的范围比你想的大。官方文档写明，执行工单的 worker 和负责分派的 router 都以 danger-full-access 运行，身份就是你当前的系统用户；gh-agent 这类包装脚本只决定它默认用哪个账号的凭据，并不隔离进程，worker 可以按路径执行任意程序，也能读你的主目录。要真正隔离，官方的建议是给它单开一个系统用户，里面只放机器人自己的凭据。

dsh-superagent 也做了一些收敛：启动检查时会去掉名字里带 KEY、PASSWORD、SECRET、TOKEN 的环境变量，把自己的命令垫片放在 worker 的 PATH 最前面，再给 worker 换上一份只用机器人凭据的 git 配置，取代你的全局和系统 git 配置，GH_TOKEN 和 GITHUB_TOKEN 也会被移除。被阻止的命令列表能减少误用，但官方没有把它说成安全边界。所以在你自己的主力机上直接跑之前，先想清楚它能读到哪些东西；名单只放自己、接受模式保持 observe，是让它先在小范围里跑的办法。

要花多少钱：代码免费，模型按 DeepSeek API 计费

dsh-superagent 的代码是 MIT 协议、免费的，没有托管版，也没有单独收费；花钱的是模型调用，由你在 DSH 里配置的模型提供方计费。Web 模板默认用 deepseek-flash，按 DeepSeek 中文价格页，截至 2026 年 11 月 1 日它的输入未命中缓存为每百万 tokens 空闲时段 1 元、高峰时段 2 元，峰谷时段和其他模型的价格见DeepSeek API 峰谷价格：几点调用更省、账单怎么算。每张工单要花多少没有公开数据：每张工单都是一个 router 加一个 worker Session，消耗取决于仓库大小和任务本身，想给它设上限可以看LLM Agent API 花费熔断开关：在供应商调用前截住失控账单。

升级前先备份 orchestrator.sqlite：新版迁移后旧版打不开

升级 dsh-superagent 前一定要备份数据库，因为新版本迁移过的数据库旧版本打不开，回滚只能靠升级前的备份。官方顺序是：等没有执行器正在一轮操作中，备份 stateDir 下的 orchestrator.sqlite，在仓库目录里运行 git pull && pnpm install && pnpm build，再 scripts/dsh-superagent restart 并查看状态。重启会结束正在进行的任务并带着恢复说明重新开始；你改过的提示词会保留，没改过的部分跟着新默认值走。单独升级了 DSH 本体之后，也要重启一次，让面板加载对应版本的文件。升级全程不要再跑建 profile 的那条命令。

DeepSeek Super Agent 部署的其他问题

能不能把 dsh-superagent 装进平时用的 DSH profile 里？

不建议。官方部署文档让你单独建一个 superagent profile：插件会改动整个进程的 PATH 和 git 设置，还需要能独立重启和升级；装进你日常用的 profile，会影响你自己的 Session。

super-agent.io 是 DeepSeek 官方的吗？

不是。截至 2026 年 11 月 1 日，这个网站页脚写的是独立指南、与 DeepSeek 无关，它的部署规划工具也不会真的安装或连接任何东西。同一天 GitHub 上还出现了 Windows 移植、文件收件箱来源、面板嵌入等第三方仓库，都不是 DeepSeek 发布的。

dsh-superagent 能用 DeepSeek 以外的模型吗？

DSH 0.2.1-rc.3 的 Web 模板里挂载了 dsh-llm-pi-ai 适配器，按它的说明可以把请求转到多家 pi-ai 提供方、OpenAI 兼容网关或自建服务器，所以适配器层面是支持的，但截至 2026 年 11 月 1 日这条路没有实际跑过。只是想在写代码时用上 DeepSeek 模型，另一条更成熟的路是Claude Code 连接 OpenRouter 和 DeepSeek：路线选择、配置与首错排查。