大家好，我是程序员天天困。

先给结论：**DeepSeek Super-agent** 不是一个新模型，是一套回答“谁来管会话”的架构设计。

10 月 31 日晚上，DeepSeek Harness 团队发了篇长文，顺手把一个 GitHub 仓库挂了出来。

![DeepSeek Harness 团队官方公众号发布的 Super-agent 设计探索全文，时间 2026 年 10 月 31 日](https://developer.qcloudimg.com/http-save/yehe-11608098/bc9d241bf171f55e100702c9c9cd62fa.png)

当晚技术群里转的标题一个比一个猛：超级智能体来了、AI 开始给 AI 派活。

我把它读完，又对着仓库 README 读了一遍，感觉大部分人是把它当成“DeepSeek 出了个新产品”在看。这不太对。今天这篇就干一件事：把 **DeepSeek Super-agent** 到底是个什么东西讲清楚，它解决什么、靠什么转、以及哪儿现在还只是个想法。

## 一、先把话说清楚：DeepSeek Super-agent 不是一个模型

**DeepSeek Super-agent**：DeepSeek Harness 团队 2026 年 10 月 31 日公开的 Agent 系统架构设计，把「维护会话、同步上下文、分派任务」这些原本压在用户身上的活搬到系统层。它不是模型，也不是一个能装的产品，你更该把它当成一份系统设计文档——只不过作者顺手把代码也开源了。

官方原文的标题是《Super-agent 设计探索：迈向更自主的 Agent 系统》。作者在文首就写了一句很多人会略过的话：这篇谈的是工程实践里的架构思路，并非对现有产品功能的介绍。

这句话是理解全文的前提。

他们把这种 Agent 形态归纳成四个词：

- 连续：你在 IM 里说用方案 A，转头在 PR 评论里改成方案 B，它得接得住。
- 高效：几个复杂任务并行推，不用等上一个跑完才听下一句。
- 主动：没人 @ 它，它也能从群聊里看出“这个问题值得管”。
- 持久：你合上电脑，它还在。

四个词翻译成人话，其实就一句：别让我记住哪个窗口里聊到哪了。

## 二、它戳的痛点：你不是在写代码，你在当消息总线

这种场景在研发团队里一天要演好几遍：支付群报超时、GitHub 来 review comment、另一个需求的测试还在跑，产品在飞书里问「按钮什么时候上」。

四件事，四个窗口，四份上下文。真正写代码的时间，往往远少于在这些窗口之间搬运信息的时间。

官方原文的说法是：一个人同时能跟住的活跃会话，大概就是 3 到 5 个。超出这个数，你脑子里存的不再是代码，而是“哪件事卡在谁那里”。

一个任务能走多远，看模型；十件事能不能同时推进，看你还剩多少注意力。

现在市面上的 Agent 产品，卷的是上下文窗口多大、能开几个子 Agent、一次能改几个文件。这些当然有用，但它们回答的是“一个任务能做多好”，没回答“十个任务谁来管”。

![](https://developer.qcloudimg.com/http-save/yehe-11608098/83f9f91e74d1a0253e69c676a20f19a6.jpg)

## 三、Router 和 Worker：把会话这层拆开，架构就懂了

大多数 Agent 都围着 Session 转：一个会话一个 ReAct Loop，串行。想并行就多开会话，然后自己当调度。

Super-agent 的做法是把这件事劈成两层。

**Router（路由层）**：常驻的全局入口，所有人类交互先进这里。它维护全局上下文、判断这条消息跟哪件事有关、把任务分派出去。关键在于它不干具体的活——官方原文里甚至说，Router 可以不配 Bash 工具。

这个细节我很喜欢。它不是靠“请勿执行任务”这种提示词约束，而是直接把工具拿掉：能力边界比自我克制可靠。

**Worker（工作层）**：真正的执行单元，每个 Worker 上下文隔离，挂满工具，专心推进一件事。它不直接跟人说话，状态和结果汇报给 Router，由 Router 统一对外回复。

打个比方，Router 像餐厅的大堂经理：接客、排桌、把单子递进后厨，自己不炒菜。Worker 是后厨各个灶台，各炒各的，炒完喊一声，经理端出去。经理要是自己冲进厨房炒两个菜，门口就没人接客了。

把这条链路画出来，就是下面这样——注意 Worker 之间没有连线，所有对外的话都由 Router 说。

![DeepSeek Super-agent 双层架构：Router 层统一接单分派，Worker 层隔离并发执行，结果由 Router 统一回复](https://developer.qcloudimg.com/http-save/yehe-11608098/8594d11f2725513d4c576002d03a724b.png)

有人会说，这不就是 Agent Team 吗？主 Agent 分派，子 Agent 干活。

区别在负载。常见的 Agent Team 是围绕**一个复杂任务**拆步骤的，步骤之间耦合紧，主 Agent 得深入细节、规划子任务、高频协调，推理负担很重。Super-agent 的 Router 只处理任务**之间**的关系，不碰任务内部的拆解，所以官方原文里说它用轻量模型往往就够。

一句话概括分工：Router 管关系，Worker 管细节。

![](https://developer.qcloudimg.com/http-save/yehe-11608098/91bfd102e012d4fecf2ed71f63ae9456.png)

## 四、事件、Thread、直通：没人 @ 它，它怎么主动干活

主动这件事，本质上是换驱动源。

以前是你往输入框里敲字，Agent 才动。现在驱动它的是环境里半结构化的事件——群消息、PR 评论、CI 结果、邮件。官方原文给这类事件起了个名字。

**Trigger（触发事件）**：进入系统的环境事件，是 Super-agent 的主要输入，替代了原来由人逐条敲进去的提示词。

但一个工作群一天几千条，全丢给大模型判断，钱和延迟都受不了。所以他们做了两级过滤，思路借的是计算机系统里的快慢路径：

- 程序层先过一遍：来源、群范围、白名单，规则能判的直接拦掉，这是快路径。
- 剩下的交给模型：结合上下文判断值不值得动手，这是慢路径。

**Thread（事件流）**：同一个 PR、同一个 IM 话题、同一封邮件串下面的连续事件，算一条流。

这里有个我觉得最聪明的设计：直通。Router 给某条 Thread 开了 Worker 之后，这条 Thread 后续的事件由程序直接发给对应的 Worker，不再经过 Router。Worker 能同时订阅多条 Thread，一条 Thread 也能被多个 Worker 订阅——两个 Worker 撞到同一个 PR 上时，都能看到对方的动静，自己解决冲突，不需要点对点通信。

把一条事件从进门到交付摊开，大概是这个走向：

![DeepSeek Super-agent 事件驱动：Trigger 经两级过滤后，由 Router 分派或直接直达已订阅的 Worker](https://developer.qcloudimg.com/http-save/yehe-11608098/6f1c28eeba21c1e0f30ecd893ebd6736.png)

效果有多大？官方原文给了个数：把直通去掉，任务完成时间几乎没变，但 Router 要做的决定多了约 30%，总读缓存 token 从 2323 万涨到 3177 万，涨了约 37%。

这个数比很多跑分都能说明问题：多 Agent 协作出毛病，常常不是模型不聪明，而是架构让一个中心节点扛了不该它扛的流量。

还有几个机制我快速带过：

- Inline & Spill：近期大概率要用的信息直接塞进上下文，超预算的留在窗口外只留引用，模型要用再去读。说白了就是把上下文窗口当缓存管。
- 链式召回（Chain of Recall）：给 Trigger、Thread、Worker Session 都编上 ID，注入时带上关联对象的 ID，这些对象在底层连成一张引用图，模型能顺着 ID 一跳一跳把旧任务捞回来。
- 投机执行：收到会议邀约，先在后台查日程冲突、备好回复草稿；群里有人报 bug，先在后台复现，确认了、也找到简单修法了才说话，否则全程安静。他们内部真配了这么一条“静默复现并修复”的策略。

> **可能有人会问：没人 @ 它，它凭什么判断该不该管？**
>
> 靠两层策略叠加。程序层先按来源和范围粗筛，语义层再由模型按提示词里写的策略判断。语义层是纯自然语言的，团队想加规矩，改提示词就行，不用动代码——所以“该不该管”，最后拼的是团队把规则写得有多清楚。

## 五、为了“一直在”，他们动了三处

前四节讲的是怎么接活，这一节讲怎么不下班。

现在你在本地跑 Agent，有个很土但很致命的问题：电脑一合盖，它就停了。计算、状态、执行环境全绑在一台机器上。Super-agent 分三步处理这件事：

1）异步 ReAct Loop。原来的 run() 是阻塞的，工具不返回，循环就卡着，你发消息它也不理。他们改成异步的 start() 和 stop()：调 start() 立刻拿到“已启动”，循环继续往下走，后台结果跑完再作为一条新事件投进来。这个能力已经在 DeepSeek Harness 里实现了，但**没有默认开启**——别看到官方原文就以为现在就能用。

2）存算分离。把推进 Agent Loop 的计算放进云端无状态容器，Session 这类要持久化的状态进数据库。容器可以重启、替换、水平扩，连续性由存储兜。

3）计算与执行环境分离。代码、未提交的本地改动、私有凭据、内网服务，这些东西根本没法完整搬上云。他们的选择是让环境留在原地，端上只放一个不保存会话状态的轻量 daemon，只负责执行命令、返回结果。这套设计支持 BYOM（Bring Your Own Machine），也支持云端托管机器。

![](https://developer.qcloudimg.com/http-save/yehe-11608098/850952ba177ace7c006a5e30f3429f88.png)

再加一个 Watchdog：主系统之外单开一个 Session，用定时消息驱动，构成外部控制回路。它不只盯接口报错、状态恢复失败这些基础设施问题，还会让模型判断每个 Worker 有没有实质进展、方向有没有跑偏。发现不对就介入修，偶发故障就持续复查到恢复。

因为 Watchdog 本身也是个有完整工具的 Session，维护者可以直接用自然语言问它“昨天那个 Worker 为什么卡住了”，也能让它在线改主系统的行为，比如增删提示词、调触发规则。

| 维度         | 本地单会话 Agent | Super-agent               |
| ------------ | ---------------- | ------------------------- |
| 计算在哪     | 你的电脑         | 云端无状态容器            |
| 状态在哪     | 内存或本地文件   | 持久化数据库              |
| 执行环境在哪 | 同一台机器       | 原地 daemon，可跨设备接入 |
| 关机之后     | 任务停           | 继续跑，设备上线后再补    |
| 谁管会话     | 你               | Router 层                 |

## 六、那组实验数据，能证明什么，不能证明什么

官方原文给了两组实验。我把设置和结论分开讲，因为传得最广的那半句是被截出来的。

端到端消融：一次实验约 300 条消息，真正算工作请求的只有 20 条上下；剩下的是聊天、催进度、中途喊停，还有一堆 CI 通知。写代码那一步被换成了一个空转耗时的假工具，每种方案跑 5 遍。

| 方案                                  | 完成时间 p50 | 完成时间 p95       |
| ------------------------------------- | ------------ | ------------------ |
| Super-agent                           | 12.4 分钟    | 15.7 分钟          |
| 单 Session + Subagent（中性提示）     | —            | 29.5 分钟          |
| 单 Session + Subagent（提示优先委派） | 好于中性     | 仍慢于 Super-agent |

p95 从 29.5 分钟到 15.7 分钟，缩短约 47%。

但我觉得更值得看的是中间那段。中性提示下，模型 5 次运行**一次都没有**主动调 Subagent，所有活都在主会话里干，被新消息不停打断。换成明确鼓励委派的提示词后，5 次里 4 次委派了，还剩 1 次它觉得“这活很小”自己干了，于是结果里多出一根明显的长尾。

同样的模型，同样的工具，只换提示词，协作行为就完全变了。这才是他们要把协调写进架构的真正理由——不是提示词没用，是提示词太不稳。

Router 压测那边：Worker 换成 Mock，把需要判断的 Trigger 从每分钟 1 条加到 40 条。平均 batch 从 1.0 涨到 2.8，单次请求耗时只从 2.5 秒到 3.9 秒，摊到每个决定上反而从 6.4 秒降到 1.6 秒。积压越多、单位成本越低，因为合并后的 Trigger 在 Prefill 阶段并行算了。

不能证明的部分得说清楚：这是合成负载、简化环境、假工具，作者自己也写了“仅作为初步参考”。它衡量的是调度与协作能力，不是这个 Agent 写代码有多强。

所以拿 47% 去说“效率翻倍”，是过度解读。我的判断是：这组数据足以支撑“双层架构比单会话更能扛并发”，但远不足以支撑“你上线就能省一半时间”。

## 七、开源原型不等于官方原文里的蓝图

这是我最想提醒的一点。

仓库叫 dsh-superagent-prototype，MIT 协议。README 开头写得很直白：仅供参考的研究原型，不是 DeepSeek 官方产品；是研究代码，不是生产级软件；为公开发布做过适配，和团队内部版本、和官方原文里描述的实现都不完全一致，有些设计只停留在方向层面，原型并没有实现。

![](https://developer.qcloudimg.com/http-save/yehe-11608098/c9ddcda0cd491b95f98d99a742f64350.png)

我对着 README 和官方原文比了一遍，差距主要在这几块：

| 官方原文里讲的                        | 原型里的情况             |
| ------------------------------------- | ------------------------ |
| Router/Worker 双层、GitHub 与飞书触发 | 有，README 写了          |
| Thread 订阅直通、投机执行             | README 未提              |
| 云端存算分离、BYOM 接本地开发机       | README 未提，属设计方向  |
| 跨实例 A2A 通信、跨月长程记忆         | 官方原文明确列为开放问题 |

原型实际能干的活，范围比标题小得多：它只服务**一个 GitHub 仓库**，监听 GitHub（可选飞书），有人向它要活时开一个 work item，在自己的会话和目录里干，然后回到原对话里回你，比如直接开个 PR。另外有个 web 面板，把需要人处理的事列出来。

![](https://developer.qcloudimg.com/http-save/yehe-11608098/1c9b7d4461909999fc29af36d0af1f03.jpg)

所以现在的正确用法是：把它当成一份能跑起来读的架构参考，而不是一套今天就能部署的效率方案。想动手，README 里有一套让 Agent 带着你配的流程；想省事，先别急。

## 八、我的判断：方向值得盯，工作流先别换

说几个我自己的看法。

这套东西最值得学的不是 Router 和 Worker 这两个词，是它处理“人的注意力”的方式。把 Session 当成实现细节、把用户从会话管理里摘出去，这个视角转换比任何具体模块都重要。你现在用的产品，有几个是围着“这件事做到哪了”设计的，而不是围着“这个窗口聊到哪了”？多数还是后者。

也别被“AI 自己给 AI 派活”这种说法带跑。它接的活仍然被白名单和团队写下的规则框着，开源的这套，来源目前也就 GitHub 和飞书。真实研发上下文散在会议、私聊、线上事故和深夜的电话里，比这两个渠道复杂不止一个量级。短期看程序员的位置没变：你还是在真实世界里收集信息、做判断、把结论喂给 Agent 的那个人。

安全那块是真问题，不是走过场。官方原文自己列了：云端 Agent 接进本地设备之后，提示词注入、端侧凭据泄露、跨设备权限，一个比一个难。他们提的方向是让 Agent 在不接触凭据本身的前提下使用凭据——这话说起来容易，做起来是另一回事。

带限定的判断：以 2026 年 11 月这个时间点看，DeepSeek Super-agent 更像一份写给整个行业的架构提案，而不是你今天装上就能提效的工具。想尝鲜，去读仓库的 README 和 docs；想提效，先把你自己那几个会话的边界理清楚，收益可能更直接。

----

我是程序员天天困，持续分享编程干货。觉得有用的话记得点赞收藏和关注~也欢迎在评论区聊聊：你现在同时开着几个 Agent 会话？看完 DeepSeek Super-agent 这套双层架构，你觉得它真能替你管过来吗？

先给结论：DeepSeek Super-agent 不是一个新模型，是一套回答“谁来管会话”的架构设计。

DeepSeek 发布的新架构 Super-agent 是什么，带你认识新理念

DeepSeek Super-agent 不是新模型，而是把 Router 和 Worker 拆成两层的调度架构。讲清它解决什么、怎么转、哪里还用不上

人工智能

架构设计

云计算

DeepSeekSuper-agent是DeepSeekHarness团队开源的Agent系统架构设计，非新模型。其核心采用Router与Worker双层架构，Router管任务关系、Worker管执行细节，通过事件驱动、Thread直通机制解决多会话管理痛点，降低中心节点负载。原型代码已公开，但部分设计仍属探索方向，现阶段更宜作为架构参考而非生产工具。

提示词注入

数据库

智能体

DeepSeek

容器

路由

GitHub

Agent

快速部署LLM、AI绘画等应用,助你玩转AIGC！


文章

问答

视频

教程

学习中心

腾讯云实验室

直播

竞赛

腾讯云代码分析专区

腾讯iOA零信任安全管理系统专区

腾讯云架构师技术同盟交流圈

腾讯云数据库专区

腾讯云智能顾问专区

腾讯云原生专区

腾讯混元专区

腾讯云TCE专区

腾讯云Lighthouse专区

腾讯云HAI专区

腾讯云Edgeone专区

腾讯云存储专区

腾讯云智能专区

腾讯轻联专区 

腾讯云开发专区

TAPD专区

腾讯轻量云游戏服专区

EdgeOne AI 安全实战专区

腾讯云最具价值专家

腾讯云架构师技术同盟

腾讯云创作之星

腾讯云开发者先锋

腾讯云代码助手

云原生构建

TAPD 敏捷项目管理

Cloud Studio

SDK中心

API中心

命令行工具

涵盖代码开发、场景应用、自动测试全流程，助你从零构建专属AI助手

一站式MCP教程库，解锁AI应用新玩法

聚焦“写作效率、视觉美观与运行性能”三方面进行全面升级，为您提供更高效、稳定的创作环境

社区富文本&Markdown编辑器全新改版上线，欢迎大家体验!

诚挚邀请您参与本次调研，分享您的真实使用感受与建议。您的反馈至关重要，感谢您的支持与参与！

社区新版编辑器体验调研

DeepSeekSuper-agent是DeepSeekHarness团队开源的Agent系统架构设计，非新模型。其核心采用Router与Worker双层架构，Router管任务关系、Worker管执行细节，通过事件驱动、Thread直通机制解决多会话管理痛点，降低中心节点负载。原型代码已公开，但部分设计仍属探索方向，...

DeepSeek 发布的新架构 Super-agent 是什么，带你认识新理念-腾讯云开发者社区-腾讯云

DeepSeek 发布的新架构 Super-agent 是什么，带你认识新理念

DeepSeek 发布的新架构 Super-agent 是什么，带你认识新理念

社区

活动

圈层

关于

腾讯云开发者

热门产品

热门推荐

更多推荐