DeepSeek Super-agent：让 Agent 从单次对话走向持续自主运行

10 月 31 日，DeepSeek 团队发布了一篇文章《Super-agent 设计探索：迈向更自主的 Agent 系统》，讨论了下一代 Agent 系统应该采用怎样的架构。

文章还公布了一个开源研究原型：dsh-superagent-prototype。

这篇文章比较有意思的地方在于，它没有继续讨论如何提升模型的推理能力、如何设计 Prompt，或者如何让多个 Agent 更好地协作完成一个任务，而是把注意力放在了一个更基础的问题上：

当 Agent 已经具备独立完成复杂任务的能力之后，应该如何设计一个能够长期运行、同时处理多个任务，并且尽量减少人工干预的 Agent 系统？

这涉及的不仅是 Agent 的推理能力，还有任务调度、事件驱动、上下文管理、系统可靠性等传统软件工程问题。

本文主要介绍 DeepSeek 提出的 Super-agent 架构，以及其中值得关注的几个设计。

一、现有 Agent 的问题在哪里？

过去一年，Coding Agent 的能力已经有了明显提升。

例如，使用 Claude Code、Codex 等工具时，我们可以直接交代一个相对复杂的开发任务，让 Agent 自行阅读代码、修改文件、运行测试，最后提交结果。

但当我们同时处理多个任务时，问题就出现了。

假设现在有三个任务：

1. 修复生产环境的一个 Bug。
2. 开发一个新的 API 接口。
3. 对某个 Pull Request 进行代码审查。

我们通常需要开启三个独立的 Agent Session。

每个 Session 都有自己的上下文，需要分别跟进进度。如果其中一个任务需要引用另一个任务的结果，还可能需要手动复制信息。

更麻烦的是，当某个任务执行了十几分钟，我们可能需要主动回去查看它有没有完成、是否遇到问题。

DeepSeek 在文章中提到，根据他们的观察，一个人通常只能同时跟进 3 到 5 个活跃 Session。

这就导致一个问题：

单任务的执行能力主要受模型限制，而多任务的执行能力开始受到人类注意力的限制。

此外，传统 Agent 还有几个问题：

• 同步阻塞：一个 Session 正在执行长任务时，新的请求往往需要等待。
• 上下文混乱：多个任务共享上下文，容易造成信息干扰。
• 缺少主动性：大多数 Agent 需要用户明确发起任务。
• 运行不持久：本地设备关闭后，Agent 也随之停止。

DeepSeek 认为，要解决这些问题，需要让 Agent 摆脱单个 Session 的限制。

由此提出了 Super-agent。

二、什么是 Super-agent？

DeepSeek 为 Super-agent 定义了四个基础特征：

特征	含义
连续（Continuous）	跨越不同会话和通信渠道，保持统一的任务上下文
高效（Efficient）	快速响应用户，同时并行执行多个复杂任务
主动（Proactive）	观察外部事件，在适当的时候主动发起任务
持久（Persistent）	长期在线，支持异常恢复与跨设备运行

可以用一个软件开发场景来理解。

假设团队在飞书群里讨论一个 Bug。

传统 Coding Agent 的工作方式是：

开发人员发现 Bug，然后打开 Coding Agent，描述问题，让它分析代码、修复问题。

Super-agent 则希望实现另一种工作方式：

它持续关注被授权的团队消息。当发现某条消息可能涉及软件缺陷时，主动分析问题，必要时启动一个独立 Worker 复现问题并尝试修复。

修复完成后，它可以创建 Pull Request，并在原来的飞书讨论中反馈结果。

如果有人在 GitHub 上提出修改意见，Agent 还能够继续处理。

整个过程可以跨越飞书、GitHub 等不同平台。

DeepSeek 在文章中展示了内部实例的类似实践，包括在没有被主动 @ 的情况下，从公共群聊中识别问题并提交修复 PR。

不过，要实现这样的能力，仅仅增加几个 Tool 或 MCP Server 显然不够。

这就涉及 Super-agent 最重要的设计：双层架构。

三、双层架构：Router 与 Worker

DeepSeek 将 Super-agent 分成两个逻辑层：

• Router：负责统一交互、全局上下文和任务分派。
• Worker：负责具体任务的执行。

整体结构如下图所示：

3.1 Router：只负责协调，不负责执行

Router 是一个常驻的全局协调层。

它负责接收来自不同渠道的消息，理解用户意图，维护跨任务的信息，并把具体工作交给 Worker。

这里有一个重要设计：

Router 尽量不参与具体任务的执行。

例如，用户要求修复一个 Bug。

Router 不需要自己读取整个代码仓库、分析调用链或者修改文件。

它只需要判断这是一个需要执行的开发任务，然后创建或找到对应的 Worker。

