不是一次产品发布：DeepSeek Super-agent 原型，以及它问对的那个问题

先说清楚：这不是一个新产品，而是一份研究原型

2026 年 10 月 31 日，DeepSeek 的 Harness 团队在 GitHub 上公开了一个仓库：deepseek-ai/dsh-superagent-prototype，标题是《Towards a More Autonomous Agent System》（走向更自主的智能体系统）。仓库建成的当天就冲上了几千 star，到 11 月 1 日爬取时已经是 6589 个 star、649 个 fork，MIT 开源协议。数字很抢眼，但读 README 的第一句话就得先降温：这是一个“仅供参考的研究原型，不是 DeepSeek 的官方产品”，代码来自团队日常开发工作的改编，和设计文章里描述的内部版本并不完全相同，有些设计只是未来的发展方向，还没有实现。换句话说，今天能下载到的东西，是一份可以读、可以改、可以跑起来的参考实现，而不是一个开箱即用的商业产品。任何把它当成“DeepSeek 发布了 Claude Code 杀手”来吹的说法，都对不上作者自己的定性。

那它到底是什么？按 README 的说法，dsh-superagent 是一个“主动式编码智能体”，打包成 DeepSeek Harness 的一个 bundle，服务范围收得很窄：一次只对接一个 GitHub 仓库。它监听 GitHub 事件， optionally 还能接飞书；当一个有权限的人在对话里向它要活儿时，它会开一个工作项，在自己的智能体 session 和目录里把活干完，再回到原来的对话里交结果——比如提一个 pull request。旁边还有一个网页面板，专门列出“需要人出面的事”。这个收窄很重要：它不承诺替整个公司管所有仓库，也不承诺 24 小时替你值班，它只解决一个仓库里的“活儿来了、有人接、结果回得来”这一段闭环。

核心理念：别让人多盯几个会话，让系统少打扰人

设计文章的出发点，是一句很直白的话：尽可能少占用人的注意力，尽可能多交付价值。一个能替整个团队干活的智能体，同样也能浪费整个团队的注意力——它每多说一句话、多开一个会话、多提一个半成品 PR，都是在向所有人收税。所以 Super-agent 的工作原则被定成两条：只在被要求时行动，或者在团队事先写好的规则允许时行动；只在有人必须行动、或者能用上结果时才开口。README 里把这套原则指向了 docs/000-philosophy.md，那篇文档是理解整个设计的第一块拼图，也是最容易被二手报道跳过的一块。

这个原则背后有一个对现状的判断：现在主流的编码智能体，是以“一次会话”为基本单位的。人要亲自开会话、给上下文、派活、盯执行，一个人能同时跟进的会话数也就是三到五个，再多就顾不过来了。Super-agent 想换一个单位：人不用多开会话，系统自己负责任务调度、上下文同步、并行执行和恢复。听起来像是从“一个人带几个助手”变成“一个人管一个能分活的调度台”，但这句话目前还只是设计方向，公开原型里并没有把全部能力都兑现，读的时候要把“文章里说的”和“仓库里有的”分开。

两层结构：一个常驻 Router，加上一群干活的 Worker

架构上，Super-agent 分成两层。上面是一个常驻的 Router，负责和人打交道、派活；下面是一群相互隔离的 Worker session，各自并行干活，干完向 Router 汇报，而不是直接去打扰用户。主会话用的是 dsh-superagent-router 预设，工具集比较小；每个 Worker 跑 dsh-superagent-worker，拥有完整的工具。这样做的好处是分工干净：Router 不用亲自写代码，所以不会被某个任务的细节拖住；Worker 不用操心该先干哪件、结果该告诉谁，只管把分到的活干完。坏处也同样明显：多一层调度，就多一层出错和延迟的可能，Router 对任务的理解一旦走偏，底下几个 Worker 可能朝着错的方向一起跑。

仓库里附带的文档是按顺序读的，一共九篇，从理念、领域模型、授权、执行、提示词、面板、部署、架构到一本“怎么加一种新来源”的 cookbook。顺序本身就是一种表态：先讲清楚“什么时候不该打扰人”，再讲“活儿怎么分”，最后才讲“怎么部署”。对想直接拿来用的团队来说，授权那篇（002）最值得先看：谁有资格在对话里给智能体派活、它能碰仓库的哪些部分、哪些动作必须先经过人点头，这些规则不是事后补丁，而是整个系统成立的前提。没有这套规则的“主动”，在真实团队里就是一场灾难：任何人随手一句话，都可能变成一次没人复核的代码改动。

那组实验数字怎么看：快，但别当成质量证明

