前言

10月31日晚，DeepSeek Harness 团队在官方公众号发布文章《Super-Agent 设计探索：迈向更自主的 Agent 系统》，并同步开源了研究原型 dsh-superagent-prototype。这无疑是 DeepSeek 官方近期投下的又一枚“技术核弹”（最近 DeepSeek 的动作确实够频繁的）。dsh-superagent-prototype 仓库上线仅三天便狂揽 1.5 万 Star，足见技术社区对该项目的关注度。

那么，Super-Agent 到底是什么？为何能赢得如此高的关注？简单来说，它是一套智能体系统架构。用官方的话说：“单任务的上限取决于模型能力，而多任务的上限取决于人的注意力。”Super-Agent 要解决的，正是多任务场景下“人的注意力不能过度分散”所带来的行为制约。

笔者最近每天都会阅读 Super-Agent 相关的技术文章与源码。今天，就带大家逐层拆解 Super-Agent 的核心原理与架构设计，看看 DeepSeek Harness 团队如何把操作系统中的进程调度、缓存、存算分离等经典思想迁移到智能体系统中。

一、为什么需要Super-Agent？

相信大家都有过这样的经历，手头积压了一堆活，改 Bug呀、写文档呀、跑数据呀……。每件事都得单独开一个会话，于是三个会话（Session）同时开着，还得时不时切过去看看进度。如果活再多一点，会话越开越多，切来切去，很快就忘了哪个Session干到哪了。

这不是大家的问题，而是现有大模型产品架构的问题。DeepSeek 团队观察到一个扎心的事实：一个人通常只能同时跟进3到5个活跃Session。现有主流智能体都以单一会话为基本单位，会话之间彼此独立，上下文互不相通。模型再强，但是人的注意力跟不上、无法同时开太多会话，效率自然也高不到哪里去。

Super-Agent 的目标，就是打破智能体与单次会话的绑定，让它成为一个跨会话保持上下文、并行推进多任务且互不干扰的连续实体。DeepSeek 官方团队为 Super-Agent 归纳了四个基础特征：

• 连续：在 IM 群聊、GitHub 评论等任何渠道交互，用户感觉始终只有“一个”智能体，无需开启多个会话；
• 高效：并行处理多个复杂任务，无需等待上一个任务完成；
• 主动：持续观察环境事件，主动找活干，不需要时保持安静；
• 持久：7×24 小时在线，遇到异常自动恢复。

二、Super-Agent核心架构：五大模块拆解

dsh-superagent是DeepSeek Harness的插件，也一个“极其主动”的智能体，目前支持GitHub仓库和飞书。以GitHub为例：当有人向智能体发起工作请求时，智能体会开启一个工作项，并自动分配Worker执行任务。人类不需要决定任务该归属到哪个会话，只需关注任务本身。Super-Agent插件采用了不少巧妙的设计思想，主要可以归结为以下五类：

2.1 双层架构：Router分派任务，Worker负责干活

双层架构是 Super-Agent 最核心的设计。DeepSeek Harness 通过两层架构分别维护全局连续性和支持高并发执行：

• Router 层：常驻的全局路由，统一承接人类交互、维护全局上下文、分派任务。它只分派不干活，甚至可以不配备 Bash 等基础命令行工具；
• Worker 层：上下文彼此隔离的执行会话，挂载完整工具链，专注完成单一任务，通常配置能力最强的模型。Worker 只干活不抢话，结果统一汇报给 Router，由 Router 对外回复。

可能有人会问：“这和我平时使用的多智能体有什么区别？”其实两者本质完全不同。大家平时使用的多智能体，通常仍发生在一个会话内：主智能体负责分配任务，子智能体负责执行。而Router-Worker架构面向的是多会话。它相当于把所有会话归拢到一个统一入口中。你的单项工作只是这个入口中的一个任务，由Router通知Worker去完成。至于Worker如何完成，既可以由Worker自行决定，也可以由Worker内部再采用多智能体方式协作。这样讲大家是不是就理解了~

单一会话有什么好处？举个例子：你在IM里说“用方案 A”，随后又在GitHub PR评论里改成“方案 B”，Router 依然能识别出这是同一个任务，并通知对应Worker调整方向。如果采用多会话，两个会话会同时推进，可能把项目改乱（除非你提前停掉其中一个）。Router-Worker 的工作模式很像操作系统的进程调度：Router是内核调度器，Worker是被隔离的进程。

2.2 事件驱动：不等指令，主动找活

传统智能体是“你问一句，它答一句”，只处理当前布置的任务。Super-Agent的输入除了用户指令，还包括环境事件：群聊消息、邮件、日程提醒、代码评审评论、CI 运行结果等，都会触发智能体执行相关操作，这些触发事件统称为Trigger。

不过一个显而易见的问题是：真实环境噪音很多，每条消息都交给大模型判断，成本根本扛不住。DeepSeek 借鉴Fast Path / Slow Path思想设计了两级过滤：

• Fast Path（程序层） ：用确定性代码按消息来源、群组、白名单快速筛掉无关消息；
• Slow Path（语义层） ：只有通过初筛的候选事件才交给大模型，由模型结合上下文判断是否要行动。

2.3 Thread订阅直通：后续事件不一定经过Router

