DeepSeek Harness团队10月31日发表技术文章《Super-agent设计探索：迈向更自主的Agent系统》，介绍一种由一个Router（路由层）和多个Worker（执行层）组成的Agent架构。Router持续运行，统一接收群聊、GitHub、邮件等平台的信息并分派任务；Worker在相互隔离的会话里并行执行，做完后把结果汇报给Router，由Router统一和用户沟通。DeepSeek说，文章附带的dsh-superagent-prototype原型插件用于验证技术路线，不是DeepSeek的正式产品。
受影响的首先是DeepSeek自己的研发人员：团队说，用这套思路搭建的内部Super-agent已经在持续运行，参与问题复现和修复、代码审查响应等工作。文章也说，云端Agent接入本地设备以后，提示词注入、端侧凭据泄露和跨设备权限风险都还需要进一步解决。
DeepSeek团队说，根据团队的观察，一个人通常只能同时跟进3到5个活跃会话；现有的主流Agent以单个会话为基本单位，用户并行推进几项工作时，要手动切换并维护各个会话的上下文。团队给这种Agent定了四项特征：连续、高效、主动和持久。
群聊消息、邮件和日程提醒、代码审查评论、CI运行结果等外部信息都被当作触发事件，系统先用程序规则过滤，再交给大模型判断要不要行动。系统还会在后台提前做事：在群聊讨论问题时先尝试复现故障、寻找修复方案，只有确认问题并找到简单的修复方式后，才把结果交给用户。计算和持久化的会话状态放在云端，执行环境可以留在用户本地的设备上，只需部署一个负责执行命令、返回结果的轻量程序；另有一个独立的Watchdog会话，用模型判断Worker有没有取得实质进展、方向有没有偏离目标。
团队做了初步实验：每次约300条消息，其中约20条是工作请求，每种方案重复5次。Super-agent完成任务时间的中位数（p50）为12.4分钟，95%分位数（p95）为15.7分钟；中性提示下的单会话方案，p95为29.5分钟。团队也说，这些实验用的是合成负载和简化环境，主要评估调度和协作能力，不衡量单个任务的实际执行能力。Super-agent要维护多个独立会话，缓存读取的Token比单会话方案多；去掉事件直通机制以后，总缓存读取量从2323万增加到3177万Token，增幅约37%。
| 方案 | 中位数（p50） | 95%分位数（p95） |
|---|---|---|
| Super-agent | 12.4分钟 | 15.7分钟 |
| 单会话方案（中性提示） | — | 29.5分钟 |
数据：DeepSeek Harness团队10月31日的文章，据媒体报道
DeepSeek团队在文章最后说，团队没有提出全新的理论，而是把任务调度、缓存管理、事件驱动、存算分离等计算机系统里的经典思路用到了Agent架构上。
