DeepSeek 开源 Super-agent 原型：Router-Worker 多任务调度架构解析

DeepSeek 最新动态： 10 月 31 日晚，DeepSeek Harness 团队发布技术文章《Super-agent 设计探索：迈向更自主的 Agent 系统》，并同步开放了一个采用 MIT 协议的研究原型。

这次更新值得关注的地方，并不是 DeepSeek 又推出了一款新的 Coding Agent，而是它开始重新思考 Agent 系统的组织方式：当一个 AI 已经能够独立完成复杂任务，为什么还需要人类不断切换会话、分配工作和跟进进度？

DeepSeek 给出的思路是，通过 Router–Worker 双层架构、事件驱动、上下文管理和持久在线机制，让 Agent 从等待指令的工具，逐步转变为能够持续处理工作流的协作系统。

这也意味着，AI Agent 的竞争正在出现新的变化。单个模型能否完成任务仍然重要，但系统能否同时管理多项任务、减少人工干预，并在长期运行中维持稳定，同样值得关注。

一、DeepSeek 为什么开始重新设计 Agent 架构？

过去一段时间，Coding Agent 的能力提升非常明显。

从代码补全、Bug 定位到代码修改、测试执行和 Pull Request 创建，AI 已经能够参与软件开发中的多个环节。开发者不再需要为每个操作都提供详细指令，一些复杂任务也可以交由 Agent 独立完成。

但模型执行能力的提高，并没有完全解决多任务管理的问题。

DeepSeek 在技术文章中指出，当前主流 Agent 仍然以 Session（会话）作为基本工作单位。不同会话之间相互独立，用户需要自行切换窗口、传递背景信息，并持续关注各个任务的进度。

根据团队的观察，一个人通常只能同时跟进 3—5 个活跃 Session。

这就产生了一个新的矛盾：AI 可以执行更多任务，但人类的注意力并没有同步增加。

例如，一个研发团队可能同时面对以下工作：
某个功能出现 Bug，需要复现并定位原因。
已提交的 Pull Request 需要进行代码审查。
CI 测试失败，需要分析构建日志。
新需求进入，需要评估修改范围。
已有任务收到新的评论，需要调整实施方案。

传统 Coding Agent 通常需要为这些任务分别创建会话。即使可以使用 Subagent 分担部分工作，主会话仍然需要承担任务协调、上下文维护和结果汇总。

当消息不断进入时，Agent 可能被新请求打断，开发者也需要反复确认哪个任务已经完成、哪个任务仍在执行。

DeepSeek 认为，问题已经不只是模型能不能完成某项工作，而是系统能否持续管理多项工作。

因此，Super-agent 的核心目标不是让一个 Agent 承担更多任务，而是重新设计任务分配、执行和管理机制。

二、DeepSeek Super-agent：Router 与 Worker 如何协作？

Super-agent 最核心的设计，是将系统划分为 Router 和 Worker 两个逻辑层。

两者承担不同职责，不再让一个 Session 同时负责接收消息、判断任务、执行操作和对外交付。

1. Router：统一入口与全局任务调度

Router 可以理解为整个 Agent 系统的协调中心。

它持续接收来自不同工作渠道的消息，例如即时通讯、GitHub 评论、代码审查反馈和 CI 运行结果。

收到事件后，Router 需要判断：
这条消息是否包含实际工作请求？
它是否属于已经存在的任务？
是否需要创建新的 Worker？
是否应该把消息交给某个正在执行任务的 Worker？
是否需要向用户反馈或请求确认？

Router 不负责具体的代码开发，而是负责全局信息维护和任务分派。

这种设计有一个重要优势：用户不需要直接管理底层的多个 Session。

无论开发者是在群聊中提出需求，还是在 GitHub Pull Request 中补充修改意见，系统都可以通过统一的任务管理机制维持工作连续性。

DeepSeek 还提到，Router 的工作主要集中在消息理解和任务调度，因此不一定需要使用最强的模型。部分判断甚至可以通过普通程序逻辑完成。

