dsh-superagent 深挖报告

DeepSeek Harness 团队开源的「主动式编码 Agent」原型：仓库实情、Router / Worker 架构、那组 p50 12.4 分钟数字到底测了什么，以及它和营销叙事之间的距离。

一句话结论

dsh-superagent 是 DeepSeek Harness 团队于 2026-10-31 以 MIT 协议发布在 deepseek-ai 官方组织下的研究原型（deepseek-ai/dsh-superagent-prototype，单提交、v0.1.0），本质是为单个 GitHub 仓库打包的 DeepSeek Harness（dsh）Cordis bundle：常驻 Router 会话做事件判断与分发，Ticket 制的相互隔离 Worker 会话负责执行。p50 12.4 分钟 / p95 15.7 分钟来自 DeepSeek 自报的合成负载仿真——测的是调度，不是代码质量——无任何独立验证或社区复现。

仓库关键数据

以上数字为 2026-11-01 12:06 UTC 直读 GitHub 仓库页核实（verified live）；仓库创建于 2026-10-31T09:32:46Z，许可证 MIT。文中标注「verified live」的条目均为调研时直读一手页面，「index」为经索引/二手来源转述，见文末来源清单。

一、仓库、发布者与许可证

• 实际仓库：deepseek-ai/dsh-superagent-prototype
• 发布者：DeepSeek Harness 团队，经 DeepSeek 官方 GitHub 组织 deepseek-ai 发布；同步在 DeepSeek 官方微信公众号（产品部）于 2026-10-31 北京时间晚间发布设计长文《Super-agent 设计探索：走向更自主的 Agent 系统》（Exploring Super-agent Design: Towards a More Autonomous Agent System）
• 创建时间：2026-10-31T09:32:46Z（verified live）
• 许可证：MIT——仓库页 License 栏标明 MIT License，根目录有 LICENSE 文件，README License 节指向 MIT
• 版本状态：1 个 commit（"add the dsh-superagent research prototype"），无 release、无 tag

Star 增长：24 小时内从 2 千到 5 千

四个采样点均为直读 GitHub 仓库页的记录（UTC）。增速本身说明：讨论热度跑在验证前面——同期仓库只有 1 个 commit、0 个 issue。

"Research prototype for reference only, not an official DeepSeek product"

—— README 首行定性声明（verified live）。同时说明：代码生长于团队日常开发、大量工程由 coding agents 完成；已为发布做适配，与内部版本及设计文章描述的实现不完全一致；文章中部分设计是未来方向，未在此原型中实现。

二、架构：Router 判断，Worker 执行

核心是一条事件驱动的流水线：Source → Trigger → Eval → Ticket → Worker。Router 只做判断和分发，不碰具体任务；干活的是每个 Ticket 一个的隔离 Worker 会话。

• Source（事件源）：GitHub——默认每分钟轮询仓库——agent 账号通知、订阅的 Issue/PR、CI 变化、PR 合并/关闭；可选监听全部新 Issue/PR/评论与默认分支 CI。Feishu——配置群聊的 live events + 历史恢复 + 订阅 topic 轮询。
• Trigger（触发）：Source 产生的原始事件，进入对应 Thread 等待研判；同一 Thread 上一轮推理期间到达的 Trigger 会累积，批量合并进下一轮 LLM 调用。
• Router / Eval（常驻主会话）：常驻的 DeepSeek Harness 主会话（代码/提示词中称 orchestrator），运行精简工具集的 dsh-superagent-router preset，维护全局上下文、处理人与 agent 的全部交互。不直接执行具体任务——设计文章称甚至可以不配 Bash 工具，因此可用较轻的模型兼顾速度与效果。
• Ticket（授权工作单元）：只有 Eval 能创建。持有不可变的 Mandate、Channels（回复地址）、Inputs、Assignments、Subscriptions。生命周期 open → ended；人类在同一 Thread 的新消息可按同一 Mandate 恢复（resumed）。
• Worker（Executor Session）：每个 Ticket 一个会话（命名 worker-<ticket id>）+ 一个以 Ticket 短名命名的独立工作目录。不直接与人交互，状态经引擎上报 Router 统一回复。

Eval 的两层判断：先代码，后模型

• Gate（准入，确定性快路径）：代码实现的硬性规则——事件来源、群范围、用户/bot 白名单（allowed list）、不同 Source 的接单模式（"只响应明确请求" / "作为候选" / "直接忽略"）。
• Assessment（研判，慢路径）：LLM 基于策略提示词做语义判断，决定是否需要行动。
• 批处理（batching）：一个 Thread 上同一时间只运行一个 Eval；等待期间到达的事件合并进下一轮调用。事件越密，单次决策的推理成本越低。
• 决策结果四种：accept（创建 Ticket + Mandate）/ stop / ignore / unavailable。

