dsh-superagent 部署教程

dsh-superagent 部署教程：GitHub、飞书与独立 Worker

作者
DeepSeekAgent.io 编辑部
发布
更新

dsh-superagent-prototype 是 DeepSeek Harness 团队公开的主动式 Coding Agent 原型。一次部署服务一个 GitHub 仓库，可以只接入 GitHub，也可以增加飞书消息来源。它不是在现有聊天中打开一个开关：需要单独的 DSH Profile、Agent 账号、执行目录、授权规则和长期运行进程。

下面按官方 SETUP.md 与部署文档整理一条可审查的安装路线。第一轮建议只连接一个测试仓库，并保持主动接单为观察模式。

部署前先准备什么

官方原型要求 Node.js 22.19+ 或 24、pnpm、Git 2.32+、Python 3.8+、tmux、GitHub CLI 2.48+，以及满足 package.json 中 engines.dsh 范围的 DSH。DSH 还需要已经可用的模型 Provider。

生产式试用还应准备：

  • 一个专门给 Agent 使用的 GitHub 账号；
  • 一个用于测试的 GitHub 仓库；
  • 一个独立的系统用户或隔离机器；
  • 独立的 DSH Profile 和 state directory；
  • 若接飞书，准备单独的机器人应用和允许接入的群聊。

不要让 Agent 默认使用操作者自己的 GitHub 登录。它创建的评论、Commit 和 Pull Request 应有清楚的机器身份。

第一步：克隆原型并阅读安装入口

官方 SETUP.md 的设计是让 Coding Agent 读取安装说明、逐项收集配置，再执行完整计划。人工操作时，也应先阅读以下文件：

SETUP.md
docs/000-philosophy.md
docs/001-domain.md
docs/002-authorization.md
docs/003-execution.md
docs/006-deployment.md

不要跳过 Philosophy 和 Authorization。它们决定哪些消息会成为任务、哪些人可以发起任务，以及 Agent 在什么情况下只能观察而不能执行。

第二步：先回答九个部署问题

官方安装流程把关键决策分为三组。

Source

  1. 只使用 GitHub，还是同时连接飞书；
  2. Agent 服务哪个 owner/repository；
  3. 使用哪个专用 GitHub Agent 账号；
  4. 若使用飞书，监听哪些群聊。

Policy

  1. 哪些 GitHub 用户可以要求 Agent 工作；
  2. 哪些飞书用户可以发起任务。

Execution

  1. 每个 Ticket 从哪个仓库副本准备工作目录；
  2. Commit 使用什么作者身份；
  3. Pull Request 是否允许自动合并。

第一轮推荐：GitHub only、单仓库、短 allowed list、不自动合并。先验证 Agent 是否正确理解 Issue、提交范围和评审反馈，再扩大来源与权限。

第三步：建立独立 Profile

官方文档建议使用名为 superagent 的专用 Profile，状态目录与日常使用的 DSH 分开。独立 Profile 有三个好处：

  • Super-agent 重启不会关闭用户正在工作的 Session；
  • Router 和 Worker 的专用 Preset 不会污染普通会话；
  • 插件修改 PATH、Git 设置或环境变量时，影响范围更清楚。

面板默认可以运行在单独端口，例如官方示例使用 3082。不要直接把面板暴露到公网；先限制在本机或受控网络中。

第四步：配置 GitHub 身份和 Source

使用专用 GitHub CLI 包装器登录 Agent 账号，并让该账号只获得目标仓库所需权限。配置 Source 时需要保存：

  • 仓库 owner/name；
  • Agent GitHub 登录名；
  • Source 是否启用；
  • 接收哪些 Issue、Pull Request、评论和 CI 事件；
  • 哪些账号位于 allowed list。

Agent 账号应能读取仓库、创建分支、Push 和提交 Pull Request，但是否可以合并由团队流程单独决定。没有成熟的分支保护和审查规则时，不开启自动合并。

第五步：配置执行目录

每个 Ticket 会获得单独目录和 Executor Session。prepare command 可以从指定仓库创建工作副本；官方文档给出的典型方向是 Git worktree 或新 Clone。

执行目录需要满足：

  • Ticket 之间互不覆盖文件；
  • 分支名能追踪到 Ticket；
  • 重启后目录和 Git 历史仍可恢复；
  • Agent 账号与操作者账号的凭据不混用；
  • 不把私人 Home 目录当作默认工作区。

prepare command 只在目录首次创建时运行，失败会让 Ticket 进入失败状态，因此要先在空白测试 Ticket 中验证。

第六步：从 observe 模式开始

accept mode 决定主动事件如何处理：

  • off：不接受推断出来的主动任务；
  • observe：完成判断并记录“本来会接受”，但不真正接单；
  • auto：符合规则的事件可以自动创建 Ticket。

默认 observe 最适合初次部署。连续检查一段时间的 Decision：哪些消息被命中、为什么命中、是否重复、是否会制造噪声。只有规则稳定后，才把个别高价值规则切换到自动执行。

第七步：可选接入飞书

飞书 Source 需要机器人应用、事件订阅和明确的聊天范围。初始配置建议只读取 @ 机器人的消息，不监听所有群聊内容。需要主动发现群内问题时，再为指定群开启更宽的接收范围，并用 admission table 限制谁能发起工作。

GitHub 身份和飞书身份不会被系统自动视为同一个人。跨来源的身份关系属于团队规则，不能靠模型猜测。

第八步：启动与验收

启动后先检查官方状态脚本和管理面板，再做三类测试：

  1. allowed list 用户在测试 Issue 中明确 @ Agent，是否创建一个 Ticket；
  2. Worker 是否在独立目录和分支中完成改动并创建 Pull Request；
  3. 未授权用户、普通闲聊和机器人消息是否按 Policy 被忽略或只记录。

随后测试失败恢复：重启进程、让测试命令失败、在已结束 Ticket 的 Thread 中追问。确认 Ticket、Subscription、目录和未处理 Input 能恢复。

第九步：再决定是否长期运行

进入长期运行前至少补齐：

  • 专用 OS 用户或隔离环境；
  • GitHub 分支保护和人工审查；
  • 面板访问控制；
  • 日志、状态和磁盘监控；
  • Token、并发 Worker 和执行时间预算；
  • 停止 Agent 与撤销凭据的流程。

Super-agent 的目标是减少人的注意力，而不是隐藏风险。先窄范围运行、减少噪声、对外输出可追责，是官方 Philosophy 给出的三条核心操作原则。

相关阅读

参考资料