DeepSeek开源多智能体编程原型

DeepSeek正把编程智能体的探索重点，从单个会话中的代码生成推向多任务协作架构。根据MarkTechPost于2026年11月1日发布的报道，DeepSeek Harness团队开源了dsh-superagent：一个采用MIT许可证、围绕单个GitHub仓库工作的主动式编程智能体研究原型。它以Router接收和分派请求，再让相互隔离的Worker并行处理任务，目标是让开发者减少盯守多个会话的时间。项目同时发布设计文章《Exploring Super-agent Design: Towards a More Autonomous Agent System》，解释其走向更自主智能体系统的设计思路。

从管理会话转向管理授权任务

dsh-superagent使用TypeScript编写，以DeepSeek Harness扩展包的形式提供，初始版本为v0.1.0，以1次提交发布。它并未绑定某个指定模型，而是使用Harness配置档案中选定的模型。系统监听GitHub事件，也可以选接飞书；当获准的人员向它提出请求时，它会创建名为Ticket的工作项。每个Ticket拥有独立的智能体会话和工作目录，结果返回原始对话，常见交付形式是拉取请求。虽然项目定位包含“主动式”能力，其工作仍建立在明确授权之上，并非看到任意消息都会直接修改代码。

团队提出这套架构的出发点，是人类注意力可能比模型能力更早成为并行工作的瓶颈。据原文引用的凤凰网对相关报告的转述，一个人能够主动跟进的会话通常只有3至5个。如果工具仍以单个会话为基本单位，开发者同时推进多项工作时，就必须不断切换上下文、查看进度并判断哪些信息需要回应。dsh-superagent因此提供本地网页面板，只列出需要人工介入的事项，把日常执行过程交给后台处理。

README把核心原则概括为“尽可能少地占用人的注意力，尽可能多地提供价值”。配套理念文档进一步将其落实为交互规则：接到任务后确认一次，工作期间保持安静，只有拿到结果、需要提问或执行失败时才再次发言。这意味着项目衡量自主性的视角不仅包括能否完成任务，也包括能否控制通知频率、避免让用户承担持续监督多个会话的负担。

Router分派，Worker隔离执行

架构分为Router和Worker两层：长期运行的Router负责交互、判断和调度，隔离的Worker会话负责实际执行。具体流程从Source产生事件开始，GitHub或飞书事件转化为Trigger，再由Eval判断一批Trigger是否构成新的工作请求。获准任务形成Ticket，其中附带不可变的Mandate，记录这项工作为什么有权继续执行。任务建立后，Subscription会把拉取请求上的后续评论送达对应Worker，无须参与者每次重新提及智能体。这里的关键，是把消息入口、授权依据和任务执行分别建模，减少不同任务之间的上下文干扰。

主会话运行dsh-superagent-router预设，工具集合较小；每个Worker运行dsh-superagent-worker预设。根据执行文档，Shell命令运行超过5秒后会转入后台，使Worker能够继续接收消息，而不必一直阻塞在命令执行上。主动工作的接受机制则设有off、observe、auto三种模式，默认采用observe：系统只记录自己原本会接受哪些任务，不据此自动开工。团队需要主动切换模式，才能开放更积极的接单行为。

部署也有明确要求：系统运行在用户自己的机器上，使用专门的DeepSeek Harness配置档案，需要Node.js 22.19+或24+、git 2.32+、Python 3.8+、tmux，以及GitHub CLI 2.48+。本地运行让团队能够掌握执行环境，但原文特别指出，智能体拥有运行它的操作系统用户的完整权限，因此使用前应隔离环境。任务目录和会话的隔离有助于组织并行工作，却不能据此认定系统已经具备操作系统层面的安全沙箱。

模拟测试提速，真实编码仍待验证

性能测试围绕模拟群聊和GitHub持续集成消息流展开：每轮约300条消息，其中约20条是真正的工作请求，每种方案运行5次。Super-agent的任务完成时间p50为12.4分钟，p95为15.7分钟；采用中性提示词的“单会话加子智能体”基线，p95为29.5分钟，未给出p50。按p95耗时比较，原型约快1.9倍。不过，基线在5次运行中调用子智能体的次数为0次，说明测试结果不仅涉及架构差异，也受到基线是否实际启用并行委派的影响，不能直接等同于对所有多智能体编程工具的全面胜出。

负载测试显示，当消息到达速率从每分钟约1条升至40条时，Router批处理规模从1.0增至2.8，单请求延迟由2.5秒升至3.9秒。另一项消融实验移除了事件直接透传机制，Router决策次数随之增加约30%，缓存读取Token增加约37%，从23.23M升至31.77M，即约2323万增至3177万。这表明将已知归属的事件直接送到对应Worker，可能减少重复调度开销。但这些数字均为团队自报，并经相关报告的二手报道传递；测试仅使用合成消息和模拟工具，没有衡量真实编码质量，也无法据此推断真实仓库中的缺陷修复成功率或最终交付质量。

与现有编程智能体的差异在哪里

原文将其与GitHub Copilot云端智能体、Claude Code Action和OpenAI Codex比较。在触发方式上，dsh-superagent依靠获准人员提及和书面规则，可选接飞书；Copilot支持Issue指派、聊天、API、Slack等入口，也列有Teams聊天来源，并可通过自动化主动开展工作。Claude Code Action支持@claude提及、Issue指派及工作流提示词，可由工作流事件触发主动执行，原文未披露其聊天来源。Codex列出的入口为Slack中的@Codex及云端任务，聊天来源为Slack，原文未披露其无人请求时主动工作的机制。dsh-superagent明确为每个Ticket建立独立并行会话，另外三款产品在该对照表中没有披露相同维度的信息；“未披露”并不代表没有相关能力。

运行位置和获取方式同样不同：dsh-superagent在本机Harness配置档案中运行，目前仍是MIT许可的研究原型；Copilot在GitHub后台运行，面向所有付费Copilot套餐，原文未披露其许可证；Claude Code Action运行在用户的GitHub Actions运行器上，采用MIT许可证，需要用户自己的API密钥或云服务提供商支持；Codex云端任务运行于Codex云环境，面向ChatGPT Plus及以上用户，原文另外注明其CLI智能体开源。由此看，dsh-superagent的鲜明特点是把授权任务、消息订阅和独立执行会话组织成可研究的开源架构，而真实使用成本仍需结合所选模型、运行机器和任务负载评估。

团队还提出了超出当前原型范围的方向，包括外部Watchdog监督机制、存储与计算分离，以及异步ReAct循环，这些仍属于后续设计探索。对于开发团队，当前版本提供了一个观察多智能体调度如何减少注意力消耗的具体样本；下一步能否证明价值，取决于它在真实仓库、真实工具和持续协作中，是否既能稳定完成工作，又能准确识别何时需要人工介入。模拟任务的耗时改善已经展示了调度设计的潜力，真实代码质量与长期运行可靠性则仍需进一步验证。