Mandate：不可变的授权凭据

Ticket 的授权来自 Mandate——一份不可变的记录，包含：Policy 版本、scope、strength（explicit 明确 / inferred 推断）、命中的规则、发送者在该 Source 的身份、Trigger 如何到达。「谁授权、授权做什么、依据哪条规则」被写成可版本化、可审计的数据，而不是藏在提示词里。Assignment 则是 Ticket 绑定到某次 Executor 执行的记录（pending → running → ended）。

Router ↔ Worker 通信

• Worker 状态经 Report（progress / waiting / ready / blocked / failed / dropped）上报引擎，由 reportRelay 转发给 Router，Router 统一对人回复。
• 交付给 Worker 的 Inputs 经 DeepSeek Harness 的 inbox 在其下一步注入。
• 订阅直达（Subscription direct pass）：同一 Thread 下的后续事件由程序直接送给已订阅的 Worker，不再经过 Router——这是省 Router token 的关键快路径；Router 仍可见全部事件做全局判断。
• Worker 之间通常不直接通信；多个 Worker 订阅同一 Thread 时可各自看到事件、自行发现冲突，跨任务协作由 Router 协调。

Worker 隔离：是 Session + 目录，不是沙箱

• 不是容器/VM：每个 Ticket 得到一个 Executor Session 和独立工作目录（默认在 <stateDir>/work 下）。所谓"相互隔离" = 独立的 DSH Session + 独立目录。
• 工具与权限：Worker 运行 dsh-superagent-worker preset，命令无需审批、以操作系统的用户身份执行；worker subagents（含嵌套）用 DSH standard preset，保留 worker 的允许工具集；Ticket 结束即失去工具。
• 并发控制：WorkerSlots 机制——Ticket 从启动（或唤醒）起占用一个 worker slot，可配置并发上限；另加 1 个专供"人类消息/状态查询"的额外 slot，保证新工作不会饿死人的干预。
• 异步执行：worker preset 中前台 shell 命令 5 秒后转后台 job，会话能在长命令执行时仍接收新消息（即设计文章的"异步 ReAct Loop"；文章注：该机制已在 DeepSeek Harness 实现但默认未开启）。后台工作最多 30 分钟，超时杀掉并报告 waiting。
• 准备与交付：Ticket 目录首次使用前可运行一次 prepare 命令（默认 git worktree 检出），10 分钟超时；worker 通过 agent 账号的 gh 访问 GitHub、通过 lark-cli 访问飞书。auto-merge 默认关闭（GitHub 会把 merge 归因于开启者），默认允许条件：PR 就绪、所需 approval 覆盖 head commit、增删合计 < 200 行。

"These wrappers and directories establish defaults, not a security boundary. A worker can still execute a program by absolute path."

—— docs/003-execution.md 原文（verified live）。隔离只是默认约定，不是安全边界。

三、性能声明：数字测的是调度，不是写代码

p50 12.4 分钟 / p95 15.7 分钟出自设计文章第 7 节"初步实验"（经 chaincatcher.com 英译全文核对）。先把测法说清楚，再看数字。

任务完成时间（从工作请求发出到结果消息）

共比较 4 种方案：Super-agent、去掉直达机制的 Super-agent、单 Session + Subagent 工具（中性提示词）、单 Session + Subagent 工具（优先委派提示词）。中性提示词下 5 次运行都没调用 subagent，全在主 Session 做且不断被新消息打断；优先委派版本有所改善，但仍整体慢于 Super-agent。

仿真方法：为什么这组数字不能按字面读

• 合成负载：用合成的群聊 + GitHub CI 消息流驱动；每次实验约 300 条消息，其中只有约 20 条是真实工作请求，其余为闲聊、追问、取消、CI 消息。
• 编码工作被替换为一个只耗时的工具——实验测的是系统的调度与协作能力，不是单任务的执行质量或代码质量。
• 消息间隔与工作时长按 1/4 缩放，模型调用时间为真实值；每种方案只跑 5 次。
• 文章自己定性为 "preliminary experiments"、"结果仅供初步参考"（some settings could be more rigorous）。

成本侧：快是有代价的，直达省的是 Router 的钱

• Super-agent 因维护多个独立会话，单次实验的读缓存 token 高于单 Session 方案。
• 去掉直达机制后，完成时间基本一致，但 Router 决策数增加约 30%，读缓存 token 从 23.23M 升至 31.77M（+37%）——直达机制省的是 Router 的 token/推理开销，不是提速。

