DSH Superagent Prototype

了解 DeepSeek 的主动编程 Agent 研究原型，如何将 GitHub 与飞书中的授权请求转为任务。参考任务路由、范围管理和结果交付机制，构建或优化自己的 Agent 工作流。

关于 DSH Superagent Prototype

DSH Superagent Prototype 是 DeepSeek 官方 GitHub 组织发布的主动编程 Agent 研究原型。它作为 DeepSeek Harness 的扩展包运行，面向单个 GitHub 仓库，也可接收飞书消息；授权请求会转为任务，在独立会话和工作目录中执行，再把结果送回原讨论。

值得借鉴的机制包括请求评估、任务范围管理，以及跟进讨论时区分上下文与新增授权。网页面板优先呈现需要人工处理的事项，同时提供历史记录和运行健康信息，帮助团队跟踪任务与结果。

仓库采用 MIT 许可，README 明确其并非正式 DeepSeek 产品，也不属于生产就绪软件。公开实现与内部版本、配套设计文章并不完全一致，文章中的部分设计尚未实现，采用时应以实际代码和文档为准。

从团队请求到 Agent 任务

了解请求如何经过权限判断、形成明确任务，并转为可以审阅的结果。

有来源的任务请求
GitHub 与可选飞书事件进入受策略约束的路由流程。允许的请求者、消息接收范围与团队规则，共同决定一条请求能否转为工作。
有范围的独立执行
已接受的工作会建立 Ticket，并通过 Mandate 记录授权范围。执行者使用独立会话和目录，订阅讨论则为后续步骤补充上下文。
回到原讨论的交付
Agent 可以在原会话中回复结果并创建 Pull Request。面板汇集待审阅、受阻及其他需要人工关注的事项，方便继续推进任务。

可以借鉴的工作流场景

围绕自己的任务改进协作与交接，再按实际环境验证软件接入方式。

处理仓库维护请求

为一个小型编程请求明确可改动范围、验收证据和交付方式。参考从任务到 Pull Request 的组织方式，让提交的修改更容易检查。

跟进评审与后续反馈

把评审意见接回对应任务，并保留原有授权范围。遇到无关工作时重新路由，避免在持续讨论中悄悄扩大执行目标。

把团队消息变为交付目标

明确哪些渠道与人员能够发起工作，以及结果应回到哪里。将这种交接方式用于 Floatboat 中组织的工作流，具体软件连接另行验证。

运行原型前需要准备什么

从设计参考进入实际试验前，先检查运行环境、账号与机器权限。

01
准备运行环境和 Agent 身份
需要受支持的 Harness 版本、已配置的模型服务和文档列出的命令行依赖。一次部署面向一个 github.com 仓库，通过专用 GitHub 用户账号执行操作。
02
划清机器与账号权限
文档中的路由与工作预设以操作系统用户身份拥有完整执行权限。独立会话和凭据包装并非沙箱；需要隔离时，应使用专用操作系统账号。
03
先检查推断任务的判断
默认 observe 模式只记录本来会接受的推断任务，显式请求仍可执行。先检查决策记录，再根据书面规则启用推断任务的自动接受。

GitHub 请求如何变成 Agent 工作流

跟随一次请求理解授权、任务执行与交付，再判断哪些机制适合自己的工作方式。