DeepSeek Harness团队于2026年10月31日发布技术文章《探索Super-agent设计：迈向更自主的智能体系统》，并开源MIT许可项目dsh-superagent-prototype。这套方案试图解决一个实际问题：当智能体同时处理多项任务时，人要在不同会话间切换、跟进进展，注意力可能成为瓶颈。早期测试结果显示任务耗时缩短，但测试使用的是合成消息流，并非对真实软件开发质量的验证。125

Router负责调度，Worker负责执行

设计将协调工作与具体执行分开：长期运行的Router接收交互、掌握整体任务状态并分派工作；相互隔离的Worker则并行处理各自任务，再向Router汇报。团队提出，单项任务的表现受模型能力影响，而并行处理多项任务时，人类跟踪和协调会成为限制因素。92250

现有材料支持“人的注意力可能成为多任务瓶颈”这一总体判断，但无法证实每个人只能同时管理三至五个智能体会话。这个数字不应被当作已经测得的结论。

设计还提出事件驱动、异步多渠道交互，以及将状态存储与计算分离等思路：系统可根据事件判断是否需要启动工作，并让任务状态不必依附于某个正在执行的会话。团队也描述了一个独立于主系统的外部Watchdog，用来监测任务进展，并协助处理常规进程健康检查难以发现的问题。这些属于设计思路，并不意味着公开原型已实现所有功能。2025

“静默复现并修复”如何运作

据报道，DeepSeek Harness内部曾设置“静默复现并修复”工作流：团队成员在群聊里反馈软件问题后，智能体可在后台尝试复现问题并寻找简单修复方案，即使没有人明确@它也可以启动。只有在确认问题并找到简单的修复办法后，它才会提交结果；否则就保持安静。20

另有报道提到，内部Super-agent实例已用于复现和修复问题、回应代码审查意见，以及参与DeepSeek Harness自身的迭代。这些是关于内部使用情况的报道，并不能证明公开原型具备相同能力或已在相同场景部署。1922

公开原型的范围有多大？

公开发布的dsh-superagent-prototype是一个为单个GitHub仓库设计的DeepSeek Harness组件，也可以选择接入飞书。获准用户提出请求后，系统会创建工作项，为其分配独立的智能体会话和目录，完成后再回到原对话中回复，例如提交一个Pull Request（拉取请求）。83545

代码文档还说明，Worker并发数量受可配置的槽位上限约束。这意味着原型具备限制并行任务数量的机制，并不代表系统存在一个适用于所有部署的固定会话数；设计中设想的多渠道系统也不等于已完整包含在公开版本里。32

项目仓库明确标注：这是“仅供参考的研究原型”，不是DeepSeek官方产品，也不是可直接用于生产环境的软件。README提醒代码可能存在缺陷，工程风格也可能不一致；公开版本经过调整，与内部系统以及设计文章中描述的实现并不完全相同。1237

测试结果说明了什么？又没有说明什么？

据报道，设计在测试中取得的最佳95百分位任务完成时间为15.7分钟，单会话基线为29.5分钟，前者约低47%。相关报道提到，测试使用合成消息流和模拟工具，每轮约包含300条消息。253

这组数据反映的是特定测试条件下的任务耗时比较，不能据此认定系统能写出更好的代码、正确修复真实缺陷，或已具备生产环境所需的可靠性与安全性。有报道提及Token成本较高，但现有材料不足以证实“缓存读取Token增加约37%”这一具体说法。23

热度不等于采用，更不等于可靠

现有材料无法独立核实该原型曾达到459或563个GitHub星标，也无法确认社区在数小时内推出改编版本的说法。另有报道提到，DeepSeek的deepseek-harness仓库星标数已超过18.8万，但这并不能证明开发者已广泛采用这个原型，更不能代表他们信任它的代码产出。23

目前能够确认的结论更为有限：DeepSeek分享了一种减少多会话协调负担的工程思路，并发布了范围有限的研究原型和早期合成测试结果。这个项目值得用来了解Router与Worker如何分工，但仓库本身的免责声明，以及测试证据的局限，都提醒读者不要把它当成已经成熟的自主编程产品。21237