Router 吞吐实验（§7.2）：事件越密，批处理越划算

方法学警告 · 必读

全部数字为厂商自报，经 marktechpost、ifeng、QbitAI、chinamodelapi 等二手报道转述。调研未发现任何独立验证或社区复现：仅找到 r/singularity 的讨论帖（440+ 赞，无复现）和媒体报道；仓库 0 open issues、仅 1 个 commit，不存在可复现的实验代码/数据集披露。把这组数字当作"比单会话快 1.9 倍"的产品级结论，是误读。

四、与 DeepSeek Harness (dsh) 生态的关系

• 是 dsh 的插件 bundle，不是 dsh 的一部分：仓库根目录有 cordis.patch.yml（Cordis 是 Harness 底层的插件运行时，用于动态组装组件），README 明确 "packaged as a bundle for DeepSeek Harness"。运行时以独立的 DSH profile 存在（默认名 superagent、端口 3082），与用户日常工作的 profile 隔离。
• 依赖关系：构建在 Harness 的插件机制上——Source 插件、Session 工具、管理路由（management routes）都经 Cordis 接入；Executor/Worker 都是 DSH Session；复用 Harness 的 inbox、异步 ReAct 基础设施。
• dsh 本体：deepseek-ai/deepseek-harness，2026-08-13 发布，MIT，star 已超 18.8 万（startupfortune 报道；pasqualepillitteri 称已达 20 万），定位为 Claude Code / Codex 的开源替代。Harness 本体仍是实验性预览软件，官方警告可能有破坏性变更、未经过安全审计、沙箱与审批控制不保证隔离。
• 官方性：发布方是 DeepSeek Harness 团队（deepseek-ai 官方组织 + 官方微信公众号产品部文章），但 README 明确 "not an official DeepSeek product"——应理解为团队行为的开源研究原型，而非公司产品线。除微信公众号文章与仓库 README 外，未发现 DeepSeek 公司层面的其他声明。Bloomberg / Investing.com 的报道将其框定为对 Anthropic Claude Code 的挑战（引自 shiftdelete、medium 转述）。

五、实用性：运行要求与成熟度

运行要求（SETUP.md，verified live）

部署复杂度：高。 SETUP.md 本身就是一个"由你的 coding agent 陪你一步步做"的交互式流程：探针检查、9 个问题（Source / 仓库 / agent 账号 / 允许名单 / checkout / 提交身份 / auto-merge 等）、手动建账号、gh auth login、Feishu 建应用配 secret、经 Management API 保存配置。默认 accept mode 为 observe——只记录不行动。

成熟度

• 现状：发布约 1 天；1 commit；0 issues；无 release。README 自承 "may still contain bugs"、非生产就绪。
• 正面：文档异常完整——000 哲学 → 008 cookbook 共 9 篇编号文档 + SETUP.md + 部署/排障，含中英术语表；工程细节（失败恢复、重启、Policy 变更、消息重试退避）写得很细。
• 负面：worker 以 OS 用户身份无审批执行命令且"不是安全边界"，安全上只能跑在专用账号/隔离环境。
• 安全与运营：每小时健康检查（从操作者自己的 profile 触发）修复未运行的实例；面板（web panel）只列出需要人工的事项；未请求的工作默认只记录（observe 模式）；主动工作需团队书面规则才允许。

六、诚实评估：新颖性 vs 局限

相对 Claude Code Agent Teams、Swarm 式多智能体编排，它的新意不在"多开几个 agent"，而在把响应规则和人类注意力当成一等公民来设计。

真正新颖 / 有价值的

• 事件驱动的领域模型：Trigger / Thread / Eval / Mandate / Ticket / Subscription 五个原语 + 明确的规则表，把"何时响应、谁授权、做到哪"写成可版本化、可审计的规则（Policy version、不可变 Mandate），而不是藏在提示词里。r/singularity 上读过文档的评论也指出：亮点是"为不打扰人而设计的规则手册"。
• 双层过滤（程序快路径 + 模型慢路径）：高噪声低触发率场景下先用确定性代码过滤，再用 LLM 研判，是工程上实在的成本控制。
• 订阅直达 + Router 批处理：Thread 订阅让后续事件绕过 Router（省约 30% 决策、约 37% 缓存 token）；Router 侧的事件累积批处理是 prefill 并行的巧妙利用。
• 以人类注意力为第一优化目标：确认一次、工作时静默、只在需要人时说话；IM 单条回复不超过 100 词的硬规则；observe 默认模式。这是对"agent 疲劳是主要失败模式"的直接回应，多数竞品没有这么明确的注意力预算设计。
• Inline & Spill / Chain of Recall：把上下文窗口当缓存管理的思路（及按需多跳回溯）有工程美感。

