超级 Agent 设计：从会话隔离到常驻多任务系统

本文根据 DeepSeek Harness 于 2026 年 11 月 1 日发布的 X Article 《Exploring Super-agent Design: Towards a More Autonomous Agent System》整理。原文为中文，公开页面提供的是机器翻译版本；原帖本身只分享了文章链接。配套原型 deepseek-ai/dsh-superagent-prototype 采用 MIT 许可，README 明确说明它是研究原型，不是官方产品，也未完全实现文章中的设计。文中的实验数据来自作者自测，测试用耗时工具模拟编码，因此衡量的是调度而不是真实任务执行。

本文也吸收了 cxuan（criscxuan）对这篇设计的长文解读（由原帖分享，2026 年 11 月 2 日）。这篇解读用“单任务的上限取决于模型，多任务的上限取决于人的注意力”概括了问题，并把 Router/Worker、事件过滤、Inline/Spill、异步 ReAct Loop、BYOM 和 Watchdog 串成一条更容易阅读的主线。下文保留官方文章的术语、实验数据和研究原型边界；通俗比喻属于解读作者的说明，不应当当作 DeepSeek Harness 的额外产品承诺。

现有 Agent 产品大多以“会话”为工作单位：一个任务一个窗口，任务之间彼此隔离。要同时推进几件事，人就得在多个会话之间切换。文章引用了一个经验数字：人通常只能同时跟踪 3–5 个活跃会话。单任务的能力瓶颈来自模型，多任务的瓶颈则来自人的注意力。

DeepSeek Harness 提出的“Super-agent”不是更大的会话，而是一个脱离手动会话、跨渠道持续工作的实体：它保留上下文、并行处理多个复杂任务，并在环境事件出现时主动判断是否行动。

四个目标与五个模块

文章把 Super-agent 的特征归纳为四点：

特征	含义
连续	交互发生在 IM、GitHub 等现有工具里，用户感觉面对的是同一个 Agent，计划变化能跨渠道追踪
高产	快速响应，并行推进多个复杂任务，在前一个任务完成前也能接收新指令
主动	监听环境事件，在值得行动时出手，否则保持安静
持久	始终在线，连接真实工作环境，异常后能够恢复

单个 ReAct 循环无法同时满足这四点，因此需要系统架构。文章给出五个模块：两级架构、事件驱动、全双工多通道交互、计算/状态/环境分离，以及独立的 Watchdog。

两级架构：Router 负责协调，Worker 负责执行

连续性和吞吐量存在直接冲突：

• 所有事情都进一个会话，上下文最连续，但 ReAct 循环被串行化，不同任务的细节互相干扰；
• 每个事件都开新会话，并发最高，但共享上下文丢失，用户会收到一堆互不相干的回复。

文章的做法是把职责拆开：一个长期存活的 Router 负责人机交互和全局协调；多个上下文隔离的 Worker 并行执行任务。会话成为实现细节，而不是用户必须管理的单位。

Router 层

Router 是全局的路由层，负责接收来自各个入口的人类交互，也是全局的顺序点、协调点和记忆。它不执行任务，只做交互和派发，甚至可以不配备 Bash 工具。

这与 Agent Team 不同：Agent Team 拆解一个复杂任务，协调的是紧耦合的角色；Router 派发的是多个任务，只跟踪任务之间的高层关系，不替每个任务做拆解。

Router 内部可以是一个长期存活的 LLM 会话。推理过程中到达的 Trigger 会排队，在下一轮一起处理，形成批处理。突发消息合并进下一次模型调用，prefill 可以并行，因此单请求耗时随批量增长得较慢，摊到每次决策上的推理时间反而下降。上限取决于上下文长度和模型能准确处理多少条 Trigger。

如果单会话处理不过来，可以加入多级过滤或水平分片，代价是牺牲一部分共享记忆和上下文。

Worker 层

Worker 拥有隔离的上下文、完整工具集和单一任务，通常需要使用能力最强的模型。它不直接与人类交互：推理和工具调用留在内部，只向 Router 汇报状态，由 Router 统一回复。这样既保持并发，又避免多个会话各自回复造成混乱。

Worker 之间一般也不直接通信。冲突通常发生在共享环境里，例如同一个 Pull Request；订阅了同一 Thread 的 Worker 会收到相同事件通知，自行发现并解决冲突。少量跨任务协调由 Router 转达。

一个 Worker 内部仍可以使用 subagent 或 Agent Team，这对 Router 是透明的。这适合代码协作，也适合个人 Agent 按话题给不同聊天页派发独立 Worker。

事件驱动：Trigger、Thread 与订阅

