DeepSeek发布超级智能体架构突破Agent生产力瓶颈

以下为全文——

1. 超级智能体

在过去的一年里，编码智能体和其他单任务智能体已经证明，模型可以使用工具来解决复杂问题，同时越来越不需要人类持续监控和逐步干预。模型在协调多个智能体方面也变得更出色，这使得跨会话组织调度工作变得切实可行。随着人们越来越少地参与底层执行，他们的角色正逐渐上移至更高层的决策与审批。

更好的模型也催生了新的应用。最近出现了许多个人智能体。它们直接连接到日常的消息、日历、电子邮件和工作平台，监控信息流并协助完成任务。

个人智能体只是这种“永远在线、事件驱动”工作方式的一种应用。这种方式并非个人专属，在软件开发等商业工作中也极具价值。

然而，如今主流的智能体设计很难支持这种跨多个任务或整个团队的工作方式。智能体仍以单一会话作为基本工作单元，且会话之间相互隔离。并行运行多个任务的用户必须手动切换会话并记住每个会话的内容。

根据我们的经验，一个人通常只能同时跟进 3 到 5 个活跃会话。在这种设计下，单任务受限于模型能力，而多任务则受限于人类的注意力。

在现有的本地单会话智能体中加入 CLI、MCP 或外部连接器，能让它接收外部消息，但其根本局限依然存在。它仍然在一个同步会话中运行，会在长时间操作上阻塞，不同任务的上下文会混杂在一起，而且一旦本地设备离线，一切都会停止。维持这样的系统运行需要大量人工干预。

要突破这些限制，意味着要将智能体与任何单一的、手动驱动的会话解耦。相反，智能体应该是一个连续的实体，能够跨会话保持上下文，并能同时处理多个复杂任务，且任务之间互不干扰。我们将这种智能体及其系统架构称为超级智能体（Super-agent）。

例如，我们运行在 DeepSeek Harness 上的内部超级智能体实例，可以在 IM 和 GitHub 之间继续同一个开发任务。它还能监控公共群聊中的反馈，即使没有人 @ 它，也能自行找到根本原因并开启 PR 来修复它们：

(同一个任务在 IM 群聊和 GitHub PR 审查中持续跟进)

(智能体监控公共群聊，在没有被 @ 的情况下找到 bug 并开启 PR 修复)

我们相信超级智能体具备四个基本特征：

· 连续（Continuous）：用户可以在他们已经在工作的地方（如 IM 聊天和 GitHub 评论）直接与其交互，且它始终感觉像同一个智能体。

用户永远不需要怀疑会话 X 是否包含上下文 Y。例如，如果用户在 IM 中要求“计划 A”，后来在 GitHub PR 评论中切换到“计划 B”，智能体能理解这种变化并调整它正在做的事。

· 高效（Productive）：它能快速响应，并高标准地并行完成多项复杂任务。它可以在上一条命令或任务完成之前接受下一条指令。

· 主动（Proactive）：它不会等待逐步的指令。它会监控环境中的事件，对任何值得处理的事情采取行动，否则保持安静。

· 持久（Persistent）：它永远在线，直接连接到用户真实的工作环境，并在长期运行中自动从异常中恢复。

没有任何单一的 ReAct 循环能同时提供所有这四种特征，因此它们必须来自于其周围的系统架构。相似的设计约束往往产生相似的架构。

当目标是建立一个永远在线、并发响应环境事件的系统时，我们预计个人智能体和商业（如软件开发）智能体最终会殊途同归。构建这样一个系统也会带来许多计算机系统领域长期研究过的问题，因此该领域的许多经典设计思想在这里同样适用。

实现方式会有所不同，但我们认为五个模块构成了支撑这些特征的基本框架。

双层架构（第 2 节）同时提供了连续交互和高效并发。

事件驱动设计（第 3 节）使智能体具有主动性。

全双工多渠道交互（第 4 节）使与用户的每次交流既连续又高效。

计算、状态和环境的分离（第 5 节），加上看门狗（Watchdog，第 6 节），使智能体能够跨设备持久在线，并自动从异常中恢复。

下图给出了超级智能体架构的概述。标有 [2] 到 [6] 的模块将在第 2 到第 6 节中介绍：

(超级智能体整体架构，标签 [2] 到 [6] 对应第 2 到 6 节)

2. 双层架构

