DSH Superagent 是什么：DeepSeek 如何把 GitHub 请求变成 Agent 工作流

需求留在 Issue 里，补充条件出现在评论中，修改后的问题又回到 Pull Request。编程 Agent 即使能写代码，人仍可能要反复整理上下文、转述反馈、确认它究竟做到哪一步。DSH Superagent 探索的是这部分协作：让 Agent 在团队讨论发生的地方接收请求，并持续跟进到交付。

DSH Superagent Prototype 是基于 DeepSeek Harness 的主动编程 Agent 研究原型，面向单个 GitHub 仓库，也可接入飞书。它把授权请求变成任务，在各自的会话和目录中执行，再回到原讨论回复，例如提交一个 PR。

截至 2026 年 11 月 2 日核查，代码位于 DeepSeek 官方 GitHub 组织下，但 README 明确说明它不是正式 DeepSeek 产品，也没有达到生产就绪状态。公开版经过调整，与内部版本和设计文章中的实现存在差异，文章提到的部分方案尚未实现。理解它的价值，应从公开工作流入手。

一次 GitHub 请求怎样变成工作

先看一个假设场景：你在一个仓库的 Issue 中提到 Agent，要求它调查导出文件的日期格式错误，补充测试，并提交 PR。这里的目标、测试和交付方式是示例需求，不是本文实际运行得到的结果。

接下来需要处理四件事：识别这条消息是谁发的，确定它是否构成请求，划定允许完成的工作，再把执行结果交回讨论。官方领域模型把它们拆成事件、评估、任务和执行等环节。

流程图依据 2026 年 11 月 2 日核查的官方领域模型整理；已有任务的后续消息还可以作为上下文继续进入任务，不必每次重新创建工作。

GitHub 和飞书是消息来源。系统先识别事件及其发送者，再判断应当开始新任务、补充已有任务，还是忽略。获准的工作成为一个 Ticket，可以理解为带范围的任务单；其中的 Mandate 记录这次工作为什么得到授权、可以做到哪里。每个任务随后交给执行者，结果再通过原渠道送回。

这套划分适合解决一个常见混乱：讨论里出现的信息，并不都代表要执行的命令。日期格式的参考文档可以帮助调查，但文档中的文字不能自行扩大任务权限。原本只要求修复导出格式，也不应因为读到一段部署说明就顺手发布应用。

「主动」如何受到规则约束

主动 Agent 最容易引起的误解，是它可以自行从所有聊天中挑选工作。DSH Superagent 把明确请求和推断出的候选任务分开处理；什么人可以请求工作、哪些消息会进入判断，取决于消息来源和当前策略。

默认的 observe 模式会评估推断候选。即使判断应该接受，也只记录「本来会接受」，不会建立并执行这项工作。切换到 auto 后，符合启用规则的推断任务才可能被接受。明确请求在所有模式下仍可执行，所以观察模式不等于全系统只读，也不保证无人发起实际任务。权限文档对此有单独说明。

这个区别给试用提供了一个实用顺序：先看系统会从什么消息中推断工作，以及它给出的理由；判断规则是否符合团队意图后，再逐步开放自动接受。它比单看最终代码是否正确更早暴露问题，因为一个执行正确、却没人希望启动的任务，同样会消耗资源和审阅时间。

执行、跟进与交付怎样保持连贯

任务得到独立会话和目录，执行者可以在自己的工作上下文中调查、修改和检查。需要准备仓库副本时，可以通过配置的准备命令创建 Git worktree；仅有一个目录，并不意味着系统已经替你完成了仓库准备。

提交 PR 后，任务仍可能收到人的补充或评审意见。与任务相关的后续讨论可以继续进入执行者；超出原有范围的要求需要交回路由处理。于是，「调整这个修复的边界条件」和「顺便重做整个导出模块」不必被当成同一份授权。

运行过程中也有等待回答、等待评审、阻塞和失败等状态。官方执行文档区分这些情况；监督面板则优先呈现需要人处理的工作，再提供系统健康和历史记录。任务正在运行、正在等待消息，以及需要人介入，是不同的下一步。

