DeepSeek开源超级智能体架构：调度器统一激活多智能体

DeepSeek 开源了一套超级智能体架构，而且连原型代码都同步公开了。按照B站视频的速报，这次的核心不是又一个 Agent 框架的堆叠，而是一个调度件统一激活的设计——把多个智能体放进同一套调度逻辑里做变形处理，而不是让它们各自为战。从公开信息看，这套系统已经在团队内部日常使用，主要承担查问题和代码评审两类任务。

架构亮点：一个调度器激活多个智能体

多智能体系统最常见的痛点，是每个 Agent 都有自己的激活条件和上下文管理，拼在一起后调度开销和状态同步成本会迅速膨胀。DeepSeek^广告 这套架构把激活入口收敛到统一的调度件上，多个智能体通过同一调度层被唤醒、变形处理，再回传结果。

这种设计的意义在于，智能体之间的协作不再依赖点对点的消息传递，而是由调度器统一编排。对工程团队来说，这意味着一套可观测、可复用的调度策略，而不是为每个任务单独写胶水代码。

多智能体系统（Multi-Agent System）通常指多个自主智能体通过协作完成复杂任务的架构。每个智能体可以是基于大语言模型的独立实例，拥有自己的提示词、工具集和上下文。传统实现中，智能体之间通过消息传递或共享内存协作，但激活条件、上下文窗口和状态管理各自独立，导致调度开销随智能体数量增长而快速膨胀。DeepSeek 将激活入口收敛到统一调度件，本质上是把“谁在什么时候被唤醒”的决策从各智能体上收到调度层，从而降低状态同步与编排的复杂度。

实测数据：52分钟完成一半，16分钟完成95%

视频里提到的实测结果值得单独拎出来看：完工实测中，有一半任务用了 52 分钟做完，95% 的任务在 16 分钟内做完。这两个数字放在一起看，说明任务耗时的分布并不均匀——中位数和尾部存在明显差距。

一个合理的解读是，调度器对不同类型的任务响应差异较大：常规的查问题、代码评审这类结构化任务能快速收敛，而复杂任务仍需更长的处理链路。这也提示使用者，评估这类系统时要看任务分布，而不是只看平均值。

内部落地：查问题与代码评审

按照速报的说法，这套系统内部已经在用，日常帮团队查问题和回代码评审。这两类任务有个共同点：输入相对明确、评判标准可验证，适合用多智能体分工来做。

查问题可以拆成复现、定位、验证几个环节，代码评审则可以拆成风格检查、逻辑审查、安全扫描。调度器统一激活的好处在这里体现得比较直接——同一套调度逻辑可以适配不同任务的智能体组合，而不必为每个场景重建流程。

开源原型意味着什么

架构和原型同步开源，比只发论文或只放架构图更有参考价值。原型代码能让人看到调度件的实际实现方式、智能体的接入约定，以及任务分发的具体策略。

对想自建多智能体系统的团队来说，这类原型的价值不在于直接拿来用，而在于提供一套可对照的工程范式：调度层怎么设计、状态怎么传递、多个智能体怎么避免互相干扰。这些细节往往才是多智能体系统落地时真正卡住的地方。

几点观察

这套架构目前公开的信息还比较有限，实测数据的口径、任务类型分布、调度器的具体机制都没有完整披露。从已有信息看，它的方向是清晰的：把多智能体的复杂度收拢到调度层，让上层任务编排变得更简单。至于这套设计在更大规模、更多任务类型下是否依然成立，还需要更多公开细节来验证。