---
title: "DeepSeek《Super-agent 设计探索》深度解读：当 Agent 不再绑定会话，瓶颈从模型转向人的注意力"
date: 2026-10-31
description: "深度解读 DeepSeek Harness 团队 2026 年 10 月 31 日发布的《Super-agent 设计探索》：四个基础特征、Router/Worker 双层架构、事件驱动与订阅直通、链式召回、投机执行、全双工交互、存算分离与 Watchdog，以及实验数据、开源原型的注意力原则、安全开放问题与落地建议。"
tags: ["DeepSeek", "Super-agent", "智能体架构", "DeepSeek Harness", "多智能体", "事件驱动", "AI安全"]
schema_type: Article
references:
  - title: "Super-agent 设计探索：迈向更自主的 Agent 系统"
    url: "https://mp.weixin.qq.com/s/zoS7GlReWPhfCjENGxXCdg"
    source: "DeepSeek Harness 团队微信公众号，2026-10-31"
  - title: "deepseek-ai/dsh-superagent-prototype"
    url: "https://github.com/deepseek-ai/dsh-superagent-prototype"
    source: "GitHub，MIT 许可，2026-10-31 创建"
  - title: "dsh-superagent 文档：000 Philosophy"
    url: "https://github.com/deepseek-ai/dsh-superagent-prototype/blob/main/docs/000-philosophy.md"
    source: "GitHub"
  - title: "dsh-superagent 文档：001 Domain model"
    url: "https://github.com/deepseek-ai/dsh-superagent-prototype/blob/main/docs/001-domain.md"
    source: "GitHub"
---

**核心判断（来源1）：单任务的上限取决于模型能力，多任务的上限取决于人的注意力。**

**DeepSeek 的答案（来源1）：打破 Agent 与单次会话的绑定，让它成为跨会话保持上下文、同时推进多项任务的连续实体，即 Super-agent。**

**关键数据（来源1）：在约 300 条消息、约 20 个工作请求的合成负载下，Super-agent 任务完成时间 p50 为 12.4 分钟、p95 为 15.7 分钟；中性提示下的单 Session 方案 p95 为 29.5 分钟。**

**本文判断：这篇文章的真正价值不是某个新算法，而是把操作系统和分布式系统的老办法系统地搬进 Agent 运行时；而它自己列出的安全与隐私问题，决定了这套架构能走多远。**

---

> 写作说明：文中标注“来源1”的为 DeepSeek 原文观点与数据，“来源2—4”为开源原型仓库内容；“本文分析”为作者推论。原文明确说明它是“面向工程实践的架构思路探讨，并非对 DeepSeek Harness 现有产品功能的介绍”（来源1）。

## 一、文章概况

- **标题**：Super-agent 设计探索：迈向更自主的 Agent 系统（来源1）
- **发布**：DeepSeek 产品部 DeepSeek Harness 团队，2026 年 10 月 31 日（来源1）
- **作者**：Yujia Qiao 完成系统实现和写作，团队十余人参与审阅讨论（来源1）
- **配套代码**：`dsh-superagent-prototype`，MIT 许可（来源2）
- **定位**：原型仓库声明其为“仅供参考的研究原型，不是 DeepSeek 官方产品”，与内部版本及文章描述的实现并不完全相同，文中部分设计是未来方向、原型中并未实现（来源2）

## 二、问题：为什么一个 Session 不够用了

原文的出发点很清楚（来源1）：

1. 以 Coding Agent 为代表的单任务 Agent 已证明模型能用工具解决复杂问题，且越来越少需要人类持续监控；
2. 近期个人助手（Personal Agent）集中涌现，直接接入消息、日程、邮件与工作平台，持续观察信息流；
3. 但主流 Agent 仍以单一 Session 为基本单位，用户并行推进多项工作时，必须手动切换并记住各个 Session 的上下文；
4. 据 DeepSeek 观察，一个人通常只能同时跟进 3 到 5 个活跃 Session。

只在本地单会话 Agent 上通过 CLI、MCP 或外部连接器做简单扩展，仍会受制于单会话同步阻塞、多任务上下文混乱、本地设备离线即停止运行等问题（来源1）。

## 三、四个基础特征

| 特征 | 含义（来源1） |
|---|---|
| 连续 | 用户在 IM、GitHub 评论等熟悉界面交互，感觉始终只有一个 Agent；在 IM 定方案 A、在 PR 评论改为方案 B，它能理解并调整 |
| 高效 | 响应迅速，并行高质量完成多个复杂任务，不必等上一个任务结束 |
| 主动 | 持续观察环境事件，主动推进值得处理的事项；不需要介入时保持安静 |
| 持久 | 始终在线，接入真实工作环境，长期运行中遇到异常能自动恢复 |