传播最广的一组数字来自团队自己的模拟实验：大约 300 条消息、约 20 个真实工作请求的一轮里，Super-agent 完成一半任务的中位时间是 12.4 分钟，95% 的任务在 15.7 分钟内完成。数字本身不难理解：并行 Worker 一起开工，当然比一个人排队等要快。但这组数字有三个硬边界，必须同时说出来。第一，消息是模拟的，工具也是模拟的，不是真实仓库里的真实任务；第二，实验测的是完成时间，没有测代码质量；第三，跑的是“每个方案各 5 次”的小样本。也就是说，它证明的是“调度结构能省时间”，没有证明“写出来的代码能用”。把 12.4 分钟解读成“以后程序员 12 分钟就能交付一个需求”，属于对实验的误读。

还有一个细节值得单独拎出来：README 坦白说，这个原型“大部分工程工作本身就是由编码智能体完成的”，代码“可能还有 bug，编码风格和工程实践可能不一致”。这句话既是诚实，也是一种自我指涉的演示：一个研究“智能体怎么替团队干活”的项目，自己的代码就是智能体写的。对读者来说，这句话的实际含义是：拿来学习、拿来改，合适；直接部署到生产仓库、放开权限让它自动提 PR，不合适。先读代码、再决定给它多大权限，这个顺序不能反。

和 Claude Code 是什么关系：对标，但不是同一类东西

不少报道把 Super-agent 写成“挑战 Claude Code”的产品。这个对标有一半是对的：两者都在解决“怎么让智能体替开发者干活”，而且 Super-agent 的 Harness 团队今年早些时候就是为了和 Anthropic、OpenAI 的编码服务竞争而组建的。但另一半是不对的：Claude Code 是一个已经大规模交付的产品，有订阅、有 IDE、有完整的工具链；而 dsh-superagent 是一个单仓库、研究性质的原型，连作者都强调它不是官方产品。把两者放在“谁赢谁输”的擂台上比，等于拿一篇架构论文去和一个上市产品比销量，维度就错了。更准确的定位是：DeepSeek 把自己内部“怎么让智能体少打扰人、多干活”的工作方式，抽出来公开了一部分，供所有人参考和批评。

对国内开发者来说，还有一个现实的观察角度：这个原型默认接的是 GitHub 和飞书。飞书这个选项不是随便加的，它说明设计团队想的“团队对话”场景包括了国内常用的协同工具；但与此同时，仓库的文档、示例和提示词目前以英文为主，团队要真正用起来，还得自己补一层本地化。部署上它也明确说了“步骤很多，所以让你的编码智能体陪你一起装”——README 甚至直接给了你一句可以粘贴给智能体的话，让它照着 SETUP.md 一步步问你、装好它。这种“用智能体装智能体”的做法，倒是和它的主题很配。

给不同读者的建议：先读，再决定给它什么权限

如果你是独立开发者，想借鉴它的思路，最值得抄的不是代码，而是那条工作原则：先定义“什么时候不许打扰我”，再谈自动化。把这条原则写进你自己的 agent 规则里，收益比直接部署这个原型更大。如果你是团队负责人，在考虑要不要试它，先做三件事：第一，只给一个非核心仓库做试点；第二，把授权规则写死，谁能派活、哪些改动必须人工合入；第三，盯着那个“需要人出面”的面板跑两周，看它到底省了多少注意力，还是制造了新的待办。如果你是研究者，九篇文档加模拟实验的设计，是一份现成的讨论材料：Router-Worker 的分层、异步多通道交互、以及“注意力预算”这个评价维度，都值得拿到自己的实验里再验一遍。

上手路径：别急着给权限，先把九篇文档读完

对真的想动手的人，仓库给出的上手路径本身就很有代表性。第一步不是下载安装包，而是读文档：九篇编号文档要求按顺序读，每一篇只建立在前面的基础之上。理念篇讲“什么时候不该打扰人”；领域模型篇把“工作项、会话、对话”这些概念定下来；授权篇讲谁能派活、能碰什么；执行篇讲任务是怎么跑起来的；提示词篇讲 Router 和 Worker 各自用什么提示词；面板篇讲那个“需要人出面”的网页怎么用；部署篇讲手动安装、配置、升级和排错；架构篇把全图拼起来；最后一本 cookbook 讲怎么给系统加一种新的来源。这个顺序对 vibe coding 的项目特别有参考价值：很多小项目的问题不是代码写不出来，而是概念没定下来就开始堆功能，最后每个人对“一个任务到底是什么状态”都有自己的理解。

