DeepSeek Super-agent 测评：Router/Worker 双层架构、p95 15.7 分钟实验数据与 dsh-superagent 原型实测

先说结论：DeepSeek Super-agent 不是新模型，也不是一款可以直接订阅的产品。 它是 DeepSeek Harness 团队在 2026 年 10 月 31 日公布的一套 Agent 系统架构，同一天在 GitHub 开源了配套的研究原型 dsh-superagent（MIT 协议）。原型能盯住一个 GitHub 仓库（可选再接飞书群），有人 @ 它提需求，它就开工单、在独立会话里干活，最后在原对话里交付，比如提一个 Pull Request。

需要注意两点：官方明确说原型仅供研究参考，不是 DeepSeek 正式产品，和内部版本、文章描述的实现也不完全一样；官方实验用的是合成负载，测的是调度能力，不是写代码的能力。第三方实测也印证了这一点：设计思路被普遍认可，但安装和容错还很粗糙，本机管理接口还有未修复的安全问题。适合拿来学架构、在测试仓库里试，不适合直接接进生产仓库。

2026-11-01 更新：补充完整的官方实验表，新增「第三方实测」和「常见问题与踩坑」两节，汇总 LaoZhang AI Blog、GitHub 社区的三份安装报告（其中一份从 Issue 跑到了 PR）和一份独立安全审计，并据此更新了优缺点和适用场景。官方数据和第三方数据分开列出。

本文信息截至 2026-11-01，依据 DeepSeek Harness 团队的官方长文、GitHub 仓库和仓库内文档，以及下文列出的第三方报道和实测。

Super-agent 是什么

官方长文《Super-agent 设计探索：迈向更自主的 Agent 系统》的说法：

这是一篇面向工程实践的架构思路探讨，并非对 DeepSeek Harness 现有产品功能的介绍
要解决的问题：现在的 Agent 以单个 Session 为单位，并行推进多项工作时要手动切换、记住每个 Session 的上下文。官方观察到一个人通常只能同时跟进 3 到 5 个活跃 Session
Super-agent 的四个特征：连续（IM、GitHub 评论等多个入口感觉是同一个 Agent）、高效（并行做多个任务，不用等上一个做完）、主动（观察环境事件，主动推进值得做的事，不需要时保持安静）、持久（一直在线，出错能自动恢复）
内部基于 DeepSeek Harness 的 Super-agent 实例已经在持续运行，日常参与问题复现与修复、代码审查响应和 DeepSeek Harness 自身的迭代。官方举的例子是：它会观察公共群聊，在没人 @ 它的情况下主动定位根因并提交修复 PR。开源原型默认不会这样做，主动接活默认是只记录不执行的 observe 模式

时间线：

2026-10-31 20:05（UTC+8）：GitHub 仓库 deepseek-ai/dsh-superagent-prototype 第一次提交，版本 0.1.0。截至 2026-11-01 23:00（UTC+8）仍只有这一次提交（6337fc8），仓库没有开放 Issues 和 PR，社区反馈集中在 DeepSeek Harness 主仓库的 Discussions
2026-10-31 晚间：官方公众号发布长文，IT之家 21:36 跟进报道
2026-10-31 至 11-01：社区陆续出现安装报告、缺陷报告和安全审计，详见下文「第三方实测」

五个核心模块

官方把架构拆成五块，下面是简化说明：

