重磅！DeepSeek 开源 Super-agent 是什么：双层架构、主动找活的 Agent 原型怎么部署（2026 年 11 月）

发布日期：2026-11-01 ｜信息来源：GitHub 仓库 deepseek-ai/dsh-superagent-prototype（README、SETUP.md、docs/000–006）、DeepSeek Harness 官方文档、DeepSeek Harness 团队技术文章《Super-agent 设计探索：迈向更自主的 Agent 系统》

Super-agent 是 DeepSeek Harness 团队 2026 年 10 月 31 日公开的一套自主 Agent 架构，配套原型 dsh-superagent 同日以 MIT 协议开源。它是一个常驻在线的 Coding Agent，盯住一个 GitHub 仓库，也可以接入飞书群。有人 @ 它提需求，它就开工单，在独立会话和目录里干活，最后回到原对话交付，比如提一个 Pull Request。架构上，一个常驻的 Router 负责收消息和分派，多个上下文隔离的 Worker 并行执行。再配合事件订阅直通、异步 ReAct Loop、存算分离和外部 Watchdog，Agent 可以"不切会话并行推进多项任务"。团队的初步实验约 300 条消息、20 项工作请求：Super-agent 任务完成时间 p50 为 12.4 分钟、p95 为 15.7 分钟；带 Subagent 工具的单会话方案在中性提示下 p95 是 29.5 分钟。官方强调这只是研究原型，不是 DeepSeek 正式产品。截至 11 月 1 日，仓库约 2,800 星。

它想解决的问题：人的注意力成了瓶颈

DeepSeek Harness 团队的判断是：模型完成单个任务已经越来越不需要人介入，限制产出的变成了人能同时盯住多少个会话。团队观察到，一个人通常只能同时跟进 3 到 5 个活跃 Session。

现在的 Coding Agent 以单个 Session 为单位工作。用户在群里定了方案 A，转头到 GitHub PR 评论里改成方案 B，这两条信息落在两个会话里，得用户自己去搬上下文。

Super-agent 要做到的是：用户感觉始终只在和一个 Agent 打交道，会话怎么拆、上下文怎么同步，由系统在底层处理。团队给它定了四个特征：

连续：在 IM 群聊、GitHub 评论等熟悉的界面里交互，跨渠道理解同一件事。
高效：不用等上一个任务做完，就能接下一条指令，多个任务并行。
主动：持续观察环境事件，值得处理的事主动推进，不需要介入时保持安静。
持久：始终在线，长期运行中出了异常能自己恢复。

项目的核心原则写在 docs/000-philosophy.md 第一行："尽可能少占用人的注意力，尽可能多给出价值。"所以它只在被请求、或团队写好的规则允许时才行动，只在有人需要决策或能用上结果时才说话。

架构拆解：五个模块，大多借自计算机系统

团队的说法是，这套设计没有提出新理论，而是把调度、缓存、存算分离、看门狗这些计算机系统里的经典思路搬进 Agent。

1. 双层架构：Router 只分派，Worker 只干活。 常驻的 Router 承接所有入口的人类交互，维护全局上下文，本身不执行具体任务，甚至可以不配 Bash 工具。Worker 之间上下文隔离，挂载完整执行工具，专注单一任务，不直接对外说话，结果由 Router 统一回复。团队实践中 Router 用较轻量的模型就够，Worker 则需要能力最强的模型。

2. 事件驱动：环境事件当输入。 群聊消息、代码评审评论、CI 结果都是 Trigger，过滤分两级：

程序层（Fast Path）：按来源、群组、白名单等确定性条件快速筛掉大部分噪音。
语义层（Slow Path）：剩下的候选事件交给大模型，按提示词写的策略判断要不要行动。

3. 订阅直通：后续事件不绕 Router。 某个 Worker 接手一个 PR 后，会直接订阅这条 Thread，之后的评论由程序直接发给它，Router 只处理还没人认领的新事件。订阅是多对多的，两个 Worker 订阅同一个 PR，就能看到彼此的操作，自行发现冲突。

4. 上下文当缓存管：Inline & Spill 与链式召回。 高频用到的信息直接内联进上下文，长内容截断后留续读入口。每个对象都内联下一跳的 ID，Router 可以从一条消息顺着 Thread、Worker Session 一路找回旧任务。文章原话："浪费上下文窗口，就是浪费模型的智能。"

5. 持久在线：存算分离加外部 Watchdog。 Agent Loop 的计算放云端，会话状态单独存，代码仓库和本地工具链留在用户机器上，电脑离线也不丢任务。另起一个独立的 Watchdog 会话定时巡检，除了接口报错，还会判断各 Worker 有没有实质进展、是不是陷入了无效循环。

此外，团队把耗时工具改成异步的 start() 和 stop()，后台跑命令时前台仍能接新指令。这个机制已在 DeepSeek Harness 中实现，但尚未默认开启。

实验数据：用更多 Token 换更短、更稳的完成时间

团队用群聊和 GitHub CI 消息流做了初步实验：单次约 300 条消息，其中约 20 条工作请求，编码工作用只耗时的工具代替，每种方案跑 5 次。

方案	任务完成时间 p50	任务完成时间 p95
Super-agent（双层架构 + 订阅直通）	12.4 分钟	15.7 分钟
单 Session + Subagent 工具（中性提示）	—	29.5 分钟（5 次都没调用 Subagent）

