DeepSeek发布全新Agent架构

2026-11-01 · 旺信证券

10月31日晚，DeepSeek Harness 团队在官方公众号发表技术文章《Super-agent 设计探索：迈向更自主的Agent 系统》。 DeepSeek表示，模型能力提升催生了新的应用形态，个人助手（Personal Agent）开始集中涌现。然而，现有主流 Agent设计还难以在多任务和团队协作的规模上支撑这一模式，多任务上限取决于人的注意力。

10月31日晚，DeepSeek Harness 团队在官方公众号发表技术文章《Super-agent 设计探索：迈向更自主的Agent 系统》。

DeepSeek表示，模型能力提升催生了新的应用形态，个人助手（Personal Agent）开始集中涌现。然而，现有主流 Agent设计还难以在多任务和团队协作的规模上支撑这一模式，多任务上限取决于人的注意力。通过双层架构、事件驱动、异步多信道交互、存算分离与外部 Watchdog等思路，DeepSeek团队突破了这些限制，系统在底层接管了繁琐的会话管理与上下文同步，使人类得以从具体的执行细节进一步上移到更高层的决策与验收。

DeepSeek把这种Agent形态及其系统架构称为 Super-agent，文章提到，目前，基于这套思路构建的内部Super-agent实例已经在持续运行，日常参与问题复现与修复、代码审查响应与 DeepSeek Harness自身的迭代。当团队成员在群聊中反馈软件问题时，即使没有人主动@ AI，它也能识别潜在缺陷，在后台尝试复现问题、寻找修复方案。

Super-agent设计探索：迈向更自主的Agent系统

本文是一篇面向工程实践的架构思路探讨，并非对 DeepSeek Harness 现有产品功能的介绍。

过去一年里，以 Coding Agent 为代表的单任务 Agent 已经证明，模型能够使用工具解决复杂问题，且越来越少需要人类持续监控和逐步干预。与此同时，模型的多 Agent 协同能力也在提升，使跨会话的组织与调度变得可行。随着人类在底层执行中的参与减少，人的角色正逐步上移到更高层的决策与验收。

模型能力的这一提升，也催生了新的应用形态。近期个人助手（Personal Agent）开始集中涌现，它们直接接入日常的消息、日程、邮件与工作平台，持续观察信息流并协助处理事务。这种持续在线、事件驱动的工作模式并不局限于个人场景，个人助手只是其中一类应用；在 软件开发 等商业场景中，它同样很有价值。

然而，现有的主流 Agent 设计还难以在多任务和团队协作的规模上支撑这一模式。Agent 的工作模式仍然以单一 Session 为基本单位，不同 Session 之间彼此独立。当用户并行推进多项工作时，必须手动切换并记住各个 Session 的上下文，而据我们观察，一个人通常只能同时跟进 3 到 5 个活跃 Session。在这种设计下，单任务的上限取决于模型能力，多任务的上限取决于人的注意力。

如果只在现有的本地单会话 Agent 上借助 CLI、MCP 或外部连接器做简单扩展，Agent 虽然也能接入外部消息，但仍受制于单会话同步阻塞、多任务上下文混乱、本地设备离线即停止运行等问题，需要大量人工维护。

要突破这些限制，需要打破 Agent 与单次手动会话的绑定，使其成为一个能跨会话保持上下文、同时推进多项复杂任务且互不干扰的连续实体。我们把这种 Agent 形态及其系统架构称为 Super-agent 。

例如，在我们内部基于 DeepSeek Harness 运行的 Super-agent 实例中，同一个开发任务可以在 IM 和 GitHub 之间连续推进；这个实例还会持续观察公共群聊中的反馈，在无人 @ 的情况下主动定位根因并提交修复 Pull Request：

同一个任务在 IM 群聊与 GitHub Pull Request 评审之间连续推进

持续关注公共群聊，在无人 @ 的情况下主动识别缺陷并提交修复 Pull Request

具体来说，我们认为 Super-agent 具备以下四个基础特征：