DeepSeek Harness团队于2026年10月31日发布技术文章《探索Super-agent设计：迈向更自主的智能体系统》，并开源MIT许可项目dsh-superagent-prototype。这套方案试图解决一个实际问题：当智能体同时处理多项任务时，人要在不同会话间切换、跟进进展，注意力可能成为瓶颈。早期测试结果显示任务耗时缩短，但测试使用的是合成消息流，并非对真实软件开发质量的验证。125

Router负责调度，Worker负责执行

设计将协调工作与具体执行分开：长期运行的Router接收交互、掌握整体任务状态并分派工作；相互隔离的Worker则并行处理各自任务，再向Router汇报。团队提出，单项任务的表现受模型能力影响，而并行处理多项任务时，人类跟踪和协调会成为限制因素。92250

现有材料支持“人的注意力可能成为多任务瓶颈”这一总体判断，但无法证实每个人只能同时管理三至五个智能体会话。这个数字不应被当作已经测得的结论。

设计还提出事件驱动、异步多渠道交互，以及将状态存储与计算分离等思路：系统可根据事件判断是否需要启动工作，并让任务状态不必依附于某个正在执行的会话。团队也描述了一个独立于主系统的外部Watchdog，用来监测任务进展，并协助处理常规进程健康检查难以发现的问题。这些属于设计思路，并不意味着公开原型已实现所有功能。2025

“静默复现并修复”如何运作

据报道，DeepSeek Harness内部曾设置“静默复现并修复”工作流：团队成员在群聊里反馈软件问题后，智能体可在后台尝试复现问题并寻找简单修复方案，即使没有人明确@它也可以启动。只有在确认问题并找到简单的修复办法后，它才会提交结果；否则就保持安静。20

另有报道提到，内部Super-agent实例已用于复现和修复问题、回应代码审查意见，以及参与DeepSeek Harness自身的迭代。这些是关于内部使用情况的报道，并不能证明公开原型具备相同能力或已在相同场景部署。1922

公开原型的范围有多大？

公开发布的dsh-superagent-prototype是一个为单个GitHub仓库设计的DeepSeek Harness组件，也可以选择接入飞书。获准用户提出请求后，系统会创建工作项，为其分配独立的智能体会话和目录，完成后再回到原对话中回复，例如提交一个Pull Request（拉取请求）。83545

代码文档还说明，Worker并发数量受可配置的槽位上限约束。这意味着原型具备限制并行任务数量的机制，并不代表系统存在一个适用于所有部署的固定会话数；设计中设想的多渠道系统也不等于已完整包含在公开版本里。32

项目仓库明确标注：这是“仅供参考的研究原型”，不是DeepSeek官方产品，也不是可直接用于生产环境的软件。README提醒代码可能存在缺陷，工程风格也可能不一致；公开版本经过调整，与内部系统以及设计文章中描述的实现并不完全相同。1237

测试结果说明了什么？又没有说明什么？

据报道，设计在测试中取得的最佳95百分位任务完成时间为15.7分钟，单会话基线为29.5分钟，前者约低47%。相关报道提到，测试使用合成消息流和模拟工具，每轮约包含300条消息。253

这组数据反映的是特定测试条件下的任务耗时比较，不能据此认定系统能写出更好的代码、正确修复真实缺陷，或已具备生产环境所需的可靠性与安全性。有报道提及Token成本较高，但现有材料不足以证实“缓存读取Token增加约37%”这一具体说法。23

热度不等于采用，更不等于可靠

现有材料无法独立核实该原型曾达到459或563个GitHub星标，也无法确认社区在数小时内推出改编版本的说法。另有报道提到，DeepSeek的deepseek-harness仓库星标数已超过18.8万，但这并不能证明开发者已广泛采用这个原型，更不能代表他们信任它的代码产出。23

目前能够确认的结论更为有限：DeepSeek分享了一种减少多会话协调负担的工程思路，并发布了范围有限的研究原型和早期合成测试结果。这个项目值得用来了解Router与Worker如何分工，但仓库本身的免责声明，以及测试证据的局限，都提醒读者不要把它当成已经成熟的自主编程产品。21237