要同时支持跨渠道的连续交互和跨任务的高效并发，就必须在系统组织会话的方式上，在连续性和吞吐量之间进行根本性的权衡。

将每个事件路由到一个会话可以获得最连续的上下文，因为该会话能看到所有内容。但一个 ReAct 循环一次只能运行一步，这限制了一个会话的工作速度：任务耗时长且吞吐量低。不同任务的中间细节最终也会在一个上下文中交错，从而降低结果质量。

为每个事件分配一个全新的会话则反转了这一权衡。它最大化了并发吞吐量，但当任务不完全独立时，缺乏共享的全局上下文会导致其结果脱节。多个会话分别回复用户也会使交互变得混乱。

为了同时获得连续性和吞吐量，我们可以在两层之间划分工作。长期存活的 Router 层（第 2.1 节）通过处理所有人类交互和全局协调来维持全局连续性，而上下文隔离的 Worker 层（第 2.2 节）以高并发执行任务，如下所示：

(双层架构：Router 层处理所有路由和外部交互，多个隔离的 Worker 会话并发执行任务)

采用双层架构后，系统接管了上下文管理和并发执行，因此用户很少需要考虑会话，并且始终与同一个超级智能体交互。让用户手动管理会话，在很大程度上是沿袭自底层 LLM API 的设计习惯。会话应该是系统的实现细节，而不是用户的精神负担。

在现有设计中，会话承担了两项工作：它管理模型的上下文，同时也是用户的项目管理单元。一旦产品与底层会话解耦，项目管理就不再需要遵循会话边界。为用户提供什么样的交互和任务管理，就变成了一个独立的产品问题，我们将在后面讨论。

这两个层次是逻辑上的责任划分。任何一层都不必实现为单个会话，且各自可以有内部的架构。接下来的两小节将依次描述这两个层。

2.1 Router 层

Router 层是一个长期存活的全局路由层，接收来自每个入口点的人类交互。所有跨任务的信息和决策都在这里汇集，因此它充当系统的全局顺序点、协调点和记忆。为了防止这个单一的全局节点成为性能瓶颈，Router 层被设计为不自己执行任务。它只负责与人交互和分发任务，甚至可以在完全没有 Bash 工具的情况下运行。

用一个中心节点向几个执行节点分发任务，这种结构看起来像典型的 Agent Team（智能体团队），但两者的侧重点不同。Agent Team 通常将一个复杂任务分解为多个步骤，并协调负责这些步骤的角色。

由于这些步骤往往紧密耦合，团队负责人（Team Lead）往往需要深入了解任务、规划子任务并频繁协调成员，这加重了推理负担。

在超级智能体中，Router 层只负责分发任务并在高层面上跟踪它们之间的关系。它不分解单个任务。

反过来，Agent Team 也可以作为双层架构工作。为此，它的提示词必须阻止主会话自己执行任务，并限制其仅进行外部交互和向独立工作的成员分发单独的任务。

根据我们的经验，Router 层的工作通常比预期的要简单，一个较轻量的模型通常就能同时提供速度和质量的保证。

在内部，Router 层也不必是单个会话，它的某些逻辑甚至可能根本不需要 LLM。我们选择了最直接的设计——单个长期存活的 LLM 会话，并发现它并不像看起来那样容易成为吞吐量瓶颈。原因是，在一次推理轮次期间到达的环境事件（第 3 节的触发器）会排队并在下一轮中一起处理。结果就是批处理（batching），并且一起处理这些事件几乎不会增加多少开销：

· 当外部事件以稳定的速率到达时，触发器逐一到达 Router 会话，并且每个响应都能快速返回。

· 当事件突发到达并在 Router 会话中开始排队时，上一轮期间积累的触发器会被自动合并，并一起注入到下一次 LLM 调用中。因为 Router 会话只做轻量级交互和分发，每一步通常输入很长而输出很短。合并到一次 LLM API 调用中的触发器在预填充（Prefill）阶段并行计算，因此每个请求的时间增长远慢于批次大小的增长。因此，在某种程度上，积压越多，每个决策的摊销推理时间就越低。极限取决于上下文长度以及模型在一轮中能准确处理多少触发器。

  第 7.2 节通过实验量化了批处理的效果。结合订阅与直通（第 3.2 节）和召回链（第 3.3 节），单个长期存活的 Router 会话保持了上下文的连续性，这已经足够满足我们目前团队规模的需求。