局限与营销夸大

• p50/p95 数字极易被误读：测的是合成消息流下的调度延迟（工作还被替换成了 sleep 工具），不含真实编码质量、模型能力差异；每种方案只跑 5 次、约 20 个请求；文章自称初步参考。
• "主动/不请自来"被媒体放大：默认 observe 模式下未被请求的工作只记录不执行；真正的无提示修 bug 是内部实例 + 团队书面规则才有的行为，开源原型默认不做。
• 原型 ≠ 文章：README 明说部分设计是未来方向未实现；Watchdog（外部看门狗会话）、计算/状态/环境分离、云端常驻等第 5–6 节内容在开源代码中没有对应实现（至少文档 000–008 未覆盖，SETUP 只做了本机 tmux + 每小时健康检查）。
• "相互隔离"名不副实：Worker 只是独立 Session + 独立目录，无容器/沙箱，文档自承不是安全边界、无审批执行命令——生产使用有实质风险。
• 生态锁定：必须跑完整 DSH + 一堆 CLI + 专用 GitHub 账号 + 单仓库，部署成本远高于 GitHub Copilot coding agent / Claude Code Action 这类零运维方案；且只支持 github.com。
• 热度与实质不匹配：1 个 commit、0 issue、24 小时 5k star，更多是"DeepSeek 出品 + 架构文章写得好"的情绪溢价；star 曲线本身也说明讨论先于验证。

未能验证事项

以下问题在本次调研中没有找到足够证据，明确标出，不做推测填充。

1. p50/p95 实验的任何独立复现或第三方验证——未找到（仅媒体报道与 Reddit 讨论）。
2. 设计文章的微信原文——仅读到 chaincatcher.com 的英译全文，未直读微信原文（微信内容不易直接抓取）。
3. Watchdog 会话在开源原型中的实现状态——设计文章有，仓库文档 000–008 与 SETUP 未提及，倾向于未实现，但未做代码级穷举确认。
4. 内部 Super-agent 实例的真实运行效果——仅文章自述，无外部证据。
5. LICENSE 文件全文——仓库页 License 栏标明 MIT，README 指向 MIT，未逐字核对 LICENSE 文本（低风险）。

来源

VERIFIED LIVE 为调研时直读的一手页面；INDEX 为经索引/二手来源，数字与定性以一手页面为准。

• [VERIFIED LIVE] 仓库主页——创建时间、MIT、1 commit、star/fork/watchers、README 全文（2026-11-01 12:06 UTC 直读）
• [VERIFIED LIVE] docs/001-domain.md——Source/Trigger/Thread/Eval/Mandate/Ticket/Subscription/Assignment 定义与规则
• [VERIFIED LIVE] docs/003-execution.md——worker slot、隔离警告、prepare/auto-merge、失败恢复
• [VERIFIED LIVE] docs/007-architecture.md（部分）——Engine/Assessor/Executor/Outbox、通信机制
• [VERIFIED LIVE] SETUP.md——运行要求、9 步配置、observe 默认
• [VERIFIED LIVE] Issues 页——0 open issues
• [INDEX] chaincatcher 英译全文——设计文章：Router/Worker、事件驱动、实验方法学（§7）、p50/p95、成本与 batch 数据
• [INDEX] marktechpost 报道——TL;DR、性能数字的二手转述与警告
• [INDEX] chinamodelapi 深度解析——Router batching 数据、"数字未经独立验证"的明确标注
• [INDEX] startupfortune——Cordis 插件运行时、dsh 本体信息、MIT
• [INDEX] pasqualepillitteri——单 commit、star 时间线、r/singularity 讨论、"observe/规则手册"评价
• [INDEX] madrobot.blog——微信文章发布时间、内部实例描述
• [INDEX] shiftdelete——Bloomberg 框架、Watchdog 描述、配置要求
• [INDEX] medium 安全指南——worker 无审批执行风险、star 数
• [INDEX] aiaffairs——合成测试约 20 个请求的转述
• [INDEX] kad8——原型 vs 文章的区别
• [INDEX] panews——文章五大模块、Trigger 过滤 / Inline&Spill / Watchdog 机制

---

调研时间：2026-11-01（数据截至 12:06 UTC 直读）。本页所有数值均来自上述来源并保留其原始限定语；标注为厂商自报、无独立验证的内容请勿当作已证实结论引用。