这有助于降低整个系统的调度成本。

2. Worker：独立执行具体任务

Worker 是真正负责执行工作的节点。

每个 Worker 拥有独立的上下文和执行环境，可以调用代码工具、终端以及其他必要的外部工具。

例如：
Worker A：负责复现某个 Bug。
Worker B：负责审查已有 Pull Request。
Worker C：负责分析 CI 失败原因。
Worker D：负责开发新的功能。

不同 Worker 可以并行推进任务，不需要等待其他任务结束。

当某个 Worker 完成工作后，会将执行状态和结果汇报给 Router，再由 Router 统一向外部用户反馈。

这样可以避免多个 Agent 在同一个群聊或任务线程中各自回复，造成信息混乱。

值得注意的是，Worker 内部仍然可以继续使用 Subagent 或 Agent Team。Router 不需要了解 Worker 内部如何拆解具体任务。

这形成了一种分层协作方式：
Router 负责任务之间的协调，Worker 负责单项任务的执行，Subagent 负责复杂任务内部的进一步分工。

与传统 Agent Team 相比，这种设计更关注多个独立任务之间的持续调度，而不只是一个复杂任务内部的角色协作。

三、事件驱动：让 DeepSeek Agent 从等待指令转向主动处理

如果只有 Router 和 Worker，Super-agent 仍然只是一个多任务执行系统。

真正让它具备主动性的，是事件驱动机制。

在传统 Agent 工作模式中，用户需要主动输入提示词，系统收到指令后才开始执行。

而在 Super-agent 的设计中，驱动 Agent 的输入不再局限于用户主动发送的提示词，还包括工作环境中持续产生的事件。

DeepSeek 将这些事件称为 Trigger。

例如：
群聊中有人反馈程序异常。
GitHub 收到新的代码审查评论。
CI 自动化测试出现失败。
某个任务收到新的修改要求。
邮件或日程中出现需要处理的信息。

系统会持续监听这些事件，再判断是否需要执行任务。

1. 两级过滤，减少无效模型调用

真实工作环境中的消息数量很大，但并不是每条消息都值得 Agent 处理。

如果每收到一条消息，就调用大模型进行完整判断，不仅增加推理成本，还会产生额外延迟。

为此，DeepSeek 采用了程序策略与模型语义判断相结合的两级过滤机制。

第一层是程序过滤。

系统根据消息来源、群组范围、用户白名单和预设规则，直接排除不需要处理的信息。

例如，某个群组只允许指定成员派发任务，或者某种消息类型默认忽略，这些判断都可以通过程序完成。

第二层是模型判断。

经过第一层筛选的候选事件，再交由大模型结合上下文判断是否具有实际处理价值。

这种设计将确定性规则与语义理解分开。

程序处理明确的条件，大模型处理需要理解上下文的复杂情况。既保留了模型的灵活性，也减少了不必要的调用。

2. Thread 订阅：避免重复进行任务路由

另一个值得关注的设计是 Thread 订阅机制。

在 GitHub 中，同一个 Pull Request 可能持续产生新的评论、修改意见和测试结果。这些消息实际上属于同一条任务线索。

Super-agent 会将相关事件组织成 Thread。

当 Router 创建 Worker 后，Worker 可以订阅对应的 Thread。后续同一 Thread 中的消息，就能够直接发送给已经订阅的 Worker，而不需要每次重新经过 Router 判断和转发。

这相当于建立了一条持续工作的任务通道。

对于长期运行的 Agent 系统而言，这种机制可以减少重复调度，并让执行中的任务及时获得新的上下文。

3. 投机执行：在用户提出明确要求前提前准备

Super-agent 还有一个比较特别的设计：投机执行（Speculative Execution）。

它借鉴了计算机系统中的提前执行思想。

当系统从环境事件中发现潜在工作机会时，可以在后台提前尝试处理。例如，研发人员在群里讨论某个 Bug，Agent 可以先尝试复现问题、分析可能原因并寻找修复方案。