原文认为单个 ReAct Loop 无法同时支持这四个特征，并提出五个模块（来源1）：

| 模块 | 支撑的特征 |
|---|---|
| 双层架构 | 连续 + 高效 |
| 事件驱动 | 主动 |
| 面向人的交互 | 连续 + 高效 |
| 计算、状态与环境分离 | 持久 |
| Watchdog | 持久（异常自愈） |

## 四、双层架构：Router 管连续，Worker 管并发

### 根本权衡

- 所有事件交给同一个 Session：上下文最连续，但串行执行吞吐低，多任务细节混杂；
- 每个事件新开 Session：吞吐最高，但缺少全局上下文，结果割裂，多个 Session 各自回复用户也会混乱（来源1）。

### Router 层

- 常驻全局路由层，承接所有入口的人类交互，充当全局的序点、协调点和记忆（来源1）；
- **不直接执行具体任务**，只负责交互与分派，甚至可以不配备 Bash 工具（来源1）；
- 与常见 Agent Team 不同：Team Lead 要深入单个复杂任务的拆解；Router 只处理任务之间的高层关联（来源1）；
- DeepSeek 的实践是 Router 任务常常没有想象中复杂，较轻量的模型往往就能兼顾速度与效果（来源1）。

**批处理是单 Router 不成为瓶颈的关键**：上一轮推理期间到达的事件会积压到下一轮合并处理；Router 每步通常是长输入、短输出，合并后在 Prefill 阶段并行计算，单次耗时增长远慢于批大小（来源1）。

### Worker 层

- 彼此上下文隔离，挂载完整执行工具，专注单一任务，通常配置能力最强的模型（来源1）；
- 不直接与人类交互，向 Router 汇报，由 Router 统一回复（来源1）；
- Worker 之间一般不直接通信；共享同一个 PR 时，通过订阅同一 Thread 收到相同事件，自行发现冲突（来源1）；
- Worker 内部还可以再开 Subagent 或本身就是 Agent Team，对 Router 透明（来源1）。

原文的一句话值得记住：**Session 应当是系统的实现细节，而不应是用户的认知负担**；让用户手动管理 Session，很大程度上是从底层 LLM API 延续下来的设计惯性（来源1）。

## 五、事件驱动：从“等指令”到“听环境”

在 Super-agent 中，群聊消息、邮件与日程提醒、代码审查评论、CI 结果等环境事件被称为 Trigger（来源1）。

### 1. 两级过滤：Fast Path + Slow Path

真实事件流“高噪音、低触发率”，绝大多数消息不需要 Agent 介入（来源1）：

- **程序层（Fast Path）**：按来源、群组、用户或机器人白名单等确定性条件做准入，可设为“仅响应明确请求”“作为候选事件”或“直接忽略”；
- **语义层（Slow Path）**：候选事件交给 LLM，按提示词编写的策略判断是否行动，也是面向人的自然语言扩展点。

### 2. 订阅与直通

同一个 PR、IM 话题或邮件串下的连续事件构成一个 Thread（来源1）：

- **已订阅（Fast Path）**：后续事件由程序直接发给对应 Worker，不经 Router；
- **未订阅（Slow Path）**：Router 仍观测全部事件，只负责判断和分派新事件；
- 订阅是多对多关系：一个 Worker 可订阅多个 Thread，一个 Thread 也可被多个 Worker 订阅。

### 3. 上下文组织：Inline & Spill 与链式召回

原文把上下文窗口当作 Cache 管理，并说了一句很有力的话：**浪费上下文窗口，就是浪费模型的智能**（来源1）。

- **Inline**：把近期很可能用到的信息直接放进上下文，省去工具调用往返；
- **Spill**：超出预算或低频的信息留在窗口外，只保留引用或摘要；
- 做法：从当前对象的 ID 和摘要开始，按局部性逐步附上关联对象 ID 和时空相邻内容（如前 50 字、相邻消息），长内容截断并保留续读入口（来源1）。

把这一规则一致地用到 Trigger、Thread、Worker Session 等对象上，它们就构成一张引用图，模型可以顺着 ID 逐跳展开上下文，这就是**链式召回（Chain of Recall）**（来源1）。

### 4. 提前行动：Agent 版投机执行

