十分钟精读 DSH Super Agent：从 Paper 到 PRD

1. Super-agent

[!abstract] 原文摘要
作者认为，以 Coding Agent 为代表的单任务 Agent 已逐渐能够独立完成复杂工作，但现有系统仍以单一 Session 为基本单位。用户并行推进多个任务时，需要自行切换会话、管理上下文；文章称一个人通常只能同时跟进 3～5 个活跃 Session，因此人的注意力成为多任务生产力的瓶颈。

文章将能够跨会话、跨工作平台持续运行，并同时推进多项任务的系统称为 Super-agent，并提出四项基础特征。

特征	含义
连续（Continuous）	用户在 IM（即时通讯）、GitHub 等不同信道与同一个 Agent 交互，不必关注底层 Session。
高效（Efficient）	响应及时，多项任务可以并发执行。
主动（Proactive）	由外部环境事件触发任务，而不必等待用户每次主动下令。
持久（Persistent）	持续在线，能够跨设备运行并从异常中恢复。

精读

作为全文开宗明义的部分，第一章很好定下了基调：这篇文章到底在说什么？是一篇解析 Cordis Plugin 的 Paper 吗？还是一次 Insights 分享？

本文的回答是：

[!tip] 核心判断
这是一篇 PRD（Product Requirements Document，产品需求文档），不是 Paper。

不然开场给你分析需求干嘛。

既然是 PRD，我们完全可以用 PRD 的方式解读，茅塞顿开。

作者希望解决 Session 太多、管不过来的问题，而市面上目前最主流的 multi-session 产品基本都是 Personal Agent，例如大家都喜欢的 Grok Bots 和 ChatGPT Dots。

Bots 能够在不同 Subagent 间进行通讯，并进一步拉起 Cursor Cloud Agent 用于编程工作；Dots 则可以拉起 Codex Cloud Session，从而在 Slack 内处理复杂工程需求。

实际上更早的 Claude Tag 也有过类似功能，但由于 Anthropic 把我号封了，本文不做评价。

通过对不同竞品实现的研究，不难产生一个疑问：什么时候，Session 会多到人管不过来？

答案是：Session 被自动创建的时候。

市面上的方案怎么处理 Session 多到管不过来的情况？

答案是引入一个 Main Agent，并确保这个 Agent 的可见性，别的 Session 自生自灭。

一群 Session 给代码/文档类工作做改动、互相打架怎么办？

答案是引入 PR 机制，用版本管理协同。

由此，本文的讨论正式展开。

2. 双层架构

[!abstract] 原文摘要
作者认为，所有事件共用一个 Session 会受串行 ReAct Loop 限制，且不同任务的上下文相互干扰；每个事件单独开 Session 则会丢失跨任务关联，并造成对外回复混乱。因此，系统区分 Router 与 Worker 两个逻辑层级，以兼顾全局连续性与并发执行。

• 2.1 Router 层：常驻、面向所有入口，负责接收人类交互、记录跨任务决策、分派任务和统一回复，不直接执行具体工作，文中称甚至可以不配备 Bash 工具。当前实现以单个常驻 LLM Session 为核心，倾向采用较轻量模型；事件积压时，将多条 Trigger 一并注入下一轮模型调用，称为 Batching。规模扩大后，可考虑分层过滤或 Sharding。
• 2.2 Worker 层：多个隔离的执行 Session 分别处理任务，配备完整工具与较强模型。Worker 将进度和结果反馈给 Router，不直接对人类发送回复；单个 Worker 内部仍可再启动 Subagent 或 Agent Team。

精读

作为对第一章所提问题的回答，第二章描绘了一种优雅的实现：双层结构。

什么是双层结构？就是外面有个秘书，里面有一群干活的工人。

用更技术化的语言来讲：用户与 Orchestrator Agent 交互，Orchestrator 再与底层干活的 worker/thread/session 交互。

在这样的产品设计里，Orchestrator 应该始终高可见，而底层实现的可见性则是可选、甚至要主动控制的。

这与 Bots/Dots/Tag 的产品功能一模一样。

当然，关于 Orchestrator 到底要不要配 Bash、DSH（DeepSeek Harness）组到底觉得 Bash 是干什么用的、为什么事件处理会积压（你连执行都给剥离出去了啊喂），作者并没有详细说明。鉴于本文是一篇 PRD，我们也无需展开。

3. 事件驱动

[!abstract] 原文摘要
作者把 IM 消息、邮件、日程提醒、GitHub Review、CI 结果等环境变化统一称作 Trigger，希望 Agent 从等待人类输入，转为持续监听并响应外部事件。本章分为四部分：