Worker 负责完成具体工作，再把结果反馈给 Router。

这种职责划分能够避免 Router 被耗时任务阻塞。

DeepSeek 甚至提到，Router 可以不配置 Bash 工具，因为它本身不需要直接操作执行环境。

Router 处理的是高层次的任务关联与交互，因此可以考虑使用较轻量的模型，以降低响应延迟和推理成本。

3.2 Worker：独立上下文，并行执行

Worker 才是真正负责干活的 Agent。

每个 Worker 拥有独立的 Session 和执行环境，可以使用文件系统、终端、代码仓库等工具。

例如：

• Worker A 正在排查数据库连接池问题。
• Worker B 正在开发一个新的接口。
• Worker C 正在审查某个 Pull Request。

三个 Worker 可以同时运行，彼此的上下文互不干扰。

由于 Worker 直接决定任务完成质量，因此通常需要使用能力更强的模型。

此外，Worker 不直接向用户发送消息，而是通过 Router 汇报任务状态和结果。

这样可以避免多个 Worker 同时向用户发送消息，造成交互混乱。

3.3 为什么不直接使用 Multi-Agent？

看到这里，可能会觉得这与传统 Multi-Agent 架构非常相似。

确实，两者在形式上都有一个协调者和多个执行者。

但设计目标存在区别。

传统 Agent Team 往往围绕单个复杂任务展开。

例如，开发一个系统时，由一个主 Agent 负责规划，再安排不同子 Agent 分别开发前端、后端和测试。

主 Agent 需要深入参与任务拆解、进度协调和结果整合。

Super-agent 的 Router 则更关注跨任务的连续性。

它不需要知道 Worker 内部每一步如何执行，只需要知道任务是什么、由谁负责、当前进度如何，以及什么时候需要通知用户。

因此，Router 与 Worker 的分离，本质上是在系统架构层面隔离全局协调和具体执行。

这也意味着，Super-agent 并不要求每个任务内部都采用 Multi-Agent。

一个 Worker 完全可以使用单 Agent Loop，结合 Skill 和 Tool 完成任务。

四、事件驱动：让 Agent 具备主动性

传统 Agent 的主要交互方式是用户主动发起请求。

Super-agent 则需要持续观察外部环境。

例如：

• GitHub 出现新的 Issue。
• Pull Request 收到新的 Review Comment。
• 飞书群里有人反馈系统异常。
• 某个后台任务执行完成。
• 定时巡检发现异常。

这些都可以成为触发 Agent 行动的事件。

但这里有一个明显的问题。

如果所有事件都直接发送给大模型，成本和系统负载会非常高。

尤其是在企业环境中，一个团队每天可能产生大量消息，其中绝大多数不需要 Agent 处理。

因此，DeepSeek 设计了事件过滤与分发机制。

4.1 快慢双通道

可以把事件处理理解为两个阶段。

首先通过快速、确定性的规则进行过滤。

例如：

• 消息是否来自允许访问的用户？
• 是否属于已经订阅的任务？
• 是否为重复事件？
• 是否满足预先定义的触发条件？

这部分逻辑可以通过普通程序完成，不需要调用 LLM。

对于无法通过规则直接判断的事件，再交给模型进行语义分析。

例如，群聊中有人说：

昨天上线之后，报表接口好像经常超时。

这条消息没有明确要求 Agent 修复问题，但可能值得进一步分析。

模型可以结合上下文判断它是否属于需要处理的软件缺陷。

这种设计的价值在于，尽量减少无意义的模型调用，同时保留处理非结构化信息的能力。

4.2 订阅与直通

并非所有事件都需要经过 Router。

假设 Worker A 正在处理某个 GitHub Issue。

它可以订阅对应的 Issue 或 Pull Request。

当有人在这个 PR 中发表评论时，事件可以直接发送给 Worker A。

这样就不需要每次都让 Router 重新判断由哪个 Worker 处理。

对于长期运行的 Agent 来说，这种订阅机制很重要。

因为一个任务可能持续几十分钟，甚至跨越多天。

如果每次事件都重新创建 Session，任务上下文就很难保持连续。

4.3 投机执行

文章还讨论了一个比较有意思的设计：Speculative Execution，投机执行。

它的思路是，当系统认为某个事件可能需要处理时，可以提前启动部分工作，而无需立即通知用户。

例如，群聊中有人反馈某个接口异常。

Agent 可以先在后台读取相关日志、定位代码，甚至尝试复现问题。

如果最终判断这是一个值得处理的任务，就继续推进。

如果判断没有必要处理，则停止。

这类似于计算机系统中的推测执行思想：提前完成可能有价值的工作，以降低后续等待时间。

当然，投机执行也会消耗计算资源，因此需要限制资源预算和操作权限。

五、全双工交互：执行任务时也能随时沟通