Super-Agent在设计时，会把同一个GitHub PR、同一个IM话题下的连续事件归为一条Thread。Router 只在新任务冷启动时创建Worker并分配任务。Worker开启任务后，该任务即作为一条Thread；同一Thread的后续事件由程序直接投递给Worker，不再经过Router转发。

大家不要小看这个设计。经过DeepSeek Harness团队的消融实验，去掉Thread订阅直通后，Router的决策数增加约 30%，读缓存 Token 从 2323 万涨到 3177 万，多烧约37%的Token！可以说这个功能守护了广大像笔者这样的DeepSeek Harness深度用户的钱包~

2.4 上下文组织：Inline & Spill + 链式召回

对于这种全流程运行的智能体，一个直观问题就是上下文会爆炸，因为信息源太多。Super-Agent 对此也有深入考虑，解法分为两层：

• Inline & Spill：近期常用信息直接放进上下文窗口（Inline），超长或低频内容截断后留在窗外（Spill），需要时再调用工具读取。
• 链式召回（Chain of Recall） ：Trigger、Thread、Worker Session 都有唯一 ID。注入上下文时，内联关联对象的 ID，构成一张引用图。模型可以从当前消息出发，顺着 ID 逐跳找回三个月前的旧任务上下文。

2.5 存算分离与 Watchdog：保证智能体持久在线

• 存算分离：推进 Agent Loop 的“计算”部署在云端持续在线，会话“状态”存入数据库，服务器重启也不丢失；本地代码仓库通过轻量后台进程被云端远程调用。
• 外部 Watchdog：长时间运行的智能体可能陷入死循环或跑偏，独立的外部 Watchdog 负责监控各 Worker 状态，发现异常即介入纠偏。

三、Super-Agent源码快速解析

DeepSeek Harness发布的Super-Agent 插件，源码地址：https://github.com/deepseek-ai/dsh-superagent-prototype 。笔者最近分析了该插件的源码，发现其目录结构非常清晰地对应了Super-Agent 的架构思想：

• src/core：Router的核心逻辑，也是调度系统的核心源码，负责任务分配与并发控制；
• src/sources：GitHub、飞书等事件源插件；
• src/executor：Worker执行器，每个Worker可派生独立的Session和工作目录；
• src/core/health.ts：通过心跳进行健康巡检，是Watchdog的雏形。

更让笔者称道的是 DeepSeek 团队的安全意识：插件设置了严密的角色隔离，Sources 只能上报事件，主 Session 只能评估分派，Executor 只能汇报事实。架构约束不再依赖“开发者自觉”，而是在编译期就拦住了越权。

四、Super-Agent实战

理论了解了，还是要通过实践直观感受一下 Super-Agent 的特性。按如下步骤安装并使用 Super-Agent。

注意：Super-Agent 是 DeepSeek Harness 的一个插件，前期务必先装好 DeepSeek Harness，大家可以参考笔者的文章 DeepSeek Harness 入门很简单（一）——认识 DeepSeek Harness 并安装。另外，目前 Super-Agent 插件不支持在 Windows 系统下运行，大家可以按照笔者文章中的说明，采用 WSL 安装 DeepSeek Harness。

1. 将 DeepSeek Harness 的仓库地址丢给 DeepSeek Harness，然后问它如何安装该插件（ https://github.com/deepseek-ai/dsh-superagent-prototype ）：

   

2. 跟随DeepSeek Harness的指引完成配置。配置完成后，就可以在DeepSeek Harness中看到一个名为 Super-Agent 的插件。配置流程比较复杂：需要注册一个GitHub小号充当DeepSeek Harness智能体机器人，还需要创建一个GitHub仓库并关联到该机器人。不过全程跟着DeepSeek Harness的指引是可以完成的。

3. 配置完成之后针对同一个Github仓库的一个项目。用户可以使用自己的账号去@ 刚才绑定智能体的小号，让它帮忙去完成一些任务。小号收到任务后会调用本地的deepseek harness完成任务并提交pr

   

4. 同时也可以在飞书中配置一个自动化机器人，大家可以自行尝试。接下来就可以直接下达命令，而不用太担心上下文问题，是不是很强大！

   

不过就笔者实际体验来看，通过GitHub下达命令编写代码，还是不如在Trae或直接在DeepSeek Harness中下达任务直观。毕竟Super-Agent目前只是 0.1 版本，官方也将其定位为参考原型，并非完整产品；同时它也非常吃电脑内存和配置。大家感兴趣可以体验，但目前想直接融入工作还不现实。

以上就是本篇文章全部内容~

五、总结

本篇文章介绍了Super-Agent，它最值得关注的地方，不在于它现在有多好用，而在于它提供了一种新思路：把操作系统中的进程调度、缓存分层、存算分离等经典思想，系统性地搬进智能体架构。Router-Worker双层架构解决全局连续性与并发执行，事件驱动让智能体主动找活，Thread订阅直通降低Router负担，Inline & Spill与链式召回控制上下文膨胀，存算分离和Watchdog保障持久在线——这五块设计彼此咬合，构成了一套可落地的工程参考。

如果大家觉得有收获，欢迎点赞、收藏，关注我的专栏《DeepSeek Harness 从入门到进阶》，后续更新不错过。下篇见！更多精彩内容，如果大家感兴趣，欢迎关注笔者的CSDN账号与专栏