连续： 用户可以直接在 IM 聊天、GitHub 评论等熟悉的工作界面与它交互，感觉始终只存在一个 Agent，不需要去想“Session X 的上下文中是否有 Y 信息”。例如，用户先在 IM 上提出采用方案 A、随后在 GitHub Pull Request 评论里改为方案 B，它能理解并调整执行方向。

高效： 交互响应迅速，同时能并行、高质量地完成多个复杂任务。无需等上一个命令或任务完成，就能接受下一条指令。

主动： 无需等待用户逐条下达指令，能持续观察环境事件并主动推进值得处理的事项，不需要介入时则保持安静。

持久： 始终在线、直接接入用户真实的工作环境，并在长期运行中遇到异常时自动恢复。

单个 ReAct Loop 无法同时支持上述四个特征，底层需要一套相应的架构。相似的设计约束会导出相似的架构选择。我们认为，无论是面向个人的助手，还是面向 软件开发 等商业场景的 Agent，如果目标是构建一个持续在线、并发响应环境事件的系统，那么在底层就可能会采用相近的架构。同时，这一过程中面临的许多问题与传统 计算机 系统长期探讨的问题具有很高的相似性，因此 计算机 系统中的许多经典设计思想在这里同样适用。

在具体落地中，这套架构会有不同的变体，但我们认为以下五个模块构成了支撑上述四个基础特征的基本框架：通过双层架构（第 2 节）兼顾连续交互与高效并发，通过事件驱动（第 3 节）实现主动响应，通过面向人的交互（第 4 节）在交互过程中同时做到连续与高效，并通过计算、状态与环境的分离（第 5 节）及 Watchdog（第 6 节）实现跨设备的持久在线与异常自愈。

下图展示了 Super-agent 的整体系统架构，图中各模块的标号 [2] 至 [6] 分别对应下文第 2 至第 6 节：

Super-agent 整体系统架构，标号 [2] 至 [6] 对应下文第 2 至第 6 节

要同时实现跨信道的连续交互与多任务的高效并发，系统在底层会话组织上面临连续性与吞吐量之间的根本权衡（Trade-off）。

如果每条事件都交给同一个 Session 处理，虽然上下文最连续，但受限于单个 ReAct Loop 串行执行的速度上限，任务完成耗时长、吞吐低，且多任务的中间细节混杂在一起也会影响完成效果。

反过来，如果每条事件都直接新开独立的 Session 去处理，虽然并发吞吐最高，但一旦任务之间并不完全独立，缺少全局上下文会让各个 Session 的结果彼此割裂，同时多个 Session 各自向用户响应也会造成交互混乱。

为了兼顾连续性与吞吐量，我们可以将“维护全局连续性”与“高并发执行”拆分到两个不同的层级中：由常驻的 Router 层 （2.1 节）统一承接人类交互与全局协调，由上下文隔离的 Worker 层 （2.2 节）并发执行具体任务，如下图所示：

双层架构：Router 层统一负责路由与对外交互，多个 Worker Session 隔离并发执行任务

通过这一双层架构，系统在底层接管了上下文管理与并发执行，从而在用户侧淡化了 Session 的存在，使用户面对的始终是同一个 Super-agent。从这个角度看，让用户手动管理 Session，在很大程度上是从底层 LLM API 延续下来的设计惯性；Session 应当是系统的实现细节，而不应是用户的认知负担。

在现有设计中，Session 同时承载了技术上的上下文管理与面向用户的项目管理。将产品形态与底层 Session 解耦后，面向用户的项目管理便不再受 Session 的限制，向用户暴露怎样的交互与任务管理方式成为了一个独立的产品问题。我们将在后文讨论这个问题。

这里的“双层”是逻辑上的职责划分，每一层在实现上都不必局限于单个 Session，而是可以有各自的内部结构。下文将分别介绍 Router 层与 Worker 层的设计。

