DeepSeek 开源多工作代理编程原型

DeepSeek 开源的 dsh-superagent，想解决的是同时把几件事交给 AI 后，人还得盯着多个会话的问题。它用一个 Router 接收和分派请求，再让独立 Worker 并行干活，把需要人处理的结果集中送回来。

这套设计值得看，但性能结论要收着读：模拟实验里，任务完成时间的 p95 从 29.5 分钟降到 15.7 分钟，约快 1.9 倍；实验用的是合成消息和模拟工具，没有测真实代码质量。它更像一份可研究的任务调度方案，还不是成熟编码能力的证明。

它想减少的，是人盯会话的时间

dsh-superagent 是 DeepSeek Harness 团队发布的 TypeScript bundle，版本为 v0.1.0，以 MIT 协议开放，发布时只有 1 个 commit。它是面向单个 GitHub 仓库的研究原型，使用 Harness profile 配置的模型，没有绑定某个指定模型。

原文转述团队的判断：一个人能主动跟进的会话通常只有 3 到 5 个。即使模型能同时工作，人也未必有精力切换窗口、补充上下文、确认进度。

因此，系统把交互规则也当成设计的一部分：收到任务确认一次，执行期间保持安静，只在有结果、需要提问或失败时再次发言。本地 Web 面板也只列出需要人处理的事项，结果则回到原始对话，常见形式是 pull request。

这里追求的不是让 Agent 多说话，而是让人少花时间追问。

这也解释了它为什么需要常驻的调度层。单个编码会话适合完成一件事，但消息持续涌入时，还需要有人判断：这是新任务、已有任务的补充，还是根本不用处理的聊天。

Router 分派工作，Worker 保住各自的上下文

系统分成两层：长期运行的 Router 负责接收消息和调度，隔离的 Worker 会话负责执行。

事件先从 GitHub 或可选的 Feishu 进入，形成 Trigger。Eval 判断一批 Trigger 是否构成新的工作请求；被授权的工作形成 Ticket，每个 Ticket 都有独立会话和目录。

Ticket 还带着不可变的 Mandate，记录这项工作为什么有权执行。可以把它理解为任务随身携带的授权依据，而不是 Worker 看见一条消息就自行开工。

后续沟通由 Subscription 衔接。例如，pull request 下新增的评论可以直接送到对应 Worker，不必每次重新提及 Agent，也不必让 Router 重新理解整个任务。

主会话使用工具集较小的 dsh-superagent-router preset，Worker 使用 dsh-superagent-worker。Shell 命令运行超过 5 秒就转到后台，使 Worker 能继续接收消息。不过，收到消息之后怎样影响正在执行的操作，原文没有展开。

主动接活也受规则约束，提供 off、observe、auto 三种 accept mode。默认是 observe，只记录它原本会接受哪些工作，并不直接执行。

团队还提出 external Watchdog、存储与计算分离、异步 ReAct 循环等方向，但这些属于原型之外的设想，不能算作当前已交付的能力。

快了约 1.9 倍，实验究竟证明了什么

实验模拟群聊和 GitHub CI 消息流，每轮约有 300 条消息，其中约 20 条是真实工作请求，每种方案运行 5 次。

Super-agent 的任务完成时间为 p50 12.4 分钟、p95 15.7 分钟；采用中性提示词的「单会话加 subagent」基线，p95 为 29.5 分钟，没有公布 p50。p95 可以粗略理解为：约 95% 的任务能在这个时间内完成。

关键问题在于，基线虽然能够调用 subagent，却在 5 次运行中调用了 0 次。因此，这组结果支持的是：在这套模拟条件下，明确设置 Router 和 Worker，比等待单会话自行决定并行更有效。 它尚未证明这种架构优于经过专门调优的并行 Agent。

另两组数据说明了调度层的成本。消息到达率从每分钟约 1 条升至 40 条时，批次大小从 1.0 增至 2.8，单请求延迟从 2.5 秒增至 3.9 秒。

消融实验移除事件直接转发后，Router 决策次数增加约 30%，缓存读取 token 增加约 37%，从 23.23M 升至 31.77M。这说明，已经知道归属的消息，直接送给 Worker，可以减少重复判断。

这些数字均为团队自报，且原文通过二手报道转述。模拟工具也没有真实编码中的依赖安装、测试失败和需求歧义，不能据此推算实际仓库的交付速度。

我的判断

我认同它把「任务调度」和「代码执行」拆开的方向。对持续收到 issue、评论和 CI 事件的仓库来说，任务归属、授权依据和消息续接，比单纯增加会话数量更值得设计。

但它目前更适合研究和试点。原文没有提供真实代码质量、PR 合并率或人工返工量，也没有展示同等提示词和调度策略下的充分对照。减少人类注意力消耗是合理目标，目前还不能当成已测出的收益。

与其他工具相比，原文列出的运行位置差异更有参考价值：GitHub Copilot cloud agent 在 GitHub 后台运行，Claude Code Action 使用 GitHub Actions runner，OpenAI Codex 使用云端；dsh-superagent 则运行在自己的机器上。表格中的「未披露」也不能理解为其他产品不支持并行隔离。

本地运行还带来明确前提。它需要 Node.js 22.19+ 或 24+、git 2.32+、Python 3.8+、tmux 和 GitHub CLI 2.48+，并使用专用 DeepSeek Harness profile。原文明确提醒，它拥有运行该进程的 OS 用户权限。Worker 的独立目录和会话，不等于操作系统权限隔离。

能拿来做什么

• 给日常 AI 编程流程增加清晰的任务归属：一个独立任务使用一个会话和目录，后续 review 评论继续回到原任务，减少上下文互相干扰。
• 如果仓库准备尝试自动接活，先使用默认的 observe，检查哪些 GitHub 或 Feishu 消息会被接受，再决定是否启用 auto。
• 评估类似工具时，同时记录完成时间、代码是否通过验证，以及人工修改量；不要只凭模拟实验的 15.7 分钟就判断生产效率。
• 试跑原型时使用隔离环境，并核对运行用户能访问的文件和凭据；不要把 Ticket 隔离当作权限隔离。