借鉴投机执行，Agent 可在不确定结果是否会被采用时，用后台算力提前尝试：有价值就交付，没价值就丢弃（来源1）。

DeepSeek 在内部用户群配置了一条“静默复现并修复”策略：有人反馈问题时，Agent 先在后台复现并找修复方案，只有确认问题并找到简单修复方案后才交付，否则全程保持安静（来源1）。

## 六、面向人的交互

### 全双工：异步 ReAct Loop

- 经典 ReAct Loop 中，同步 `run()` 会阻塞，期间无法响应新输入（来源1）；
- DeepSeek 把耗时命令与子任务改为异步 `start()` / `stop()`：调用后立即返回“已启动”，完成后结果作为新事件投递回会话；模型也可主动 `stop()` 超时任务（来源1）；
- 该机制**已在 DeepSeek Harness 中实现，但尚未默认开启**（来源1）。

### 多信道：输出匹配信道带宽

- **IM**：低打扰，只在需要决策或验收时通知；一条验证过的硬性规定是**单次回复不超过 100 词**（来源1）；
- **GitHub、邮件、文档**：结构化、高信息密度的异步交付，例如按规范写 PR 背景、改动说明与验证结果（来源1）。

## 七、计算、状态与环境的分离

### 第一步：计算与状态分离

Agent Loop 的计算放进云端无状态弹性容器，Session 等状态存入数据库；容器可水平扩展、重启或替换，连续性由持久化存储保障（来源1）。

### 第二步：计算与执行环境分离

- 真实工作环境常含未提交修改、私有凭据、内网依赖和特定硬件，在云端重建成本高且易遗漏；要求用户全部迁往云端，迁移成本又过高（来源1）；
- 方案：Agent Loop 在云端，执行环境留在原地，端侧只部署一个**不保存会话状态的轻量 daemon**，负责执行命令和返回结果（来源1）；
- 原文指出这一思路与 Anthropic 提出的“脑手分离”一致；区别在于 DeepSeek 首先要接入的是用户日常使用、可能间歇在线的个人机器，因此支持 BYOM（Bring Your Own Machine）（来源1）；
- 设备重新上线后，云端 Agent 可自动触发并完成需要在该设备上执行的任务（来源1）。

## 八、Watchdog：监控“进展”，而不只是“存活”

- 持久在线系统需要主系统之外的独立外部控制回路（来源1）；
- Agent 的许多异常不是进程崩溃，而是**陷入无效循环或偏离目标**，所以既要监控基础设施，也要监控任务进展（来源1）；
- DeepSeek 用定时消息驱动一个独立的 Watchdog Session：处理接口报错、状态恢复失败等故障，并由模型判断各 Worker 是否有实质进展、方向是否偏离（来源1）；
- Watchdog 本身是有完整工具能力的 Agent Session，维护者可用自然语言询问故障原因，也可让它**在线修正主系统行为**，例如增删提示词、调整触发规则（来源1）。

## 九、初步实验：数据说了什么

原文强调：实验基于合成负载与简化环境，结果仅作初步参考（来源1）。

### 1. 消融实验

**设置（来源1）**：群聊与 GitHub CI 消息流同时驱动；单次约 300 条消息，其中约 20 条为工作请求；编码工作用只消耗时间的工具代替，衡量的是调度与协作能力；每种方案重复 5 次。

**四种方案（来源1）**：Super-agent；去掉直通的 Super-agent；单 Session + Subagent 工具（中性提示）；单 Session + Subagent 工具（提示优先委派）。

**结果（来源1）：**

| 指标 | 结果 |
|---|---|
| Super-agent 任务完成时间 | p50 12.4 分钟，p95 15.7 分钟 |
| 单 Session（中性提示） | 5 次运行中一次都没调用 Subagent，所有工作在主 Session 中被新消息不断打断，p95 达 29.5 分钟 |
| 单 Session（提示优先委派） | 5 次中有 4 次委派，完成时间缩短但整体仍慢于 Super-agent；剩下 1 次判断工作“很小”自己执行，形成长尾 |
| 去掉直通 | 完成时间与完整版基本一致，但 Router 需做的决定增加约 30%，总读缓存 token 从 2323 万增至 3177 万，增幅约 37% |
| Token 开销 | Super-agent 读缓存 token 高于单 Session，以更多 token 换取更短更稳定的完成时间 |