如果系统增长到单个会话真的无法承受的地步，Router 层可以在内部使用多级过滤结构，或者通过水平分片（horizontal sharding）拆分成多个会话。它的内部设计就归结为同样的连续性与吞吐量之间的权衡。分片越细，Router 层获得的并发吞吐量就越高，但分片间共享的记忆和上下文就越少。在全局记忆问题得到解决之前，这种权衡将一直存在。

2.2 Worker 层

Worker 层由执行任务的会话组成。每个 Worker 都有隔离的上下文和全套执行工具，并专门负责一个任务。Worker 会话直接决定每个任务的结果及其代码质量，因此它们通常需要最强大的模型。

Worker 从不直接与人交互。它们的推理过程和工具调用留在外部渠道之外。相反，每个 Worker 向 Router 层报告其状态，由 Router 层处理对用户的所有回复。这样，系统既保持了并发性，又保持了输出的质量，而且不会出现多个会话分别回复造成的混乱。

当任务并发运行时，每个 Worker 都在处理自己的任务，平级 Worker 通常不需要直接通信。Worker 之间的冲突往往出现在共享的工作环境中，例如同一个 PR。只要涉及的 Worker 都订阅了该环境的 Thread（线程），它们就会收到相同的事件通知（第 3.2 节），并有机会自行发现和解决冲突。Router 层负责中转少数需要跨任务协调的情况。

与 Router 层一样，Worker 内部也不必是单个会话。对于复杂的任务，一个 Worker 可以创建子智能体（subagents）或者本身就是一个 Agent Team，这对上层的 Router 层是透明的。相同的结构也适用于代码协作，其中独立的任务（如复现问题、审查 PR 和开发功能）可以同时进行而不会相互阻塞。它也适用于个人智能体场景，即使个人智能体通常只提供一个聊天页面。当用户在该聊天中同时讨论多个主题时，页面保持了对话的连续性。同时，后端可以为每个主题分派一个单独的 Worker，并行处理任务和起草回复。

3. 事件驱动的触发器

要使超级智能体具有主动性，我们首先需要改变驱动系统的方式。智能体的主要输入不再是人类逐个输入到会话中的提示词，而是来自环境的半结构化事件。在超级智能体中，这些环境事件（如群聊消息、电子邮件、日历提醒、代码审查评论和 CI 结果）被称为触发器（Triggers）。因为智能体监听并响应触发器，所以它不必像单会话智能体那样在每次运行前等待人类的命令。

下面的小节将跟随一个环境事件从到达至处理的全过程，分为四个递进的步骤。首先，结合代码和模型的两阶段策略将大量噪音过滤掉（第 3.1 节）。接下来，订阅与直通机制将事件路由给 Worker（第 3.2 节）。然后，内联与溢出（Inline & Spill）以及召回链将密集上下文注入模型，并按需召回更多内容（第 3.3 节）。最后，推测执行允许智能体根据环境信号在后台提前行动（第 3.4 节）。

3.1 事件过滤

一旦连接到真实的群聊和代码平台，系统就会看到一个噪音大、触发率低的事件流：日常绝大多数消息不需要智能体采取行动。让大模型从头开始判断每个事件会带来太多延迟并消耗太多算力。借鉴计算机系统中的快路径/慢路径（Fast Path / Slow Path）思想，我们将大模型推理视为灵活但昂贵的慢路径。频繁、定义明确且稳定的判断可以改为确定性代码，作为低延迟、低成本快路径。

因此，系统首先过滤每个传入事件。确定性策略在调用任何大模型之前消除噪音，只有需要语义理解的候选事件才会送给模型。我们使用结合了程序化策略和大模型的两阶段过滤：

· 程序化策略（快路径）：代码对确定性条件（如事件源、群组以及用户或机器人白名单）运行快速准入检查。例如，每个源可以设置为“仅响应明确请求”、“视为候选事件”或“忽略”。这些检查在调用任何模型之前丢弃了大多数无关消息。

· 语义策略（慢路径）：通过程序化检查的候选事件进入 LLM，由其根据上下文和作为提示词编写的策略来决定是否采取行动。语义阶段也作为自然语言的扩展点，因此人类可以随时通过提示词开启或关闭策略，或添加新策略，如下所示：

(两阶段过滤：程序化策略首先筛除大多数无关消息，语义策略判断剩下的部分)

3.2 事件路由

