DeepSeek 发布 Super-agent 新架构：双智能体并行与自动执行闭环落地真实研发流程

作者：李嘉佑 59分钟前

一、事件概述：从「等指令」到「找活干」的架构发布

10月31日晚间，DeepSeek Harness团队通过官方公众号发表技术文章《Super-agent设计探索：迈向更自主的Agent系统》，正式公开其面向自主智能体探索的全新架构Super-agent（超级智能体），相关原型已同步在GitHub开源，仓库为deepseek-ai/dsh-superagent-prototype，采用MIT协议。需要强调的是，团队在文章开头即明确边界：本文是一篇面向工程实践的架构思路探讨，并非对DeepSeek Harness现有产品功能的介绍；开源仓库README亦标注「仅作研究参考，不是DeepSeek官方产品」。

DeepSeek在文章中给出的问题陈述直指当前智能体产品的结构性瓶颈：现有主流Agent设计仍以单一Session（会话）为基本单位，不同会话之间彼此独立，用户并行推进多项工作时必须手动切换并记住各个会话的上下文。据团队观察，一个人通常只能同时跟进3至5个活跃会话——在这种设计下，单任务的上限取决于模型能力，多任务的上限取决于人的注意力。

基于这一判断，Super-agent的定位是打破Agent与单次手动会话的绑定，使其成为能跨会话保持上下文、同时推进多项复杂任务且互不干扰的连续实体。团队将其归纳为四项基础特征：连续、高效、主动、持久。基于同一思路构建的内部实例，已在DeepSeek日常研发中持续运行，参与问题复现与修复、代码审查响应以及Harness自身的迭代。

二、技术拆解（上）：Router与Worker双智能体并行机制

Super-agent架构的第一根支柱是双层设计。上层为常驻的Router（路由）层，统一承接来自即时通讯群聊、GitHub、邮件等多渠道的人类交互，负责接收消息、分配任务和维护全局上下文；下层为Worker（执行）层，由多个上下文彼此隔离的Worker会话组成，并行执行问题复现、代码审查、功能开发等具体工作，必要时可在内部再创建Subagent。

两层的分工逻辑十分明确：Router层为了避免全局节点成为性能瓶颈，在设计上不直接执行具体任务，只负责交互与任务分派，甚至可以不配备Bash工具，团队实践显示其任务复杂度不高、使用较轻量的模型即可兼顾速度与效果；Worker层直接决定交付质量，通常配置能力最强的模型，但不与人类直接交互，其推理过程和工具调用统一向Router汇报后对外回复。这与常见的Agent Team（智能体团队）形成区别——后者用于单个复杂任务内部的步骤拆解，Team Lead需要深入理解任务细节；而Super-agent的Router只处理任务之间的高层关联与分派。

支撑并行的关键机制是「订阅与直通」。同一个GitHub Pull Request、同一个即时通讯话题下的连续事件构成一条Thread（事件流），Router根据初始事件创建Worker后，该Worker直接订阅对应Thread，后续事件由程序直通发往该Worker，无需再经Router层层转发；订阅关系为多对多，当多个Worker在同一共享环境中交集时，会收到相同事件通知，从而有机会自行发现并解决冲突。

在事件入口侧，系统采用两级过滤以应对真实群聊「高噪音、低触发率」的特征：程序层策略作为Fast Path，先对事件来源、群组范围、白名单等确定性条件做代码级快筛；通过筛选的候选事件再交由大模型构成的语义层Slow Path判断是否需要行动。配合「计算、状态与执行环境分离」的存算分离设计与独立Watchdog（看门狗）机制——后者在主系统之外以外挂Agent的形式监控任务是否陷入无效循环并尝试修复——构成「主动」与「持久」两项特征的工程基础。

三、技术拆解（下）：自动修复与直接提交的执行闭环

在日常研发协作场景中，Super-agent最具代表性的是「主动执行闭环」：环境事件（Trigger）——包括群聊消息、邮件与日程提醒、代码审查评论、CI运行结果——持续流入系统，Agent不再等待人类逐条下达指令，而是持续观察环境并主动推进值得处理的事项。

