专注AIGC技术的专业社区，关注大语言模型（LLM）的发展和应用落地，聚焦LLM及AI技术的市场研究和开发者生态，欢迎关注！
开发团队的群聊里冒出一个代码问题，接下来通常要有人把消息复制到任务系统、补齐背景，再找出谁来处理。
DeepSeek Harness团队想探索的，是让Agent接过其中一部分协调工作：从授权的信息源接收请求、分派给不同的执行会话，再把进展和结果带回原来的对话。
10月31日，团队发布《Super-agent设计探索：迈向更自主的Agent系统》，并公开了 dsh-superagent-prototype。这次的重点不是新模型，而是Agent如何跨会话组织任务、并行推进工作。公开代码聚焦单个代码仓库，供开发者参考和试用；部署前需要检查代码，并按实际环境调整。
Router接收和分派，Worker负责执行
Super-Agent的架构分为Router与Worker两层。
Router接收来自GitHub等渠道的消息，维护任务之间的关联，并判断请求该交给谁处理。Worker则在各自独立的会话和工作目录中推进任务，完成后把进度与结果交回Router，由Router统一反馈给人。
这种分工针对的是一个常见的开发负担：任务一多，开发者就得自己切换会话、记住每个任务的上下文，还要在不同窗口之间搬运信息。DeepSeek团队希望把这部分管理工作交给系统，让使用者更多关注任务本身和最终结果。
Router不需要介入每项工作的具体细节。它负责全局协调，Worker专注执行；Worker之间的上下文彼此隔离，以减少多个任务互相干扰。如果多个Worker参与同一个Pull Request，它们可以订阅相关讨论串，收到后续更新。
公开代码从单个仓库开始
项目README介绍，`dsh-superagent`以DeepSeek Harness插件形式运行，围绕单个代码仓库工作。它可以监听GitHub，也可以选配飞书。获准用户提出任务后，系统创建工作项，在独立会话和目录中执行，再回到原对话汇报，例如提交Pull Request。网页面板则集中显示需要人工处理的事项。
这套设计包含“主动处理”的设想，但不等于Agent可以随意监控、接管团队工作。公开原型围绕授权请求和团队预先设定的规则运行。至于根据环境事件识别问题、主动推进任务，设计文章展示了团队内部的探索案例；它和开发者下载后即可使用的功能范围并不完全相同。
这个原型可以读取消息、访问代码仓库并运行命令。项目部署文档提醒，Worker会以运行者的操作系统账户执行命令，账号凭证的包装本身并不构成系统隔离。对开发团队来说，真正部署前还要审查代码权限、运行账号和执行环境。
测试看调度效率
设计文章披露了一组初步测试。每轮约有300条消息，其中约20条是工作请求，每种方案重复运行5次。团队报告称，Super-Agent方案完成任务的中位时间（p50）为12.4分钟，95分位时间（p95）为15.7分钟；对照组中，单Session方案在中性提示配置下的p95为29.5分钟。
这组数据关注的是任务调度和协作速度，不是代码正确率或编程能力排名。测试使用合成负载和简化环境，因此这些时间不能直接套用到真实研发项目中。
Router压力测试关注另一件事：消息集中涌入时，系统能否合并处理，避免每条事件都单独触发一次推理。测试中，事件速率从每分钟约1条升至约40条，平均批处理大小由1增至2.8；团队报告的单个决策分摊推理时间则从6.4秒降至1.6秒。这是特定测试条件下的结果，实际效果还会受到消息类型、任务复杂度和系统负载影响。
Agent要长期工作，权限和恢复机制得跟上
一个Agent同时启动多个Worker只是起点。长期运行时，系统还得判断消息是否可信、任务有没有偏离目标、权限是否合适，以及某个执行环节出错后能不能恢复。
DeepSeek团队在设计中加入了Watchdog，用来监控接口错误、恢复失败和Worker的任务进展。文章也讨论了长程记忆、Agent之间的通信、安全与隐私等问题。这些因素关系到系统能否从演示走进日常工作：任务做得快固然重要，但出了问题能否发现、能否及时叫人介入，同样决定它是否可靠。
Super-Agent的看点，是把编程Agent从“一个会话处理一项任务”往“多个任务由系统协调推进”拓展。Router和Worker的分工并不新鲜，真正需要验证的是它们能否长期保持上下文、按权限办事，并在复杂协作中稳定交付。DeepSeek这次放出的原型，提供了一个可以研究和试用的起点；离团队能放心交付日常开发任务，还有实际使用这一关要过。
