DeepSeek Super-agent – DeepSeek 开源的编程智能体原型

DeepSeek Super-agent 是 DeepSeek Harness 团队于 2026 年 10 月以 MIT 协议开源的主动式编程智能体研究原型，面向单个 GitHub 仓库工作，可接 GitHub 通知与飞书消息，用 Router 与 Worker 双层结构把同一项工作拆到多个会话并行推进，适用于需要让智能体长期跟进一个仓库的开发场景。

DeepSeek Super-agent 的核心能力

DeepSeek Super-agent 要解决的不是「模型会不会写代码」，而是「一个团队的工作被拆成多少段对话、每段进行到哪一步没人记得清」。官方文档给出的观察是人通常只能同时跟进三到五个活跃会话，瓶颈会更快从模型转到人的注意力。公开仓库是这套架构的研究原型，官方定位为技术路线验证，并非正式产品；下文区分已落地功能与设计构想。

Router 与 Worker 拆成两层

上层 Router 接收消息、分配任务并维护全局上下文，下层 Worker 各自持有独立会话与工作目录，多项任务并行互不干扰。Router 只做调度不参与实现，任务量涨上去时扩的是 Worker 数量，而不是继续把上下文压给同一个会话。

订阅与直通让后续消息直达 Worker

某个 Worker 接手一个拉取请求后可以直接订阅它的后续评论，之后有人提修改意见，消息直接交给该 Worker，不必再经 Router 层层转发。官方在对照实验里关掉直通机制后，Router 的决策次数增加约 30％，读取缓存 Token 增加约 37％。这组实验跑在合成负载与简化环境里，看的是调度与协作开销，不看单任务执行能力。

从事件到工单全链留痕

来源产出事件，事件归入线程，Eval 判断是否立新工单，接受时签发 Mandate 记下依据与授权范围，Assignment 把工单交给执行会话，结果再经 Channel 回到原对话。同一个事件被接受两次只产生一个工单，服务重启也不会重放已经读过的事件。

授权写进版本化的策略层

谁能通过哪个来源发起工作、允许名单里有谁、哪些机器人可以提候选，都写在 Policy 里并按版本管理。Policy 变更不撤销已经发出的 Mandate，而是投递给正在执行的工单，避免半成品被中途掐断；工单被人唤醒复跑之前会重新对照当前 Policy 校验，校验不过即撤销 Mandate。站内的 OpenAI Agents API 是另一条路径——编排接口把授权与工具托管在平台侧，这里的授权留在自己的仓库里。

会话状态与执行环境分开存放

计算逻辑、会话状态与工作目录三者分开：状态落在本机 stateDir 的会话库里，执行环境留在原有机器上。服务停掉后状态仍在，重启后接着处理；执行环境始终在本机，机器离线期间没有云端代跑。起停走 tmux 里的脚本，状态查询用四个退出码区分「正常」「没起来或重了」「起来了但有部件报错」「等人配置」三种异常。

Watchdog 监督异常，异步循环不阻塞交互

官方设计文章另提出独立的 Watchdog 会话：它监督其他执行会话，既发现程序故障，也判断任务是否陷入无效循环或偏离目标。同文提到的异步 ReAct Loop 让耗时任务不阻塞新指令，官方说明该机制已在 DeepSeek Harness 中实现但未默认开启。两项均出自设计说明，公开原型的代码与文档里未见对应实现。

DeepSeek Super-agent 与同类开源编程智能体的对比

下表从运行形态、任务来源、状态与恢复等维度，对三个开源编程智能体项目逐项对照，比较的是工作怎么被组织起来，而不是各自模型强弱。

• 表格内数据来源：DeepSeek Super-agent 一列取自官方 README、SETUP.md 与部署文档；Pi 与 Prime Agent 取自各自仓库说明与 GitHub 接口实查。协议一栏指代码授权，不含所调用模型的授权。
• 产品对比简述：三者都是开源编程智能体，差别在组织方式——DeepSeek Super-agent 把消息来源、工单与授权做成独立一层；Pi 走极简路线，只给模型四个基础工具，能力靠扩展包叠加；Prime Agent 用递归语言模型与持久 REPL 承载长周期任务。

