2026 年 10 月 31 日晚间，DeepSeek Harness 团队公布了一项自主 Agent 探索项目 Super-agent 的底层架构，相关设计思路写在了技术文章《Super-agent 设计探索：迈向更自主的 Agent 系统》里。这次开源最值得关注的地方，并不在于又多了一个会聊天的模型，而在于它把"会话调度"这件原本压在人身上的事，交还给了系统层——换句话说，让 AI 来管 AI。配套的DeepSeek Super-agent 开源仓库已经放出。根据 GitHub API 实测，该仓库采用 MIT 协议，创建于 2026-10-31，截至 2026-11-02 已经收获约 9,374 颗星，主要语言为 TypeScript，默认分支是 main，仓库描述写着 "Towards a More Autonomous Agent System"。这意味着，今天你就能把代码拉下来，照着它的路子，搭一个"一直在线、能同时干多件事、会主动找活干、出问题能自己恢复"的 Agent。
它想解决什么：人成了 Agent 的瓶颈
今天的许多多 Agent 系统，真正的瓶颈往往不在模型，而在"人"。你给一个 Agent 派活，它干完一件，就停在那儿等你的下一条指令；再干一件，再等。任务一旦变多变杂，人就变成了整个链路里最慢的节点：要不停地分发任务、汇总结果、判断下一步往哪走。DeepSeek Harness 团队在技术文章中称，他们想要造出的，是一个"一直在线、能同时干多件事、会主动找活干、出问题能自己恢复"的 Agent。
注意这里的目标并不是"更聪明的单点模型"，而是一套更像计算机系统的调度体系。团队把调度、缓存、存算分离、看门狗（Watchdog）这些经典工程世界里反复验证过的思想，直接搬进了 Agent 架构。这也是为什么这次开源的重心是"架构"而不是"模型权重"——它交付的是一套让 Agent 自主运转起来的方法学，重点落在系统层如何接管会话调度。
回顾 Agent 发展的脉络，过去大家普遍在卷单 Agent 的工具调用能力、卷上下文长度、卷推理深度。但 Super-agent 指向的是另一个维度：当 Agent 数量变多、任务变长，瓶颈会从"单个 Agent 聪不聪明"转移到"整个系统会不会自己编排"。这次开源，正是把这个长期被忽视的维度摆到了台面上。
落到具体设计上，团队把整套方案拆成了五个模块来落地这套思想：双层架构（Router 加 Worker）、事件驱动、异步多信道交互、存算分离，以及外部的 Watchdog。前两个模块负责"怎么分派"和"怎么被触发"，中间两个模块负责"怎么并发"和"怎么管状态"，最后那个 Watchdog 负责"出事怎么办"。五个模块环环相扣，缺了任何一个，"系统层接管会话调度"都很难真正跑顺。这也解释了为什么团队反复强调，它交付的是一套工程方法论，而不是单点能力的堆砌。
双层架构：Router 分派，Worker 干活
整套架构最核心的一层，是双层结构，也就是 Router 加 Worker 的配合。
Router 层常驻为全局路由，负责承接人类交互和全局协调。它的原则很明确：只分派任务，不亲自干活。这一步带来两个直接好处。第一，因为 Router 不做具体执行，它可以把多次决定合并起来做批处理，把推理成本摊薄；第二，Router 可以不挂载像 Bash 这样危险的执行工具，甚至使用更轻量的模型，从而跑得更快、也更省资源。一个只做调度的轻量角色，天然适合长期在线。
Worker 层则与 Router 做上下文隔离，每个 Worker 挂载完整的执行工具，并发地执行具体任务。Worker 干完之后，把结果汇报给 Router，再由 Router 统一对外回复。这就避免了多会话各自回复、信息互相打架的混乱局面——对外只有一个出口，对内可以无限并行。
可以这么理解这套分工：Router 像一个永远在岗、不写代码的项目经理，只负责拆任务、派活、收尾；Worker 像并行开工的工程师，各自专注把分配给自己的那块活干完，最后统一由项目经理汇总出口。这样一种职责分离，正是"系统层接管会话调度"的关键落点。它解决的，正是"多 Agent 各自为战、人疲于协调"的老问题。
事件驱动：不让 Agent 干等指令
如果 Agent 只能被动等人下指令，它就还是个高级点的脚本。Super-agent 引入事件驱动机制，正是为了让 Agent 主动起来。
环境里发生的各种事件——群聊里冒出来的新消息、一封新到的邮件、一次 CI 的构建结果——都被抽象成统一的 Trigger。这些 Trigger 不会一股脑全丢给模型，而是先经过两级过滤：先用程序做快速筛选，把明显无关的噪声挡掉；再用语义模型做慢速判断，决定哪些事件真正值得 Agent 介入。这样既不浪费推理，也不漏掉关键信号。
更有意思的是"订阅与直通"机制。当一个 Thread 已经被某个 Worker 接手之后，这个 Thread 后续产生的事件会直接发给对应的 Worker，绕开 Router 重新走一遍全局路由。相当于 Agent 一旦认领了一件事，就持续盯着它，而不是每次都从零开始排队。GitHub 仓库显示，这种订阅直通机制显著减少了 Router 的重复决策，是减轻全局路由压力的关键设计。
此外还有异步多信道交互与存算分离两条线。异步多信道让 Agent 能同时盯着邮件、群聊、代码仓库等多个来源；存算分离则把"状态存储"和"计算执行"拆开，让 Worker 可以无状态地扩缩，状态集中管理。再加上外部 Watchdog 机制：Watchdog 不碰具体业务，专职盯着整个系统有没有卡死或者跑偏。一旦发现某个 Worker 长时间没进展，或者流程陷入异常，Watchdog 可以介入中断、重启、或者把任务重新分派，让系统具备自愈能力。这同样是把计算机世界里经典的看门狗思想，原封不动搬进了 Agent 系统。
实验说了什么：快了，但更费 token
光有架构还不够，团队给出了一组初步的实验数字。这里必须先强调一句：这些数字基于合成负载和简化环境，是初步参考，不能当成正式产品结论。
先看速度。实验里，一半的任务在 12.4 分钟内完成，95% 的任务在 15.7 分钟内完成，明显优于使用 Subagent 工具的单 Session 方案。与此同时，Router 的批处理把单次决定的分摊推理时间从 6.4 秒降到了 1.6 秒——这正是 Router 能把多个决定合并处理的直接体现。
再看代价。当关掉"订阅直通"之后，Router 的决定数量增加了大约 30%，而读取缓存的 token 从 2,323 万增加到了 3,177 万。换句话说，系统是用更多的 token，换来了更稳、更快的响应。这恰恰就是这套架构的核心取舍：拿更多 token 换时间与稳定性。对真正的工程团队来说，这种取舍往往划算——一次稳定推进、不返工，比省下的那点 token 值钱得多。
需要提醒的是，"快"和"省"在这套设计里是一对矛盾。Router 批处理、订阅直通，都是在用空间（token、状态）换时间（延迟、稳定）。如果你追求极致省钱，这套架构未必最优；但如果你追求的是"长时间无人值守还能稳定推进"，它就是冲着这个场景去的。
已经有人在用：IM 与 GitHub 间连续推进
这套架构不是纸上谈兵。智东西在 11 月 1 日的报道中提到，DeepSeek 已经基于 DeepSeek Harness 构建了一个内部的 Super-agent 实例，用在了日常研发协作里。
这个实例会在 IM 群聊和 GitHub PR 之间连续推进任务。更关键的是，它不需要被人 @ 才动：系统能够主动识别代码里的缺陷，并且自行提交修复 PR。这正体现了"会主动找活干、出问题能自己恢复"的设计目标。它已经连接了 GitHub 和飞书，也就是说，它既能读群聊里的讨论，又能碰代码仓库里的改动，把原本分散的工作流串成了一条线。
从工程角度看，这才是 Super-agent 最有说服力的地方。很多 Agent 演示停在"给个 prompt 跑一段"，而这个内部实例展示的是"跨系统、长周期、少人值守"的真实用法。它证明了"系统层接管会话调度"不只是架构图上的漂亮说法，而是能在研发流水线里真正跑起来的东西。
这套思路能直接抄吗
要回答这个问题，得先看清它的定位。DeepSeek Harness 团队明确把它定位为"面向工程实践的架构探索 + 开源原型"，它还不是 DeepSeek 正式的独立产品。仓库路径 github.com/deepseek-ai/dsh-superagent-prototype 上挂着的，就是这样一份原型；精确地说，它的归属是 deepseek-ai/dsh-superagent-prototype，采用 MIT 协议，任何人都可以基于它做二次开发，门槛相当低。
所以"能不能直接抄"，答案是：架构思路可以抄、值得抄，但别把它当成开箱即用的成品。对小团队和个人而言，最有价值的不是复制整套系统，而是借鉴其中几条原则——把调度和执行的职责分开、用事件而不是轮询去驱动 Agent、给系统配一个能兜底重启的 Watchdog。哪怕你手里只有单模型，把这些思想用起来，也能少踩很多坑。
另外必须保持清醒：实验基于合成负载，结论不能直接外推到真实复杂业务。等真正落地时，你会发现真实环境的事件噪声、长尾任务、权限边界，都比实验里复杂得多。先小范围试，再慢慢放大，是比较稳妥的节奏。
常见问题
Q1： Super-agent 和常见的 Agent Team 有什么区别？
A1：常见的 Agent Team 通常由人驱动，人负责派活、汇总和下一步决策，Agent 之间更像是被串联起来的工具。Super-agent 把"会话调度"这件事交给了系统层的 Router，由常驻的 Router 统一分派、由隔离的 Worker 并发执行、再由 Router 统一出口，并辅以事件驱动和外部 Watchdog。区别的核心在于：调度从"人"转移到了"系统"。
Q2： Router 层会成为性能瓶颈吗？
A2：理论上，如果所有事件都过 Router，它确实可能成为瓶颈。团队用两个手段缓解：一是 Router 只做分派、不做具体执行，可以挂更轻量的模型；二是引入"订阅直通"，Worker 认领某个 Thread 后，后续事件直接发给 Worker，绕开 Router。实验显示，关掉订阅直通后 Router 的决定数量会增加约 30%，说明直通机制对减轻 Router 压力作用明显。
Q3： 这个架构现在能直接用吗，它是产品吗？
A3：不是正式产品。它定位为面向工程实践的架构探索加开源原型，仓库 deepseek-ai/dsh-superagent-prototype 采用 MIT 协议，任何人都能拉取并做二次开发，但 DeepSeek 并未把它作为独立产品发布。想用的人，目前更适合把它当参考实现来借鉴，而不是当成开箱即用的 SaaS。
Q4： 实验数据可靠吗，评测环境怎么样？
A4：需要谨慎看待。团队自己在技术文章中强调，实验基于合成负载与简化环境，是初步参考，不是正式产品结论。给出的数字——一半任务 12.4 分钟、95% 任务 15.7 分钟、单次决定 6.4 秒降到 1.6 秒——反映的是特定负载下的趋势，不能简单外推到真实复杂业务。
Q5： 普通人或者小团队怎么借鉴这套思路？
A5：不必复制整套系统，重点借鉴三个原则：第一，把调度和执行分离，让一个轻量角色专职分派；第二，用事件触发而不是轮询等待，让 Agent 主动响应；第三，加一个 Watchdog 做兜底，遇到卡死能中断重启。哪怕只用单模型，这些思想也能显著提升 Agent 系统的稳定性。