1. 事件过滤：因为外部事件「高噪音、低触发率」，先通过确定性程序策略检查来源、群组、白名单等（Fast Path），再让 LLM 对候选事件做语义判别（Slow Path）。
2. 事件路由：将同一 PR、IM 话题或邮件往来串视为 Thread。新 Thread 由 Router 判断并创建 Worker；后续已订阅 Thread 的事件直接送往 Worker，减少经过 Router 的次数。Thread 与 Worker 支持多对多订阅。
3. 上下文组织：使用 Inline & Spill 管理上下文窗口；优先内联近期相关内容，长内容只放摘要、ID 或续读入口。为 Trigger、Thread、Worker 等对象建立引用关系，沿关联 ID 按需检索历史，称为 Chain of Recall。
4. 提前行动：将 Agent 根据环境信号提前开始工作称为 Speculative Execution。例如收到会议邀请后提前检查日程并准备草稿，或者在群聊出现 Bug 反馈时静默尝试复现和修复，仅在找到有价值结果时通知用户。

精读

实际上，这是本文唯一涉及工程化的讨论。但考虑到 DSH 是一个专注于 frontier 研究的组织，「工程化」不足以概括其工作，因此我们将其称为「抽象」。

事件驱动是一种主流的抽象结构，主要用于异步系统。

例如，区块链对任务的处理需要时间，结果也可能失败，无法同步处理；与此同时，每个区块都会产生大量我们并不关心的事件，需要过滤。需求的提交者主动监听区块事件，直到拿到自己需要的那条为止。

更形象的解读是：你在群里问了一个问题，其他群友还在水群，你得一直等到群主回复你的消息，才算把问题处理完。

这个过程中，你每一次看群，群里的消息都是 event；你要一边应付群友水群的消息，一边抽空艾特群主，让群主赶紧回你。

由此可以理解以下现象：

• 为什么事件驱动系统的噪音很大；
• 为什么事件驱动系统是异步的（需要等待）；
• 为什么事件驱动系统经常「太长不看」。

4. 面向人的交互

[!abstract] 原文摘要
本章希望解决两个问题：后台任务阻塞前台对话，以及不同工作信道的信息呈现方式不同。

• 4.1 全双工交互：传统同步 run() 工具调用需等待执行结束。文章提出将耗时操作改为异步 start() / stop()：启动时立即返回 Started，任务继续在后台运行，完成后将结果作为新的事件投递给 Session，使模型在后台工具运行期间仍能处理后续输入。原文称，这一机制已在 DeepSeek Harness 中实现，但尚未默认开启。
• 4.2 多信道交互：Worker 的推理和工具调用不直接输出到外部信道，而由 Router 统一沟通；IM 侧保持简短、低打扰，文章举出单次回复不超过 100 词的规则；GitHub、邮件、文档侧则提供更完整、结构化的信息。

精读

这个章节我完全没看懂，想不出为什么要专门拎出来写一章。

可能的意思是：Agent 执行任务或调用工具时，不必阻塞前台交互。

但这个功能似乎已经是市面上几乎所有主流 Harness 都具备的能力，包括但不限于 Codex、Claude Code、pi、omp、Antigravity、Cursor 等。

哦对，本文是一篇 PRD。我怎么又忘了。

5. 计算、状态与环境的分离

[!abstract] 原文摘要
作者认为，本地 Agent 往往将 Agent Loop 的计算、Session 状态和实际执行环境绑定在一台机器上，因此本机离线会使任务中断。本章提出两次解耦：

• 5.1 计算与状态分离：将 Agent Loop 放入云端无状态计算容器，把 Session 等持久化状态存入数据库。容器可以重启、替换或水平扩展，通过重新加载状态延续任务。
• 5.2 计算与执行环境分离：Agent Loop 在云端运行，用户本地机器或其他环境仅运行轻量 daemon，负责接收命令、执行并返回结果。这样可以保留未提交代码、内网依赖、特定硬件及本地凭据等重状态环境，同时支持 BYOM（Bring Your Own Machine）、多设备切换和设备重新上线后的任务恢复。

文章将此设计与 Anthropic 的「脑手分离」进行对照，强调自己关注的是用户个人设备等可能间歇在线的执行环境。

精读

意思是：把 session.json 存起来，或者存进 DB；需要执行时，再把 session.json 发到 Agent Worker 恢复 context。

对于太重、或其他不适合发到云端的状态，就先留在本地，让这台机器成为 Orchestrator。

Codex 的远程控制模式、Claude Code 的远程控制模式、豆包 / WorkBuddy / 千问办公的「连接我的电脑」，乃至专门用于运行 CLI 的 Orchestrator（例如 Orca / T3 Code / Paseo / Conductor），基本也都是这么干的。

你甚至能去 Vercel 直接买到用于临时跑 Agent 的快闪 VM。

感觉 DSH 想卖云服务了。

6. Watchdog

[!abstract] 原文摘要
作者认为，长期运行的 Agent 不仅可能出现进程故障，也可能在程序仍正常运行时陷入无效循环或偏离任务目标。因此，在主系统之外另设一个独立的 Watchdog Session，由定时事件驱动，构成外部 Control Loop。

Watchdog 使用模型检查 Worker 是否有实质进展、是否偏离整体目标，并尝试处理接口异常、状态恢复失败或任务停滞。维护者还可以通过自然语言向 Watchdog 查询故障，或让它调整主系统提示词与触发规则。

精读

鉴于本章原文也就只比摘要长了一点，且实在没什么能精读的，我也跳过吧。

话说提了需求不做方案，是要加倍给下一个人吗？