Router 层是常驻的全局路由层，负责承接所有入口的人类交互。所有跨任务的信息与决策都在 Router 层中汇总，由它充当全局的序点（Sequence Point）、协调点和记忆。为了避免这一全局节点成为系统的性能瓶颈，Router 层在设计上不直接执行具体任务，只负责人类交互与任务分派，甚至可以不配备 Bash 工具。

这种由一个中心节点分派多个执行节点的结构，表面上看与常见的 Agent Team 相似，但两者的侧重点不同。常见的 Agent Team 主要用于单个复杂任务内部的步骤拆解与角色协作，由于子步骤通常耦合较紧，Team Lead 往往需要深入理解任务细节、规划子任务并高频协调各个成员，自身承担了很重的推理负载。而在 Super-agent 中，Router 层只处理任务之间的高层关联与分派，无需介入单任务内部的拆解；相反，如果通过提示词约束一个 Agent Team 的主会话不亲自执行具体任务，仅负责对外交互并将不同任务分派给各成员独立推进，那么它也可以视为这种双层架构。从我们的实践来看，Router 层的任务常常没有想象中复杂，使用较轻量的模型往往就能兼顾速度与效果。

在内部实现上，Router 层同样不必局限于单个 Session，甚至部分逻辑未必需要调用 LLM。我们选择了最直接的单个常驻 LLM Session 作为 Router 层的核心实现，并发现它并没有表面看起来那么容易成为吞吐瓶颈，因为上一轮推理期间到达的环境事件（即第 3 节的 Trigger）会积压下来、在下一轮一并处理，形成 批处理（Batching） ，而合并处理的额外开销很小：

当外部事件流平稳时，Trigger 逐条进入 Router Session，此时单次响应延迟较低；

当事件密集涌入、Router Session 开始出现排队拥堵时，上一轮推理期间积压的多条 Trigger 会自动合并，在下一次 LLM 调用中一并注入。Router Session 只做轻量的交互与分派，每步通常是长输入、短输出。把积压的多条 Trigger 合并进一次 LLM API 调用，会在 Prefill 阶段并行计算，单次请求耗时的增长远慢于批处理大小。因此在一定范围内，积压越多，单个决定分摊的推理时间越低；上限取决于上下文长度，以及模型在一轮中能准确处理多少条 Trigger。

我们将在 7.2 节通过实验定量展示这一批处理机制的效果。加上后文将介绍的订阅与直通机制以及链式召回（见 3.2、3.3 节），单个常驻 Router Session 在保持上下文连续的同时，在我们目前的团队规模下已经够用。

当规模进一步扩大、单个会话确实不足以承载时，Router 层内部也可以设计为多层过滤结构，或 水平切分（Sharding） 为多个会话。此时，Router 层的内部设计本质上是连续性与吞吐量的权衡。切分粒度越细，Router 层的并发吞吐量就越高，但分片之间的记忆与上下文连续性就会越低。在全局记忆问题被解决之前，这一权衡始终存在。

Worker 层由负责具体执行的会话组成，各个 Worker 彼此上下文隔离，挂载完整的执行工具，在独立上下文中专注完成单一任务。由于 Worker Session 直接决定任务结果与代码质量，通常需要配置能力最强的模型。

Worker 不会直接与人类交互，其推理过程和工具调用不会直接输出到外部信道，而是向 Router 层汇报状态、由 Router 层统一向用户回复，从而在保障并发度与交付质量的同时避免多个会话各自回复带来的混乱。

在多任务并发执行时，各个 Worker 独立推进任务，同层 Worker 之间通常也不需要直接 通信 。多个 Worker 在具体执行中的冲突往往出现在同一个 Pull Request 等共享工作环境中；只要它们都订阅了对应的 Thread，就会收到相同的事件通知（见 3.2 节），从而有机会自行发现和解决冲突，少数跨任务协同则由 Router 层中转。

