DeepSeek 公布 Super-agent 架构：Router 调度，Worker 执行

DeepSeek Harness 团队发表技术文章《Super-agent 设计探索：迈向更自主的 Agent 系统》，公布了一套正在探索中的 Agent 架构。按照文章设想，未来的 Agent 不再被限制在单个聊天窗口里，而是能够长期在线、同时推进多项任务，并在外部环境发生变化时主动采取行动。

团队把瓶颈指向人而不是模型。目前大多数 Agent 仍以 Session 为基本工作单位，用户需要在不同窗口之间反复切换、记住各自的任务上下文；据他们观察，一个人通常只能同时跟进 3 到 5 个活跃会话。即使通过 CLI、MCP 等工具让 Agent 接入更多平台，也无法解决单会话串行执行、多任务上下文混乱，以及本地设备离线后任务中断的问题。

为此，DeepSeek 设计了 Router 与 Worker 的双层结构。Router 是持续运行的全局协调节点，统一接收来自群聊、GitHub、邮件等不同平台的信息，判断任务如何分配并维护跨任务上下文；Worker 各自拥有独立的上下文与工具能力，可以分别负责问题复现、代码审查、功能开发，必要时还能继续调用 Subagent。对于用户而言，面对的始终是同一个 AI 助手；对于系统而言，背后可能已经有多个独立 Agent 同时工作。为了减少协调开销，团队还引入订阅机制，某个 Worker 接手 GitHub Pull Request 后，后续评论和状态变化可以直接发给它。

主动性是这套架构里更值得关注的部分。群聊消息、邮件、日程提醒、GitHub 评论以及 CI 测试结果都可以成为触发 Agent 行动的 Trigger，团队设计了两级过滤：先用程序规则快速排除无关消息，再交给大模型结合上下文判断是否需要行动。更进一步，他们借鉴计算机系统的投机执行思想，在内部用户群配置了“静默复现并修复”策略——只有当问题确认存在、且找到相对简单的修复方法时，AI 才会把结果提交给开发人员，否则全程保持安静。文章展示了这样的场景：团队成员还在群聊里讨论解决方案，Super-agent 已经在后台提交了修复 Pull Request。

在响应方式上，DeepSeek 设计了异步 ReAct Loop，让耗时工具调用转入后台执行，前台会话继续接收新指令，用户还可以在执行过程中要求它改变方向或终止任务。该机制已在 DeepSeek Harness 中实现，但尚未默认开启。团队还借鉴存算分离思路，把 Agent 的执行循环放在云端、会话状态存入数据库，而代码仓库、文件和工具链等工作环境仍留在用户设备上，本地只需部署一个轻量级 daemon；设备暂时离线，相关任务也可以在重新上线后继续执行。此外还有独立的 Watchdog 机制，检查任务是否取得进展、是否陷入无效循环。

初步实验模拟了群聊与 GitHub CI 消息流，单次约 300 条消息，其中约 20 条是真正的工作请求，每种方案重复运行五次。结果显示，Super-agent 的任务完成时间 p50 为 12.4 分钟、p95 为 15.7 分钟；采用中性提示词的传统单 Session 方案 p95 达到 29.5 分钟，且五次实验中模型一次都没有调用 Subagent，所有任务都挤在主会话里受新消息干扰。

效率提升有代价。取消事件直通机制后，Router 需要做出的决定增加约 30%，总缓存读取量从 2323 万 Token 增加到 3177 万 Token，增幅约 37%。当事件到达速率从每分钟约 1 条升至 40 条时，Router 通过批处理提高吞吐量，单次请求耗时仅从 2.5 秒增加到 3.9 秒。团队也说明，实验使用合成消息和模拟耗时工具，主要验证任务调度与协作能力，并未直接评估真实编码质量。

目前 DeepSeek 已将部分设计实现为 dsh-superagent-prototype 原型插件，但这仍是面向工程实践的架构探索，尚非正式推出的独立产品。长期记忆、安全与隐私，以及用户如何查看进度、介入执行并决定哪些操作必须人工批准，都还没有答案。团队在文末坦言，他们并未提出全新理论，而是把任务调度、缓存管理、事件驱动、存算分离等经典系统思想应用到了 Agent 架构上；真正被重新定义的，是人一次能管理多少个 AI。