拆解DeepSeek Super-agent架构：Router+Worker如何破解多会话管理瓶颈

当你可以同时开五个AI会话分别修bug、写文档、做代码审查时，生产力似乎理应翻倍。但现实往往是：你成了那个在各会话间疲于奔命的人——切换窗口、检查进度、补充指令、处理异常，甚至忘了自己下一步要做什么。据B站UP主对DeepSeek^广告团队最新Super-agent论文的解读，这种「人忙着管理模型」的困境，恰恰是DeepSeek提出新架构的出发点：当模型执行能力持续增长，人的注意力、上下文切换和任务监督已成为新的瓶颈。

多Session并行的甜蜜与负担

UP主在视频中还原了一个典型场景：早期我们只开一个会话，让AI改代码或解决问题；随着模型能力增强，我们开始并行多个会话——一个修bug、一个写文档、一个做code review。表面上生产力提升，但很快问题浮现：你需要不断切换会话查看任务进度、补充指令、处理异常，甚至因为任务太多而忘记每个Agent在做什么。

这背后是两种传统方案的局限。把所有任务塞进同一个Session，上下文虽然连续、缓存可复用，但不同任务的信息混杂，任务聚焦度下降，性能受损；且同步ReAct模式下，新指令会打断正在执行的任务。反之，每个任务开独立会话虽能并行且互不污染，却让人陷入更频繁的切换与管理负担，跨会话信息也难以共享。

DeepSeek的答案是一个Router + Worker的双层架构：Router是长期运行的Agent会话，负责与用户交互、理解新任务、判断归属并全局协调；Worker则负责具体任务执行，拥有独立的上下文和工具，不与用户直接交互。用户只面对Router，任务被分派给不同Worker并行推进。

双层架构的工程机制：Fast Pass、Slow Pass与链式召回

架构图揭示了消息如何高效流转。外部事件进入系统后，先经过一层规则筛选，分为Fast Pass和Slow Pass两条路径。以PR场景为例：当Worker订阅某个PR后，该PR后续的commit或review消息会通过内部维护的订阅表直接送达对应Worker，完全绕过Router——这就是Fast Pass，避免了不必要的路由开销。

不在订阅表中的新任务或陌生消息则走Slow Pass，由模型进行语义分析（RM）判断：无关消息直接丢弃，需要处理的任务才交给Router分派新Worker。UP主展示的数据显示，经过路由转达相比代码直送，会带来约37%的额外缓存开销，主要源于Router作为模型需要读取上下文缓存并进行新一轮推理；但由于Router设计轻量且模型本身响应快，实际速度差异并不明显。

上下文组织上，DeepSeek提出inline与spell两种策略。inline把当前最相关的信息直接放入上下文，比如Worker处理PR时的当前评论、任务目标和最近讨论；spell则把暂时用不到的完整信息存入外部存储，需要时再检索引用。

更关键的是链式召回（Chain of Recall）。UP主举例：几天前有人在群里反馈bug，Worker已做分析；几天后用户私聊Router问「上次那个登录问题怎么样了」，Router如何知道指的是哪个任务？链式召回会保存此前的订阅关系和Worker间的关联依赖，当新消息出现时通过依赖关系判断是否处理过，若处理过则直接召回并送入对应Worker。

此外，系统还设计了全双工的Router通信、基于任务类型的回复策略（群聊简洁、PR详细），以及看门狗机制监控Worker是否健康推进而非陷入死循环。

ReAct模式（Reasoning + Acting）是当前Agent设计的主流范式，由Shunyu Yao等人在2022年提出。它让模型在「推理—行动—观察」的循环中交替推进：先输出思考内容（Thought），再决定调用哪个工具（Action），拿到工具返回结果（Observation）后继续下一轮推理。这种模式的优势在于可解释性和动态纠错，但代价是每一步都需要模型完整读取上下文并生成输出，即所谓的「同步ReAct」——一次工具调用未返回前，后续指令无法插入。当多个任务共享同一个ReAct会话时，新消息只能排队或打断当前循环，这正是把所有任务塞进单一Session会损失聚焦度和响应性的根本原因。Router+Worker架构本质上是在ReAct循环之上增加了一层调度，把长循环拆解到独立Worker中并行执行，从而绕开同步阻塞。