传统 ReAct Agent 通常按照「用户输入、模型思考、工具调用、观察结果、继续思考、最终回复」的流程运行，下图上半部分就是这种同步的方式：

在一个长任务执行过程中，用户往往需要等待。

如果中途想补充要求，就可能遇到新的输入无法及时处理，或者必须中断当前任务的问题。

Super-agent 希望实现全双工交互。

例如：

用户：帮我修复订单接口的超时问题。

Agent：已经开始排查。

用户：优先检查数据库慢查询。

Agent：收到，已经将这个信息同步给执行任务的 Worker。

用户：另外帮我看看昨天的发布记录。

Agent：已创建另一个任务并开始处理。

在这个过程中，原来的 Worker 可以继续执行。

Router 始终保持响应能力。

这里的关键是，人类交互和后台任务执行拥有不同的生命周期。

用户发送消息不必等待后台任务完成，后台任务也不需要因为用户发来新消息而中断。

此外，Agent 还需要根据不同通信渠道调整表达方式。

例如，在 IM 群聊中应该尽量简洁，在 GitHub PR 中则可以提供更详细的技术分析。

这种设计能够减少 Agent 对用户注意力的占用。

六、计算、状态与环境分离

如果希望 Agent 持续运行，就需要解决另一个问题：

本地电脑关闭之后怎么办？

传统 Coding Agent 通常运行在本地终端中。

本地电脑休眠、网络中断或者进程退出，都可能导致任务停止。

DeepSeek 提出将计算、状态与执行环境进行分离，结构如下图所示：

Agent 的推理和任务管理可以在云端持续运行。

本地设备则作为可连接的执行环境，按需提供文件访问、应用操作等能力。

即使用户关闭电脑，云端 Agent 仍然可以处理不依赖本地设备的任务。

从工程角度来看，这种设计也有利于任务恢复。

例如，Worker 进程异常退出后，系统可以根据持久化的任务状态恢复执行。

不过，这里有一个需要注意的地方。

持久化 Session 并不等于简单地保存完整聊天记录。

实际系统还需要保存任务状态、工具执行结果、事件处理进度，以及必要的上下文信息。

尤其对于具有副作用的操作，还需要考虑幂等性。

例如，Agent 在创建 Pull Request 后发生异常，恢复时不能再次创建一个重复的 PR。

这些都是构建长期运行 Agent 时需要解决的工程问题。

七、Watchdog：监督 Agent 的 Agent

长时间运行的 Agent 还可能出现另一类问题：执行过程失控。

例如：

• 不断重复相同的工具调用。
• 长时间停留在某个错误的解决方向。
• 遇到异常后持续重试。
• 已经偏离最初的任务目标。
• 消耗大量 Token，却没有取得有效进展。

传统 Agent 可以依靠用户发现这些问题并手动干预。

但 Super-agent 的目标恰恰是减少人工监控。

因此，DeepSeek 引入了 Watchdog 机制。

Watchdog 可以理解为一个外部监督者。

它定期检查 Agent 的执行状态，判断任务是否正常推进。

例如：

Watchdog 可以关注任务运行时间、重复行为、错误频率、进度变化等信号。

当检测到异常时，可以采取重新规划、重启 Worker、暂停任务或请求人工介入等措施。

需要强调的是，Watchdog 本身也可能误判。

因此，对于生产系统，比较合理的做法是将确定性监控与模型判断结合起来。

例如，超时、资源占用、重试次数可以通过程序判断；任务是否偏离目标，则可能需要模型进行语义分析。

八、实验结果：双层架构带来了什么？

DeepSeek 在文章中还通过实验比较了不同架构的任务执行效率。

其中值得关注的是任务完成时间。

根据文章披露的实验结果：

指标	Super-agent	单会话与子任务对照方案
p50 任务完成时间	12.4 分钟	约 20 分钟
p95 任务完成时间	15.7 分钟	29.5 分钟

这说明在其测试条件下，Super-agent 不仅改善了中位数任务完成时间，也明显降低了长尾延迟。

更有意思的是，团队还尝试通过 Prompt 优化对照方案，让主 Agent 更积极地分派任务。

优化后，p50 可以下降到约 14 分钟，但 p95 仍然接近 29 分钟。

这说明，仅靠 Prompt 调整调度策略，可能难以解决系统层面的阻塞问题。

当然，Super-agent 也存在成本。

文章披露的实验中，Super-agent 的缓存读取 Token 量明显高于对照方案，部分指标接近后者的四倍。

因此，吞吐量、响应速度和推理成本之间仍然存在权衡。

这些实验数据也需要结合测试任务、并发规模和执行环境理解，不能直接推广为所有 Agent 系统都能获得相同的性能提升。

九、从 Agent 工程角度看，这套架构有什么价值？

