DeepSeek团队又一次提出了一个新的概念，这就是最近几天很火的Super-agent 构想。而且DS团队还给了一个原型项目：https://github.com/deepseek-ai/dsh-superagent-prototype。给出了这个构想的一个初步解答方法。

在过去，我们使用 Claude Code、Codex 等 Coding Agent，

基本还是「人提出任务 → Agent 执行 → 人验收结果」的工作模式。

而 DeepSeek 希望让 Agent 从一个被动调用的工具，变成一个长期在线、能够主动发现问题、并行执行任务的数字员工。

一、Super-agent 到底解决什么问题？

10 月 31 日，DeepSeek Harness 团队发布《Super-agent 设计探索：迈向更自主的 Agent 系统》，感兴趣的大家都可以去读一下这篇文章。

官方提出了一个很有意思的观点：

单任务的上限取决于模型能力，多任务的上限取决于人的注意力。

不知道你们在日常生成中，使用code agent的时候，有没有关注到，自己经常需要在不同的agent中进行频繁切换。

举个实际的例子。假设我正在开发一个项目，同时打开了三个 Claude Code：

看起来三个 Agent 可以同时工作，效率应该很高。但实际情况是什么呢？

Agent A 写到一半，突然需要我确认技术方案；Agent B 找到了 Bug 原因，等着我批准修改；Agent C 发现测试不通过，又需要我提供额外的上下文。

于是我不得不在三个终端之间来回切换，不断阅读它们的输出、确认进度、补充 Prompt，甚至还得自己协调它们之间的依赖关系。

最后发现，虽然 AI 已经可以同时干三个人的活，但我却成了这三个 AI 的项目经理。

而且随着 Agent 数量增加，这种管理成本会越来越高。

你同时运行 10 个 Agent，并不意味着生产力就能提升 10 倍，因为人的注意力根本跟不上。

这也是 DeepSeek Super-agent 想解决的问题。

DeepSeek 认为，随着模型能力越来越强，这种由人来管理 Session 的方式反而成了生产力瓶颈。

二、技术上有哪些值得关注的设计？

它的核心思路可以概括为五个方面：

这些设计其实并不算全新的算法创新。Router/Worker、事件总线、任务队列、缓存、Watchdog，本来就是传统分布式系统中非常成熟的思想。

DeepSeek 的价值，是把这些工程机制重新组合进 Agent Runtime，让 Agent 不再受单个对话窗口的生命周期限制。 

具体我们可以以DS这个原型项目可以探讨一下。其核心目标很明确：

尽可能让 Agent 自己处理事务，只在真正需要人工参与的时候打扰开发者。

DeepSeek Super-agent 最核心的设计是

 Source → Trigger → Eval → Ticket → Executor。

当 GitHub 出现新的 Issue、评论或 CI 结果时，系统会创建 Trigger，并通过 Thread 将同一任务的相关事件关联起来，避免重复处理。

判断事件是否需要执行、是否已有 Agent 负责，以及是否具备执行权限。通过 Mandate 限制任务授权范围，避免 Agent 擅自扩大权限。

传统 Agent 以 Session 为中心，Session 结束任务也就结束了。

Super-agent 则通过 Ticket 保存任务状态，即使 Worker 中断或重启，也能恢复任务并继续执行。

当 Ticket 已经关联某个 GitHub Issue，后续评论、CI 失败、Review 意见等事件，可以直接投递给对应 Worker，无须 Router 重新判断。

很多人也在想，Super-agent和我们以前的Multi-Agent有什么区别？

传统 Multi-Agent 主要解决的是：如何让多个 Agent 协作完成一个复杂任务？

DeepSeek Harness 提出的 Super-agent 则进一步关注：如何让一个 Agent 系统长期运行，主动发现任务，并同时管理多个互不相关的任务？

Super-agent 可以理解为 Multi-Agent + Agent Runtime + Event Bus + Persistent Memory + Scheduler。它是把传统 Multi-Agent 从单次任务执行提升到持续运行的系统层面。

如果你的业务只是分析一次对局、生成一份报告，那么传统 Multi-Agent 就足够了。但如果你希望系统长期监控模型训练、自动发现评测下降、分析异常样本、启动新实验、提交代码修复，并在完成后向人汇报，Super-agent 的架构就更适合。

三、DS还给我们跑了一下Super-agent的效果

群聊和 GitHub CI 消息流同时驱动四种端到端方案：单次实验包含约 300 条消息，其中约 20 条是工作请求，其余是闲聊、跟进、叫停和 CI 消息。编码工作用一个只消耗时间的工具代替，因此实验衡量的是系统的调度与协作能力，而非对单个任务的执行能力。每种方案重复运行 5 次。