团队披露的内部实例展示了这一闭环的真实运行样态：同一个开发任务可以在即时通讯群聊与GitHub之间连续推进——用户先在群聊中提出采用方案A，随后在GitHub Pull Request评论里改为方案B，系统能理解前后变化并调整执行方向；更典型的场景是，团队其他成员在公共群聊中讨论一个软件缺陷时，即使无人@AI，系统也能识别出这是一条具体缺陷，在后台自动复现并排查代码，找到修复方案后直接提交修复Pull Request，附前后对比截图。团队披露的一则案例显示，针对桌面端「窗口未聚焦时单击被误识别为双击」的缺陷，Super-agent静默复现后定位到根因并提交了修复PR。若未找到有效结果，则保持安静、避免打扰——这对应其「投机执行」设计：在结果是否会被采用尚不确定时先行后台尝试，有价值则交付、无价值则丢弃。

安全边界同样被明确设计。据海外媒体对开源文档的核验，授权模块提供off、observe（默认）、auto三种模式：默认的observe模式仅记录Agent本会采取的动作而不实际执行；Agent使用独立的GitHub账号而非运维者本人账号；自动合并默认关闭，在Agent的Pull Request保持正确记录一段时间前由人来执行合并。

四、效率数据核验：「缩短近一半」的口径与证据链

本次发布最受关注的数据是任务完成时间。根据团队披露的初步实验：在每次约300条消息、其中约20条为工作请求的合成协作负载测试中，多种配置重复测试5次，Super-agent的任务完成时间中位数（p50）为12.4分钟，95分位（p95）为15.7分钟；作为对照，传统单会话加Subagent工具方案在中性提示下95分位达到29.5分钟，且五轮测试中均未发生委派。以95分位口径计，29.5分钟降至15.7分钟，降幅约46.8%——「缩短近一半」的表述即来源于此。

但该数据的适用边界必须如实呈现：其一，实验基于合成负载与简化环境，团队自己称之为初步实验；其二，测试中编码本身由纯耗时工具替代，实测的是调度能力而非代码质量。因此这组数据证明的是「系统层接管会话调度」的可行性，而非端到端研发效率的普遍结论。

效率的另一面是成本。实验显示，若取消订阅直通机制，Router决策次数增加约30%，读缓存Token从2323万增至3177万，增幅约37%，而完成时间基本持平——这说明直通机制是影响系统成本结构的关键设计。Router层的批处理机制则在压力场景下发挥作用：事件到达速率从每分钟约1条升至约40条时，积压事件合并处理使单个决定分摊的推理时间从6.4秒降至1.6秒

图1 Super-agent与单会话方案任务完成时间对比（初步实验）　

图2 Router批处理压测：单个决定分摊的推理时间　

图3 取消订阅直通后的读缓存Token变化　

五、范式之变：智能体协作与自动执行闭环的行业影响

判断这次发布的行业意义，关键不在模型本身——Super-agent并非新模型，团队也坦言「并没有提出全新的理论，而是将计算机系统中经典的工程思想应用到了Agent系统的构建中」，任务调度、事件驱动、存算分离、看门狗等均源自操作系统与体系结构的经典设计。真正值得注意的是路径变化：当模型执行单个任务已越来越不需要人工干预，产业竞争的焦点正从「模型能不能把一件事做好」转向「系统如何让多个任务被持续、并行、可靠地完成」。

这一转向与权威机构的判断相互印证。Gartner于2026年5月20日发布新闻稿指出，企业级AI编码智能体市场已进入扩张与竞争重排的新阶段，竞争正从追求「最神奇的开发者体验」演变为运营卓越、商业成熟度与企业级就绪度的较量；Gartner同时预测，到2027年，使用智能体化编码的工程团队中超过65%将把集成开发环境（IDE）视为可选项，控制、治理与验证将转移到自动化平台。

政策环境亦在同步铺垫。国务院印发的《关于深入实施「人工智能+」行动的意见》明确，到2027年新一代智能终端、智能体等应用普及率超过70%，到2030年超过90%。在这样的框架下看，Super-agent所代表的「系统层接管会话管理、人上移到目标设定与结果验收」的思路，指向的是同一件事：智能体要从被动响应指令的工具，演变为持续在线、可并行处理多项任务的协作者，而人的注意力从「盯会话」中解放出来，转向决策与验收。