看完这篇文章，我觉得有几个值得关注的地方。

9.1 Session 应该成为系统内部概念

现在很多 Agent 产品直接把 Session 暴露给用户。

用户需要自己创建会话、管理上下文、记住每个会话正在做什么。

但从产品设计上看，这种方式其实把底层实现细节转嫁给了用户。

对于一个长期运行的 Agent，用户真正关心的是任务。

例如：

• 订单接口的 Bug 修复到哪里了？
• 昨天安排的代码审查有没有完成？
• 上周提到的优化方案是否已经落地？

至于这些任务分别使用了几个 Session，用户通常不需要知道。

因此，未来的 Agent 系统可能会越来越强调 Task、Project 等高层对象，而将 Session 隐藏在内部。

9.2 Agent Runtime 会越来越像传统分布式系统

Super-agent 的很多设计，其实都可以在传统计算机系统中找到对应概念。

Agent 系统设计	传统系统中的类似概念
Router	调度器、协调节点
Worker	工作进程、任务执行器
Trigger	事件、消息
Subscription	发布订阅
Session State	状态持久化
Watchdog	健康检查、故障监控
Speculative Execution	推测执行
Context Isolation	进程隔离、任务隔离

这意味着，随着 Agent 系统复杂度提高，传统软件工程中的很多经验会重新变得重要。

例如消息队列、任务调度、状态机、幂等性、故障恢复、资源隔离等。

模型负责理解和决策，系统架构则负责保证任务能够可靠地运行。

9.3 主动性需要配合权限边界

Super-agent 的主动性非常有吸引力，但也会带来风险。

例如，Agent 看到群聊中有人反馈问题后，是否应该立即修改代码？

修改完成后，是否可以自动合并 PR？

如果 Agent 能操作生产环境，又应该如何限制它的权限？

这些问题不能完全交给模型自行判断。

实际落地时，仍然需要明确的权限控制、操作审批和审计机制。

尤其是涉及生产发布、数据删除、资金操作等高风险行为时，必须保留必要的人类确认环节。

9.4 主动执行不意味着频繁打扰用户

我认为这是 Super-agent 很容易被忽略的一点。

如果 Agent 只是把原来需要用户主动查看的任务状态，变成不断向用户发送消息，那么它并没有真正降低管理成本。

一个好的 Super-agent 应该能够判断：

什么时候需要通知用户？

什么时候应该继续在后台执行？

什么时候需要用户做决策？

什么时候只需要记录结果？

因此，除了任务完成率和执行耗时之外，单位任务消耗的人类注意力，也可能成为未来衡量 Agent 系统的重要指标。

十、开源原型与实际落地

DeepSeek 同时开放了一个研究原型：

https://github.com/deepseek-ai/dsh-superagent-prototype

这个项目基于 DeepSeek Harness，面向单个 GitHub 仓库的开发工作流，可以监听 GitHub 事件，并可选接入飞书。

它会根据授权用户的请求或预先配置的规则创建任务，在独立的 Agent Session 和工作目录中执行，并通过原始交互渠道反馈结果。

不过，官方 README 也明确说明：

该项目是研究原型，尚未达到生产就绪状态。

公开版本与内部实现并不完全一致，文章中的部分架构设计也还没有在开源原型中实现。

因此，当前更适合把它作为 Agent Runtime 的架构参考，而不是直接用于生产环境。

总结

DeepSeek 这篇文章讨论的核心问题，是如何让 Agent 从单个任务的执行工具，发展为能够持续工作的系统。

其提出的几个关键设计包括：

1. 使用 Router 与 Worker 双层架构，分离全局协调和任务执行。
2. 通过事件驱动和订阅机制，让 Agent 能够主动响应环境变化。
3. 通过全双工交互，让用户沟通与后台任务执行互不阻塞。
4. 将计算、状态和环境分离，支持长期运行和异常恢复。
5. 使用 Watchdog 监督执行过程，降低人工监控成本。

这些设计并不依赖某一种特定模型。

随着模型的工具使用和复杂任务执行能力不断提升，Agent 系统的瓶颈也会逐渐从单次推理能力，转向并发调度、上下文管理、运行可靠性和人机协作效率。

从这个角度看，Super-agent 的意义在于，它开始把 Agent 当作一个需要长期运行的软件系统来设计。

未来 Agent 的竞争，除了模型能完成多复杂的任务，还要看系统能以多低的人工管理成本，持续、可靠地完成这些任务。

参考资料

• DeepSeek：《Super-agent 设计探索：迈向更自主的 Agent 系统》：https://mp.weixin.qq.com/s/zoS7GlReWPhfCjENGxXCdg
• DeepSeek Super-agent 开源原型：https://github.com/deepseek-ai/dsh-superagent-prototype