DeepSeek《Super-agent 设计探索》深度解读：当 Agent 不再绑定会话，瓶颈从模型转向人的注意力

核心判断（来源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）。

三、四个基础特征

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

四、双层架构：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）：

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

2. Router 批处理压测

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

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

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

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

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

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

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

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

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

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

这意味着 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、少切窗口、少被打扰。真正的挑战，是在“更自主”与“更可信”之间找到边界：主动但不越权，持续在线但可被约束，能自我修复但每次修改都留下证据。

事实来源

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生成，仅供参考）