Super-agent 的主要输入不再是逐条命令，而是半结构化的环境事件：群消息、邮件、日历提醒、代码审查评论、CI 结果。文章把这些统称为 Trigger。

先过滤，再判断

真实事件流噪声很大，每个事件都调用大模型既慢又贵。系统借用 Fast Path / Slow Path 的思路：

• 程序化策略（快路径）：检查来源、群组、用户/机器人白名单。来源可以配置为只响应明确请求、只作为候选，或完全忽略。
• 语义策略（慢路径）：由模型结合上下文和提示词策略判断候选事件是否值得处理。策略用自然语言编写，便于启用、停用和追加。

路由与订阅

Router 处理冷启动和跨任务协调；后续事件由代码直接送到负责的 Worker。

同一个 Pull Request、IM 话题或邮件链上的连续事件构成一个 Thread。Router 为第一个事件创建 Worker 时，该 Worker 订阅这个 Thread：

• 已订阅（快路径）：后续事件直接进入 Worker；如果超出任务范围，Worker 可以退订或把事件退回 Router。
• 未订阅（慢路径）：Router 看到所有事件，但只评估和派发那些没有订阅者的事件。

订阅是多对多的：一个 Worker 可以订阅多个 Thread，一个 Thread 也可以有多个 Worker。共享事件会送达所有订阅者，让它们发现并解决冲突，而不需要点对点通信。Worker 仍会把关键结论汇报给 Router，由 Router 负责用户回复和全局记忆。

上下文组织：把窗口当缓存

文章把上下文窗口视为缓存，核心问题是“注入多少信息”：

• Inline：把大概率会用到的信息直接放进上下文，减少额外工具调用；
• Spill：超出预算或很少使用时，把完整信息留在窗口外，只保留引用或摘要，按需取回。

利用局部性：从当前对象的 ID 和摘要开始，逐步加入相关 ID 和邻近内容，例如附近消息或审查评论；长内容则用截断指针留在外部。

Router 的麻烦在于大量后续事件绕过它，历史不断累积。文章用“Chain of Recall”做按需的多跳检索：Trigger、Thread、Worker Session 等对象都有唯一 ID，被注入的对象内联下一跳对象的 ID，形成引用图；召回的对象也带上下一跳摘要和 ID，模型可以沿着引用链按需展开。

提前行动：推测执行

推测执行指在还不确定结果是否会被使用时，先在后台做一部分工作：有用就交付，没用就丢弃。

例如收到会议邀请或待办事项时，Agent 可以先查日历冲突、收集背景、起草回复。在内部用户群里，“静默复现并修复”策略会让 Agent 在后台复现问题、寻找简单修复，确认后才开口。

全双工与多通道

要同时做到连续和高产，后台操作不能阻塞对话，回复也要符合不同渠道的规范。

全双工

传统同步 run() 调用会一直阻塞到任务完成。文章建议把长调用换成异步的 start() 和 stop()：start() 立即返回“已开始”，结果稍后作为事件消息到达，stop() 可以终止过长的后台命令。新输入在当前推理步骤结束后就能处理，而不必等工具全部完成。DeepSeek Harness 实现了这个机制，但没有默认开启。

多通道

Worker 保留冗长的推理和工具日志，Router 负责对外交互。提示词为不同渠道设定规范：

• IM：轻量、少打扰，只在需要决策或确认时通知，直接提问，给简短结论。文章提到一条经过验证的硬规则：回复不超过 100 词。
• 异步渠道（GitHub、邮件、文档）：结构化、信息密度高，包含背景、变更说明和验证结果；邮件和总结按固定结构起草。

计算、状态与环境分离

本地 Agent 把计算、持久会话状态和执行环境绑在一台设备上。设备离线，Agent 就停了；其他环境也无法访问。

计算与状态分离

Agent Loop 的计算可以无状态，只有会话状态需要持久化。这样计算节点可以替换、扩缩容，状态独立存储和恢复。

计算与执行环境分离

执行环境本身就是上下文的一部分。文章指出两种常见做法都有问题：重建云沙箱很难复制未提交的改动、凭证、内网依赖和专用硬件；把用户整体迁到云端又往往成本过高。

更可行的方式是把 Agent Loop 留在云端，让状态重的环境留在原地。每个端点只运行一个轻量、无状态的 daemon，负责执行命令并返回结果。这类似 Anthropic 所说的“把大脑和手分开”，但文章更强调个人机器优先，同时支持 BYOM（Bring Your Own Machine）和云端托管机器。Agent 因此可以切换执行设备、按需读取上下文，并在间歇联网的个人设备重新上线后继续工作。

Watchdog：独立于主系统的控制回路

常驻运行需要主系统之外的控制回路。文章强调，Agent 系统不能只做进程存活检查：进程可能还在跑，但模型在原地打转，或者已经偏离目标。

