一文拆解DSH Super-agent双层架构：如何做到后台跑任务、前台继续接活
朱进约 9 分钟开发者公众号专属群聊
扫码加入获取更多一手教程、科技前沿报告
10 月 31 日晚，DeepSeek Harness 团队在公众号发表长文《Super-agent 设计探索：迈向更自主的 Agent 系统》，同时开源了原型项目 dsh-superagent-prototype。文章里有个内部实例的画面：团队成员在群聊里反馈软件问题，没有人 @ AI，系统自己认出这是个缺陷，在后台复现、定位根因，找到简单修法后直接提交了修复 PR。
先把性质说清楚：这不是产品发布。团队在文首特意声明，这是一篇面向工程实践的架构思路探讨，不涉及现有产品功能。也正因为如此，它把问题定义和系统设计讲得很干净，值得逐层拆开看。
01
过去两年，模型干单个任务的能力涨得很快。以编码场景为例，Coding Agent 完成一项复杂工作需要人工介入的环节越来越少，人的角色从"盯着每一步"上移到"定目标、验结果"。
麻烦出在多任务。主流 Agent 的工作单位仍然是单次会话（Session）：一个人同时推进几项工作，就得手动开几个 Session，来回切换，还要自己记住每个 Session 里说过什么。DeepSeek 团队给了一个观察数据：一个人通常只能同时跟进 3 到 5 个活跃会话。
于是瓶颈换了位置。单任务的上限取决于模型能力，多任务的上限取决于人的注意力。模型越强，这个矛盾越尖锐。活儿 AI 都能干，可安排活儿、同步上下文的还是人脑。
图 1 ｜ 瓶颈的转移：单任务时代卡在模型能力，多任务时代卡在人的注意力
Super-agent 要解决的就是这一件事：把会话管理和上下文同步从人手上移到系统层。人只负责目标与验收，调度和执行交给系统。团队把这个形态和支撑它的架构统称为 Super-agent。
02
一句话定义：打破 Agent 与单次手动会话的绑定，让它成为一个跨会话保持上下文、同时推进多项复杂任务、互不干扰的连续实体。
它有四个特征：
连续：在 IM、GitHub、邮件等熟悉的工作界面直接交互，感觉始终只有一个 Agent。先在 IM 里拍板方案 A，随后在 GitHub PR 评论里改成方案 B，它能理解并调整方向，不需要人去想"这个上下文在哪个 Session 里"。
高效：交互响应快，多个复杂任务并行推进。不必等上一个命令跑完，就能接受下一条指令。
主动：持续观察环境事件，值得处理的事主动推进，不需要介入时保持安静。
持久：始终在线、直接接入真实工作环境，长期运行中遇到异常能自动恢复。
图 2 ｜ 连续、高效、主动、持久：四个特征与五组支撑模块
团队自己也说得很直白：整套设计没有提出全新的理论，做的是把计算机系统里经典的工程思想——调度、缓存、存算分离、看门狗、投机执行——搬进 Agent 系统。具体实现会随技术演进，但设计思路有长期参考价值。下面逐个看这五组模块。
03
先看为什么要拆两层。两个极端都有问题：所有消息进同一个会话，上下文连续，但执行串行阻塞，不同任务的细节互相污染；每条消息新开一个会话，并发好做，全局协调和交互一致性又丢了。
Super-agent 把"维护全局连续性"和"高并发执行"拆到两个层级：
Router 是持续运行的全局协调节点，统一承接人类交互与跨任务协调：接收群聊、GitHub、邮件等多渠道消息，识别任务归属并分派，维护跨任务的全局上下文，统一向用户回复。它不执行具体任务，甚至可以不配备 Bash 工具，职责边界直接焊死在系统结构里。
Worker 是一组相互隔离的会话，各自维护独立上下文，并行执行问题复现、代码审查、功能开发等具体工作。Worker 挂载完整执行工具链，通常配置能力最强的模型；它不直接与人类交互，状态和结果汇报给 Router，由 Router 统一对外说话。任务复杂时，Worker 还可以继续调用 Subagent。
图 3 ｜ 双层架构：Router 统一对外，Worker 隔离并发，绿色虚线为订阅直通
这个设计和常见的多智能体团队形态相似，差别主要在职责边界：Router 不必成为深入参与每个子步骤的技术主管，具体的技术判断留在 Worker 内部。职责边界由系统结构承接，不指望模型临场决定要不要委派。这一点很关键，它把"会不会放权"从模型的发挥题，变成了架构里的确定约束。
开源原型里，工作被组织成 Ticket：每个任务关联自己的执行会话与目录，面板集中显示等待回答、等待审查、受阻的事项。任务的进度和讨论可以延续，用户不再用聊天窗口的位置来记住哪件事推进到哪了。
04
驱动 Agent 的主要输入，不再只是人类逐条键入的提示词，而是群聊消息、邮件与日程提醒、代码评审评论、CI 运行结果这类半结构化环境事件，DeepSeek 把它们统称为 Trigger。
真实环境的特征是高噪音、低触发率：绝大多数群聊消息根本不需要 AI 介入。如果每条消息都过一遍大模型，成本和延迟都撑不住。团队的解法借鉴了操作系统的 Fast Path / Slow Path 思想，做两级过滤：
程序层策略（Fast Path）用确定性代码做快速准入检查（来源、接收范围、准入条件），在调用模型前滤掉大部分无关消息；语义层策略（Slow Path）把候选事件交给 LLM，依据提示词里编写的策略和上下文判断是否需要行动。Slow Path 同时是个自然语言扩展点：团队用大白话写"什么值得做"，比改代码灵活得多。
图 4 ｜ 两级过滤与订阅直通：新任务走 Slow Path 进 Router，已订阅 Thread 直接送达 Worker
事件路由上同样有省钱的细节：全局 Router 只负责新任务的冷启动与跨任务协调，已确定归属的后续事件由程序直接发往对应 Worker。同一个 PR、IM 话题或邮件串构成 Thread，由接手的 Worker 订阅，后续评论和 CI 结果直达，不再劳烦 Router。
两个值得记住的约束：其一，Thread 与 Worker 是多对多关系——一个任务可以跟踪多个讨论，一个讨论也可能关联多个任务；其二，订阅只提供信息，不自动赋予新的操作权限，超出当前任务范围的要求仍要重新走分派。原型里还用 Mandate 限定每个任务的授权范围，防止 Agent 擅自扩权。
对于"主动接活"这件事，原型默认采取观察模式：系统先记录"本来会接什么任务"，跑一段时间确认推断可靠后，再放开自动执行。这是一个灰度思路，主动性也得先证明自己。
05
"始终在线"说起来简单，工程上要拆成三件事：计算放哪、状态存哪、环境跑在哪。
Super-agent 的答案是把 Agent Loop 的计算、会话状态和执行环境解耦：执行循环放在云端，会话状态存入数据库，执行环境保留在用户本地设备，本地只部署一个负责执行命令、返回结果的轻量 daemon。你的电脑合上盖子，云端 Agent 的任务状态还在；设备重新上线，daemon 接着跑。
长期运行还绕不开一个老问题：Agent 会卡死、陷入无效循环、偏离目标，甚至程序本身崩掉。DeepSeek 的处理方式是给 Agent 配一个独立的 Watchdog。这个设计借鉴嵌入式系统里的看门狗定时器：由独立进程监督其他 Agent，检测程序故障和目标偏离，并尝试介入修复。监督者和被监督者分开部署，避免"自己检查自己"的盲区。
图 5 ｜ 存算分离：云端算、库里存、本地跑，Watchdog 独立兜底
06
异步 ReAct Loop
传统 ReAct 循环里，工具调用是同步的：启动一个十几分钟的训练任务，整个会话就干等着。Super-agent 把耗时工具调用改成异步的 start() 和 stop()：Agent 启动后台任务后立即返回 Started 状态，结果随后作为新事件回流进会话。前台对话不阻塞，用户随时能插进新指令。团队说明这个机制已在 DeepSeek Harness 里实现，但默认没开——发布节奏上相当克制。
投机执行
借鉴 CPU 的投机执行思想：结果是否被采用尚未确定时，先在后台提前尝试，有价值再交付，没有就丢弃。内部落地的策略叫"静默复现并修复"：群里有人反馈 Bug，AI 先在后台复现、分析根因，确认问题存在且找到简单修法才提交，否则保持安静。宁可白干，不可打扰。这套机制同样适用于个人助手：收到会议邀请，先核对日程冲突、整理背景资料、备好回复草稿，等你确认。
图 6 ｜ 异步 ReAct 让会话不阻塞；投机执行让 AI 宁可白干也不打扰人
顺带一提上下文管理。跨会话、跨任务的长程记忆靠两个机制：Inline & Spill 把近期大概率用到的信息直接放进模型上下文窗口，超出预算或低频的内容留在窗口外按需读取；Chain of Recall 则利用 Trigger、Thread、Worker Session 之间的引用关系，让模型沿关联 ID 一步步找回历史任务信息。前者控制"现在装多少"，后者解决"过去怎么找回来"。
07
DeepSeek 公布了初步实验数据，在约 300 条消息、20 项工作请求的模拟协作环境中，每种配置重复测试 5 次：
图 7 ｜ 完成时间对比：P95 口径下，Super-agent 比单 Session 方案快约一倍
另有两个消融数据，恰好说明这套架构不是免费的午餐：
去掉订阅直通后，Router 决策次数增加约 30%，读缓存 token 从 2323 万涨到 3177 万，涨幅约 37%。事件路由机制在省真金白银。
Router 批处理把单个决定分摊的推理时间从 6.4 秒降到 1.6 秒，突发消息洪峰靠攒批扛住。
也就是说，Super-agent 是拿更多的 token 换时间和稳定性，而且实验基于合成负载与简化环境，只是初步参考。团队能把代价和局限一起摆出来，比只报喜的论文诚实不少。
08
算法上没什么新东西，赢在系统工程。Router/Worker、事件总线、任务队列、缓存、看门狗、投机执行，全是分布式系统和操作系统里跑了几十年的老东西。Super-agent 的价值在于把它们重新组合进 Agent Runtime，让 Agent 摆脱单次对话窗口的生命周期限制。这提醒我们：Agent 的下一程竞争，可能不在模型榜单，而在谁先把"操作系统"那一层做扎实。
职责边界写进结构，比写进提示词可靠。Router 不装 Bash、Worker 不直接对人说话、订阅不给权限、Mandate 限定授权范围。每一处都是用架构约束代替对模型自觉的期待。当你不能确定模型每次都会做出正确选择时，就把它物理上做不到的事从能力清单里删掉。
主动性的落地路径是灰度。观察模式先记录"本来会接什么"，验证可靠后再放开执行；投机执行宁可白干也不打扰。这两个设计合在一起，回答了"AI 主动干活"最容易被质疑的问题：怎么保证它不乱来、不烦人。答案没押在更强的对齐训练上，押在了更保守的交付策略上。
个人助手和商业场景，底层是同一件事。文章里反复强调：个人助手与软件开发等商业 Agent，只要目标都是持续在线、并发响应环境事件，底层架构就是相通的。这也解释了为什么各家 Coding Agent 厂商都在往"长驻、多任务、事件驱动"方向走：形态先在研发场景跑通，再泛化到更广的个人助理市场。
09
Super-agent 没有发明新理论。它做的事，是把一个正在发生的趋势说清楚了：模型能力足够强之后，Agent 系统的设计重心从"怎么把单件事做好"转向"怎么同时管好很多件事"。会话管理、上下文同步、异常恢复这些以前由人脑承担的成本，正在被一层系统架构接走。
人剩下什么？定目标，验结果。听起来轻松，实际上是把更大的判断责任压到了人这边——验收能力会成为新的瓶颈吗？这个问题，可能要等下一篇文章来回答。
参考资料
DeepSeek Harness 团队公众号：《Super-agent 设计探索：迈向更自主的 Agent 系统》（2026-10-31）
开源原型：
github.com/deepseek-ai/dsh-superagent-prototype（MIT 协议）智东西：《DeepSeek 又开源了！公布 Super agent 架构》（2026-11-01）
凤凰网科技：《DeepSeek 提出 Super-agent 架构设计》（2026-10-31）
腾讯云开发者社区：《DeepSeek 开源 Super-agent 架构》（2026-11-01）