DeepSeek 开源超级智能体原型：GitHub 上活来了它自己干

用 AI 写代码的人都懂那种"喂活"的累：模型再强，你也得当人肉调度器——发现问题、开 issue、复制上下文、盯着跑完、验收合并，一轮下来自己的活没干几件，注意力先耗光了。Agent 越能干，人越成了瓶颈。

10 月 31 日，DeepSeek 官方组织在 GitHub 开源了一个直指这个痛点的项目：dsh-superagent 原型（dsh-superagent-prototype）。它是一个面向单个代码仓库的"主动式编码智能体"，MIT 协议，开源不到两天 star 已经过两千二。注意官方在 README 第一行就写明：这是研究原型，不是正式产品。

它是怎么干活的

拆开说，dsh-superagent 的日常是这样一个循环：

1. 听着。它挂在你的 GitHub 仓库上（也可以接飞书），监听 issue、评论、消息这些"活从哪来"的入口。
2. 接单。有权限的人说一句"把这个 bug 修了"，它就开一个工单，在自己的独立会话和独立目录里开工，不污染你的工作区。
3. 交差。干完回到原来的对话里回复结果，典型形态是直接提交一个 Pull Request 等人审。
4. 找人。所有需要人拍板的事，集中显示在一个 Web 面板上，你不用翻聊天记录找进度。

官方给这套设计写了一句很提纲挈领的话：尽量少占用人的注意力，尽量多产出价值。能自己干的绝不打断你，只在有人必须行动、或者有结果值得你知道的时候才说话。反过来，一个能替全团队干活的 Agent 也能浪费全团队的注意力，所以它只在被要求时、或在团队明文写下的规则允许时才行动。

怎么跑起来

安装流程官方做得相当取巧：仓库里的 SETUP.md 不是给人读的操作手册，而是给编码智能体读的施工图。官方建议的姿势是直接对你的 Claude Code 或者其他编码助手说一句："读这个仓库的 SETUP.md，和我一起把 dsh-superagent 装好。"它会一次问一个短问题、先展示完整计划、然后动手装好配好，比自己翻文档省事得多。

想先看懂再装，文档按编号排好了阅读顺序：000 讲设计哲学，001 讲领域模型，002 讲授权，003 讲执行，006 讲部署排障，007 讲架构，008 是"给仓库加一个消息源"的菜谱。前几篇都不长，半小时能把设计思路过一遍。

几个工程细节值得划线：花钱的动作（调付费 API、买服务）一律直接拒绝，不留"先斩后奏"的口子；每次执行都在独立目录里做，事后可审计；授权模型里"谁能派活"是显式配置的，不是靠口头信任。

放到真实场景里想象一下它的位置：仓库里挂着一个没人修的低危 bug，维护者在 issue 里@它一句"试试修这个"，它自己拉分支、改代码、跑测试、开 PR，附上一段改动说明；或者每周五定时巡检一次依赖更新，有安全补丁就主动提 PR，没有就不吭声。这类"重要但不紧急、每次都要打断人"的活，恰好是最适合交给它的那一种。

两点冷静看待

其一，这是研究代码，不是生产工具。README 坦承大部分工程是编码智能体写的，代码风格可能不一致，还会有 bug，别直接抄进关键业务。其二，论文《Exploring Super-agent Design》里描述的部分设计（比如更激进的自主决策方向）在这个原型里还没有实现，当前版本守着一个"受控的主动"——它替你干活，但每个动作都在你画好的圈里。

即便如此，方向感已经出来了：单点的 AI 编程工具在卷"一次任务的完成度"，而团队级的 Agent 开始卷"占用了多少人类注意力"。前者比拼模型能力，后者比拼系统设计——授权、审计、报告的颗粒度，这些东西在 dsh-superagent 的文档里占的篇幅比提示词还多，本身就是个信号。

仓库地址：github.com/deepseek-ai/dsh-superagent-prototype。手里有闲置仓库、又常年在编码智能体旁边盯进度的人，可以找个低风险项目先让它跑一轮感受一下。