DeepSeek Harness 团队 10 月 31 日晚发表长文《Super-agent 设计探索：迈向更自主的 Agent 系统》，提出一套双层 Agent 架构，并在 GitHub 公开了原型 dsh-superagent-prototype。团队在文中写明，这个原型用来验证技术路线，不是 DeepSeek 的正式产品。
文章的出发点是一个很朴素的观察：模型单独完成一件任务需要的人工干预越来越少，卡住生产力的变成了人的注意力。按团队的说法，一个人通常只能同时跟进 3 到 5 个活跃 Session，任务一多就得手动来回切换、自己记上下文。
Session该是系统的实现细节，不该是用户的认知负担。
Router 管对话，Worker 管干活
架构分两层。常驻的 Router 层负责接收人的消息、维护全局上下文、分派任务，它不带 Bash 这类执行工具，可以用轻量模型驱动。Worker 层由多个上下文互相隔离的会话组成，挂载完整工具、用最强的模型，各自专注一件事，并发执行。Worker 不直接回复用户，状态和结果都先报给 Router，由 Router 统一对外说话。
另外几块设计围绕“让 Agent 一直在线”展开：
- 事件驱动：群聊消息、邮件、日程提醒、代码审查评论、CI 结果都算 Trigger，先用程序规则滤掉大部分噪音，剩下的才交给模型判断要不要动；已分配过的 Thread，后续事件由程序直接投递给对应 Worker，不再经过 Router。
- 异步 ReAct Loop：耗时的工具调用拆成 start() 和 stop()，后台任务启动后立刻返回 Started，前台继续接用户的话，结果作为新事件回到会话。
- 计算、状态与环境分离：Agent Loop 和状态放在云端，执行环境可以留在用户本机，只跑一个轻量 daemon，支持自带机器（BYOM）。
- Watchdog：一个独立会话定时醒来，除了看进程活没活着，还让模型判断每个 Worker 有没有实质进展、方向有没有跑偏。
文中还举了“投机执行”的例子：群里有人报了个 bug，Agent 先在后台尝试复现和修复，修好了才开口，没修好就不打扰人。
数字只来自合成负载
团队做了一组对比实验：每轮约 300 条消息，其中约 20 条是工作请求，其余是闲聊和噪音，每种方案重复 5 次。Super-agent 完成任务的耗时 p50 为 12.4 分钟、p95 为 15.7 分钟；对照组“单 Session 加 Subagent”在中性提示下 p95 为 29.5 分钟。去掉事件直通机制后，Router 的决策次数多出约 30%，缓存读取 token 多出约 37%。
Router 压力测试里，Trigger 从每分钟约 1 条加到约 40 条，平均批处理大小从 1.0 升到 2.8，单次请求耗时从 2.5 秒涨到 3.9 秒，摊到每个决定上的推理时间反而从 6.4 秒降到 1.6 秒。
限制也写得很直白：实验用的是合成负载和简化环境，只衡量调度与协作，不衡量单个任务做得好不好；Super-agent 的 token 开销高于单会话方案，但总量没有披露。开源原型目前只面向单个 GitHub 仓库，跨设备、云端常驻和 Watchdog 都没有完整实现。
从 dsh 到 Super-agent
把时间线串起来看，DeepSeek 在 Agent 这条线上是先放框架、再放调度思路。今年 8 月前后，它以 MIT 协议开源了 Agent 框架 DeepSeek Harness（命令行名 dsh），文件系统、Shell、模型适配、Web UI 和子代理都做成可替换插件；随后几个月，V4.1 Flash 等模型陆续上线，第三方编程工具也开始拿它当主力模型。
这次的长文往上走了一层，讨论的已经是“一个 Agent 实例怎样同时盯几十件事”。团队透露，文中的异步任务机制已经写进 DeepSeek Harness，只是默认没开；基于同一思路的内部实例一直在跑，用来复现和修复问题、响应代码审查，也用来迭代 Harness 本身。
团队列出的待解问题包括 Router 层如何随任务量扩展、跨月的长程记忆、多个 Agent 实例之间的通信。安全一项写得最具体：云端 Agent Loop 一旦被提示词注入，接入的本地设备可能被控制，放进模型上下文的凭据也可能在正常执行中泄露。这些风险怎么防，文中没有给出完整方案。
参考来源：DeepSeek Harness 团队技术长文与 dsh-superagent-prototype 仓库说明、IT之家、CocoLoop、凤凰网科技；实验耗时、压力测试数据以团队公布的合成负载结果为准。