上下文缓存（Context Cache） 是理解37%额外开销的关键。大模型推理时，如果每次请求都重新计算整个前缀的注意力，成本会随上下文长度线性甚至平方增长。主流推理框架（如vLLM的PagedAttention、DeepSeek自身的上下文硬盘缓存）会把已处理过的token的KV Cache保留下来，后续请求命中相同前缀时直接复用，只计算新增部分。Router作为模型需要读取并复用Worker已经建立的上下文缓存，相当于多了一次「读缓存+再推理」的环节，这部分额外计算就体现为约37%的缓存开销。不过因为Router的上下文通常较短、模型响应快，缓存命中率较高，所以端到端时延的差异被摊薄，用户感知并不明显。

计算与执行环境分离：云端持久化与多端节点

传统本地Agent把模型运行循环、状态和执行环境放在同一台机器上，关机即停止。DeepSeek的方案将Agent loop跑在云端，状态和任务持久化保存在数据库，实际执行命令的环境则可以是云端、手机、Mac或Windows——只要设备上运行了相应节点。UP主以本机的GorgBot为例：手机上给GorgBot发消息，它可以操控跑在Windows和Mac上的执行节点处理本机任务。这种存算分离也让故障恢复成为可能：中断后可从存储中找到卡点继续推进。

存算分离借鉴自分布式系统与云计算架构，原指将数据存储层与计算层解耦，使两者可以独立扩展和故障隔离。在Agent语境下，「算」是模型推理循环和工具调用逻辑，「存」是任务状态、对话历史、订阅关系和执行中间结果。传统本地Agent把两者耦合在同一进程甚至同一台机器上，进程崩溃或设备关机就意味着任务丢失，也无法从另一台设备接管。存算分离后，Agent loop运行在云端常驻服务中，状态写入数据库，执行节点（手机、Mac、Windows）只承担具体的命令执行和文件操作，通过节点协议与云端通信。这样任一执行节点掉线都不影响任务本身，云端可重新调度到其他节点或等待重连，从而实现断点续跑和跨端接力。

并非全新范式：与现有实践的对照

UP主坦率指出，Super-agent并非从零提出的全新范式。他展示了自己今年4月做的开源项目Hive，以及本机运行的GorgBot，架构高度相似：一个「大内总管」式的Router管理多个Worker，甚至同样具备架构观察员做自检、将数据沉淀到GitHub。他进一步提出，在Codex或ChatGPT中同样可以定义规则让会话互相发消息，模拟出Router-Worker架构。DeepSeek论文本身也承认，底层机制大量借鉴了软件工程和分布式系统思想。

架构缓解了入口混乱，但人的注意力瓶颈仍在

这是UP主最具价值的独立判断。DeepSeek以人的注意力有限为出发点，但Router+Worker只是把会话管理责任更多交给系统，并未从根本上消除人的注意力瓶颈。当一个人同时管理五个项目，所有消息汇聚到一个Router，人仍需分别理解项目背景、处理任务、做出决策；若所有项目消息挤在同一聊天流里，反而可能产生新的交互混乱——处理完第一个任务再翻回去找第二个，只会更乱。他个人更倾向于让专门任务交给专门Bot处理，清晰度更高。

同样值得警惕的是「Agent多十倍，生产力就增长」的假设。单个Agent能力提升并不必然带来系统有效产出提升：任务间存在依赖、冲突、共享状态和协调成本；即便Agent完成得再快，仍需人判断任务是否有价值。UP主分享了自己的感受：每天很忙、Agent一直在跑，回过头却感觉没多少成果，还挤占了深入学习思考的时间。真正值得优化的，不只是Agent多聪明，而是如何让这些智能以合理的计算成本和人类注意力成本，持续转化为有效产出。

编辑观点

DeepSeek的Super-agent架构在工程上是扎实的：Fast Pass/Slow Pass的路由分层、链式召回的记忆关联、存算分离的持久化，都是对多会话管理痛点的针对性设计。但它更像是一次系统性整合而非范式革命。对开发者而言，真正的启示或许在于：架构只是手段，当Agent数量膨胀时，人如何保持对任务的掌控感和价值判断，才是更难的命题。