10 月 31 日，DeepSeek Harness 团队发布《Super-agent 设计探索》，同一天在 GitHub 开源了 dsh-superagent-prototype。截至 11 月 1 日下午，仓库攒到约 4800 star。
很容易把它当成"超级助理"的安装包。README 开头却写着"Research prototype for reference only, not an official DeepSeek product"，并特意注明这是研究原型。 官方文章也声明"并非对 DeepSeek Harness 现有产品功能的介绍"。 这两句话，决定了你该怎么用它。DeepSeek 公众号
它开源的是一个单仓库值班 Agent
dsh-superagent 是挂在 DeepSeek Harness 上的一个插件包，只服务一个 GitHub 仓库。有人在 Issue 或评论里 @ 它，请求会变成一个 Ticket；它在自己的 Session 和目录里干活，最后回到原对话回复，通常是一个 PR。飞书可接，但不是必需。
文章里的 Router/Worker 双层、Trigger、Thread、Policy、Ticket，在仓库文档里都能找到对应物：主 Session 负责分派，Executor Session 负责执行。但 README 也直说，这是从日常开发里长出来的研究代码，“may still contain bugs”，工程风格可能不一致。 所以它更像给某个仓库配的值班工程师，而不是装上就有一堆分身的私人助理。你要先接受这个定位，后面的部署才有意义。
最短路径：安装不难，难在账号
README 推荐的做法不是自己照着文档配，而是把 SETUP.md 交给你的编码 Agent，让它读、一次问你一个问题，最后装好。这份文档本来就是写给 Agent 的。
自己动手也行。先备齐 Node 22.19+ 或 24+、pnpm、git 2.32+、Python 3.8+、tmux、GitHub CLI 2.48+，以及一个配好模型的 DSH。模型在 DSH 的 Settings → Models 里填 DeepSeek API key，或者接第三方、自定义端点。DeepSeek Harness 文档
```sh
npm install -g @deepseek-ai/dsh@0.2.1-rc.3
git clone https://github.com/deepseek-ai/dsh-superagent-prototype
cd dsh-superagent-prototype
pnpm install && pnpm build
dsh superagent --from-default-profile web --dump-config > /dev/null
dsh plugin --profile superagent add “link:$PWD”
```
这一组命令装 DSH、建一个独立的 superagent profile、把仓库挂成插件。再把 examples/profile.cordis.patch.yml 复制到 ~/.dsh/profiles/superagent/cordis.patch.yml，把 stateDir 改成绝对路径。端口默认 3082。
真正卡人的是账号。它要一个独立的 GitHub 用户账号来评论、推分支、开 PR，不能用 GitHub App——它要读这个账号的通知。 给机器人账号仓库写权限，再做一个只带它凭据的 gh 包装器：DeepSeek Harness 文档
```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
```
然后启动：
```sh
scripts/dsh-superagent start
scripts/dsh-superagent status
```
打开 http://127.0.0.1:3082，侧边栏找 Superagent。Source 填 owner/name 和 gh-agent 的绝对路径；Settings → Eval 里把你的 GitHub 登录名加进允许列表；Execution 填工作目录根和 prepare 命令，文档给了用 git worktree 的现成两行，每个 Ticket 会拿到独立检出。面板里的 Eval 和 Execution 可以分别指定模型；按官方文章的思路，判断和分派用轻一点的模型，真正干活的 Worker 用强模型。
最后用允许列表里的账号，在 Issue 里评论 `@机器人 帮我修一下……`。默认一分钟轮询，Overview 里会出现 Ticket。DeepSeek Harness 文档
装之前，先接受三个前提
它跑在你的机器上，用你的系统用户，权限是 danger-full-access。 Worker 能按路径执行程序，也能读你的 home 目录。文档的建议很直接：要隔离，就上独立机器或独立系统账号，别放在主力开发环境里。DeepSeek Harness 文档
它只盯一个仓库，只支持 github.com，GitHub Enterprise Server 不支持。 默认 accept mode 是 observe：人明确找它的事照做，它自己判断"该做"的事只记录、不执行。这算合理的默认值，先看它想干什么，再决定要不要开 auto。DeepSeek Harness 文档
主动性来自常驻。机器休眠、进程退出，"持续观察"就没了。仓库里的启动脚本用 tmux 跑服务，再配一个每小时检查兜底重启；默认面板只监听 127.0.0.1，想从外网看，得自己加 SSH 隧道或反向代理。你要有一台常开的机器，这不是纯软件问题。
谁现在值得试
想要一个接消息、管日程、同时盯很多任务的私人助理，这个原型接不住。它更像给团队某个仓库配的值班工程师：接 Issue、复现、改代码、开 PR，人负责验收。
手头有一个低风险仓库、一台常开机器、愿意花半天配账号和权限的开发者，可以试。装完先让它做一件小事，看它在你的仓库里怎么说话、怎么写代码——这比 star 数更能说明它现在值不值得用。