第 2 节的全局 Router 层保持了跨渠道交互的连续性。但是，如果分配给任务的所有后续事件仍必须通过 Router 层，这个单一的全局节点将承受沉重的负载并减慢响应速度。因此，快/慢路径的划分也适用于路由过滤后的事件。Router 层仅处理新任务的冷启动和跨任务协调，而代码将后续事件直接发送给拥有它们（订阅了它们）的 Worker 会话。

在真实的工作流中，同一个 GitHub PR、IM 主题或电子邮件链上的连续事件形成了一个事件流，我们称之为 Thread（线程）：

(Thread 示例：同一个 IM 主题或 GitHub PR 下的连续触发器形成一个 Thread)

当 Router 层为 Thread 中的第一个事件创建 Worker 会话时，该 Worker 直接订阅该 Thread。从那时起，事件路由遵循下面两条路径之一：

· 已订阅（快路径）：代码将 Thread 中的后续事件直接直通（pass-through）给已订阅的 Worker，因此 Router 层不需要另一次工具调用来转发它们。如果新事件超出当前任务范围，Worker 可以退订或将事件交还给 Router 层重新分发。

· 未订阅（慢路径）：Router 层依然能看到每个事件，这使其能够跟踪全局状态，但它仅评估和分发还没有订阅者的新事件。

(订阅与直通：初始事件经过 Router 层创建一个已订阅的 Worker，同一 Thread 中的后续事件直接进入该 Worker)

Thread 与 Worker 之间的订阅是多对多的。一个 Worker 可以订阅多个相关的 Thread，一个 Thread 也可以有多个订阅的 Worker。当 Worker 在同一个工作环境或讨论中重叠时，共享 Thread 中的每个新事件都会直接同时直通给其所有订阅者。然后 Worker 们就有机会了解彼此在做什么，并自行解决冲突，无需点对点通信。在输出端，Worker 仍然向 Router 层报告关键结论，Router 层处理对用户的所有回复并保持全局记忆同步。

3.3 上下文组织

在事件被过滤并路由到目标会话后，接下来的问题是向模型上下文窗口中放入多少信息。输入不再是有限的人类提示词，而是环境不断产生的半结构化事件，因此工具调用和事件注入的设计更为重要。注入太多，窗口会填满，稀释模型的注意力。注入太少，模型不得不反复调用工具来阅读上下文，这增加了执行步骤。浪费上下文窗口就是在浪费模型的智能。

因此，我们可以将有限的上下文窗口视为缓存。借用编译器优化和计算机系统术语，上下文注入归结为两个基本操作。内联（Inline）将可能很快需要的信息直接放入当前上下文窗口，节省额外的工具调用往返。溢出（Spill）在完整信息超出预算或很少使用时将其保留在窗口外，只在窗口留下引用或摘要，模型可以通过它们按需阅读完整信息。

结合计算机系统设计中的经典思想——局部性（locality），内联与溢出可以逐步改进事件注入和工具调用：

· 从最小信息开始：起初，只给模型当前对象的 ID 及其内容的摘要。

· 通过局部性逐步内联相关信息：内联模型可能很快需要的信息。从紧密相关对象的 ID 开始，然后添加空间或时间上相邻的内容。例如内容的前 50 个字符、某条消息前后的 IM 消息以及它回复的那条消息、同一个代码审查讨论中的相邻评论。

· 溢出超出限制的内容：对无法完整内联的长内容设置较小的长度上限，并将超出的部分溢出到窗口外。一个简单的做法是截断内容并留下指向其继续位置的指针，这样模型在需要时可以调用工具读取剩余部分。

Router 层有它自己的上下文问题。许多后续事件直接直通给 Worker，且过去的任务在长期运行中不断累积，因此 Router 层无法将每个任务的完整历史保留在其上下文窗口中。

然而，当用户在其他渠道提到旧任务时，Router 层依然必须恢复该任务的上下文。对系统中的每一种对象一致地应用内联与溢出，形成了一个按需的、多跳的检索机制：召回链（Chain of Recall）。它减少了 Router 层在长时间运行中丢失早期信息的程度，如下所示：

(召回链：召回对象时内联下一跳对象的 ID，让上下文沿着引用逐跳扩展)

系统为触发器、Thread 和 Worker 会话等对象赋予唯一的 ID，并在注入某个对象时内联紧密相关对象的 ID。这些 ID 将对象连接成一个引用图。每次通过工具调用召回一个对象时也遵循内联与溢出，因此返回结果中内联了下一跳对象的摘要和 ID。从当前事件开始，模型可以顺着这些引用逐跳召回上下文，直到满足需要。

