DeepSeek发布Super Agent架构：Router+Worker双层设计

DeepSeek Harness团队发布了一篇关于Super Agent设计探索的文章，提出了下一代Agent系统的架构思路。距离其开源核心推理框架仅过去11天，这一节奏引发了开发者社区的广泛关注。

Agent的核心痛点：人的精力成为瓶颈

据B站UP主「因势分解」的解读，当前Agent最大的痛点在于：AI能干的活越来越多，但人的精力有限。现有Agent仍以单一会话为基本单位，不同会话之间相互独立，普通人同时管理三到五个活跃会话就已相当吃力。

这一观察切中了要害。Agent能力的提升并没有同步降低人的管理负担——用户反而需要在多个对话窗口之间来回切换、反复交代背景、手动跟进进度。DeepSeek^广告的Super Agent架构正是针对这一结构性矛盾提出的。

双层架构：Router调度，Worker执行

Super Agent的核心思路并不复杂：把AI从一问一答的聊天工具，改造成一个常驻后台的虚拟团队。系统分为两层——调度员Router和干活的Worker。

Router对接所有消息，同时也能解决任何问题；多个Worker则隔离并行干活、互不干扰。用户不需要盯着每一步执行细节，只负责定目标、验收结果，调度跟进与上下文同步交由系统自动处理。这一分工实际上把「项目经理」的角色从人转移给了Router，人退回到「需求方」的位置。

SubAgent（子代理）机制：SubAgent指由一个主Agent派生出来、负责执行具体子任务的从属Agent实例。主Agent把大任务拆解后分派给多个SubAgent并行处理，各自拥有独立的上下文与工具权限，完成后把结果汇总回主Agent。这种模式能提升并行度，但也带来额外开销：每个SubAgent都要携带自己的系统提示与任务描述，且主从之间的结果汇总本身也要消耗Token和一轮推理。文中提到的“带SubAgent工具的单会话”即指这种较重的基线方案，Super Agent的提速正是相对它而言。

四大核心特征

这套架构提出了四个关键特性：

• 连续：同一个任务可以跨群聊、GitHub等多个平台推进，不用反复交代背景。
• 高效：多个任务并行跑，一个长任务不会卡住其他工作。
• 主动：持续监听环境事件，即使没人提醒，发现bug这类事情也会自行启动处理。
• 持久：长期在线运行，程序卡死或出错可自动恢复，保证任务不半路中断。

「连续」和「持久」两项尤其值得注意。跨平台上下文保持意味着Agent开始具备跨会话的记忆与状态管理能力，而自动恢复则直接把长任务的可靠性从「人工看护」提升到「系统自愈」。

性能数据与Token代价

团队公布的实测数据显示，P50与P95的完成时间分别为12.4分钟和15.7分钟，大约只花带SubAgent工具的单会话时间的一半。

速度提升的代价是Token用量上涨。UP主用了一个直白的比喻：要让大肥鱼干得快，大白饭必须得管够。对于实际部署而言，这意味着成本结构的变化——省下的是人的时间，付出的是推理开销，是否划算取决于具体场景的任务密度。

P50与P95的含义：这两个指标来自延迟统计中的百分位数（percentile）。P50即中位数，表示有一半任务的完成时间短于该值；P95表示95%的任务完成时间短于该值，剩下5%的“长尾”任务会超过它。用P50和P95一起汇报，比单看平均值更能反映真实体验——平均值容易被极快或极慢的个别任务拉偏，而P95能暴露最慢那批任务到底有多慢。文中12.4分钟与15.7分钟相差不大，说明任务完成时间的分布比较集中，长尾拖尾不严重，这对需要稳定交付的常驻型Agent来说是重要信号。

从工具到团队的转变

Super Agent架构的深层意义在于Agent形态的转变：从被动响应的工具，转向常驻后台、自主协作的团队。Router承担调度与上下文同步，Worker负责隔离并行执行，人只做目标定义与结果验收。这一模式若能落地，将改变开发者与AI协作的基本单位——不再是单次对话，而是一个持续运行的任务系统。

目前该文章仍属架构探索阶段，具体实现细节与开放程度有待后续观察。