如果最终确认问题成立，而且找到了可行的处理方式，就可以将结果提交给人类审查。

如果判断结果不成立，或者没有形成有价值的结果，则可以放弃这次尝试。

需要注意，主动执行并不意味着 Agent 可以不受限制地修改代码或执行所有操作。实际系统仍然需要通过权限、策略和人工审批来控制行为范围。

从工程角度看，这种模式的价值在于将一部分等待时间转化为后台准备时间。

四、异步执行、存算分离与 Watchdog：Agent 如何长期运行？

Super-agent 不仅关注任务如何分配，也关注任务如何持续执行。

这涉及三个比较重要的工程设计。

1. 异步 ReAct：执行任务时不阻塞对话

传统 ReAct Loop 通常按照模型推理、工具调用、等待结果、继续推理的顺序执行。

当某个工具需要较长时间才能返回结果时，当前会话可能一直处于等待状态，无法及时响应新的输入。

DeepSeek 提出的异步 ReAct 机制，将耗时工具调用拆分为启动和停止操作。

Agent 调用 start 后，可以立即收到任务已启动的通知。实际执行过程放在后台进行，完成后再通过新的事件返回结果。

与此同时，Agent 可以继续接收其他消息。

这让前台交互和后台任务执行实现了解耦。

不过，DeepSeek 原文明确说明，这项异步任务机制虽然已经在 DeepSeek Harness 中实现，但当时尚未默认开启。因此，不能将其描述为所有 Super-agent 实例都已经默认具备的能力。

2. 存算分离：摆脱单台设备的运行限制

传统本地 Agent 通常将计算过程、会话状态和执行环境放在同一台设备上。

一旦电脑关机、休眠或断网，Agent 的运行就可能中断。

DeepSeek 提出的解决思路，是将三者进行解耦。

计算部分可以放在云端运行，会话状态通过数据库持久化保存，而代码仓库、本地文件、依赖服务等执行环境则可以继续留在原来的设备上。

端侧只需要运行一个轻量级的执行程序，负责接收命令并返回结果。

这样，Agent 的核心运行逻辑不再完全依赖某台电脑的生命周期。

对于企业而言，这种架构有一定参考意义。不同团队的开发环境、内网资源和本地依赖往往存在差异，直接将所有执行环境迁移到云端并不现实。

通过计算与执行环境解耦，可以为跨设备任务调度提供更多可能性。

3. Watchdog：不仅检查进程，还要检查任务进度

长期运行的系统不能只关注服务是否启动。

有时候，进程没有崩溃，但 Agent 可能已经陷入无效循环，或者执行方向偏离原本的任务目标。

DeepSeek 为此提出了外部 Watchdog 机制。

它可以理解为一个独立的监控与控制回路。

Watchdog 会定期检查系统状态，除了处理接口异常、状态恢复失败等基础设施问题，还会判断 Worker 是否取得实质进展，以及当前执行方向是否符合整体目标。

发现异常后，可以尝试介入恢复。

这一思路与传统软件系统中的健康检查有所不同。传统监控主要判断服务是否存活，而 Agent 系统还需要判断任务是否真正向目标推进。

这对于需要长时间运行的自动化研发系统尤其重要。

五、DeepSeek 实验数据：Super-agent 的效率提升有多大？

架构设计是否有价值，最终还需要实验数据进行验证。

DeepSeek 在文章中披露了一组初步消融实验，用于比较不同任务调度方案的表现。

实验使用群聊和 GitHub CI 消息流作为输入。每次运行约包含 300 条消息，其中约 20 条属于实际工作请求，其余包括闲聊、任务跟进、取消操作和 CI 消息。

每种方案重复运行 5 次。

需要强调的是，实验中的编码工作由一个只消耗时间的工具模拟。因此，这组数据主要反映任务调度和协作效率，而不是模型实际编写代码的质量。

1. 四种方案的对比

表格

从结果来看，Super-agent 的 P95 完成时间为 15.7 分钟，而中性提示词下的单 Session 方案达到 29.5 分钟。

