DeepSeek 开源了一个会刷 GitHub Issue 的 Agent，默认只给你 3 个工人

DeepSeek 开源了一个会自己刷 GitHub Issue 的 Agent。默认只开 3 个工人槽，最多 16 个，另外留 1 个给人类消息。这个数字比宣传语有意思。

项目叫 dsh-superagent-prototype，MIT 许可，DeepSeek 说它是研究原型，不是产品。它来自 DeepSeek Harness 团队。用法很具体：盯一个 GitHub 仓库，可选接入飞书群。白名单里的人提需求，它开工作项，先做一版，草拟修复，再把结果交回人类 Review。仓库在 deepseek-ai/dsh-superagent-prototype。Leandro von Werra 在 X 上发了消息，AGTP 随后给了更完整的拆解。

文档截图里写得很直白：GitHub 和飞书触发事件，确定性门控先检查发送者是否在允许列表，主会话路由器判断接受、停止、忽略或不可用，然后创建带不可变指令的票据。每个票据有自己的工人会话和目录，结果回到同一线程。

AGTP 的推文把架构说得更完整：常驻 Router 加多个并行 Worker，触发器包括群聊、邮件、日历提醒、GitHub 评论和 CI 测试结果。它 24/7 在线，自己接活。DeepSeek Harness 工程师 Yujia Qiao 写了设计文章《Super Agent: Proactive Is All You Need?》。文章先在国内传播，几小时后出现社区英文翻译，官方英文版说很快发。

关键限制在文档里：

这些数字比口号有用。它把人类注意力当成上限，然后给上限加护栏：一个 ticket 一个 worker，有超时，有拉人规则。模型多强先放一边，边界写清楚更重要。

社区反应分两派。支持者看到软件工厂，觉得仓库离自我维护近了一步。反对者先算账：more workers just means more prs to read。有人担心两个 agent 碰同一个文件，第二个 PR 要 rebase。有人问原型会不会让重叠 PR 走一个协调器，还是让它们先撞车再解决。还有人说，很多 agent 并行处理 Issue 和 PR 听起来很好，直到一个累的人要 Review 全部。

有人直接贴了辛普森一家喊 Stop 的视频，配文 job market。

并行越多，冲突和 Review 队列越像新瓶颈。DeepSeek 把默认 3 个工人槽写进文档，至少没假装人类不存在。想试的人，先拿一个小仓库跑。别一上来就把全仓 Issue 交给 16 个工人。