如果更关心同一出品方在开源基础设施上的另一条线，站内的 DeepInfer（DeepSeek 开源的内部大规模推理框架）可以直接对照着读。

DeepSeek Super-agent 的应用场景与适用人群

一个团队长期在一个仓库上协作时适用；只想让助手补全几行代码的，用终端助手更直接：

• 处理仓库事务：群里报了缺陷，智能体贴着上下文复现、定原因，能修就直接开拉取请求。
• 跨平台接着聊：群里先定方案，评审里又改成另一版，同一项工作跨会话延续，不用重复交代背景。
• 多任务并行：几个工单同时推进，长任务不阻塞新对话，人只被叫到必须决策的那一步。
• 长期值守：夜间与休息时段继续跑，异常时尝试自愈，回到工位先看面板上的待决清单。

适用人群：适合已经在用 DeepSeek Harness、想把重复的开发协作交给常驻智能体的团队；每个实例面向一个仓库，多仓库需分别部署；完全不用命令行、也没有长期在线机器的，这套方案的价值难以成立。站内另有一篇观察写透了这条产品线的来路：DeepSeek 把编程智能体搬上桌面；自托管多智能体这一侧还有 Octop 可作对照。

DeepSeek Super-agent 的使用方法

官方把安装做成一件「智能体陪你做」的事：机器上先有 Node.js 与 DeepSeek Harness，剩下的交给读 SETUP.md 的编程智能体逐项完成。两条路径：本机部署是主路径，接进飞书群聊是可选项。代码在 dsh-superagent 仓库。

本机部署：另建 superagent profile 再接起来

1. 备齐前置：Node.js 22.19 以上或 24 以上、pnpm、git 2.32 以上、Python 3.8 以上与 tmux，此外需 GitHub CLI 2.48 以上；Harness 版本需满足仓库 engines 的 dsh 约束。
2. 为智能体单独开一个 GitHub 账号并给仓库写权限，用独立配置目录的 gh-agent 包装器登录，不要混用自己的账号。
3. 在 Harness 里新建名为 superagent 的 profile，把仓库里的 cordis.patch.yml 复制到 ~/.dsh/profiles/superagent/，填好 stateDir 等占位项。
4. 把配置交给编程智能体做：让它读仓库里的 SETUP.md，一次问一个短问题，之后安装与配置一并完成。
5. 用 scripts/dsh-superagent start 起服务、status 看状态，面板默认只在 127.0.0.1 上提供。

接进飞书群聊：以插件形式让机器人在群里接活

1. 在飞书开放平台建一个带机器人能力的自建应用，开通接收消息事件、读写群消息与读取群成员权限后发布应用。
2. 用独立配置目录初始化 lark-cli，再用 lark-bot 包装器把凭证限定在机器人身份上。
3. 在面板的 Sources 里加上飞书这一路，允许名单与准入规则写进 Policy。

四点需留意：面板只监听 127.0.0.1，远程访问要自加反向代理与鉴权；Worker 以当前系统用户身份、用 danger-full-access 预设运行，能读主目录、可按路径执行程序，要隔离需另开只放智能体凭证的系统账号，且该账号不存放个人凭据；仓库限定 github.com，不支持 GitHub Enterprise Server；该原型与官方设计文章所述并非同一份代码，投产前需自行核对。

DeepSeek Super-agent 的项目地址

• 项目仓库：https://github.com/deepseek-ai/dsh-superagent-prototype
• 运行环境 DeepSeek Harness：https://www.deepseek.com/harness/

DeepSeek Super-agent 的价格方案

项目本身以 MIT 协议开源免费，代码、文档与示例随仓库发布，自建自用不产生授权费用。

花钱的地方在两处：一是模型侧，插件默认用所在 Harness profile 的默认模型，按该提供方方式结算，也可另指一个；二是机器侧，需要一台长期在线的机器承载 Harness、会话库与工单目录。

飞书这一路不单独收费，需用到企业自建应用与机器人权限，平台侧计费以其规则为准。

DeepSeek Super-agent 的常见问题