从单会话
到 Super-agent

DeepSeek 的常驻 Agent 架构解读与思考

IM
PR
邮件
CI
群聊
日程
Router
Worker
Worker
Worker
← → 翻页 · F 全屏
问题

同时开五个会话,谁在帮你跟进?

做一件事
你
Agent
等模型想清楚
这一块,模型进步得很快
同时做五件事
Agent
Agent
Agent
Agent
Agent
你
等你看、等你点头
每件事都要恢复背景,再判断是否介入
DeepSeek Super-agent 设计文与开源原型试一下:会话越开越多
四个目标能力

希望它像一个持续工作的数字同事

Continuous
跨会话
仍能接着做

IM 改需求、GitHub 跟进,
仍能关联同一任务

Productive
多个任务
并行推进

几件事同时执行,
长任务进行时仍能接新请求

Proactive
感知变化
主动行动

监听外部事件,
在授权内判断是否介入

Persistent
状态持久
故障可恢复

持续运行、保存任务状态,
发生故障后尝试恢复

DeepSeek 设计文 §1 · 目标能力,后续页面展开实现与限制
模块 1 · 两层架构

会话怎么分,才能兼顾连续性和并行?

全塞进一个会话
一个会话
历史集中等工具时卡住几件事串味
每件事开一个 像开 5 个窗口
并行,快人来回切需另做协调
分两层
前台
连贯并行
DeepSeek Super-agent 设计文与开源原型
模块 1 · 两层架构

Router 保持交互连续,Worker 执行完整任务

你
IM · GitHub · 邮件
Router 层 · 常驻
Router
交互 · 派活 · 全局协调
Worker A
修 PR #42
Worker B
复现一个 bug
Worker C
回一封邮件
限制执行职责保留路由判断
一任务一会话全套工具按任务选模型不直接找你
DeepSeek Super-agent 设计文与开源原型完整结构图看一条消息怎么走
模块 2 · 事件处理链路

一条外部事件,怎样找到负责的 Worker?

先按规则准入,再依据订阅关系,走模型判断或代码直送。

不值得:不建任务
外部事件 · Trigger
PR / CI / 群消息
环境产生的新输入
Fast Path · 代码
规则准入
来源、群组、白名单
不符合准入规则:忽略
没有订阅者
Slow Path · 模型研判
Router 判断、派活
值不值得做、交给谁
值得处理
执行任务
Worker
订阅话题,接收后续事件
已有订阅:Pass-through 代码直送
省去 Router 再次判断和转发;Router 仍可掌握事件。

Worker 回报关键状态与结论,由 Router 协调并统一对外回复。

原文 §3.1–3.2 · 准入、路由与执行授权是不同职责;直送不改变权限
模块 2 · 事件驱动

PR 已有人接手,新评论还要前台转发吗?

话题 · PR #42
新评论:补个测试
Router
看得到,不用转
正在修 #42 的 Worker
订阅了这个话题
没订阅时:先绕前台判断一圈
代码查订阅表,直接送

话题 = 同一个 PR、同一串群聊回复、同一封邮件往来

DeepSeek Super-agent 设计文与开源原型动画对比:经前台 vs 直送
模块 2 · 事件驱动

一次事件进入时,系统如何组织上下文?

系统按规则准备输入;模型发现信息不足,再通过工具读取。

基础信息

ID、摘要、关联对象

提前内联 · Inline

邻近消息与关键背景

超长外置 · Spill

完整内容在外部,留读取引用

本次上下文
#T-812 · Safari 登录白屏
相关:PR #42 · Worker W-3
消息预览:Safari 登录没反应…
被回复消息 + 邻近讨论
完整历史的读取引用
外部存储
需要时读取
原文 §3.3 · 并列的上下文构建规则,不对应三轮模型推理 · 右图内容为示意
模块 2 · 事件驱动

换个渠道问旧任务,Router 怎么找回来?

先定位相关话题,再沿已建立的 ID 关系召回历史

定位IDID
当前消息 · IM 私聊
「上次那个登录问题
怎么样了?」
Thread · 群话题
#T-812
有人报了 Safari 白屏
Worker 会话
W-3
做过复现和修复
Thread · 代码评审
PR #42
评审意见都在这

引用关系让历史可追溯,但不会自动建立所有跨渠道关联。
“上次那个问题”有歧义时,仍需检索、确认或补充信息。

DeepSeek Super-agent 设计文与开源原型 · 示例内容为示意
模块 2 · 主动行动策略

主动行动:什么时候值得先在后台做准备?

是 否
群里
有人报了个 bug
策略允许的后台工作
复现、找修复
确认了?
修复简单?
带着修复出声
在授权范围内汇报、提 PR
暂不主动通知
没有可交付成果时,减少打扰

个人场景也一样:收到会议邀请 → 先查冲突、找背景、起草回复,你只要看一眼再发

原文 §3.4 · 投机执行:事件系统之上的主动行动策略
模块 3 · 全双工 · 多通道

Worker 跑十分钟测试,还能接新消息吗?

以前
run() 一直等
run(跑测试)……等结果
你:顺便改下文案
排队
→ 这时才能回你
现在
start() 马上返回
start()
测试在后台跑
你:顺便改下文案
下一推理步可回应
结果当成一条新消息回来
多个 Worker:任务间并行 · 异步工具:会话内不阻塞(原文 §4.1)
模块 3 · 全双工 · 多通道

结果该怎么说,才不会占满群聊?

