issue 没人回、代码没人审？他们让一个 agent 蹲在仓库里主动干活（2 万星）

2026-11-11silcano

你雇一个人，是让他等你喊，还是让他自己找活干？现在的 agent 全都是"等你喊"的那种。

DeepSeek 这个原型换了个方向：让 agent 常驻在一个仓库里，监听 GitHub（可选飞书），有人提 issue、有人 @ 它，它自己判断要不要动手。

项目叫 dsh-superagent-prototype，10 月 31 日才放出来，现在 2.2 万星，每天涨 2025 星。它明确写着"仅供参考的研究原型，不是官方产品"——这句话很重要，下面会讲清楚它意味着什么。

一、先说结论：它把"被动"改成了"主动"

现在所有 coding agent 的交互都是同一个形状：你给任务，它干活，干完停。

这个形状有个天然的浪费：agent 不知道仓库里发生了什么。issue 积了三天的没人看，PR 里的代码明显有问题但没人指出，CI 挂了两次也没人管——这些信息一直在那儿，但 agent 不看，因为它"没被叫"。

主动型 agent 的思路是把这个循环倒过来：agent 常驻，事件驱动。仓库里发生了一件事，触发它去看、去判断、去动手。

这个原型的边界画得很清楚，一句话：一个 agent 只管一个 GitHub 仓库。

二、它明确不是给你的成品

README 第一段就把话说死了，我几乎照抄给你看：

后面还有两句更关键的：这段代码是从团队日常开发里长出来的，大量工程是 coding agent 自己写的；而且为了公开发布做过适配，和他们内部版本、以及那篇文章里描述的实现并不完全一样。

这三点决定了它的定位：

最后一条特别有意思。一个"让 agent 主动写代码"的项目，它自己的代码也是 agent 写的——这本身就是一次实验：agent 写出来的东西，人能不能接得住。

三、它到底怎么工作

按 README 的描述，把机制拆成四步：

1. 监听。 盯着一个 GitHub 仓库的事件流（issue、评论、PR 等）。可选接入飞书，把消息也当触发源；
2. 唤醒。 有人"允许"它参与时（README 指的是被 @ 或获得授权），它才动手。这条设计很关键——不是无条件自己改；
3. 执行。 作为一个 DSH bundle 跑起来，用 harness 里的工具去读代码、改文件、跑测试；
4. 回写。 把结果写回仓库（回复、提交）。

这里有个设计上的取舍值得说：它把"要不要动手"做成了权限问题，而不是判断问题。

意思是：它不去猜"这个 issue 值不值得我管"，而是等一个明确的授权信号。这比"让模型自己判断要不要行动"保守得多，也安全得多。

四、装：它是 dsh 的一个 bundle

它不是独立程序，是 DeepSeek Harness 的一个 bundle。所以前置条件是先有 dsh。

先确保 dsh 能跑：

然后按仓库 Setup 一节装这个 bundle。package.json 里能确认它的身份：

注意 "private": true——它没有发布到 npm，所以你只能从源码装，不能 npx。

这意味着流程是：clone 仓库 → 按 Setup 里的步骤装进 dsh → 配置仓库和凭据 → 启动。

五、配置清单：动手前必须准备好的四样东西

这类"常驻监听"的系统，最贵的不是装，是配。按重要程度排：

第四项最容易省，也最不能省。它要改代码、要跑命令，这些动作在你本机上执行时，权限跟你一样。

可选接飞书。接了之后，群里的一条消息也能触发它。好处是入口更低，坏处是攻击面变大——群里任何人发的消息都成了输入。

六、这类系统真正难的地方（不是模型）

我看完这个原型，最大的感受是：难点全在模型之外。

第一，幂等。 同一个 issue 被编辑了三次，它会不会干三遍活？事件流是"至少一次"投递，不是"恰好一次"。

第二，冲突。 它在改文件的时候，人也在改。谁赢？没有锁机制的话，最坏情况是互相覆盖。

第三，退避。 一个 PR 改坏了 CI，它去修，修坏了再修，无限循环。必须有"我搞不定，交给人"的出口。

第四，记账。 它花了多少钱、改了多少行、开了多少 PR。没有账本，你无法判断它是在帮忙还是在制造噪音。

这四件事，README 没有逐一展开——因为这是原型，不是产品。但你真要上这类系统，这四条是必须自己补的。

七、为什么只盯"一个仓库"

这个限制看着很弱，其实是刻意的。

管一个仓库，意味着它的上下文可以很小：一套代码结构、一套 CI、一套规范。它能把这套东西记住、背下来，判断才有依据。

要是让它管十个仓库，它每次动手前都得先搞清"这是哪个项目、规范是什么"，光这一层就吃掉大半上下文。

这个思路跟你带人一样：新人先跟一个项目，跟熟了再放手。

八、七个坑，按踩到的概率排

• 把它当产品用。 README 明说不是。没有 SLA，没有支持，接口随时变；
• 用个人主号跑。 它的一切动作都以那个身份留下记录。用专用号；
• Token 给太大。 只给目标仓库，别给 repo 全权限；
• 没设触发白名单。 谁能唤醒它，等于谁能指挥它改你的代码；
• 没有成本上限。 事件驱动 = 可能高频触发 = 账单失控。设日预算；
• 没有 kill switch。 出问题时你得能在 10 秒内停掉它，别去翻文档找命令；
• 指望它一次就对。 原型阶段的正确率不会高，先让它只做"读 + 提建议"，不给写权限，跑一周看质量再放权。

最后一条是我最想强调的。放权要分阶段：先只读、再只写评论、最后才给提交权限。反过来做，第一次事故就够你放弃这个方向。

九、这类"主动 agent"的合规与伦理边界

它会在你的仓库里留下 commit、评论、PR。这些是公开记录。

开源社区对 bot 的容忍度很低。一个自动 agent 在别人仓库里刷三条无效评论，就会被举报。

十、谁该看这个项目

十一、把它和"定时任务"分清楚

很多人第一反应是：这不就是个 cron？

不是。cron 是时间驱动——每天九点跑一次，不管有没有事；这个是事件驱动——有事才动，没事就睡着。

成本那一条是关键。事件驱动的账单不是线性的——一个热门仓库一小时来二十条评论，它就醒二十次。

十二、地址与版本汇总

版本（截至 2026-11-10）：

最后一句：这个项目最值钱的地方不是它能替你干活，而是它把"主动 agent"的骨架摊开给你看——触发、权限、执行、回写，四段，缺一段就不成立。