例如，模型可以从当前消息的 Thread 开始，顺着内联的 ID 找到相关的 Worker 会话，然后找到与该 Worker 关联的另一个代码审查 Thread。

3.4 提前行动

我们还从计算机系统借用了推测执行（speculative execution）。基于环境信号，智能体在知道结果是否会被使用之前就开始在后台工作。它利用额外的后台算力，使人们等待的时间更少，需要介入的频率更低。证明有用的结果被交付，其余的被丢弃。

在个人智能体场景中，当收到会议邀请邮件或待办消息时，智能体可以在后台检查日历冲突、收集背景信息并起草回复。用户接下来只需查看草稿并发送。相同的方法适用于研发协作。例如，在我们内部的 DeepSeek Harness 用户群中，我们配置了一个“静默复现与修复”策略。当有人报告问题或讨论提议的变更时，智能体首先在后台尝试复现该问题并寻找修复。只有在确认问题并找到简单的修复后，它才会交付结果。否则，它全程保持沉默。

(推测执行示例：当群里还在讨论解决方案时，超级智能体已经在后台开启了包含修复的 PR)

4. 全双工多渠道交互

第 2 节的双层架构在上下文层面上保持了跨渠道交互的连续性。但要使日常交互既连续又高效，还需要解决两个问题：交互如何工作，以及交互在哪里发生。第一是防止耗时的后台操作阻塞前台对话。异步 ReAct 循环解决了这个问题，因此会话可以在不等待上一条命令或任务完成的情况下随时接受新指令（第 4.1 节）。第二是针对每个通信渠道以及人们在那里的沟通方式，量身定制智能体回复的内容和细节程度（第 4.2 节）。

4.1 全双工

在经典的 ReAct 循环中，当模型进行同步的 run() 工具调用时，循环会阻塞，直到工具完成并返回其最终结果。在此之前，会话无法响应用户的任何新内容。为了消除这种阻塞，对话必须从基于回合的半双工模式转变为全双工模式，如下所示：

(经典与异步 ReAct 循环对比：异步调用立即返回“已开始”通知，且会话在后台工具运行时依然可以响应新消息)

为了实现这一点，我们用异步的 start() 和 stop() 调用替换耗时的命令和工具调用，将循环转变为异步 ReAct 循环。调用 start() 立即返回“Started（已开始）”，循环不再等待工具。当工具在后台完成时，系统将其最终结果作为新的事件消息传递给会话。基于上下文，模型也可以调用 stop() 来结束运行时间过长的后台命令。

前台对话与后台任务解耦后，智能体可以在耗时的后台任务运行时对人类做出响应。新的输入将在当前推理步骤结束时立即处理，而不是在后台工具完成后才处理。

DeepSeek Harness 已经实现了这种异步任务机制，但尚未默认启用。

4.2 多渠道

人们在群聊、电子邮件和 GitHub 讨论中的交流方式各不相同。智能体需要调整细节程度和回复方式以适应每个渠道。详细的推理和工具调用日志可能适合单用户终端，但原封不动地发布在群聊中可能会让参与者信息过载。

在超级智能体中，双层架构已经解决了这个问题的部分。每个任务冗长的推理过程和频繁的工具调用留在其 Worker 会话内，绝不会直接进入外部渠道，而 Router 层处理所有的外部交互。除此之外，系统需要连接到用户每天依赖的工作环境，并使用提示词为每个渠道设置交互规范：

· IM 和其他即时通讯渠道：保持沟通轻量，尽可能少打扰别人。像人类同事一样，只有在需要决策或审批时才通知，只问直接的问题，给出简短的结论。我们验证过的一个简单有效的硬性规则是：每次回复最多 100 字。

· 异步渠道（如 GitHub、电子邮件和文档）：提供结构化、信息密集的输出。例如，在创建或更新 PR 时，按照项目惯例写出完整的问题背景、变更说明和验证结果。在个人智能体场景中，直接起草结构化的电子邮件和文档摘要。

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

默认情况下，本地智能体将三样东西绑定到一台设备上：运行 Agent Loop 的计算资源、必须持久化的会话状态，以及执行环境（如代码仓库和本地工具链）。