模块	做什么
双层架构	常驻的 Router 负责接收所有人类消息、维护全局上下文、分派任务，自己不执行具体工作（甚至可以不给 Bash 工具），可以用轻量模型；多个上下文隔离的 Worker 并发执行任务，通常配能力最强的模型，Worker 不直接回复用户，向 Router 汇报
事件驱动	群聊消息、邮件、代码审查评论、CI 结果都叫 Trigger。先用程序规则过滤（快路径），再交给模型判断（慢路径）。Worker 订阅自己负责的 Thread，后续事件直接发给它，不再经过 Router
面向人的交互	异步 ReAct Loop：耗时工具改成 start() / stop()，启动后立刻返回，后台跑的同时还能接新消息。按信道调整输出密度，IM 里单次回复不超过 100 词，GitHub 和邮件里写完整的结构化说明
计算、状态与环境分离	Agent Loop 的计算放云端无状态容器，会话状态存数据库，执行环境留在用户本地，只装一个轻量 daemon，支持 BYOM（接入自己的开发机）
Watchdog	主系统外再挂一个独立的 Watchdog Session，定时检查每个 Worker 有没有实质进展、方向有没有跑偏，发现问题就介入

另外还有几个机制：Inline & Spill（把上下文窗口当缓存管，常用信息直接放进去，长内容截断后留续读入口）、链式召回（沿着 Trigger、Thread、Worker Session 的 ID 一跳一跳找回旧任务）、投机执行（在群里还在讨论问题时，先在后台尝试复现和修复，确认有简单修法才说话，否则保持安静）。

官方特别说明：异步任务机制已在 DeepSeek Harness 中实现，但尚未默认开启。

如果想看这些模块的动画演示，公众号「赛博禅心」的《动态图解：DeepSeek 的 Super-agent 架构》把官方长文逐段做成了动态图解，适合配合原文阅读。它是图解而不是实测，没有新的测试数据。

价格

Super-agent 没有单独的价格：

原型 dsh-superagent 是 MIT 协议开源，免费使用
DeepSeek Harness 本身也是开源的，官网写的是全球公开预览
真正花钱的是模型调用。原型默认用 DeepSeek Harness 配置里的默认模型（Web 模板默认是 deepseek-flash），费用按你接的模型 API 计
官方实验里，Super-agent 一次实验的读缓存 token 是 2323 万，单 Session 中性提示方案只有 605 万，约为后者的 3.8 倍。它是用更多 token 换更短、更稳的完成时间，按量计费时要把这一点算进去
目前没有任何公开数据说明一张真实工单要花多少钱

官方实验数据

以下全部是 DeepSeek 自己的初步实验，官方原话是“基于合成负载与简化环境，部分设置还可以更加严谨，仅作为初步参考”。

端到端对比

设置：用群聊和 GitHub CI 消息流驱动，每次约 300 条消息，其中约 20 条是工作请求，其余是闲聊、跟进、叫停和 CI 消息。编码工作用一个只消耗时间的工具代替，每种方案跑 5 次。任务完成时间指从工作请求到结果消息的耗时。官方完成曲线图的图注说明，消息间隔与工作时长按 1/4 缩放，模型调用耗时为真实值。

完整结果如下（官方长文里这张表是图片，我们按原图逐格核对过）：

方案	任务完成时间 P50 / P95（分钟）	单次实验读缓存 token（全部 Session）
Super-agent	12.4 / 15.7	2323 万
Super-agent，去掉订阅直通	12.6 / 15.5	3177 万
单 Session + Subagent 工具，中性提示	20.4 / 29.5	605 万
单 Session + Subagent 工具，提示优先委派	13.8 / 29.0	1082 万

几个要点：

中性提示下，模型 5 次运行一次都没有调用 Subagent，所有工作都在主 Session 里做，还不断被新消息打断，所以 p50 和 p95 都最慢
提示优先委派后，5 次里有 4 次委派，p50 降到 13.8 分钟，接近 Super-agent；但剩下 1 次模型判断工作“很小”自己做了，p95 仍是 29.0 分钟，形成长尾
去掉订阅直通，完成时间和完整版基本一致，但 Router 要做的决定多了约 30%，读缓存 token 增加约 37%
Super-agent 赢在稳定，p95 只比 p50 多 3.3 分钟；代价是读缓存 token 最多

