昨晚，DeepSeek Harness 团队公开了 Super-agent 的设计，也把部分实现整理成 dsh-superagent-prototype 开源了。
项目地址： https://github.com/deepseek-ai/dsh-superagent-prototype
这个项目瞄准的，是很多人用 Agent 时的另一种累：代码写得越来越快，自己却越来越忙。这个窗口等回复，那个窗口要验收，GitHub 上又多了两条评审意见。光是记住每件事做到哪一步，就得来回翻半天。
DeepSeek 想把这部分工作也交出去。你仍在熟悉的群聊和 GitHub 里提要求，背后由系统安排多个 Agent 接着做。
团队已经在内部持续使用这套系统，DeepSeek 给出的字体设置案例，很能说明它到底想解决什么。
用户先在群里要求把正文、代码、终端的字体分开设置，接着补了一句，字号也要分开。到了 GitHub，维护者嫌设置项太多，设计师又提出另一种展开方式。Agent 沿着同一个 PR 修改，合并后再回群里通知。
不用自己管一排窗口
DeepSeek 团队的观察是，一个人通常只能同时跟进 3 到 5 个活跃会话。再多，就容易顾此失彼。
把所有任务塞进一个会话也不省心。修 Bug 的细节、新功能的方案、长时间运行的测试混在一起，一件事还没完，另一件又把它打断了。
Super-agent 把工作分成两层：Router 负责接话和分派，Worker 负责执行。
Router承接交互与多个Worker并行执行
Router 留在前面，知道哪些事情正在做，新的要求应该交给谁。它不亲自跑去修代码，甚至可以不配 Bash 工具，避免一个耗时操作把所有交互堵住。
Worker 则带着完整工具，在各自隔离的上下文里推进任务。一个修白屏，另一个做字体设置，彼此不用背着对方的调试记录。
这和给一个大任务拉起 Agent Team 的侧重点不同。Team Lead 常常要拆步骤、盯细节；这里的 Router 主要管任务之间的关系，任务内部怎么做交给 Worker。复杂时，Worker 里面还可以再开子 Agent。
团队的经验是，Router 往往用较轻量的模型就够了，真正决定代码质量的 Worker 再配更强的模型。
后来的消息送到正在做事的地方
“切换会话会白屏”“控制台报空指针”“这里补一个测试”，可能出现在群聊和 PR 的不同位置，实际说的是同一项修复。
群聊与PR各自形成连续的讨论串
系统把一条消息称为 Trigger，把同一个话题或 PR 下的一串消息称为 Thread。Worker 接手后，会订阅相关 Thread。后续评审、CI 结果直接送到它那里，不必每次都请 Router 再转一遍。
同一个 Worker 可以订阅群聊和 PR 两条线。前面字体设置的案例，就是这样在不同地方接着改。新要求若已变成另一件事，再交回 Router 分派。
从群聊提需求到GitHub评审再到合并
历史越来越长，也不能把全部聊天硬塞进上下文。DeepSeek 的办法是：眼前可能用得上的消息、相邻讨论和关联编号先放进来，长内容留在外面，需要时续读。
找到一条消息，就能顺着编号找到讨论串，再找到负责它的 Worker，以及关联的另一个 PR。这套按引用逐步展开的办法，叫 Chain of Recall。
沿消息和任务之间的引用找回上下文
群里还在聊它已经开工
DeepSeek 还有一个更有意思的内部案例。
有人抱怨，macOS 桌面端的窗口没聚焦时，点一下会话容易被当成双击，误进重命名。没有人专门 @Agent，它已经在后台排查，并提交了修复 PR 和前后对比。
查到的原因很具体：Electron 吞掉了激活窗口的那次点击，下一次点击带着 detail=2，于是被识别成双击。
DeepSeek团队披露的内部主动修复案例
这背后有一条预先配置的策略：静默复现并修复。 群里出现问题反馈，先试着复现、找方案。确认问题并找到简单修复后再交结果，没找到就保持安静。
DeepSeek 借用了“投机执行”这个说法：多花一点后台算力，少让人等一轮、催一次。
当然，群里不只有 Bug。“中午吃什么”也来了，难道都要想一遍？
所以消息先过程序规则，按来源、群组和白名单筛选；留下的候选，再让模型结合上下文判断。下面这张图里，“新版界面挺清爽”不需要接活，“切换会话偶发白屏”才值得继续看。
先筛来源再判断是否需要介入
后台忙着前台还能说话
任务交出去以后，人往往还会改主意。
测试正在跑，你忽然想到“先别合并，移动端再确认一下”。传统同步工具调用要等测试结束，模型才重新处理输入，这句话就只能排着。
DeepSeek 的异步 ReAct Loop 把耗时操作改成 start()：先返回“已启动”，结果完成后再作为新事件送回来。后台继续跑，前台可以接新消息；必要时还能用 stop() 终止后台操作。
后台工具运行时对话仍能继续
新消息在当前推理步结束后处理，不必等后台工具结束。这套机制已经在 DeepSeek Harness 中实现，但尚未默认开启。
回复也跟着工作场景走。群里只交代需要你决定或验收的事，团队试过把单次回复限制在 100 词以内；PR 里则完整写问题背景、改动和验证结果。调试过程留在 Worker 内部，不往群里逐条刷日志。
电脑离线以后
要一直在线，光把 Agent 放进群聊还不够。
DeepSeek 将推进 Agent Loop 的计算放到云端，会话和任务状态存进数据库。计算容器可以重启或更换，历史不跟着消失。
DeepSeek给出的Super-agent整体架构
麻烦的是执行环境。真实开发机上有没提交的代码、内网服务、特定工具链，把它们全复制进云端沙箱，未必比直接干活省事。
因此，设计让环境留在原处，端侧只放一个负责执行命令、返回结果的轻量 daemon。云端 Agent 按任务需要，连接个人开发机、云端机器或临时环境。
计算与状态在云端执行环境留在原处
本地电脑离线时，云端仍能接收和安排工作；必须在那台电脑上执行的部分，等它重新上线再继续。
长期运行还有一种故障：进程活着，Agent 却一直在原地打转。外部的 Watchdog Session 会定时检查，不只看接口报错，还判断 Worker 有没有实际进展、方向是否跑偏，再介入处理。
更快是有代价的
这套架构到底帮上了多少忙，DeepSeek 做了一组初步实验。
每次约 300 条消息，其中约 20 条是工作请求，其余混着闲聊、跟进、叫停和 CI 通知。编码工作用一个只消耗时间的工具代替，测的是调度和协作。 四种方案各跑 5 次。
四种方案的累计完成曲线
Super-agent 的任务完成时间中位数是 12.4 分钟，P95 是 15.7 分钟。单 Session 虽然配了 Subagent 工具，在中性提示下，5 次运行却一次都没调用它，所有工作挤在主会话，P95 达到 29.5 分钟。
把提示词改成优先委派，5 次里有 4 次分了工；剩下那次，模型觉得工作“很小”，还是决定自己做。于是曲线上留下了一条长尾。
给模型一个分工工具，和让系统按分工运行，效果还真不一样。
完成时间与读缓存Token开销
Super-agent 单次实验的全部会话合计读取缓存 token 为 2323 万，高于两种单 Session 方案的 605 万和 1082 万。这里是在用更多 token 换时间和稳定性，并非又快又省。
再看直通机制：去掉它以后，完成时间基本没变，但 Router 要多做约 30% 的决定，读缓存 token 从 2323 万涨到 3177 万，增加约 37%。在这组负载下，直通主要省的是调度开销。
最后
Hugging Face 研究负责人 Leandro von Werra 在介绍这个项目时，也抓住了同一个目标：多个 Agent 并行处理 Issue 和 PR，尽量少占用人的注意力。
现在开源的原型围绕一个 GitHub 仓库运行，可选接入飞书，和内部版本并不完全相同。想试，可以先让你手头的 Agent 阅读仓库的 SETUP.md，协助完成配置。
参考链接
-
DeepSeek Harness团队 Super-agent设计探索：https://mp.weixin.qq.com/s/zoS7GlReWPhfCjENGxXCdg -
DeepSeek Super-agent公开原型与文档：https://github.com/deepseek-ai/dsh-superagent-prototype