工作请求的累计到达曲线与四种方案的累计完成曲线（5 次实验运行均值；消息间隔与工作时长按 1/4 缩放，模型调用耗时为真实值）

实验结果显示，Super-agent 的任务完成效率明显优于传统单 Session + Subagent 方案，p50 和 p95 分别为 12.4 分钟和 15.7 分钟，而传统方案在中性提示下的 p95 达到 29.5 分钟。核心原因在于，传统方案依赖模型自主判断是否调用 Subagent，容易出现主 Agent 独自执行任务、被新消息频繁打断的问题。相比之下，Super-agent 通过 Router + Worker 双层架构，在系统层面实现任务分工与独立执行，减少了上下文干扰，提高了执行效率和稳定性。 不过，实验仅重复 5 次，结论仍需更大规模验证。

看完 DeepSeek 这次的 Super-agent 构想，我其实有比较大的感受，也就是

大模型越来越强之后，限制 AI 生产力的，有可能是我们使用 AI 的方式。

以前我们希望模型更聪明，能够一次性完成更复杂的任务。后来有了 Multi-Agent，我们又希望多个 AI 能够分工协作。但发展到今天，一个新的问题出现了：

Agent 越来越多，人反而越来越忙。

我们不仅要给 Agent 分配任务，还要不断检查它们的进度、补充上下文、处理异常，甚至协调不同 Agent 之间的工作。说是 AI 帮我们干活，最后却变成了我们天天管理 AI。

DS提出来的Super-agent 想做的，就是进一步把任务调度、状态管理和事件响应这些工作交给系统本身，让 AI 能够持续运行，并且只在必要的时候向人请求决策。

当然，这次 DeepSeek 开源的还只是一个原型，实验也主要验证了调度效率，并不能证明它已经具备成熟的自主工作能力。而且从技术角度看，Router、Worker、事件总线、任务队列、Watchdog 等设计，也并不是什么全新的发明。

以前我们研究的是如何让一个 AI 完成更多工作，未来可能要研究的是如何让一个人管理更少的 AI，却完成更多的工作。

或许这才是 Super-agent 最值得期待的方向。

从 Multi-Agent 到 Super-agent，DeepSeek 想解决 AI 编程的最后一道瓶颈

后台策略工程师

人工智能

架构设计

开发工具

DeepSeek团队发布Super-agent构想及原型，旨在解决多Agent协作中人的注意力瓶颈。其核心为Router+Worker双层架构、事件驱动及Ticket持久化，实现任务并行与自动调度。实测任务完成效率提升显著，p95从29.5分钟降至15.7分钟，让AI从被动工具变为主动数字员工。

事件总线

单元测试

DeepSeek

GitHub

Agent

文章

问答

视频

教程

学习中心

腾讯云实验室

直播

竞赛

腾讯云代码分析专区

腾讯iOA零信任安全管理系统专区

腾讯云架构师技术同盟交流圈

腾讯云数据库专区

腾讯云智能顾问专区

腾讯云原生专区

腾讯混元专区

腾讯云TCE专区

腾讯云Lighthouse专区

腾讯云HAI专区

腾讯云Edgeone专区

腾讯云存储专区

腾讯云智能专区

腾讯轻联专区 

腾讯云开发专区

TAPD专区

腾讯轻量云游戏服专区

EdgeOne AI 安全实战专区

腾讯云最具价值专家

腾讯云架构师技术同盟

腾讯云创作之星

腾讯云开发者先锋

腾讯云代码助手

云原生构建

TAPD 敏捷项目管理

Cloud Studio

SDK中心

API中心

命令行工具

涵盖代码开发、场景应用、自动测试全流程，助你从零构建专属AI助手

一站式MCP教程库，解锁AI应用新玩法

聚焦“写作效率、视觉美观与运行性能”三方面进行全面升级，为您提供更高效、稳定的创作环境

社区富文本&Markdown编辑器全新改版上线，欢迎大家体验!

诚挚邀请您参与本次调研，分享您的真实使用感受与建议。您的反馈至关重要，感谢您的支持与参与！

从 Multi-Agent 到 Super-agent，DeepSeek 想解决 AI 编程的最后一道瓶颈

从 Multi-Agent 到 Super-agent，DeepSeek 想解决 AI 编程的最后一道瓶颈

社区

活动

圈层

关于

腾讯云开发者

热门产品

热门推荐

更多推荐