一旦设备休眠或离线，智能体就会停止，也无法访问其他设备上的环境。为了使超级智能体持久在线并连接到其任务所需的真实工作环境，我们借鉴了计算机系统中的算存分离理念，分两步将这三者解耦。首先，我们将计算资源与会话状态分离，使智能体摆脱任何单台机器的生命周期，并使其在云端持久在线（第 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（将大脑与手解耦）”采取了相同的方法：执行框架保持无状态，会话日志存储在其外部，执行环境通过统一接口按需连接。

不同之处在于目标场景。Anthropic 的文章描述的是托管服务，主要讨论按需创建的沙箱和客户 VPC 内的资源。我们首先需要连接人们每天使用的个人电脑，这些电脑包含未提交的更改和本地凭证，并且可能只是间歇性地在线。因此，我们的设计支持 BYOM（Bring Your Own Machine，自带机器），将用户自己的开发机或个人电脑连接到云端智能体。它也支持云端托管机器和按需创建的计算环境。

因此，智能体不再绑定到一台机器上。它可以在执行设备之间切换，在任务需要的任何环境中运行命令和读取上下文。它甚至可以与只是间歇性在线的设备一起工作：当用户的个人设备重新连接时，云端智能体会自动启动并完成需要在该设备上运行的任务。下图展示了由此产生的结构，计算、持久状态和执行环境在两个层面解耦：

(算存分离和解耦的执行环境：在云端，Agent Loop 与持久状态分离，并通过端点守护进程按需访问不同的执行环境)

6. 看门狗（Watchdog）

保持持久在线需要的不仅仅是第 5 节中的算存分离：系统还必须在长期运行期间自动从异常中恢复。一个持久在线的分布式系统如果只依赖其内部逻辑，很少能保持长期可靠。它需要在主系统外部有一个独立的控制循环。

智能体系统需要的也不仅仅是传统的进程存活探测或监控脚本。许多异常不是崩溃：进程仍在运行，但模型陷入了无成效的循环或偏离了目标。因此，长期运行的智能体系统不仅要监控基础设施的存活状态，还要监控任务进度。

我们外部的控制循环是一个独立的 Watchdog 会话，它运行在主系统外部，由定时消息驱动。Watchdog 处理诸如 API 错误和状态恢复失败等基础设施故障。它还使用模型来判断每个 Worker 是在取得实质性进展还是偏离了整体目标。它及时修复异常，并不断复查瞬态外部故障，直到解决。

因为 Watchdog 本身就是一个拥有全套工具的智能体会话，维护人员可以用自然语言问它为什么某些东西失败了。他们还可以让它在系统运行时纠正主系统的行为，例如通过添加或删除提示词，或者调整触发规则。

7. 初步实验

我们在两个层面对核心调度和路由设计进行了初步实验：整个系统和 Router 层。端到端实验比较了双层架构与单会话设计，并测量了订阅与直通机制的效果（第 7.1 节）。第二个实验测试了 Router 层中的批处理（第 7.2 节）。实验使用了合成工作负载和简化环境，部分设置可以更加严谨，因此以下结果仅供参考。

7.1 消融实验（Ablation Study）

四种端到端设计同时运行，由群聊和 GitHub CI 消息流驱动。每次运行约有 300 条消息，其中约 20 条是工作请求。其余是闲聊、跟进、取消和 CI 消息。编码工作由一个简单消耗时间的工具模拟，因此实验测量的是系统的调度和协调，而不是其执行单个任务的能力。每种设计运行 5 次。

这四种设计分别是：超级智能体（Super-agent）、无直通的超级智能体（Super-agent without Pass-through），以及使用不同提示词的两种单会话加子智能体工具（Single Session with Subagent tool）版本。

· 中性提示词（neutral prompt）：“在合适的时候使用子智能体来完成某项工作……”。

· 委派优先提示词（delegation-first prompt）：“聊天的每条消息都会到达你这里，因此你自己运行的工作总是因为新消息而停下来。更倾向于把每项工作交给它自己的子智能体，你自己只做小事情……”。

(四种设计下工作请求的累计到达和累计完成情况)

注：每种设计运行 5 次。任务完成时间从工作请求测量到结果消息。

超级智能体在 p50 下 12.4 分钟、p95 下 15.7 分钟完成任务，明显快于单会话加子智能体工具的设计。单会话设计较慢是因为在这个实验中，它在很大程度上依赖于其提示词：主会话经常决定自己完成工作，这使得完成时间较长且不稳定。

