10 月 31 日，DeepSeek Harness 团队发了一篇《Exploring Super-agent Design》，同一天在 GitHub 上开源了配套的 dsh-superagent-prototype，MIT 协议。它想解决的不是"模型不够聪明"，而是另一个更现实的卡点：一个 Agent 再能干，人也就只能同时盯三五个会话。

README 第一句就把定位说清楚了——研究原型，不是 DeepSeek 官方产品，代码是团队日常开发里长出来的，相当一部分还是 coding agent 自己写的。

这套设计在解决什么问题

文章开头给了一个很朴素的观察：一个人能同时跟的活跃会话大概是 3 到 5 个。单任务的上限是模型，多任务的上限是人的注意力。所以这套方案里，重点不在模型，在调度。

官方把它拆成五块：

• Router + Worker 两层。Router 只跟人打交道、决定这活派给谁，它自己不拆任务，甚至不给 shell，用小一点的模型就够；Worker 各自独立会话、独立目录、并行干活，用最强的模型。
• • 事件而不是提示词。群聊消息、邮件、review 评论、CI 结果都算 trigger。先由代码过滤，只有过了过滤的才交给模型判断。Worker 订阅自己的 thread，后续追问不经过 Router。
• • 长任务先返回。聊天回复限制在 100 字以内，耗时的工具调用立刻返回句柄，Agent 边干边说。异步任务机制 DSH 本身有，但默认关着。
• • 计算、状态、机器分离。循环跑在云上，状态放数据库，本机只跑一个小 daemon 执行命令。这样开发机不用 24 小时开机。
• • Watchdog。一个单独的会话按定时器挨个检查 Worker 是不是真在推进，卡住了就处理；维护者可以用大白话问它哪一步出了问题。

自测数据：p95 从 29.5 分钟到 15.7 分钟

官方跑了一组合成负载：每次约 300 条消息，其中约 20 条是真实工作请求，跑 5 次。写代码被换成一个只消耗时间的假工具，所以测的是调度和协作，不是代码质量。团队自己也说这是初步结果。

Router 侧还有两个数字：每分钟约 1 个 trigger 时，每次决策要 6.4 秒推理；升到每分钟约 40 个时，反而降到 1.6 秒，平均批量 2.8 条。也就是说高负载下它是靠"攒一批一起判"来扛的。

最值得看的是中间那行。中性提示词下，模型五次都选择自己干，然后被不断进来的新消息打断，尾巴一路拖到 29.5 分钟。Super-agent 的解法很工程：不给 Router 干活的工具，它就没法抢活。这一刀切得比在提示词里写十遍"请学会委派"都干净。

变了什么，没变什么

变的是"谁来决定分工"。以前的 subagent 是主 Agent 自己判断这活要不要拆出去，判断本身就消耗注意力，还经常判断错。现在是角色隔离：说话的不管干活，干活的不管接客。

没变的是底下那套东西：还是 LLM 加工具调用加上下文管理，上下文满了还是得压缩，token 还是照烧。文章里有个容易被忽略的细节——如果让追问回到 Router 而不是直接进 Worker，完成时间没变，Router 决策多了约 30%，缓存 token 从 23.23M 涨到 31.77M。省的是人的时间，不是账单。

对普通开发者意味着什么

最直接受影响的是"一个人负责一条产品线"这类岗位：需求从群里来，bug 从 issue 来，CI 挂了也得有人看。以前是自己开五六个窗口来回贴，现在可能是一个常驻进程在群里接活，你只在它卡住或者需要拍板的时候出现。

但"常驻"一上来，权限就成了主要矛盾。原型里 Worker 是以运维者本机用户身份直接执行命令的，没有审批弹窗。README 自己写得很直白：跑在隔离机器或容器里，用专用 GitHub 账号，不要用你天天登录、存着 SSH key 和云凭证的那台。另外还有几个约束值得抄下来：

• 没人要求的工作先进 observe 模式，只记录它本来会做什么，不动手；
• • allowed list 一开始只放自己；
• • 文档原话，“不要用它来刷产出量”；
• • 消息、评论、引用文档都只是决策的输入，不能改变权限。
    想试的话，环境门槛不算低：

node -v          # 需要 22.19+ 或 24+
pnpm -v
git --version    # 2.32+
gh --version     # 2.48+
# 另外还需要 tmux、Python 3.8+

npx @deepseek-ai/dsh web          # 默认起在 http://127.0.0.1:3080
dsh --profile web --dump-config   # 看这台机器实际加载的插件树

安装流程官方没打算让人手搓，README 的建议是让你的 coding agent 去读仓库里的 SETUP.md，一次问一个问题，把依赖和配置装完。

几点提醒：它按 package.json 里 engines.dsh 的版本范围构建，而 DSH 自己还是 developer preview，破坏兼容是常态，装之前先对版本号；多 Agent 并行等于多份 token，Router 用轻模型只省一点；最后，这是 research prototype，文章里有些设计（比如多个 Agent 实例之间的上下文边界怎么划）代码里还没有。

最后

这套东西真正改的不是模型能力，是"一个人能带多少活"的计量单位。以前按"我一天能处理几个需求"算，以后可能按"我盯着几个 Agent"算。至于这个数字是变大还是变小，得看你是分活的那个，还是被分活的那个。

你怎么看，评论区聊聊。