另外两组数据：

订阅直通省 Token：去掉直通后，完成时间基本不变，但 Router 决定数增加约 30%，读缓存 Token 从 2,323 万涨到 3,177 万，增加约 37%。
Router 越堵，单个决定越便宜：Trigger 到达速率从每分钟约 1 条升到约 40 条，平均 batch 从 1.0 升到 2.8，单次请求耗时只从 2.5 秒增到 3.9 秒，单个决定分摊的推理时间从 6.4 秒降到 1.6 秒。

团队自己也说明了局限：实验基于合成负载和简化环境，只作初步参考。Super-agent 要维护多个会话，读缓存 Token 本身就高于单会话方案。

实操：部署 dsh-superagent 原型

dsh-superagent 是一个 DeepSeek Harness 插件包。官方推荐让你自己的 Coding Agent 读 SETUP.md，一问一答地带你配置；下面是手动部署的主干步骤。

第 1 步：准备环境。

Node.js 22.19+ 或 24+、pnpm、git 2.32+、Python 3.8+、tmux
GitHub CLI 2.48+
一个 github.com 仓库（不支持 GitHub Enterprise Server）
一个专门给 Agent 用的 GitHub 账号，不要用自己的

第 2 步：安装 DeepSeek Harness 和插件。

npm install -g @deepseek-ai/dsh@0.2.1-rc.3
git clone https://github.com/deepseek-ai/dsh-superagent-prototype dsh-superagent && cd dsh-superagent
pnpm install && pnpm build
dsh superagent --from-default-profile web --dump-config > /dev/null
dsh plugin --profile superagent add "link:$PWD"

第 4 条命令会新建 ~/.dsh/profiles/superagent 配置。已有这个配置时不要再跑，它会覆盖并删掉原来的 cordis.patch.yml。

第 3 步：配置模型。 dsh-superagent 默认用 profile 的默认模型，Eval 和执行设置里也可以分别指定。在 DeepSeek Harness 的 Settings → Models 里可以填 DeepSeek API Key，也可以选 Custom model API，接任意 OpenAI 兼容网关：

Base URL 填网关地址，比如七牛云 Token Plan 的 https://api.qnaigc.com/v1。这个订阅的一个专用 Key 覆盖 DeepSeek、GLM、Kimi、MiniMax 等厂商的模型。
协议选 OpenAI Chat Completions。
模型 ID 以控制台显示为准。

按架构设计，Router 可以配轻量模型，Worker 配能力强的模型，分开设置能压低 Router 的成本。

第 4 步：机器配置与启动。 把 examples/profile.cordis.patch.yml 复制到 ~/.dsh/profiles/superagent/cordis.patch.yml，替换里面的占位符，stateDir 必须是绝对路径。然后：

scripts/dsh-superagent start
scripts/dsh-superagent status

面板默认跑在 127.0.0.1:3082，在里面配置 Sources（仓库和 Agent 账号）、Policy（允许谁提需求）和 Execution（工作目录）。

第 5 步：试一下。 用白名单里的账号，在仓库的 Issue 里评论 @<Agent 账号> <你的需求>。默认一分钟轮询一次，面板 Overview 里会出现一张工单，Agent 确认需求后开工，最后在原对话里交付。

部署前要想清楚的三件事

权限很大。Worker 和 Router 都以 danger-full-access 运行，用的是你的系统用户，能按路径执行程序、读你的主目录。官方建议用一个只放 Agent 凭据的独立系统账号来跑。
从窄处开始。默认的 accept 模式是 observe，主动发起的工作只记录、不执行。白名单先只放自己，看一段时间 Agent "本来会做什么"，觉得靠谱再放开。
自动合并先别开。SETUP.md 的推荐答案是"否"：等 Agent 的 PR 持续一段时间都没问题，再考虑让它自动合并。

常见问题

Q：Super-agent 和 Claude Code、Codex 这类 Coding Agent 有什么区别？ Claude Code、Codex 主要是人在终端或 IDE 里开一个会话交互使用。Super-agent 是常驻进程，从 GitHub、飞书等渠道接收事件，自己开会话、分派任务，人只在决策和验收时出现。它的 Worker 本身也可以是一个带 Subagent 的 Agent 会话。

Q：能直接用到生产项目里吗？ 官方明确不建议。README 写明这是"仅供参考的研究原型，不是 DeepSeek 正式产品"，代码大量由 Coding Agent 完成，可能有 Bug，和内部版本、技术文章描述的实现也不完全一致。适合在测试仓库里跑通、借鉴架构思路。

总结

DeepSeek Super-agent 把"维护全局连续性"和"并发执行"拆成 Router 与 Worker 两层，用事件订阅、上下文缓存化管理、存算分离和外部 Watchdog，让 Agent 从等人下指令的聊天窗口，变成持续在线、主动推进工作的协作者。初步实验显示，它用更多 Token 换来了更短、更稳定的任务完成时间。dsh-superagent 原型已经可以在单个 GitHub 仓库上跑通。本文信息基于 2026 年 11 月 1 日的仓库版本 0.1.0 和 DeepSeek Harness 团队的技术文章，项目处于早期，部署细节请以仓库 docs 最新说明为准。