官方的结论是：靠提示词让单个 Session 自己决定“分不分工”不稳定，双层架构在系统层面把这件事固定下来了。直通机制不提速，但能省 Router 的 token。

Router 批处理压测

设置：Router 用真实模型，Worker 用 Mock 模型，Trigger 到达速率从每分钟约 1 条提高到约 40 条。

指标	每分钟约 1 条	每分钟约 40 条
平均 batch 大小	1.0	2.8
单次请求耗时	2.5 秒	3.9 秒
单个决定分摊的推理时间	6.4 秒	1.6 秒

意思是消息越堵，Router 越会把积压的事件合并成一次调用处理，单个决定反而更便宜。官方据此认为，在他们目前的团队规模下，单个 Router 够用，不需要过早拆分。

官方没有公布用的是哪个模型，也没有 SWE-bench 这类编码基准。这不是一个模型，所以 Artificial Analysis、LMArena、OpenRouter 上也没有对应的榜单。

我们的实测

2026-11-01 我们在一台 x86_64、8 核的 Linux 机器上（Node.js 24.22.1、pnpm 11.7.0）拉取了仓库（commit 6337fc8），做了离线检查：

pnpm install --frozen-lockfile 能正常装完，依赖的 @deepseek-ai/dsh-* 预发布包（0.2.1-alpha.2）都能从 npm 拉到
pnpm check（类型检查 + 测试 + 构建）全部通过：59 个测试文件、1197 项测试全部通过，vitest 报告耗时 10.58 秒，构建成功
补充核对（11-01 更新）：在同一台机器的 Node.js 24.22.1 上，ps 把 Node 主进程的 ucomm 显示为 MainThread 而不是 node，和下文 GitHub 讨论 #11700 报告的 Node 24 进程名问题一致；而仓库里的服务脚本正是按 ucomm 找进程的
补充核对（11-01 更新）：对照 6337fc8 的源码，安全审计指出的管理 API 校验函数 sameOrigin 确实只检查 Host、一个固定请求头 x-orchestrator-request: 1 和可选的 Origin，这个请求头在官方部署文档里是公开写明的。审计的 PoC 仓库未公开，我们没有复现攻击本身

我们没有接入真实的 GitHub 账号和模型去跑完整工单，所以上面只能说明代码能装、能测、能构建，不代表它干活的质量。真实工单的情况见下一节的社区报告。

第三方实测

下面只收录有实际操作的报告，按测试深度排列。环境、版本各不相同，都是个人或媒体的结果，不是官方数据。

GitHub 讨论 #11706：从 Issue 跑到 PR，但通知可能“静默收不到”

xxxxkkkqq 在 DeepSeek Harness 仓库的讨论（11-01）。环境：Ubuntu、Node.js 24.14.0、dsh 0.2.1-rc.5、gh 2.103.3，按 SETUP.md 从全新 clone 安装，接一个私有仓库，把一个 Issue 里的请求一直做到了 Pull Request。这是目前能找到的唯一一份公开的端到端报告。踩到的问题：

通知收不到却显示正常：在 Issue 里 @ 机器人账号后没有生成工单，GitHub 来源一直是 ready，详情写着“0 notifications”，部署检查也全部通过。原因没有完全查清，但 gh auth login 默认不申请 notifications 权限，补了权限、订阅了仓库后机器人的通知列表仍然是空的。最后的绕法是在来源里打开 observeIssues 和 observeComments，让它直接读仓库
中文系统下测试会挂一项：LANG=zh_CN.UTF-8 时 1196 项通过、1 项失败（tests/environment.spec.ts），因为断言匹配的是 git 的英文报错，而 git 会按系统语言翻译报错。加 LC_ALL=C 即可
多个 gh 配置目录可能串号：按文档给机器人建单独的 GH_CONFIG_DIR 后，系统自带的旧版 gh 2.45.0 用的是共享钥匙串，结果操作者自己的 git 也开始以机器人身份认证，访问不了自己的私有仓库
作者也确认遇到了 #11700 里的 Node 24 进程名问题

