DeepSeek 开源 Super-agent：部署实战与关键配置

DeepSeek 近日开源了 Super-agent 原型（仓库 deepseek-ai/dsh-superagent-prototype，MIT 协议，star 已破 1.7 万）。它不是又一个聊天框 Agent，而是一个「盯仓库」的主动性编码智能体：监听 GitHub（可选飞书），把被授权的请求变成工单（Ticket），在独立会话和独立目录里干活，最后回到原对话交付——比如直接开一个 PR。官方明确说这是研究原型：代码大量由编码智能体写成，别直接上生产。

这篇按官方 SETUP.md 和部署文档走一遍完整落地：环境探测、双账号隔离、五步安装、启停排错表、配置保存顺序。

一、先搞懂域模型：四个概念决定所有配置

智能体内部是一条流水线：Triggers（请求来源，GitHub 或飞书）→ Policy（谁有权要活）→ Ticket（工单）→ Executor（在独立目录里执行的会话）。官方哲学文档讲的设计原则只有一句话：占用最少的人类注意力，产出最多的价值——智能体只在被要求或规则允许时行动，只在必须有人介入时说话。

理解这句话，才能理解部署里的几个「反直觉」要求：为什么必须独立 profile、为什么必须独立 GitHub 账号、为什么默认只开观察模式。

二、环境探测：一条命令查完所有依赖

前置依赖一长串：Node.js 22.19+ 或 24+、pnpm、git 2.32+、tmux、Python 3.8+、GitHub CLI 2.48+，DSH 版本要落在 package.json 的 engines.dsh 区间。官方给的探测命令一次查完：

node -v; pnpm -v; git --version; tmux -V; python3 --version
gh --version | head -1; dsh --version
gh api user --jq .login
command -v lark-cli

注意 gh api user 输出的是你自己的 GitHub 登录名，后面配置授权名单要用。飞书是可选项，不用飞书就跳过 lark-cli，Source 只配 GitHub。另外 DSH 需要配好模型供应商，智能体默认用 profile 的默认模型。

三、账号隔离：两个坑提前说

坑 1：GitHub App 当不了智能体。dsh-superagent 靠读账号的 notifications 工作，GitHub App 没有通知流。必须给智能体建一个普通 GitHub 账号，并给它仓库写权限。

坑 2：凭证必须物理隔离。官方做法是给智能体单独一个 gh CLI wrapper，用 GH_CONFIG_DIR 把凭证目录分开：

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

权限模型也要心里有数：智能体的两个 preset（worker 和 router）以 danger-full-access 跑在你的 OS 用户下，worker 能按路径执行程序、能读 home 目录。文档给的建议很直接：要强隔离，就把智能体跑在专用 OS 账号里，只放它自己的凭证。

四、五步安装：第四条命令只能跑一次

npm install -g @deepseek-ai/dsh@0.2.1-rc.3
git clone <仓库地址> 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"

逐条说重点：

• 第 1 条装 DSH 运行时，版本钉死 0.2.1-rc.3，换版本必须满足 engines.dsh 约束；
• 第 4 条从 Web 模板创建独立 profile（~/.dsh/profiles/superagent）——全新安装只跑这一次。重复执行会整个替换 profile 并删掉 cordis.patch.yml（含机器配置），升级时绝对不能用；
• 第 5 条把 bundle 挂进 profile。

为什么要独立 profile？文档原话：这个插件会改进程级 PATH 和 git 配置，进程需要独立重启和升级。跟日常工作的 profile 混用，等于把开发环境和智能体运行时绑死。

五、启停与排错：exit code 记住四档

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

start 在 tmux 会话里拉起服务，最多等 1 分钟就绪；stop 优雅停机，最多等 5 分钟让 Executor 收尾，绝不强杀。status 打印 pid、健康状态和 setup 问题，退出码含义如下：

退出码	含义	重启能否修复
0	正常运行	—
1	没起来 / 起了两个实例 / 不应答 / 运行时报错	能
2	运行中，但非运行时部件报错（某 Source、Policy 同步）	不能
3	运行中，在等 setup 信息	不能

实战里最容易绕晕的是 1 和 3：exit 1 重启大概率自愈；exit 3 说明服务在等你补配置，重启多少次都没用，去看 status 输出的 setup 字段缺什么。Source 还在启动中算正常。日志在 .artifacts/ 目录，按 dsh-superagent--<日期>-<时间>-.log 命名，最新 20 份保留。

六、配置保存：顺序和生效行为都有讲究

配置走 Management API，顺序：github Source → （可选）feishu Source → policy 授权名单 → executor 执行目录。prompts 最后存，内容含提交身份（commit 作者署智能体账号）和交付要求（是否自动合并）。

两个生效细节：

• 保存返回 restarting: true 会触发重启——等 status 不再 exit 1 再发下一个请求，并重新读 settings 里的 revision；
• 被拒绝的保存会在响应体里点名问题，对照部署文档的 Troubleshooting 表修。

自动合并建议保持关：人审通过后再合并，观察期过了再考虑交给另一个有合并权限的账号 CLI 去执行。

七、验收与第一批活

验收就一条：从授权名单里的账号，在仓库 issue 下评论 @智能体登录名 加请求内容，一分钟内面板上应出现对应 Ticket。

首次运行保持默认 observe 模式：只记录主动性工作但不真正执行，先看它「想干什么」，把噪声调到可接受再放行真执行。官方哲学文档给了三条操作者守则：起点收窄、往少噪声调、智能体说的话你兜底。

参考来源

1. dsh-superagent 仓库 README 与 SETUP.md（DeepSeek 官方，MIT 协议）
2. DeepSeek Harness 部署文档 docs/006-deployment.md
3. 论文 Exploring Super-agent Design: Towards a More Autonomous Agent System
4. DeepSeek Harness 官方主页