DeepSeek 超级智能体全拆解:路由器派活、工作器干活,获批才开口
DeepSeek Harness 团队 10 月 31 日在 GitHub 发布 dsh-superagent-prototype,MIT 协议开源:面向单个仓库的主动式编程智能体原型,监听 GitHub 与飞书,获批后以拉取请求回话;同期设计文章给出内部超级智能体的用法与模拟测试数字,仓库说明同时划清原型与正式产品的界限。

最新进展
共 1 条 · 新的在上-
要闻首发:由快讯《DeepSeek开源超级智能体原型:监听仓库与群聊,获批才动手干活》(https://himiao.ai/news/2026-11-02-deepseek-superagent-prototype)扩写。
后续更新会出现在这里
事件经过
原型把一个仓库的日常协作拆成两层:常驻的路由器接收对话、评估请求并派活,隔离的工作器在各自会话与目录里执行,完成后把结果送回原对话,例如一份拉取请求。每个获批请求对应一张工单,工单附有不可更改的授权说明,后续针对拉取请求的评论也会回到对应的工作器,不用重新提及。配套的网页面板只列出需要人工处理的工作项。
同期发布的《Exploring Super-agent Design: Towards a More Autonomous Agent System》给出内部用法:据 MadRobot 对设计文章的转述,DeepSeek 内部超级智能体已经在复现并修复缺陷、回应代码评审、协助搭建 DeepSeek Harness;内部实例会持续读取公开群聊反馈、定位问题根因,并在无人点名时提交修复拉取请求。设计文章给出的理由是注意力瓶颈:据 MarkTechPost 转述,一个人同时跟进的会话数有限,3 至 5 个已是上限,模型能力之外的注意力成为并行任务的约束。
授权规则是原型与内部版本共用的门槛。文档定义三种接受模式:off、observe 与 auto,默认 observe 模式下智能体只记录本会接受的请求,不实际执行;团队写定的规则与获批人员的请求是工单开立的两条通道。运行中的行为规则同样收紧:确认一次后保持安静,工作期间不重复发言,只在拿到结果、需要提问或出现失败时再次开口。
发布背景方面,Harness 是 DeepSeek 在 2026 年 8 月发布的开源智能体框架,同样采用 MIT 协议;超级智能体原型以 Harness 的组件包形式发布,运行在操作者自己的机器上,需要专用 Harness 配置、Node.js 22.19 或更高版本、Git、Python、tmux 与 GitHub CLI。多家报道称,仓库上线一天内收获数千星;多家报道转述彭博社的描述,把此次发布看作对 Anthropic Claude Code 的挑战。
各方表态
DeepSeek 在仓库说明开篇划清界限:原型仅供参考,不是 DeepSeek 的正式产品,不是可直接用于生产的代码,可能仍有缺陷,工程风格也不统一,使用前需要检查并改造。说明同时指出,公开代码经过改编,与团队内部版本以及设计文章中的实现并不相同,文章中部分设计属于未来方向,尚未在原型中实现。README 给出的工作原则原文为:take as little human attention as possible, and give as much value as possible.
设计文章对单会话模式的批评由 MarkTechPost 转述:主流智能体把单个会话当作基本单位,人在并行任务中跟进的会话数有限,注意力成为瓶颈;超级智能体的路由器与工作器分工,是为把注意力花在必须人工处理的工作项上。报道同时提醒,模拟测试的数字来自团队自述,并非独立测评。
第三方报道的口径集中在边界上。MarkTechPost 指出,原型在自己机器上以专用 Harness 配置运行,会话以操作系统用户身份拥有完整访问权限,隔离前需要单独的操作系统账户;CompleteAITraining 的报道补充,当前版本只支持 github.com,暂不支持 GitHub Enterprise Server。两篇报道都没有把原型描述为开箱即用的产品。
关键事实
- 发布方与时间:DeepSeek Harness 团队,2026 年 10 月 31 日发布于 GitHub;仓库 deepseek-ai/dsh-superagent-prototype,2026 年 10 月 31 日 09:32 UTC 创建,MIT 协议,TypeScript 组件包,版本 v0.1.0,发布时为单次提交
- 定位:面向单个 GitHub 仓库的主动式编程智能体,打包为 DeepSeek Harness 的组件包;监听 GitHub,可选监听飞书
- 架构:常驻路由器派活,隔离工作器执行;每个获批请求对应一张工单,工单附不可更改的授权说明;网页面板只列出需要人工处理的工作项
- 授权模式:off、observe、auto 三种,默认 observe,只记录不执行;团队规则与获批请求是工单开立的通道
- 模拟测试:约 300 条消息、约 20 项工作请求,每种方案运行 5 次;中位完成时间 12.4 分钟,95 分位 15.7 分钟,单会话基线 95 分位 29.5 分钟;每次运行消耗约 2320 万缓存 token,基线为 610 万至 1080 万;数字来自团队自述模拟,并非独立测评
- 运行要求:操作者自己的机器,专用 Harness 配置;Node.js 22.19 或更高版本、Git 2.32 或更高版本、Python 3.8 或更高版本、tmux、GitHub CLI 2.48 或更高版本;只支持 github.com
- 边界:研究原型仅供参考,不是正式产品,不可直接用于生产;公开代码与内部版本及设计文章实现并不相同,部分设计属于未来方向
为什么重要
编程智能体从等人下指令转向按规则主动接活,路由器与工作器分工成为开源参考,但原型明确非正式产品,团队规则与人工复核仍是上线前的门槛。
相关公司DeepSeek
订阅 HIMIAO视界
不用注册 · 随时退订推送通知
早报出来时,手机或电脑上弹一条提醒。不用留邮箱。
™