GitHub 讨论 #11700：第一个小时就碰到两个缺陷

mikel38487 的讨论（10-31）。环境：WSL2 下的 Ubuntu 26.04、Node.js 24.22.2、dsh 0.2.1-rc.5、GitHub CLI 2.103，接真实仓库。两个缺陷都给了修复和回归测试，修复后 pnpm vitest run 59 个文件、1200 项测试通过：

Node 24 下服务脚本找不到自己的进程：Node 24 把主线程命名为 MainThread，ps 的进程名不再是 node。结果服务明明在跑，status 却返回空进程列表和 exit 1，start 等满 60 秒报超时，stop 也停不掉
GitHub 通知来得晚，评论会永久丢失：通知的时间窗口和线程游标配合有问题，晚到的 @ 评论被丢掉后再也不会被读到。作者在真实仓库上复现了两次
这份报告也说明，Windows 用户在 WSL2 里可以跑起来

GitHub 讨论 #11714：装了一整夜，“思路很喜欢，安装很反感”

maxonxie 的讨论（11-01）。环境：macOS 26.6.2 arm64、Node v24.19.0、pnpm 12.11.2、gh 2.98.0、tmux 3.7c。有意思的是，这篇是操作者让 DSH 自己（模型 deepseek-flash）在同一个会话里排障、复现并写成的。主要发现：

一个插件不兼容，整个 DSH 起不来：Web 界面、插件树和 webserver 在同一个进程里，插件版本对不上时端口直接不监听，浏览器连不上，作者只能用别家的 Agent 读日志、删插件修复。其实 dsh --help 里有救援命令：dsh rescue --from-default-profile web、dsh plugin --profile superagent remove dsh-superagent、dsh --dump-config，但部署文档没写
包名撞车：npm i -g dsh 装到的是 2016 年一个无关的 JS shell，正确的包是 @deepseek-ai/dsh
DSH 版本太旧只报“Failed to load plugins”：作者本机原来是 0.1.5-rc.1，插件要求 ^0.2.1-alpha.2，报错里不会告诉你该装哪个版本
原生模块安装脚本被跳过：npm 提示 5 个包（包括 node-pty、koffi）的 install script 没有执行，装完看起来正常，用一会儿就挂
面板访问要 token：直接访问 127.0.0.1:3082 返回 401，带 token 的地址只出现在 .artifacts/ 下的滚动日志里
没有专用 GitHub 账号就一直停在 exit 3，没法先“只看看界面”
作者认可的地方：status 的 0/1/2/3 退出码设计、默认 observe 加白名单的保守策略、分篇递进的文档

LaoZhang AI Blog：macOS 上实测到“等待配置”

《DeepSeek Super Agent GitHub 部署教程：首次启动 exit 3 是正常的》（11-01）。环境：Apple 芯片 macOS、Node 24.11.0、DSH 0.2.1-rc.3。实测停在建机器人账号之前，没有派真实工单：

装 DSH 和 pnpm 约 1 分钟，pnpm install 5.9 秒，pnpm check 同样是 59 个文件、1197 项测试通过；Node 24 会刷很多行 ExperimentalWarning: SQLite，不影响结果
第一次 start 返回 exit 3 和 repositoryUnset（GitHub 来源没有设置仓库），这是服务已经起来、在等配置，不是装失败
实测了几种报错原文：没写 stateDir 时 start 约 1 分钟后超时、exit 1、面板跑在 3080 而不是 3082；CLI 路径不对时报 agentCliMissing；机器人账号没登录时报 agentCliSignedOut；少了请求头时管理 API 返回 403
面板跟随浏览器语言显示中文，概览页会直接列出“部署检查未通过”和“名单为空”两条待办

独立安全审计：一个公开请求头就能改管理设置