在使用中性提示词时，模型在 5 次运行中没有一次调用子智能体。所有工作都在主会话中运行，新消息不断打断它，p95 达到了 29.5 分钟。在使用委派优先的提示词时，模型在 5 次运行中有 4 次进行了委派。

完成时间有所下降，但总体上仍长于超级智能体。在剩下的一次运行中，模型判断工作“很小”并自己做了，这导致了图中紫色的长尾。

单会话必须依赖提示词工程和模型的临场判断来决定是否委派。

双层架构在系统层面缓解了这个问题：Router 不自己执行工作，并且每个 Worker 只接收来自其订阅的 Thread 的消息。

因为超级智能体维护了几个独立的会话，它每次运行使用的缓存读取 Token 比单会话设计多，用 Token 换取更短、更稳定的完成时间。无直通的超级智能体完成任务的时间与超级智能体大致相同，但其 Router 每次运行做出的决策多出约 30%，总缓存读取 Token 从 23.2M 增加到 31.8M，增加了约 37%。

因此，在这种工作负载下，直通并不能使任务完成得更快或更好，但它大幅削减了 Router 会话的 Token 使用量和推理开销。

7.2 Router 层批处理

为了找出单个长期存活的 Router 会话在第 2.1 节所述的批处理下能处理多大负载，我们对 Router 层单独进行了压力测试。Router 调用真实的模型，而 Worker 使用模拟模型。

我们逐步将需要决策的触发器到达率从大约每分钟 1 个提高到每分钟约 40 个。在每个速率下，我们测量平均批大小、每个请求的时间以及每个决策的摊销推理时间。一个决策可能跨越多个 LLM 请求，因为 Router 在分发之前可能需要进行多步推理或通过工具调用召回上下文，所以每个决策的时间可能超过每个请求的时间。

(不同触发器到达率下 Router 会话的批大小、每请求时间和每决策摊销推理时间)

如上图所示，当需要决策的触发器到达率从大约每分钟 1 个上升到每分钟约 40 个时，平均批大小从 1.0 增加到 2.8。每个请求的时间仅从 2.5 秒增长到 3.9 秒，增长慢于批大小，因此每个决策的摊销推理时间从 6.4 秒下降到 1.6 秒。

换句话说，当外部事件突发到达时，Router 层通过自动合并堆积的事件来提高其有效吞吐量。批处理也解释了第 7.1 节的结果：移除直通提高了 Router 的峰值负载，然而单个 Router 仍未达到其吞吐量极限。

因此，在我们目前的团队规模下，没有必要以牺牲全局上下文连续性为代价过早地对 Router 层进行分片。

8. 开放问题

第 2 到第 6 节描述了构成超级智能体基本架构的五个模块。第 7 节的实验表明，当许多任务并发运行时，其核心调度和路由机制能够正常工作。系统之所以能保持相对简单，很大程度上是因为在当前阶段，我们简化了工程设计和所支持的场景。

除了这些简化之外，在四个领域仍存在未解决的问题：扩展双层架构（8.1 节）、在没有会话的情况下与智能体协同工作（8.2 节）、上下文边界与智能体到智能体（A2A）通信（8.3 节），以及安全与隐私（8.4 节）。

8.1 如何扩展双层架构

到目前为止，一个简单的组合以较低的工程成本覆盖了我们大部分的日常工作：单个长期存活的 Router 会话、订阅与直通，以及 Worker 之间没有直接通信。一旦任务变得更大、耦合更紧密，以至于单个 Router 会话无法处理，每一层的正确结构尚未确定。

我们仍然需要测试更多的场景，以找出 Router 层何时应该分片以及分片多细，以及平级 Worker 何时应该直接通信以及采用何种协作拓扑。系统与模型的协同设计是另一个值得探索的方向。专门针对 Router 层工作（如判断事件、批量分发和召回上下文）训练模型，可能进一步提高 Router 层的吞吐量和决策质量。

记忆也限制了系统能够扩展的程度。长期存活的 Router 层，以及在引用图上的召回链，主要处理近期任务和会话历史的按需检索。一旦系统运行了几个月或更长时间，长期记忆将成为主要瓶颈。

8.2 如何在没有会话的情况下与智能体工作

因为双层架构将多会话管理对用户隐藏起来，会话不再是产品设计的主要关注点。但是，一旦底层的执行会话不再直接映射到界面中的对话，一个新问题就出现了：如何向用户展示任务，以及什么样的交互和项目管理形式让人感觉自然。