沿用日期格式的例子，一个便于审阅的交付应包含修改范围、测试结果和仍未处理的问题。这是适合采用的交付标准，不是仅凭开启项目就能保证的输出质量。PR 已创建也不表示它适合合并；合并审批需要结合团队要求，并在 GitHub 分支保护中落实需要强制执行的规则。

Harness 与 Superagent 各自负责哪一层

DeepSeek Harness提供 Agent 运行与扩展的基础。Superagent 则以 bundle 的形式装入 Harness，为仓库协作增加请求接收、任务分配、跟进和监督界面。两者有依赖关系，但读者选择它们时要回答的问题不同。

这个分层也解释了为什么换一个模型不能自动解决协作问题。即使模型能写出正确修复，系统仍要知道该听谁的、哪些信息属于当前任务，以及何时等待审阅。需要进一步理解模型与完整系统的关系，可以参考 DeepSeek Agent 的组成与类型。

哪些设计可以用于自己的工作流

对在 Floatboat 中组织资料和任务的人，最容易借鉴的是把「输入」和「授权」分别写清楚。一次研究任务可以接收网页、文档和评论，但只有指定请求才能改变交付目标。把参考资料和行动指令混在同一段提示词里，会增加后续判断的困难。

第二个可借鉴点是为任务保留持续的上下文。把最初需求、补充材料、当前结论和待办问题关联起来，后续反馈才不必从零解释。实现时可以从一份明确的任务记录开始，不必一开始就复制完整的路由系统。

第三个是让交付成为一个可检查的状态。例如，研究流程可以要求「给出来源、比较依据、未确认项与结论」，内容流程可以要求「交稿并等待审核」，而不是把「Agent 停止输出」当作完成。针对不同任务设计验收证据，通常比增加一段笼统的自主执行指令更有用。

这些是根据公开机制提出的工作流建议。直接运行该项目、复用部分源码，以及只借鉴设计，是不同的实施选择；任何一种都不意味着它已经与 Floatboat 建立连接。先选定一个真实问题，再判断是否需要软件集成。

运行之前要考虑的条件

根据部署文档，原型需要 Node.js 22.19+ 或 24+、pnpm、Git、Python、tmux、GitHub CLI，以及已配置模型服务的 Harness。它面向 github.com 仓库，不支持 GitHub Enterprise Server。GitHub 身份需要专用用户账号并获得仓库写权限；当前实现读取用户通知，不能用 GitHub App 替代这个身份。飞书接入是可选项，还需要相应机器人和 CLI 配置。

模型服务与运行主机也有成本。MIT 适用于源码许可，不代表模型调用和机器资源免费；候选评估、执行、重试与后续修改都可能产生调用。本文依据公开文档分析机制，未完成本地安装与成本实测，不能给出稳定任务费用或成功率。

还需要单独看待本机执行权限：任务目录和账号命令包装器不构成安全沙箱。预设以运行者的操作系统身份执行，能够接触该身份可访问的文件与程序。官方建议使用仅放置 Agent 凭据的专用系统账号。任务层面的允许范围，不能代替操作系统层面的隔离。

从一项可验收的任务开始

如果你需要处理的是仓库中的持续协作，可以先选一个测试仓库、少量授权人员和一个清楚的交付目标。保留推断任务的观察模式，让显式请求完成一轮工作，再查看哪些讨论被识别为候选、哪些反馈进入了原任务，以及是否存在多余回复。

验证时记录四类结果就足够开始：请求是否被正确接受，任务是否保持范围，交付是否提供审阅证据，以及人实际花了多少时间纠正或补充。遇到阻塞时，还要看系统能否说明需要什么帮助。只有这些结果符合预期，才有理由扩大自动执行范围。

如果只是偶尔在本地修一个文件，常规交互式 Agent 可能更直接；如果工作需要跨多个仓库，或涉及非编程的业务动作，也应先评估原型的单仓库定位。DSH Superagent 最值得研究的地方，是它把接收请求、授权、执行和人的注意力一起纳入设计。你可以先把其中一个薄弱环节补进自己的流程，再决定是否需要部署整套系统。