《一条公开请求头 = 管理员权限：dsh-superagent 安全审计实录》（CTF导航转载，11-01）。作者对 commit 6337fc8 做了源码审计，报告两个可复现问题，PoC 测试 2 个文件、4 项测试通过，原有 1197 项测试不受影响：

高危：本机管理 API 没有真正的认证。只要能连 127.0.0.1 的进程带上公开的 x-orchestrator-request: 1 请求头，就会被当成面板操作，可以改 GitHub CLI 路径、执行前的 prepare 命令和授权名单；保存 GitHub 设置时服务会立刻执行新填的 CLI。公网不能直接访问，打的是本机信任边界，比如共享主机上的其他用户，或者被提示词注入后能跑 shell 的 Agent
中危：被拒绝的消息可以“借”别人的授权。同一批次里既有白名单成员的请求、又有被拒绝的消息时，工单授权取批次里最强的那个人，评估器只要接受被拒那条，就会以白名单成员的名义开单
外部风险：订阅线程上的消息会作为上下文送进以 danger-full-access 运行的 Worker。公开仓库里任何能评论的人都能往里写内容，提示词注入后再调用本机管理 API 就能持久化
作者的 PoC 仓库目前是私有的，截至发稿上游未修复。我们核对了源码中的校验逻辑（见上文），没有复现攻击

其他实测和反馈（首发版已收录）

离线工程练习：mushroom.cv 在 Apple M4 上跑了上游完整 pnpm check，同样是 59 个测试文件、1197 项测试通过；又基于上游真实的 Engine、SQLite Store 写了 7 个场景（事件重放去重、未授权用户不产生工单、数据库重开后继续派工、事务回滚等），全部通过。作者也提醒，没有连接真实模型和 GitHub，没有验证真实的进程取消、沙箱和提示词注入防护
部署指南：七牛云整理了手动部署步骤，并提醒三件事：权限很大、先从窄处开始、别开自动合并
“能直接用来干活了吗”：什么值得买的文章结论是“能干，但还不能直接用”。提到有开发者安装时要开 WSL、对齐 dsh 版本、补必填的 stateDir 配置，也有人反映依赖的预发布包装不下来。文章还引用了一条评论：省的是调度，不是本事
社区解读：X 上有开发者把它类比成 Slack 里能 @ 的 Claude，例子主要是“飞书群聊 ↔ GitHub”之间持续推进任务（@lijiankuan）

小结：几份报告的共识是设计值得学、安装和容错还没准备好。能装、能过测试、能起服务这几步大家都复现了；真正接仓库派活时，通知链路、Node 24 兼容和版本对齐是最常见的卡点；安全上，本机管理接口和公开仓库的提示词注入是部署前必须想清楚的两件事。

常见问题与踩坑

按出现的先后顺序整理，来源见上一节：

装错包：用 npm install -g @deepseek-ai/dsh@0.2.1-rc.3，不要 npm i -g dsh。插件要求 DSH 落在 ^0.2.1-alpha.2 区间；LaoZhang 按 11-01 的 npm 标签核算，latest 指向的 0.2.1-rc.5 在区间内，@alpha 标签的 0.2.2-alpha.2 不在
npm 跳过原生模块脚本：看到 allow-scripts 警告时，要按提示允许这些脚本重新安装，否则 subprocess 和 pty 组件缺失
第一次启动 exit 3 是正常的：意思是服务在跑、等你配置仓库和名单。exit 0 正常运行，1 是没在跑或运行时报错，2 是某个部件报错，3 是等配置，2 和 3 重启都没用
stateDir 必须填绝对路径：不写会超时退出；超时后进程可能还留着，先 scripts/dsh-superagent stop 再改配置
建 profile 的命令只能用一次：dsh superagent --from-default-profile web 在 profile 已存在时会整个替换并删掉 cordis.patch.yml，升级时千万别再跑
Node 24 下 status 显示没在跑：这是 #11700 报告的进程名问题。官方还没修，作者在自己的 fork 分支里给了补丁可以参考
@ 了没反应：先查发起人在不在名单里、来源有没有开、是不是编辑 Issue 正文补的 @（必须发新评论）。如果来源显示 ready 却一直是 0 条通知，检查机器人账号的 notifications 权限，或者像 #11706 那样打开 observeIssues 和 observeComments
中文系统跑测试挂一项：加 LC_ALL=C 再跑
插件装坏导致 DSH 整个起不来：先试 dsh rescue --from-default-profile web 和 dsh plugin --profile superagent remove dsh-superagent
面板 401：去 .artifacts/ 下最新的日志里找带 token 的地址
gh 串号：给机器人单独建 GH_CONFIG_DIR 后，确认 ~/.gitconfig 里的 credential helper 指向的是你平时用的那个 gh
Windows：服务脚本依赖 fcntl 和 tmux，原生 Windows 跑不了，用 WSL2
升级前备份数据库：新版迁移过的 orchestrator.sqlite 旧版打不开，回滚只能靠备份