第二步是安装，而安装方式也值得注意：README 直言“步骤很多，所以让你的编码智能体陪你一起装”，并给出了一句可以直接粘贴的话，让智能体照着 SETUP.md 一次问一个短问题，先把完整计划展示一遍，再动手安装和配置。这种做法把“装一个 agent 系统”本身也变成了一次 agent 协作的演示，但它同时也意味着：如果你连自己的编码智能体都还没有跑顺，直接上这个原型会很吃力。更稳妥的顺序是先在本地把一个最小的 Harness 环境跑起来，确认能收到 GitHub 事件、能开工作项、能在面板里看到待办，再去碰飞书那条线。飞书的接入是可选的，先把 GitHub 这一条主链路跑通，再扩展消息渠道，出了问题也好定位。

第三步是定规则，而且要在第一次给它真实仓库权限之前就定好。至少要写清楚四条：哪些人可以在对话里派活；哪些仓库、哪些分支是它能碰的；哪些操作（比如合入主分支、发版、改权限配置）必须经过人工确认；以及它的产出以什么形式回来，是直接提 PR，还是先以草稿形式等人过目。README 里说的“只在被要求时行动，或者在团队事先写好的规则允许时行动”，在落地时就对应这四条。没有这四条就放开权限，等于把一个还会犯错的研究原型直接放进了生产流程，出了问题再去翻日志就晚了。面板的存在正是为了这一步：它不重复智能体的全部活动日志，只列出“需要人出面”的事，健康状态下这个面板甚至可以是空的——空面板不是没干活，而是活都干完了、不需要你。

争议与未解问题：星标速度、报道口径与内部版差距

这个发布还有三处值得冷静看的地方。第一是星标速度。仓库 10 月 31 日 09:32 UTC 创建，当天就冲到两千多 star，次日爬取时已是 6589 个。这种速度在 GitHub 上并不常见，它说明话题本身踩中了所有人的焦虑：大家都想要一个“不用一直盯着”的智能体。但星标数衡量的是兴趣，不是质量，更不是生产就绪度。过去几年里，一天暴涨几千 star 后又迅速沉寂的仓库并不少，真正能留下来的是那些在三个月后还有人提 issue、修 bug、写文档的项目。判断这个原型值不值得长期跟进，标准不该是首周的 star 曲线，而应该是接下来几个月里，Harness 团队是否持续更新它、是否把设计文章里“未来方向”的部分逐步兑现。

第二是报道口径的差异。彭博等媒体的报道把它放在了“挑战 Claude Code”和 Anthropic 即将 IPO 的时间点上讲，这个叙事很抓眼球，但它和仓库自己的定性有落差：作者说这是研究原型、不是官方产品，公开版和内部版并不相同。媒体叙事关心的是竞争格局，仓库关心的是工作方式，两者都没错，但读者如果只读了媒体标题，就会以为 DeepSeek 马上要拿出一个能直接替代现有工具的产品。更公允的读法是把两者拼起来看：竞争格局确实在变化，DeepSeek 也确实在加码编码智能体，但这次公开的东西，是一份架构参考，而不是一次产品发布。把“发布了原型”写成“发布了产品”，是这轮报道里最常见的夸大。

第三是内部版和公开版之间的差距。README 明确说了，公开版经过改编，和内部版本以及设计文章描述的实现不完全相同，文章里的一些设计是未来的发展方向、尚未实现。这意味着，设计文章里最吸引人的部分——比如全天候的持久运行、推测执行、多通道的异步交互——不一定能在今天下载到的代码里找到。读者在引用这篇文章时，最好养成一个习惯：每提到一个能力，就问一句“这是文章里说的，还是原型里已经有的”。这个习惯不仅适用于 Super-agent，也适用于所有“论文加原型”式发布。原型存在的意义，恰恰是让这种追问变得可能：你可以打开代码、跑通流程、自己验证，而不是只能相信文章的说法。

一句话总结这轮发布：它不是来终结谁的，而是一个值得被认真读、谨慎试的参考实现——读它的理念，试它的原型，但别急着把生产仓库的钥匙交出去。

最后回到开头那句话：这个仓库值得关注，不是因为它在一天里拿了几千 star，而是因为它把一个平时被忽略的问题摆到了台面上——智能体越能干，人越容易被它的产出淹没。Super-agent 给出的答案还很初步，原型和内部版本之间还有距离，实验也还没有回答质量问题。但它至少把问题问对了：下一个阶段的竞争，可能不在于谁的模型写代码更快，而在于谁的系统更懂得“什么时候闭嘴”。这个判断，是这篇 10 月 31 日的发布留给所有做 agent 的人最有价值的东西。