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

1. Super-agent

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

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

连续（Continuous）：用户在 IM、GitHub 等不同信道与同一个 Agent 交互，不必关注底层 Session。

高效（Efficient）：响应及时，多项任务可以并发执行。

主动（Proactive）：由外部环境事件触发任务，而不必等待用户每次主动下令。

持久（Persistent）：持续在线，能够跨设备运行并从异常中恢复。

精读

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

本文的回答是：这是一篇 PRD，不是 Paper。

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

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

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

Bots 能够在不同 sub agent 间进行通讯，并进一步拉起 cursor cloud agent 用于编程工作。Dots 可以拉起 Codex Cloud session，从而实现在 Slack 内处理复杂工程需求的功能。

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

通过对不同竞品实现的研究，我们不难提出一个疑问：什么时候，session 会多到人管不过来？

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

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

答案是引入一个 main agent 并确保这个 Agent 的可见性，别的 session 自生自灭吧。

一群 session 给代码/文档化工作做改动打架怎么办？

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

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

2. 双层架构

作者认为，所有事件共用一个 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 组到底觉得 bash 是干啥用的、为什么事件处理会积压（你连执行都给剥离出去了啊喂），作者并没有详细说明。鉴于本文是一篇 PRD，我们也无需展开。

3. 事件驱动

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

3.1 事件过滤：因为外部事件「高噪音、低触发率」，先通过确定性程序策略检查来源、群组、白名单等（Fast Path），再让 LLM 对候选事件做语义判别（Slow Path）。

3.2 事件路由：将同一 PR、IM 话题或邮件往来串视为 Thread。新 Thread 由 Router 判断并创建 Worker；后续已订阅 Thread 的事件直接送往 Worker，减少经过 Router 的次数。Thread 与 Worker 支持多对多订阅。

3.3 上下文组织：使用 Inline & Spill 管理上下文窗口；优先内联近期相关内容，长内容只放摘要、ID 或续读入口。为 Trigger、Thread、Worker 等对象建立引用关系，沿关联 ID 按需检索历史，称为 Chain of Recall。

3.4 提前行动：将 Agent 根据环境信号提前开始工作称为 Speculative Execution。例如收到会议邀请后提前检查日程并准备草稿，或者在群聊出现 Bug 反馈时静默尝试复现和修复，仅在找到有价值结果时通知用户。

精读

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

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

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

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

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

在这个过程中，我们即可理解以下现象

• 为什么事务驱动系统的噪音是大的

• 为什么事务驱动系统是异步（需要等待）的

• 为什么事务驱动系统经常「太长不看」

4. 面向人的交互

本章希望解决后台任务阻塞前台对话，以及不同工作信道的信息呈现方式不同的问题。

4.1 全双工交互：传统同步 run() 工具调用需等待执行结束。文章提出将耗时操作改为异步 start() / stop()：启动时立即返回 Started，任务继续在后台运行，完成后将结果作为新的事件投递给 Session，使模型在后台工具运行期间仍能处理后续输入。原文称这一机制已在 DeepSeek Harness 中实现，但尚未默认开启。

4.2 多信道交互：Worker 的推理和工具调用不直接输出到外部信道，而由 Router 统一沟通；IM 侧保持简短、低打扰，文章举出单次回复不超过 100 词的规则；GitHub、邮件、文档侧则提供更完整、结构化的信息。

精读

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

可能意思是 Agent 执行任务或者 tool 的时候不用阻塞前台交互吧。

但这个功能似乎已经是市面上几乎所有主流 Harness 的实现了，包括但不限于 codex / claude code / pi / omp / antigravity / cursor 等。

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

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

作者认为，本地 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

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

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

精读

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

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

7. 初步实验

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

7.1 消融实验

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

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

完整版 Super-agent 的任务完成时间 p50 为 12.4 分钟，p95 为 15.7 分钟。文章称单 Session 基线在中性提示下 5 次均未调用 Subagent；在优先委派提示下 5 次有 4 次调用。

去掉订阅直通后，任务完成时间基本不变，但 Router 决策次数增加约 30%，总读缓存 Token 从 2323 万增至 3177 万，约增加 37%。

7.2 Router 批处理实验

Router 使用真实模型、Worker 使用 Mock 模型，将需要 Router 决策的 Trigger 到达速率从约 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. 开放问题

文章将目前尚未充分解决的问题分为四类：

8.1 双层架构扩展：当单一 Router 无法承载全部任务时，何时分片、如何分片，以及 Worker 之间何时需要直接通信；跨月运行又会引出长期记忆问题。作者还提及针对 Router 的事件判别、批量分派、上下文召回进行专门训练的可能性。

8.2 脱离 Session 的人机协作：当底层 Session 与用户可见任务不再一一对应，应如何呈现任务、项目和进度；如何允许人类在后台执行过程中介入、接管或实时协作。

8.3 上下文边界与 A2A：个人、团队与组织分别如何划分共享上下文和权限边界；多个独立 Agent 实例之间如何安全可靠地通信协作。

8.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. 结语

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

文章称基于 DeepSeek Harness 的内部 Super-agent 已持续参与问题复现、代码修复、Review 响应以及 Harness 自身的迭代。文末另说明，部分设计已实现于 dsh-superagent-prototype，它是用于验证技术路线的原型插件，不是 DeepSeek 的正式产品。

精读

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

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

鉴于来看精读的朋友应该也是没有看原文的，那么我们不妨在这里做一个愉快的收尾。

祝大家身体健康，财源滚滚，事业有成。

全文完。我们下次再见。