与 Router 层类似，每个 Worker Session 在内部也不必局限于单个会话：在执行复杂单任务时，Worker 内部可以再创建 Subagent，也可以本身就是一个 Agent Team，这些对上层的 Router 层保持透明。这一结构既适用于代码协作场景（同时推进多个独立的问题复现、Pull Request 评审与特性开发而互不阻塞），也适用于个人助手场景：虽然个人助手在界面上通常只提供一个单会话的聊天页面，但当用户在同一对话框中同时讨论多个不同话题时，前端的单一聊天页负责维持交互的连续性，而底层可以为每个话题分别分派 Worker，并行推进任务、起草回复。

要让 Super-agent 具备主动性，首先需要改变系统的驱动方式。驱动 Agent 的主要输入不再是人类在 Session 中逐条键入的提示词，而是环境中的半结构化事件。在 Super-agent 中，群聊消息、邮件与日程提醒、代码审查评论、CI 运行结果等环境事件被称为 Trigger 。通过监听并响应 Trigger，Agent 不必再像单 Session 模式下那样，等人类下达指令才被动执行一次。

围绕一条环境事件从进入到处理的生命周期，下文将依次讨论四个递进的问题：如何通过程序与模型结合的 两级策略 过滤大量噪音（3.1 节）、如何通过 订阅与直通 机制将事件路由给 Worker（3.2 节）、如何利用 Inline & Spill 与链式召回 向模型高密度地注入与按需召回上下文（3.3 节），以及如何利用 投机执行 根据环境信号在后台提前行动（3.4 节）。

在接入真实的群聊与代码平台后，环境事件流呈现出显著的“高噪音、低触发率”特征，绝大多数日常消息并不需要 Agent 介入。如果对每个事件都调用大模型从头判断，延迟和算力成本都会难以承受。借鉴 计算机 系统中的 Fast Path / Slow Path 思想，大模型推理可以看作一条灵活但高成本的 Slow Path，而将已经明确且稳定的高频判断固化为确定性代码，则构成了低延迟、低成本的 Fast Path。

因此，事件进入系统后的第一步是过滤，目标是在调用大模型之前先用确定性策略筛除噪音，只将需要语义理解的候选事件交给模型判断。我们采用程序策略与大模型相结合的 两级过滤 机制：

语义层策略（作为 Slow Path）： 通过程序层准入的候选事件交给 LLM，由它根据用提示词编写的策略和上下文判断是否需要行动。语义层同时作为面向人类的自然语言扩展点，方便随时通过提示词开关或新增策略，如下图所示：

两级过滤：先由程序层策略筛除大部分无关消息，再交由语义层策略判断

第 2 节引入的全局 Router 层负责维持跨信道的连续性，但如果已分配任务的每个后续事件仍需经由 Router 层转发，这一全局节点依然会承受大量负载，推高系统的响应延迟。因此，Fast / Slow Path 同样适用于过滤后的事件路由。全局 Router 层仅负责新任务的冷启动与跨任务协调，而已确定归属关系的后续事件由程序直接发往对应的 Worker 会话，无需经由 Router 层转发。

在实际工作流中，同一个 GitHub Pull Request、同一个 IM 话题或同一封往来邮件串下的连续事件构成一条事件流，即 Thread ：

Thread 示例：同一个 IM 话题或同一个 GitHub Pull Request 下的连续 Trigger 构成一条 Thread

在 Router 层根据某个 Thread 的初始事件创建 Worker Session 后，该 Worker 会直接订阅对应的 Thread，从而将事件路由分为如下图所示的两条路径：

已订阅（Fast Path）： 同一 Thread 下的后续事件由程序直通已订阅的 Worker，无需 Router 层再次调用工具转发。若新事件超出了当前任务的范围，Worker 也可取消订阅或交回 Router 层重新分派。

未订阅（Slow Path）： Router 层仍可观测所有事件以掌握全局状态，但仅负责判断和分派尚未被订阅的新事件。

订阅与直通：初始事件经由 Router 层创建 Worker 并建立订阅，同一 Thread 的后续事件直接发往该 Worker

