DeepSeek开源代理原型：多个代理并行干活，只在需要你拍板时开口

10月31日，DeepSeek Harness团队发布了一篇设计文章《探索超级智能体设计：迈向更自主的智能体系统》，并附带了一个采用MIT许可证的研究原型，名为dsh-superagent-prototype。

其理念并非新的基础模型，而是围绕现有模型驱动的工具进行编排，专为单个GitHub仓库构建。一个持久的Router会话负责处理传入对话和调度决策，但自身不执行实际工作。每个被接受的工作项都会获得独立的Worker会话和目录，因此任务可以并行运行而无需共享上下文。该原型监听GitHub事件，并可选择监听飞书消息，然后在原始对话中返回结果，通常以拉取请求的形式呈现。本地Web面板仅列出需要人工决策的事项。

其声明的理念直截了当：尽可能少占用人工注意力，尽可能多提供价值。智能体应只确认一次，工作时保持静默，仅在出现结果、问题或失败时再次发言。它只应在被授权人员请求或团队编写的规则允许工作时采取行动。对于仅凭推断的工作，文档默认模式为仅观察：记录其将采取的行动，但不执行。

DeepSeek的论点是，当前瓶颈在于人工注意力，而非模型能力。团队表示，一个人一次只能主动跟进3到5个智能体会话。在其自身模拟测试中，每次运行约300条消息和约20个真实工作请求，超级智能体方法完成最慢的5%任务耗时15.7分钟，而单会话基线为29.5分钟。

将这些数字视为自我报告，而非独立基准。测试使用了合成消息和模拟工具，未衡量真实编码质量，且尚未与Claude Code或Codex进行验证性比较。DeepSeek还异常明确地指出了原型限制：这是研究代码，非官方产品或生产就绪版本，可能包含错误，与内部系统不同，且部分文章理念是未来方向，而非已实现功能。据报道，内部实例已用于错误复现、代码审查和Harness工作，但这是团队的说法。

讨论：Router加Workers的拆分是否合理，还是只是并行会话的更好听说法？你会在主动工作方面划出什么界限？你会让智能体在你的仓库中打开拉取请求吗，以及在它接触任何内容之前，你会要求哪些权限和团队编写的规则？

来源：GitHub上的DeepSeek dsh-superagent-prototype；10月31日MarkTechPost（https://www.marktechpost.com/2026/11/01/deepseek-dsh-superagent-router-worker-coding-agent/）和Venture Atlas（https://www.ventureatlas.org/news/2026-10-31-deepseek-superagent）的报道。

―― 高票评论（帖子共2条讨论）――

[+1] u/Even_Success1295：如果你曾见过单个智能体在任务中途因上下文窗口而绊倒，这种拆分就说得通了。

[+1] u/Alone-Dragonfruit602：权限部分是我真正信任的。默认仅观察，在人工确认前无写入权限。我很乐意让它在沙盒中处理副项目，仅起草拉取请求。让它带着合并权限在主仓库上自由操作，那才是我担心的地方。