Watchdog 是一个独立的 Agent 会话，由定时消息驱动，负责三类事情：

1. 处理基础设施故障，例如 API 错误和状态恢复失败；
2. 判断 Worker 是否在取得实质进展；
3. 重试瞬时失败。

因为它有工具，维护者可以用自然语言问它“哪里出了问题”，也可以让它在系统运行时调整提示词或触发规则。这把运维从“看日志猜原因”变成“向一个受控 Agent 询问并执行修复”。

初步实验：调度收益与代价

文章做了两组初步实验。需要再次强调：编码任务由耗时工具模拟，实验衡量的是调度和上下文管理，不是模型真实的编码能力。

消融实验

四种设计各处理约 300 条消息，其中约 20 个工作任务，每种设计跑 5 次：

设计	p50 / p95 完成时间（分钟）	缓存读取 Token
Super-agent	12.4 / 15.7	23.2M
去掉 pass-through 的 Super-agent	12.6 / 15.5	31.8M
单会话 + subagent，中性提示	20.4 / 29.5	6.1M
单会话 + subagent，委派提示	13.8 / 29.0	10.8M

几个值得注意的结果：

• 中性提示下，模型五次都没有主动委派，工作全压在主线，反复被打断；
• 委派提示下，五次中有四次委派，剩下一次自己做完，造成长尾；
• 去掉 pass-through 几乎不改变完成时间，但 Router 决策增加约 30%，Token 增加约 37%。

也就是说，两级设计用更多缓存 Token 换来了更快、更稳定的完成时间；pass-through 的主要价值是减少 Router 的重复判断和上下文负担。

Router 批处理

Trigger 到达率从每分钟约 1 条升到 40 条时：

• 平均批量从 1.0 升到 2.8；
• 单请求耗时只从 2.5 秒升到 3.9 秒；
• 摊到每次决策的推理时间从 6.4 秒降到 1.6 秒。

在当前团队规模下，单个 Router 还没有触到吞吐上限，过早分片反而会损失全局上下文。

四个开放问题

文章没有把设计说成已经解决，而是列出四个仍在探索的问题：

1. 两级架构怎么扩展。 目前单个长驻 Router、订阅/pass-through、Worker 不直接通信已经够用；但什么时候分片、分多细，Peer Worker 何时应该直接通信，仍不清楚。为路由任务专门设计或训练模型也是方向之一。系统运行数月后，长期记忆会成为主要瓶颈。

2. 没有会话之后，产品怎么设计。 会话被隐藏后，任务和项目管理如何呈现？聊天窗口的主导地位可能部分是路径依赖；更多交互可能转移到 GitHub Issues、Pull Requests 这类领域界面。用户还需要在任务中途介入，同时不破坏后台自主性。

3. 上下文边界与 A2A。 配置 Super-agent 本质上是在决定哪些上下文共享、哪些隔离。跨边界协作，例如个人 Agent 与团队 Agent 合作，需要安全可靠的通信机制，因为双方没有共享上下文，权限边界也不同。

4. 安全与隐私。 事件驱动意味着更多不可信输入。云端—端点设计假设双方互信，但服务器被攻破或提示词注入可能危及所有已连接端点。凭证只要进入模型上下文就可能泄漏，因此 Agent 需要在不“看见”凭证的情况下使用它们，同时保留跨环境召回能力。

结论

文章把 Super-agent 设计看成对已有计算机系统思想的组合，而不是提出新理论：两级架构解决协调与并发，事件触发解决输入方式，全双工解决交互阻塞，计算/状态/环境分离解决设备绑定，Watchdog 解决常驻运行的可靠性。

作者称内部已经有一个持续运行的 Super-agent 实例，用于复现和修复问题、响应代码审查，并参与开发 DeepSeek Harness 本身。随着模型在单个任务上需要的人工干预减少，瓶颈会转向人的注意力；系统架构的价值，是替人管理会话和上下文，让人退到更高层的决策与确认。

配套原型可以验证这套思路，但它是研究代码，不是官方产品，也不等同于文章描述的全部设计。真正落地前，仍需要按自己的权限、审计、成本和故障恢复要求重新评估。

来源

• DeepSeek Harness：Exploring Super-agent Design（2026 年 11 月 1 日；原文中文，公开页面为机器翻译）
• cxuan：通了个宵，终于把 Super-Agent 架构玩明白了及其 X Article（2026 年 11 月 2 日；二次解读）
• cxuan 长文中引用的微信原文
• deepseek-ai/dsh-superagent-prototype（MIT；研究原型，非官方产品）
• 原型架构文档
• 原型设计原则