优点、缺点和适合谁

优点：

思路清楚、可借鉴：把调度、缓存、存算分离、看门狗这些计算机系统里的老办法用到 Agent 上，长文和仓库文档写得很细
省人的注意力：默认只在被请求或团队规则允许时才行动，只在需要人决策或有结果时才说话
有真实数据：虽然是合成负载，但给了三组对照和每组的 token 开销，不只是概念
运维接口设计得好：status 的 0/1/2/3 退出码和结构化输出、默认 observe 加白名单，被第三方测试者专门点名表扬
能跑通：社区已有从 Issue 做到 PR 的报告；多位测试者在 macOS、Linux 上都复现了 59 个文件、1197 项测试通过
开源、MIT 协议

缺点：

不是正式产品，官方自己说可能有 bug，代码大量由 Coding Agent 写成，风格不统一；文章里的部分设计还没在原型中实现
安装和容错很脆：DSH 版本、原生模块、Node 24 进程名、通知权限都可能让它“看起来正常但不干活”，插件出错还可能让整个 DSH 起不来
有未修复的安全问题：独立审计报告本机管理 API 只靠公开请求头校验，以及批次授权可被借用两个问题，截至 11-01 上游未修复
权限很大：官方部署文档写明，Worker 和 Router 都以 danger-full-access 在你的系统用户下运行，能按路径执行程序、读你的主目录。官方建议用一个只放 Agent 凭据的独立系统账号来跑
门槛高：要 Node.js 22.19+ 或 24+、pnpm、git 2.32+、tmux、Python 3.8+、GitHub CLI 2.48+，还要单独的 GitHub 用户账号；只支持 github.com，不支持 GitHub Enterprise Server
费 token：官方实验里读缓存 token 约为单 Session 中性提示方案的 3.8 倍
安全问题没解决：官方自己列出的开放问题包括提示词注入、端侧凭据泄露和跨设备权限风险

适合：

想研究“常驻、多任务、事件驱动”Agent 架构的开发者和团队
想给私有测试仓库配一个“值班 Agent”，愿意自己排障、fork 改造的人

不适合：

想要开箱即用的产品的人
接到生产仓库，或者装在存有敏感凭据的主力机器、多人共用的主机上
接公开仓库或大群：任何能评论的人都能把内容送进全权限 Worker

怎么用

Super-agent 不是 API 模型，没有模型 id，AI Code With 上不会有一个叫 Super-agent 的模型。能用的是开源原型 dsh-superagent，它是 DeepSeek Harness 的一个插件包。

官方推荐的方式是让你自己的 Coding Agent 读仓库里的 SETUP.md，一问一答地带你配置。手动部署的主干步骤（来自官方 docs/006-deployment.md）：

1. 准备环境：上面列的 Node.js、pnpm、git、tmux、Python、GitHub CLI，一个 github.com 仓库，一个专门给 Agent 用的 GitHub 用户账号（不能用 GitHub App）

