DeepSeek 团队在 GitHub 发布了 dsh-superagent 研究原型，展示将 GitHub 协作与可选飞书消息串成受约束任务流的实验性智能体方案。项目为参考性原型，强调授权策略、执行隔离与观察/自动模式的差异，非正式产品且未达生产就绪。
DeepSeek Harness 团队于 2026 年 10 月 31 日在 GitHub 公开 dsh-superagent 研究原型，尝试把 GitHub 协作、可选的飞书消息与代码任务执行串成一条工作流：获准任务可由智能体在独立会话和目录中处理，再回到原讨论交付结果，例如创建拉取请求。项目说明同时明确，它仅供参考，不是正式 DeepSeek 产品，也未达到生产就绪状态。原型仓库
仓库提交记录显示，团队在 10 月 31 日提交了首个原型版本；这能确认公开仓库的提交日期，却不能单独证明确切上线时刻。README称，代码为公开发布作过调整，与团队内部版本及设计文章所描述的实现并不完全相同，部分设计仍属未来方向。因而，这次公开的重点是一个供参考的协作代理实验，而不是 DeepSeek 宣布了可直接部署的完整产品。
核心变化是把协作消息变成受约束的任务
与只在对话中回答问题的助手不同，dsh-superagent 面向单个 GitHub 仓库工作，并可选择监听飞书。项目文档描述的流程包括接收讨论、形成工作项、在专属会话和目录中执行，再把结果送回原始对话；Web 面板则集中呈现需要人员处理的事项。这样的设计试图减少团队逐条转交任务的负担，但也让“哪条消息能授权代理行动”成为系统设计的关键问题。
授权文档把显式请求与推断出的候选工作区分开来。获准用户直接向代理提出请求，可进入明确授权路径；从普通消息推断出的候选，则受到策略和规则约束。项目说明的默认 observe 模式会评估并记录推断候选，而不自动接受；auto 模式也只有在匹配已启用规则时，才允许这类候选继续。文档还指出，明确请求在不同模式下仍可工作。因此，observe 不能简单理解为系统完全只读，也不能据此推断所有外部操作都必经人工确认。授权机制文档
授权也不是一次开关就能概括。文档描述了执行中的任务、后续消息归属、策略变更后的重新校验等情形；策略调整不会被等同为对所有进行中工作的即时撤销。换言之，真正决定边界的是允许名单、规则、任务范围和运行时如何处理后续消息，而不只是界面上选择 observe 或 auto。
Harness 提供运行底座，原型不等于成熟能力
DeepSeek 将 Harness 介绍为基于 Cordis 插件架构的开源运行环境，涵盖编码、研究、后台任务和插件扩展等用途。Harness 官方介绍为理解这个原型提供了背景：dsh-superagent 是构建在 Harness 之上的特定协作实验，而不是 Harness 本身的新版本，也不是新的基础模型发布。
这种组合说明，智能体进入团队工作流不仅取决于模型能否生成代码，还取决于消息来源识别、任务授权、执行隔离和结果回传等系统环节。原型把这些环节放进一个可供检视的项目中，但公开仓库并没有因此证明其安全性、稳定性或效率已得到独立验证。本稿依据公开仓库和文档核验，未安装或运行该软件。
对希望试验的团队而言，项目自身的“研究原型”标注应被视为实际边界：应先理解其授权策略与部署要求，再在隔离仓库和受控权限下评估；不应把示例流程当作生产承诺。MIT 许可证允许按许可证条件使用和修改代码，但许可证本身不是安全或可靠性背书。
AIFluxNews此前介绍过 DeepSeek Harness 的工作目录与 Git Worktrees 实验能力。两者相关但并非同一事件：前者讨论 Harness 运行时能力，此次则是把协作消息和授权流程组织成单仓库编码代理的研究原型。