此外，Thread 与 Worker 之间的订阅是多对多的关系。一个 Worker 可以同时订阅多个相关的 Thread，同一个 Thread 也可以被多个 Worker 订阅。当多个 Worker 在同一个工作环境或讨论中发生交集时，该 Thread 下的新事件会同时直通给所有订阅它的 Worker，使它们无需点对点 通信 ，也有机会获知彼此的操作并自行解决冲突。而在输出侧，Worker 仍将关键结论汇报给 Router 层，由 Router 层统一向用户回复并同步全局记忆。

在事件经过过滤与路由、进入目标 Session 后，下一个问题是应当向模型的上下文窗口注入多少信息。由于系统输入从有限的人类提示词转向了环境持续产生的半结构化事件，工具调用与事件注入的结构设计变得更加重要。注入过多会挤占窗口、稀释模型注意力，注入过少又会迫使模型反复调用工具读取，增加执行步数。浪费上下文窗口，就是浪费模型的智能。

为此，我们可以将有限的上下文窗口当作 Cache 来管理。借用编译优化与计算机系统中的概念，上下文注入的设计可以归纳为两个基本操作。 Inline 是指将近期很可能用到的信息直接内联进当前上下文窗口，以省去额外的工具调用往返。 Spill 则是指将超出窗口预算或低频使用的完整信息留在上下文窗口之外，仅在窗口内保留引用或摘要，供模型按需读取。

结合计算机系统设计中经典的 局部性（Locality） 思想，我们可以用 Inline & Spill 对事件注入和工具调用逐步优化：

从最少信息开始： 最初只提供当前对象的 ID 和内容摘要。

利用局部性逐步 Inline 关联信息： 将近期很可能用到的信息 Inline 到上下文中，先附上紧密关联对象的 ID，再附带时空相邻的内容，例如内容前 50 字、IM 消息的前后相邻消息与所回复的消息，或代码评论所在评审讨论中的相邻评论。

超出上限则 Spill： 对无法全部 Inline 的长内容设定较小的长度上限，将超出部分 Spill 到窗口之外。一种简单直接的做法是截断超出部分并保留续读入口，模型需要完整内容时再调用工具读取。

此外，在大量后续事件直通 Worker、且系统在长期运行中累积了许多历史任务后，Router 层既不能把所有任务的全量历史都放入自己的上下文窗口，又需要在用户跨信道提起某个旧任务时找回上下文。将 Inline & Spill 一致地应用到系统中的各类对象后，就得到了一种按需展开的多跳检索机制，即 链式召回（Chain of Recall） 。这种链式召回过程缓解了 Router 层在长程中丢失先前信息的问题，如下图所示：

链式召回：每次召回的对象均内联下一跳关联对象的 ID，支持沿引用关系逐跳展开上下文

具体来说，系统为 Trigger、Thread 和 Worker Session 等对象赋予唯一 ID，并在注入时内联紧密关联对象的 ID，使这些对象在底层构成一张引用图。由于每一次调用工具召回的对象本身同样遵循 Inline & Spill，其返回结果中又会内联下一跳关联对象的摘要与 ID，模型便可以从当前事件出发，顺着引用关系逐步按需召回上下文。

例如从一条当前消息读取所在 Thread，再从 Thread 内联的 ID 追踪到相关的 Worker Session，进而找到该 Worker 关联的另一个代码评审 Thread。

借鉴计算机系统中的 投机执行（Speculative Execution） 思想，Agent 可以在还不确定结果是否会被采用时，根据环境信号在后台提前尝试，通过消耗额外的后台算力来减少人类的等待与介入成本。结果有价值就交付，没有价值就丢弃。

在个人助手场景下，当收到一封会议邀约邮件或待办消息时，Agent 可以先在后台核对日程冲突、搜集相关背景资料并备好回复草稿，待用户过目后即可直接确认发出。在研发协作场景下同样如此，例如我们在公司的 DeepSeek Harness 内部用户群中配置了一条“静默复现并修复”策略：当群里有人反馈问题或讨论改动方案时，Agent 先在后台尝试复现并寻找修复方案，只有在确认问题并找到简单的修复方案后，才会把结果交付给用户，否则全程保持安静。

投机执行示例：群内还在讨论解决方案时，Super-agent 已在后台提交了修复 Pull Request