7. 初步实验

[!abstract] 原文摘要
文章采用两组初步实验，重点测量调度、路由和 Router 批处理表现，而非 Coding Agent 完成代码任务的能力。

7.1 消融实验

合成场景约 300 条消息，包含约 20 条工作请求，其余为闲聊、跟进、叫停和 CI 消息；实际编码工作由只消耗时间的工具代替。每种方案重复 5 次。

比较对象包括：完整版 Super-agent、去掉订阅直通的 Super-agent，以及采用中性提示或优先委派提示的两种「单 Session + Subagent 工具」。

方案	关键结果
完整版 Super-agent	任务完成时间 p50 12.4 分钟、p95 15.7 分钟
去掉订阅直通	完成时间基本不变；Router 决策次数增加约 30%；总读缓存 Token 从 2323 万增至 3177 万（约 +37%）
单 Session + Subagent（中性提示）	5 次均未调用 Subagent
单 Session + Subagent（优先委派提示）	5 次中有 4 次调用 Subagent

7.2 Router 批处理实验

Router 使用真实模型、Worker 使用 Mock 模型，将需要 Router 决策的 Trigger 到达速率从约 1 条/分钟增加到 40 条/分钟。

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

作者明确指出，实验基于合成负载和简化环境，仅供初步参考。

精读

7.1 的意思是：经过一系列复杂的实验，我们证明了多个 Agent 干活比一个 Agent 快；并且发现，跟 Agent 强调派遣 Subagent 的重要性后，Agent 更倾向于派遣 Subagent。

7.2 的意思是：经过一系列复杂的实验，我们证明了一次处理 3 条 event 比一次处理 1 条 event 更快，但单次处理所需的时间更长。

实验设计确实不太完善，但至少有实验，总比没实验强。

8. 开放问题

[!abstract] 原文摘要
文章将目前尚未充分解决的问题分为四类：

1. 双层架构扩展：当单一 Router 无法承载全部任务时，何时分片、如何分片，以及 Worker 之间何时需要直接通信；跨月运行又会引出长期记忆问题。作者还提及针对 Router 的事件判别、批量分派、上下文召回进行专门训练的可能性。
2. 脱离 Session 的人机协作：当底层 Session 与用户可见任务不再一一对应，应如何呈现任务、项目和进度；如何允许人类在后台执行过程中介入、接管或实时协作。
3. 上下文边界与 A2A：个人、团队与组织分别如何划分共享上下文和权限边界；多个独立 Agent 实例之间如何安全可靠地通信协作。A2A 即 Agent-to-Agent。
4. 安全与隐私：云端 Agent 接触不可信环境事件，却通过 daemon 连接含私有代码、敏感数据及凭据的端侧设备，可能遭受提示词注入、凭据泄露与跨设备控制风险。文章提出，需要让 Agent 在不直接接触凭据内容的情况下使用相应权限。

精读

8.1 的意思是：一个 Router 可能不够用，可能要再分几个 Router。

而且 Router 越多，系统复杂度越大；如果复杂度更大，「蓝色大肥鱼」这种傻孩子可能处理不过来，可能要考虑用轨迹数据做后训练。

8.2 的意思是：怎么在 Session 低可见的情况下，让人介入和观测。

简单来说，就是水多了加面，面多了加水，找这个平衡点。

8.3 的意思是：上下文切不好，不仅影响任务，还可能导致缓存爆炸，需要好好设计。

实际上，这个被轻描淡写带过的小章节，是目前几乎所有涉及 Multi-agent 结构的 Harness 都在重度优化的点位。Codex 做了一年都没做利索，唯一做得比较好的是 Claude Code。

8.4 的意思是：云端机器连接本地 daemon 时，可能泄露敏感数据和敏感权限，所以要想办法隔离凭据与工具。

我小时候写作文，经常到最后一段才发现字数没写够，于是草草补一个司马迁的案例，凑够 800 字。我认为 8.4 的定位就是本文的「司马迁」。

9. 结语

[!abstract] 原文摘要
作者重申，文章并未提出全新的理论，而是将计算机系统中的经典工程思想用于 Agent 系统：以双层架构协调多任务、以事件驱动实现主动响应、以异步交互减少阻塞、以存算及环境分离支持持久运行，再通过 Watchdog 实现异常检查和恢复。

文章称，基于 DeepSeek Harness 的内部 Super-agent 已持续参与问题复现、代码修复、Review 响应以及 Harness 自身的迭代。

[!warning] 重要说明
文末另说明，部分设计已实现于 dsh-superagent-prototype，它是用于验证技术路线的原型插件，不是 DeepSeek 的正式产品。

精读

我觉得这个章节最幽默，感觉是前面写完之后心里没底，发给 ChatGPT 问了一句「你怎么看」。ChatGPT 说：好啊，你写得好啊；但你写的这些东西，计算机系统里已经有人写过很多遍了，不如稍微致敬一下。

就像 DSH 当时写了半天热插拔插件，最后发现有个叫 OSGi 的玩意写得基本一样，于是连忙致敬，并不忘戏谑地调侃自己一句「其实我们没有提出全新的理论」。