DeepSeek 开源 Super-agent：让 AI 管理任务，把人的注意力留给决策

2026 年 10 月 31 日，DeepSeek Harness 团队做了一件事：公开了一套他们自己已经在内部跑了好几个月的东西——一个叫 dsh-superagent-prototype 的研究原型，以及配套的长文《Super-agent 设计探索：迈向更自主的 Agent 系统》。

这不是又一个 SWE-agent、又一个 Codex CLI 的替代品。它的目标从一开始就不一样：让 AI 持续承接工作，同时尽量少占用人的注意力。

如果你用过 Claude Code 的 sub-agent 或 OpenHands 之类的框架，可能会说：这不就是”多开几个并行任务”吗？

不完全是。DeepSeek 的观察是——

“单任务的上限取决于模型能力，多任务的上限取决于人的注意力。”

一个人通常只能同时跟进 3 到 5 个活跃 Session。你让 AI 帮你并行 10 个任务，最后不是 AI 累垮，是你盯着一堆终端窗口累垮。

dsh-superagent 的答案是：让 Session 从你眼前消失。

一、它到底是什么

先分清楚两份东西：

材料	内容	性质
GitHub 仓库 `deepseek-ai/dsh-superagent-prototype`	可运行的原型代码（MIT 许可）	研究原型，经过公开发布改编
技术长文	完整系统架构 + 设计理念	部分设计仍是未来方向，尚未在原型中落地

原型基于 DeepSeek Harness 插件框架运行，面向一个 GitHub 仓库，可接入 GitHub 和飞书。当团队里有人允许它干活时，它自己开一个工单、一个独立的 Agent Session、一个独立的工作目录，默默干完，然后在原对话里回复你，比如一个 Pull Request。

核心原则写在 docs/000-philosophy.md 里，一句话——

Take as little human attention as possible, and give as much value as possible.

每一条消息、每一个通知、每一个面板元素，都要付注意力成本。它存在的理由，必须大于它消耗的注意力，否则删掉。

二、核心架构：Router + Worker 双层

最值得关注的设计是两层分离。

┌─────────────────────────────────┐
│  Router（主会话，包工头）         │
│  - 轻量模型                        │
│  - 只看消息、派活、协调            │
│  - 不碰具体任务                    │
└──────────────┬──────────────────┘
               │ 分派工单
               ▼
┌─────────────────────────────────┐
│  Worker（执行会话，牛马）         │
│  - 最强模型                        │
│  - 一个工单 = 一个独立会话 + 目录  │
│  - 内部可再调子 Agent              │
│  - 干完只回复最终结果              │
└─────────────────────────────────┘

你面对的始终只有这一个 Router。它不干活，只派活。Worker 才是干活的——每个工单有自己的 Git worktree（同一仓库的另一份工作目录），互不干扰。

五个核心原语

原型把消息流和权限用五个概念组织起来：

原语	通俗解释
Source	消息来源（GitHub issue、PR 评论、飞书群）
Trigger	Source 发出来的一条不可变事件
Thread	同一条讨论里的 Trigger 按序排列
Mandate	工单获得的不可变授权（干什么、干多大）
Ticket	一张获准开工的工单，含输入、进展和交付状态

一个 Stateless Evaluator（无状态评估器）负责判断每个 Trigger 值不值得接单。它不保存任何中间状态，只拿一批 Trigger + 仓库策略 → 立刻判定。这样做的好处是：重启安全——挂了之后从 Git 历史和 Webhook 偏移量恢复读位置就行，没有待处理队列需要手动处理。

订阅不能越权

工单通过 Subscription（订阅）关联 Thread。一个 PR 的新评论、CI 构建完成，会直接 Fan-out（扇出）给 Worker。但这个扇出绕过 Evaluator 不等于能扩大权限——Mandate 一旦定死就不能变。如果有人在评论里提了超出范围的需求，Worker 不会自己加活，而是把它原样交还给 Router。

这和很多”自主增强”型 Agent 形成了鲜明对比。

三、主动性的三级开关

团队消息很多，真值得启动工作的只占一部分。原型提供了三种接单模式：

模式	对主动候选的处理
off	不接收推断出的工作机会
observe（默认）	评估候选，正面判断只记录”本来会接单”，实际不开工单
auto	匹配启用规则后允许自动接单