按照 P95 计算，完成时间缩短约 46.8%。

更值得关注的是提示词对 Subagent 调用行为的影响。

在中性提示词下，模型连续 5 次运行都没有调用 Subagent，所有工作都留在主 Session 中执行。

当提示词明确要求优先委派任务后，5 次运行中有 4 次发生了委派，但仍有一次任务被模型判断为较简单，最终选择自行处理，形成了较长的完成时间。

这说明，即使模型具备多 Agent 协作能力，也不代表它在每一次任务中都会主动进行合理分工。

相比之下，Super-agent 将 Router 与 Worker 的职责直接固化在架构中，不再完全依赖模型临场判断是否需要委派。

2. 效率提升并不意味着成本同步下降

实验还有一个容易被忽略的细节：Super-agent 使用了更多的缓存读取 Token。

在完整方案中，单次实验的读缓存 Token 约为 2323 万。

去掉事件直通机制后，Router 需要作出的决策增加约 30%，读缓存 Token 增加至 3177 万，增幅约 37%。

这意味着，多 Worker 并行运行，需要维护更多会话和上下文，调度效率的提升是以更高的上下文存储与读取开销作为代价。

六、实验结果说明了什么？效率提升背后还有成本权衡

从实验数据来看，Super-agent 的优势不只是任务完成速度，还包括任务调度的稳定性。

DeepSeek 团队设置了四种方案进行对照，分别是完整 Super-agent、关闭消息直通机制的 Super-agent，以及采用不同提示词策略的单 Session + Subagent 方案。

完整 Super-agent 的 P95 完成时间为 15.7 分钟，相比中性提示词下的单 Session 方案缩短约 47%。

这里还有一个值得关注的现象：当提示词明确要求模型优先委派任务时，单 Session 方案的 P50 从 20.4 分钟下降到 13.8 分钟，但 P95 仍达到 29 分钟。

这说明，提示词能够影响模型的任务分配行为，却不一定能够保证每次都按照预期执行。

在五次实验中，中性提示词下模型一次也没有调用 Subagent；明确鼓励委派后，五次中有四次进行了委派，还有一次因为模型判断任务较简单而选择自行处理。

这也是 Super-agent 采用独立 Router 的重要原因：任务是否需要拆分、应该交给哪个 Worker，不再完全依赖模型在当前对话中的临时判断，而是由系统架构承担相应的调度职责。

不过，效率提升也伴随着资源成本。

实验数据显示，完整 Super-agent 每轮的缓存读取 Token 约为 2323 万，而两种单 Session 方案分别约为 605 万和 1082 万。多 Worker 并行运行，需要维护更多会话和上下文，因此不能简单理解为 Agent 数量增加就能降低总体成本。

另一个实验验证了 Thread 直通机制的价值。

关闭这一机制后，Super-agent 的 P95 仍然保持在 15.5 分钟，与完整方案接近，但 Router 需要处理的决策数量增加约 30%，缓存读取 Token 增加约 37%。

这意味着，消息直通机制的主要价值不是直接缩短任务执行时间，而是减少不必要的重复路由和上下文处理。

DeepSeek 还对 Router 进行了独立压力测试。当 Trigger 到达速度从每分钟约 1 条提升至每分钟约 40 条时，平均批处理大小从 1.0 增长到 2.8，单次请求耗时从 2.5 秒增加到 3.9 秒，而分摊到单个决策上的推理时间从 6.4 秒下降到 1.6 秒。

这一结果体现了事件批处理的价值：消息数量增加时，系统可以合并处理积压事件，降低每次决策的平均开销。

但需要强调，以上实验采用合成消息负载和简化执行环境，编码任务由模拟耗时的工具代替。实验主要验证的是任务路由、调度和协作效率，并没有证明 Super-agent 能够以相同比例提升实际代码质量或 Bug 修复成功率。

因此，15.7 分钟和约 47% 的提升应当被理解为特定测试条件下的调度性能结果，而不是所有 Agent 项目都能直接获得的生产收益。

