探索超级智能体设计：迈向更高自主性的 Agent 系统架构
本文讨论的是架构层面的构想，并非对 DeepSeek Harness 现有功能的介绍。
1. 超级智能体
过去一年里，编码智能体以及其他单任务智能体已经证明：模型能够借助工具解决复杂问题，同时越来越少地需要人类持续盯守和逐步干预。模型在协调多个智能体方面也变得越来越强，这使得跨会话地组织和调度工作变得切实可行。随着人们越来越少地介入底层执行，人的角色也逐步上移到更高层的决策与验收确认。
更强的模型也催生了新的应用形态。近来涌现出许多个人智能体（personal agent）。它们直接接入日常使用的即时通讯、日历、邮件和工作平台，监控信息流并协助完成任务。个人智能体只是这种"永远在线、事件驱动"工作方式的一种应用。这种工作方式并不专属于个人场景，在软件开发等商业工作中同样具有价值。
然而，当今主流的智能体设计难以支撑这种跨越多个任务乃至整个团队的工作方式。智能体仍然以单个会话作为工作的基本单位，而会话之间彼此隔离。一个并行推进多项任务的用户不得不在会话之间手动切换，并记住每个会话里装了什么内容。按照我们的经验，一个人通常同时只能跟进 3 到 5 个活跃会话。在这样的设计下，单个任务受限于模型能力，而多任务则受限于人的注意力。
在已有的本地单会话智能体上增加 CLI、MCP 或外部连接器，可以让它接收外部消息，但其根本局限依然存在。它仍然运行在一个同步会话中，遇到耗时操作就会阻塞；不同任务的上下文会混在一起；一旦本地设备离线，一切都会停摆。要让这样一套设置持续运行，需要耗费大量人工维护。
要突破这些限制，就必须让智能体与任何单个、由人工驱动的会话解耦。取而代之，智能体应当是一个连续的实体：跨会话保持上下文，同时处理多项复杂任务，而各项任务之间互不干扰。我们把这类智能体及其系统架构称为超级智能体（Super-agent）。
例如，我们内部运行在 DeepSeek Harness 上的超级智能体实例，可以跨 IM 与 GitHub 延续同一个开发任务。它还会监控公开群聊中的反馈，即使没有人 @ 它，也能自行定位根因并提交 Pull Request 来修复：
同一个任务在 IM 群聊与 GitHub Pull Request 评审之间延续
智能体监控一个公开群聊，在未被 @ 的情况下发现了一个 bug，并提交 Pull Request 修复它
我们认为超级智能体具备四项基本特性：
- 连续（Continuous）： 用户可以在自己原本工作的地方直接与它交互，例如 IM 聊天和 GitHub 评论，并且始终感觉面对的是同一个智能体。用户永远不必去琢磨"会话 X 的上下文里到底有没有信息 Y"。例如，如果用户在 IM 里要求方案 A，之后又在 GitHub Pull Request 评论中改口要方案 B，智能体能理解这一变化，并据此调整正在做的事情。
- 高产（Productive）： 它响应迅速，能并行完成多项复杂任务，且每项任务都保持高质量。它可以在上一条指令或任务尚未结束时就接下一条指令。
- 主动（Proactive）： 它不等待逐步指令。它会监控所处环境中的事件，对任何值得处理的事情采取行动，其余时候则保持安静。
- 持久（Persistent）： 它永远在线，直连用户真实的工作环境，并在长时间运行过程中从异常中自动恢复。
没有任何单一的 ReAct 循环能够同时提供这四项特性，因此它们必须来自围绕 ReAct 循环的系统架构。相似的设计约束往往会导出相似的系统架构。当目标是构建一个始终在线、能并发响应环境事件的系统时，我们预计个人智能体与软件开发等商业场景的智能体最终会殊途同归，形成相似的设计。构建这样一个系统还会引出许多与计算机系统领域长期研究过的问题高度相似的问题，因此该领域的许多经典设计思路在这里同样适用。
具体实现会各有不同，但我们认为有五个模块构成了支撑这些特性的基础框架。两层架构（第 2 节）同时提供连续交互与高并发产出。事件驱动设计（第 3 节）让智能体具备主动性。全双工多渠道路由（第 4 节）让每一次与用户的往来既连续又高效。将计算、状态与环境分离（第 5 节），再加上 Watchdog（第 6 节），则让智能体跨设备持久在线，并能自行从异常中恢复。
下图给出超级智能体架构的总览。标注为 [2] 到 [6] 的模块分别在第 2 节到第 6 节中展开：
超级智能体的整体架构，标注 [2] 到 [6] 分别对应第 2 节到第 6 节
要同时支持跨渠道的连续交互与跨任务的高并发产出，系统在组织会话的方式上必然要在连续性与吞吐量之间做出根本性的权衡。
把每个事件都路由到同一个会话，能获得最连续的上下文，因为这个会话能看到所有事情。但 ReAct 循环一次只推进一步，这就限制了单个会话的工作速度上限：任务耗时长，吞吐量低。不同任务的中间细节最终还会交错混杂在同一份上下文里，使结果质量下降。
给每个事件都开一个全新会话，则把这一权衡翻到了另一面。它能最大化并发吞吐量，但当任务之间并非完全独立时，缺少共享的全局上下文会让各自的结果彼此割裂。而且多个会话分别回复用户，也会让交互变得混乱。
为了同时获得连续性与吞吐量，我们可以把工作拆给两层承担。一个长期存活的 Router 层（第 2.1 节）通过处理全部人工交互与全局协调来维持全局连续性，而一个上下文隔离的 Worker 层（第 2.2 节）则以高并发执行任务，如下图所示：
两层架构：Router 层负责全部路由与对外交互，多个隔离的 Worker Session 并发执行任务
借助两层架构，系统接管了上下文管理与并发执行，用户几乎不必再关心会话，而是始终与同一个超级智能体打交道。因此，让用户手动管理会话，很大程度上是一种从底层 LLM API 沿用下来的设计习惯。会话应当成为系统的实现细节，而不是用户的心智负担。
在既有设计中，一个会话承担两项职责：既管理模型的上下文，又是用户进行项目管理的单位。一旦产品与底层会话解耦，项目管理就不必再遵循会话的边界。向用户提供怎样的交互方式与任务管理方式，就变成了一个独立的产品问题，我们稍后再回到这一点。
这两层是一种逻辑上的职责划分。任一层都不必实现为单个会话，每一层都可以有各自的内部结构。接下来的两个小节将依次介绍这两层。
2.1 Router 层
Router 层是一个长期存活的全局路由层，接收来自各个入口的人工交互。所有跨任务的信息与决策都在这里汇聚，因此它充当系统的全局定序点、协调点与记忆。为了避免这个单一的全局节点成为性能瓶颈，Router 层在设计上不自行执行任务。它只与人交互并派发任务，甚至可以完全不配备 Bash 工具。
由一个中心节点向多个执行节点派发任务，这种结构看起来像典型的 Agent Team，但两者的侧重点不同。Agent Team 通常要把一个复杂任务拆成若干步骤，并协调负责各步骤的角色。由于这些步骤之间往往耦合紧密，Team Lead 常常必须深入理解任务、规划子任务并频繁协调成员，累计起来是相当重的推理负担。而在超级智能体中，Router 层只负责派发任务，并在高层面上跟踪任务之间的相互关系，它并不拆解单个任务。反过来说，Agent Team 也可以改造成两层架构。为此，它的提示词必须约束主会话不要自行执行任务，而只做对外交互以及把彼此独立的任务派发给成员，由成员各自独立完成。按照我们的经验，Router 层的工作往往比预期更简单，一个更轻量的模型通常就能同时提供速度与质量。
在内部，Router 层也不必是单个会话，其中部分逻辑甚至未必需要 LLM。我们选择了最直接的设计——一个长期存活的单个 LLM 会话——并发现它并不像看上去那样容易成为吞吐瓶颈。原因在于，在一次推理回合期间到达的环境事件（也就是第 3 节中的 Trigger）会排队，并在下一个回合被一起处理。这就是批处理（batching），而把事件合在一起处理带来的额外开销很小：
- 当外部事件以稳定速率到达时，Trigger 会逐个到达 Router Session，每次响应都能很快返回。
- 当事件突发式到达、开始在 Router Session 处排队时，上一回合期间积攒的 Trigger 会被自动合并，并一起注入下一次 LLM 调用。由于 Router Session 只做轻量的交互与派发，每一步通常是长输入、短输出。被合并进同一次 LLM API 调用的 Trigger 会在 Prefill 阶段并行计算，因此单次请求耗时随批大小的增长要慢得多。于是，在一定范围内，积压越多，每个决策摊薄后的推理时间反而越低。其上限取决于上下文长度，以及模型在一个回合内能准确处理多少个 Trigger。
第 7.2 节用一项实验量化了批处理的效果。结合订阅与透传（第 3.2 节）以及 Chain of Recall（第 3.3 节），单个长期存活的 Router Session 就能保持上下文的连续性，这已足以支撑我们目前规模的团队。
如果系统增长到一个会话确实难以承受的程度，Router 层可以在内部采用多级过滤结构，或通过**水平分片（horizontal sharding）**拆分为多个会话。此时它的内部设计又归结为同一个连续性与吞吐量之间的权衡。分片越细，Router 层获得的并发吞吐量越高，但各分片之间共享的记忆与上下文就越少。在全局记忆问题被解决之前，这一权衡将持续存在。
2.2 Worker 层
Worker 层由执行任务的会话构成。每个 Worker 都拥有隔离的上下文和一整套执行工具，并且专属于单一任务。Worker Session 直接决定每项任务的结果及其代码质量，因此它们通常需要能力最强的模型。
Worker 从不直接与人交互。它们的推理过程和工具调用不会进入外部渠道。取而代之，每个 Worker 向 Router 层汇报自己的状态，由 Router 层负责对用户的全部回复。这样一来，系统既能保持并发能力，又能保持输出质量，同时避免多个会话各自回复造成的混乱。
当任务并发运行时，每个 Worker 处理自己的任务，同级 Worker 之间通常无需直接通信。Worker 之间的冲突往往出现在共享的工作环境中，例如同一个 Pull Request。只要相关 Worker 都订阅了该环境的 Thread，它们就会收到相同的事件通知（第 3.2 节），从而有机会自行发现并化解冲突。少数需要跨任务协调的情况，则由 Router 层中转处理。
与 Router 层一样，Worker 在内部也不必是单个会话。对于复杂任务，Worker 可以创建子智能体，或者它本身就是一个 Agent Team，而这对上层的 Router 层是透明的。同样的结构也适用于代码协作：复现问题、评审 Pull Request、开发功能等彼此独立的任务可以同时推进，而不会互相阻塞。它也适用于个人智能体场景，即便个人智能体通常只提供一个聊天页面。当用户在该聊天中同时讨论多个话题时，页面让对话保持连续；与此同时，后端可以为每个话题分别派发一个 Worker，并行处理任务并起草回复。
要让超级智能体具备主动性，我们首先需要改变驱动系统的东西。智能体的主要输入不再是人类逐条敲进会话的提示词，而是来自环境的半结构化事件。在超级智能体中，这些环境事件——例如群聊消息、邮件、日历提醒、代码评审评论和 CI 结果——被称为 Trigger。由于智能体监听并响应 Trigger，它不必像单会话智能体那样，每次运行前都要等待人类下达指令。
下面的几个小节沿着一个环境事件从到达至处理的全过程展开，分四步递进。首先，由代码与模型结合的两阶段策略过滤掉大量噪声（第 3.1 节）。接着，订阅与透传机制把事件路由给 Worker（第 3.2 节）。然后，Inline & Spill 与 Chain of Recall 将密集上下文注入模型，并按需召回更多内容（第 3.3 节）。最后，**推测执行（speculative execution）**让智能体基于环境信号在后台提前行动（第 3.4 节）。
3.1 事件过滤
一旦接入真实的群聊和代码平台，系统面对的就是一条噪声很大、触发率很低的事件流：日常消息中的绝大多数都不需要智能体采取任何行动。若让大模型对每个事件都从零开始判断，会带来过高的延迟和算力开销。借鉴计算机系统中的 Fast Path / Slow Path（快路径／慢路径）思想，我们把大模型推理视为一种灵活但昂贵的慢路径；而那些高频、定义明确且稳定的判断，则可以下沉为确定性代码，充当低延迟、低成本的快路径。
因此，系统会先对每一个进入的事件进行过滤。确定性策略会在调用任何大模型之前剔除噪声，只有需要语义理解的候选事件才会被送到模型面前。我们采用结合程序化策略与大模型的两级过滤：
- 程序化策略（快路径）： 代码针对事件来源、群组、用户或机器人白名单等确定性条件执行快速的准入检查。例如，每个来源都可以被设置为“仅响应明确请求”“视为候选事件”或“忽略”。这些检查会在调用任何模型之前丢弃大部分无关消息。
- 语义策略（慢路径）： 通过程序化检查的候选事件会交给 LLM，由它根据上下文以及以提示词形式编写的策略来判断是否采取行动。语义阶段同时也是一个天然的自然语言扩展点：人们可以随时通过提示词开启或关闭某条策略，或新增策略，如下图所示：
两级过滤：程序化策略先筛掉大部分无关消息，语义策略再对剩余事件作出判断
3.2 事件路由
第 2 节介绍的全局 Router 层让交互能够跨渠道保持连续。但如果某个已分配任务的每一个后续事件都仍然必须经过 Router 层，这个单一的全局节点就会承载沉重的负载并拖慢响应速度。因此，快／慢路径的划分同样适用于被过滤后的事件路由。Router 层只负责新任务的冷启动和跨任务协调，而后续事件由代码直接发送给负责它的 Worker Session。
在真实工作流中，同一个 GitHub Pull Request、IM 话题或邮件链上连续发生的事件会构成一条事件流，我们称之为 Thread：
Thread 示例：同一个 IM 话题或 GitHub Pull Request 下连续的 Trigger 构成一个 Thread
当 Router 层为某个 Thread 中的第一个事件创建 Worker Session 时，该 Worker 会直接订阅这个 Thread。此后，事件路由会走上如下图所示的两条路径之一：
- 已订阅（快路径）： 代码会把该 Thread 中的后续事件直接透传给已订阅的 Worker，因此 Router 层无需再发起一次工具调用去转发它们。如果新事件超出了当前任务的范围，Worker 可以取消订阅，或把事件交还给 Router 层重新派发。
- 未订阅（慢路径）： Router 层依然能看到每一个事件，因此可以追踪全局状态，但它只会评估和派发那些尚无订阅者的新事件。
订阅与透传：初始事件经过 Router 层创建一个已订阅的 Worker，同一 Thread 中的后续事件则直接送达该 Worker
Thread 与 Worker 之间的订阅关系是多对多的。一个 Worker 可以订阅多个相关的 Thread，一个 Thread 也可以拥有多个订阅它的 Worker。当多个 Worker 的工作环境或讨论内容出现重叠时，共享 Thread 中的每一个新事件都会一次性透传给它的所有订阅者。这样，各 Worker 就有机会了解其他 Worker 在做什么，并自行解决冲突，而无需点对点通信。在输出侧，Worker 仍会把关键结论上报给 Router 层，由 Router 层统一负责所有面向用户的回复，并保持全局记忆同步。
3.3 上下文组织
当一个事件被过滤并路由到目标会话之后，下一个问题是：应该往模型的上下文窗口里放多少信息。此时的输入不再是为数有限的人类提示词，而是环境持续产生的半结构化事件，因此工具调用与事件注入的设计变得更为重要。注入太多，窗口会被占满，稀释模型的注意力；注入太少，模型就必须一次又一次地调用工具去读取上下文，增加执行步骤。浪费上下文窗口，就是在浪费模型的智能。
因此，我们可以把这个有限的上下文窗口当作一层缓存来看待。借用编译器优化和计算机系统中的说法，上下文注入可归结为两种基本操作。**Inline（内联）**把很可能马上就会用到的信息直接放进当前上下文窗口，省去额外的工具调用往返；**Spill（外溢）**则在信息超出预算或不常使用时，把完整信息留在窗口之外，只在窗口内留下一个引用或摘要，模型可以按需通过它读取完整信息。
结合计算机系统设计中的经典思想 locality（局部性），Inline & Spill 可以一步步改进事件注入与工具调用：
- 从最小信息开始： 一开始只把当前对象的 ID 和内容摘要交给模型。
- 借助局部性逐步内联相关信息： 把模型很可能马上需要的信息内联进来。先内联紧密相关对象的 ID，再补充在空间或时间上相邻的内容。例如内容的前 50 个字符、某条消息前后的 IM 消息以及它所回复的那条消息、同一次代码评审讨论中相邻的评论，都属于此类。
- 超出上限的内容则外溢： 为无法完整内联的长内容设定一个较小的长度上限，并把超出的部分外溢到窗口之外。一个简单的做法是截断内容，并留下一个指向后续内容位置的指针，这样模型在需要时就可以调用工具读取剩下的部分。
Router 层也有自己的上下文难题。大量后续事件会直接透传给 Worker，而随着长时间运行，过去的任务会不断累积，因此 Router 层无法把每个任务的完整历史都保存在自己的上下文窗口中。然而，当用户在另一个渠道重新提起某个旧任务时，Router 层仍然必须恢复该任务的上下文。把 Inline & Spill 一致地应用到系统中的每一类对象上，就能得到一种按需的、多跳的检索机制：Chain of Recall（回忆链）。它减少了 Router 层在长时间运行中丢失的早期信息，如下图所示：
Chain of Recall：每个被召回的对象都会内联下一跳对象的 ID，使上下文能够沿着引用一跳一跳地扩展
系统会为 Trigger、Thread、Worker Session 等对象分配唯一 ID，并在注入某个对象时内联其紧密相关对象的 ID。这些 ID 把各个对象连成一张引用图。每个通过工具调用被召回的对象同样遵循 Inline & Spill，因此返回结果中会内联下一跳对象的摘要和 ID。这样，模型就可以从当前事件出发，沿着这些引用一跳一跳地召回上下文，需要追溯多远就能走多远。
例如，模型可以从当前消息所在的 Thread 出发，顺着内联的 ID 找到相关的 Worker Session，再找到与该 Worker 相关联的另一个代码评审 Thread。
3.4 提前行动
我们还从计算机系统中借鉴了 speculative execution（推测执行）。智能体会根据环境信号，在尚不知道结果是否会被使用的情况下，就提前在后台开始工作。它用额外的后台算力，换来人们更少的等待和更少的介入。事后被证明有用的结果会被交付出去，其余的则被丢弃。
在个人智能体场景中，当收到一封会议邀请邮件或一条待办消息时，智能体可以在后台检查日历冲突、收集背景信息并起草回复。用户随后只需浏览草稿并发送即可。同样的方法也适用于研发协作。例如，在我们内部的 DeepSeek Harness 用户群里，我们配置了一条“静默复现并修复”策略。当有人报告问题或讨论一项拟议的改动时，智能体会先在后台尝试复现问题并寻找修复方案。只有在确认了问题并找到一个简单的修复方案之后，它才会交付结果；否则它全程保持安静。
推测执行示例：当群里还在讨论解决方案时，Super-agent 已经在后台开了一个包含修复的 Pull Request
第 2 节的两级架构在上下文层面让交互能够跨渠道保持连续。但要让日常交互既连续又高效，还需要解决另外两个问题：交互以何种方式进行，以及在何处发生。第一个问题是避免耗时的后台操作阻塞前台对话。异步 ReAct 循环解决了这个问题，使会话可以随时接受新的指令，而无需等待上一条命令或任务完成（第 4.1 节）。第二个问题则是针对每一个沟通渠道以及人们在该渠道中的沟通方式，量身定制智能体回复的内容与详细程度（第 4.2 节）。
4.1 全双工
在经典的 ReAct 循环中，当模型发起一次同步的 run() 工具调用时，循环会一直阻塞，直到工具执行完毕并返回最终结果。在此之前，会话无法响应用户的任何新消息。为了消除这种阻塞，对话必须从基于轮次的半双工模式转向全双工模式，如下图所示：
经典 ReAct 循环与异步 ReAct 循环对比：异步调用会立即返回一条 Started 通知，而会话在后台工具运行期间仍能响应新消息
为此，我们用异步的 start() 和 stop() 调用取代耗时的命令与工具调用，从而把循环变成一个异步 ReAct 循环。调用 start() 会立即返回“Started”，循环不会等待工具。当工具在后台完成时，系统会把它的最终结果作为一条新的事件消息投递给会话。根据上下文，模型还可以调用 stop() 来结束一个运行过久的后台命令。
当前台对话与后台任务解耦之后，智能体就可以在耗时任务于后台运行的同时与人交互。新的输入会在当前推理步骤一结束时就得到处理，而不必等到后台工具执行完毕。
DeepSeek Harness 已经实现了这套异步任务机制，但目前尚未默认启用。
4.2 多通道
人们在群聊、邮件和 GitHub 讨论中的沟通方式各不相同。智能体需要同时调整回复的详细程度和表达方式，以适配每一种渠道。详尽的推理过程和工具调用日志也许适合单人终端，但如果原样贴到群聊里，就会让参与者被信息淹没。
在 Super-agent 中，两级架构已经解决了这个问题的一部分。每个任务冗长的推理过程和频繁的工具调用都留在其 Worker Session 内部，绝不会直接进入外部渠道，而所有对外交互都由 Router 层处理。除此之外，系统还需要接入用户日常依赖的工作环境，并用提示词为每个渠道设定交互规范：
- IM 及其他即时通讯渠道： 保持沟通轻量，尽可能少打扰他人。像人类同事一样，只在需要决策或确认时才通知，只提直接的问题，给出简短的结论。我们验证过的一条简单而有效的硬性规则是：每次回复不超过 100 词。
- GitHub、邮件、文档等异步渠道： 交付结构化、信息密度高的输出。例如，在创建或更新 Pull Request 时，按照项目约定写清完整的问题背景、改动说明和验证结果。在个人智能体场景中，则可以直接起草结构化的邮件和文档摘要。
默认情况下，本地智能体会把三样东西绑定在同一台设备上：运行 Agent Loop 的计算、必须持久化的会话状态，以及代码仓库和本地工具链等执行环境。一旦设备休眠或离线，智能体就会停止运行，也无法访问其他设备上的环境。为了让 Super-agent 持续在线，并连接到其任务所需的真实工作环境，我们借鉴计算机系统中的计算与存储分离，分两步把这三者解耦。第一步，把计算与会话状态分离，使智能体摆脱单台机器的生命周期限制，在云端持续在线（第 5.1 节）。第二步，把云端托管的 Agent Loop 与状态密集的执行环境解耦，这样执行环境可以留在原地，而智能体能够跨设备访问它们（第 5.2 节）。
5.1 计算与状态分离
运行 Agent Loop 的计算可以是无状态的，只有会话状态必须持久化。因此，第一层解耦把这部分计算放进无状态、可弹性伸缩的云容器中运行，而把会话及其他需要持久化的状态保存在数据库里。容器可以横向扩容、重启或被替换，持久化存储则维持着会话与任务的连续性。本地设备休眠或离线不再会让智能体停下来，它可以在云端持续在线。
5.2 计算与执行环境分离
一旦 Agent Loop 和会话状态都放到了云端，下一个问题就是：智能体如何抵达任务所需的执行环境。模型所处理的上下文，很大一部分来自针对代码仓库、本地文件、依赖服务以及其他执行环境的工具调用。因此，从广义上说，上下文也包括执行环境本身。
有两种常见做法。第一种是在云端启动沙箱，把代码拉取过去，再尝试重建并同步环境。但真实的工作环境往往包含尚未提交的本地改动、私有凭证、对内网服务的依赖，以及特定的硬件或工具链。要把这些全部同步过去代价高昂，而且很容易遗漏。第二种做法是要求用户放弃本地环境、把工作迁移到云端，而对许多用户来说，这种迁移的成本过高。
既然难以复制和同步的正是环境本身，就没有必要把它连同 Agent Loop 一起搬到云端。第二层解耦让 Agent Loop 留在云端，而把状态密集的执行环境留在原地。每个终端只需要一个轻量级守护进程（daemon），它不保存任何会话状态，只负责执行命令并返回结果。执行环境始终位于云端之外，智能体按需从中读取上下文。
Anthropic 的《让大脑与双手解耦》（Decoupling the brain from the hands）采用了同样的思路：harness 保持无状态，会话日志存放在它之外，执行环境通过统一接口按需接入。区别在于目标场景。Anthropic 的文章描述的是一种托管服务，主要讨论按需创建的沙箱以及客户 VPC 内的资源。而我们首先要接入的是人们日常使用的个人机器，这些机器上有未提交的改动和本地凭证，还可能只是间歇性在线。因此，我们的设计支持 BYOM（Bring Your Own Machine），即把用户自己的开发机或个人电脑接入云端智能体。它同时也支持云主机以及按需创建的计算环境。
这样一来，智能体就不再被绑定在某一台机器上。它可以在不同的执行设备之间切换，在任务所需的任何环境里运行命令、读取上下文。它甚至可以只与间歇性在线的设备协作：当用户的个人设备重新联网时，云端智能体会自动启动并完成那些需要在该设备上运行的任务。下图展示了由此得到的结构：计算、持久化状态与执行环境在两个层级上实现解耦：
计算与存储分离、执行环境解耦：在云端，Agent Loop 与持久化状态相互独立，并通过终端守护进程按需抵达不同的执行环境
要做到持续在线，仅靠第 5 节所述的计算与存储分离还不够：系统还必须在长时间运行过程中自动从异常中恢复。一个持续在线的分布式系统，如果只依赖自身的内部逻辑，很少能长期保持可靠。它需要主系统之外一个独立的控制回路（Control Loop）。
智能体系统也不只需要传统的进程存活探针或监控脚本。许多异常并不是崩溃：进程仍在运行，但模型卡在无效的循环里，或者已经偏离了目标。因此，长时间运行的智能体系统不仅要监控基础设施的存活状态，还要监控任务的进展。
我们的外部控制回路是一个独立的 Watchdog Session，它运行在主系统之外，由定时消息驱动。Watchdog 负责处理 API 错误、状态恢复失败等基础设施故障。它还会调用模型来判断每个 Worker 是否在取得实质性进展，或者是否偏离了整体目标。它会及时修复异常，并持续复查暂时性的外部故障，直到这些问题被解决。
由于 Watchdog 本身就是一个拥有完整工具集的智能体会话，维护者可以用自然语言问它某件事为什么会失败。他们还可以让它在系统运行期间纠正主系统的行为，例如增加或删除提示词，或者调整触发规则。
我们在两个层面对核心的调度与路由设计做了初步实验：整个系统，以及单独考察 Router 层。端到端实验把两级架构与单会话设计进行对比，并衡量订阅与透传（pass-through）机制的效果（第 7.1 节）。第二个实验测试 Router 层的批处理（第 7.2 节）。实验使用合成负载和简化环境，部分实验设置的严谨性还有提升空间，因此下面的结果仅供参考。
7.1 消融实验
四种端到端设计同时运行，由一股群聊与 GitHub CI 消息流驱动。每次运行约有 300 条消息，其中约 20 条是工作请求，其余则是闲聊、追问、取消和 CI 消息。编码工作由一个仅消耗时间的工具模拟，因此实验衡量的是系统的调度与协调能力，而不是执行单个任务的能力。每种设计各运行 5 次。
这四种设计分别是 Super-agent、Super-agent without Pass-through（不带透传的 Super-agent），以及两个使用不同提示词的 Single Session with Subagent tool（单会话 + 子智能体工具） 版本。
**中性提示词（neutral prompt）**的内容是：“在合适的时候，把一项工作交给子智能体去做……”
**委派优先提示词（delegation-first prompt）**的内容是：“聊天中的每条消息都会送到你这里，所以你自己执行的工作会不断被新消息打断。优先把每一项工作交给它专属的子智能体，你自己只做小事……”
四种设计下工作请求的累计到达量与累计完成量（5 次运行的平均值；消息间隔与工作时长按 1/4 缩放；模型调用时长未缩放）
| 设计 | 任务完成时间 p50 / p95（分钟） | 每次运行的缓存读取 token 数（全部会话） |
|---|---|---|
| Super-agent | 12.4/15.7 | 23.2M |
| Super-agent without Pass-through | 12.6/15.5 | 31.8M |
| Single Session with Subagent tool，中性提示词 | 20.4/29.5 | 6.1M |
| Single Session with Subagent tool，委派优先提示词 | 13.8/29.0 | 10.8M |
注：每种设计各运行 5 次。任务完成时间从工作请求发出时开始计算，到对应的结果消息为止。
Super-agent 的任务完成时间为 p50 12.4 分钟、p95 15.7 分钟，明显快于 Single Session with Subagent tool。单会话设计更慢，是因为在这个实验中它高度依赖提示词：主会话经常决定自己动手完成工作，从而使完成时间变长且不稳定。使用中性提示词时，模型在 5 次运行中一次都没有调用子智能体。所有工作都在主会话中执行，新消息不断打断它，p95 达到 29.5 分钟。使用委派优先提示词时，模型在 5 次运行中有 4 次进行了委派。完成时间有所下降，但总体上仍长于 Super-agent。在剩下那一次运行中，模型认为这项工作“很小”而自己做了，于是形成了图中紫色的长尾。单会话必须依靠提示词工程和模型的临场判断来决定是否委派。两级架构则在系统层面缓解了这个问题：Router 自己并不执行工作，而每个 Worker 只接收它所订阅的 Thread 发来的消息。
由于 Super-agent 维护着多个相互独立的会话，它每次运行使用的缓存读取 token 数多于单会话设计，以换取更短、更稳定的完成时间。不带透传的 Super-agent 完成任务的时间与 Super-agent 大致相当，但它的 Router 每次运行所做的决策数多出约 30%，总缓存读取 token 数也从 23.2M 上升到 31.8M，增加了约 37%。因此，在这类负载下，透传并不能让任务完成得更快或更好，但它大幅降低了 Router Session 的 token 用量与推理开销。
7.2 Router 层批处理
为了弄清单个长期存活的 Router Session 借助第 2.1 节所述的批处理能承受多大负载，我们单独对 Router 层做了压力测试。Router 调用的是真实模型，而 Worker 使用的是模拟模型。我们逐步把需要决策的 Trigger 的到达速率从每分钟约 1 个提高到每分钟约 40 个。在每一个速率下，我们测量平均批大小、单次请求耗时，以及每次决策分摊的推理时间。一次决策可能跨越多次 LLM 请求，因为 Router 在派发之前可能要推理多个步骤，或通过工具调用回忆上下文，所以每次决策的耗时可能超过单次请求的耗时。
不同 Trigger 到达速率下 Router Session 的批大小、单次请求耗时与每次决策分摊的推理时间
如上图所示，当需要决策的 Trigger 的到达速率从每分钟约 1 个提高到每分钟约 40 个时，平均批大小从 1.0 增加到 2.8。单次请求的耗时仅从 2.5 秒增长到 3.9 秒，增速慢于批大小的增长，因此每次决策分摊的推理时间从 6.4 秒下降到 1.6 秒。换句话说，当外部事件成批涌来时，Router 层通过自动合并已经积压的事件来提高有效吞吐量。批处理也解释了第 7.1 节的结果：去掉透传提高了 Router 的峰值负载，但单个 Router 仍然没有触及吞吐上限。因此，在我们目前的团队规模下，没有必要为了追求扩展而过早地对 Router 层做分片，从而牺牲全局上下文的连续性。
第 2 节到第 6 节描述了构成 Super-agent 基础架构的五个模块。第 7 节的实验表明，它的核心调度与路由机制在大量任务并发运行时是可行的。系统之所以能保持相对简单，很大程度上是因为在这个阶段，我们既简化了工程设计，也简化了所支持的应用场景。在这些简化之外，还有四个方面的问题尚未解决：如何扩展两级架构（第 8.1 节）、如何与没有会话的智能体协作（第 8.2 节）、上下文边界与智能体之间（A2A）的通信（第 8.3 节），以及安全与隐私（第 8.4 节）。
8.1 如何扩展两级架构
到目前为止，一个简单的组合已经以较低的工程成本覆盖了我们日常的大多数任务：单个长期存活的 Router Session、订阅与透传，以及 Worker 之间不直接通信。一旦任务变得更大、耦合更紧，超出单个 Router Session 的处理能力，每一层应当采用什么结构就还没有定论。我们仍需测试更多场景，才能弄清 Router 层应在何时分片、分多细，以及同级 Worker 之间应在何时直接通信、采用什么样的协作拓扑。系统与模型的协同设计是另一个值得探索的方向。专门针对 Router 层的工作（例如判断事件、批量派发、回忆上下文）训练模型，可能进一步提升 Router 层的吞吐与决策质量。
记忆也限制了系统能扩展到什么程度。长期存活的 Router 层连同基于引用图的 Chain of Recall，主要处理近期任务与会话历史的按需检索。一旦系统运行数月甚至更久，长期记忆就会成为主要的瓶颈。
8.2 如何与没有会话的智能体协作
由于两级架构把多会话管理对用户隐藏了起来，会话不再是产品设计的核心关切。但一旦底层的执行会话不再直接对应界面上的对话，就会出现一个新问题：如何向用户呈现任务，什么样的交互形式与项目管理方式才是自然的。我们认为聊天窗口之所以成为交互的中心，部分原因是路径依赖。更多的交互可能会转移到特定领域的界面中去，正如我们内部的 Super-agent 实例直接在 GitHub Issue 和 Pull Request 中工作。会话也可以继续留在界面里，因为用户已经习惯了它们，只是用户在界面上看到的一段对话，不必对应底层的一个会话。
前面的章节主要讨论任务开始时和验收时的人际交互。但在模型能力快速提升的这段过渡期，许多任务仍然需要人在中途参与。产品设计如何让用户在不失去后台自主工作所带来的效率的前提下，逐步介入关键细节，同样值得探索。例如，用户可以在后台执行的任意时刻介入、接管，或与智能体实时协作。
总体来看，用户所需的任务管理与交互方式，很大程度上取决于其工作领域和个人风格，因此最终的设计很可能高度定制化。DeepSeek Harness 采用开放的架构，这使此类定制更容易实现。
8.3 如何界定上下文边界并通过 A2A 协作
到目前为止，我们讨论的都是单个 Super-agent 实例的设计，并假定其范围内的所有信息都汇集在一个全局上下文中。当使用范围从个人和小团队扩展到更大的组织时，如何划分 Super-agent，实际上就变成了决定哪些上下文共享、哪些上下文隔离。组织中需要共享上下文的部分共用一个实例，需要隔离的部分则各自拥有自己的实例。
一旦组织内部或跨组织之间出现了相互隔离的实例，跨越这些边界的协作就是 A2A 通信，例如每个成员的个人智能体与团队共享的 Super-agent 之间的通信。这里的 A2A 泛指智能体之间的通信，而非某个特定协议。对于不共享底层上下文、各自代表不同权限边界的智能体，如何安全、可靠地通信与协作，仍有待我们解决。
8.4 如何保障安全与隐私
第 3 节的事件驱动设计让更多种类的环境可以驱动智能体，但同时也让智能体暴露在更多不可信的输入之下。除非安全与隐私得到妥善处理，否则 Super-agent 只能在非常小且可信的范围内工作。
例如，第 5 节的设计把 Agent Loop 运行在云端，并在执行设备上安装轻量级守护进程。它隐含地假定云端与终端彼此信任。但云端托管的 Agent Loop 会持续接收外部事件，而终端设备则保存着私有代码、敏感数据和本地凭证。把两者连接起来会带来显著的安全与隐私风险。一旦服务端入侵或提示词注入攻破了 Agent Loop，所有接入它的终端设备都可能被接管。
即使云端从未被攻破，凭证也可能泄露。只要终端上的凭证能够进入模型的上下文，正常执行过程就可能把它们暴露出来。因此，智能体需要一种无需看到凭证就能使用凭证的方式。要让这套架构获得更广泛的应用，它必须在保留从多种不同环境回忆上下文的能力的同时，解决好这些安全与隐私问题。
这套设计并不是提出什么新理论，而是把计算机系统中经典的工程思想应用到智能体系统的构建上。具体实现会随着技术发展而变化，但我们相信其背后的系统设计思想会在更长时间内保持价值。我们内部的 Super-agent 实例正是基于这些思想和 DeepSeek Harness 构建的，目前已在持续运行。它每天都在帮助复现和修复问题、响应代码评审，以及开发 DeepSeek Harness 本身。
正如我们在开头所指出的，大模型在单个任务上需要的人工干预越来越少，因此进一步提升生产力的瓶颈正在转向人的注意力。两级架构、事件驱动设计、异步多通道交互、计算与存储分离，以及外部 Watchdog 结合在一起，让系统接管了管理会话与同步上下文这类繁琐工作。人们于是可以向上移动，从执行细节转向更高层的决策与验收。
以这种方式构建出来的智能体，不再只是一个等待指令的聊天窗口。它成为一个自主的协作伙伴，持续在线于人们所使用的数字环境之中。对个人而言，它可以是帮助处理跨设备日常任务的个人智能体。对团队而言，它成为研发工作流的一部分，承接任务并推动其向前发展。我们相信，随着模型与系统架构共同演进，这种更自主的工作方式有望成为人机协作的常态。
本文的部分设计实现在 dsh-superagent-prototype 中。该插件只是用于验证技术路线的原型，并非 DeepSeek 的正式产品。
作者与致谢
本文基于 DeepSeek Harness 团队的共同工作。Yujia Qiao 实现了该系统并撰写了本文。Huanqi Cao、Zui Chen、Xieting Chu、Tianyi Cui、Shiyuan Feng、Yudong Han、Kexin Liu、Shichun Liu、Gesi Luo、Yifan Shi、Tongrui Xiong、Hanxiang Xu、C.C. Yu、Ziya Zhang、F. Zhou 等人参与了评审与讨论并提供了反馈。系统与本文都受益于团队日常的交流及其积累的经验。