DeepSeek想让Agent常驻上班：Router管全局，Worker并行干活

DeepSeek在10月31日公布了一套名为Super-agent的智能体架构：上层Router统一接收消息、维护全局上下文和分派任务，下层多个Worker在隔离会话中并发执行工作，再由Router统一向人类汇报结果。

这不是DeepSeek发布的新模型，也不是一个已经成熟的商业产品，而是DeepSeek Harness团队对下一代Agent系统形态的工程探索。团队已经公开研究原型dsh-superagent-prototype，但明确提醒：公开代码与内部运行版本并不完全一致，部分设计仍停留在未来方向，不能直接按生产级系统看待。(ithome.com)

Super-agent是一个持续在线、能够同时管理多个任务，并根据外部事件主动采取行动的智能体系统。 DeepSeek给它归纳了四个核心特征：连续、高效、主动和持久。

这四个词听上去并不新，但组合起来意味着Agent的产品逻辑发生了变化：过去是“人打开一个对话框，让AI完成一件事”，Super-agent想实现的则是“人确定目标和边界，AI长期观察环境并持续推进多件事”。

人类注意力正在成为Agent的新瓶颈

DeepSeek认为，当前Agent的主要限制正在从“模型能不能完成任务”，转向“人能不能同时管理足够多的AI任务”。

现有Claude Code、Codex CLI以及多数本地Agent工具，基本都以Session，也就是会话，作为工作边界。每个会话有自己的历史消息、工具调用和执行状态，不同会话之间通常不知道对方正在做什么。

Session是一次相对独立的Agent工作上下文。 它适合处理“修复这个Bug”“分析这份表格”或“重构这个模块”等单项任务，但当用户同时运行十几个Session时，问题就从模型推理转移到了人工调度。

DeepSeek团队观察到，一个人通常只能稳定跟进3至5个活跃Session。超过这个数量后，用户需要不断检查哪个任务卡住、哪个任务需要补充信息、哪个任务已经完成，以及不同会话是否修改了同一批文件。(ithome.com)

这也是当前“多开几个Agent窗口”并没有带来线性生产力提升的原因。模型可以并行，人类的注意力却不能；Agent数量越多，任务切换、状态确认和结果验收的成本越高。

Super-agent试图解决的核心问题，并不是让单个Worker变得更聪明，而是让系统替人承担任务分配、上下文维护、进度追踪和异常恢复。

Router负责沟通，Worker负责干活

Router是Super-agent中的全局协调层，负责理解事件、维护跨任务状态、选择Worker并统一与用户交互。 它不需要亲自完成每一项工作，更像一名项目经理或操作系统的调度器。

Worker是Super-agent中的隔离执行单元，负责在独立Session和工作环境中完成具体任务。 一个Worker可以复现故障，另一个Worker可以检查Pull Request，第三个Worker则可以整理会议资料，它们不共享混乱的短期上下文，也不直接争抢对话窗口。

Worker完成阶段性工作后，不直接向用户发送消息，而是把状态和结果汇报给Router。Router判断信息是否值得打扰用户，并决定是继续执行、要求补充信息，还是输出最终结果。

| 架构 | 上下文组织 | 多任务能力 | 用户交互方式 | 主要问题 | |---|---|---:|---|---| | 单Session Agent | 所有信息进入一个会话 | 较弱，任务通常串行 | 用户直接与执行Agent沟通 | 长任务阻塞、上下文容易膨胀 | | 单Session + Subagent | 主会话临时调用子Agent | 中等 | 主会话仍承担协调和回复 | 主会话可能成为吞吐瓶颈 | | Router + Worker | 全局路由与执行上下文分离 | 较强，可并发运行多个Worker | Router统一对外沟通 | 调度、权限和长期状态更复杂 |

Router与Worker的分工并不是一个全新的多智能体理论。Manager-Agent、Planner-Executor和Orchestrator-Worker等设计早已存在，真正值得关注的是DeepSeek把事件流、异步工具、持久状态和故障恢复一起放进了架构，而不是只让几个Agent在同一个Prompt里互相讨论。