七、Super-agent 距离真正的企业级应用还有多远？

从技术方向来看，Super-agent 已经展示了长期运行 Agent 的一种可行架构，但距离成熟的企业级应用仍有不少问题需要解决。

第一，长期记忆与任务状态管理。

企业任务往往持续数周甚至数月。Agent 不仅需要记住近期对话，还要能够追踪历史决策、任务进度、负责人和执行结果。

当多个 Worker 同时修改同一项目时，如何处理上下文冲突、任务状态覆盖和版本变化，也需要更完善的机制。

第二，权限与安全边界。

Super-agent 可以接入群聊、GitHub、邮件和本地开发环境，这意味着它可能接触代码仓库、项目文件和业务数据。

系统必须明确不同 Worker 的权限范围，限制敏感操作，并保留完整的操作日志。

尤其是 Agent 主动读取外部消息并执行任务时，还需要防范提示词注入、恶意指令和凭据泄露等问题。不能因为 Agent 能够自主判断，就默认它可以自主执行所有操作。

第三，多 Agent 之间的协作与资源治理。

Worker 数量增加后，系统还需要处理任务重复执行、资源争抢、调用预算、失败重试和优先级管理等问题。

例如，代码审查、Bug 修复和测试任务可能同时作用于同一个代码仓库。如何避免多个 Worker 重复修改文件，如何协调任务依赖关系，都需要系统层面的设计。

第四，模型选择与调用成本。

不同任务对模型的要求并不相同。

代码分析、简单分类、复杂推理和结果审核，对模型能力、响应速度和调用成本的要求存在差异。

企业在搭建 Agent 系统时，需要根据任务类型配置模型路由，而不是让所有 Worker 都使用同一款模型。

这也对底层 API 接入提出了更高要求。企业需要关注不同模型的接口兼容性、调用稳定性、费用统计和故障切换能力。

对于需要同时接入 DeepSeek、Kimi、Qwen、GLM 等国产模型的开发团队，可以通过统一 API 网关减少不同供应商接口带来的适配工作。例如，星链 API 提供国产大模型统一接入能力，开发者可以结合实际任务需求评估模型，并在应用侧设计不同的调用策略。

当然，API 网关解决的是模型接入和调用管理问题，并不能替代 Agent 自身的任务调度、权限控制和状态管理。

八、DeepSeek 这次开源，真正值得关注的是什么？

回到这次技术探索，DeepSeek Super-agent 最值得关注的，并不是又增加了多少个 Worker，也不是让 Agent 在没有人工指令的情况下执行更多任务。

它真正尝试改变的是 Agent 的工作组织方式。

过去，开发者主要关注模型能不能理解需求、能不能调用工具、能不能完成复杂代码任务。

现在，当单个 Agent 已经具备较强的任务执行能力，新的问题开始出现：谁来决定任务应该交给谁？谁来维护长期状态？谁来判断任务是否真正取得进展？系统出现异常后，又由谁负责恢复？

这些问题很难仅靠更长的提示词解决。

Router、Worker、Thread、Watchdog、异步执行和状态持久化，本质上都是将传统软件工程中的系统设计思想引入 Agent 架构。

这也意味着，未来 Agent 的竞争可能不再局限于单个模型的推理能力，而是逐渐延伸到整个系统的任务吞吐量、资源利用率、执行可靠性和安全治理能力。

需要注意的是，DeepSeek 此次开源的是用于验证技术思路的原型，不能直接等同于完整的企业级 Super-agent 产品。异步执行等部分机制也尚未默认开启，实际部署仍需要进一步验证。

对于开发者而言，这次开源提供了一个值得研究的工程方向；对于企业而言，更重要的是提前考虑多 Agent 系统的任务管理、模型调度、权限审计和成本控制。

Agent 从能够完成任务，走向能够长期管理任务，中间缺少的不是一个更长的提示词，而是一套真正可靠的系统架构。

这或许才是 DeepSeek 此次 Super-agent 探索给行业带来的重要启发。