2. 安装 DeepSeek Harness 和插件：npm install -g @deepseek-ai/dsh@0.2.1-rc.3，克隆仓库后 pnpm install && pnpm build，再运行 dsh superagent --from-default-profile web --dump-config > /dev/null 创建 profile，最后 dsh plugin --profile superagent add "link:$PWD" 装上插件

3. 机器配置：把 examples/profile.cordis.patch.yml 复制到 ~/.dsh/profiles/superagent/cordis.patch.yml，stateDir 必须填绝对路径

4. 启动：scripts/dsh-superagent start，用 scripts/dsh-superagent status 看状态，第一次返回 exit 3 属于正常；面板默认在 127.0.0.1:3082，带 token 的地址在 .artifacts/ 的日志里

5. 在面板里配置 Sources（仓库和 Agent 账号的 CLI 路径）、Policy（谁可以派活）、Execution（工作目录和准备命令）

6. 试用：用白名单里的账号在 Issue 里发一条新评论 @Agent账号你的需求，默认一分钟轮询一次，面板里会出现工单

几个默认设置值得保留：主动发起的工作默认是 observe 模式（只记录“本来会做”，不执行）；白名单先只放自己；SETUP.md 推荐不开自动合并。结合安全审计，建议再加两条：用独立系统账号运行，不要接公开仓库。

模型方面，原型默认用 DeepSeek Harness 当前 profile 的默认模型，也可以在 Eval 和 Execution 设置里分别指定。官方长文建议 Router 用轻量模型、Worker 用能力最强的模型。

AI Code With 目前提供 DeepSeek V4.1 Flash，模型 id 是 deepseek-flash，详情见模型页。把它接进 DeepSeek Harness 的配置我们还在验证，跑通后会在这里补充完整示例。第三方 API 的通用配置方式可以先看《Claude Code 接入第三方 API：Base URL、API Key 与模型配置》。

常见问题

DeepSeek Super-agent 是新模型吗？

不是。它是一套 Agent 系统架构，加一个开源的研究原型。DeepSeek 这次没有发布新的 API 模型。

能直接用在生产项目里吗？

官方不建议。README 写明这是“仅供参考的研究原型，不是 DeepSeek 正式产品”，可能有 bug；第三方还报告了未修复的安全问题。建议在私有测试仓库、独立系统账号里试。

有人真的用它提过 PR 吗？

有。GitHub 讨论 #11706 的作者在 Ubuntu 上接私有仓库，把一个 Issue 里的请求做到了 PR，但中途遇到通知收不到的问题，靠打开 observeIssues 和 observeComments 绕过。目前没有公开数据说明它的 PR 质量或单张工单成本。

第一次启动返回 exit 3，是装失败了吗？

不是。exit 3 表示服务已经在跑、在等配置，通常是还没设置要监听的仓库。按面板提示补仓库、机器人账号和名单即可。

Windows 能用吗？

原生 Windows 不行，服务脚本依赖 fcntl 和 tmux。有测试者在 WSL2 的 Ubuntu 里跑通了。

收费吗？

原型和 DeepSeek Harness 都是开源的，不收费。费用来自你接的模型 API，多会话架构会比单会话消耗更多读缓存 token。

官方实验能说明它写代码更强吗？

不能。实验里的编码工作被一个只消耗时间的工具代替了，衡量的是调度和协作，不是单个任务的完成质量。

支持飞书以外的 IM 吗？

原型目前支持 GitHub，可选接入飞书。官方 docs/008-cookbook.md 说明了怎么自己添加新的 Source。

来源（核对于 2026-11-01，11-01 晚间更新）

官方：

第三方实测（11-01 更新新增）：

报道和其他实测：

DeepSeek Super-agent 是什么？架构、官方实验数据与 dsh-superagent 原型实测测评