有来源的任务请求
GitHub 与可选飞书事件进入受策略约束的路由流程。允许的请求者、消息接收范围与团队规则，共同决定一条请求能否转为工作。
DSH Superagent Prototype
了解 DeepSeek 的主动编程 Agent 研究原型，如何将 GitHub 与飞书中的授权请求转为任务。参考任务路由、范围管理和结果交付机制，构建或优化自己的 Agent 工作流。
把 Issue 请求转成有范围的代码任务
从允许处理的仓库请求及结果返回位置出发，研究 DSH 从请求到任务单和草稿 PR 的方式。请求保留发起者授权与原始范围，并将连接和执行权限作为独立前提核对。
带入 Floatboat 的请求
请求可预览和复制，不会从此处自动发送。
参考来源: DSH Superagent Prototype https://github.com/deepseek-ai/dsh-superagent-prototype 先阅读原始说明并核对当前环境与依赖。需要安装或连接新工具时，先提出方案。 我的任务: 阅读 DSH Superagent 原型的配置与授权文档，为我的仓库设计 Issue 到草稿 PR 的流程。列明请求者权限、重复事件处理和必要审批，任何账号、Webhook 或服务配置前先给出方案。 期望交付: 包含授权检查、重复请求处理与可审阅交接的请求到工单流程。
关于 DSH Superagent Prototype
DSH Superagent Prototype 是 DeepSeek 官方 GitHub 组织发布的主动编程 Agent 研究原型。它作为 DeepSeek Harness 的扩展包运行，面向单个 GitHub 仓库，也可接收飞书消息；授权请求会转为任务，在独立会话和工作目录中执行，再把结果送回原讨论。
值得借鉴的机制包括请求评估、任务范围管理，以及跟进讨论时区分上下文与新增授权。网页面板优先呈现需要人工处理的事项，同时提供历史记录和运行健康信息，帮助团队跟踪任务与结果。
仓库采用 MIT 许可，README 明确其并非正式 DeepSeek 产品，也不属于生产就绪软件。公开实现与内部版本、配套设计文章并不完全一致，文章中的部分设计尚未实现，采用时应以实际代码和文档为准。
从团队请求到 Agent 任务
消息进入 DSH 后，还需要对应可问责的来源、明确范围和结果回传位置。这些机制使仓库任务能够追溯，收到请求本身则不能代替授权判断，也不能证明结果已经被接受。
有范围的独立执行
已接受的工作会建立 Ticket，并通过 Mandate 记录授权范围。执行者使用独立会话和目录，订阅讨论则为后续步骤补充上下文。
回到原讨论的交付
Agent 可以在原会话中回复结果并创建 Pull Request。面板汇集待审阅、受阻及其他需要人工关注的事项，方便继续推进任务。
DSH Superagent Prototype的使用场景
仓库维护和审阅跟进需要回到同一任务，消息触发还要明确谁有权提出请求。DSH 的交接方式可用于设计可追踪的请求链，同时保留原范围、结果回传位置及单独核验的连接条件。
处理仓库维护请求
仓库维护可以按请求、任务单和草稿 PR 的链路组织。开始前限定编码需求、允许修改的文件和验收条件，交付时将验证证据附到拟议变更上。这样既方便追溯和审阅结果，也不会把生成草稿 PR 误当作变更已经获准。
跟进评审与后续反馈
审阅反馈应关联到对应任务及原始授权。安排后续处理时保留已有范围，将无关需求单独分流，不在原任务中静默扩大工作。交接说明应让人看清本轮正在处理哪些评论，以及哪些新要求还需要另外决定。
把团队消息变为交付目标
由消息触发的工作流，需要明确允许的频道、请求人和结果返回位置。先定义触发、授权、任务分配和交付链路，再将这种交接方式借鉴到 Floatboat 中组织的工作。连接要求应独立核验，不能因为流程相似就假定已有内置集成。
启用任务前审阅执行边界
路由和工作进程的环境，需要与请求者规则及推断任务处理一起检查。依据当前运行前提，明确原型使用哪个账号、仓库和操作系统权限。将观察设置、执行授权及机器隔离分开，再决定可以接受哪种限定实验，之后才考虑真实仓库请求。
准备 DSH Superagent 运行环境
运行原型需要兼容 Harness 环境、模型访问和专用仓库身份。以下条件同时涉及操作系统权限；独立会话与凭据包装本身不构成沙箱，不能据此假定路由或工作进程已被隔离。
准备运行环境和 Agent 身份
需要受支持的 Harness 版本、已配置的模型服务和文档列出的命令行依赖。一次部署面向一个 github.com 仓库，通过专用 GitHub 用户账号执行操作。
划清机器与账号权限
文档中的路由与工作预设以操作系统用户身份拥有完整执行权限。独立会话和凭据包装并非沙箱；需要隔离时，应使用专用操作系统账号。
检查 DSH Superagent 的任务判断
观察记录可帮助判断推断任务是否适合自动接受，但 observe 模式中的明确请求仍可能执行。核对权限和任务记录时必须保留这个区别，不能把该模式当作全面阻止执行的开关。
先检查推断任务的判断
默认 observe 模式只记录本来会接受的推断任务，显式请求仍可执行。先检查决策记录，再根据书面规则启用推断任务的自动接受。
GitHub 请求如何变成 Agent 工作流
跟随一次请求理解授权、任务执行与交付，再判断哪些机制适合自己的工作方式。
相关软件项目
比较这些项目的用途、运行条件和源码许可。
DSH Superagent Prototype 常见问题
DSH Superagent 是 DeepSeek 模型吗？
它是在 DeepSeek Harness 上运行的 Agent 应用代码，推理由另行配置的模型服务提供。项目本身不是模型权重，也不包含模型 API 订阅。
它与 DeepSeek Harness 有什么区别？
Harness 提供 Agent 运行环境与扩展机制；Superagent 是基于它构建的扩展包，负责仓库中的请求接收、任务管理、会话执行与结果交付。
必须接入飞书吗，支持所有 GitHub 环境吗？
飞书是可选入口。当前文档限定一次部署面向一个 github.com 仓库，不支持 GitHub Enterprise Server。执行身份需要具有仓库写权限的专用 GitHub 用户账号，而非 GitHub App。
observe 模式会阻止全部任务执行吗？
不会。它会评估推断任务，并记录本来会接受的结果，但不真正接受这些任务。显式请求在所有模式下仍可执行；推断任务自动接受需要启用 auto 模式并匹配规则。
独立工作目录能隔离我的电脑吗？
不能。独立任务目录和账号包装不构成安全沙箱。文档中的预设拥有操作系统用户的完整执行权限，因此部署指南建议使用只放置 Agent 凭据的专用操作系统账号。
MIT 是否意味着已经成熟并且推理免费？
MIT 适用于源码，模型服务和机器运行另有费用与条款。README 将其定位为研究原型，公开版与内部实现存在差异，设计文章中的部分方案也尚未实现。