DeepSeek 提出 Super-agent 架构设计：Router 与 Worker 双层架构，探索更自主的 Agent 系统

IT之家 10 月 31 日消息，DeepSeek Harness 官方团队今日发布《Super-agent 设计探索：迈向更自主的 Agent 系统》一文，介绍了其面向工程实践的 Super-agent 架构设计思路。

随着大模型执行单个任务时越来越不需要人的干预，限制生产力进一步提升的因素正逐渐转向人的注意力，Agent 系统需要从被动响应指令的单任务工具，向持续在线、能够并行处理多项任务的自主协作者演进。

DeepSeek 表示，现有主流 Agent 设计仍以单一 Session（会话）为基本单位，不同 Session 之间相互独立。用户并行推进多项工作时，需要手动切换并维护各个 Session 的上下文。

根据 DeepSeek 团队观察，一个人通常只能同时跟进 3 至 5 个活跃 Session。即使通过 CLI、MCP 或外部连接器扩展本地 Agent，也仍可能面临单会话同步阻塞、多任务上下文混乱，以及本地设备离线后任务停止等问题。

他们将这种新型 Agent 形态及其系统架构称为 Super-agent，并归纳出四项基础特征：连续、高效、主动和持久。

首先，连续意味着用户可以在即时通讯、GitHub 评论等不同渠道与同一个 Agent 交互；高效意味着能够并行处理多个复杂任务；主动意味着系统可以持续观察环境事件并自行推进值得处理的事项；持久则要求 Agent 始终在线，并能在长期运行中从异常状态恢复。

DeepSeek 提出的整体架构主要由双层架构、事件驱动、面向人的交互、计算与状态及环境分离、Watchdog 五部分组成。

其中，双层架构将系统划分为 Router 层和 Worker 层：Router 负责承接人类交互、维护全局上下文并分派任务，Worker 则在相互隔离的会话中并发执行具体工作。Worker 不直接向用户回复，而是将状态和结果汇报给 Router，由后者统一对外沟通。

在事件驱动机制中，群聊消息、邮件与日程提醒、代码审查评论、CI 运行结果等外部信息被称为 Trigger。系统先通过程序规则过滤事件，再交由大模型判断是否需要采取行动。对于已经分配任务的事件流，Worker 可以订阅对应 Thread，后续相关事件由程序直接发送给 Worker，无需每次都经过 Router，从而降低路由负载。

DeepSeek 团队还介绍了 Inline & Spill 和链式召回（Chain of Recall）机制。前者将近期可能用到的信息直接放入模型上下文窗口，将超出预算或低频使用的内容保留在窗口之外，供模型按需读取；后者则通过 Trigger、Thread 和 Worker Session 等对象之间的引用关系，让模型沿关联 ID 逐步找回历史任务信息。

为减少人类等待时间，Super-agent 还引入投机执行机制，可以根据环境信号在后台提前开展工作。例如，收到会议邀约后先检查日程冲突、搜集背景资料并准备回复草稿；在研发协作场景中，则可以在群聊讨论问题时尝试复现故障、寻找修复方案，只有确认问题并找到简单修复方式后才向用户交付结果。

在人机交互方面，文章提出异步 ReAct Loop，将耗时工具调用改为异步的 start () 和 stop ()。Agent 启动后台任务后即可返回 Started 状态，不必等待任务完成，后台结果随后作为新事件进入会话。

这样，前台对话可以继续接收用户的新消息。不过，DS 团队特别说明，这项异步任务机制已经在 DeepSeek Harness 中实现，但尚未默认开启。

针对长期在线运行，DeepSeek 将 Agent Loop 的计算、会话状态和执行环境进行解耦：计算与持久化状态放在云端，执行环境则可以保留在用户本地设备，仅部署负责执行命令和返回结果的轻量 daemon。该设计支持 BYOM（Bring Your Own Machine），即将用户日常使用的开发机或个人电脑接入云端 Agent，也支持连接云端托管机器或按需创建的计算环境。

此外，系统在主架构之外设置独立的 Watchdog Session，形成外部控制回路。Watchdog 不仅监控接口报错、状态恢复失败等基础设施问题，还会通过模型判断 Worker 是否取得实质进展、执行方向是否偏离目标，并在发现异常时介入修复。

DeepSeek 团队还进行了初步实验，对比 Super-agent、去掉事件直通机制的 Super-agent，以及两种提示词配置下的单 Session 加 Subagent 方案。

实验每次包含约 300 条消息，其中约 20 条为工作请求，每种方案重复运行 5 次。结果显示，Super-agent 的任务完成时间 p50 和 p95 分别为 12.4 分钟和 15.7 分钟；中性提示下的单 Session 方案 p95 为 29.5 分钟。

DeepSeek 团队指出，这些实验基于合成负载和简化环境，主要评估系统调度与协作能力，并不衡量单个任务的实际执行能力。

在 Router 层压力测试中，Trigger 到达速率从每分钟约 1 条提升至约 40 条时，平均批处理大小从 1.0 增至 2.8，单次请求耗时从 2.5 秒增至 3.9 秒，而单个决定分摊的推理时间从 6.4 秒降至 1.6 秒。团队据此认为，事件突发时，Router 可以通过合并积压事件提高有效吞吐。

文章同时指出，这套架构仍存在待解决的问题，包括 Router 层如何随任务规模扩展、跨月乃至更长时间跨度的长程记忆、脱离 Session 后的人机协作方式、不同 Agent 实例之间的 A2A 通信，以及安全与隐私保护。尤其是云端 Agent 接入本地设备后，提示词注入、端侧凭据泄露和跨设备权限风险都需要进一步解决。

DeepSeek 团队表示，基于上述思路和 DeepSeek Harness 构建的内部 Super-agent 实例已经持续运行，参与问题复现与修复、代码审查响应以及 DeepSeek Harness 自身迭代。

此外，他们在文章中还提供了名为 dsh-superagent-prototype 的原型实现，但明确指出，该插件用于验证技术路线，并非 DeepSeek 正式产品。

参考资料：

• dsh-superagent 的 GitHub 仓库：https://github.com/deepseek-ai/dsh-superagent-prototype