六、产业链影响：开发者工具链与研发执行方式

对开发者工具链而言，Super-agent的落地样态是「面向单个GitHub仓库的主动式编码Agent，打包为DeepSeek Harness的一个插件包，监听GitHub并可选接入飞书」。这意味着智能体的接入点正从IDE对话框延伸到代码仓库、即时通讯与CI系统——工作请求从这些环境事件中产生，结果以Pull Request等形式在原对话中交付。Gartner「IDE成为可选项」的预测，与这一产品形态的演进方向一致。

对研发执行方式而言，影响集中在两处。其一是成本结构的变化：多会话并行以更高的Token消耗换取时间与稳定性，缓存读取Token的37%增幅表明，事件路由设计的优劣将直接决定智能体系统的运行成本；其二是人的角色变化：在DeepSeek披露的内部实例中，工程师的日常介入点已从逐条下达指令，转变为在群聊中正常讨论问题、在GitHub上评审Pull Request，修复执行由系统后台完成。需要指出的是，这些表现来自团队内部环境，外部可复现性尚待开源原型在实际仓库中的验证。

同时应当保持克制：开源README明确该原型「可能仍包含缺陷、与团队内部版本并不完全一致」，其默认配置也刻意保守。对于考虑引入此类系统的企业研发团队，Gartner在上述新闻稿中提示的评估维度具有参考价值——除产品能力外，治理、定价、支持与商业成熟度同样是规模化的前置条件。

七、竞争格局与展望：多智能体路线的分野

将本次发布放进赛道坐标，可以看到多智能体编程正在分化出不同技术路线。海外媒体报道认为，DeepSeek此举与OpenAI、Anthropic旗下Claude Code、Codex等形成竞争，竞争焦点正从模型参数扩展到工作流调度与系统可靠性。国内刊发的另一条标志性动态是：微软研究院于10月24日以MIT协议开源Agensh框架（论文已于9月22日提交arXiv，编号2609.26781），其核心主张恰恰相反——去除中央编排器，让最多1024个编码智能体自行认领任务、自行合并代码；在ProgramBench最难五题上，智能体数量从1个、8个、32个增至128个时，平均通过率相应由19.31%、20.68%、26.52%升至28.78%。

两条路线形成有趣对照：DeepSeek的Router-Worker双层架构保留了全局协调节点，以「调度集中、执行分散」换取连续性与可控性；微软Agensh则将协调逻辑写进提示词，以彻底去中心化换取规模上限。二者的实验口径完全不同——前者测调度时延，后者测任务通过率——不能直接比较，但共同指向同一个判断：单模型能力之外，「智能体如何组织」已成为决定研发智能化的下一个变量。

展望后续，有三个值得跟踪的验证点：一是开源原型在外部真实仓库中的复现情况，尤其是调度效率数据能否脱离合成负载成立；二是「自动修复-提交」闭环在真实代码审查流程中的采纳率与正确率；三是企业级治理工具（授权模式、审计、成本核算）的成熟节奏。在上述验证完成之前，对「研发效率减半」类结论的引用应保持口径意识——它目前描述的是调度层面初步实验中的长尾压缩，而非软件工程生产率的普遍跃升。

图4 微软Agensh：智能体数量与ProgramBench五题平均通过率（GPT-5.6-sol）　

结论

DeepSeek Super-agent架构发布的核心价值，不在于刷新了某项模型基准，而在于把「智能体协作＋自动执行闭环」从概念推进到了可运行、可开源、可检验的系统方案：Router与Worker双智能体并行处理多任务，事件驱动的两级过滤与订阅直通降低噪音与开销，自动修复与Pull Request提交打通真实研发流程，Watchdog与存算分离支撑长期在线。初步实验中95分位任务完成时间从29.5分钟降至15.7分钟、缩短近一半的数据，证明了系统层接管会话调度的可行性，但其合成负载口径亦提示外部引用需保持边界。在Gartner所判断的企业级AI编码智能体市场「扩张与竞争重排」阶段，围绕「智能体如何组织」的架构竞争——集中调度还是去中心化协作——预计将成为下一阶段行业演进的主线之一。