换句话说，Super-agent更接近一个Agent操作系统，而不是一个“AI开会”的演示项目。

事件不再只是消息，而是可调度的任务信号

Trigger是可能引发Agent行动的外部事件。 群聊消息、邮件、日程提醒、GitHub评论、代码提交和CI测试结果都可以成为Trigger。

Super-agent不会把所有事件原封不动地交给大模型，因为公共群聊每天可能产生数千条消息，其中绝大多数与Agent无关。DeepSeek采用了两级过滤：程序规则先排除明显不相关的事件，再由模型结合语义和历史上下文判断是否需要采取行动。

这种设计比“所有消息都调用一次大模型”更现实。规则层便宜、速度快，模型层则负责处理模糊意图；前者像垃圾邮件过滤器，后者像真正理解项目背景的助理。

Thread是一组围绕同一对象持续发生的相关Trigger。 一个GitHub Pull Request下的评论、代码更新和CI结果可以组成一条Thread，群聊中围绕同一个故障的连续讨论也可以组成一条Thread。

当某个Worker已经接手一条Thread后，后续事件可以直接送达该Worker，而不必每次重新经过Router判断。这一机制减少了全局路由层的压力，也避免了Router反复阅读完整任务历史。

在Router压力测试中，当Trigger到达速率从每分钟约1条提高到约40条时，平均批处理大小从1.0增加到2.8，单次模型请求耗时从2.5秒增加到3.9秒，但每个路由决定分摊的推理时间从6.4秒下降至1.6秒，降幅达到75%。(ithome.com)

这个结果说明，Router可以把短时间内积压的事件合并判断，而不是机械地一条消息调用一次模型。不过，这只是合成环境下的吞吐实验，不能证明Router在真实企业消息流中也能维持同样的判断准确率。

主动性来自“投机执行”，但不能无限主动

投机执行是系统在尚未确定结果是否会被使用时，提前利用后台算力开展工作的机制。 这个概念类似CPU的分支预测：先做可能有用的计算，预测正确就节省时间，预测错误则丢弃结果。

例如，Agent收到会议邀请后，可以提前检查时间冲突、整理参会者背景并生成回复草稿；当研发群里有人讨论Bug时，Agent可以在无人点名的情况下尝试复现问题、定位原因和寻找修复方案。

DeepSeek展示的理想场景是：团队成员还在群聊里讨论问题，Super-agent已经在后台完成复现，并提交了一个修复Pull Request。只有当问题被确认、修复相对简单且结果有价值时，系统才通知人类；如果没有发现有效结果，它可以保持沉默。

这可能是Super-agent最有产品价值、也最危险的能力。主动Agent如果判断准确，可以减少等待和指令编写；如果判断不准，则会制造大量无用分支、重复任务、噪声通知和算力消耗。

DeepSeek公开原型的设计原则也强调，Agent发送的每条消息都会消耗团队成员的注意力，因此它应该只在规则允许、用户确实需要行动或结果确实有价值时开口。(github.com)

主动性不是“什么都做”，而是在明确权限、成本和通知策略下，尽量提前完成高概率有价值的工作。对于企业Agent而言，克制可能比积极更重要。

异步ReAct让长任务不再锁死对话

异步ReAct Loop是一种把耗时工具调用转为后台任务的Agent执行循环。 传统ReAct通常按照“思考—调用工具—等待结果—继续思考”的顺序运行，只要工具没有返回，整个会话就可能处于阻塞状态。

DeepSeek提出把耗时工具设计为异步的start()和stop()操作。Agent启动任务后可以立即获得Started状态，前台会话继续处理新消息；后台任务完成后，其结果再作为新事件进入会话。

这个改变看似只是工程优化，实际上决定了Agent能不能长期在线。如果一个代码构建需要20分钟、一次数据分析需要1小时，Agent不应该在这段时间里拒绝其他请求。

DeepSeek表示，异步任务机制已经在DeepSeek Harness中实现，但截至2026年10月31日尚未默认启用。(ithome.com)