第 2 节的双层架构从上下文层面保证了跨信道的连续，但要在实际的人机交互体验中同时做到连续与高效，还需要在交互方式与交互渠道上解决两个问题：一是如何通过 异步 ReAct Loop 消除后台耗时操作对前台对话的阻塞，使会话无需等待上一个命令或任务完成即可随时接受新指令（4.1 节）；二是当交互发生在用户熟悉的不同工作信道时，如何让系统的输出方式匹配对应信道的带宽与人的使用习惯（4.2 节）。

在经典的 ReAct Loop 中，模型发起一次同步的 run() 工具调用后，循环会阻塞，直到工具执行完毕并返回最终结果，在此期间会话无法响应任何新的用户输入。要消除这一阻塞，需要将对话从一问一答的半双工模式转变为全双工模式，如下图所示：

经典 ReAct Loop 与异步 ReAct Loop 对比：异步调用立即返回 Started 通知，后台工具运行期间仍可响应新消息

为此，我们将耗时的命令与子任务工具调用改为异步的 start() 和 stop()，构成 异步 ReAct Loop 。模型调用 start() 后立即收到“已启动（Started）”的返回，循环不再等待该工具；在后台工具执行完成后，系统再将最终结果作为一条新的事件消息投递进会话；同时，模型也可以根据上下文调用 stop() 主动终止执行时间过长的后台命令。

由此，前台对话响应与后台任务执行得以解耦，Agent 在后台运行耗时任务的同时也能响应人类输入。新输入在当前推理步结束后即被处理，不必等待后台工具完成。

这一异步任务机制已经在 DeepSeek Harness 中实现，但尚未默认开启。

不同工作信道具有不同的信息密度与交互习惯，系统的输出需要与之匹配。如果将面向单人终端的交互方式直接搬入群聊，把冗长的推理过程与密集的工具调用原样输出，在多人协作中极易造成信息过载。

在 Super-agent 中，双层架构已经解决了其中一部分问题：具体任务中冗长的推理过程和密集的工具调用都被隔离在 Worker Session 内部，不会直接输出到外部信道，而由 Router 层统一负责对外交互。在此基础上，系统还需要接入用户日常使用的各类工作环境，并通过提示词针对不同信道定制交互规范：

IM 等即时通讯信道： 侧重低打扰的轻量沟通，像人类同事一样只在需要决策或验收时发送通知，只问直接问题、给简短结论。我们验证过的一条简单有效的硬性规定是单次回复不超过 100 词。

GitHub、邮件与文档等异步信道： 侧重结构化、高信息密度的异步交付，例如在创建或更新 Pull Request 时按项目规范撰写完整的问题背景、改动说明与验证结果，或在个人助手场景下直接起草结构化的邮件与文档摘要。

现有的本地 Agent 默认将推进 Agent Loop 的 计算 、需要持久保存的会话 状态 ，以及代码仓库与本地工具链等执行 环境 绑定在同一台设备上。一旦设备休眠或离线，Agent 就会停止运行，且无法访问其他设备上的环境。要让 Super-agent 做到持久在线并灵活接入各类真实工作环境，我们可以借鉴计算机系统中 存算分离（Compute-Storage Separation） 的思想，分两步解耦这三者的绑定：第一步先将推进 Agent Loop 的计算与持久化的会话状态分离，使 Agent 摆脱单机生命周期限制、实现云端持久在线（5.1 节）；第二步再将云端的 Agent Loop 与重状态的执行环境解耦，让真实工作环境留在原地并支持跨设备访问（5.2 节）。

推进 Agent Loop 的计算可以做成无状态的，需要持久保存的是会话状态。因此，第一层解耦是将推进 Agent Loop 的计算放入云端无状态的弹性计算容器中，而将 Session 等持久化状态存入数据库。无状态计算容器可以水平扩展、重启或替换，会话与任务的连续性则由持久化存储保障，从而使 Agent 摆脱单台本地设备的生命周期限制，实现云端持久在线。