DeepSeek 的 Super-agent 不是新产品，是一张“让 agent 自己排班”的施工图

10 月 31 日，DeepSeek Harness 团队发布了技术文章《Super-agent 设计探索：迈向更自主的 Agent 系统》，同时开源了 dsh-superagent-prototype。先把性质钉死，这一点比所有技术细节都重要：团队自己在 README 第一行就写明，它是“仅供参考的研究原型，不是官方 DeepSeek 产品”，文章里的一部分设计在公开代码里还没实现，生产可用性不在承诺范围内。把它当成已上线的产品来部署，会踩坑。这张施工图的核心是两层结构：一个常驻的 Router 只负责和人对话、判断什么活可以接、派发工单；一群平行的 Worker 各自在独立会话与独立目录里干活，互不干扰。Router 跑轻量模型、工具集被刻意收小，shell 与任务等待被限制在几秒内，它永远不亲自写代码；Worker 拿到完整工具集，前台 shell 命令超过 5 秒就转后台，保证人随时能打断。状态放在同一个 SQLite 数据库里，Outbox 把回复路由回原来的对话渠道。主动干活默认从观察模式开始，除非团队写好的规则明确允许，否则不自动动手。文章还提了另外几块拼图：事件驱动的任务调度、异步多通道交互、计算与持久状态与执行环境分离、一个独立的 Watchdog 会话负责监控进度与故障修复。数字同样要分口径：DeepSeek 自己的仿真负载（约 300 条消息、约 20 个工作请求，每种方案重复 5 次）报出，Router-Worker 设计的任务完成 p50 为 12.4 分钟、p95 为 15.7 分钟，而单会话基线的 p95 是 29.5 分钟；另一份整理指出，它比单会话多用了缓存读取 token（23.23M 对 6.05M 或 10.82M）。这组数字是厂商自己的仿真，不是独立复测，换来的速度是用更多缓存 token 买的。原型本身的落地形态也很具体：一个面向单个 GitHub 仓库的主动编码 agent，打包成 DeepSeek Harness 的 bundle，监听 GitHub，可加 Feishu，授权人一提需求就开工单、在自己的会话与目录里干活、最后回到原对话交结果，比如提一个 pull request。11 月 2 日 GitHub 趋势盘点里它仍以单日数千星在涨，说明 builders 在拿它当参考架构读，而不是当产品装。我的判断：这篇对两类人有用。第一类是已经在用多 agent 协作的小团队：Router 与 Worker 的分工、以及“查的人不是干活的人、派活的人不亲自干活”这条边界，可以直接抄进你自己的 agent 编排规范里，哪怕你不用 DeepSeek Harness。第二类是正在被“一个会话越跑越慢、一个任务卡住全队停摆”折腾的人：问题往往不在模型，而在单会话什么都往里塞，拆成 Router 常驻监听、Worker 隔离执行，卡住的只是某一个工单，不是整个系统。别急着照搬 Watchdog 那部分——公开原型里它更多是设计方向，先把 Router 收权、Worker 隔离、工单可重跑这三件做实。什么情况下这篇结论不成立：你只想找一个开箱即用的编码产品，那“研究原型、非生产就绪、未过安全审计”三条就直接把它排除；或者你的团队只有一个仓库、一天只有几个需求，那 Router-Worker 的编排全是 overhead，单会话加好一点的任务清单更划算；又或者你把仿真里的 p95 提升当成生产承诺——那组数字没有独立复测，也没算你多付的缓存 token。