异步执行也会带来新的状态管理问题：用户可能在任务运行期间改变目标，代码仓库可能已经更新，多个Worker也可能同时修改同一依赖。系统必须具备取消、暂停、重试、幂等和冲突检测机制，否则“后台运行”很容易变成“后台失控”。

长期记忆不等于把所有内容塞进上下文

Inline & Spill是一种将高频信息放入上下文、将低频信息保留在外部存储的记忆管理机制。 近期任务状态和关键约束可以Inline，也就是直接进入模型窗口；体积较大或暂时无关的信息则Spill到窗口外，等需要时再读取。

Chain of Recall是一种沿对象引用关系逐步找回历史信息的检索方式。 Router不必一次性搜索所有历史记录，而是可以从当前Trigger找到对应Thread，再从Thread定位Worker Session、任务记录和相关文件。

这比单纯向量检索更符合工程任务的结构。代码协作中的上下文通常具有明确关系：评论属于某个Pull Request，Pull Request对应某个分支，分支又关联某个故障或需求。沿关系链检索，往往比在数百万条消息里寻找语义相似片段更可靠。

但跨月甚至跨年的长期记忆仍然没有被解决。历史信息可能过期，规则可能改变，同一个项目名也可能对应完全不同的阶段；如果Agent把旧决策当成当前约束，它会非常自信地执行错误任务。

长期记忆的难点不是“存下来”，而是判断哪些信息仍然有效、哪些已经失效，以及发生冲突时应该相信哪一个版本。

云端大脑连接本地机器，便利与风险同时放大

BYOM是Bring Your Own Machine的缩写，指用户把自己的开发机或个人电脑接入云端Agent系统。 DeepSeek设想把Agent Loop和持久化状态放在云端，本地设备只运行轻量daemon，负责执行命令并返回结果。

这种存算与执行环境分离的架构，可以让Agent在用户电脑离线时继续维护任务状态，设备重新上线后再恢复本地操作。系统也可以连接云端托管机器，或者按需创建新的执行环境。

公开原型的部署文档显示，Worker可以以操作系统用户身份执行程序并读取用户主目录，文档建议使用只保存Agent凭据的独立操作系统账户进行隔离。(github.com)

这条提醒非常关键。一个持续接收群聊、邮件和GitHub内容，同时又拥有本地代码及凭据访问权的Agent，天然是提示词注入攻击的高价值目标。

攻击者不一定需要直接攻破模型服务，只需要在Issue、Pull Request、文档或网页中埋入恶意指令，就可能诱导Worker读取敏感文件、修改代码或泄露凭据。Router与Worker分层能够隔离上下文，但不能自动解决授权问题。

真正进入生产环境之前，Super-agent至少需要细粒度权限、工具白名单、网络访问控制、密钥隔离、人工审批、操作审计和可回滚执行环境。Watchdog能发现异常循环，却不能代替安全边界。

Watchdog是AI监督员，但不能证明结果正确

Watchdog是独立于Router和Worker的外部监控会话。 它不仅检查接口错误、进程退出和状态恢复失败，还可以借助模型判断Worker是否取得实质进展、是否偏离目标或陷入重复循环。

这一设计比让Worker“自己检查自己”更可靠，因为执行者通常会继承自己的错误假设。独立Watchdog拥有不同上下文，可以从外部评估任务状态，并尝试重启、重新分配或要求人工介入。

不过，模型监督模型并不会自动得到可靠结论。两个模型可能共享相同盲点，Watchdog也可能把正常的长时间探索误判为卡死，或者把生成了大量文件误判为取得进展。

Watchdog适合做运行状态监控，却不应被当成最终质量保证。代码是否正确仍需测试、安全扫描和人工Review；数据分析是否可信仍需来源校验和结果复核。

初步实验显示调度更快，但远非通用跑分

DeepSeek使用合成消息流测试了Super-agent的调度能力，每次实验约包含300条消息，其中约20条是真正的工作请求，每种方案重复运行5次。

Super-agent的任务完成时间p50为12.4分钟，p95为15.7分钟；采用中性提示词的单Session加Subagent方案，p95达到29.5分钟。按p95计算，Super-agent将长尾完成时间缩短了13.8分钟，降幅约46.8%。(ithome.com)

