DeepSeek 发布 Super-agent 架构设计长文：Router 与 Worker 双层架构，原型插件已开源

2026 年 11 月 01 日——10 月 31 日晚，DeepSeek Harness 团队在官方公众号发表技术文章《Super-agent 设计探索：迈向更自主的 Agent 系统》，提出由常驻 Router 层与隔离 Worker 层构成的双层架构，推动 Agent 从被动响应指令的单任务工具转向持续在线、并行处理多任务的自主协作者。初步实验显示，Super-agent 的任务完成时间 p50 为 12.4 分钟、p95 为 15.7 分钟，而中性提示下带子助手工具的单会话方案 p95 为 29.5 分钟。配套开源原型插件 dsh-superagent-prototype 已同步上架 GitHub，官方明确其并非 DeepSeek 正式产品。

文章定位：架构思路探讨，非产品功能说明

文章开篇即声明，这是一篇面向工程实践的架构思路探讨，并非对 DeepSeek Harness 现有产品功能的介绍。

DeepSeek 团队在文中给出的核心判断是：随着模型执行单个任务越来越少需要人工干预，限制生产力提升的瓶颈正在转向人的注意力。现有主流 Agent 设计以单一 Session（会话）为基本单位，用户并行推进多项工作时必须手动切换并维护各会话上下文，据其观察，一个人通常只能同时跟进 3 到 5 个活跃 Session。官方认为，在这种设计下，单任务的上限取决于模型能力，多任务的上限取决于人的注意力。

文章将这种新型 Agent 形态称为 Super-agent，并归纳出四项基础特征：连续（在 IM、GitHub 评论等不同信道与同一个 Agent 交互）、高效（并行完成多个复杂任务）、主动（持续观察环境事件并自行推进）与持久（始终在线、异常自动恢复）。

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

整体架构由双层架构、事件驱动、面向人的交互、计算与状态及环境分离、Watchdog 五部分组成。其中双层架构的职责划分如下：

• Router 层：常驻的全局路由层，承接所有入口的人类交互，充当全局序点、协调点与记忆，只负责交互与任务分派、不直接执行具体任务，甚至可以不配备 Bash 工具。官方表示，实践中用较轻量的模型往往即可兼顾速度与效果。
• Worker 层：由上下文彼此隔离的会话组成，挂载完整的执行工具，在独立上下文中专注完成单一任务。由于直接决定任务结果与代码质量，Worker 通常配置能力最强的模型。

Worker 不直接向用户回复，而是将状态和结果汇报给 Router 层，由后者统一对外沟通。文章认为，让用户手动管理 Session 在很大程度上是从底层 LLM API 延续下来的设计惯性，Session 应当是系统的实现细节，而不应是用户的认知负担。

事件驱动与配套机制

系统的主要输入从人类逐条键入的提示词，换成环境中的半结构化事件——群聊消息、邮件与日程提醒、代码审查评论、CI 运行结果等，官方称之为 Trigger。围绕 Trigger，文章介绍了以下机制：

• 两级过滤：程序层策略作为 Fast Path，按事件来源、群组范围、用户或机器人白名单等确定性条件先筛除大部分噪音，再由语义层策略（大模型）作为 Slow Path 判断是否需要行动。
• 订阅与直通：同一个 GitHub Pull Request、同一个 IM 话题下的连续事件构成 Thread。Worker 订阅 Thread 后，后续事件由程序直接发往该 Worker，无需每次经 Router 层转发。
• Inline & Spill 与链式召回：将近期可能用到的信息直接注入上下文窗口，超出预算或低频的内容留在窗外供按需读取；系统为 Trigger、Thread、Worker Session 等对象赋予唯一 ID 构成引用图，模型可沿引用关系逐跳找回历史任务上下文。
• 投机执行：根据环境信号在后台提前行动。例如收到会议邀约先核对日程冲突、搜集背景资料并备好回复草稿；内部配置的静默复现策略会在群聊讨论问题时于后台尝试复现，仅在确认问题且找到简单修复后才交付结果，否则全程保持安静。
• 异步 ReAct Loop：将耗时工具调用改为异步的 start() 与 stop()，调用后立即返回 Started 状态，后台结果作为新事件进入会话。官方说明该机制已在 DeepSeek Harness 中实现，但尚未默认开启。

在部署形态上，文章借鉴存算分离思想做两层解耦：Agent Loop 的计算放入云端无状态弹性计算容器、会话状态存入数据库，实现云端持久在线；重状态的执行环境留在用户本地设备，仅部署一个不保存会话状态的轻量 daemon 负责执行命令与返回结果，支持 BYOM（Bring Your Own Machine）。文章认为这一思路与 Anthropic 提出的脑手分离一致，区别在于后者描述的是托管服务中的按需沙箱，而 Super-agent 首先要接入的是用户日常使用、可能间歇在线的个人机器。主架构之外还设有独立的 Watchdog Session，由定时消息驱动构成外部控制回路，除处理接口报错等基础设施故障外，还会用模型判断各 Worker 是否取得实质进展、方向是否偏离目标，发现异常时介入修复。

初步实验：完成时间与吞吐数据

文章用群聊和 GitHub CI 消息流同时驱动四种端到端方案做消融实验：单次实验包含约 300 条消息，其中约 20 条为工作请求，其余为闲聊、跟进、叫停和 CI 消息；每种方案重复运行 5 次。

Router 层压力测试数据如下：

DeepSeek 团队据此认为，事件突发拥堵时 Router 层能够通过自动合并积压事件提高有效吞吐：上一轮推理期间到达的 Trigger 积压至下一轮一并注入，合并在 Prefill 阶段并行计算，单次请求耗时的增长远慢于批处理大小，因此积压越多，单个决定分摊的推理时间反而越低。

官方同时限定：以上实验基于合成负载与简化环境，衡量的是系统调度与协作能力，并非单个任务的实际执行能力，结果仅作初步参考。

官方披露的风险与开放问题

文章未回避安全与隐私风险：云端 Agent Loop 一旦因服务端入侵或提示词注入被攻破，其连接的全部端侧设备都面临被控制的潜在风险；即使云端未被攻破，只要端侧环境中的凭据能够进入模型的上下文，正常执行过程中同样存在凭据泄露的风险，需要设计让 Agent 在完全不接触凭据本身的情况下使用凭据的机制。

开放问题还包括：Router 层随任务规模的扩展方式、跨月乃至更长时间跨度的长程记忆、脱离 Session 后的人机协作界面，以及不同 Agent 实例之间的 A2A 通信等。

原型插件：dsh-superagent-prototype

文章同步提供了名为 dsh-superagent-prototype 的原型实现，官方明确该插件用于验证技术路线，并非 DeepSeek 正式产品。GitHub 仓库信息如下：

据仓库 README，dsh-superagent 是面向单个 GitHub 仓库的主动式编码代理，打包为 DeepSeek Harness 的 bundle，监听 GitHub 及可选的飞书消息：被允许的用户请求工作后，它在独立会话和目录中完成工作，并以 Pull Request 等形式回到原对话回复，仓库自带 Web 面板展示需要人工介入的事项。README 同时提示，代码源自团队日常开发工作、大部分工程由编码代理完成，已为发布做适配，与内部版本及文章所述实现并不完全一致，部分设计属于未来方向、未在本原型中实现。

官方在结语中表示，基于这套思路与 DeepSeek Harness 构建的内部 Super-agent 实例已持续运行，日常参与问题复现与修复、代码审查响应与 DeepSeek Harness 自身的迭代。