我们认为聊天窗口成为交互的中心，部分原因是路径依赖。更多的交互可能会转移到特定领域的界面中，就像我们的超级智能体实例直接在 GitHub Issues 和 PR 中工作一样。会话也可以保留在界面中，因为用户习惯了它们，但用户看到的一个对话不需要对应一个底层会话。

前面的小节主要涵盖了任务开始和审批时的人类交互。但在当前这个过渡时期，由于模型正在快速改进，许多任务在推进到中途时仍然需要人。产品设计如何在不让用户失去自主后台工作效率的情况下，让他们对关键细节进行逐步干预，这也是值得探索的。

例如，用户可以在后台执行期间的任何时刻介入、接管或与智能体实时合作。

总体而言，用户需要的项目管理和交互在很大程度上取决于他们的工作领域和个人风格，因此最终的设计可能会高度定制化。DeepSeek Harness 拥有开放的架构，这使得此类定制更容易得到支持。

8.3 如何定义上下文边界并通过 A2A 协作

到目前为止，我们已经讨论了单个超级智能体实例的设计，并假设其范围内的所有信息都汇聚在一个全局上下文中。随着使用范围从个人和小团队扩展到更大的组织，如何配置超级智能体实际上变成了决定哪些上下文共享、哪些上下文隔离。组织内需要共享上下文的部分共享一个实例，需要隔离的部分各自拥有自己的实例。

一旦组织内部或跨组织存在隔离的实例，跨边界的协作就是 A2A 通信，例如每个成员的个人智能体与团队共享的超级智能体之间。这里的 A2A 指代的是广义的智能体到智能体通信，并非某个特定的协议。我们仍需研究不共享底层上下文、且各自代表不同权限边界的智能体，如何能够安全可靠地进行通信和协作。

8.4 如何确保安全与隐私

第 3 节的事件驱动设计让更广泛的环境来驱动智能体，但它也使智能体暴露在更多不可信的输入中。除非安全与隐私得到妥善处理，否则超级智能体只能在非常小的可信范围内工作。

例如，第 5 节的设计将 Agent Loop 运行在云端，并在执行设备上安装轻量级守护进程。它隐含地假设云端和端点相互信任。但是云端托管的 Agent Loop 不断接收外部事件，而端点设备保存着私有代码、敏感数据和本地凭证。连接两者会带来重大的安全和隐私风险。如果服务端入侵或提示词注入危害了 Agent Loop，与其连接的所有端点设备都可能被控制。

即使云端从未被攻破，凭证也可能泄露。只要端点上的凭证可以进入模型的上下文，正常执行就可能暴露它们。因此，智能体需要一种无需看到凭证即可使用凭证的方法。为了使这种架构得到更广泛的使用，它必须在保持从许多不同环境召回上下文能力的同时，解决这些安全和隐私问题。

9. 结论

本文的设计并没有提出新理论，而是将计算机系统中的经典工程思想应用到了智能体系统的构建中。随着技术的发展，具体的实现方式会发生变化，但我们相信其背后的系统设计思想将在更长时间内保持有用。

我们基于这些思想和 DeepSeek Harness 构建的内部超级智能体实例已经在持续运行。它每天都在帮助复现和修复问题、响应代码审查，以及开发 DeepSeek Harness 本身。

正如我们在开头提到的，大模型在单个任务上需要的人类干预越来越少，因此进一步生产力提升的瓶颈正在转移到人类的注意力上。

双层架构、事件驱动设计、异步多渠道交互、算存分离以及外部看门狗，这些技术结合在一起，让系统接管了管理会话和同步上下文等繁琐的工作。人们则可以进一步向上移动，从执行细节转向更高层次的决策与审批。

这样构建的智能体不再仅仅是一个等待指令的聊天窗口。它变成了一个自主的协作者，在人们使用的数字环境中保持在线。

对于个人来说，它可以是一个跨设备帮助处理日常任务的个人智能体。

对于团队来说，它成为研发工作流的一部分，承担任务并推动其向前发展。我们相信，随着模型和系统架构的共同演进，这种更自主的工作方式可能成为人机协作的常态。

本文中的部分设计已在 dsh-superagent-prototype 中实现。此插件仅用于验证技术方法的原型，并非 DeepSeek 的官方产品。