| 测试指标 | Super-agent | 单Session方案 | 差异 | |---|---:|---:|---:| | 单次消息数量 | 约300条 | 约300条 | 相同合成负载 | | 工作请求数量 | 约20条 | 约20条 | 相同任务密度 | | 任务完成时间p50 | 12.4分钟 | 未公布完整可比数字 | — | | 任务完成时间p95 | 15.7分钟 | 29.5分钟 | 缩短约46.8% | | 每种方案运行次数 | 5次 | 5次 | 样本规模有限 |

这些数字证明的是并发调度和事件分发可以减少排队时间，不是Worker写代码、查资料或做决策的能力提高了46.8%。DeepSeek也明确表示，实验主要评估系统调度与协作能力，不衡量单个任务的实际执行质量。

因此，不能把15.7分钟理解成Super-agent解决复杂开发任务的固定耗时，也不能据此判断它优于所有现有Agent产品。真实生产环境还有任务难度、模型限流、仓库规模、工具稳定性和人工审批等变量。

DeepSeek真正押注的是Agent基础设施

Super-agent最值得关注的地方，不是Router指挥Worker这一张架构图，而是DeepSeek正在把竞争范围从基础模型扩展到Agent运行时。

DeepSeek Harness本身强调插件化，模型、工具、会话、执行循环和界面都可以作为组件组合；Super-agent则进一步加入事件路由、任务持久化、主动触发和多Worker调度。公开原型目前主要面向单个GitHub仓库，可以监听GitHub以及可选的飞书消息，并在独立Session和目录中执行任务、提交Pull Request。(deepseek.com)

这条路线与单纯提升模型跑分不同。模型能力可以通过调用更强模型快速获得，但稳定的Agent系统需要积累大量任务状态、权限策略、失败案例、工具适配和人机交互经验。

DeepSeek也没有把Super-agent包装成已经解决一切的“数字员工”。公开仓库只有一个研究原型，官方明确称其不是正式产品，代码可能存在Bug，工程实践也可能不一致。

这一克制反而是合理的。当前行业里最不缺的是能在演示中自动写代码的Agent，真正稀缺的是能连续运行数周、不越权、不丢任务、不反复打扰用户，并能在失败后恢复的系统。

Super-agent方向正确，但离常驻同事还有距离

DeepSeek对问题的判断基本成立：当单个Agent完成任务的能力越来越强，人类管理多个Agent的注意力成本会成为新瓶颈。

Router与Worker分层、事件驱动、异步ReAct、外部记忆和Watchdog，也都是构建长期运行Agent的必要组件。它们未必构成算法创新，却把经典分布式系统思想放到了Agent工程中，这比单纯增加Agent数量更有现实价值。

不过，Super-agent现阶段最大的风险同样来自“常驻”。临时运行10分钟的Agent犯错，用户通常可以立即停止；拥有跨平台消息入口、本地执行权限和长期记忆的Agent犯错，影响可能扩散到代码仓库、团队沟通和生产环境。

Super-agent最终能否成立，不取决于Router一次能处理多少Trigger，而取决于系统能否回答三个问题：它为什么决定行动、它具体做了什么、用户如何安全地撤销。

DeepSeek这次提出的是一张值得关注的工程蓝图，而不是已经可以直接接管团队工作的成品。对开发者而言，当前最适合的态度不是立刻把它接入所有仓库，而是研究其事件模型、隔离方式和权限边界，在低风险项目中验证持续运行的可靠性。

如果说过去两年的Agent竞争是在比较“谁更会干活”，Super-agent代表的下一阶段，很可能是在比较“谁更会管理一群会干活的Agent”。

参考来源

• IT之家：DeepSeek提出Super-agent架构设计 —— 汇总DeepSeek Harness团队公布的架构组成、实验数据及目前仍待解决的问题。
• GitHub：dsh-superagent-prototype —— DeepSeek公开的Super-agent研究原型，包含项目定位、部署说明、权限模型与架构文档。
• GitHub：DeepSeek Harness —— DeepSeek开源Agent Harness底座，用于了解其插件、Session与Agent运行时设计。