明确授权的请求（”帮我修这个 bug”）在这三种模式下都能执行。所以 observe 的”只读”只是针对主动接单的——不是整个系统完全只读。

这个设计非常适合逐步验证：先观察它会选哪些工作、误判率多少、再决定要不要扩大自主范围。

四、真实运行数据

DeepSeek Harness 的公开仓库关闭了 PR 功能，但有研究者按照原型规定的分支命名规则（工单 ID 前 12 位后缀）去查代码提交记录：

2026 年 9 月 14 日至 10 月 29 日，共合并了 99 个 PR
其中 10 月一个月就有 75 个
大多是小修小补（深色模式菜单间距、悬停提示不全、波浪号渲染成删除线……）
还有一个被同事回滚了——AI 牛马也逃不过被批

压力测试也有数字：Router 每分钟处理的消息从约 1 条涨到 40 条，积压消息合并成批处理后，单个决定分摊的推理时间从 6.4 秒降到了 1.6 秒。这个包工头越忙越快。

官方的模拟实验里，Super-agent 的任务完成时间中位数 12.4 分钟，p95 为 15.7 分钟。不过 DeepSeek 自己也说，这些数字主要评价的是调度与协作，不能直接推导真实编码质量。

五、优势与亮点

1. 注意力成本优先，而非模型能力优先

几乎所有 Agent 框架都在卷”你的 benchmark 跑了多少分”。dsh-superagent 反其道而行：它设计里的每一个元素——消息、通知、面板、文档——都要过一条筛：它花了多少注意力、换回了多少价值？ 花多换少的，直接删。

2. 无状态评估 + 不可变授权 = 安全

Evaluator 不保存中间状态，Mandate 一旦签发不可变。这两个设计组合起来，把”Agent 越界”的风险压到了最低。重启安全、越权防护、Worker 失控可回收。

3. 人说话的方式被重新定义

传统 Agent 是”我让你干什么、你就干什么”。dsh-superagent 是”我给你一个规则，你自己看哪些消息该处理”。规则可以用自然语言写（prompt 文本），不一定非要写成结构化 JSON 配置。

4. 投机执行（Speculative Execution）

对于推断出的主动候选，系统先在后台试试——有结果就交付，没结果就当没发生。不吵人、不占注意力、只有真正有价值的才浮出水面。

六、缺点与风险

1. Worker 以你的 OS 用户身份执行 Shell 命令

没有审批提示。这是研究原型的取舍——Agent 需要动手能力，审批提示会打断流程。但这也意味着，如果你给它错了权限，它可能在你的机器上干你没想到的事。

2. 不是生产就绪

仓库 README 开头就写了：”It may still contain bugs, and its coding style and engineering practices may be inconsistent.” 内部版本和公开原型不完全一样，部分设计还只是论文里的方向。别直接上生产。

3. 安装门槛不低

得自己装 Node.js、pnpm、DeepSeek Harness，还要配置 GitHub Token、飞书机器人和 Webhook。不像 Codex CLI 一个命令搞定，也不像 Claude Code 一键 npx。

4. 单仓库聚焦

原型主要围绕一个 GitHub 仓库工作。如果你的团队有 10 个仓库，要么每个仓库起一个 Super-agent 实例，要么等它多仓库支持（论文里有这个方向，但原型里没实现）。

5. 没有独立基准

DeepSeek 没有发布独立的 Agent 编码质量 benchmark。它的实验数据是内部模型、内部流程、内部代码库的数字。你看到的 12.4 分钟中位数，不能直接和 SWE-bench 的 80% 对比——完全是两件事。

七、竞品对比