群聊
登录那个问题有进展吗?
已修复,测试通过。
等你确认后合并。
每条 ≤ 100 词只在要你拍板时开口
GitHub · Pull Request
fix: Safari 登录页点击无响应
背景
改动
验证
写完整结构化、信息密度高
DeepSeek Super-agent 设计文与开源原型 · 示例内容为示意
模块 4 · 计算、状态、环境分开

电脑离线后,哪些工作还能继续?

场景:修复要用到 Mac 上未提交的代码,但这台 Mac 已经离线。

云端 · 计算

Agent Loop

继续接收消息、协调任务

持久化存储 · 状态

Session 数据库

保存会话与任务状态

读取 / 保存状态
执行环境
远程工具:下发命令,返回执行结果

本地 Mac

已离线

依赖本地代码的操作,等设备恢复连接。

BYOM:接入自己的机器,通过本地 daemon 执行

云端机器 / 沙箱

可用

具备所需代码与工具的其他任务,可以继续。

不会自动接替 Mac 上尚未同步的工作环境

Mac 离线时,本地操作暂停,云端仍可接消息、保存状态。

DeepSeek 设计文 §5 · 架构示意,假设云端服务与存储正常可用
模块 5 · Watchdog

Worker 跑了两小时,怎么知道有没有进展?

Worker A
修 PR #42
Worker B
写新功能
Worker C
排查 CI
● 进程在线
● 进程在线
● 进程在线
原地打转?
独立于主系统
Watchdog
定时醒来,巡一圈
查接口报错判断有没有进展问它:为什么挂了按授权调整规则
我们的建议:先问它在干嘛→给恢复建议→重启任务→高风险的找人
原文 §6 · 下方干预顺序为我们的建议
实验 · 直送开关对比

关掉 Pass-through,多花了什么?

同一套两层架构,只比较后续消息是否按订阅关系直接送给 Worker。

指标开启直送关闭直送
每次运行的缓存读取量23.2M token31.8M token 约 +37%
完成时间 · 中位数 p5012.4 分钟12.6 分钟
完成时间 · p9515.7 分钟15.5 分钟

为何时间接近?Router 批处理可吸收额外事件;这组负载尚未压满吞吐。

这组负载里,直送减少了额外读取和路由开销,未明显缩短完成时间。

原文 §7 · 合成负载,每方案 5 次;编码用耗时工具模拟 · 缓存读取量为所有会话合计,不等于总费用

三个 PR 出现架构冲突,谁来协调?

三个 Worker 各自完成任务,却对同一个模块采用了不同方案。

任务内可以解决

Worker 处理局部冲突,并报告影响。

需要深入分析几个 PR

Router 识别问题,交给专门的协调 Worker 分析依赖与方案。

涉及目标、授权或重大取舍

把证据和选项交给有权决定的人。

前台需要多强,取决于系统留给它多少判断工作。

我们的场景推演 · 原文 §2、§8.1 将紧耦合任务的协作列为开放问题

一个两分钟的改动,值得新开 Worker 吗?

同样的修改,两种执行路径(示意)

派给新会话
派单加载背景执行汇报转述
主会话顺手做
省下交接,但可能占住入口
执行
拆太细

固定交接开销可能超过执行时间

拆太粗

更依赖 Worker 的规划与进度反馈

我们的看法与疑问,不是原文结论 · 示意,不是实测动画对比

三种实践,各自在解决什么问题?

对照维度DeepSeek Super-agent设计文 · 部分能力见原型Hive公开仓库说明 · 本地工作台Grok bot既有实践 · 未做对照实验
组织方式Router 派发完整任务Orchestrator 规划与派单入口分工,执行者交接
协作载体Thread / Session 与订阅CLI 进程、任务图与报告消息、文件与角色约定
进展判断设计独立 Watchdog 巡检Worker 报告,人可介入既有定时观察与人工跟进
证据范围合成负载调度实验功能与机制说明小规模使用经验

接下来值得试:减少消息转述,能否降低人工跟进和返工?

设计、实现与使用经验分开看 · Hive README 核对于 2026-11-05 · 未进行三者同条件对比

我们的实践:Grok bot 与 Hive

一个负责持续跟进,另一个把开发、审查和成员状态放在同一工作台。

Grok bot:分工 + 定时晨报

Bot 团队成员列表与 Hive 项目增量晨报

Hive:开发 + 审查 + 状态可见

Hive v2.1.19 工作台,左侧为任务交接,右侧为开发和审查成员及运行状态
用户提供的实际使用截图 · 点击图片可放大 · 反映截图时的状态,不代表效果评测

Agent 多十倍,生产力就能增长十倍吗?

更多并发只是起点,还要让结果经过协调、验证和决策。

并行执行

AgentAgentAgentAgentAgentAgentAgentAgentAgent

独立任务可同时推进

协作与验收

任务依赖 等上游结果
冲突协调 对齐修改与上下文
结果验证 检查质量与返工
有效产出
完成且可用的结果
仍需关键决策与人的确认

并发能力增强后,瓶颈可能转移到协调、验证与人的注意力。

我们的分析框架 · 示意流程,非性能曲线或定量实验结论

谢谢.

欢迎一起讨论
原文:DeepSeek Harness · Exploring Super-agent Design(官方英文版,2026-11-01)
开源原型:deepseek-ai/dsh-superagent-prototype(MIT,研究用途)
DeepSeek Super-agent 设计文与开源原型