**原文结论**：相比依赖提示词工程和模型临场判断“分不分工”，双层架构在系统层面缓解了这一问题；直通机制不提高完成质量与速度，但为 Router 节省了可观的 token 与推理开销（来源1）。

### 2. Router 批处理压测

Router 调用真实模型、Worker 用 Mock 模型，Trigger 到达速率从约每分钟 1 条提升到约 40 条（来源1）：

| 指标 | 约 1 条/分钟 | 约 40 条/分钟 |
|---|---|---|
| 平均 batch 大小 | 1.0 | 2.8 |
| 单次请求耗时 | 2.5 秒 | 3.9 秒 |
| 单个决定分摊推理时间 | 6.4 秒 | 1.6 秒 |

原文据此认为，在目前团队规模下无需过早对 Router 做水平切分而牺牲全局上下文连续性（来源1）。

## 十、开源原型：一种“最少占用注意力”的工作方式

`dsh-superagent` 是面向单个 GitHub 仓库的主动编程 Agent，作为 DeepSeek Harness 的组合包发布，监听 GitHub 和可选的飞书；被授权的人请求工作时，它开工作项、在独立会话和目录中执行，并在原对话中回复，例如提交 PR（来源2）。

其设计哲学只有一句：**尽可能少占用人的注意力，尽可能多地提供价值**（来源2、来源3）。由此推出的行为规则（来源3）：

- 只在被请求或团队书面规则允许时行动；没人请求的工作需要团队写好的规则，并**先以只记录“本来会做什么”的模式启动**；
- 只在有人必须行动或能用上结果时发言；确认一次，工作时保持安静；
- 一次只问一个具体问题；
- 按影响而非工作量决定停在哪里：局部改动做到可评审，需要设计决策的改动停下来提问；
- 诚实报告：草稿标为未完成，失败报为失败，不绕过限制来避免提问。

领域模型中有几条对安全很关键的规则（来源4）：

- 只有 Eval 能创建 Ticket；**Mandate（授权）不可变**，扩大范围意味着新建 Ticket；
- 不同信源上的身份**永不相互映射**；
- Policy 变化不取消运行中的任务，而是记录并通知，避免留下半成品；
- 订阅只提供上下文，不提供权限：Executor 为获取上下文而跟随的 Thread 不会赋予其授权。

## 十一、深度分析（本文分析）

### 1. 它本质上是一份“Agent 操作系统”设计

原文自己说，并没有提出全新理论，而是把计算机系统的经典思想应用到 Agent 构建中（来源1）。对照一下：

| 计算机系统概念 | Super-agent 中的对应 |
|---|---|
| 中断与事件循环 | Trigger 驱动 |
| Fast Path / Slow Path | 程序过滤 + LLM 判断；订阅直通 + Router 分派 |
| 批处理 | Router 合并积压 Trigger |
| Cache 与局部性 | Inline & Spill |
| 指针与引用图 | 链式召回 |
| 投机执行 | 后台静默复现修复 |
| 异步 I/O | `start()` / `stop()` |
| 存算分离 | 无状态 Loop + 持久化 Session |
| 看门狗 | Watchdog Session |

这意味着 Agent 工程正在从“提示词技巧”走向“系统工程”，评价一个 Agent 产品，也应从“模型多强”扩展到“调度、状态、恢复和隔离做得怎样”。

### 2. 实验最有价值的发现：别指望模型自己决定分工

中性提示下模型 5 次一次都没委派，提示优先委派后仍有一次“自己干”造成长尾（来源1）。这说明：**把关键架构决策交给模型临场判断，会带来不稳定性**；用结构约束行为（Router 不能执行、Worker 只收订阅消息），比用提示词劝说更可靠。

### 3. 主动性是一把双刃剑

“无人 @ 时主动修复”很诱人，但每一次主动行为都消耗团队注意力，也可能越权。原型给出的答案相当克制：先影子模式记录，再逐步放开；短白名单起步；噪音大时收紧提示词或暂停（来源3）。这比原文中的演示更值得企业参考。

### 4. Watchdog 能改提示词，等于系统具备了自我修改能力

Watchdog 可在线增删提示词、调整触发规则（来源1）。这与本站此前解读的可信递归自我改进问题直接相关：一个能修改自身行为规则的系统，需要版本化、回滚、变更审计和独立评估，否则“修复”可能悄悄变成“漂移”。原文没有展开这部分治理机制。

### 5. 安全是这套架构的天花板

原文坦言（来源1）：

