DeepSeek 编程智能体原型的任务调度设计

DeepSeek 的 dsh-superagent 最值得看的，是它怎样决定「该不该接活」，以及接活之后如何分配上下文、隔离任务、把结果交回原来的讨论。它展示了一套团队编程代理的控制流程，核心取舍是：让代理持续监听，但把执行权限落实到每一项工作。

先放低产品预期：仓库 deepseek-ai/dsh-superagent-prototype 采用 MIT 许可证，版本为 v0.1.0，只有一次提交。README 明确说它是供参考的研究原型，并非 DeepSeek 官方产品。读它更适合借鉴设计，性能数字则需要连同测试条件一起看。

持续监听，为什么还要等人开口

按原文时间线，DeepSeek Harness 团队在 10 月 31 日通过微信公布项目，11 月 1 日 Bloomberg 已将其描述为对 Claude Code 的挑战。但项目实际覆盖的范围更具体：围绕一个 GitHub 仓库工作，以扩展包的形式运行在 DeepSeek Harness 上。

它监听 GitHub 事件，也可以接入 Feishu。获得许可的人提出需求后，代理建立工作项，在独立会话和目录里执行，再回到原来的讨论中答复，结果经常是一份 pull request。本地网页面板只列出需要人处理的事项。

这里的「主动」有边界。代理可以一直接收消息，但只有收到请求，或者命中团队预先编写的规则，才会行动；只有需要人介入，或有可用结果时，才发声。

持续在线不等于持续获得执行授权。

这个区分对团队很实际。一个群聊机器人如果把讨论、建议、随口提问都当作任务，会同时消耗机器资源和人的注意力。作者看重的，正是项目把这种注意力约束写进了控制流程。

每项工作都要留下授权依据

项目的基本工作单位叫 Ticket，每个 Ticket 都携带不可变的 Mandate，用来记录「这项工作为什么可以执行」。授权跟着任务走，而不是先给整个代理一份宽泛许可。

原文用这段流程说明事件如何变成工作，以及后续消息如何回到已有任务：

Source        GitHub or Feishu produces events
Trigger       a single event arrives
Eval          does this batch of triggers ask for new work?
Ticket        unit of authorized work, with an immutable Mandate
Subscription  later PR comments reach the right worker, no new mention

要看的是最后一行 Subscription：后续 PR 评论会送到已经持有上下文的 Worker，不必每次重新提及代理、重新开启会话。前面的 Eval 则负责判断，一批消息到底有没有提出新工作。

执行架构分成两层。长期运行的 Router 使用 dsh-superagent-router 预设，只配备较小的工具集，负责交互和分发；真正干活的是隔离的 Worker，会话使用 dsh-superagent-worker 预设。每个 Ticket 对应一个会话和一个工作目录，减少并发任务互相覆盖状态的机会。

还有一个细节：shell 命令运行超过 5 秒后会转到后台，让 Worker 在慢命令执行期间继续接收消息。它解决的是会话响应问题，不能据此推断命令执行速度变快。

自主接单还有单独的门禁，提供 off、observe、auto 三种模式，默认是 observe。此时只记录「哪些任务本来会被接受」，不会实际执行。人先检查日志，再决定是否切到 auto。

作者推测切换应按规则进行，而非一次性全局放开，但原文没有确认具体粒度。可以确认的是：默认行为给团队留出了观察误触发的机会。

快了约 1.9 倍，测到的究竟是什么

DeepSeek 的模拟测试每轮约有 300 条消息，其中约 20 条是真实工作请求，每种方案运行 5 轮。super-agent 的完成耗时为 p50 12.4 分钟、p95 15.7 分钟；采用中性提示词的单会话代理虽然支持子代理，p95 却达到 29.5 分钟。

约 1.9 倍来自尾部耗时对比。这里 p95 可以理解为观察较慢一端表现的分位数，但样本轮数很少，不宜把结果当作稳定保证。

更关键的是，基线在 5 轮中一次也没有调用子代理。这个对比支持的判断是：显式分发机制，比等待一个通用会话自行决定拆任务，更容易在这组输入下发挥并发能力。它无法证明该架构胜过所有经过专门调优的单会话方案。

Router 的负载测试也有具体数字：消息到达率从每分钟约 1 条升至 40 条时，批处理规模从 1.0 增至 2.8，单请求延迟从 2.5 秒增至 3.9 秒。这说明它在模拟负载下能够合并处理消息，延迟增长相对有限。

这组测试验证的是嘈杂输入下的分发设计，没有验证真实代码质量。

流量是合成的，工具是模拟的，真实编码质量没有测量。README 还说明，公开代码经过发布适配，与内部版本并不完全相同；配套文章中的部分设计属于未来方向，尚未实现。

我的判断

我更认可它的任务模型和默认权限设置。Ticket、Mandate、任务隔离、只呈现待处理事项的面板，分别回答了四个问题：在做什么、凭什么做、会不会互相干扰、什么时候需要人。

相比一个拥有大量工具、直接驻扎在聊天频道里的机器人，这种设计更容易追查任务来源，也更容易控制打扰。不过，原文没有提供长期团队使用的对照数据。「更少占用注意力」目前主要是设计目标和作者判断，不能当成已验证收益。

隔离也有边界：独立工作目录能减少本地状态冲突，却不等于多个任务修改同一仓库时没有集成冲突。原文没有交代合并协调的完整办法。

原文还援引 Microsoft Agensh 实验：1,024 个没有管理者的代理，被一个使用更新模型的代理超过。它可以提醒读者别迷信代理数量，但模型与实验条件不同，不能拿来直接证明 dsh-superagent 的优势。

能拿来做什么

• 如果你在给前端或 Node 仓库接入聊天触发的编程代理，可以先建立持久化任务记录，并为每项任务保存授权依据，让执行过程有据可查。
• 如果准备让代理自动接单，可以借鉴 observe：先记录会接受哪些请求，检查普通讨论是否被误判，再决定开放哪些规则。
• 如果代理要并发处理多个 PR，可以采用每项任务独立会话和目录的方式，并把后续评论路由回原 Worker，减少上下文反复重建。
• 如果只是想试运行原型，先核对 Node.js 22.19+ 或 24+、git 2.32+、Python 3.8+、tmux、GitHub CLI 2.48+，并使用独立的 Harness profile。原文给出的安装入口，是让编码代理读取仓库内的说明：

Read SETUP.md in this repository and set up dsh-superagent with me.

注意其中的 SETUP.md：安装流程面向代理编写，会逐个提出简短问题，完整展示一次计划后再安装。试运行仍应按研究原型评估，不能把模拟测试成绩直接当作仓库生产力预期。