维度	dsh-superagent	SWE-agent	OpenHands	Codex CLI	Cline	AutoGPT
定位	团队协作层	单任务编码	交互式终端 Agent	交互式终端 Agent	IDE 插件 + CLI	通用多任务
架构	Router-Worker 双层	ACI 壳 + 单 Worker	Sandbox 里的 Agent	单会话多工具	单会话 + sub-agent	目标分解 + 执行循环
多任务	原生并行，独立 Session + 目录	单任务	单会话多步	手动多窗口	支持 sub-agent	自动但易”脱轨”
权限模型	不可变 Mandate + 订阅	ACI 命令集约束	Sandbox + 用户审批	用户审批 Shell	用户审批 Shell	无硬约束
主动工作	observe/auto 三级，投机执行	只能被动接 issue	被动接指令	被动接指令	被动接指令	永远主动
开源	MIT	MIT	Apache 2.0	CLI Apache 2.0	Apache 2.0	MIT
模型	随 DeepSeek Harness 换	任何 LLM	任何 LLM	只 OpenAI	任何 LLM（自己配 key）	任何 LLM
生产就绪	❌ 研究原型	⚠️ 工具链	⚠️ 可用但不稳	✅ 成熟	✅ 成熟	❌ 易跑飞
注意力成本	极低（核心理念）	中	高（要盯）	中	中	极高
SWE-bench Verified	未发布	~30%（原版）	~48%（Claude 3.7）	96.2%（GPT-6 Sol）	~70%（Opus 4）	极低

几个关键差异

dsh-superagent vs SWE-agent / OpenHands：后两者是单任务编码能力的天花板提升者，dsh-superagent 是多任务协调层。它们解决的不是同一个问题——前者解决”AI 能不能修好这个 bug”，后者解决”团队 10 个 bug 怎么让 AI 同时盯”。

dsh-superagent vs AutoGPT：AutoGPT 是”永远不停的循环”，容易脱轨、容易浪费 token。dsh-superagent 的 observe 模式和不可变 Mandate 把”自主”关进了笼子里——默认被动，主动要开三级开关。

dsh-superagent vs Codex CLI / Cline：后两者的用户管理着 Session 窗口。dsh-superagent 让 Session 消失在后台。你面对的始终只有一个 Router。

八、什么时候用？

适合的场景：

中型以上研发团队：人太多、Session 管不过来、团队有统一的 GitHub + 飞书
重复性修复任务密集：比如每天来一堆 issue、CI 天天挂、Code Review 改不完
对注意力成本敏感：不想每次都手动开 Agent、不想听它”正在努力”
愿意先 observe 再 auto：团队对”AI 越权”持谨慎态度

不适合的场景：

小团队或个人开发者：手动管理 3-5 个 Session 没问题，用 Codex CLI 或 Cline 更直接
需要跨仓库协作：原型只聚焦一个仓库，多仓库还得自己想办法
对 Shell 执行权限零信任：Worker 无审批跑 Shell，这个取舍你接受不了就不能用
追求 SWE-bench 分数：它不是跑 benchmark 用的，别拿它和 Codex CLI 比分

九、使用注意事项

从 observe 模式起步：跑一段时间看它会选什么任务、误判率多少、哪些任务本来不该它插手。验证好了再开 auto。
先配短名单：把 allowed list 控制在小范围内。别一上来让整个群的所有人都能使唤它。
定期 Review 它的 prompt：它发出去的每一条消息、每一个 PR、每一次飞书回复，都是在用你的账号说话。定期纠正它的 prompt。
Worker 以你的 OS 用户运行：重要的机器上别用，或者单独开一台 VM。
别指望秒跑 benchmark：这是研究原型，不是生产框架。遇到 bug 是正常的。
DeepSeek V4 Pro 涨价了：高峰时段 27 元/百万 token，空闲时段 13.5 元。Router 用轻量模型、Worker 用强模型是省钱的关键。

十、结论

dsh-superagent 最值得关注的，不是它跑了多少个 PR、不是它的 SWE-bench 分数——是它提出了一个反直觉的衡量指标：Agent 让人多做了多少协调、纠错和确认。

节省执行时间，只有最终转化为节省人的时间，才真正有价值。

它没有发明新模型，没有刷新 benchmark，没有把 SWE-bench 分数从 80% 推到 90%。但它提出了一个问题：当模型越来越强，拖后腿的是不是我们自己？ 一个人能跟进 3-5 个 Session，模型再多能干的事，也会被这三五个窗口上限卡死。

Router-Worker 双层架构、注意力成本优先、无状态评估、不可变 Mandate、投机执行——这些设计组合在一起，勾勒出一种新的 Agent 使用方式：你不再手动管理每个 Session，而是给 Agent 写规则、设边界、观察它的判断、再慢慢放开。

它不是终点——原型里写得明白，很多设计还没落地。但它展示了一个方向：多任务的上限，不取决于模型能力，取决于你能接受让 AI 代替你承担多少”协调成本”。