- 事件驱动扩大了接触不可信输入的面；
- 云端 Loop 一旦遭入侵或提示词注入，所有连接的端侧设备都有被控制的风险；
- 即便没被攻破，端侧凭据进入模型上下文也有泄露风险，需要让 Agent “不接触凭据本身却能使用凭据”。

本文判断：群聊里任何人的一句话都可能成为 Trigger，这让间接提示词注入从“可能”变成“日常”。在这个问题被工程化解决之前，Super-agent 适合在小而可信的团队里运行，这也与原文“只有在一个很小且可信的范围才能工作”的判断一致（来源1）。

### 6. 实验的局限

- 合成负载，编码工作被替换为耗时工具，未测任务质量（来源1）；
- 每种方案仅 5 次运行（来源1）；
- 没有公开对比开销与收益的成本模型，例如 token 增加对应多少人时节省（本文分析）；
- 消息间隔与工作时长按 1/4 缩放（来源1），真实节奏下的表现仍需验证。

## 十二、落地建议（本文分析）

1. **先做双层，再做主动**：先把交互与执行拆开，让 Router 不执行、Worker 不对外发言。
2. **能写成代码的过滤不要交给模型**：白名单、来源、群组等确定性规则放 Fast Path。
3. **以 Thread 为单位管理上下文**：PR、话题、邮件串天然就是任务边界。
4. **影子模式起步**：主动策略先只记录“本来会做什么”，人工复核后再开。
5. **授权与上下文分离**：看得到不等于能做；授权范围固定，扩权必须重新审批。
6. **凭据不进上下文**：通过代理或令牌服务代为调用。
7. **端侧 daemon 最小权限**：限定目录、命令与网络访问，云端被攻破时能止损。
8. **Watchdog 的修改要可回滚**：提示词与规则变更版本化，保留审计记录。
9. **按信道限制输出**：IM 简短、PR 结构化，把冗长推理留在 Worker 内部。
10. **用注意力而不是产出量衡量**：统计打扰次数、误报率和人工介入时长，而不是 PR 数量。

## 十三、结语

原文最后说，随着大模型执行单个任务越来越少需要人工干预，限制生产力进一步提升的瓶颈正在转向人的注意力（来源1）。

这句话点出了 Super-agent 的全部意义：它不是让 Agent 更聪明，而是让人少管 Session、少切窗口、少被打扰。真正的挑战，是在“更自主”与“更可信”之间找到边界：主动但不越权，持续在线但可被约束，能自我修复但每次修改都留下证据。

## 常见问题

Q: Super-agent 和普通多 Agent 系统有什么区别？

A: 原文指出，常见 Agent Team 主要用于单个复杂任务内部的拆解，Team Lead 承担很重的推理负载；Super-agent 的 Router 只处理任务之间的高层关联与分派，不介入单任务拆解，也不直接执行任务（来源1）。

Q: 为什么一个 Router 不会成为瓶颈？

A: 上一轮推理期间到达的事件会积压到下一轮合并处理。压测中，到达速率从约每分钟 1 条升到约 40 条时，平均 batch 从 1.0 升至 2.8，单次请求耗时只从 2.5 秒增至 3.9 秒，单个决定分摊推理时间从 6.4 秒降至 1.6 秒（来源1）。

Q: 这是 DeepSeek 的正式产品吗？

A: 不是。原文说明它是架构思路探讨；配套仓库声明为研究原型，并非官方产品，且与文章描述的实现不完全相同（来源1、来源2）。

Q: 最大的风险是什么？

A: 原文认为是安全与隐私：事件驱动增加接触不可信输入的风险，云端 Loop 被攻破可能波及所有端侧设备，端侧凭据进入上下文也可能泄露（来源1）。

## 事实来源

1. **DeepSeek Harness 团队原文**（来源1）：四个特征、五个模块、双层架构、事件过滤与路由、Inline & Spill、链式召回、投机执行、异步 ReAct Loop、多信道规范、存算分离、BYOM、Watchdog、实验设置与数据、开放问题、作者信息。
2. **dsh-superagent-prototype README**（来源2）：原型定位、功能描述、与文章实现的差异。
3. **000 Philosophy**（来源3）：注意力原则与行为规则。
4. **001 Domain model**（来源4）：Trigger、Thread、Eval、Mandate、Ticket、Subscription 等概念与规则。

**本文推论部分（非来源表述）**：计算机系统概念对照表、深度分析各条、实验局限中的成本模型判断、落地建议、结语观点。

**本文不构成任何投资、法律或技术选型建议。**

*（内容由AI生成，仅供参考）*